From nobody Thu Oct 1 00:40:45 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822773A0DEB for ; Thu, 1 Oct 2020 00:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmIAKIr8CaQX for ; Thu, 1 Oct 2020 00:40:42 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E5B3A0DE9 for ; Thu, 1 Oct 2020 00:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22895; q=dns/txt; s=iport; t=1601538041; x=1602747641; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=eQFDEEGiFo+EqMqUvu1C8Du/zMohhVSvx8WSr5lXb7M=; b=MlJ2RGnRRgImdQ9l6c0Bvw6q6cAYLTcc1voIW03Lc5oAepuWUgHg7F+y Q9O7IiOIZQ/Stcqt1hHBVVl5UzyHz2AwoPWP9i0aWP2gwtOiqJ2vKiClh wCnssiPp7IKvORucVe9PH14kNnHkRnopzcgC/cV9jmeXi2GeV3LyT34aD 4=; X-IPAS-Result: =?us-ascii?q?A0ByAACzhnVf/xbLJq1gGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFPgxpVASASLIQ9iQKIGC6aOYFpCwEBAQ8YCwwEAQGESwKCM?= =?us-ascii?q?iY4EwIDAQEBAwIDAQEBAQUBAQECAQYEbYVcDIVyAQEBAwEBASEPAQU2CQIFB?= =?us-ascii?q?wQJAhEEAQEBAgIjAwICJx8JCAYNBgIBAYMiAYJcIA+ZIZsFdoEyg0+BAEFDg?= =?us-ascii?q?zOBQoEOKo1JgUE/gREngmk+glwBAQIBAYEmARIBgziCYASQAxmKQIp5kXGCc?= =?us-ascii?q?YMThWiRUwUHAx+DDoEoiFiFE4xHgi+deJVLgWsjZ3AzGggbFRohgmkJRxkNj?= =?us-ascii?q?isXg06DRoFOhUQ/AzACNQIGAQkBAQMJjxIBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,323,1596499200"; d="scan'208";a="27604349" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Oct 2020 07:40:37 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 0917eaaK000373; Thu, 1 Oct 2020 07:40:36 GMT To: Robert Raszuk Cc: "lsr@ietf.org" , Huzhibo , "Joel M. Halpern" References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <04d09cb0fe8341d184683ca01d5b6ae3@huawei.com> <93b3a490-d76d-8db4-5083-238120c0edda@joelhalpern.com> <080f7dacdcfd403b9f640aad565ca350@huawei.com> <51f3f15f-5b13-0840-7357-a4297af65287@cisco.com> From: Peter Psenak Message-ID: <6e56db6d-7d0d-fa74-efe6-cd82f5164dc5@cisco.com> Date: Thu, 1 Oct 2020 09:40:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 07:40:45 -0000 Robert, On 30/09/2020 19:30, Robert Raszuk wrote: > Peter, > > Granted - you can do this with MPLS encapsulation. > > But if you are doing native IP forwarding or SRv6 I am still unclear. > > Imagine you get allocated by RIR say IPv4 /16 or IPv6  /32. > > So you take some part of that block and use it for flex algo next hops > .. flood it via IGP and have flex algo F1 running/enabled on some nodes. > So far so good. > > But what prevents the non enabled nodes to still use for those next hops > less specific say /8 from someone else in the Internet ? we are talking IGPs here. A node send FA(X) route and inside the area all routers see it and can only route to it via nodes that are participating in FA(X). The only place where routes can get modified is at the inter-area or inter-domain boundary. That needs to be FA(X) aware if you want end-to-end FA(X) path. The case you are describing is that a BGP speaker that is not FA(X) aware outside of the originating AS will pick the NH that is advertised in a summary that is not associated with any FA. Traffic will get directed to the right AS, and inside that AS, the first FA(X) aware router will switch to FA(X) aware path. thanks, Peter > > Sure in some implementations (we both are a bit familiar with) we have a > way to track that next hop is declared unreachable if it was learned > from prefix shorter then /X. But this constrain seems to be not > documented anywhere in respect to flex algo. At min I think IP flex algo > use should make it clear and make it also a MUST. > > So my point is that for SRv6 or Ron's proposal next hop MUST be only > learned via local IGP or be of no less then /X to be used for BGP next > hop resolution. > > Many thx, > R, > > > > > > > > On Wed, Sep 30, 2020 at 5:18 PM Peter Psenak > wrote: > > Robert, > > On 30/09/2020 16:28, Robert Raszuk wrote: > > Peter, > > > > Let's see if we are talking about the same thing ... > > > > Take SRv6 as example ... You can run flex algorithm only on selected > > segment endpoints as you do encap and dst rewrite. So rest of the > > network (P/transit routers) do not need to have a clue about any > > flex-algo other then plain old SPF. > > if all transit nodes do not participate/understand flex-algo, you will > not be able to route the traffic between the segment endpoints based on > the flex-algo, in other words algo specific locators will not be > reachable. > > > > > Now in Ron's case where there is no encap and you are applying > flex-algo > > to naked packets don't you think there is a difference and a bit of > > deployment difficulty to make it work ? > > it is the same as with SRv6 locator - prefix associated with algorithm, > with some additional SRv6 data. From the flex-algo calculation and > forwarding perspective there is no difference. > > > > > So assume one P node will not support it. This is native IP > switching so > > BGP advertises routes with new flex-algo next hop. If that next > hop is > > unreachable as signalling to that flex algo loopback was not > understood > > by P (new signalling extension) packets will be dropped. > > such P node would never ever be in the flex-algo forwarding path for > prefix associated with flex-algo. We are talking underlay here, not > BGP. > BGP service allocates the SRV6 SID from the algo specific locator in > case of SRv6. It can pick the NH as algo specific prefix I assume and > the rest is the same. > > > > > But what if that next hop would happen to be covered by some > aggregate > > route not subject perhaps to intended IP TE ? > > aggregation needs to be algo aware for it to work. > > thanks, > Peter > > > > > > Cheers, > > R. > > > > > > > > On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak > > >> wrote: > > > >     Hi Robert, > > > >     On 30/09/2020 09:28, Robert Raszuk wrote: > >      > Hi, > >      > > >      >  > It uses the HBH option > >      > > >      > Currently Ron's proposal seems to work well for both IPv4 > and IPv6 > >      > addresses. I hope this discussion will not try to derail it to > >     IPv6 only > >      > track. > >      > > >      > I see no issue with loopback to flexible algorithm mapping > in 1:1 > >     fashion. > >      > > >      > I do however see some issues in deploying such technology > as it will > >      > only work well if *all* nodes in the network support this new > >      > functionality. In contrast in SR world or control plane > based TE I > >      > proposed or any encapsulation based proposal only anchor nodes > >     need to > >      > support the new functionality while rest of the network > does not > >     need to > >      > be even aware about it. > > > >     above is not really true. > > > >     Algo participation needs to be signaled, one way or the > other. It's > >     done > >     for SR as well. There is no need for all routers to understand > >     flex-algo, as only those that participate (and as a result also > >     understand it) will be used during the flex-algo path > computation and > >     consequently flex-algo specific forwarding. This applies to > >     flex-algo in > >     general, regardless of the data plane being used. > > > >     thanks, > >     Peter > > > > > >      > > >      > Many thx, > >      > R. > >      > > >      > > >      > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo > > >     > > >      > > >>> wrote: > >      > > >      >     Hi Joel: > >      > > >      >          For details about the method defined in RFC 6550. It > >     uses the > >      >     HBH option to carry the RPLInstaceID. The RPLInstaceID and > >      >     FlexAlgoID are similar. > >      > > >      >     Thanks > >      > > >      >     Zhibo > >      > > >      >     -----Original Message----- > >      >     From: Lsr [mailto:lsr-bounces@ietf.org > > >     > > >      >      >>] > >     On Behalf Of Joel M. Halpern > >      >     Sent: Wednesday, September 30, 2020 12:05 PM > >      >     Cc: lsr@ietf.org > > > >     >> > >      >     Subject: Re: [Lsr] New Version Notification for > >      >     draft-bonica-lsr-ip-flexalgo-00.txt > >      > > >      >     I am missing something in this discussion of multiple > algorithms. > >      > > >      >     My understanding of flex-algo whether for MPLS, SRv6, > SRH, or > >     IPv6, > >      >     is that you need to associated a forwarding label > (e.g. MPLS > >     label > >      >     or IPv6 > >      >     address) with a specific algorithm so that you can compute > >     the next > >      >     hope for the forwarding label using the proper algorithm. > >     Then when > >      >     a packet arrives, it is simply forwarded according to the > >     forwarding > >      >     table (e.g. > >      >     FIB, LIB, ..) > >      > > >      >     If that is so, then I do not understand how a given > prefix can be > >      >     safely associated with more than one algorithm.  I > could imagine > >      >     doing several calculations according to different > >     algorithms.  But > >      >     how do you decide which one applies to the packet?  As > far as I > >      >     know, flex-algo does not look at the QoS/CoS/ToS bits. > >      > > >      >     Yours, > >      >     Joel > >      > > >      >     PS: I will admit that it took until  an operator > described some > >      >     "interesting" constraints before I understood why one > would > >     even do > >      >     this. > >      > > >      >     On 9/29/2020 11:50 PM, Huzhibo wrote: > >      >      > Hi. > >      >      > > >      >      > Associating multiple algorithms with a given prefix > is an > >      >     interesting topic, and I think this can simplify the > >     complexity of > >      >     FlexAlgo. I wonder if the author would consider using > cases with > >      >     multiple algorithms with a given prefix. > >      >      > > >      >      > Thanks > >      >      > > >      >      > ZHibo > >      >      > > >      >      > -----Original Message----- > >      >      > From: Lsr [mailto:lsr-bounces@ietf.org > > >     > > >      >      >>] > >     On Behalf Of tony.li@tony.li > > > >      >      > >> > >      >      > Sent: Tuesday, September 29, 2020 10:05 PM > >      >      > To: Ron Bonica > > >      > > >      >      > >      >>> > >      >      > Cc: lsr@ietf.org > > > >      > >> > >      >      > Subject: Re: [Lsr] New Version Notification for > >      >      > draft-bonica-lsr-ip-flexalgo-00.txt > >      >      > > >      >      > > >      >      > Ron, > >      >      > > >      >      > This is nice. It makes it clear that constraint > based path > >      >     computation need not have MPLS overhead for those that > don’t > >     want it. > >      >      > > >      >      > One thing that you don’t talk about is how this > gets used, tho > >      >     that may be blindingly obvious: you’ll need all nodes > placing > >     their > >      >     prefixes in the RIB/FIB, where it will need to be > selected over > >      >     other path computation for the same prefixes.  This > somewhat > >      >     precludes the possibility of a given prefix being > useful in > >     multiple > >      >     flex-algos. > >      >      > > >      >      > More text on application would be most welcome, > just to ensure > >      >     that we’re on the same page. > >      >      > > >      >      > Tony > >      >      > > >      >      > > >      >      >> On Sep 29, 2020, at 6:37 AM, Ron Bonica > >      >      > >      > > >      >      > >      >>> wrote: > >      >      >> > >      >      >> > >      >      >> Please review and comment > >      >      >> > >      >      >>                                        Ron > >      >      >> > >      >      >> > >      >      >> > >      >      >> Juniper Business Use Only > >      >      >> > >      >      >>> -----Original Message----- > >      >      >>> From: internet-drafts@ietf.org > > >      > > >      >      > >      >> > >      > > >      >      > >      >>> > >      >      >>> Sent: Tuesday, September 29, 2020 9:36 AM > >      >      >>> To: Parag Kaneriya > >     > > >      >      >>>; > >     Shraddha Hegde > >      >      >>> > > >      > >>>; Ron > >      >     Bonica > > >      > >>>; Rajesh M > >      >      >>> > > > >      > >>>; William > >      >     Britto A J > >     > > > >     >>> > >      >      >>> Subject: New Version Notification for > >      >      >>> draft-bonica-lsr-ip-flexalgo-00.txt > >      >      >>> > >      >      >>> [External Email. Be cautious of content] > >      >      >>> > >      >      >>> > >      >      >>> A new version of I-D, > draft-bonica-lsr-ip-flexalgo-00.txt > >      >      >>> has been successfully submitted by Ron Bonica and > posted > >     to the > >      >     IETF > >      >      >>> repository. > >      >      >>> > >      >      >>> Name:           draft-bonica-lsr-ip-flexalgo > >      >      >>> Revision:       00 > >      >      >>> Title:          IGP Flexible Algorithms > (Flexalgo) In IP > >     Networks > >      >      >>> Document date:  2020-09-29 > >      >      >>> Group:          Individual Submission > >      >      >>> Pages:          14 > >      >      >>> URL: > >      > > https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- > >      >      >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > >      >      >>> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > >      >      >>> Status: > >      >      >>> > >      > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b > >      >      >>> o > >      >      >>> nica-lsr- > >      >      >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > >      >      >>> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > >      >      >>> Htmlized: > >      >      >>> > >      > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr > >      >      >>> a > >      >      >>> ft- > >      >      >>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > >      >      >>> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > >      >      >>> Htmlized: > >      > https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > >      >      >>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > >      >      >>> > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > >      >      >>> > >      >      >>> > >      >      >>> Abstract: > >      >      >>>    An IGP Flexible Algorithm computes a > constraint-based > >     path > >      >     and maps > >      >      >>>    that path to an identifier.  As currently defined, > >     Flexalgo > >      >     can only > >      >      >>>    map the paths that it computes to Segment > Routing (SR) > >      >     identifiers. > >      >      >>>    Therefore, Flexalgo cannot be deployed in the > absence > >     of SR. > >      >      >>> > >      >      >>>    This document extends Flexalgo, so that it can map > >     the paths > >      >     that it > >      >      >>>    computes to IP addresses.  This allows > Flexalgo to be > >      >     deployed in any > >      >      >>>    IP network, even in the absence of SR. > >      >      >>> > >      >      >>> > >      >      >>> > >      >      >>> > >      >      >>> 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 > . > >      >      >>> > >      >      >>> The IETF Secretariat > >      >      >>> > >      >      >> _______________________________________________ > >      >      >> Lsr mailing list > >      >      >> Lsr@ietf.org > > > >     >> > >      >      >> https://www.ietf.org/mailman/listinfo/lsr > >      >      > > >      >      > _______________________________________________ > >      >      > Lsr mailing list > >      >      > Lsr@ietf.org > > > >     >> > >      >      > https://www.ietf.org/mailman/listinfo/lsr > >      >      > _______________________________________________ > >      >      > Lsr mailing list > >      >      > Lsr@ietf.org > > > >     >> > >      >      > https://www.ietf.org/mailman/listinfo/lsr > >      >      > > >      > > >      >     _______________________________________________ > >      >     Lsr mailing list > >      > Lsr@ietf.org > > >     >> > >      > https://www.ietf.org/mailman/listinfo/lsr > >      >     _______________________________________________ > >      >     Lsr mailing list > >      > Lsr@ietf.org > > >     >> > >      > https://www.ietf.org/mailman/listinfo/lsr > >      > > > > From nobody Thu Oct 1 01:07:37 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E7B3A0E19 for ; Thu, 1 Oct 2020 01:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmw1M_KLRygf for ; Thu, 1 Oct 2020 01:07:31 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99013A0E1A for ; Thu, 1 Oct 2020 01:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4002; q=dns/txt; s=iport; t=1601539650; x=1602749250; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=F9gn31wkiz1eLxQNnPEtODaRSzmLkH1AZvJk1OHoptU=; b=FB7HuUgHa8oZ/Z6Yy58Un8VA9P7QX7VuX076sjXX34Idfh3ltY/0cZyP tDA5fiYVLpr56gnj6UxzFxnBudQTup8midHp0Ak2uYdxrijjJMAUzvq+U jdsECSbyTOKgsRBBjBQHFbpPPY6+rcpN5UOZT/JjOjYvA0WU1fks53UBp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAwBEjXVf/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DGlUBIBIshD2JAogZLpo5gWkLAQEBDxgNCgQBAYRLAoI?= =?us-ascii?q?yJjgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBBAEBIRU2CQ4ECxEEAQEBAgI?= =?us-ascii?q?mAgInKAgGAQwGAgEBgyIBgnwPrwZ2gTKET0FDgzaBQoEOKo1JgUE/gTiCaT6?= =?us-ascii?q?CXAEBAgEBgSYBEgGDOIJgBJpcgRmbUYJxgxOFaJFTBQcDH4MOgSiIWIUTjEe?= =?us-ascii?q?CL5MNimuVS4FrI2dwMxoIGxUaIYJpCUcZDZIQhRSFRD8DMAI1AgYKAQEDCY8?= =?us-ascii?q?SAQE?= X-IronPort-AV: E=Sophos;i="5.77,323,1596499200"; d="scan'208";a="30042513" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Oct 2020 08:07:26 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 09187QgK008918; Thu, 1 Oct 2020 08:07:26 GMT To: Ron Bonica , "lsr@ietf.org" References: <160138654056.12980.329207214151594381@ietfa.amsl.com> From: Peter Psenak Message-ID: Date: Thu, 1 Oct 2020 10:07:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 08:07:33 -0000 Hi Ron, I can only guess the use-case, but it may be worth of documenting it in the draft. Your proposal is basically mimicking SRv6 Locator behavior for regular IPv6 and IPv4 prefixes. One can even argue that for IPv6 you can use a Locator advertisement with no SIDs, but I agree that would be a hack and separate encoding is cleaner. One thing that needs further work is the algo participation part. Given that we have a separate participation for SR and IP flex-algo, one would have to run a separate calculation each in the context of the same flex-algo. Even though in most cases one would expect the set of participating routers to be the same for both. I don't see an easy way out, actually this is what the base FA draft requires it in section 10.2. What I would suggest is to clearly document the fact that the computation for the IP flex-algo is independent of the other flex-algo computations (e.g. SR) and that IP flex-algo is an application of its own from the flex-algo perspective. Les has commented on ISIS encoding, I have a question on OSPF one - have you considered using the OSPFv2 Extended Prefix Opaque LSA with OSPFv2 Extended Prefix TLV (rfc7684) and define a new "IP Felex-algo" metric sub-TLV? thanks, Peter On 29/09/2020 15:37, Ron Bonica wrote: > > Please review and comment > > Ron > > > > Juniper Business Use Only > >> -----Original Message----- >> From: internet-drafts@ietf.org >> Sent: Tuesday, September 29, 2020 9:36 AM >> To: Parag Kaneriya ; Shraddha Hegde >> ; Ron Bonica ; Rajesh M >> ; William Britto A J >> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt >> >> [External Email. Be cautious of content] >> >> >> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt >> has been successfully submitted by Ron Bonica and posted to the IETF >> repository. >> >> Name: draft-bonica-lsr-ip-flexalgo >> Revision: 00 >> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks >> Document date: 2020-09-29 >> Group: Individual Submission >> Pages: 14 >> URL: https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- >> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ >> Status: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr- >> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ >> Htmlized: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- >> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ >> Htmlized: https://urldefense.com/v3/__https://tools.ietf.org/html/draft- >> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ >> >> >> Abstract: >> An IGP Flexible Algorithm computes a constraint-based path and maps >> that path to an identifier. As currently defined, Flexalgo can only >> map the paths that it computes to Segment Routing (SR) identifiers. >> Therefore, Flexalgo cannot be deployed in the absence of SR. >> >> This document extends Flexalgo, so that it can map the paths that it >> computes to IP addresses. This allows Flexalgo to be deployed in any >> IP network, even in the absence of SR. >> >> >> >> >> 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. >> >> The IETF Secretariat >> > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > From nobody Thu Oct 1 03:13:49 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172FD3A0F0F for ; Thu, 1 Oct 2020 03:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, RCVD_IN_MSPIKE_H2=-0.001, 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=FY2hxd9e; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zGDszgX/ 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 8Xeon3anBcMZ for ; Thu, 1 Oct 2020 03:13:43 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191843A0F0E for ; Thu, 1 Oct 2020 03:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1092; q=dns/txt; s=iport; t=1601547223; x=1602756823; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mLsFyqU2UH8WBfToOlGKo+gn3EJ3Wtawslz49bDIZpk=; b=FY2hxd9eedaRh4idQXt3mNffhOga73TNwOaVuuPXxg9Nm1ffChabEvwe nDr+sJSku/2rYgj6+L4cy4x3Gkv5ffpTeK2XvWcJL5IqvexH3udiHlHCm oelwI2+RqlAg+M/S7+HRmtNOyOeVjWZXqfkQx/ODvx8IFNpLfH2xtLJf0 g=; IronPort-PHdr: =?us-ascii?q?9a23=3A+It7TBxEqupjSFTXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRaBt/5tjVnAQYjf5vlDjqzdtfOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX1Z1zUq2G/6TMZHR?= =?us-ascii?q?C5PgwmbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQCGq3Vf/51dJa1fHQEBAQEJARI?= =?us-ascii?q?BBQUBQIE+BQELAYFRUQeBSS8sCoQzg0YDjgCYd4JTA1ULAQEBDQEBLQIEAQG?= =?us-ascii?q?ESwIXghoCJTcGDgIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQMBEhERDAEBNQI?= =?us-ascii?q?BDwIBCBgCAiYCAgIwFRACBA4FIoMEgkwDDiABnRECgTmIYXaBMoMBAQEFhRE?= =?us-ascii?q?YghAJgQ4qAYJxg2mGUxuCAIE4HIJNPoQbAQEggxczgi2PeYNCpA8KgmeXcIJ?= =?us-ascii?q?qAx+hF7MbAgQCBAUCDgEBBYFqJIFXcBVlAYI+UBcCDY4fN4M6ilZ0NwIGAQk?= =?us-ascii?q?BAQMJfI0FAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,323,1596499200"; d="scan'208";a="568740065" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Oct 2020 10:13:21 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 091ADLUB029624 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2020 10:13:21 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 05:13:20 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 06:13:19 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 1 Oct 2020 05:13:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AvC08GiboV5JX4FpQJcgkks9eabMZ9l8fkacvx7kg+Izpk2+PX0UHqxWfdLjkxvjCKMGiUVU8SpVB5xvM9dZltMCdu795xdDASfWe4X8GR3J0zYyqKnCRn6LfxhcirNjasrrjIvGE2ejE+DFPFdqZwZEqxdJQesFJtHU8MYeaHx1Y7nYs/V8Fcok/rQREETXkl9YfguJNA/X6Y4LAJzw2eSndqrEOe/nw2Hnl9zXG0nABsc0/qmftgC4JR55vVHZSShH45zUNyKPtMT/0DVKFa69QycY2x93z6/BBDagbZK9oS8wLOf1ej5ZSSN/yunPt46NxZ0X/tf5CTjM7K3lBA== 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=mLsFyqU2UH8WBfToOlGKo+gn3EJ3Wtawslz49bDIZpk=; b=lu2r/qiVXxdqFq/XELPVL80WO4SI6zsxNqFhO006cZd8z1Rc+afskNfSkUhQ97MoeLnr6/m2g1MTxwpA5aSWJKXbRj4j2qBy9+49xK0TN8k8u/kaDst5eEXvXjYletlXPvintRxbGXzsLGXwrajJwoVK9GNXSQ8Kh0EZaW4f6fSXhw/tcBec3tPc84wtrssZPczAQ0pOXaYo77KOCW2oEXnIzCkcSUlLfFYYV0l8PT7N6Of6VJa4rtTzWWtua8uGeagMCqq7moMgM1SM5nILcjU1eC3qf+kDkoonrIQr3r77pulMw9J+yxELfUwLWrd6OpA+TAZm0BWSiKVgNULPmw== 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=mLsFyqU2UH8WBfToOlGKo+gn3EJ3Wtawslz49bDIZpk=; b=zGDszgX/afLIAz14xl9ess5IaP6reNeC9q2AtrLk1KbAl/jZFIl017lAfvRJ/DuW7g2bHxXPu8Lzl4ub747YC1C9wUbupivCy/KcLNuv+fdgMSSz5d24K5lRpytvjStuSmStInaGBwW2rnt0alP8J+r40M6OZ9IXqywtX1AWdos= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3797.namprd11.prod.outlook.com (2603:10b6:a03:fe::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21; Thu, 1 Oct 2020 10:13:17 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3412.029; Thu, 1 Oct 2020 10:13:17 +0000 From: "Acee Lindem (acee)" To: Aijun Wang CC: Aijun Wang , "Peter Psenak (ppsenak)" , "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt Thread-Index: AQHWl5yn9zOw389W5Em3DsM/J5vmWamCRKYA Date: Thu, 1 Oct 2020 10:13:17 +0000 Message-ID: <33AEF7BB-F6C4-430F-966D-1AC5CE3266B4@cisco.com> References: <32E90101-724C-4B38-8F11-7CF552B4F926@chinatelecom.cn> In-Reply-To: <32E90101-724C-4B38-8F11-7CF552B4F926@chinatelecom.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: chinatelecom.cn; dkim=none (message not signed) header.d=none;chinatelecom.cn; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb8e17b4-5201-4efb-371c-08d865f29d88 x-ms-traffictypediagnostic: BYAPR11MB3797: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XMkUZsb4icrUHPG0qTJVNXkoUzH4HyTB41Co4jZQmqC3xAKnC1PFDFG5YuSqne/52YbX7ET3liepAPfeMsqtTkuyb7+m3FsRk3BtAcY9FkuBD2oB7nklJY9QdugJ4N2rjHX739o6vVzmG/TUpdwGuS+ERD/qZlvDnzet6MC6DxGe+KUPvqTOsWzNXJ35EESxGYURjTwznFpwwzYR0v3D4F3oiw0EJvEbhWqEBSa+Ue/WF1tdHWHLMno6lQfFzV/zK38c2k5GTbGI6XAb9ACK22rjR6D9SKHwRwR69R6zH6IS2I+2udw4fF+7MnaDVpnFsBctSzbvaSpMOs0rB22DkQehylJ2zpexVG7BArnfcPqaeIXy/bxpubSm4mQAElUD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(346002)(376002)(136003)(366004)(6506007)(53546011)(86362001)(83380400001)(478600001)(186003)(33656002)(15650500001)(54906003)(36756003)(4326008)(26005)(8676002)(316002)(6512007)(2906002)(8936002)(64756008)(66946007)(66446008)(66476007)(66556008)(6916009)(76116006)(5660300002)(4744005)(71200400001)(6486002)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EXOuYZnmyezHYK1/v8+k168XvBBGVuA0+qB0HnSaHtcSjfaJsEKVudJUmy2mUwg0RYmkvdGT6QWaAhl+N8B9aEqFLQGvYgxnZgtB0NvJ3Ims7qDdCWTc0lURVzQluSVXck2NGPJUR9nANofn9Uy10lRchpl+QQEaROlQhRsrcEAQG4jJ1yOEHkNcwFt54UqZ7rQ8axwDLhFu9wFKhsLmsgTPHLf6HAqU673S8qH5V6ObVpnonu16nGu5qEnjIu4DGJArzk128PNFunjriLrCrPs8gAZjbrVAHDB8bDno8MrjXRyCyOvq8ZEEzdN8P4y+R7SgJcjGUwMcdFYJVk3oMUp4DODXwaOYV25jpUEICZW9oq+WCL2kH7OJARpFpxJAg08q6UGcPlik1GZaJQKXAdvew/S/nn51gFPFpoYKhw1iDsAk4XL3j51ZSlZae0Fe+LkkH11brmy64BmV0bWamemXVvflTulPjyEdTF4fYPcTRC14/+nzSzoSXNHfoPuIkkZzZL8P5kd8q4CahBQ6RG7//R/Wd9tP30Mnjn/9L85v/sp/U6ujuD/FlNwHLvFjx0B10iaRizHJZissWLFVxEJ8M2OaS2oFNmKGLAIrpze2AjuAo1h8pUacD4fiPS5+sl5ntfaZDeB2UegEFGKiow== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb8e17b4-5201-4efb-371c-08d865f29d88 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 10:13:17.0497 (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: lcAMVKywJf1+BjFnWmFO6c1gAKKugZ7WQj1IP4EI4wrmr14858OkdRyyDsk3Vhkw X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3797 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 10:13:47 -0000 SGkgQWlqdW4sIA0KWW91IGRpZG4ndCBhbnN3ZXIgbXkgcXVlc3Rpb24gYW5kIHBydW5lZCBteSBt ZXNzYWdlLiBPdGhlciB0aGFuIHlvdXIgYXR0ZW1wdCB0byBleHBvc2UgdGhlIHRvcG9sb2d5IG9m IGFyZWFzIG91dHNpZGUgdGhlIGFyZWEsIHRoZXJlIGlzIG5vIG90aGVyIHJlYXNvbiB0byBhc3Nv Y2lhdGUgdGhlIHBhc3NpdmUgaW50ZXJmYWNlIGF0dHJpYnV0ZSB3aXRoIGEgcHJlZml4LiBXZSBz ZWVtIHRvIGJlIGluIGEgY2lyY3VsYXIgZGlzY3Vzc2lvbi4uLi4gDQpBY2VlDQoNCu+7v09uIDkv MzAvMjAsIDEwOjQzIFBNLCAid2FuZ2FqM0BjaGluYXRlbGVjb20uY24gb24gYmVoYWxmIG9mIEFp anVuIFdhbmciIDx3YW5nYWozQGNoaW5hdGVsZWNvbS5jbj4gd3JvdGU6DQoNCiAgICBIaSwgQWNl ZToNCiAgICBFeGNlcHQgdGhlIGNvcm5lciBjYXNlcyBvZiB1bm51bWJlcmVkIGludGVyZmFjZSwg d291bGQgeW91IGxpa2UgdG8gaWxsdXN0cmF0ZSBvdGhlciBzY2VuYXJpb3MgdGhhdCB0aGUgcHJv Y2VzcyBkb2VzIG5vdCBhcHBseT8NCiAgICBBcyBtZW50aW9uZWQgaW4gbGFzdCBtYWlsLCBrbm93 aW5nIHRoZSBwYXNzaXZlIGludGVyZmFjZXMgY2FuIGFzc2lzdCB0aGUgbm9kZXMgb3IgY29udHJv bGxlciBrbm93IHRoZSBib3VuZGFyaWVzIG9mIHRoZSBuZXR3b3JrLg0KDQogICAgQWlqdW4gV2Fu Zw0KICAgIENoaW5hIFRlbGVjb20NCg0KICAgID4gT24gU2VwIDMwLCAyMDIwLCBhdCAxOTo0Nywg QWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQogICAgPiANCg0KDQo= From nobody Thu Oct 1 07:37:25 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 200203A09DE; Thu, 1 Oct 2020 07:37:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <160156304006.21595.16235591023887706076@ietfa.amsl.com> Date: Thu, 01 Oct 2020 07:37:20 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-06.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 14:37:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Model for OSPFv3 Extended LSAs Authors : Acee Lindem Sharmila Palani Yingzhen Qu Filename : draft-ietf-lsr-ospfv3-extended-lsa-yang-06.txt Pages : 29 Date : 2020-10-01 Abstract: This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-06 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-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 Oct 1 08:31:42 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D903A0B36; Thu, 1 Oct 2020 08:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=VG1qiooD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XtYdU1eK 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 pa5xfOVtTqq0; Thu, 1 Oct 2020 08:31:39 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D983A0AC3; Thu, 1 Oct 2020 08:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1794; q=dns/txt; s=iport; t=1601566298; x=1602775898; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6twgocJ3S999G5OGOV3vScOfNoBWJJ3xMZZVFzbbw90=; b=VG1qiooDrZOJ2zjg3ntauTkwGadLTKDeGIO19ayuqqzzrKueVqk6GT4+ FU55acYh1xmi0HQd+5ewtLYFlezMr1F3iq1YOUiTVUBqPP9QybYftuo41 X3w8IG/0ksff+kjkUf9PKr9CE/bEDE4KI+xasRzuzNlUS/s9AGrxGBNA8 Q=; X-IPAS-Result: =?us-ascii?q?A0C0BgDS9XVf/5xdJa1fgQmBT4FSUQdwWS8sCoQzg0YDj?= =?us-ascii?q?VuZHYEuFIERA1ULAQEBDQEBJQgCBAEBhEsCF4IeAiU0CQ4CAwEBAQMCAwEBA?= =?us-ascii?q?QEFAQEBAgEGBG2FXAELhXMCBBILBhEMAQE3AQ8CAQgaAiYCAgIwFRACBA4FI?= =?us-ascii?q?oMEAYJLAy4BDp9FAoE5iGF2gTKDAQEBBYEzARNBgwwYghADBoEOKoJyg2mGU?= =?us-ascii?q?xuCAIERJwwQgk0+glwCAgEBFYERARIBgzgzgi2TO6QPCoJniHuRXwMfgw6KA?= =?us-ascii?q?JQJkw2Ka5UjAgQCBAUCDgEBBYFUOmdwcBU7KgGCPlAXAg2SEIUUhUJ0DygCB?= =?us-ascii?q?gEJAQEDCXyNBQGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3A0augihWAw/z4+oMZR/J9PMMRxh7V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,323,1596499200"; d="scan'208";a="544310145" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Oct 2020 15:31:38 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 091FVbGB017701 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2020 15:31:37 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 10:31:37 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 10:31:37 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 1 Oct 2020 10:31:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i2epxvt456+ga8tK78O6Ivda5FEnAdqmsWO3Isk6Rs/sSwN0vTAyN6nhB73ILACiB2AGjxrxPBYUaOulXWggyNZpeJ1bvzLdg7HzJz2uq4yclJeYQn4CcITbsBGXP1HkfEh7jYw4NJYA3aHcwLCYpsrGJNW7z7Tr+6xx5e9rU9HY8yTZOFi1/jjY8yctvED/ZMRIzGc6qaGmHwl0I3V5afpec2z7Ldih6Fh0ZHvW7uDZ47Y8lpBlNuwuMHdVocCjJlm359cCoMxG+ANuVcXeTRaje+823X63VKABhJlVeVfY1mfylt3P9d+6rPPxDYSl7s1hVavRYOHXbEKkA/r80w== 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=6twgocJ3S999G5OGOV3vScOfNoBWJJ3xMZZVFzbbw90=; b=RusElCaPX63WJOjxXQc/QGpkblzmI/lcQhY2NXL5nfAYlmM0gTj21rbfUI9wHwK0BpvxUjh9KeFuJZlOC2apNXHy1vyeUIuHJX5WEZuG+Fnl6CWWi9qZeTBQO0UnmQPLYHbTk6PZuFAGOMPatiHwdRhPzxQ5ec0wy36wthBIhoFL5hrFoM9aP6djvz2TTKqP37K40C1ETQBF6PMo1nlnSQdgBq4p1qull6o1eIfjk87p23v8yhO8NZEbgmXOqD3K/rlRsarH5K+VYUaRCtUq3bvfBByUgBiJxc/fv9h8QXf19d9jPoScQXf7OQZJ5Okkc8Mzfh9baWNaxsEIdro/0w== 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=6twgocJ3S999G5OGOV3vScOfNoBWJJ3xMZZVFzbbw90=; b=XtYdU1eKod5HRDhq2kwdgQgo3YNpSvI2uBacYndkwgkQCYBfE7M9E/cuH+6tggi7CSPStFHyuvCsheMSM+NGEI5v8fHvPr7Ag6o2AG9iZrbrJRWROIUofRRBWzW77rZtHo6wde6c54WOyrwAN5IkBoVzrW5uYvXlCVqdNDWJGJE= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB2744.namprd11.prod.outlook.com (2603:10b6:a02:c8::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Thu, 1 Oct 2020 15:31:36 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3412.029; Thu, 1 Oct 2020 15:31:36 +0000 From: "Acee Lindem (acee)" To: "lsr@ietf.org" CC: "lsr-ads@ietf.org" , "draft-ietf-lsr-flex-algo.all@ietf.org" Thread-Topic: WG Last Call for draft-ietf-lsr-flex-algo Thread-Index: AQHWdO5dCxh3DJtMj02Qv0+fxUsOPqmC4vEA Date: Thu, 1 Oct 2020 15:31:35 +0000 Message-ID: <0DA948D0-5337-4870-B4A8-DC16D22FB559@cisco.com> References: <9094873B-3A03-4F48-B438-55AB0CA75396@chopps.org> In-Reply-To: <9094873B-3A03-4F48-B438-55AB0CA75396@chopps.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d4562562-144a-42a6-4f68-08d8661f157c x-ms-traffictypediagnostic: BYAPR11MB2744: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sIth/oxjvkHJX6yoe3YZGnyGfx4NEtlQ4bbN76CkC/bxD0iYVyF9Zs8hgwONH7+aO8YEzJB7LJLKn/q8mzOASzlfe2DBi7EYEWvprvgu2r8HYMmb0HiB7rJFCHZd15IbaYhSmWNk2/eFcyURS4dadh70onPC/iKP5fquYrliMx8Ex9z8l47AEZspwfQNU6KnAnHM2NdX25aWMnYkdm/7/aNNBD6tpRL2THkCCsrlCHYmuOWthrDAa/D6MVu+NFQqIi3jYwQujR4h3zVCCwTaQeDumN+TyQIzTXoolnWmY1If5zDdHawLvzc81H1Ygh77BTT9VxAy/L9oki8IIUd+UAYIYEN4ou+wUlA7RypSwPU5f6vTePSWXITdBH7kDVAO9rSD3ADrs3V91YqOFDV0ed5GWv0RCk8iCjiaWr4k8H5Le9DxwJaezds6XcN+00Rd x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(396003)(39860400002)(136003)(2616005)(33656002)(316002)(6486002)(8676002)(6512007)(4326008)(2906002)(8936002)(36756003)(6916009)(66946007)(66556008)(66446008)(5660300002)(478600001)(66476007)(54906003)(76116006)(64756008)(966005)(71200400001)(26005)(6506007)(450100002)(186003)(86362001)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DkC5dF0T2uVIiUMS+csdzokXoP6DgH/DMCwGJ/ScGZFv1G2EHq+upsv+EjPUS+7Auv5+V0/SUzjgVPVcp5SpEYoAouuTheMmZJjLOypzhOJjZBXDvlERsPcdH6Jrf3n1N4GET/0tXNZ/KzF7/fhUIYaBJwfaZu2Iwij5qy8BIoeaNb1T4aDbU8GqSf8H02pMDqqjPcwc4JVf4anxbrBSAULPui4OSWznMIU1kkCYZHRI/16kU/jtKFfMrPEwHms/HqI9HqmCL4WoR/4DynUDEc5qNw4PM2e75XxXwt60Tf3Ssnmn++MUBTZlXOYPcG8qFabiGlEWvkazFjud7RQlAwRkuMseXvP8e4IC6ZmSEo7w6bdDsZW+ItvVBjCqA+2A8QJchBIjF5JY+UbNJ5CGFSDrSucR89l6KTDUCVPWXa64N4m5XunqxrbewDxtFVUrlzGB6BXO9Lhgo3UJYlvF2hvMIKM+VpARchiI4eke0Hn5e6KxiCUcvsbrkCg9pXv61I1zOXu8RzgHDPd9oEEg/KUEpJaC/dFd17QSS0IKYU8pSlhlDiKrCWupkedWyN51nEbgPeVTO2dT7bzLbAEjTVNxDHzrN+fcET8KfebwdmdX1+T+PavWD2g9ZgpeqtJUNWF49XHvOd9+e2H2kfM+vg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <184DA7CD64AAB444B16451DF8ABCA6A8@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d4562562-144a-42a6-4f68-08d8661f157c X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 15:31:36.2283 (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: 9pnObQtR1ost2AyIqZujQ0qs258v2nzQgxsd+aUOQVDVUTHvnrTaAe7u05NF1lt3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2744 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 15:31:41 -0000 VGhlIFdHIGxhc3QgY2FsbCBoYXMgZW5kZWQuIEFsbCBjb21tZW50cyBoYXZlIGJlZW4gYWRkcmVz c2VkIG9yIGNvbmNsdWRlZC4gVGhlcmUgd2FzIGNvbnNpZGVyYWJsZSBkaXNjdXNzaW9uIHJlZ2Fy ZGluZyB0aGUgcmVxdWlyZW1lbnQgdGhhdCBhbHRlcm5hdGUgbGluayBtZXRyaWNzIGNvbWUgZnJv bSBBcHBsaWNhdGlvbi1TcGVjaWZpYyBMaW5rIEF0dHJpYnV0ZXMgKEFTTEFzKSBhbmQgd2hldGhl ciB0byBhbGxvdyB0aGVtIGZyb20gVEUgYWR2ZXJ0aXNlbWVudHMgYXMgd2VsbC4gVGhlIGNvbnNl bnN1cyB3YXMgdG8gc2luY2UgdGhpcyBpcyBhIG5ldyBhcHBsaWNhdGlvbiBtYW5kYXRpbmcgYSBz aW5nbGUgc291cmNlIG9mIHRydXRoIGZvciBBU0xBcy4gRnJvbSBhIHRlY2huaWNhbCBzdGFuZHBv aW50LCB0aGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSB3aXRoIE9TUEYgd2hlcmUgYWxsb3dpbmcgdGhl bSB0byBjb21lIGZyb20gVEUgYWR2ZXJ0aXNlbWVudHMgcmVxdWlyZXMgY29ycmVsYXRpb24gb2Yg YW4gYWRkaXRpb25hbCBMU0EgcGVyIGxpbmsgYW5kIGFsbCB0aGUgYXR0ZW5kYW50IGNvbXBsZXhp dHkuIA0KDQpUaGUgZG9jdW1lbnQgd2lsbCBiZSBzdWJtaXR0ZWQgdG8gdGhlIElFU0cgZm9yIHB1 YmxpY2F0aW9uIGFzIHNvb24gYXMgSSBjb21wbGV0ZSB0aGUgc2hlcGhlcmQgd3JpdGV1cC4gDQoN ClRoYW5rcywNCkFjZWUgDQoNCu+7v09uIDgvMTcvMjAsIDc6MzAgUE0sICJDaHJpc3RpYW4gSG9w cHMiIDxjaG9wcHNAY2hvcHBzLm9yZz4gd3JvdGU6DQoNCiAgICBUaGlzIGJlZ2lucyBhIDIgd2Vl ayBXRyBMYXN0IENhbGwsIGVuZGluZyBhZnRlciBTZXB0ZW1iZXIgMXN0LCAyMDIwLCBmb3IgZHJh ZnQtaWV0Zi1sc3ItZmxleC1hbGdvDQoNCiAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbHNyLWZsZXgtYWxnby8NCg0KICAgIEFsbCBhdXRob3JzLCBwbGVh c2UgaW5kaWNhdGUgYnkgc2VuZGluZyBhbiBlbWFpbCB0byB0aGUgbGlzdCwgd2hldGhlciB5b3Ug YXdhcmUgb2YgYW55IG90aGVyIElQUiBiZXlvbmQgd2hhdCBpcyBhbHJlYWR5IHBvc3RlZDoNCg0K ICAgICAgW0Zyb20gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9zdWJt aXQ9ZHJhZnQmaWQ9ZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdvXQ0KDQogICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2lwci8zOTEwLw0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9pcHIvMzI0OC8NCg0KICAgIFRoYW5rcywNCiAgICBDaHJpcyAmIEFjZWUuDQoNCg0K From nobody Thu Oct 1 08:33:35 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03C73A0B36; Thu, 1 Oct 2020 08:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=v8f6AuiI; dkim=pass (1024-bit key) header.d=juniper.net header.b=Acw/wBEp 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 7hXH2wYEwKuw; Thu, 1 Oct 2020 08:33:33 -0700 (PDT) Received: from mx0b-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 0FAA13A0B6B; Thu, 1 Oct 2020 08:33:32 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 091FNTll022957; Thu, 1 Oct 2020 08:33:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=0F0vBKT0QN+g7UU0HtDuhnlsqeJqi9fp2rbUq9GrYaY=; b=v8f6AuiIIGbPROfbTeymZlp534ZQcp6HBAZrRsescZTQ81Dil3WqJqBQmuEHhdpLxKlh HJ1qMm2C7A+Y5JPGI7htPpi8RFNOcnYF6UPrE6KOHPTGT5gIv4O5tt0wYXKsE0mHnczR PzZImxaS3ncurpKalm+1pEpdgmBdZZ6ZXuwl+qPaxSm+juOqAoR+ZKO7/RP3MJzGegIL RchtdhD6ljpVcTvWKykqbr+yVGitk98Dk8nRUarYTbBVsUQ/4xRIv1rultAq2y6ltSSK 48Iy0hHc8b4ZseY3jg1cSCzDvTuDIUVM3haptczZW/8QpuimyT4j2NtoYDCVvHVYvVp9 JA== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2104.outbound.protection.outlook.com [104.47.70.104]) by mx0a-00273201.pphosted.com with ESMTP id 33t4wn91r5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Oct 2020 08:33:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hNUNHpZW6ZxcvA7ACTa99lpgDAObRfrxTRZvR6A+iEjHha2lp3KZU75S7eIhkdNFsWgCT5sh2S4DSPHszN77ni3kTVY6PLAz6zsxg4Hes2uxU6A9A/jRrA21khOAO19IIFgrqSzsvpQb4YiGYA+Gyf+Leo3hGeQDdna0mPNSZ44hdsupImJOMqW41l1cXRrMTbmcvJ1jZs4wdQis34Wmza34nC+vZ60r2w6bcYa/Nq0ie4DCdiw0XZupsUjNVPNE7Myot5kEYTctrIzXfnZKXGM18qYG9Uby3dq/148tay8dXGsNG0WtcQK8oljZeWXUKoekGMS1W/+tz8ddxsoZWw== 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=0F0vBKT0QN+g7UU0HtDuhnlsqeJqi9fp2rbUq9GrYaY=; b=fiQeodDU9vtgxSebDritVAL9t1urBkj55pm95yu0TYfV3TdsqDE6F93kdfchnS4/mW2h8fQuSFRzNvoZWw5U+L8jKgFG25w47LrAUa9csDh4X/xXP/Zf9I12HUPSuSaq6k2nCt8vnfcEvTYYDgM0OEIlYh42a+vNQ4d4Jr2dMTWdzZNw9HC3EsWYM7Xnj0EcKJabxay8HSAe30nunMYhaTnNPqEe16Z/ovzwVHbtE7Xw4rTgkjqZ3iRKGZWG+BgciFoh2SM3+mHRqx7rDgVqc+Cqqu+Ofbx+SflQE3ZMs+u+IAOsT9mc4FZnXHcm+bKnLqbl6d4nD5uyAoxC+deLyg== 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=0F0vBKT0QN+g7UU0HtDuhnlsqeJqi9fp2rbUq9GrYaY=; b=Acw/wBEp6IgqItZyH5oDd2kD2U9gqsZe60Ncdkg+YvDMhK+xlXYVaSdePP2ywrwJ+X2q3ayAYS3xzylceJ7XQcJJw8amK74KTnqUsztFjUfjCfESIZ6A/pHvEyzavCpBEIU831fiuxKk5vBqeuFbl6x+SJhIfjQBrt5jSWVaH50= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DS7PR05MB7303.namprd05.prod.outlook.com (2603:10b6:5:2c1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.20; Thu, 1 Oct 2020 15:33:30 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782%3]) with mapi id 15.20.3433.038; Thu, 1 Oct 2020 15:33:30 +0000 From: Ron Bonica To: "Les Ginsberg (ginsberg)" , "lsr@ietf.org" Thread-Topic: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAHu7oCAAVYnUA== Date: Thu, 1 Oct 2020 15:33:30 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-09-29T13:37:30Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=d6b57ccc-2990-43db-bc9b-bf6593cad0d2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 098cd411-406d-4589-f0d9-08d8661f598b x-ms-traffictypediagnostic: DS7PR05MB7303: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QP98cuV6fd1p3HfoklzjykYr2wAHL5hLDAauim7/vRRdA6jZ7yvrZY1Aqy2yPT0ngN/FopU3YhwyFD72ibfc3XPjJNKfKxs/qs3SLfrRXmDLTm7RX4sC53LepObLIuz3jYAyp9Vj9263msA86F+DvishCVoXVGS/QYFSCJHz61JKldT68U3N1KSLwoSdiD2O44kCG1lB+A29+z1kjEUfaRGGSotFHDlonzcg9dzGMs9Q0yK1nbGBrVlL6lYZlyyOaZYChEAh8NIk6S24Rx0386O3tYIcaApn/mNddiFnnNPTuGntagbXs/WyxdvX7u6Dngg3USvQ4wgGtY5LL5UIr04hix1lsVJ55YNrdNM6ZdsGU5d7Xz5+uvx7roblB+iDxPSJE1fGkk+4Y8mP7WBIaQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(346002)(136003)(39860400002)(366004)(55016002)(7696005)(66946007)(186003)(33656002)(966005)(8936002)(478600001)(5660300002)(15650500001)(86362001)(26005)(2906002)(8676002)(64756008)(71200400001)(66476007)(6506007)(66556008)(110136005)(66446008)(53546011)(66574015)(9686003)(83380400001)(316002)(52536014)(83080400001)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: vwR9TWf5d34wx4ruylkPluERKI4tSR/G+f7W24defLcnb8lVPNR7QovR2v5BNXIw8kPxhGLdSGKtwrL2ZiZejpTwk3mrSZ1ABXrl6xqX04n9ygT0Wiv+14+vzMmTSQX7Cnt8oiRE8cvC1P1VdHLdGMJ0tKxFGRFMh2jG8vsozdBLr0bUCctAQwAwi7GCH3s92/TZ71qLpmuyxwZ87jADBo6acz+WUbKa2OCo6wh4cesghw6UHlqKE1lNN6kvUJMT3ORkgWrJFi2S6f+WXnJfmeimBSfroeoCZlNp0+CXUEoWw/0b6cH7bTR2z8m2fK8Zl743ExqPkmgs6GsrHWfstLQFgTtQeAxCYgI2teuKVEK9L64rVx0PrUrIlIg3KZkErWqoijtb0n+SR+QasL5+lp+jTnHw5UcTEE+6fsVfV6zwM//ba67Zz91SS4KxcPWLqI1EO5c2nThOhkGZLXKN4SPeX3Rn4W/Eui7w8F7y1aekHT6IEiSpJ7gFX1uRr8aH7Vv9Sl4EILlQXjyEtA92YPQn6OueimFbM8lv9VJrx+ygueBRNI5qp5DpO1NRowQ66ri935GCvDe4VBEBZngcQp4jsJX9YnI255lNvf8+RTr4nxbZYLEgdH+mY1rEW3iJrQ/mv6E0SkPXL9VB578Nlw== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 098cd411-406d-4589-f0d9-08d8661f598b X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 15:33:30.3728 (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: mNFKjtAJ7cvkElHafyfjhd5Xm+y7DBMtTao4vuCH7a5wKYjt3xKQpdNHlnHUkibJzdArGg6HQa7VBD99623TZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR05MB7303 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-01_05:2020-10-01, 2020-10-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 suspectscore=0 adultscore=0 spamscore=0 bulkscore=0 impostorscore=0 mlxscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010010132 Archived-At: Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 15:33:35 -0000 Les, Thanks for the review. All good catches. We will address them all in the next draft version. Ron Juniper Business Use Only -----Original Message----- From: Les Ginsberg (ginsberg) =20 Sent: Wednesday, September 30, 2020 3:39 PM To: Ron Bonica ; lsr@ietf.org Subject: RE: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.t= xt [External Email. Be cautious of content] Ron - Interesting proposal. A few mundane - but I think still important - comments. New IS-IS TLVs -------------------- There is no need to have two TLVs for each address-family - one for MTID #0= and one for all non-zero MTIDs. One TLV/AF will suffice. The reason we have separate TLVs today is because MT (RFC 5120) came along= after TLV 135/236 had been defined/deployed. Since you have a greenfield here you can simply have one TLV/AF and allow a= ll MTIDs (including 0). MTID is a 16 bit field with 4 reserved bits and 12 bits used for MTID value= . (I believe someone else pointed this out as well.) See RFC 5120. You should specify that the new TLVs inherit the sub-TLV space defined in h= ttps://urldefense.com/v3/__https://www.iana.org/assignments/isis-tlv-codepo= ints/isis-tlv-codepoints.xhtml*isis-tlv-codepoints-135-235-236-237__;Iw!!NE= t6yMaO-gk!Rh_KQ_Gqclv8ar4yhZ4nGijt5s9AbhGufBcPVYsk5iEHCP_lp_nRG_C8qZvvh30w$ The U-bit ------------- I appreciate that there is precedence for calling this the U-bit based on R= FC 5308 - but I would prefer that you call it the D-bit. Regardless of name, it MUST be consistent with existing usage - meaning it = is set when the prefix is leaked downwards. Currently your text says: "U (1 bit): Set indicates up. Clear indicates down." This needs to be reversed. Constraints --------------- I think you need to speak to various constraints including (but not limited= to): 1)Algorithm is limited to flex-algo values (128-255) I don't understand why Section 6 (main part - not the sub-sections) is ther= e. What relevance do non-flex-algos have to this draft?? I also think the new sub-TLV would be better named "Native Flex-Algo Algori= thm Sub-TLV". Unless you are proposing to use this sub-TLV in ways not related to flex-al= go - in which case I think you need to provide some explanation of the use = case for this. 2)How to handle advertisement of same algo both in the new Algorithm sub-TL= V and the existing SR Algorithm sub-TLV (prefer SR??) Note that legacy rout= ers may understand SR Algorithm Sub-TLV but not the new one. Les > -----Original Message----- > From: Lsr On Behalf Of Ron Bonica > Sent: Tuesday, September 29, 2020 6:38 AM > To: lsr@ietf.org > Subject: [Lsr] FW: New Version Notification for=20 > draft-bonica-lsr-ip-flexalgo- 00.txt > > > Please review and comment > > Ron > > > > Juniper Business Use Only > > > -----Original Message----- > > From: internet-drafts@ietf.org > > Sent: Tuesday, September 29, 2020 9:36 AM > > To: Parag Kaneriya ; Shraddha Hegde=20 > > ; Ron Bonica ; Rajesh M=20 > > ; William Britto A J > > Subject: New Version Notification for=20 > > draft-bonica-lsr-ip-flexalgo-00.txt > > > > [External Email. Be cautious of content] > > > > > > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF=20 > > repository. > > > > Name: draft-bonica-lsr-ip-flexalgo > > Revision: 00 > > Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > > Document date: 2020-09-29 > > Group: Individual Submission > > Pages: 14 > > URL: https://urldefense.com/v3/__https://www.ietf.org/id/dra= ft- > bonica- > > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > > Status: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > bonica-lsr- > > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > > Htmlized: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr > > aft- > > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > > Htmlized: > https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > > > > > > Abstract: > > An IGP Flexible Algorithm computes a constraint-based path and maps > > that path to an identifier. As currently defined, Flexalgo can only > > map the paths that it computes to Segment Routing (SR) identifiers. > > Therefore, Flexalgo cannot be deployed in the absence of SR. > > > > This document extends Flexalgo, so that it can map the paths that it > > computes to IP addresses. This allows Flexalgo to be deployed in an= y > > IP network, even in the absence of SR. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > _;!!NEt6yMaO-gk!Rh_KQ_Gqclv8ar4yhZ4nGijt5s9AbhGufBcPVYsk5iEHCP_lp_nRG_ > C8qYrcbkbN$ From nobody Thu Oct 1 08:38:01 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2863A0ABD for ; Thu, 1 Oct 2020 08:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=CPXDrvGj; dkim=pass (1024-bit key) header.d=juniper.net header.b=V+s/k8JJ 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 59Hh5EGuLJuf for ; Thu, 1 Oct 2020 08:37:55 -0700 (PDT) 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 6AFAD3A0A7E for ; Thu, 1 Oct 2020 08:37:55 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 091FNFLo000486; Thu, 1 Oct 2020 08:37:54 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=y+4iyU9B0W6Xa1lVMpRWydcylw69BKaLB7oRl/MXIR4=; b=CPXDrvGjijUml1/97u4OcdMZa/QG/N0qXlQMiWzXO5kJ0fz76/BqmYoWRUZV7KvuOycu E0NkXzQzENUMhXnMZBaWD4cw3KL9EFU6lypmFmgZFl+yz27Ri4vdACRIf3y0T3V7kzBv CkE/4ASJx/YZ2PL7iiBuU0BV85vgNgKlpUhlgTX4M98vc8E7lDvFx2LBLChvVXcaGbb8 p8/sLYR/hQRFEiQaVuKo22fdFQETHBi6kNWgKFGtTgwmn0p3TuhwwLHZ1lRrSnm8/5uD CgIIwnd7PLeeIgRWxICGS1wlRpHhaFuaS1LRXrYS2I8fy8mVpQ7i95PuShl78tuD+YVO +Q== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2169.outbound.protection.outlook.com [104.47.56.169]) by mx0b-00273201.pphosted.com with ESMTP id 33t0vrh8m0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Oct 2020 08:37:54 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B77iSkviaAuC1K61fNklS7DFkr4GIUj2lrYKPWOu1ITaDsmzXInCL10o9zDG8ru6TbLQ7MiEsnQvq467oU2uPjBa7nwUe0fjwq0gSi6sAw1dzCmBiHpWDmdkUPQcvJDGphhDRLXtxfJ0zllG6DuapXdJ+eNj2tYhEwvaBM3eFH5nPGb8mxaeC+dK0YLiF+slmJNou0xbzMxQgBDX5b12PQubr/qXoD/95MJw/9XkqjEH9kw0Z5XLlz46KAFbmGegrU8yH2CQEowL+fdPKSz/YR7mKmEQmAURoJrj3EEGB3S0XA/XnqLOKoJ3c1i4LwDLZC1yKvm+sivYhUg0rDyhqA== 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=y+4iyU9B0W6Xa1lVMpRWydcylw69BKaLB7oRl/MXIR4=; b=QObMEj3UUS1CA66mT0zQLg08VXgwdcXh4TUxIpnStOCbCxZTEEDXpyZqLOlN4r8XfxGooXxms/YQoNBa0QZG6ayLteiIifvMlltARbBEF0WnfDbjKII1e4drjg9F+w679cBZkmDyLe1NP6LhGIXIhaZZQFmVBKH5vlzSBERhMl0ESJigLg/0gVpBt5MBirPKzeUIHGl2VwZ3M5OuOERd0CyjjHqMLu8p87mkoWRE6XyUTRSumbX7V+6ity+qoigMK+sAR+8kDQ0KwgnpQuoZrKrAth2hkB682nE+Q/4sPSOhLwoe4ZqNzduBENxAypZwEJp28pMTWMmB+yMX1MMs7Q== 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=y+4iyU9B0W6Xa1lVMpRWydcylw69BKaLB7oRl/MXIR4=; b=V+s/k8JJVq2U0uHlEEkRkN9HxvEeGgb2OB0K2/HLaKcAP1JbANZyyBZjufiCf7rAKgEzSE5D14mZcMtYyqENgic9MXRqbD/AIpk838dlYaLTYMyMrrbRxPoSGy0XjAbmDSgCSgUwzXPqm8gzl7GIJewCnqPHavCx5hIeofSTUKw= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5322.namprd05.prod.outlook.com (2603:10b6:5:5a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.18; Thu, 1 Oct 2020 15:37:47 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782%3]) with mapi id 15.20.3433.038; Thu, 1 Oct 2020 15:37:47 +0000 From: Ron Bonica To: "tony.li@tony.li" CC: "lsr@ietf.org" Thread-Topic: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAAHxoCAAz50wA== Date: Thu, 1 Oct 2020 15:37:46 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-01T15:37:44Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=d4158edc-d43a-448d-bb73-c78736652a86; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: tony.li; dkim=none (message not signed) header.d=none;tony.li; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7179d407-61f0-4fb0-45e9-08d8661ff270 x-ms-traffictypediagnostic: DM6PR05MB5322: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZiTkGweR0R8cpcfWsW0WEA/JEnX3gAo0HxbeNTVyvDA78gAw8AUXh2cHXqyVxQ5xsnLkrT3f+bxg/FyZawGPj8PjgTDD00wFk7gED2NfMvAhzb42moaZJfYbMeggP32LP3yJtO8H+FVCL/ZxltxliYjIb5XvYx3qOyyJbGDlgqLItJQdAxNjyDPDoS0hxCNFWzaLaBDBAhqYUcQyu5pb0i8/WkcsP6iTlC/aHcBOX0MrVT/77McaIaORz2vqz93ktg9VTVDWJpTgX9kVxUR/Xw01l/BY6Rcjv3cnwBxkypNxPoG68zmbOFNrLaZLTuQ/F+rL5P8BuNOtpUycDHySihKZWYgfux2mov7iLDtsVBn+CRj+UGC12yWG0diWM2DwmnWkzR3gJsrWfq/V8use7g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(346002)(39860400002)(366004)(376002)(2906002)(478600001)(6506007)(55016002)(66476007)(64756008)(66446008)(53546011)(15650500001)(7696005)(186003)(966005)(83380400001)(66574015)(86362001)(66946007)(5660300002)(76116006)(83080400001)(71200400001)(52536014)(8936002)(33656002)(26005)(316002)(4326008)(6916009)(9686003)(66556008)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: yjDtk3h5jSpnZpndeqhr0q12w8QwItznwnJeyUAIeJYangwa+KSh2bpIK4LOb8/emoBbdSLdgtSY63yysEew8tGUeidgck2D5s7i5P9cWooT31Zvo2byiP6vDL8dgn+FRuCPcl0KLs5QbX298d9mJ5Rwuq2tKFSSSKOBBlMfdH2aTLRQbi22WGuCroL+ELg5/3bNklAglIwremGUdhfNZItxQhbsmv76UceNgULtFDMB/Ny7C0mk7OMwDZ3v82s8L1Q4T2DRss5H/CC0fcccsqQSGXAcsnkG6CxcKQgl1Q8UoVKOp+1dMA+YlJ/wl7feGWB4P5LrHZlR3JxhwJOKC+Y1/mkSe3nBK1fFu9p+SCLggIM5ql0vRFrrbDRsP3znr725wm8E4+3v5dWKThC+9idstXl1kyrhFopnJ0AZqSq5pA840q/mxjTGGXKCUxJ6T3T6h4wgWGwxTXjJMVpRq4fz8oq3prp/do1ll6pzrbL2Fp9cFUvOPlxm92qJYU+P9ohjXaIWnO6vwSHFQr/7AcjJMiO+cpxe7UZMgtkKrcxlY4MXLjyGB5SqRTi1xZOgZlEklbM0eopddrKfwUIKgKetNuGHdhhDL7Rg6BEKp3FZ2cqnHQBdZirozBf3ATLEoxEf/UknmV8OHXmmgNxmpQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7179d407-61f0-4fb0-45e9-08d8661ff270 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 15:37:46.9119 (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: jGjLIRaquUNTyj7kWRPim6UTYIG2xZzxhI+2K0zBYNXepHkJd4S2hRuBVBr4tO72xSZ0cnVdaKeI5lBI62G7Eg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5322 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-01_05:2020-10-01, 2020-10-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 bulkscore=0 clxscore=1015 spamscore=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 adultscore=0 phishscore=0 mlxscore=0 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010010132 Archived-At: Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 15:37:59 -0000 SGkgVG9ueSwNCg0KWW91IGFyZSBjb3JyZWN0IGluIHRoYXQgYSBwcmVmaXggY2FuIG9ubHkgYmUg YXNzb2NpYXRlZCB3aXRoIG9uZSBGbGV4YWxnby4NCg0KSSB3aWxsIGFkZCBzb21lIHRleHQgYWJv dXQgYXBwbGljYXRpb25zIGluIHRoZSBuZXh0IHZlcnNpb24uDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgUm9uDQoNCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUb255IExpIDx0b255MWF0aG9tZUBnbWFpbC5jb20+IE9u IEJlaGFsZiBPZiB0b255LmxpQHRvbnkubGkNClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyOSwg MjAyMCAxMDowNSBBTQ0KVG86IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+DQpDYzog bHNyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0xzcl0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1ib25pY2EtbHNyLWlwLWZsZXhhbGdvLTAwLnR4dA0KDQpbRXh0ZXJuYWwgRW1h aWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQoNCg0KUm9uLA0KDQpUaGlzIGlzIG5pY2UuIEl0 IG1ha2VzIGl0IGNsZWFyIHRoYXQgY29uc3RyYWludCBiYXNlZCBwYXRoIGNvbXB1dGF0aW9uIG5l ZWQgbm90IGhhdmUgTVBMUyBvdmVyaGVhZCBmb3IgdGhvc2UgdGhhdCBkb27igJl0IHdhbnQgaXQu DQoNCk9uZSB0aGluZyB0aGF0IHlvdSBkb27igJl0IHRhbGsgYWJvdXQgaXMgaG93IHRoaXMgZ2V0 cyB1c2VkLCB0aG8gdGhhdCBtYXkgYmUgYmxpbmRpbmdseSBvYnZpb3VzOiB5b3XigJlsbCBuZWVk IGFsbCBub2RlcyBwbGFjaW5nIHRoZWlyIHByZWZpeGVzIGluIHRoZSBSSUIvRklCLCB3aGVyZSBp dCB3aWxsIG5lZWQgdG8gYmUgc2VsZWN0ZWQgb3ZlciBvdGhlciBwYXRoIGNvbXB1dGF0aW9uIGZv ciB0aGUgc2FtZSBwcmVmaXhlcy4gIFRoaXMgc29tZXdoYXQgcHJlY2x1ZGVzIHRoZSBwb3NzaWJp bGl0eSBvZiBhIGdpdmVuIHByZWZpeCBiZWluZyB1c2VmdWwgaW4gbXVsdGlwbGUgZmxleC1hbGdv cy4NCg0KTW9yZSB0ZXh0IG9uIGFwcGxpY2F0aW9uIHdvdWxkIGJlIG1vc3Qgd2VsY29tZSwganVz dCB0byBlbnN1cmUgdGhhdCB3ZeKAmXJlIG9uIHRoZSBzYW1lIHBhZ2UuDQoNClRvbnkNCg0KDQo+ IE9uIFNlcCAyOSwgMjAyMCwgYXQgNjozNyBBTSwgUm9uIEJvbmljYSA8cmJvbmljYT00MGp1bmlw ZXIubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4NCj4NCj4gUGxlYXNlIHJldmlldyBhbmQg Y29tbWVudA0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0K Pg0KPg0KPg0KPiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+DQo+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+DQo+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMjAg OTozNiBBTQ0KPj4gVG86IFBhcmFnIEthbmVyaXlhIDxwa2FuZXJpYUBqdW5pcGVyLm5ldD47IFNo cmFkZGhhIEhlZ2RlIA0KPj4gPHNocmFkZGhhQGp1bmlwZXIubmV0PjsgUm9uIEJvbmljYSA8cmJv bmljYUBqdW5pcGVyLm5ldD47IFJhamVzaCBNIA0KPj4gPG1yYWplc2hAanVuaXBlci5uZXQ+OyBX aWxsaWFtIEJyaXR0byBBIEogPGJ3aWxsaWFtQGp1bmlwZXIubmV0Pg0KPj4gU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4+IGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxleGFs Z28tMDAudHh0DQo+Pg0KPj4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50 XQ0KPj4NCj4+DQo+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9uaWNhLWxzci1pcC1m bGV4YWxnby0wMC50eHQNCj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9u IEJvbmljYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIA0KPj4gcmVwb3NpdG9yeS4NCj4+DQo+PiBO YW1lOiAgICAgICAgICAgZHJhZnQtYm9uaWNhLWxzci1pcC1mbGV4YWxnbw0KPj4gUmV2aXNpb246 ICAgICAgIDAwDQo+PiBUaXRsZTogICAgICAgICAgSUdQIEZsZXhpYmxlIEFsZ29yaXRobXMgKEZs ZXhhbGdvKSBJbiBJUCBOZXR3b3Jrcw0KPj4gRG9jdW1lbnQgZGF0ZTogIDIwMjAtMDktMjkNCj4+ IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+IFBhZ2VzOiAgICAgICAg ICAxNA0KPj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1ib25pY2EtDQo+PiBsc3ItaXAtZmxleGFsZ28tMDAu dHh0X187ISFORXQ2eU1hTy1nayFYN1BWRFAtDQo+PiBGblVBMG9DY1pNdzNRZGU2aW4wQzcyaHVf OWhPWjUza1BzcElhclI4Zk5EeVU5VmNrODBaYmpvaWokDQo+PiBTdGF0dXM6DQo+PiBodHRwczov L3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtYm8NCj4+IG5pY2EtbHNyLQ0KPj4gaXAtZmxleGFsZ28vX187ISFORXQ2eU1hTy1nayFYN1BW RFAtDQo+PiBGblVBMG9DY1pNdzNRZGU2aW4wQzcyaHVfOWhPWjUza1BzcElhclI4Zk5EeVU5VmNr OHg3ZTVacUkkDQo+PiBIdG1saXplZDoNCj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYQ0KPj4gZnQtDQo+PiBib25p Y2EtbHNyLWlwLWZsZXhhbGdvX187ISFORXQ2eU1hTy1nayFYN1BWRFAtDQo+PiBGblVBMG9DY1pN dzNRZGU2aW4wQzcyaHVfOWhPWjUza1BzcElhclI4Zk5EeVU5VmNrODJ3XzZDeVUkDQo+PiBIdG1s aXplZDogICAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC0NCj4+IGJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDBfXzshIU5FdDZ5 TWFPLWdrIVg3UFZEUC0NCj4+IEZuVUEwb0NjWk13M1FkZTZpbjBDNzJodV85aE9aNTNrUHNwSWFy UjhmTkR5VTlWY2s4MV9RckpfcCQNCj4+DQo+Pg0KPj4gQWJzdHJhY3Q6DQo+PiAgIEFuIElHUCBG bGV4aWJsZSBBbGdvcml0aG0gY29tcHV0ZXMgYSBjb25zdHJhaW50LWJhc2VkIHBhdGggYW5kIG1h cHMNCj4+ICAgdGhhdCBwYXRoIHRvIGFuIGlkZW50aWZpZXIuICBBcyBjdXJyZW50bHkgZGVmaW5l ZCwgRmxleGFsZ28gY2FuIG9ubHkNCj4+ICAgbWFwIHRoZSBwYXRocyB0aGF0IGl0IGNvbXB1dGVz IHRvIFNlZ21lbnQgUm91dGluZyAoU1IpIGlkZW50aWZpZXJzLg0KPj4gICBUaGVyZWZvcmUsIEZs ZXhhbGdvIGNhbm5vdCBiZSBkZXBsb3llZCBpbiB0aGUgYWJzZW5jZSBvZiBTUi4NCj4+DQo+PiAg IFRoaXMgZG9jdW1lbnQgZXh0ZW5kcyBGbGV4YWxnbywgc28gdGhhdCBpdCBjYW4gbWFwIHRoZSBw YXRocyB0aGF0IGl0DQo+PiAgIGNvbXB1dGVzIHRvIElQIGFkZHJlc3Nlcy4gIFRoaXMgYWxsb3dz IEZsZXhhbGdvIHRvIGJlIGRlcGxveWVkIGluIGFueQ0KPj4gICBJUCBuZXR3b3JrLCBldmVuIGlu IHRoZSBhYnNlbmNlIG9mIFNSLg0KPj4NCj4+DQo+Pg0KPj4NCj4+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPj4gc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMc3IgbWFp bGluZyBsaXN0DQo+IExzckBpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3JfDQo+IF87ISFORXQ2eU1h Ty1nayFSbk0tei1PM2xlSF9JSUgwNkx4UnpaS2JSTVF1dVFjUnM0ZzRSQ2lUYkUwUGxlWTcwU20y aDMNCj4gcEZvNDJ3N2pBOCQNCg== From nobody Thu Oct 1 09:51:35 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636FC3A1116 for ; Thu, 1 Oct 2020 09:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, RCVD_IN_MSPIKE_H2=-0.001, 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=MfNmtHeF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zg2/3a3O 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 1nQk6rFUoCSF for ; Thu, 1 Oct 2020 09:51:30 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DE03A0CC8 for ; Thu, 1 Oct 2020 09:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6750; q=dns/txt; s=iport; t=1601571090; x=1602780690; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wesImw/qnG0nzD6KffqVMsT0+hai/Paf/BU2gYSlBMU=; b=MfNmtHeFGMSjVUL34yeIQtF7ZzwGQ9Xi8P3tOnJIghrsCoEFqeB36F95 v5ycS8jSXaZ0En7GbgteJgJTeg/NCS8YwjaZWmhmAdf/oskowBRNEQXoR uy1+ryjFs/+1dgKKaol6L/NelSL6lxrTmlBeJ48LiZaWSWZ/HoBmttm6n Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A4BXvdRS2MujI0dLROQL/AljjQNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ5/dNkeGQsq38VyoH+5nS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4TsbAB?= =?us-ascii?q?65NAdpKKLyAIGBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7CABtCHZf/4gNJK1fHgEBCxIMQIF?= =?us-ascii?q?EC4FSUQdwWS8sCoQzg0YDjgGYd4FCgREDVQsBAQENAQEYDQgCBAEBhEoCF4I?= =?us-ascii?q?eAiU3Bg4CAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAwEBEBERDAEBLAkDCwQ?= =?us-ascii?q?CAQgRBAEBAQICJgICAiULFQgIAgQBEiKDBAGCSwMuAQ6gDQKBOYhhdoEygwE?= =?us-ascii?q?BAQWBR0GDDBiCEAmBDiqCcoNphlMbggCBOByCTT6CXAEBAgEBgSYBEgEhF4M?= =?us-ascii?q?AM4Itkz2HJ5xsCoJniH2RYQMWCYMOgSiIWZFdgi+TEopulSMCBAIEBQIOAQE?= =?us-ascii?q?FgWokZ3BwFRohKgGCPglHFwINjh+DcYUUhUJ0AjUCBgEJAQEDCXyMRwGBEAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.77,323,1596499200"; d="scan'208";a="586711706" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Oct 2020 16:51:29 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 091GpT8C015257 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2020 16:51:29 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 11:51:28 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 12:51:27 -0400 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 1 Oct 2020 11:51:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UO0CuCwac/lZo4vrfoi+AzVi+OY5NCvP3ieHeBYzCDzBcN2bZyG+/77ltqE8hfoCkbtaDaGUHe6lZGpmbDfnY9q+E72zlqdcWaO8PbVTTpli6H08pkAHWgK8yvafTNzULOZFPd7cBBVvGaXeCSCIqaml9mJWZushWrLJOYHcsqR6wrzIjb/MsG9Z0GxwFpkRwd+Uu+bP2WoSSQhDLMIiTX3/jq1rhdEQL+0uUTMha6x8nGqjkd7wy02uiJs5+yhcZnrrWwRSIPt+/cYcbOmuuCgch0/rDYVbrKODa3SWoHH0RW1WkE4EIGBr4Qrp/vcMy6gPzeY/zHjgT5kEsYhUpQ== 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=wesImw/qnG0nzD6KffqVMsT0+hai/Paf/BU2gYSlBMU=; b=DVD+ZCsS5MOzyEW3Stw0cmyi69gTu+o2Qw9J/vz1d4G1P0CQwRbThlKwdz9zvKZyFWXnbkS6nyeMe6zJb8vD8VeNXaCqN1WEzf9SjW0khB5WR7c1DHHt5Cy08YgiExYLlpVnWI+lSryNd3K6BZPCLloDkjYH5aDAzjrdq6iIlkd5z9mK9zM6pGQcgWfpZR4qTp/H4CZVCh5WjvFof1432lqZVATzRi+qwvORUL92oFu8VNfGiZ4ua1KXW+sXoQCTraRzGiwSnzwYpH7l9d0WuG5EqEZ/5zRJsVuERDDDwb858WQ1KeWQ1QVOoQ2RNGzgB3kXOsk1wGGWOcab0xfsnQ== 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=wesImw/qnG0nzD6KffqVMsT0+hai/Paf/BU2gYSlBMU=; b=zg2/3a3OhbbvwZ+QWnzMdB2fAvZfbRTmRYQ0Etl7U35i8sThJzOlOUekhCWUmOOKe7uo7FIamayASKhhwrKegJvY4DGxsD9mTpGwNQxZC1fjJVf/McFkRwHPZPU/qXU+pxQ8B1L6+bEN7C3vchuv+J/+3EujlkkWLdfW6fN7tBo= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB2854.namprd11.prod.outlook.com (2603:10b6:a02:c9::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.36; Thu, 1 Oct 2020 16:51:26 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3412.029; Thu, 1 Oct 2020 16:51:26 +0000 From: "Acee Lindem (acee)" To: Peter Psenak , Ron Bonica , "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgALInQCAAE9MgA== Date: Thu, 1 Oct 2020 16:51:25 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b32f1b2-f1d6-4c0b-0f3b-08d8662a3cc8 x-ms-traffictypediagnostic: BYAPR11MB2854: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SYV+TbzBmD8twiCEFiClVosyXkz29zxWVR1ZFdfXgp3ySAlOi8Iyxoyg7MQunXCMWL+DwSJ36cIANTzxl8sh5zmVn+VNugLcSwG9WJb8YbsuWydK0Sigy26uMoTbD0T3zBsB2pdcmVn6gE7CFi2F1J+VA9eZxIG9RyQRk917kmU53DBAvZH/pZXH0SymxO9ui7C/aV+XUgznC6Bp/qHAj5okGQ9uR9pbB4jZf5pcvaKuJ6Z8oNSzPmlZK264E+3xOMus5DRqFcZqnI4Eq2YmUAS7YcX0fZ2VWGLDkmGbOlSkRjoDm/qk2Im3g3tsn0iYdxE3gtzOeBuoVAxm3gFnpnxGQJbAVuBGkuouuzCRPs2T+K6YquBsSav1uVVjKKPKMi0TbVZUsOJuq14fl9vHrQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(346002)(376002)(366004)(136003)(71200400001)(5660300002)(66446008)(15650500001)(2906002)(86362001)(66946007)(6512007)(8936002)(83380400001)(26005)(76116006)(64756008)(6486002)(186003)(83080400001)(53546011)(8676002)(66556008)(6506007)(66476007)(478600001)(33656002)(316002)(110136005)(966005)(36756003)(2616005)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: y6KB9pyA7hWtUgIqcFjYviR8UHQVVipnSNyv+rhMNPeSHlUHphSrj3aafXujfMwcnYZnmSOVmfT2kaOHJy3hAIMfBNlL+ILDQ78DRRI/pEXcF8V3aTjnf0mvtr9zgkR1cem2K7hfCnONiOnZe8SY+xh4GRdcsfEAptO0Cu0w+NZtRls0YRXq9i/lQ+M0dxjOlRT7sDp3anOxMsKyxDme10yD6I/6U6usAFaxNYMfY45D9FGu512v/KK4WqOE4kynoJ/jB7gYX2iJOQ6hn/ENmkdBWzwjYa0v/O75Avg5cwbwVi1jrXVW4jvKDbZenfUzskyQN1rjNWd6Orfj1YhRsjODEQRlAQow8LZ40CytrAP5s7mj7xgTpoMBKpITYYIw5unHBVVzGGxVm+I3bicTwplq2R+N5wv8UzHpSDzMPMLwBj5c319sJAfiMWZ0Eu/i/zez9mEZc0KTft2evZ/xRYO0XiEV9Fruztc9W5DPBMIpkiwlobMetwWthd8r3njoTPNz7L0CGJZgVAFqWu1hT4RPH1eVk4FfmOaix3HaJmyDu9b1+q0cLk94LQF9N4ECxjLb2znICQfY0DTgN7kbHOwhYYp/Agqnyusjw2WJj5g/gTVDCW56E6zAhAegxtQxZ3S7M3hfAYBg+s8nrWHTGA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7A4F9B2EE1CFE048B8A0AE8C5DB2A0E7@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b32f1b2-f1d6-4c0b-0f3b-08d8662a3cc8 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 16:51:26.5919 (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: RLi+lTB6YBLIv53irjXR9wHf718UwD9rsVkUagz7A80JL+Ft4U/zlyfsMcdk0xtx X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2854 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 16:51:32 -0000 U3BlYWtpbmcgYXMgV0cgbWVtYmVyLi4uIA0KDQpJIGFncmVlIHRoYXQgYW4gaW5kZXBlbmRlbnQg Y2FsY3VsYXRpb24gaXMgcmVxdWlyZWQgZm9yIElQIEZsZXggQWxnb3JpdGhtIGFuZCBTUiBGbGV4 IEFsZ29yaXRobSBhbmQgdGhpcyBzaG91bGQgYmUgZG9jdW1lbnRlZC4gSG93ZXZlciwgaXQgZG9l c24ndCBzZWVtIHRvIG1lIGEgbm9ybWFsIHVzZSBjYXNlIHdvdWxkIGJlIHRvIGRlcGxveSB0aGVt IGluIHRoZSBzYW1lIElHUCBhcmVhLiANCg0KVGhhbmtzLA0KQWNlZQ0KDQrvu79PbiAxMC8xLzIw LCA0OjA3IEFNLCAiTHNyIG9uIGJlaGFsZiBvZiBQZXRlciBQc2VuYWsiIDxsc3ItYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YgcHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4g d3JvdGU6DQoNCiAgICBIaSBSb24sDQoNCiAgICBJIGNhbiBvbmx5IGd1ZXNzIHRoZSB1c2UtY2Fz ZSwgYnV0IGl0IG1heSBiZSB3b3J0aCBvZiBkb2N1bWVudGluZyBpdCBpbiANCiAgICB0aGUgZHJh ZnQuDQoNCiAgICBZb3VyIHByb3Bvc2FsIGlzIGJhc2ljYWxseSBtaW1pY2tpbmcgU1J2NiBMb2Nh dG9yIGJlaGF2aW9yIGZvciByZWd1bGFyIA0KICAgIElQdjYgYW5kIElQdjQgcHJlZml4ZXMuIE9u ZSBjYW4gZXZlbiBhcmd1ZSB0aGF0IGZvciBJUHY2IHlvdSBjYW4gdXNlIGEgDQogICAgTG9jYXRv ciBhZHZlcnRpc2VtZW50IHdpdGggbm8gU0lEcywgYnV0IEkgYWdyZWUgdGhhdCB3b3VsZCBiZSBh IGhhY2sgYW5kIA0KICAgIHNlcGFyYXRlIGVuY29kaW5nIGlzIGNsZWFuZXIuDQoNCiAgICBPbmUg dGhpbmcgdGhhdCBuZWVkcyBmdXJ0aGVyIHdvcmsgaXMgdGhlIGFsZ28gcGFydGljaXBhdGlvbiBw YXJ0LiBHaXZlbiANCiAgICB0aGF0IHdlIGhhdmUgYSBzZXBhcmF0ZSBwYXJ0aWNpcGF0aW9uIGZv ciBTUiBhbmQgSVAgZmxleC1hbGdvLCBvbmUgd291bGQgDQogICAgaGF2ZSB0byBydW4gYSBzZXBh cmF0ZSBjYWxjdWxhdGlvbiBlYWNoIGluIHRoZSBjb250ZXh0IG9mIHRoZSBzYW1lIA0KICAgIGZs ZXgtYWxnby4gRXZlbiB0aG91Z2ggaW4gbW9zdCBjYXNlcyBvbmUgd291bGQgZXhwZWN0IHRoZSBz ZXQgb2YgDQogICAgcGFydGljaXBhdGluZyByb3V0ZXJzIHRvIGJlIHRoZSBzYW1lIGZvciBib3Ro LiBJIGRvbid0IHNlZSBhbiBlYXN5IHdheSANCiAgICBvdXQsIGFjdHVhbGx5IHRoaXMgaXMgd2hh dCB0aGUgYmFzZSBGQSBkcmFmdCByZXF1aXJlcyBpdCBpbiBzZWN0aW9uIA0KICAgIDEwLjIuIFdo YXQgSSB3b3VsZCBzdWdnZXN0IGlzIHRvIGNsZWFybHkgZG9jdW1lbnQgdGhlIGZhY3QgdGhhdCB0 aGUgDQogICAgY29tcHV0YXRpb24gZm9yIHRoZSBJUCBmbGV4LWFsZ28gaXMgaW5kZXBlbmRlbnQg b2YgdGhlIG90aGVyIGZsZXgtYWxnbyANCiAgICBjb21wdXRhdGlvbnMgKGUuZy4gU1IpIGFuZCB0 aGF0IElQIGZsZXgtYWxnbyBpcyBhbiBhcHBsaWNhdGlvbiBvZiBpdHMgDQogICAgb3duIGZyb20g dGhlIGZsZXgtYWxnbyBwZXJzcGVjdGl2ZS4NCg0KICAgIExlcyBoYXMgY29tbWVudGVkIG9uIElT SVMgZW5jb2RpbmcsIEkgaGF2ZSBhIHF1ZXN0aW9uIG9uIE9TUEYgb25lIC0gaGF2ZSANCiAgICB5 b3UgY29uc2lkZXJlZCB1c2luZyB0aGUgT1NQRnYyIEV4dGVuZGVkIFByZWZpeCBPcGFxdWUgTFNB IHdpdGggT1NQRnYyIA0KICAgIEV4dGVuZGVkIFByZWZpeCBUTFYgKHJmYzc2ODQpIGFuZCBkZWZp bmUgYSBuZXcgIklQIEZlbGV4LWFsZ28iIG1ldHJpYyANCiAgICBzdWItVExWPw0KDQogICAgdGhh bmtzLA0KICAgIFBldGVyDQoNCg0KDQoNCiAgICBPbiAyOS8wOS8yMDIwIDE1OjM3LCBSb24gQm9u aWNhIHdyb3RlOg0KICAgID4gDQogICAgPiBQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50DQogICAg PiANCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCiAg ICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCiAg ICA+IA0KICAgID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPj4gRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQogICAgPj4g U2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDI5LCAyMDIwIDk6MzYgQU0NCiAgICA+PiBUbzogUGFy YWcgS2FuZXJpeWEgPHBrYW5lcmlhQGp1bmlwZXIubmV0PjsgU2hyYWRkaGEgSGVnZGUNCiAgICA+ PiA8c2hyYWRkaGFAanVuaXBlci5uZXQ+OyBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0 PjsgUmFqZXNoIE0NCiAgICA+PiA8bXJhamVzaEBqdW5pcGVyLm5ldD47IFdpbGxpYW0gQnJpdHRv IEEgSiA8YndpbGxpYW1AanVuaXBlci5uZXQ+DQogICAgPj4gU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1ib25pY2EtbHNyLWlwLWZsZXhhbGdvLTAwLnR4dA0KICAg ID4+DQogICAgPj4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KICAg ID4+DQogICAgPj4NCiAgICA+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9uaWNhLWxz ci1pcC1mbGV4YWxnby0wMC50eHQNCiAgICA+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFJvbiBCb25pY2EgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KICAgID4+IHJlcG9zaXRv cnkuDQogICAgPj4NCiAgICA+PiBOYW1lOiAgICAgICAgICAgZHJhZnQtYm9uaWNhLWxzci1pcC1m bGV4YWxnbw0KICAgID4+IFJldmlzaW9uOiAgICAgICAwMA0KICAgID4+IFRpdGxlOiAgICAgICAg ICBJR1AgRmxleGlibGUgQWxnb3JpdGhtcyAoRmxleGFsZ28pIEluIElQIE5ldHdvcmtzDQogICAg Pj4gRG9jdW1lbnQgZGF0ZTogIDIwMjAtMDktMjkNCiAgICA+PiBHcm91cDogICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQogICAgPj4gUGFnZXM6ICAgICAgICAgIDE0DQogICAgPj4gVVJM OiAgICAgICAgICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1ib25pY2EtDQogICAgPj4gbHNyLWlwLWZsZXhhbGdvLTAwLnR4dF9fOyEh TkV0NnlNYU8tZ2shWDdQVkRQLQ0KICAgID4+IEZuVUEwb0NjWk13M1FkZTZpbjBDNzJodV85aE9a NTNrUHNwSWFyUjhmTkR5VTlWY2s4MFpiam9paiQNCiAgICA+PiBTdGF0dXM6DQogICAgPj4gaHR0 cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWJvbmljYS1sc3ItDQogICAgPj4gaXAtZmxleGFsZ28vX187ISFORXQ2eU1hTy1nayFY N1BWRFAtDQogICAgPj4gRm5VQTBvQ2NaTXczUWRlNmluMEM3Mmh1XzloT1o1M2tQc3BJYXJSOGZO RHlVOVZjazh4N2U1WnFJJA0KICAgID4+IEh0bWxpemVkOg0KICAgID4+IGh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LQ0KICAgID4+IGJvbmljYS1sc3ItaXAtZmxleGFsZ29fXzshIU5FdDZ5TWFPLWdrIVg3UFZEUC0N CiAgICA+PiBGblVBMG9DY1pNdzNRZGU2aW4wQzcyaHVfOWhPWjUza1BzcElhclI4Zk5EeVU5VmNr ODJ3XzZDeVUkDQogICAgPj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtDQogICAgPj4gYm9uaWNhLWxz ci1pcC1mbGV4YWxnby0wMF9fOyEhTkV0NnlNYU8tZ2shWDdQVkRQLQ0KICAgID4+IEZuVUEwb0Nj Wk13M1FkZTZpbjBDNzJodV85aE9aNTNrUHNwSWFyUjhmTkR5VTlWY2s4MV9RckpfcCQNCiAgICA+ Pg0KICAgID4+DQogICAgPj4gQWJzdHJhY3Q6DQogICAgPj4gICAgIEFuIElHUCBGbGV4aWJsZSBB bGdvcml0aG0gY29tcHV0ZXMgYSBjb25zdHJhaW50LWJhc2VkIHBhdGggYW5kIG1hcHMNCiAgICA+ PiAgICAgdGhhdCBwYXRoIHRvIGFuIGlkZW50aWZpZXIuICBBcyBjdXJyZW50bHkgZGVmaW5lZCwg RmxleGFsZ28gY2FuIG9ubHkNCiAgICA+PiAgICAgbWFwIHRoZSBwYXRocyB0aGF0IGl0IGNvbXB1 dGVzIHRvIFNlZ21lbnQgUm91dGluZyAoU1IpIGlkZW50aWZpZXJzLg0KICAgID4+ICAgICBUaGVy ZWZvcmUsIEZsZXhhbGdvIGNhbm5vdCBiZSBkZXBsb3llZCBpbiB0aGUgYWJzZW5jZSBvZiBTUi4N CiAgICA+Pg0KICAgID4+ICAgICBUaGlzIGRvY3VtZW50IGV4dGVuZHMgRmxleGFsZ28sIHNvIHRo YXQgaXQgY2FuIG1hcCB0aGUgcGF0aHMgdGhhdCBpdA0KICAgID4+ICAgICBjb21wdXRlcyB0byBJ UCBhZGRyZXNzZXMuICBUaGlzIGFsbG93cyBGbGV4YWxnbyB0byBiZSBkZXBsb3llZCBpbiBhbnkN CiAgICA+PiAgICAgSVAgbmV0d29yaywgZXZlbiBpbiB0aGUgYWJzZW5jZSBvZiBTUi4NCiAgICA+ Pg0KICAgID4+DQogICAgPj4NCiAgICA+Pg0KICAgID4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAg ICA+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KICAgID4+DQogICAgPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAg ICA+Pg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICA+IExzciBtYWlsaW5nIGxpc3QNCiAgICA+IExzckBpZXRmLm9yZw0KICAgID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3INCiAgICA+IA0KICAgID4gDQoN CiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAg IExzciBtYWlsaW5nIGxpc3QNCiAgICBMc3JAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0KDQo= From nobody Thu Oct 1 11:45:09 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDB83A0E41 for ; Thu, 1 Oct 2020 11:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=eiDZtnI+; dkim=pass (1024-bit key) header.d=juniper.net header.b=iCmSIj36 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 P3n9xpwO3xFT for ; Thu, 1 Oct 2020 11:45:05 -0700 (PDT) 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 5AAA43A0E3F for ; Thu, 1 Oct 2020 11:45:05 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 091IhXaE025286; Thu, 1 Oct 2020 11:45:04 -0700 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=YpBkOQOYU2lxgsKMMKg8mu75E0R9qV1Hbf4rQ/Ng9jg=; b=eiDZtnI+qCSs9Rx9+x4g0EJm4mXdnB32+zG4dGL1g03iYkgEEv+rA8PzXYUI1oB6Sfss T2/lmg90KpMNNDXoyoIqfMxxEp2hkpUYY5V5fEYRvfqG3JUAwyBr3qQ+vB3Csq7MLpwm VGI+fXQTcIo7gDIszzXj8igChTo+Z0DtT7k/ya6HSLRMYh8bDBeWBK6h/N1TD+dQwO2f u736fD9+K9AnWm6KouqqrWNcbpvFnTQ4DbK7sxF2u1u1tLdKOcYSy8JcOhkAv33FNxVp /VioVLKX9ey8bpFpLbPCbK0t74YNTsk8NIVVkUnbjoeleKjfIo09mBNFO6vC+pv4Zhlf 9Q== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by mx0a-00273201.pphosted.com with ESMTP id 33vx64j7wu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Oct 2020 11:45:04 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KOCch+dPeZ/w1FIuHqPAaz8f3cUGn1qlPPHD8tU/UKFvmWNrMmqEmpUon+3dzAnzOVQ3cD2Fpk1DQZl6DH8MA4rSPaL7E4OajgsO7OGbqZxts2/vf3ChvYwgN8ZP+u89Kto7YD+uWGdbG0Ts2/wA6MwjP0YtZpk3PWDZAJzk/tsPVMQdOPPZaD+UXi/eDBfS0VpoSWPeB3ZWLaWDlaXa/bY/0XvWRA7gdR8c5HzS+9lpceinlQfAJ1wT04E7qDOoKF4SIkNPG7JgC8Ou2xQ/u0AFqzQasEVlOXdZ+UhsA/olAUUqdLWU2vmZHbEN5S9dG2SdUyO/CYsuZr7/kUZTEg== 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=YpBkOQOYU2lxgsKMMKg8mu75E0R9qV1Hbf4rQ/Ng9jg=; b=LQ4tzNKQ6PksxGqGoHTO4tqBnWQfCZZSHj4PavB0w0ukZS+R6OTxr19x28iL7nUpBJFQEiPHyVVSOjBMFPtUpwAejJqL7OAOKelRFIVk9TGn9SScfoZnHE9fhxJ/0+2q9IQCwJnmp9SKmmAHgWlH6zSvZCkrF6wmrZfO5b3zCUXgCOmYK+2zDK3WCW1B9dASo7d9sR0Kbayi3vkLYMjOoFl8rtAHGXH0c5twQWEqnQ4ed/aqkxV/cYR1gya0yKmGwRycw59+uZkTuZuAznR9Pwcbjn/vGZB8sIvjsKGdxbpwg56WuX2/LAe0ry3PROvjqpxuCsqo1G4zQTvZzNOT8A== 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=YpBkOQOYU2lxgsKMMKg8mu75E0R9qV1Hbf4rQ/Ng9jg=; b=iCmSIj36RW31DoU2X9vXwDrFnGz3FeLe0JwGVFctJcMdo+aIJ0Nwp56mZwnKsCt8THr9w5k3vSjejPcF+VSIFb2aFoYiulay60/HatxAY/GsqdjQY8bHHbB7g25kyX9DBa8s3/DKpGdsKiotz4p/I3MGQ8WYQio2Hiyzo2HvO1E= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5084.namprd05.prod.outlook.com (2603:10b6:5:79::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.13; Thu, 1 Oct 2020 18:45:01 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782%3]) with mapi id 15.20.3433.038; Thu, 1 Oct 2020 18:45:00 +0000 From: Ron Bonica To: Jeff Tantsura CC: "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAGYiICAAB9mMIAA726AgADTSnA= Date: Thu, 1 Oct 2020 18:45:00 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> In-Reply-To: <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-01T18:44:58Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=b880b4df-1d4b-4f35-a070-f865ff0db514; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5b992b30-6942-4e8d-85c3-08d8663a1a63 x-ms-traffictypediagnostic: DM6PR05MB5084: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9G952aTv5nVBTLRthuWcwcMnIS/+0ydDzWcTkz+/3Gf+v+oyfrEVcwuZnpmpzp5sxr5waD7RXoGnGe1YKMNMdl4tiFsWTgM161U2+/l967SBVph6glo8eweNAX2WXOH+89kzJ4+tUp41jwgBxJjLxBeVuea8UfzznjaPQRlc2583d67vi/59Vv5JeemQ/QqmippCV5prRJWisKDWgHA8EZqoxE7NYQm6L6f7PO41rMPh5nWlnHpBPK2tjxMYT2fyxG3wTzAjjGTRhOOapRbGMOEp6fX7ue5wWCyhYCKVZgmtBe4ppBuwBDWPDvP9EnAB0gmptHTfjBJg+8Qdo/Ph86SiykAr7y6PckZBeBhFXI6P5/gWH8hSRyRsXK6wJriwzK6rsrk2JnYZlamLKTI0GQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(39860400002)(136003)(366004)(376002)(966005)(166002)(4326008)(83080400001)(15650500001)(86362001)(53546011)(64756008)(66556008)(6506007)(6916009)(7696005)(8936002)(9686003)(8676002)(26005)(2906002)(52536014)(316002)(66446008)(478600001)(66476007)(33656002)(76116006)(186003)(66946007)(83380400001)(55016002)(66574015)(71200400001)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: BmoLSYa+rdsa2tCPOcJhc+wpMHynvqnH0L1FASSnn0N/SvSEruwNcyyYCoO/wsSf+xELYz/Cc+12VlwHpsH7XmV8wk7sRM+lSVRevVscxxmw5GouTvZLgn6cz0ammQPIqDyWIxdoxcuMvVAvFuJ1oqt5grpLxyqYYsA4URfXhCFZW0a8xi7+BMjo3pG1IAPJg5U9oqrXQ2LC6e50OUmGzT1IYdi8D0KyoEaxAZfI8pImBdTqdT3LP02JUOqI+aXypT91KxE1GKJJT/lClXHrxjbSTnbApNufeDTI8F2AMxvgG6owPgmCknkINjDlU9N5ybFpVoF36P6lyyJeZ3FQwYjhfTDP1Z3bv4yIKk7NMJnBF47nXXtBVNhh7xL2XAU9HjDbNiY2mSJjocdVfRyxFJP/gVy+wvGNeIU5sHPKg0tzMbAmPI4IAWV/lVhz6hm+iEbKSZfyi79gGCDgdcyHblfYVwRzM8TSnzp0ybPJVcKLPXhsX6gts7Io82Kk1Elxnn3h2bM6aKy58wqb38zJ84DYdhJ1zLNy/LuN/Z6Iql5NSo+E7Q6h0/ZWtZFubbLJ6+Tr7k4nWCGBLzwZVHhf6IeOQZbPoPWJmijyAuXSqNZeObYlRPgB8WKMnmEu5yhvdyX3P11qwmWm2/WXeAdKtw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB63480E863599BBC810BF334AAE300DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5b992b30-6942-4e8d-85c3-08d8663a1a63 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 18:45:00.8851 (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: pOAmMnf9RWAucDjzHyXijCQ2SKOStX/cfWH2ptnJxbFwSSXHX0LA92FYPvA3qOTloyC0o2WHhnKR8Qp2Fc8W2A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5084 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-01_07:2020-10-01, 2020-10-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 clxscore=1015 spamscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 suspectscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010010152 Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 18:45:07 -0000 --_000_DM6PR05MB63480E863599BBC810BF334AAE300DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good point!! Juniper Business Use Only From: Jeff Tantsura Sent: Thursday, October 1, 2020 2:08 AM To: Ron Bonica Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-fle= xalgo-00.txt [External Email. Be cautious of content] Hi Ron, the readers would benefit if the draft would state that in order for the te= chnology to work properly, there must be a contiguous set of connected rout= ers that support it between the S/D, since lookup (route installed in conte= xt of the algo it is associated with) is done per hop. Cheers, Jeff On Sep 30, 2020, 9:03 AM -0700, Ron Bonica >, wrote: Hi Muthu, Thanks for the review. An interface can be associated with, at most, one Flexible Algorithm. Likew= ise, an IP address can be associated with, at most, one Flexible Algorithm. I tried to express this in the text below, but probably didn't do a very go= od job. If you can think of a better way to say it, I would appreciate sugg= estions. Ron Text from draft =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Network operators configure multiple loopback interfaces on an egress node. They can associate each loopback interface with: o Zero or more IP addresses. o Zero or one Flexible Algorithms. If an IP address and a Flexible Algorithm are associated with the same interface, they are also associated with one another. An IP address MAY be associated with, at most, one interface. Juniper Business Use Only From: Muthu Arul Mozhi Perumal > Sent: Wednesday, September 30, 2020 9:59 AM To: Ron Bonica > Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-fle= xalgo-00.txt [External Email. Be cautious of content] A quick question: If an IP address and a Flexible Algorithm are associated with the same interface, they are also associated with one another. An IP address MAY be associated with, at most, one interface. If multiple IP addresses and multiple flexible algorithms are associated wi= th a loopback interface, is each IP address associated with all flexible al= gorithms? What matters is the association b/w an IP address and a flexalgo,= so the relationship should be defined in a direct way rather than each bei= ng associated with an interface, right? Regards, Muthu On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica > wrote: Please review and comment Ron Juniper Business Use Only > -----Original Message----- > From: internet-drafts@ietf.org > > Sent: Tuesday, September 29, 2020 9:36 AM > To: Parag Kaneriya >; S= hraddha Hegde > >; Ron Bonica >; Rajesh M > >; William Britto A J > > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt > > [External Email. Be cautious of content] > > > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-lsr-ip-flexalgo > Revision: 00 > Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > Document date: 2020-09-29 > Group: Individual Submission > Pages: 14 > URL: https://urldefense.com/v3/__https://www.ietf.org/id/draft= -bonica- > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > Status: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica= -lsr- > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > Htmlized: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-<= https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-> > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > Htmlized: https://urldefense.com/v3/__https://tools.ietf.org/html/d= raft- > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > > > Abstract: > An IGP Flexible Algorithm computes a constraint-based path and maps > that path to an identifier. As currently defined, Flexalgo can only > map the paths that it computes to Segment Routing (SR) identifiers. > Therefore, Flexalgo cannot be deployed in the absence of SR. > > This document extends Flexalgo, so that it can map the paths that it > computes to IP addresses. This allows Flexalgo to be deployed in any > IP network, even in the absence of SR. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr --_000_DM6PR05MB63480E863599BBC810BF334AAE300DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good point!!

 

 

 

Juniper Business Use Only

From: Jeff Tantsura <jefftant.ietf@gmail.c= om>
Sent: Thursday, October 1, 2020 2:08 AM
To: Ron Bonica <rbonica@juniper.net>
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr= -ip-flexalgo-00.txt

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Hi Ron,

the readers would benefit if the draft would state that in order for the te= chnology to work properly, there must be a contiguous set of connected rout= ers that support it between the S/D, since lookup (route installed in conte= xt of the algo it is associated with) is done per hop.

 

Cheers,

Jeff

On Sep 30, 2020, 9:03= AM -0700, Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>, wrote:<= /p>

Hi Muthu,

 

Thanks for the review.

 

An interface can be associated with, at most, one Flexible Algorit= hm. Likewise, an IP address can be associated with, at most, one Flexible A= lgorithm.

 

I tried to express this in the text below, but probably didn’= ;t do a very good job. If you can think of a better way to say it, I would = appreciate suggestions.

 

           =             &nb= sp;            =             &nb= sp; Ron

 

Text from draft

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Network operators configure multiple loopback interfaces on an egr= ess

   node.  They can associate each loopback interfac= e with:

 

   o  Zero or more IP addresses.

 

   o  Zero or one Flexible Algorithms.

 

   If an IP address and a Flexible Algorithm are associa= ted with the

   same interface, they are also associated with one ano= ther.  An IP

   address MAY be associated with, at most, one interfac= e.

 

 

 

 

 

Juniper Business Use Only

From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Sent: Wednesday, September 30, 2020 9:59 AM
To: Ron Bonica <rbonica@ju= niper.net>
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr= -ip-flexalgo-00.txt

 

[External Email. Be cautious of content]=

 

A quick question:

   I=
f an IP address and a Flexible Algorithm are associated with the
   same interface, they are also=
 associated with one another.  An IP
   address MAY be associated wit=
h, at most, one interface.

 

If multiple IP addresses and multiple flexible algorithms are = associated with a loopback interface, is each IP address associated with all flexible algorithms? What matters is the association b/w an IP ad= dress and a flexalgo, so the relationship should be defined in a direc= t way rather than each being associated with an interface, right?

 

Regards,

Muthu 

 

On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org&g= t; wrote:


Please review and comment

                     = ;                  Ron



Juniper Business Use Only

> -----Original Message-----
> From: in= ternet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: Tuesday, September 29, 2020 9:36 AM
> To: Parag Kaneriya <pkaneria@juniper.net>; Shraddha Hegde
> <shraddha= @juniper.net>; Ron Bonica <rbonica@juniper.net>; Rajesh M
> <mrajesh@j= uniper.net>; William Britto A J <bwilliam@juniper.net>
> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.= txt
>
> [External Email. Be cautious of content]
>
>
> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF > repository.
>
> Name:           draft-bonica-lsr-ip-flex= algo
> Revision:       00
> Title:          IGP Flexible Algorithms (Flex= algo) In IP Networks
> Document date:  2020-09-29
> Group:          Individual Submission
> Pages:          14
> URL:            https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica-
> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-l= sr-
> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$
> Htmlized:       https://urldefens= e.com/v3/__https://tools.ietf.org/html/draft-
> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-
> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$
>
>
> Abstract:
>    An IGP Flexible Algorithm computes a constraint-based pat= h and maps
>    that path to an identifier.  As currently defined, F= lexalgo can only
>    map the paths that it computes to Segment Routing (SR) id= entifiers.
>    Therefore, Flexalgo cannot be deployed in the absence of = SR.
>
>    This document extends Flexalgo, so that it can map the pa= ths that it
>    computes to IP addresses.  This allows Flexalgo to b= e deployed in any
>    IP network, even in the absence of SR.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/= mailman/listinfo/lsr

--_000_DM6PR05MB63480E863599BBC810BF334AAE300DM6PR05MB6348namp_-- From nobody Thu Oct 1 13:33:39 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A753A0855; Thu, 1 Oct 2020 13:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=EWPA2usy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=p83QJj6E 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 IGXhQnXZRgHL; Thu, 1 Oct 2020 13:33:35 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135453A07CE; Thu, 1 Oct 2020 13:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11895; q=dns/txt; s=iport; t=1601584415; x=1602794015; h=from:to:cc:subject:date:message-id:mime-version; bh=Vxco7UmKoaPqAMSPNuqHbyS40BwSNtD12c4iQVbf56Q=; b=EWPA2usy+1TmezXoJxbh95Bzfv5bjqtaXwvPEYzHQwxqjvAtqRGiXrjD EpgxZ7abQys1GgtOvNpuowRJQcqedoXPt/1mkQ7xOdp1tZFQ4Pa9JJ8vf KrwKZlfpJAu4fm+veYEbGKs6Tielj2J/hJgcSVp6/6QKe2fIzn4lu/QEm g=; IronPort-PHdr: =?us-ascii?q?9a23=3AJef+CRQY9gkKYOgNvCwRc3nEstpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4BgDoO3Zf/4wNJK1gHgE8DAILgWS?= =?us-ascii?q?BIy9RB3BZLywKhDODRgONW5QvhG6BLhSBEQNVCwEBAQ0BASUIAgQBAYRKGYI?= =?us-ascii?q?eAiU0CQ4CAwEBCwEBBQEBAQIBBgRthVwBC4V1FhEdAQEsBgUBEQFKAgQwJwQ?= =?us-ascii?q?OJ4MEAYF+TQMuAQ6gRQKBOYhhdoEygwEBAQWBMwGBF4JHGIIQAwaBOIJyg2m?= =?us-ascii?q?GUxuCAIE4DBCFZwICARaBEQESATgWgmozgi2QCYM0hwGdEgqCZ4h9kWEDH4M?= =?us-ascii?q?OigGUDJIMDHqKbpUjAgQCBAUCDgEBBYFUOmdwcBU7KgGCPlAXAg2SEIUUhUJ?= =?us-ascii?q?0DygCBgoBAQMJfIxHAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,325,1596499200"; d="scan'208,217";a="565592649" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Oct 2020 20:33:32 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 091KO6Ui024263 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Oct 2020 20:24:06 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 15:24:05 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 15:24:05 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 1 Oct 2020 15:24:05 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G7zPqsOVFniftkuiZYAT9PLKm0sYfU104tAVTYckSV8OH3QeLx9z7oWpqeyuW+gV4Vm9+wxm9vteR97jT8iqqtvhUp2oSld8fQ12OcT2BeNBhC8BBSLw5evPCumeaGeDfmBcD5CvTt9/2BGmysW9w+pbRkPycFuIgdx6B9BmKNp+iHODpxBCXTlK8D0lexSfPzoHLxI0zF5GEUfTwxj+Nxe/jRuK8yCWnJKa9WhO8EqSjUi0lKql0bHatt6emHA32E/wrOYPkJDavP28ycw13krvVLa3Vswj3njJPCk488a6UPgyXq5SVqEf5K4xyhzzJM3zXnCWDhm3iyfyjIcoqw== 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=Vxco7UmKoaPqAMSPNuqHbyS40BwSNtD12c4iQVbf56Q=; b=FPELIu+jR0h/U0hXTOs90kte7i1KmO6OJxa/GK/ZbPkOOnDK6hfwTnJrNY+aE1E9SCWZeL9k2sqXLMGbJ9dzc+xhlUFr1b3u/sUBZANe1mOiHVhceI0fl10SfM+0RZ/SwSVXtU9hRiUpeKcCtmAw7Tj+YAjWJo+5JOQITILbRpNguAwMOqjj4QFkdP0RYH1+8rcEp7vRIQ8HfgD3WeRv/YdWgXFYeWZK4+HMcSb0V3Mk0IWMZFZiBXzXyEm+DiQO2Afw8ThLzC04X0bOmIzq2Vy6y3iQCtmeMeCuwmOtd+5dzjb6Xk8HTUfNy33wRmtYYywri7BeQKq0C32fKWzdbQ== 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=Vxco7UmKoaPqAMSPNuqHbyS40BwSNtD12c4iQVbf56Q=; b=p83QJj6E8fD+/ib3EX1Ho0bUjGsz5WfmUSqwC19VPpfa/xPypfIyAw5TFqMxIy256bMvbHhVGRoF+yDoPe5cefilDM51x6dSbcTohwUPnWZzcsXnNM6Kepocq1jhShMWnzhfspdAaZtC8bu8bABvABGCMkfmYNdBthZBX+U0+IE= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB2774.namprd11.prod.outlook.com (2603:10b6:a02:c1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.26; Thu, 1 Oct 2020 20:24:02 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3412.029; Thu, 1 Oct 2020 20:24:02 +0000 From: "Acee Lindem (acee)" To: "draft-ietf-lsr-flex-algo@ietf.org" CC: "lsr@ietf.org" Thread-Topic: IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt Thread-Index: AQHWmDDNhkw+5hrRJ0Oa3/xXMwvRhA== Date: Thu, 1 Oct 2020 20:24:02 +0000 Message-ID: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5a5156e-1791-4682-ae56-08d86647efc6 x-ms-traffictypediagnostic: BYAPR11MB2774: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ERZy18ZzMbQdThFXObnE/yIRGr0gcPvaPG2Q+iRNsfbxaT3ha6rvpj7+OswnJJIHpruBUHmZrzf1I6iLtuIyHT9zwxFbsA6W3xMXUSyGERkBvQ8o7FC9FFAZrxZjqWhzt5Jiy2WwUhrFv4wQs3t99+KEzwaDVhUEXboDIrt+b7qG0LdwyqQasXBKGtj3RrJdApitRcamrrPO8jqaJfi50LYw6wzo6O9YZCuQ6PJBqaDdFYMRwC3cjLxUYeJz4pWGb4keXBULLgAbBpC2iUSIYq6KPgvCEom6cWdOxMVEMRRGDYTt4h+/vTh21jsd2F0A0RB4hE9srQw2mi8xOip7qXH67G9FMK2sVbWXgrgjVeXrlZX9UzVkaa+K9hQHgb4w7eY34UaBn/nQDZjYiHoaEJOEhmWU5B4Ff/m+TOxOIynM90t++9V4xzmvVb1yxJM1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(39860400002)(376002)(366004)(136003)(36756003)(316002)(8676002)(186003)(6506007)(8936002)(64756008)(66556008)(86362001)(66446008)(5660300002)(478600001)(83380400001)(6916009)(26005)(2616005)(33656002)(966005)(450100002)(76116006)(66946007)(66476007)(6486002)(2906002)(166002)(4326008)(6512007)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FMU+U+zKW8FaNx78HJVpPfX8nMMmZvy9W3M90KhdOtAqa4+c6P3RhWq9CHBel7ju6W/KDX4N2RDCkiqnlOoHZ/t3UNQdN6uFXGRvSzcuvPSuplkqIEtKDzcKwUMZwI+OlY/ZRGjM4cxeN9G5NK0KeD+KyZ3qrmi3qWVqv5ibMvLqLlyzEqa2zXB8GtZN7Ny9ykNITPjR66dVezDw2HdUhI5ee0HvY1yusUPGufvcer01qv9Jc2SV9kad7ddvTxT7yZW//bot/jXEp2HJaDtKt7sryHeHUpwmVQhSYAGVuV/aQfn3na6H6yRtx4Y2biX82s/TC0RL6WI1aPJ3gJ6Rccp6HUmf2OFbPjfmiZWqIlp1zMlfGh1OQZLdLGRqNb0Orys3mn2ljFsj7I2fCedgfyF7F1bKODYU2O7toY+3PrZOKGWwR2JnWiYMyXKmBWIE3J/iV0uzC4eqdqjcR9UIvSiO6gUtyENKb1yilaIfs3UgwqmdQIQbKGuTiiDyG+5af5eURDaxyGP7wJKWCedb6bT4gYCvd3y3QchzqsI1cS+fHMbaf0loeW5ClXmS6/SSj6TJ3Dew9XZmxWnM99GWiDPA8SbMQx9LDwrIx98qrmOPcg9Ssx/KYSwTJsDWqHKQOydFCnnhZzx8rCUl9+nIVw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_561B9BA49638403089D4E7A25F89EE51ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5a5156e-1791-4682-ae56-08d86647efc6 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 20:24:02.2762 (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: Ycr5lOR9P6gJy62XI4GdfFsQHLMPspY5DjLorJptnKVt6Z00GeKUqSAVLrkZI+RJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2774 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 20:33:38 -0000 --_000_561B9BA49638403089D4E7A25F89EE51ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXV0aG9ycywNCg0KVGhlIGZvbGxvd2luZyBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIChleGNlcnB0 ZWQgZnJvbSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP3N1Ym1pdD1k cmFmdCZpZD1kcmFmdC1pZXRmLWxzci1mbGV4LWFsZ28pOg0KDQpEYXRlDQpJRA0KU3RhdGVtZW50 DQoyMDE4LTA4LTA4DQozMjQ4DQpDaXNjbydzIFN0YXRlbWVudCBhYm91dCBJUFIgcmVsYXRlZCB0 byBkcmFmdC1pZXRmLWxzci1mbGV4LWFsZ288aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p cHIvMzI0OC8+DQoyMDE5LTEyLTA1DQozOTEwDQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLixMdGQn cyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdv PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzM5MTAvPg0KDQoNCkFyZSB5b3UgYXdh cmUgb2YgYW55IG90aGVyIElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1sc3ItZmxleC1h bGdvPw0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ug d2l0aCBJRVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzgg Zm9yIG1vcmUgZGV0YWlscykuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0 aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kDQp0byB0aGlzIGVtYWlsIHJlZ2FyZGxl c3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkNCnJlbGV2YW50IElQUi4g KlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBMU1IgV0cgbWFpbGluZw0KbGlz dC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGls IGENCnJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRy aWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBMU1IgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5v dCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQpjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGlj aXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZg0KYW55IElQUiB0aGF0IGhhcyBu b3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCg0K VGhhbmtzLA0KQWNlZQ0KDQoNCg== --_000_561B9BA49638403089D4E7A25F89EE51ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8BD9EAF862B6F441B4C1D585D9E2F101@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5BdXRob3Jz LCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+VGhlIGZvbGxvd2luZyBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIChl eGNlcnB0ZWQgZnJvbQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIv c2VhcmNoLz9zdWJtaXQ9ZHJhZnQmYW1wO2lkPWRyYWZ0LWlldGYtbHNyLWZsZXgtYWxnbyI+DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP3N1Ym1pdD1kcmFmdCZhbXA7 aWQ9ZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdvPC9hPik6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29O b3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdp ZHRoPSIxMzM3IiBzdHlsZT0id2lkdGg6MTAwMi43NXB0O2JhY2tncm91bmQ6d2hpdGU7Ym9yZGVy LWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0aGVhZD4NCjx0cj4NCjx0ZCB2YWxpZ249ImJvdHRvbSIg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgI0RERERERCAxLjVwdDtwYWRk aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8 L3RkPg0KPHRkIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRv bTpzb2xpZCAjREREREREIDEuNXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JRDxvOnA+ PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjREREREREIDEuNXB0O3BhZGRpbmc6Ljc1 cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5TdGF0ZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8L3RoZWFkPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249 InRvcCIgc3R5bGU9ImJvcmRlcjpub25lO2JhY2tncm91bmQ6I0Y5RjlGOTtwYWRkaW5nOjIuMjVw dCAyLjI1cHQgMi4yNXB0IDIuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjIwMTgtMDgtMDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOm5vbmU7YmFja2dyb3VuZDojRjlGOUY5O3Bh ZGRpbmc6Mi4yNXB0IDIuMjVwdCAyLjI1cHQgMi4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MzI0ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6bm9uZTtiYWNrZ3JvdW5kOiNGOUY5 Rjk7cGFkZGluZzoyLjI1cHQgMi4yNXB0IDIuMjVwdCAyLjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2lwci8zMjQ4LyI+Q2lzY28ncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0 ZWQgdG8gZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0RERERERCAxLjBwdDtwYWRkaW5nOjIuMjVwdCAy LjI1cHQgMi4yNXB0IDIuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjIwMTktMTItMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRk IHZhbGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRERERERE IDEuMHB0O3BhZGRpbmc6Mi4yNXB0IDIuMjVwdCAyLjI1cHQgMi4yNXB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MzkxMDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNEREREREQgMS4wcHQ7cGFkZGluZzoyLjI1cHQgMi4yNXB0IDIuMjVwdCAyLjI1 cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8zOTEwLyI+SHVhd2VpIFRlY2hu b2xvZ2llcyBDby4sTHRkJ3MgU3RhdGVtZW50IGFib3V0IElQUiByZWxhdGVkIHRvIGRyYWZ0LWll dGYtbHNyLWZsZXgtYWxnbzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPkFyZSB5b3UgYXdhcmUgb2YgYW55IG90aGVyIElQUiB0aGF0IGFwcGxpZXMgdG8mbmJzcDtk cmFmdC1pZXRmLWxzci1mbGV4LWFsZ28/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5JZiBzbywgaGFzIHRo aXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOmJsYWNrIj4oc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBk ZXRhaWxzKS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1l bnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPnRvIHRoaXMgZW1h aWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr Ij5yZWxldmFudCBJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTFNS IFdHIG1haWxpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjpibGFjayI+bGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRv IHRoZSBuZXh0IHN0YWdlIHVudGlsIGE8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+cmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQg ZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5JZiB5 b3UgYXJlIG9uIHRoZSBMU1IgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4g YXV0aG9yIG9yPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6YmxhY2siPmNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3Bv bmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPmFueSBJUFIgdGhhdCBoYXMgbm90IHll dCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNr Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkFjZWU8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_561B9BA49638403089D4E7A25F89EE51ciscocom_-- From nobody Thu Oct 1 20:28:36 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E584E3A0D97; Thu, 1 Oct 2020 20:28:33 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=gyGLvy6B; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EYNNIKXl 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 VIHVgI93NyMm; Thu, 1 Oct 2020 20:28:32 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070D33A0D95; Thu, 1 Oct 2020 20:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14824; q=dns/txt; s=iport; t=1601609312; x=1602818912; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=64YpHmjTFo+7cnqvUr36N12me75m89rkCyIa0HlPDQ8=; b=gyGLvy6Bhm+10srCw5GSYCloy7vURG5XD/FGAPn6srEf/fskvQmiNGsm lH9CJvu4skMqnNOmsObIiDmyLr8GybxGbGVFbMp1LQbcns/4Uf42pqT/R nSt3qz3qqmy0iYeDks84R4xNR0B/1+CoNH4uGGGrkgAnpY01CZ9xMucRu w=; IronPort-PHdr: =?us-ascii?q?9a23=3ABJOWGRw4BdBNTpfXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWDt/5sl1TOG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iKwMFNeH4D1YFiB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1CQCKnXZf/49dJa1gg3svUQdwWS8?= =?us-ascii?q?sCoQzg0YDjgGUCYRugUKBEQNVCwEBAQ0BASUIAgQBAYRKAheCHgIlOBMCAwE?= =?us-ascii?q?BCwEBBQEBAQIBBgRthVwMhXIBAQEBAxIRChMBASwGBQEPAgEIEQQBASsCAgI?= =?us-ascii?q?wHQgCBAENBQgagwWBfk0DLgEOnRQCgTmIYXaBMoMBAQEFgTMBg2YYghADBoE?= =?us-ascii?q?4gnKDaYZTG4FBP4FUgk0+glwCAgEWgREBEgEjFRaCajOCLZAJgzSHAZ0SCoJ?= =?us-ascii?q?niH6SBIMOigGUDJINDHqKb5UkAgQCBAUCDgEBBYFrI2dwcBU7gmlQFwINkhC?= =?us-ascii?q?FFIVCdA8oAgYKAQEDCXyMOwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,326,1596499200"; d="scan'208,217";a="587115332" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Oct 2020 03:28:30 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0923SUGg030258 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2020 03:28:30 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 22:28:30 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 22:28:30 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 1 Oct 2020 23:28:29 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kovjtmOl41LldcTSxYcVPeo9hso1JOSymBj1gJrQgloE2OgOT1SPSoFSVVTMSoWLodJA00IOIG0M+zHcjbpDei5uM7CniCcx+Pv4YqYF6P+/A+pjgXCPQnbumjYxKr+uXnVm3X32WmPhE++3oDP9bXyDd0tAr+8eU7wae3pvUXh1CBN+808gk5JZqNUMzWDxyhTSBOWBN4i1ohPSpj8oXKTWlYnqukxQRI1JdKlcyZ7OR4sgBXA1yiqgYGdco6Bi+SJ4NJsvDp9FjGGKBSWQbckCZkWlO8QF8HEQQ4ErG1gkIB/BUzGwrmm4jyN46hAEHaWe0vzHEtw42IF/MylHyw== 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=64YpHmjTFo+7cnqvUr36N12me75m89rkCyIa0HlPDQ8=; b=HtllFv9rKqD9ORNpTGaFYVSfW7w5dkHSzIwApfvANLH1kgaQevEui4Q8pudJN8PM82NkaqBYVpOoxC4eqYvNulxFH+c09gLtJE8F8f5Tg1fyvUzTJg6Ks9Qoaekhwqy0p/m0z8By4qxNg83sN/kFLcRWo0SKIiV14elRTc7PfpQ46xzRD4zBGVOrjLHR59wHVp4JMZKVYlloBPTy8dCkGV23DLVVEREBTGyUMf9/NTa5YAiwRb71NhEvSqjyQHUa3kDWTULyqQ0jqgWduMHmz1iWcVLhSE8rlKsGHX/SUWuIp5I7eJBXUANjc0HDe8vB5XtxTHNM1oSCcHPn1WEn3w== 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=64YpHmjTFo+7cnqvUr36N12me75m89rkCyIa0HlPDQ8=; b=EYNNIKXlPDRxx3YvwJZ5rJHTYtx0t7V9ajYa7wZrG7q1IEuQvSRq4KG7lrZNT8sKE5p4BcjDpzrLJmQE+BgjkoEUgx1Jf++bpkNuLiRJxJOZr6CgCClWgdSor/0lZfDzkarruWzSWZLesliKQtqtLNtQPdTGt+nRM3sR4e7Dses= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1360.namprd11.prod.outlook.com (2603:10b6:300:26::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.37; Fri, 2 Oct 2020 03:28:29 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3433.034; Fri, 2 Oct 2020 03:28:28 +0000 From: "Ketan Talaulikar (ketant)" To: "Acee Lindem (acee)" , "draft-ietf-lsr-flex-algo@ietf.org" CC: "lsr@ietf.org" Thread-Topic: IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt Thread-Index: AQHWmDDNhkw+5hrRJ0Oa3/xXMwvRhKmDp6MQ Date: Fri, 2 Oct 2020 03:28:28 +0000 Message-ID: References: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> In-Reply-To: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.14] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dd5e884c-8653-4fb9-d5ef-08d866833afd x-ms-traffictypediagnostic: MWHPR11MB1360: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Aq4ln0hGD4MxOtDp/vKPdiFQ5ut0gFS9JfPNwNrr5xN+1oy/5u9HORgnBTtHemRmOHkDIFNhjVcwe4Kd/0fvQvY6ZdIzQ78BNC88Q/kL0tYf8Fcec+CF0HFLu8hD4TKrrTQ0IX9TEbpCcoFdd0sAmV6qieAbxhUw2K4GQ4ArJAYaY/hQuKuwFaOBXCRitIC1fTAB5JDHHNduDug1IOYaR9Rg3c6qyro9PZHGZuksF0MtjC+aNGCh6oGI3TGdRduuCjxd7dWXsCy5Uwjc1Kzl9bbuIpG03T3+zwWd6aNz7tKYdd5eFCpD6+tchAztIIuUXX8TG97Q9JfgQTLHsXHmjM+OYzuzwyfouhhrBaPGztEfGAxF1fn9zXRT3poxAARxYy/hMxD2i3xZvQ/BnvLwkA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(376002)(136003)(39860400002)(346002)(66946007)(64756008)(66556008)(66476007)(53546011)(6506007)(76116006)(33656002)(966005)(478600001)(83380400001)(86362001)(8936002)(9686003)(186003)(166002)(83080400001)(2906002)(8676002)(5660300002)(4326008)(450100002)(55016002)(110136005)(71200400001)(52536014)(66446008)(316002)(26005)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rL4KiKyIktVOyYCl2OL7LfuFiVhunQhgR5dkxcGbATEKWyctE91s3//lvIM/Pid0WRq4d9nS/M0FJMJTGJ5h3O/PnStJjxKkVZhtDlwLf3lvGD3OE8f0chbUOzQfbIKGPsOaCbxEBvqyrZGXl8RasLZn70lwdHfjeVRoPIL8HH8N2oI1vkNE78JzQNvLP6qwoBhnbnfvBFUp12XGGO6WO0noDESalivHzHPLta+MrR7mYTf5Xzgjny71jC/KGwK67MoxYmm5zqYquzOHYM74QwXYPHkov1p0oKMq2YLa4TUV/LK7c6z7HvTYVWU+ZaKVtw1jGBCMjAAPoFmQnSfOi59GPbn9a1n0jo5Mfb6iYCEhrFmCCaM6K6VFP3978gILtPH31Tfj9pTqkP0BBcW/PSCRRqvB2RcgYN1WDRmz2qnMSLWJXBMLMzGk/1t0L4sDKYdRvFFGNpGFQ3cCWT5e7viiQKN0oLzO6rmKRvmnze7N8BGAyGGiaqS3zaEFKi/vLeT/6nKCV/qRSDnaDVB0najXCXB1s22OSHBqws/pQk+m7ex8fLzSBFjuzLZhrZsUniHvEGVOJYFZ2mgTDegtKVWUvnDribTGd9bccw64TrcgF5rqnjkX7mP8eQ6tnE7/2FU3mPvdzafxovR2G/tpZA== Content-Type: multipart/alternative; boundary="_000_MW3PR11MB457004E764BAF9868B6EEAC5C1310MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd5e884c-8653-4fb9-d5ef-08d866833afd X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 03:28:28.5515 (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: gxDY9XgteUDRpY6432C6NXKWpLV8tYfS0EDOERwGV3TfQNV6PiyY6BJY7ocAp7ob8A+kWL8QfAcROpNBPx2fCw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1360 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 03:28:34 -0000 --_000_MW3PR11MB457004E764BAF9868B6EEAC5C1310MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBvdGhlciB0aGFuIHRoZSBvbmUgYWxyZWFkeSBkaXNj bG9zZWQgYmVsb3cuDQoNClRoYW5rcywNCktldGFuDQoNCkZyb206IEFjZWUgTGluZGVtIChhY2Vl KSA8YWNlZUBjaXNjby5jb20+DQpTZW50OiAwMiBPY3RvYmVyIDIwMjAgMDE6NTQNClRvOiBkcmFm dC1pZXRmLWxzci1mbGV4LWFsZ29AaWV0Zi5vcmcNCkNjOiBsc3JAaWV0Zi5vcmcNClN1YmplY3Q6 IElQUiBDYWxsIG9uICJJR1AgRmxleGlibGUgQWxnb3JpdGhtIiAtIGRyYWZ0LWlldGYtbHNyLWZs ZXgtYWxnby0xMS50eHQNCg0KQXV0aG9ycywNCg0KVGhlIGZvbGxvd2luZyBJUFIgaGFzIGJlZW4g ZGlzY2xvc2VkIChleGNlcnB0ZWQgZnJvbSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lw ci9zZWFyY2gvP3N1Ym1pdD1kcmFmdCZpZD1kcmFmdC1pZXRmLWxzci1mbGV4LWFsZ28pOg0KDQpE YXRlDQpJRA0KU3RhdGVtZW50DQoyMDE4LTA4LTA4DQozMjQ4DQpDaXNjbydzIFN0YXRlbWVudCBh Ym91dCBJUFIgcmVsYXRlZCB0byBkcmFmdC1pZXRmLWxzci1mbGV4LWFsZ288aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9pcHIvMzI0OC8+DQoyMDE5LTEyLTA1DQozOTEwDQpIdWF3ZWkgVGVj aG5vbG9naWVzIENvLixMdGQncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQt aWV0Zi1sc3ItZmxleC1hbGdvPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzM5MTAv Pg0KDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IG90aGVyIElQUiB0aGF0IGFwcGxpZXMgdG8gZHJh ZnQtaWV0Zi1sc3ItZmxleC1hbGdvPw0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xv c2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KKHNlZSBSRkNzIDM5NzksIDQ4 NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoNCklmIHlvdSBhcmUgbGlzdGVk IGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kDQp0byB0 aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBh bnkNCnJlbGV2YW50IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBM U1IgV0cgbWFpbGluZw0KbGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRo ZSBuZXh0IHN0YWdlIHVudGlsIGENCnJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFj aCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBMU1IgV0cgZW1h aWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQpjb250cmlidXRvciwg dGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZg0K YW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdp dGggSUVURiBydWxlcy4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCg== --_000_MW3PR11MB457004E764BAF9868B6EEAC5C1310MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1JTiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkg SVBSIG90aGVyIHRoYW4gdGhlIG9uZSBhbHJlYWR5IGRpc2Nsb3NlZCBiZWxvdy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+S2V0YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IEFjZWUgTGluZGVtIChh Y2VlKSAmbHQ7YWNlZUBjaXNjby5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMDIgT2N0b2Jl ciAyMDIwIDAxOjU0PGJyPg0KPGI+VG86PC9iPiBkcmFmdC1pZXRmLWxzci1mbGV4LWFsZ29AaWV0 Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGxzckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBJ UFIgQ2FsbCBvbiAmcXVvdDtJR1AgRmxleGlibGUgQWxnb3JpdGhtJnF1b3Q7IC0gZHJhZnQtaWV0 Zi1sc3ItZmxleC1hbGdvLTExLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+QXV0aG9ycywmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpi bGFjayI+VGhlIGZvbGxvd2luZyBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIChleGNlcnB0ZWQgZnJv bQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9zdWJt aXQ9ZHJhZnQmYW1wO2lkPWRyYWZ0LWlldGYtbHNyLWZsZXgtYWxnbyI+DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP3N1Ym1pdD1kcmFmdCZhbXA7aWQ9ZHJhZnQtaWV0 Zi1sc3ItZmxleC1hbGdvPC9hPik6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMTMzNyIgc3R5bGU9IndpZHRoOjEwMDIuNzVwdDtiYWNrZ3JvdW5kOndoaXRlO2JvcmRl ci1jb2xsYXBzZTpjb2xsYXBzZSI+DQo8dGhlYWQ+DQo8dHI+DQo8dGQgdmFsaWduPSJib3R0b20i IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICNEREREREQgMS41cHQ7cGFk ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkRhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0K PC90ZD4NCjx0ZCB2YWxpZ249ImJvdHRvbSIgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1ib3R0 b206c29saWQgI0RERERERCAxLjVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SUQ8bzpw PjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249ImJvdHRvbSIgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgI0RERERERCAxLjVwdDtwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+U3RhdGVtZW50PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPC90aGVhZD4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWdu PSJ0b3AiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGOUY5Rjk7cGFkZGluZzoyLjI1cHQgMi4yNXB0IDIu MjVwdCAyLjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4yMDE4LTA4LTA4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249 InRvcCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y5RjlGOTtwYWRkaW5nOjIuMjVwdCAyLjI1cHQgMi4y NXB0IDIuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjMyNDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBz dHlsZT0iYmFja2dyb3VuZDojRjlGOUY5O3BhZGRpbmc6Mi4yNXB0IDIuMjVwdCAyLjI1cHQgMi4y NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMzI0OC8iPkNpc2NvJ3MgU3Rh dGVtZW50IGFib3V0IElQUiByZWxhdGVkIHRvIGRyYWZ0LWlldGYtbHNyLWZsZXgtYWxnbzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIg dmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNEREREREQg MS4wcHQ7cGFkZGluZzoyLjI1cHQgMi4yNXB0IDIuMjVwdCAyLjI1cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4yMDE5LTEyLTA1PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0RERERERCAxLjBwdDtwYWRkaW5nOjIuMjVwdCAyLjI1cHQgMi4yNXB0 IDIuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjM5MTA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjREREREREIDEuMHB0O3BhZGRpbmc6Mi4y NXB0IDIuMjVwdCAyLjI1cHQgMi4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p cHIvMzkxMC8iPkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZCdzIFN0YXRlbWVudCBhYm91dCBJ UFIgcmVsYXRlZCB0byBkcmFmdC1pZXRmLWxzci1mbGV4LWFsZ288L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+QXJlIHlvdSBhd2FyZSBvZiBhbnkgb3RoZXIgSVBSIHRoYXQg YXBwbGllcyB0byZuYnNwO2RyYWZ0LWlldGYtbHNyLWZsZXgtYWxnbz88L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5J ZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRG IElQUiBydWxlcyZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPihzZWUgUkZD cyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9y IHBsZWFzZSByZXNwb25kPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+dG8gdGhpcyBl bWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+cmVsZXZhbnQgSVBSLiAqVGhlIHJlc3BvbnNl IG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIExTUiBXRyBtYWlsaW5nPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+bGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRo ZSBuZXh0IHN0YWdlIHVudGlsIGE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5yZXNw b25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOmJsYWNrIj5JZiB5b3UgYXJlIG9uIHRoZSBMU1IgV0cgZW1haWwgbGlzdCBidXQgYXJl IG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFj ayI+Y29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlv dSBhcmUgYXdhcmUgb2Y8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5hbnkgSVBSIHRo YXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1 bGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5BY2VlPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MW3PR11MB457004E764BAF9868B6EEAC5C1310MW3PR11MB4570namp_-- From nobody Fri Oct 2 00:44:45 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC73A0EE1; Fri, 2 Oct 2020 00:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbQs6pqNpzRK; Fri, 2 Oct 2020 00:44:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BCE03A0A3E; Fri, 2 Oct 2020 00:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1571; q=dns/txt; s=iport; t=1601624681; x=1602834281; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=s1r0nD/j0waJ82vKMHXqZHko3NGIm0LDI4gRMc/CKxo=; b=IZGSXB48QzCtBRCPUNZww+7tUf0ulYlkQEDgg83K+CewJ37TCbc19nek K/HTrNeeDB8T2h634omRTdqTCNqE5wFqw3zxPWEWYLKh/INOJZSI4adDM AG9ODudBXo+UAmDpC/XwHxqjnrwWG2MjBCjniGdqurKb5WE8vOwsi6Tys o=; X-IronPort-AV: E=Sophos;i="5.77,326,1596499200"; d="scan'208";a="30062934" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Oct 2020 07:44:40 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 0927id0T024008; Fri, 2 Oct 2020 07:44:39 GMT To: "Acee Lindem (acee)" , "draft-ietf-lsr-flex-algo@ietf.org" Cc: "lsr@ietf.org" References: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> From: Peter Psenak Message-ID: <293b0824-2791-69dd-75b8-f2eee0876986@cisco.com> Date: Fri, 2 Oct 2020 09:44:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 07:44:44 -0000 Hi Acee, I am not aware of any IPR other than the one already disclosed below. thanks, Peter On 01/10/2020 22:24, Acee Lindem (acee) wrote: > Authors, > > The following IPR has been disclosed (excerpted from > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo): > > > *Date* > > > > *ID* > > > > *Statement* > > 2018-08-08 > > > > 3248 > > > > Cisco's Statement about IPR related to draft-ietf-lsr-flex-algo > > > 2019-12-05 > > > > 3910 > > > > Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-lsr-flex-algo > > Are you aware of any other IPR that applies to draft-ietf-lsr-flex-algo? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond > > to this email regardless of whether or not you are aware of any > > relevant IPR. *The response needs to be sent to the LSR WG mailing > > list.* The document will not advance to the next stage until a > > response has been received from each author and contributor. > > If you are on the LSR WG email list but are not listed as an author or > > contributor, then please explicitly respond only if you are aware of > > any IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, > > Acee > From nobody Fri Oct 2 03:03:53 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174523A0F78 for ; Fri, 2 Oct 2020 03:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 ZqjPOYv0k7lo for ; Fri, 2 Oct 2020 03:03:50 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 398E93A0EF0 for ; Fri, 2 Oct 2020 03:03:50 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 9E4A060424; Fri, 2 Oct 2020 10:03:49 +0000 (UTC) From: Christian Hopps Message-Id: <935951C4-C130-43E4-9BD9-AEB9AEC55982@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_2D0C5221-EC1D-41E1-B426-5B39A433AB21"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 2 Oct 2020 06:03:48 -0400 In-Reply-To: Cc: Christian Hopps , lsr@ietf.org To: Donald Eastlake References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Lsr] Review of draft-ietf-lsr-isis-ttz-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 10:03:52 -0000 --Apple-Mail=_2D0C5221-EC1D-41E1-B426-5B39A433AB21 Content-Type: multipart/alternative; boundary="Apple-Mail=_BDB16FB2-AC50-401E-B30C-B581EDF730D3" --Apple-Mail=_BDB16FB2-AC50-401E-B30C-B581EDF730D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 22, 2020, at 1:21 AM, Donald Eastlake wrote: >=20 >=20 > One final question: I may be confused but my understanding of IS-IS is > that there are Level 1 links, Level 2 links, and links that are both > Level 1 and 2. A border router between Level 1 and Level 2 is a router > that has both types of links attached to it. Such a router is a part > of each Level 1 Area to which it is linked and a part of Level 2. So, > the Level 1 / Level 2 boundary is, in a real sense, internal to such a > border router. Actually IS-IS is different than this (your last 2 sentences). This is a = key conceptual difference between OSPF and IS-IS. In OSPF an OSPF router = (instance) can be attached to several areas. In IS-IS an L1 or L1L2 = router (instance) resides belongs to only a single L1 area. Thus in OSPF = area boundaries exist within the OSPF instance, while in IS-IS the L1 = area boundaries exists on the wire between L2 adjacencies. Thanks, Chris. --Apple-Mail=_BDB16FB2-AC50-401E-B30C-B581EDF730D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Sep 22, 2020, at 1:21 AM, Donald Eastlake <d3e3e3@gmail.com> = wrote:


One final = question: I may be confused but my understanding of IS-IS is
that there = are Level 1 links, Level 2 links, and links that are both
Level 1 and = 2. A border router between Level 1 and Level 2 is a router
that has both = types of links attached to it. Such a router is a part
of each Level = 1 Area to which it is linked and a part of Level 2. So,
the Level 1 / = Level 2 boundary is, in a real sense, internal to such a
border = router. 

Actually IS-IS is different than this = (your last 2 sentences). This is a key conceptual difference between = OSPF and IS-IS. In OSPF an OSPF router (instance) can be attached to = several areas. In IS-IS an L1 or L1L2 router (instance) resides belongs = to only a single L1 area. Thus in OSPF area boundaries exist within the = OSPF instance, while in IS-IS the L1 area boundaries exists on the wire = between L2 adjacencies.

Thanks,
Chris.
= --Apple-Mail=_BDB16FB2-AC50-401E-B30C-B581EDF730D3-- --Apple-Mail=_2D0C5221-EC1D-41E1-B426-5B39A433AB21 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl92+wQACgkQLh2DDte4 MCWQrw/+MPB9SeYSRiRzK1+q1XyXXIKfDTc4CRWL8T0VpDLTnXBj2WgqXFhm4LzV z0UhyjU1GzVzWWQ8w4jfVxA7WTfyqkZVH3UoTPNb47u9cPhXqQ+ORg/PStkZtJI1 6vRP7fZB0eC0/+gzVP7MzGuCATQWqRIHyf1Wved4IJeV8DqGlt3FSUfhiTDsfNwC my2fhl2Gtu5OdbyhHBWJhijhs2Hfonma2+VrJrnzU2pABX04MnEzr4roQNSwBb2p M6OZL21wk1U+PmxRud5q2HIH6lfDOCHQJaOYDBSf9/rj1cuSfVAMUJLc6UxmrOJy HLA78x2C72OCHVu4v76i+HJZ7wWsA3pQSBcrRwSTminRQ6Qi035vjf5stbJ1DHKm 0N1KnS3s0RbAzOrHDbrEhoXbrCZDQaPKkQvl386jDHf2HhOJlDrz5M3ExxsXbeMT zn3lH6xxmf+fcKyGdQK8nB50ykhvkt0bArvRVr6rV3SyUCN11X7JcmNqB3/ZaJdb uk13BlziXIszF/dZ/engnUrQ6pqkj+wws54KEXL8yl6TGBquLODxAcRSUKeTLZR7 yKCAHndzCdeH1Iwvdnwcr4zcCqEeUp9wkomuOfMKq1v5xjV+jyDeenjaEHxOuQfm Eo7hR+DyD+5hVysf8O2Le39H233rrkIneImwhNU6sArDafI2Lno= =zBMB -----END PGP SIGNATURE----- --Apple-Mail=_2D0C5221-EC1D-41E1-B426-5B39A433AB21-- From nobody Fri Oct 2 03:32:41 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FD83A0FB5; Fri, 2 Oct 2020 03:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NM9fTTDrp9Vm; Fri, 2 Oct 2020 03:32:32 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2393A1018; Fri, 2 Oct 2020 03:32:31 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id EB87460424; Fri, 2 Oct 2020 10:32:30 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1B5109E4-8970-4E02-A4F9-DCAE817998C9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 2 Oct 2020 06:32:29 -0400 In-Reply-To: Cc: Christian Hopps , draft-ietf-lsr-isis-srv6-extensions@ietf.org, lsr@ietf.org To: Peter Psenak References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Lsr] Pre-writeup review comments X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 10:32:40 -0000 --Apple-Mail=_1B5109E4-8970-4E02-A4F9-DCAE817998C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the update, a couple issues remain. [ ] 7.1 and 8.1 The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" = are defined differently (and probably incorrectly) than the other reserved = bits. Reserved bits "MUST" be set to zero, not "SHOULD", I believe. [ ] 11. Implementation Status I know you mentioned that the section should be removed, but how about = adding a note to the editor in the next revision e.g., "RFC Ed.: Please = remove this section prior to publication"? [ ] 12.5. Sub-Sub-TLVs for SID Sub-TLVs This section needs to better conform to registry creation standards (see https://tools.ietf.org/html/rfc8126). In particular there is no = guidance. It looks like there is more discussion from Joel on this draft, so I = will hold off on submission for that to resolve. Thanks, Chris. > On Sep 23, 2020, at 4:36 PM, Peter Psenak = wrote: >=20 > Hi Chris, >=20 > thanks for your comments. >=20 > Please see inline (##PP): >=20 > On 18/09/2020 16:08, Christian Hoppsprotocol=3D = application/pgp-signature wrote: >> During my review and while doing the Shepherd writeup for = https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I = came up with the following comments: >> 4.3 - Maximum H.Encaps MSD Type: >> - what is the default if not advertised? >=20 > ##PP > added "or no value is advertised" as for other MSD types. >=20 >> 6. Advertising Anycast Property >> Should "Locator that is advertised..." be: >> "An SRv6 Locator that is advertised..."? >> or: >> "A prefix/SRv6 Locator that is advertised..."? >=20 > ##PP > fixed. >=20 >> 7.1 SRv6 Locator TLV Format >> The R fields and their handling, are not defined. >=20 > ##PP > added >=20 >=20 >> 8. Advertising SRv6 Adjacency SIDs >> "must be" "in order to be correctly applied" -> "are" and ""? >=20 > ##PP > I replaced with: >=20 > Certain SRv6 Endpoint behaviors = [I-D.ietf-spring-srv6-network-programming] are associated with a = particular adjacency. >=20 >=20 >> 8.1. SRv6 End.X SID sub-TLV >> "Other bits" -> "Reserved bits" -- labels should match >=20 > ##PP > fixed. >=20 >> 8.2. SRv6 LAN End.X SID sub-TLV >> I'm sympathetic to Bruno's comment, and so I think it would be better = to say: >> Diagram: "System ID (1-6 octets)" and in text: >> "6 octets" -> "System ID: 1-6 octets" >> I see no reason to mess with this even if the commonly-implemented = value is 6 at >> this point. IS-IS implementations that only support 6 octets are free = to only >> support 6 in this sub-TLV as well. They won't be talking with other = IS-IS >> routers that are configured to have a non-6 octet system ID value. = What other >> extension RFCs may or may-not do WRT this doesn't really matter I = think. >=20 > ##PP > I have updated the text to match what is being used in RFC8667, = section 2.2.2 >=20 >=20 >> "Other bits" -> "Reserved bits" -- labels should match >=20 > ##PP > fixed >=20 >> 11. Implementation Status >> Does this section need a "RFC Ed.: Please Remove prior to = publications"? It >> seems pretty wrong to document current status of implementations = permanently in >> an Standards Track RFC. >=20 > ##PP > yes this section will be removed prior to publication. This is a = standard procedure we follow. >=20 >> 12. IANA Considerations >> An odd space between "sub- TLV". >=20 > ##PP > fixed >=20 >> 12.5. Sub-Sub-TLVs for SID Sub-TLVs >> This section needs to better conform to registry creation standards = (see >> https://tools.ietf.org/html/rfc8126). >=20 > ##PP > I updated the IANA section format similar to RFC8667. >=20 >=20 >> ID-NITS: >> There are 19 instances of too long lines in the document, the = longest one >> being 5 characters in excess of 72. >=20 > ##PP > fixed. >=20 >> References: >> Normative: >> Published: RFC 8754 draft-6man-segment-routing-header >=20 > ##PP > fixed. >=20 >=20 >> Out of date reference: [I-D.ietf-6man-spring-srv6-oam] >> Out of date reference: [I-D.ietf-spring-srv6-network-programming] >=20 > ##PP > Whenever the new version of draft-ietf-lsr-isis-srv6-extension is = published it picks the latest version, but as these drafts keep changing = the reference may get out of date quickly. >=20 >=20 >=20 >> Informative: >> Published: RFC 8402 draft-ietf-spring-segment-routing >=20 > ##PP > fixed >=20 > thanks, > Peter >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >=20 --Apple-Mail=_1B5109E4-8970-4E02-A4F9-DCAE817998C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl93Ab0ACgkQLh2DDte4 MCVruxAAjR/zqUFyhatZTt2d8j/z20236gUdoUuRh7N8LH+h4eh5kUuRnbCK9/5t rCQNW4zyAVrVTJs5SeZvW7dFHH+7CxZfoMeuAUqxVPOARF6M7W3XIkYiMevcP3ZI TqQH/9DgTsmf7/fd8iX8svBV0HHT6XRWFg/kSB1HLb7bpN7zCrTWJWQbSD/D1VZc sNxhbK0+eDvhO6BjzYa6PT4vs+c2DuEGm1C1RCclvMvWnQLeJ7mgwEwjLHwl40Mo TltmbXgketzHiCbBCfs2TsMh/AMi0ZMcHV/6GuUigrpFb7y2MH34cehU7FqBaHOa zijhU7uZ+fWrSbiHrPtq1JHHwEuQeZ9/tnCmV0Bs95o2x4u8lAzGRfZNdeOOXodd idz6Xh5xd90paVmoT65coHb/661Vqx176hMvEh9++yM9lyE7HhFd9dXs7zIhcj5G dvKQ2m2OwPx1jXuDSzBvXe22ubYuTBxfdBk9jrnFqsrHTDOF1C87GIvdUo+JZoJE WMRUGwfdE0AasOOFbBA4VcVU2B6QRTv4FdMiySnfq7mB2Ruud/9Ks3WXdzEKZEAq 1tWh+ct4Ga6ELAldJmXZS0+LIy3cmsmpOL5vKbw5kIlLxH8+6OuSMA195FuuOpiK ijodnSQAidEGZ8nQ479cs7f9gjyGF7RCuhNnDxSEh4Rsqvy888I= =+RTQ -----END PGP SIGNATURE----- --Apple-Mail=_1B5109E4-8970-4E02-A4F9-DCAE817998C9-- From nobody Fri Oct 2 04:59:31 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 653823A10C1; Fri, 2 Oct 2020 04:59:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.18.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160163997039.28883.88233522459412577@ietfa.amsl.com> Date: Fri, 02 Oct 2020 04:59:30 -0700 Archived-At: Subject: [Lsr] The LSR WG has placed draft-ketant-lsr-ospf-l2bundles in state "Call For Adoption By WG Issued" X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 11:59:30 -0000 The LSR WG has placed draft-ketant-lsr-ospf-l2bundles in state Call For Adoption By WG Issued (entered by Christian Hopps) The document is available at https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ From nobody Fri Oct 2 05:00:01 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3873A10C1; Fri, 2 Oct 2020 04:59:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.18.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <160163999579.28732.10133164971741531655@ietfa.amsl.com> Date: Fri, 02 Oct 2020 04:59:55 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-07.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 11:59:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Model for OSPFv3 Extended LSAs Authors : Acee Lindem Sharmila Palani Yingzhen Qu Filename : draft-ietf-lsr-ospfv3-extended-lsa-yang-07.txt Pages : 29 Date : 2020-10-02 Abstract: This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-07 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 2 05:03:38 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285233A0F82; Fri, 2 Oct 2020 05:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FQ3MvbXQuzN2; Fri, 2 Oct 2020 05:03:34 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 696CB3A0F5F; Fri, 2 Oct 2020 05:03:31 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id C18026046C; Fri, 2 Oct 2020 12:03:30 +0000 (UTC) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_3A14591C-66A4-4D4A-8A2D-66E639429B46"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> Date: Fri, 2 Oct 2020 08:03:29 -0400 Cc: Christian Hopps , lsr-chairs@ietf.org, draft-ketant-lsr-ospf-l2bundles.all@ietf.org To: lsr@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 12:03:36 -0000 --Apple-Mail=_3A14591C-66A4-4D4A-8A2D-66E639429B46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This begins a 2 week WG adoption call for the following draft: https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ Please indicate your support or objection by October 16, 2020. Authors, please respond to the list indicating whether you are aware of = any IPR that applies to this draft. Thanks, Chris and Acee. --Apple-Mail=_3A14591C-66A4-4D4A-8A2D-66E639429B46 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl93FxEACgkQLh2DDte4 MCV6HRAAo8jwri1Y1raqGCAcmedza1eqjlCkF8f8F2CGYJhUbaLiCBALod5HeeD+ 0/nfR/H+KC9tT4z40DoBNULz9DnpnsjQ9+4Oimuk/9fhexIReYem8TDzBMFsulyU s2hKLQxso/ptCYQvFumOukJbA8boj8qBMDkTBazUgJYbZhtZAmwcCRroP6WQq+vn 8wienR3b/EesqxMFfkH11AP6j1Vh6QDiGcZ21xHEOQ6xwXBbyC5m5C/SX2scItIU RCYAtxvY32ZgyDQoKnVYuo+lcpMVEHKybVr+xGfrXYAdsRHiCy3E8TUjFVf8IN2O K79zvRRyC48NKqqHj8a8Ne0mLaT73Iv60BfFUSLgKozip12cUFs5mFKSvCuNFI0m Ve2gfywyGZS122uES1PfUXb4xkx8e9zcqB0hB60wlF1Sc4i4iGlFpWAsslFVYd6I 5OdrGMCkz69A65ipxBuzmu8lcsl+s7v3uBqnhikL0TMMs1JL1N5QzYkXhFXD4QMq SCB79jl77gzO+b+qz436AxJIH5pO1sYtt1se/pHtoeUqNeySvaT1t8uYeBO4M6YL /iYc+iSvYp+8uRe5tgKentvs/iX6kBTmIBk7RTZ59bh0Eq94Dg9KEkbBUWPDMtMR pB3HXeeNJ2vxcTelI3O9pWsIvS68sfYfJu4YAY9sJECRojIYC8o= =bfbV -----END PGP SIGNATURE----- --Apple-Mail=_3A14591C-66A4-4D4A-8A2D-66E639429B46-- From nobody Fri Oct 2 09:30:46 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50C33A1134 for ; Fri, 2 Oct 2020 09:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 O0gjsDFzgn9m for ; Fri, 2 Oct 2020 09:30:41 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 37A123A1103 for ; Fri, 2 Oct 2020 09:30:41 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id z1so552460uaa.6 for ; Fri, 02 Oct 2020 09:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LgfjRaMjdbkxvXbYWEvke1AZli7wBXl0qVLQoXooE6Q=; b=B3CEiK/h9t3h8HwoYez7ZN2Fp/Kz+QvCEE7GboFj9oqzG0jjlFtAOUS9MKoziyEL0G +yiMDEF/ENM++Tu3Yd75Lfa6+GAynKrKXztpC2oKeLjr6ecor2plbIbycp1TcD49zkrq J5Sn+d/VjchUdlLeA7eSmPU03h3stohv0xLtVp2yiQnIdA121bNulj9WDwdFVldEPeRz 8k4xaH6DzeXSE2p86ArSh9Ckl1oC0IHfAKGypIQe5jyc9nGjtuScfTDvOGOoJxpNnMba +BPsIZvSz5BhckOJxbhGZnSkBpYONelX1mqyNJT2ppTNbV7hVpcbdeBRgrdrAV7gC6mg yFpg== 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=LgfjRaMjdbkxvXbYWEvke1AZli7wBXl0qVLQoXooE6Q=; b=AMJwzSvCYPajre7FtYK0NFGQVnTkUouk/aDioyJ9OJ2h3IeLZhgxajpi4b0CNbY9mz Xm5+1SjbFYDXD8V2sCc5Bc2wizcnoNjKCgwnMuQDuJGNl02H/Q174SAIb9wttY+EJTn0 L8Ylr6E6Gelp2VTgaGBR19Yh9d8CmdsbgVVYFyB2YxCsPR/Q786QMv2qOxYPogiSssGt SWhNaJjzX1HdpyMPbdGWnL0G5hoQTNjIxrqsG4wugPGNFyvQnytF9noo7o3cmkl8Cl4Q HlD3HF6+FiyE2TlpsqX8s0KTrBKDvGcKOC6heUDlrzairBXW5vYUXlJD5vor+EJRKP+A VG/w== X-Gm-Message-State: AOAM530P+TFHQgwkKY0G/olxHxaNeCwdowFDIjcuGM1AGFCub54YiAFj 8WqR54iYEGtsReKfTiZmswiH2Bm7p+ZnxkUbZG8= X-Google-Smtp-Source: ABdhPJxBZP4laGxrfjvHb0VVgS8lJC8MfcUQ+WjeTLWCTpY7Rf1me1eoZd+wy4b6iHg2Qj2uP6Ht5r77uTeAY9GtNgY= X-Received: by 2002:ab0:4e25:: with SMTP id g37mr1717186uah.106.1601656239947; Fri, 02 Oct 2020 09:30:39 -0700 (PDT) MIME-Version: 1.0 References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> In-Reply-To: From: Gyan Mishra Date: Fri, 2 Oct 2020 12:30:29 -0400 Message-ID: To: Ron Bonica Cc: Jeff Tantsura , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003c04c905b0b2a76c" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 16:30:45 -0000 --0000000000003c04c905b0b2a76c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ron I really like the idea of being able to use flex algo over native IPv4 or IPv6. I had asked that very question early on with flex algo and wondered if there was a way to support it with native IP. Great concept and idea!! As mentioned in the thread as you are using loopbacks associated with the flex algorithm the concept is very similar to SRv6 locator and only one algorithm per IP, interface or prefix and uses the same IGP longest prefix match routing. A lot of the basic concepts TLV and nomenclature from the SR flex algo draft seems to be adopted with this draft. Main difference is IP data plane forwarding instead of SR Segment based forwarding plane. Had a question related to the data plane forwarding and building of the explicit paths loose or strict similar to constraint based prefix sid loose path or adjacency sid based strict path done in SR paradigm. As you are using a native IP forwarding plane, how do we accomplish the same building of the explicit path as done with Segment Routing SRv6 using SRH SID list or SR-MPLS label stack from a data plane forwarding standpoint? Would you use a similar RSVP TE style ERO lose or strict record route option used for FRR n:1 facility protection in IP world use ip source route record route IP option to record the path. For IPv6 would you use EH routing header to record the path. In this section maybe having some examples or graphical depiction of the forwarding plane both loose and strict path instantiation and how that would work. 8 . Calculating Constraint-Based Paths Nodes calculate constraint-based paths as described in Section 12 of [I-D.ietf-lsr-flex-algo ]. Maybe recording of the path is not needed if we are doing hop by hop routing just with different constraint algorithms and not the instantiation of a source routed path as with SR. With SR flex algo since the data plane is SR based its a source routed path that is instantiated so this would be different as it would be a IGP control plane based hop by hop routed path. If that=E2=80=99s the case. As flex algo in SR framework can be used in conjunction with SR-TE can this IP based flex algo be used with RSVP TE maybe adding in future IGP opaque LSA or TLV extension to flex algo. As IP based flex algo is very similar to SRv6-BE w/o SRH it seems they both would interoperate nicely as both use native IPv6 forwarding plane. Maybe down the road a separate draft on interoperability of IP flex algo with SR and RSVP-TE if you think that is feasible. All, With SRv6 and IP based flex algo a generic question as it applies to both. Is it possible to have within a single IGP domain different sets of nodes or segments of the network running different algorithms. From both drafts it sounds like all nodes have to agree on same algorithm similar to concept of metric and reference bandwidth all have to have the same style metric and play to the same sheet of music. If there was a way to use multiple algorithms simultaneously based on SFC or services and instantiation of specific algorithm based on service to be rendered. Doing so without causing a routing loop or sub optimal routing. I thought with flex algo that there exists a feature that on each hop there is a way to specify which algo to use hop by hop similar to a hop by hop policy based routing. Kind Regards Gyan On Thu, Oct 1, 2020 at 2:45 PM Ron Bonica wrote: > > > > > > > > > > > > > > > > > Good point!! > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > *From:* Jeff Tantsura > > > *Sent:* Thursday, October 1, 2020 2:08 AM > > > *To:* Ron Bonica > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] FW: New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt > > > > > > > > > > *[External Email. Be cautious of content]* > > > > > > > > > > > > Hi Ron, > > > > > > the readers would benefit if the draft would state that in order for the > technology to work properly, there must be a contiguous set of connected > routers that support it between the S/D, since lookup (route installed in > context of the algo it is associated > > with) is done per hop. > > > > > > > > > > > > > > Cheers, > > > > > Jeff > > > > > > > > > > > On Sep 30, 2020, 9:03 AM -0700, Ron Bonica < > rbonica=3D40juniper.net@dmarc.ietf.org>, wrote: > > > > > > > Hi Muthu, > > > > > > Thanks for the review. > > > > > > An interface can be associated with, at most, one Flexible Algorithm. > Likewise, an IP address can be associated with, at most, one Flexible > Algorithm. > > > > > > I tried to express this in the text below, but probably didn=E2=80=99t do= a very > good job. If you can think of a better way to say it, I would appreciate > suggestions. > > > > > > Ron > > > > > > Text from draft > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Network operators configure multiple loopback interfaces on an egress > > > node. They can associate each loopback interface with: > > > > > > o Zero or more IP addresses. > > > > > > o Zero or one Flexible Algorithms. > > > > > > If an IP address and a Flexible Algorithm are associated with the > > > same interface, they are also associated with one another. An IP > > > address MAY be associated with, at most, one interface. > > > > > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > *From:* Muthu Arul Mozhi Perumal > > > *Sent:* Wednesday, September 30, 2020 9:59 AM > > > *To:* Ron Bonica > > > *Cc:* lsr@ietf.org > > > *Subject:* Re: [Lsr] FW: New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt > > > > > > > > > > > > *[External Email. Be cautious of content]* > > > > > > > > > > A quick question: > > > > > > > If an IP address and a Flexible Algorithm are associated with the > > > > same interface, they are also associated with one another. An IP > > > > address MAY be associated with, at most, one interface. > > > > > > > > > > > > > > > If multiple IP addresses and multiple flexible algorithms are associated > with a loopback interface, is each IP address associated > > with all flexible algorithms? What matters is the association b/w an IP > address and a flexalgo, so the relationship should be defined in a direct > way rather than each being associated with an interface, right? > > > > > > > > > > > > > > Regards, > > > > > > > Muthu > > > > > > > > > > > > > > > > On Tue, Sep 29, 2020 at 7:07 PM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > > > > > > > > Please review and comment > > > > > > Ron > > > > > > > > > > > > Juniper Business Use Only > > > > > > > -----Original Message----- > > > > From: internet-drafts@ietf.org > > > > Sent: Tuesday, September 29, 2020 9:36 AM > > > > To: Parag Kaneriya ; Shraddha Hegde > > > > ; Ron Bonica ; Rajesh M > > > > ; William Britto A J > > > > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.t= xt > > > > > > > > [External Email. Be cautious of content] > > > > > > > > > > > > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > > > > has been successfully submitted by Ron Bonica and posted to the IETF > > > > repository. > > > > > > > > Name: draft-bonica-lsr-ip-flexalgo > > > > Revision: 00 > > > > Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > > > > Document date: 2020-09-29 > > > > Group: Individual Submission > > > > Pages: 14 > > > > URL: > > https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- > > > > > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > > > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > > > > Status: > > > > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica= -lsr- > > > > > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > > > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > > > > Htmlized: > > > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- > > > > > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > > > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > > > > Htmlized: > https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > > > > > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > > > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > > > > > > > > > > > > Abstract: > > > > An IGP Flexible Algorithm computes a constraint-based path and maps > > > > that path to an identifier. As currently defined, Flexalgo can only > > > > map the paths that it computes to Segment Routing (SR) identifiers. > > > > Therefore, Flexalgo cannot be deployed in the absence of SR. > > > > > > > > This document extends Flexalgo, so that it can map the paths that it > > > > computes to IP addresses. This allows Flexalgo to be deployed in an= y > > > > IP network, even in the absence of SR. > > > > > > > > > > > > > > > > > > > > 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 > > . > > > > > > > > The IETF Secretariat > > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000003c04c905b0b2a76c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Ron

I really like the idea of being able to use flex algo over = native IPv4 or IPv6.=C2=A0 I had asked that very question early on with fle= x algo and wondered if there was a way to support it with native IP. =C2=A0=

Great concept and idea!= !

As mentioned in the th= read as you are using loopbacks associated with the flex algorithm the conc= ept is very similar to SRv6 locator and only one algorithm per IP, interfac= e or prefix and uses the same IGP longest prefix match routing.=C2=A0
=

A lot of the basic concepts T= LV and nomenclature from the SR flex algo draft seems to be adopted with th= is draft.=C2=A0 Main difference is IP data plane forwarding instead of SR S= egment based forwarding plane.

Had a question related to the data plane forwarding and building of = the explicit paths loose or strict similar to constraint based prefix sid l= oose path or adjacency sid based strict path done in SR paradigm.=C2=A0 As = you are using a native IP forwarding plane, how do we accomplish the same b= uilding of the explicit path as done with Segment Routing SRv6 using SRH SI= D list or SR-MPLS label stack from a data plane forwarding standpoint?

Would you use a similar RSVP= TE style ERO lose or strict record route option used for FRR n:1 facility = protection in IP world use ip source route record route IP option to record= the path.

For IPv6 woul= d you use EH routing header to record the path. =C2=A0


In this section = maybe having some examples or graphical depiction of the forwarding plane b= oth loose and strict path instantiation and how that would work.

8.  Calcula=
ting Constraint-Based Paths


   Nodes calculate constrain=
t-based paths as described in Section 12 of
   [I-D.ietf-lsr-flex-algo].

Maybe recording of the path= is not needed if we are doing hop by hop routing just with different const= raint algorithms and not the instantiation of a source routed path as with = SR.

With SR flex algo si= nce the data plane is SR based its a source routed path that is instantiate= d so this would be different as it would be a IGP control plane based hop b= y hop routed path.=C2=A0 If that=E2=80=99s the case.

As flex algo in SR framework can be used in co= njunction with SR-TE can this IP based flex algo be used with RSVP TE maybe= adding in future IGP opaque LSA or TLV extension to flex algo.

As IP based flex algo is very simil= ar to SRv6-BE w/o SRH it seems they both would interoperate nicely as both = use native IPv6 forwarding plane.

Maybe down the road a separate draft on interoperability of IP fl= ex algo with SR and RSVP-TE if you think that is feasible.

All,

With SRv6 and IP based flex algo a generic question as it a= pplies to both.=C2=A0 Is it possible to have within a single IGP domain dif= ferent sets of nodes or segments of the network running different algorithm= s.=C2=A0 From both drafts it sounds like all nodes have to agree on same al= gorithm similar to concept of metric and reference bandwidth all have to ha= ve the same style metric and play to the same sheet of music.=C2=A0 If ther= e was a way to use multiple algorithms simultaneously based on SFC or servi= ces and instantiation of specific algorithm based on service to be rendered= .=C2=A0 Doing so without causing a routing loop or sub optimal routing.=C2= =A0 I thought with flex algo that there exists a feature that on each hop t= here is a way to specify which algo to use hop by hop similar to a hop by h= op policy based routing.


Kind Regards=C2=A0

=
Gyan

On Thu, Oct 1, 2020 at 2:45 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> w= rote:















Good = point!!



=C2=A0



=C2=A0



=C2=A0





Juniper Business U= se Only






From: Jeff Tantsura <jefftant.ietf@gmail.com>

Sent: Thursday, October 1, 2020 2:08 AM


To: Ron B= onica <rbonica@= juniper.net>


Cc: lsr@ietf.org


Subject: Re: [Lsr] FW: = New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt<= /u>







= =C2=A0



[External Email. Be cautious of content]=



=C2=A0<= u>









Hi Ron,





the readers= would benefit if the draft would state that in order for the technology to= work properly, there must be a contiguous set of connected routers that su= pport it between the S/D, since lookup (route installed in context of the a= lgo it is associated

with) is done per hop.







=C2=A0





Cheers,





Jeff











On Sep 30, 2020, 9:03 AM -0700, Ron Bonica <= rbonica=3D40juniper.net@dmarc.ietf.org>, wrote:






Hi Muthu,


=C2=A0



Thanks for the review.



=C2=A0



An interface can= be associated with, at most, one Flexible Algorithm. Likewise, an IP addre= ss can be associated with, at most, one Flexible Algorithm.

=C2=A0



I tried to express this in the text below, but probably didn= =E2=80=99t do a very good job. If you can think of a better way to say it, = I would appreciate suggestions.



=C2=A0



=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron

=C2=A0



Text from draft



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



=C2=A0



Network o= perators configure multiple loopback interfaces on an egress<= /p>

=C2=A0=C2=A0 node.=C2=A0 They can associa= te each loopback interface with:



=C2=A0



=C2=A0=C2=A0 o= =C2=A0 Zero or more IP addresses.



=C2=A0



=C2=A0=C2=A0 = o=C2=A0 Zero or one Flexible Algorithms.



=C2=A0



=C2= =A0=C2=A0 If an IP address and a Flexible Algorithm are associated with the=



=C2=A0=C2=A0 same interfac= e, they are also associated with one another.=C2=A0 An IP

=

=C2=A0=C2=A0 address MAY be associated with,= at most, one interface.



= =C2=A0



=C2=A0=



=C2=A0



=C2=A0



=C2= =A0





Juniper Business Use Only







From: Muthu Arul Mozhi Perumal <= ;muthu.arul@gmail= .com>


Sent: Wednesday, September 30, 2020 9:59 AM<= br>

To: Ron Bonica <rbonica@juniper.net>


Cc: lsr@ietf.org


= Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip= -flexalgo-00.txt







=C2=A0





[Extern= al Email. Be cautious of content]



=C2=A0






A quick question:







=C2=A0=C2=A0 If an IP address and =
a Flexible Algorithm are associated with the


=C2=A0=C2=A0 same interface, they are also associated with one another=
.=C2=A0 An IP


<=
span style=3D"font-family:monospace;color:black">=C2=A0=C2=A0 address MAY b=
e associated with, at most, one interface.





=C2=A0




=


If multiple IP=C2=A0addresses and multiple flexibl= e algorithms are associated with a loopback interface, is each IP address= =C2=A0associated

with all flexible algorithms? What matters is the = association b/w an IP address and a flexalgo, so the=C2=A0relationship shou= ld be defined in a direct way rather than each being associated with an int= erface, right?







<= p class=3D"MsoNormal">=C2=A0







Regards,







<= p class=3D"MsoNormal">Muthu=C2=A0






<= br>

=C2=A0






<= br>


On Tue, Sep 29, 2020 at 7:07 PM Ron = Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:







Please review and co= mment





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Ron











Juni= per Business Use Only





> -----Original Message----= -


> From: internet-drafts@ietf.org <internet-drafts@ietf.org>

> Sent: Tuesday, September 29, 2020 9:36 AM


> To: Parag K= aneriya <pkane= ria@juniper.net>; Shraddha Hegde


> <shraddha@juniper.net>; Ro= n Bonica <rboni= ca@juniper.net>; Rajesh M


> <mrajesh@juniper.net>; William Bri= tto A J <bwill= iam@juniper.net>


> Subject: New Version Notification f= or draft-bonica-lsr-ip-flexalgo-00.txt


>


> [Ext= ernal Email. Be cautious of content]


>


>

> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt

=
> has been successfully submitted by Ron Bonica and posted to the IE= TF


> repository.


>


> Name:=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bonica-lsr-ip-flexalgo


&= gt; Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000


> Title:=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 IGP Flexible Algorithms (Flexalgo) In IP Networks<= br>

> Document date:=C2=A0 2020-09-29


> Group:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission


> Pages= :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 14


> URL:=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0

https://urldefense.= com/v3/__https://www.ietf.org/id/draft-bonica-


> lsr-ip-f= lexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP-


> FnUA0oCcZMw3Qde6in0C= 72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$


> Status:


&= gt;

https://urldefense.com/v3/__ht= tps://datatracker.ietf.org/doc/draft-bonica-lsr-


> ip-fle= xalgo/__;!!NEt6yMaO-gk!X7PVDP-


> FnUA0oCcZMw3Qde6in0C72hu_9hO= Z53kPspIarR8fNDyU9Vck8x7e5ZqI$


> Htmlized:


>

https://urldefense.com/v3/__https://datatr= acker.ietf.org/doc/html/draft-


> bonica-lsr-ip-flexalgo__= ;!!NEt6yMaO-gk!X7PVDP-


> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspI= arR8fNDyU9Vck82w_6CyU$


> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://urldefense.com/v3/__https://tools.ietf.org/html/dr= aft-


> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP-<= br>

> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$<= br>

>


>


> Abstract:


>= =C2=A0 =C2=A0 An IGP Flexible Algorithm computes a constraint-based path an= d maps


>=C2=A0 =C2=A0 that path to an identifier.=C2=A0 As cu= rrently defined, Flexalgo can only


>=C2=A0 =C2=A0 map the pat= hs that it computes to Segment Routing (SR) identifiers.


>=C2= =A0 =C2=A0 Therefore, Flexalgo cannot be deployed in the absence of SR.
=

>


>=C2=A0 =C2=A0 This document extends Flexalgo, s= o that it can map the paths that it


>=C2=A0 =C2=A0 computes t= o IP addresses.=C2=A0 This allows Flexalgo to be deployed in any

>=C2=A0 =C2=A0 IP network, even in the absence of SR.


>

>


>


>


> Please note = that it may take a couple of minutes from the time of submission

> until the htmlized version and diff are available at
<= br>tools.ietf.org.


>


> The IETF Secretariat=


>


_______________________________________________=


Lsr mailing list


Lsr@ietf.org


h= ttps://www.ietf.org/mailman/listinfo/lsr





___________________________________________= ____


Lsr mailing list


Lsr@ietf.org


https://www.ietf.org/mailman/li= stinfo/lsr







=








_________________________= ______________________

Lsr mailing list

Lsr@ietf.org

https:= //www.ietf.org/mailman/listinfo/lsr

-- =
=


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
<= /i>Silver Spring, MD


=
--0000000000003c04c905b0b2a76c-- From nobody Fri Oct 2 09:42:13 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ACC3A1156 for ; Fri, 2 Oct 2020 09:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcGpj9ROzNlD for ; Fri, 2 Oct 2020 09:42:11 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFF63A1147 for ; Fri, 2 Oct 2020 09:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1530; q=dns/txt; s=iport; t=1601656931; x=1602866531; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=KYAcG13QGBhixAhjKPhSehnuLIgqeVbS14aG88/HVmw=; b=YBB8Lwu4kI36El2Gh/v/1xj7dRhmAEvs2/uXkbo2ZTP9+uaaZK9Fj4cW ZJbH7MO74QvJ/QXj9zxr+gV0NY6LIjHIqKIcu994KVflTJlyFBZASKO69 XfZ56r0HG3SaX7d/YoWsa4NLONBKo5FvDTeCELorhkBNYHxAEyVEVQP7s s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUAwA5V3df/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DbwEgEoRpiQKICC6cIgsBAQEPLwQBAYRKAoI3JjgTAgM?= =?us-ascii?q?BAQsBAQUBAQECAQYEbYVohXIBAQEBAgEjDwEFPwIFCwsOCgICJgICVwYBDAg?= =?us-ascii?q?BAYMigl0gqE12gTKFVINCgUKBDiqNSYFBP4E4gmk+h1SCYASQH4Jekz+REoJ?= =?us-ascii?q?xgxOXQgUHAx+SIo57kxOgPIFrI4FXMxoIGxWDJU8ZDZxoPwNnAgYBCQEBAwm?= =?us-ascii?q?OSAEB?= X-IronPort-AV: E=Sophos;i="5.77,328,1596499200"; d="scan'208";a="30012765" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Oct 2020 16:42:07 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 092Gg5GX015869; Fri, 2 Oct 2020 16:42:06 GMT To: Gyan Mishra , Ron Bonica Cc: "lsr@ietf.org" , Jeff Tantsura References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> From: Peter Psenak Message-ID: Date: Fri, 2 Oct 2020 18:42:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 16:42:13 -0000 Gyan, On 02/10/2020 18:30, Gyan Mishra wrote: > All, > > With SRv6 and IP based flex algo a generic question as it applies to > both. Is it possible to have within a single IGP domain different sets > of nodes or segments of the network running different algorithms. absolutely. > From > both drafts it sounds like all nodes have to agree on same algorithm > similar to concept of metric and reference bandwidth all have to have > the same style metric and play to the same sheet of music. all participating nodes need to agree on the definition of the flex-algo and advertise the participation. That's it. > If there was > a way to use multiple algorithms simultaneously based on SFC or services > and instantiation of specific algorithm based on service to be > rendered.  Doing so without causing a routing loop or sub optimal > routing. you can certainly use multiple algorithms simultaneously and use algo specific paths to forward specific traffic over it. How that is done from the forwarding perspective depends in which forwarding plane you use. Flex-algo control plane is independent of the forwarding plane. >I thought with flex algo that there exists a feature that on > each hop there is a way to specify which algo to use hop by hop similar > to a hop by hop policy based routing. no, there is no hop-by-hop classification, that is problematic and does not scale for high speeds. Classification is done at the ingress only. thanks, Peter > From nobody Fri Oct 2 10:17:22 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EB13A1139; Fri, 2 Oct 2020 10:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=PN+EbaW8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nJlXQ5bU 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 Rf_IjjSpo7B1; Fri, 2 Oct 2020 10:17:19 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81723A11EC; Fri, 2 Oct 2020 10:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=846; q=dns/txt; s=iport; t=1601659034; x=1602868634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RGzGKbAH4QGnI5BbP/hZ4f+H0RJbpIFRXBw2vQ08+2M=; b=PN+EbaW88KKJ1/Lgr7YzllFkN0Eg47VqtS4mMPlBlujfxAyiyAVZ+2DA xDy1sawUJXUh8tradDGoi8bBoRYHPY1hAlKz8O3IkiLReucdJvUh4b450 eg6/98qz0hrBF1p6KOmAi5H8Pa9RgN52P2hg9frKoE5jWvPEYVYOjjSAt E=; IronPort-PHdr: =?us-ascii?q?9a23=3Ah+MuExan2RU4aFjLzFKMXzL/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD47b7OpckKzRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutbF3VumWpqzkIFU?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDEABCYHdf/5BdJa1gHQEBPAEFBQE?= =?us-ascii?q?CAQkBFYFRgVBRB3BZLywKhDODRgOmZ4JTA1ULAQEBDQEBIwoCBAEBhEoCF4I?= =?us-ascii?q?fAiU4EwIDAQELAQEFAQEBAgEGBG2FXAyFcwIBAxILBhEMAQE3AQ8CAQgODAI?= =?us-ascii?q?mAgICMBUQAgQBDQUigwQBgksDLgEOnlgCgTmIYXaBMoMBAQEFgUdBgxMYghA?= =?us-ascii?q?DBoEOKgGCcYNphlMbggCBECgcgk0+glwCAwGBW4MXM4Itkz6kFAqCZ4h+kWM?= =?us-ascii?q?DH4J8EooClA2SDQx6im6VJgIEAgQFAg4BAQWBayOBV3AVOyoBgj5QFwINkhC?= =?us-ascii?q?FFIVCdDcCBgEJAQEDCXyMOwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,328,1596499200"; d="scan'208";a="566308879" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Oct 2020 17:17:13 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 092HHDhV030701 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2020 17:17:13 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 2 Oct 2020 12:17:13 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 2 Oct 2020 13:17:12 -0400 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 2 Oct 2020 13:17:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oU8CmaCW00eVhDUNCnr98bDHuF4yEpNj0HKvaNn+TnTqT3Ax+OvfrnqkNeIpGPv7eNdVdwbbL5hH8hur06UWa/703gxffA2cLZcQCm1QjjgU12ttuORrPhdMgqu/bi1NEBVm+msrmGymD5CgczEoVmm7+RxW3sKbu08zi+Upava+B7Jz1I1JF/ByrG5OxxjGEzG+A8GWVz4m04qc9eMz88y4xLkdVXX9z9Lj2gK8CVzo1Zwe7i8FERYcjbNxPed4mFGkXizwXktI/Vhusi26aytQfwDV1VaPYMyJGonrOi4qbXkgh9Sj6ugINljSjhCMizV8iy47QIcjgChlGlbT6A== 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=RGzGKbAH4QGnI5BbP/hZ4f+H0RJbpIFRXBw2vQ08+2M=; b=S+09kFAvndcHH6nVMYQeqEfgMISxLzlvFVrTkCn0092N8MCMexRUFabT617/dCuhZNE32IjGA4wyG/76AlDydI5wVOLGCoFs6XXEJFaM4ci5ecl+LYthF93kCeVB/YIPH+m19a1z5WquZET1uDSD++ld8mGkisFzxvRr28+64TPDvd+WXI53nWS5Abj5c89fk215mnRBWYnES+xZtLNS6wNdmTxMokhD44A/6X6FpqkTpt0nr/tcmIfWq1JqcjeZhHIBMk0t7PsCu3SfDcNMWGhFDo89TpGqcpfsn9MNySAkKPuxZS8pULklWgXHQxXuYfIt4jdmhkJoCVYfsSmvzQ== 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=RGzGKbAH4QGnI5BbP/hZ4f+H0RJbpIFRXBw2vQ08+2M=; b=nJlXQ5bUG27w+FGfbnrh0jXUPaA1B/qsfqfw73EM1i3TTU65pZl624U0wDpy4CZB9o15h2CdCmHb4zjfOIVC9rTDcUVlS6N1mCjvS18ga6ugx+P6A1f8P7OVvEzYjD02BHstlH0kH8Qp88K0I9Bm3yLi69KKJKyfUsNH7g7yjsU= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB2742.namprd11.prod.outlook.com (2603:10b6:a02:c1::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Fri, 2 Oct 2020 17:17:10 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3433.039; Fri, 2 Oct 2020 17:17:10 +0000 From: "Acee Lindem (acee)" To: Christian Hopps , "lsr@ietf.org" CC: "lsr-chairs@ietf.org" , "draft-ketant-lsr-ospf-l2bundles.all@ietf.org" Thread-Topic: WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 Thread-Index: AQHWmLROhn60mItAckuZlw3AF7BykqmESz6A Date: Fri, 2 Oct 2020 17:17:10 +0000 Message-ID: <5D297116-F8BA-41F6-BBEA-04608ABABF50@cisco.com> References: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> In-Reply-To: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5aa26332-3651-4779-390c-08d866f6ff9f x-ms-traffictypediagnostic: BYAPR11MB2742: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JzBPR5CgNXaDrQBsVgjBbgVEIj8HgzP86RbvwvubrC8eVwkyJhAH/Vl4BxHcZ62+x4e4TClunfvsQh8g2OIbXT8ofOfy4qzpFFSSo7mq9DkMU8KxJuyUTkmbsmz05MXiRApnfplG7M4JPuDfn+/td/fmgQWhpcUT6MP279AnOpjHDcHbqvY9U8NY9S3X0Zns7Bq/vyHGdJ1BL5Ie42W7kvkRsDcD7qfJTWvAjcfGCK2SF+V6x+NAAIrkWMmsm/L3Nikc2KrU+R5/tMggigPur9msdunn1YjfYqb57ndWde46LhhPP1FTA8Lx0bwKyjZXfsTUZvNsMREvNy+JaNQzobB7jIawD3br2JTbimC/pXoSd85oVwp4QJmnbT1U54ttP7EI2CEF2SCtdhq+2u89Uw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(346002)(396003)(376002)(136003)(71200400001)(83080400001)(66446008)(66556008)(64756008)(54906003)(110136005)(66946007)(66476007)(26005)(316002)(76116006)(2906002)(36756003)(6506007)(2616005)(33656002)(6486002)(86362001)(6512007)(478600001)(4744005)(966005)(5660300002)(186003)(8936002)(4326008)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: vzmGZCv+iP2uwwQFFmz8Z/c1rbZ8mKEVAa9AsFUnsv2wCTrpACaafOrDL2o5VlCzH/IVl3j1HpG6vA8sdq3S3EekhWuoDI4xzy/c2PLCoBKQfKqbwnKMPJAXzOopvHu3PZBLvC15p775/yQA7ngo7Wz81hoOc+Ph4pvN3Jfmxt4KGA+h7elhQfrpC/OsWaTSLKigk3M14ZB8/+/79AEdKWYC8DnGImDGoqSYniw6GUbzO2ugb4jFxfYK4wJGZtJT42szODhN/6l3vom6XIRV9MgSm7iYsLDzPA7yBlqzXpI+79EJFo8lSDugwx7cf/bF3CbnIqZhXLbJfV91gdhuWutyyljEJLPWHoIixI9VKzoot7T7w6oL0Rk2IMSRnIhS9NCFBvKdfhcZfdDPtrP25YU3WfzmQ/YRoOwOjWUfBISVP1NphU4Nt3H30uhbcMNDwiIu8fhFgaqJqiDwM5ZRO7TwWh8tfbYGg1cttpnGhv/tjYVtRZmsphawZOTyWbPRDKp265haYTpTHECLPAQUueoj3bIZaLpAerGz8QLIgfvBjW29KKSDjdDzwFLDO29EQsuANMlcuPrebtr1Sbgsa3uq7iCHNo9bJ8Yf38kOvzvFecBnWwf74qvpy7/5R5i2+wxxEp3yW9+TM8IGWYQ/qg== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5aa26332-3651-4779-390c-08d866f6ff9f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 17:17:10.8258 (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: k4/Z0ijzjBZjkQxiSacfLChMLQDs8UZChvChsfxLhyaNCJtpLLESn5M9FZbG+nzj X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2742 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 17:17:21 -0000 U3BlYWtpbmcgYXMgV0cgbWVtYmVyOg0KIA0KSSBzdXBwb3J0IFdHIGFkb3B0aW9uIG9mIHRoaXMg ZG9jdW1lbnQuIEl0IGlzIG5lZWRlZCBmb3IgSVMtSVMgcGFyaXR5IGFuZCB0aGVyZSBhcmUgYWxy ZWFkeSBvdGhlciBub24tV0cgZG9jdW1lbnRzIHJlZmVyZW5jaW5nIGl0LiANCg0KVGhhbmtzLA0K QWNlZQ0KDQrvu79PbiAxMC8yLzIwLCA4OjA1IEFNLCAiQ2hyaXN0aWFuIEhvcHBzIiA8Y2hvcHBz QGNob3Bwcy5vcmc+IHdyb3RlOg0KDQogICAgVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgYWRvcHRp b24gY2FsbCBmb3IgdGhlIGZvbGxvd2luZyBkcmFmdDoNCg0KICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V0YW50LWxzci1vc3BmLWwyYnVuZGxlcy8NCg0KICAg IFBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9uIGJ5IE9jdG9iZXIgMTYs IDIwMjAuDQoNCiAgICBBdXRob3JzLCBwbGVhc2UgcmVzcG9uZCB0byB0aGUgbGlzdCBpbmRpY2F0 aW5nIHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlz IGRyYWZ0Lg0KDQogICAgVGhhbmtzLA0KICAgIENocmlzIGFuZCBBY2VlLg0KDQo= From nobody Fri Oct 2 10:41:56 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01373A165C for ; Fri, 2 Oct 2020 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 s74Qr8T9-Pg5 for ; Fri, 2 Oct 2020 10:41:54 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 DAA163A11F3 for ; Fri, 2 Oct 2020 10:41:53 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id q26so600407uaa.12 for ; Fri, 02 Oct 2020 10:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HEXEQfGznsKiNpZtnZESIy7StORgb3Z2mUzCtnDqTbA=; b=BOAakEirblnsqvLtSFUH3wPlqVe8xFEh8u8cnnOnDUEAPfVrW11dRN2U1aG4SisLQg DL7Tcuc+wA7149qEaOLIOJC2YeR7gON+woBU4kX4Y0b4IsaHshifE6ksIu05K/zIUUgv dMguNXxeJzpccj/+ZruEtdLdsVrXyt12iZrIYmcPmaR6bE51180em7zQrAnVGc6kcRWn gk2SuMjzxyWIp0d8nKyrjZ3Bh6bQSQDXg+5yFOUCDnsPxBQEl0ZEyfvblCPMozigM3h9 zHOvJECX3iKJqWPcu8OZXgDFHPzvnpy6FTDRCGt5weZD0NDdZGGXIAv/tA67We7xj4Rz K6MQ== 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=HEXEQfGznsKiNpZtnZESIy7StORgb3Z2mUzCtnDqTbA=; b=K+jT30VQFJGqrRc4lVlCr+owHf8xwT0jzvRizKj/mJI7Vqk3IOM1sFxH1LHAxvUtLv M6IJhzTCK28A/FWmn+d6Q8gIe6X1YBFQq6fiuhc8n3Mb3TwbY9Pa/vfiparN1b+5k1iq MXfyHVAnAEu8Bv19BtLS7lMu74J+YZ9BRt4XzxtWIvaUys2grHQAxN9baBqoRME8wwH0 umwVLAG8HSoBmKGlkpdxyhW4paTk/6/jMQDQsHrkU2RkH9khM/yD+pRqBDvCyf56ewRX ZKngp6lZPQkOr5TbGdZRuxiDM5id15JbO5BMPha41SmIKN3azHawdLIkIc0QmxG69rHq b8Ew== X-Gm-Message-State: AOAM531+IM3huBq/hlsPjiv3YCopVpivZFoophoLahIz8ggIPAck0rWE N9i0JkIW8RpD/0Oewi+2DV78xKk4L9LilBeHXNo= X-Google-Smtp-Source: ABdhPJzAA2eXyVeztE3fTN3DlAZkp5Crz+MLM/7UIVBvhTYyhdOCGH45IMl0dYHMtjfGMaWm+aBP29tkB7o8wBneUms= X-Received: by 2002:ab0:4e25:: with SMTP id g37mr1964927uah.106.1601660512677; Fri, 02 Oct 2020 10:41:52 -0700 (PDT) MIME-Version: 1.0 References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> In-Reply-To: From: Gyan Mishra Date: Fri, 2 Oct 2020 13:41:41 -0400 Message-ID: To: Peter Psenak Cc: Jeff Tantsura , Ron Bonica , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e8b62605b0b3a5ec" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 17:41:56 -0000 --000000000000e8b62605b0b3a5ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Peter! On Fri, Oct 2, 2020 at 12:42 PM Peter Psenak wrote: > Gyan, > > > > On 02/10/2020 18:30, Gyan Mishra wrote: > > > All, > > > > > > With SRv6 and IP based flex algo a generic question as it applies to > > > both. Is it possible to have within a single IGP domain different sets > > > of nodes or segments of the network running different algorithms. > > > > absolutely. Gyan> Great. As was noted on the thread that with SR-MPLS you can have multiple labels and each label bound to a different algorithm for a service prefix, however that is not possible with SRv6 as it=E2=80=99s a 1-1 bindin= g destination prefix to SRv6 sid. With SRv6 standard longest prefix matching can you also have different sets of nodes running different algorithms within the same domain. SRv6 has the advantage of LPM but SR-MPLS does seem to have an advantage of being able to have multiple algorithms tied to a label bound to the same FEC. That does seem to be an advantageous feature with SR-MPLS - MPLS data plane use of flex algo as compare to SRv6. > > > > > From > > > both drafts it sounds like all nodes have to agree on same algorithm > > > similar to concept of metric and reference bandwidth all have to have > > > the same style metric and play to the same sheet of music. > > > > all participating nodes need to agree on the definition of the flex-algo > > and advertise the participation. That's it. > Gyan> Trying to picture how it would work if you had let=E2=80=99s say = all nodes in a single IGP domain or MT instance running let=E2=80=99s say 2 dif= ferent algorithms simultaneously. Would it be like 2 different routing overlay IGP instances or ISIS MT instance or ospf process. Also would that work with just SR-MPLS or would that also work with SRv6? In the case where you have groups of nodes running a different algorithm the adjacent border nodes between the groupings would end up running multiple algorithms. So it can work and not issue with routing loops or sub optimal routing. > > > > > If there was > > > a way to use multiple algorithms simultaneously based on SFC or service= s > > > and instantiation of specific algorithm based on service to be > > > rendered. Doing so without causing a routing loop or sub optimal > > > routing. > > > > you can certainly use multiple algorithms simultaneously and use algo > > specific paths to forward specific traffic over it. How that is done > > from the forwarding perspective depends in which forwarding plane you > > use. Flex-algo control plane is independent of the forwarding plane. > > Gyan> Is there a flex algo use case draft? > > > > >I thought with flex algo that there exists a feature that on > > > each hop there is a way to specify which algo to use hop by hop similar > > > to a hop by hop policy based routing. > > > > no, there is no hop-by-hop classification, that is problematic and does > > not scale for high speeds. Classification is done at the ingress only. > > Gyan> Is the classification of interesting traffic base on QOS marking o= n > ingress to map to a specific flex algo for a particular service? > > thanks, > > Peter > > > > > > > > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000e8b62605b0b3a5ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Peter!

On Fri, Oct 2, 2020 at 1= 2:42 PM Peter Psenak <ppsenak@cisco= .com> wrote:
Gyan,



On 02/10= /2020 18:30, Gyan Mishra wrote:

> All,

>

> W= ith SRv6 and IP based flex algo a generic question as it applies to
> both. Is it possible to have within a single IGP domain different set= s

> of nodes or segments of the network running different algori= thms.=C2=A0



absolutely.

<= /div>
=C2=A0 =C2=A0Gyan> Great.=C2=A0 As was noted on t= he thread that with SR-MPLS you can have multiple labels and each label bou= nd to a different algorithm for a service prefix, however that is not possi= ble with SRv6 as it=E2=80=99s a 1-1 binding destination prefix to SRv6 sid.= =C2=A0 With SRv6 standard longest prefix matching =C2=A0can you =C2=A0also = have different sets of nodes running different algorithms within the same d= omain.=C2=A0 SRv6 has the advantage of LPM but SR-MPLS does seem to have an= advantage of being able to have multiple algorithms tied to a label bound = to the same FEC.=C2=A0 That does seem to be an advantageous feature with SR= -MPLS - MPLS data plane use of flex algo as compare to SRv6.



> From

> both drafts it soun= ds like all nodes have to agree on same algorithm

> similar to c= oncept of metric and reference bandwidth all have to have

> the = same style metric and play to the same sheet of music.



all p= articipating nodes need to agree on the definition of the flex-algo
and advertise the participation. That's it.
=C2=A0
=C2=A0 =C2=A0 Gyan> Trying to pi= cture how it would work if you had let=E2=80=99s say all nodes in a single = IGP domain or MT instance running let=E2=80=99s say 2 different algorithms = simultaneously.=C2=A0 Would it be like 2 different routing overlay IGP inst= ances or ISIS MT instance or ospf process.=C2=A0 Also would that work with = just SR-MPLS or would that also work with SRv6?=C2=A0 In the case where you= have groups of nodes running a different algorithm the adjacent border nod= es between the groupings would end up running multiple =C2=A0algorithms.=C2= =A0 So it can work and not issue with routing loops or sub optimal routing.=



> If there was

&= gt; a way to use multiple algorithms simultaneously based on SFC or service= s

> and instantiation of specific algorithm based on service to = be

> rendered.=C2=A0 Doing so without causing a routing loop or = sub optimal

> routing.=C2=A0



you can certainly u= se multiple algorithms simultaneously and use algo

specific paths t= o forward specific traffic over it. How that is done

from the forwa= rding perspective depends in which forwarding plane you

use. Flex-a= lgo control plane is independent of the forwarding plane.

Gyan> I= s there a flex algo use case draft?



>I thought with flex = algo that there exists a feature that on

> each hop there is a w= ay to specify which algo to use hop by hop similar

> to a hop by= hop policy based routing.



no, there is no hop-by-hop classi= fication, that is problematic and does

not scale for high speeds. C= lassification is done at the ingress only.

Gyan> =C2=A0Is the cla= ssification of interesting traffic base on QOS marking on ingress to map to= a specific flex algo for a particular service?

thanks,

Peter=



>



--


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver S= pring, MD


--000000000000e8b62605b0b3a5ec-- From nobody Fri Oct 2 13:15:51 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F983A16D1 for ; Fri, 2 Oct 2020 13:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 68Limbf5zT8q for ; Fri, 2 Oct 2020 13:15:48 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700119.outbound.protection.outlook.com [40.107.70.119]) (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 D58A83A16D4 for ; Fri, 2 Oct 2020 13:15:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fq69uQizGuC+vKI9B8mFiehoV6rRZbUSl2tEs1IihJuBpemoBnlRyCWLP91pfvDIWfEyuYmhURDsmcWfeEsijxctJaFRfhCT9pd2xqXCpOe8wG7LP5twgPjrpQgv0KNVIHCpZrLv1V70vtcGcp1KoSWQeL1XEDL9LBVIQorkESvaOu/jFc07MW99gL1Da+j0eXSwv76Mr6wDhp1KMrcJx2TxPvmy5oS50VGAOhUbxH3tmr0j8jXSkqXV9P8XMP9Bfpw25PBAu5nv87cui2N9bVVb39oj+SlUXI+rcUeuLK2eYuJbL2IV0uOPoExeAz9qwRaYBGtSTSXQzDtQBsjutg== 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=vYQ2h/ZreOYFs3PX/WFkELJ0ibuQ0DBmwbQG232yfSE=; b=I+cKvKgiW11QF25X/9a7cIUe20zMFWqjKRJ46v6fCeglRfjAlSYAEvJTVMnsOS9qkR7uNy2HgPiwEw8WrmCgX7bYHD1Nba2X3dKQl3h8q4gS+HBJxybN920WPZHnClKl9DtWGWw3mZtiQIguMmt9ie9My7+KC0VtbOLuw6/ZOG140H/34uEb+eTi9gwnb8MNbmxETAps2uJ/8jt+XEQPvjuGxQ8WhkeWuQYEmsVM7zwLkbMOHxlEE2wzMeAucZo0fDkB2sRuV3veiWS8lvlv4Jnjp7vg2R2XeJE476OholrNv6Lk90MZQ4qGsWOrQIrpkOVshlstAOmPJujNVbQREQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vYQ2h/ZreOYFs3PX/WFkELJ0ibuQ0DBmwbQG232yfSE=; b=G2J4MPCxL4jzIdSa/EkostZd0m9hdzZl8JR8R4/e0J5SOvlJ9ELXRVamf6ACsqCN4II/BRaO1E4PPyU+RM4jhOw/Gsd5bRofKn+qyMSdIt0P67GxnSrL4562iw9ev5nguKDOC0fdUjruzrwwPH6GZ+xqNy/nTdNjqRy0iLyzQfw= Received: from BY5PR13MB3048.namprd13.prod.outlook.com (2603:10b6:a03:188::21) by BY5PR13MB2949.namprd13.prod.outlook.com (2603:10b6:a03:18c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.13; Fri, 2 Oct 2020 20:15:44 +0000 Received: from BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::381e:6640:d3a3:5034]) by BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::381e:6640:d3a3:5034%5]) with mapi id 15.20.3455.013; Fri, 2 Oct 2020 20:15:44 +0000 From: Yingzhen Qu To: Peter Psenak , Gyan Mishra , Ron Bonica CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAGYiICAAB9mMIAA726AgADTSnCAAWzZgIAAAz2A///GWIA= Date: Fri, 2 Oct 2020 20:15:44 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:646:9500:c900:580:ac8a:4587:58a0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58ca46b7-82d9-4b62-1f41-08d8670ff161 x-ms-traffictypediagnostic: BY5PR13MB2949: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cNHf3ygpEw7qTxZoA4/v8or2EKsK4iUogNr08DVG5tFlZDNyRkL/2oEvq/YRmwHo+ncJO22LURfGDFkRDsUlcKzZCQlFt8Kxacf8g1HM1dGm8P1p6PxMui69Qsha3KPWGcfeGrVZCZBpKSkkaF8tjS5aoXuApMz9dO9nAv/lEL7CyFpE1bTQumd0q1WhkfEMhO9Z5tZRpm1gpTQnLr/FCZ7vr+rpj57McG00zHscnwJa+KvEwFkTTf0AqOzCu5SMBbhopYJPE7as+5s+29Hi17sDaJqULpIOCLOZu9NEN/3wH8KvjH/ZWveVrnUNPDFs7PoAIHbWzm219XgvgLWI5lesJ3zK4l4R/oAQM0UDBrcfOo0EigobbDLpvNM2RwKuvjL6QC9jmbcCJywrGZvEoQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3048.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(366004)(136003)(346002)(39840400004)(33656002)(8936002)(44832011)(71200400001)(83080400001)(86362001)(316002)(8676002)(966005)(2616005)(6486002)(2906002)(53546011)(478600001)(45080400002)(186003)(5660300002)(66556008)(54906003)(66446008)(66476007)(6506007)(6512007)(36756003)(110136005)(66946007)(64756008)(4326008)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 5mEMpR6nTXFoTpzmR2+fxgbSmZ07v639w4+mNn8W7fQetCakA52KldX09rDHifU3I077meKDlQ/2i64T47OVfzrpo2Cp4VGbz0ARBQNs8VzzPbTnGdQLYFq6kXmpL5Va2TQOE+MRV9amMMjImaI6HoKcJqae1Yzp7zhCAhZlrBt5y4yzgHOE9XjBXdIpOyXJIzr1eNwjOfmbgsvp9pYJFavZe+WPgWCNhn3D7ODTbbdF5Bhl/7A0ycJ5HgDSVUvzrUFpK5PcgUobF9vWUUsEtwg/sEuoyvy/KVC5ufsvGQ7kLz5Lnesn7GQgXtOmRzvxTXTMaFSHH4RACGqZs6e2eONRLsbd6NPAd06NKNKoP6bC6gRan8Lkxq63nM7gRagFQPtVDVW3mM7GeScGMth84ojtSzn88DnFeD85eKIKGC0T3T/a+9i6ArXrRlWYHPqf7coeGrFRNQBStweCdhTnRLxSNPAlKroSvTHn9DLTV7OYkoaDHUUg4xBDnZPZdDeze9cY+fdqHptHGbt6aLgHJs8/6F+xSjVgEac2yJa4lJ85qVfoWu8ydQAevX0Jo7G61cg0coqYHXB3isqAHgo3bcgOGweJqFyE1QtWG9gSXQ3onSTxlPBcTXSp4GdiylLlc/xju5lG2jpeS8Bnij92u1l88AdXd00DSrpzNnnKfs1YwsOEmKO9XiaoqzQoWE9J1fh0plPlwTvUw8/d/3K/vg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <74FCE0C392F68844B893B2404C5EC37C@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3048.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58ca46b7-82d9-4b62-1f41-08d8670ff161 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 20:15:44.3760 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1IFNCc8ZTuLsgyXZIm5k1MBNTm4b9g1PjbjdzSK2qSVbbGo7mhXbcoS9SHHZnSHcnMiESkyualGUPoWm1lmGLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB2949 Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 20:15:49 -0000 SGkgUGV0ZXIsDQoNCk15IHVuZGVyc3RhbmRpbmcgb2YgZmxleC1hbGdvIGlzIHRoYXQgZm9yIHRy YWZmaWMgZGVzdGluZWQgdG8gYSBwcmVmaXggb24gYSBwYXJ0aWN1bGFyIGFsZ28sIGl0IGNhbiBv bmx5IGJlIHJvdXRlZCBvbiByb3V0ZXJzIGJlbG9uZyB0byB0aGF0IGFsZ28sIHdoaWNoIGFsc28g bWVhbnMgb25seSByb3V0ZXJzIGluIHRoYXQgYWxnbyBjYWxjdWxhdGVzIGhvdyB0byByZWFjaCB0 aGF0IHByZWZpeCBhbmQgaW5zdGFsbCBpdCBpbnRvIHRoZSByb3V0aW5nIHRhYmxlLiBJdCBzZWVt cyB0byBtZSB0aGF0IHVzaW5nIGZsZXgtYWxnbyAoc2VjdGlvbiAxMiBvZiB0aGUgZHJhZnQpIGl0 J3MgcG9zc2libGUgdG8gaGF2ZSBhIGxvb3BiYWNrIGFkZHJlc3MgYXNzb2NpYXRlZCB3aXRoIG9u bHkgb25lIGFsZ28sIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEknbSBtaXNzaW5nIG9yIG1pc3VuZGVy c3Rvb2Qgc29tZXRoaW5nLg0KDQpUaGFua3MsDQpZaW5nemhlbg0KDQrvu79PbiAxMC8yLzIwLCA5 OjQzIEFNLCAiTHNyIG9uIGJlaGFsZiBvZiBQZXRlciBQc2VuYWsiIDxsc3ItYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgcHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3Jv dGU6DQoNCiAgICBHeWFuLA0KDQogICAgT24gMDIvMTAvMjAyMCAxODozMCwgR3lhbiBNaXNocmEg d3JvdGU6DQogICAgPiBBbGwsDQogICAgPiANCiAgICA+IFdpdGggU1J2NiBhbmQgSVAgYmFzZWQg ZmxleCBhbGdvIGEgZ2VuZXJpYyBxdWVzdGlvbiBhcyBpdCBhcHBsaWVzIHRvIA0KICAgID4gYm90 aC4gSXMgaXQgcG9zc2libGUgdG8gaGF2ZSB3aXRoaW4gYSBzaW5nbGUgSUdQIGRvbWFpbiBkaWZm ZXJlbnQgc2V0cyANCiAgICA+IG9mIG5vZGVzIG9yIHNlZ21lbnRzIG9mIHRoZSBuZXR3b3JrIHJ1 bm5pbmcgZGlmZmVyZW50IGFsZ29yaXRobXMuICANCg0KICAgIGFic29sdXRlbHkuDQoNCiAgICA+ IEZyb20gDQogICAgPiBib3RoIGRyYWZ0cyBpdCBzb3VuZHMgbGlrZSBhbGwgbm9kZXMgaGF2ZSB0 byBhZ3JlZSBvbiBzYW1lIGFsZ29yaXRobSANCiAgICA+IHNpbWlsYXIgdG8gY29uY2VwdCBvZiBt ZXRyaWMgYW5kIHJlZmVyZW5jZSBiYW5kd2lkdGggYWxsIGhhdmUgdG8gaGF2ZSANCiAgICA+IHRo ZSBzYW1lIHN0eWxlIG1ldHJpYyBhbmQgcGxheSB0byB0aGUgc2FtZSBzaGVldCBvZiBtdXNpYy4N Cg0KICAgIGFsbCBwYXJ0aWNpcGF0aW5nIG5vZGVzIG5lZWQgdG8gYWdyZWUgb24gdGhlIGRlZmlu aXRpb24gb2YgdGhlIGZsZXgtYWxnbyANCiAgICBhbmQgYWR2ZXJ0aXNlIHRoZSBwYXJ0aWNpcGF0 aW9uLiBUaGF0J3MgaXQuDQoNCiAgICA+IElmIHRoZXJlIHdhcyANCiAgICA+IGEgd2F5IHRvIHVz ZSBtdWx0aXBsZSBhbGdvcml0aG1zIHNpbXVsdGFuZW91c2x5IGJhc2VkIG9uIFNGQyBvciBzZXJ2 aWNlcyANCiAgICA+IGFuZCBpbnN0YW50aWF0aW9uIG9mIHNwZWNpZmljIGFsZ29yaXRobSBiYXNl ZCBvbiBzZXJ2aWNlIHRvIGJlIA0KICAgID4gcmVuZGVyZWQuICBEb2luZyBzbyB3aXRob3V0IGNh dXNpbmcgYSByb3V0aW5nIGxvb3Agb3Igc3ViIG9wdGltYWwgDQogICAgPiByb3V0aW5nLiAgDQoN CiAgICB5b3UgY2FuIGNlcnRhaW5seSB1c2UgbXVsdGlwbGUgYWxnb3JpdGhtcyBzaW11bHRhbmVv dXNseSBhbmQgdXNlIGFsZ28gDQogICAgc3BlY2lmaWMgcGF0aHMgdG8gZm9yd2FyZCBzcGVjaWZp YyB0cmFmZmljIG92ZXIgaXQuIEhvdyB0aGF0IGlzIGRvbmUgDQogICAgZnJvbSB0aGUgZm9yd2Fy ZGluZyBwZXJzcGVjdGl2ZSBkZXBlbmRzIGluIHdoaWNoIGZvcndhcmRpbmcgcGxhbmUgeW91IA0K ICAgIHVzZS4gRmxleC1hbGdvIGNvbnRyb2wgcGxhbmUgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIGZv cndhcmRpbmcgcGxhbmUuDQoNCg0KICAgID5JIHRob3VnaHQgd2l0aCBmbGV4IGFsZ28gdGhhdCB0 aGVyZSBleGlzdHMgYSBmZWF0dXJlIHRoYXQgb24gDQogICAgPiBlYWNoIGhvcCB0aGVyZSBpcyBh IHdheSB0byBzcGVjaWZ5IHdoaWNoIGFsZ28gdG8gdXNlIGhvcCBieSBob3Agc2ltaWxhciANCiAg ICA+IHRvIGEgaG9wIGJ5IGhvcCBwb2xpY3kgYmFzZWQgcm91dGluZy4NCg0KICAgIG5vLCB0aGVy ZSBpcyBubyBob3AtYnktaG9wIGNsYXNzaWZpY2F0aW9uLCB0aGF0IGlzIHByb2JsZW1hdGljIGFu ZCBkb2VzIA0KICAgIG5vdCBzY2FsZSBmb3IgaGlnaCBzcGVlZHMuIENsYXNzaWZpY2F0aW9uIGlz IGRvbmUgYXQgdGhlIGluZ3Jlc3Mgb25seS4NCg0KICAgIHRoYW5rcywNCiAgICBQZXRlcg0KDQog ICAgPiANCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgTHNyIG1haWxpbmcgbGlzdA0KICAgIExzckBpZXRmLm9yZw0KICAgIGh0dHBzOi8v bmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRmxzciZhbXA7ZGF0YT0wMiU3QzAx JTdDeWluZ3poZW4ucXUlNDBmdXR1cmV3ZWkuY29tJTdDNTFkZDk0MGFiMjVkNGVhMTliMWIwOGQ4 NjZmMjNiNmElN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3 MzcyNTM3ODY5Mjk2ODg3JmFtcDtzZGF0YT1SJTJGSSUyQkFVa2N3MTJGbWdEdHNoJTJGQk9MN3pM alBGJTJCd3dScHF3bkUyTmR2JTJGZyUzRCZhbXA7cmVzZXJ2ZWQ9MA0KDQo= From nobody Fri Oct 2 15:04:19 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C283A1702; Fri, 2 Oct 2020 15:04:18 -0700 (PDT) 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 VeL0mIbVuxnO; Fri, 2 Oct 2020 15:04:16 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E773A1701; Fri, 2 Oct 2020 15:04:16 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id q18so1716091pgk.7; Fri, 02 Oct 2020 15:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=GTEmbc64CKxV66XRu4mPg593MzdnsQbwRzVs11iNGZ8=; b=fl3XFp9vdz99HZpKwMczCUoIaL7h2ClZlJZYUjpOGn3x49JvgpvQL4oHLe++xSdzvu vXwXbJtMYnL7mG9MjpUDfCgxcr6xY5+L66nS/wkuKgbH4yMAHJrkQjnXFEVQe2I1yT+r nEntM+qc20NEHSxWtxMVLXJ0eonIJpagsF9+SC5NE5+quDVRKioWuNb3RBUP/roFOHuG UiiF7W+d6bDyyrC8iKpobL4fFyS5dYDbBB+EmzQRciX8kWIitzdFxmm7EoN1JCAY1fm3 2wd13jn7RdtqyUy56EyM59idpsrE2bCIBkn20GU1zMEi/PRaaR0IapfFQEuUSByBX2I+ CGiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=GTEmbc64CKxV66XRu4mPg593MzdnsQbwRzVs11iNGZ8=; b=CGm3ppYkSkux6pJp+2ITRb/KQYBjriyUt93VSZaMLRMti/96m2IZgL1XZy3s9ks5e5 CrDYxt7e1BHsJg7UMgBZP/PXXXeCO6gwh2fFMui26S/J1gX0ngFMRJnmmQ/9Q7Ircjis o6QJXe79T/se1hdBRQyB/39p/fn9vfRz3QS/hUSNQjAJHy5Z7MorODZq7Q06/H60j852 /wGIiyDBcLs2DlHXXFjwqkimiJwnIwEDA1SaL+OlK36PqybVQJxL8ffZBNxwfiUf3aSE Gf/VmGjQCXONSFlvZozP20e6qzFWsQYxfFDFwtNHmyitZ7MeOVSDikJZyg0/4xMH4ONw a6sA== X-Gm-Message-State: AOAM531yuyc5AYDymKAAWIrT3PxQR8PBBh9ixZ0jJIiNF+QMbWkljfJx jxTx16bUynBM6MvpVqUxRYiW7CNKF70= X-Google-Smtp-Source: ABdhPJweoSkZkMiW2OzjgtgnQwCNGsPDblC8SmrJc9k3+FATTdR+wfGd5/vT5gCfY1Kh3fxYKl66hQ== X-Received: by 2002:a62:7743:0:b029:13c:1611:658e with SMTP id s64-20020a6277430000b029013c1611658emr4787234pfc.11.1601676255920; Fri, 02 Oct 2020 15:04:15 -0700 (PDT) Received: from [192.168.1.14] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id 72sm3052481pfx.79.2020.10.02.15.04.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 15:04:15 -0700 (PDT) Date: Fri, 2 Oct 2020 15:04:06 -0700 From: Jeff Tantsura To: lsr@ietf.org, Christian Hopps Cc: lsr-chairs@ietf.org, draft-ketant-lsr-ospf-l2bundles.all@ietf.org Message-ID: <8c9fa689-d04e-4ca4-a71c-30962e27879a@Spark> In-Reply-To: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> References: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> X-Readdle-Message-ID: 8c9fa689-d04e-4ca4-a71c-30962e27879a@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f77a3de_74b0dc51_6469" Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 22:04:18 -0000 --5f77a3de_74b0dc51_6469 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline yes/support Cheers, Jeff On Oct 2, 2020, 5:03 AM -0700, Christian Hopps , wrote: > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ > > Please indicate your support or objection by October 16, 2020. > > Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft. > > Thanks, > Chris and Acee. > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr --5f77a3de_74b0dc51_6469 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
yes/support

Cheers,
Jeff
On Oct 2, 2020, 5:03 AM -0700, Chri= stian Hopps <chopps=40chopps.org>, wrote:
This begins a 2 week WG adoption call for the following draft:<= br />
https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/

Please indicate your support or objection by October 16, 2020.

Authors, please respond to the list indicating whether you are aware of a= ny IPR that applies to this draft.

Thanks,
Chris and Acee.

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Lsr mailing list
Lsr=40ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--5f77a3de_74b0dc51_6469-- From nobody Fri Oct 2 15:11:26 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973753A0963; Fri, 2 Oct 2020 15:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=EO7fXoZ3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CZMNNLpO 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 mLpVwPp7NrVU; Fri, 2 Oct 2020 15:11:22 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6403A095D; Fri, 2 Oct 2020 15:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=856; q=dns/txt; s=iport; t=1601676682; x=1602886282; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=d2sRP3K1G9qNMpOxbMw+Wo1iCB8g8uGUXHkrwOJvUAA=; b=EO7fXoZ3IIA4aWmB3Zx6glEtjBTquAOcYWTCjEp1N0yT3FzucyQpampJ lWly/GEEae8DP8mfHnikhshcL0vPx+tjQ3EuTh7QHenaaIg2mSO9BVzzs ZcjhAcYksDsO1bUZZ4LXkJK6sAhCUeU0vXXwXBGD2o+T8Pn5UpUdtR280 k=; IronPort-PHdr: =?us-ascii?q?9a23=3AGT0/AxZig7yepz9GWuY95Yf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD47b7OpckKzRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutbF3VumWpqzkIFU?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLIQBXpHdf/4YNJK1gHAEBATwBAQQ?= =?us-ascii?q?EAQECAQEHAQEVgVGBPAIBEVEHcFkvLIgDA41vmHeCUwNVCwEBAQ0BASMKAgQ?= =?us-ascii?q?BAYRKAoI2AiU4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDEgsdBgEBNwE?= =?us-ascii?q?LBAIBCA4DBAEBHxAyHQgCBAENBQgagwWCSwMuAQ6eeAKBOYhhdIE0gwEBAQW?= =?us-ascii?q?BR0GDExiCEAMGgTYCAQEBgm+KPxuBQT+BEESCTT6CXAIDAYFdJIMkgi23Ugq?= =?us-ascii?q?CZ4h+kgWDDooClA2SDQx6im6VJgIEAgQFAg4BAQWBayOBV3AVO4JpUBcCDZI?= =?us-ascii?q?QhRSFQnQ3AgYKAQEDCXyNTAEB?= X-IronPort-AV: E=Sophos;i="5.77,329,1596499200"; d="scan'208";a="566467319" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Oct 2020 22:11:21 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 092MBLSq020515 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2020 22:11:21 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 2 Oct 2020 17:11:21 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 2 Oct 2020 17:11:20 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 2 Oct 2020 17:11:20 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a84wRBeJ4wdGhtWDxxytB8c3hg2QsST3xVfxVKLk9RYFos6hXdHaI6PYf6PD5HtrwoKpBZ/u7eUBgGdW2UOBOKplxEhPYvDd/1Ayl+yKZkUqcmBtJ/tstUrrOl4jIkfSl3zNYu5iTyzLNHRsENKVl5JvyjpouY1+Get8yhN3RmMmUtmNjS4D5YV9fR38nIvywOGulDnnx1t1qIvxVE95OpKDnDiOuxOXTExiAvfaON7OABpv/Zu50h7bz6LMluavLh5cajTUVru0SqeyZyiZDhAbBa+MWTU/FyXM6ftkSQcAbLEW9LrAvLUdv7UoY6ZJwDPjP4C5e176f1iRgacccg== 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=OfytKvR1dwFQLYIDOWv7aLdkwuqb2Ewoe+9UjtcexRw=; b=m4mgAMh42nuHCwzu/bzP9tbj1xlUlBv5rqglK4SGtYdrdarP7zdQcNb2oQ7xzh1P84FsawZmuDdwZjJLhl8pRPsP7XbJJ2nqMWxEymEY0M6MqLfnq5V9OQYCgDN8PglQs9inA1sUr1A1VE/vHjolqXw9bBUZ4ys9+KjRxGt6hNeCj/91xLF5N21CsXoNZ5+rj79VYZvURnOff7UzCoaANFnh8Y1OcwlV861yk8gztkICnsF0Bhpc8RDDNuL+AS+qA5AOxC0fIVuYk3J5/0FWeAYUnbf1QYX+TBXYO0zOUl8kxajGyvAX2Iu1qqSXx4o4NxWkADhVTMHXDQNjlfpXRw== 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=OfytKvR1dwFQLYIDOWv7aLdkwuqb2Ewoe+9UjtcexRw=; b=CZMNNLpOe46HBBtrev5OKvNPPppZBCYn0hI60x3vfPbCUzwVHE0MkT7ofCNeMhrec9q6H4474VQG9joA+AdBnWuQvKxa/UzNqh65VoNlCLUJh5dO/vzKUbCLMsqaBH2GMuFpPAjeAY9rYM6kENkkPF0CTiKXND1FA60ZBBYsBJE= Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB3461.namprd11.prod.outlook.com (2603:10b6:a03:7b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.37; Fri, 2 Oct 2020 22:11:19 +0000 Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf%3]) with mapi id 15.20.3412.029; Fri, 2 Oct 2020 22:11:19 +0000 From: "Les Ginsberg (ginsberg)" To: Christian Hopps , "lsr@ietf.org" CC: "lsr-chairs@ietf.org" , "draft-ketant-lsr-ospf-l2bundles.all@ietf.org" Thread-Topic: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 Thread-Index: AQHWmLRSpbvGVkD8cUypKXaTdlETP6mE38/g Date: Fri, 2 Oct 2020 22:11:19 +0000 Message-ID: References: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> In-Reply-To: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2602:306:36ca:6640:3cd7:8618:5ab0:b1d5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0c711edf-44ca-47d1-5992-08d867201725 x-ms-traffictypediagnostic: BYAPR11MB3461: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eP0EvLWNo4k774nOF0/mhZzFqwTHBLZVqPYWdta6KpELv7Sk7oHJCfNOZbZXC3oF2nSC1/OoMcURbU1uWW40q89RK2+q78Zs+xsuJ/3LhNWOwqFLVQx3BuxRwWmdHIfPh+ScuL3Q2b7KKiHAS0FyT92w9y6vXuQMH0IU9WbQk8zey5AjHJytwy0r1zsYpGB2CZMdBwMv7AxXhT8xcDHgIzbq91IdM8If6NHnFAAveJLfn8641fa0Dzof2fM/HoIiNUTqv+f8x6pg+dou6r2KnOtA+IAjnYYOka2XhvuWi7QAqV0ZqfqDwzTbd8MmJbVl6TqP3kdSgHyq7/RYvUSjETQjrQ1dhiZHuYwulgz/QrF/VzWmQ5KspyWiuyWjfi+a0f2pb85LwqX+saL0vDgxMw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(376002)(136003)(39860400002)(346002)(76116006)(66476007)(66946007)(64756008)(33656002)(6506007)(966005)(53546011)(86362001)(8936002)(478600001)(9686003)(186003)(66556008)(83380400001)(83080400001)(2906002)(8676002)(54906003)(52536014)(4326008)(55016002)(316002)(4744005)(5660300002)(7696005)(71200400001)(110136005)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WXFWEYFi0CumKbxIy22/XkU6gfuCAVp4xASxbQsRuKzi99x1b0HlMugfRKgE6b8cbO+eqJ2Rpy9mfNLTntaDp+VrOvvEg/0Fa1v6ISRYk4YDAq4Sg7Fp2BeumAlsxXDHvJVrjiSjPz0/Rj5I5kAd3JLzC4dvUTjvoGDQmh0pAPui4HE4wm7zWhp4nav7Yyhcl0Ox/ZrxEjqgpdgjhG+8KWxQL5um47NUA8QPZ1vo+bkR4k4gD6jd8Qm0FT6nbWhddW0VLbp3iPYwmv0eZcVmrRzhRnzNor/fd06stcHX0vfOcgiLJ2Af7AvjYfOfySfyvGLTFuzu1VqqJhYDcax4ZOqsUdVjgtQLbq5gY/3imj5ox7n43r9y88I1e0kdiEEe8BaMC2M7D7cIdVFH45rdD/5IGCbOZE2Xyu5XdaJgb0pxZvkhhUNZ82d+cdg35NqHACUY0zfo6zujiMeVO0do8QtgyzHezYK5pqcn74gYsrvSIez9ReOh6vBlLx4W1ijUT3HneaDcnnbZga5G8w4xBNQcpT3U3GiYNiKJdYFYwqV6V3zgySJ9Lq3tSu/+0jjPcDurfqHLKhJO1ptppTkg4Ig63fskbFiJyCWTRut66NijUkdCsdlUip4GKjuhzMDvBM8vSja487048dw5gr5bqdY58t58iEdzOBAzYLztt4U2LIPKR0v7TDKW18vP1svwtDec6FjO/lP2wGpvCgi4eQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c711edf-44ca-47d1-5992-08d867201725 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 22:11:19.6554 (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: mN+lTa0KPKHeHEAMaA1/4ecF9LUcD4DVysFCQK/TSnxsom5Y66jhPrWe2NujBAJttTUkSHwLdUBf/IYi8qURcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3461 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 22:11:25 -0000 I support WG adoption of this draft. OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668. Les > -----Original Message----- > From: Lsr On Behalf Of Christian Hopps > Sent: Friday, October 02, 2020 5:03 AM > To: lsr@ietf.org > Cc: lsr-chairs@ietf.org; Christian Hopps ; draft-ketan= t- > lsr-ospf-l2bundles.all@ietf.org > Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 >=20 > This begins a 2 week WG adoption call for the following draft: >=20 > https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ >=20 > Please indicate your support or objection by October 16, 2020. >=20 > Authors, please respond to the list indicating whether you are aware of a= ny > IPR that applies to this draft. >=20 > Thanks, > Chris and Acee. From nobody Fri Oct 2 15:25:43 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88B23A1707 for ; Fri, 2 Oct 2020 15:25:40 -0700 (PDT) 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 eeDe_kxx29zh for ; Fri, 2 Oct 2020 15:25:39 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 EF2A93A1704 for ; Fri, 2 Oct 2020 15:25:38 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id q4so1877157pjh.5 for ; Fri, 02 Oct 2020 15:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=e7H0WVZgVY3ROJH7xTYz1wyaUZKZzU+KsEyPodNnPVg=; b=dK+NwI9I+FOkpN0wPS/5aikcRSf3nGZmIdnRzNrMOqs0KBfXw31Yt2GMXcuX4ZhgJ4 nGQKoxBQEafU6LF8HTsSNm77LAMSo7L4NgffFtWTUZRFFZhpDOw8ej0BNjhlgc3GGZnC yfry5/UIL2va6zwDtrv8nb2U7gtjcL60joAn/V9cLqGeKapsVGrcVRd30rHP3JaGU+5r e+bjC8sRpENL7V0lpNDIdZ660uqe4RLpduFvExc/hLUfRXSRbN+EUWghvIWUlF82EZH4 0YZqQ6ilER3CZjhImnidvLm35kz60dZofC2RCUEMp/2S5PaGDj3qtI3MjGySm1IAD7QU 4VbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=e7H0WVZgVY3ROJH7xTYz1wyaUZKZzU+KsEyPodNnPVg=; b=phaWzkpIlGZNiHHSxOimlmp2S1QZyib/d/1qAzVSaRryUCuFxPvCbEQJhSpv6b8FjW W2jR+h/G34JGbA3D+iBcjAR/9dAlsITCTJb/a4Njqu0eh4Gy+tPfqfY7buV+3J1tg8px tsJ/AzcNlMP6/WHi2E3TwXWMvi6PIi5XIA3nhEoEtXyyuRy339IxwZiCN9hmWewgVApW uB1j4UWng2Uj8gS47OE+xWlNbMX61ZpPPYxIlqjqwi2tBYqS+f0FBaRZonVykp5dk7GA lYPpgv83reWgiYjAXPbJ9R8yNdO2eTRHYghWK2oYkcAnVuPufrmVqFstnoYoIYIvYhob 9k0g== X-Gm-Message-State: AOAM533+v2tuKBMMDeLCUyde9nIoevwXtKCSev5B6wUE2POgQhEqvP8b MmUwarEV9KTJ/T3FGSY/NAk= X-Google-Smtp-Source: ABdhPJyuxp2Eru4ecQEadzB3pKk1ZxJFLpWULXpku2L86BwzH4BSi11L0O7wAE24Zbtn9u3IklSAAw== X-Received: by 2002:a17:90a:4b45:: with SMTP id o5mr4967584pjl.226.1601677538083; Fri, 02 Oct 2020 15:25:38 -0700 (PDT) Received: from [192.168.1.14] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id a1sm2569934pjh.2.2020.10.02.15.25.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 15:25:37 -0700 (PDT) Date: Fri, 2 Oct 2020 15:25:31 -0700 From: Jeff Tantsura To: Peter Psenak , Gyan Mishra , Ron Bonica , Yingzhen Qu Cc: "=?utf-8?Q?lsr=40ietf.org?=" Message-ID: In-Reply-To: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> X-Readdle-Message-ID: cfae6af4-23d0-44b0-8bb3-f5e631b4c805@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f77a8e0_7c83e458_6469" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 22:25:41 -0000 --5f77a8e0_7c83e458_6469 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Yingzhen, Yes, that=E2=80=99s the case.=C2=A0=C2=A0The most important property of a= n algo computed path is that is has to be consecutive, as either SID or I= P address associated with a particular topology is only known within that= topology. Looking specifically at Ron=E2=80=99s draft (MPLS could be more complex d= ue to potential hierarchy) - the prefix itself defines the context(topolo= gy) and must be globally unique, since IPv4 header can=E2=80=99t have any= additional meta-data attached. Cheers, Jeff On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu ,= wrote: > Hi Peter, > > My understanding of flex-algo is that for traffic destined to a prefix = on a particular algo, it can only be routed on routers belong to that alg= o, which also means only routers in that algo calculates how to reach tha= t prefix and install it into the routing table. It seems to me that using= flex-algo (section 12 of the draft) it's possible to have a loopback add= ress associated with only one algo, please correct me if I'm missing or m= isunderstood something. > > Thanks, > Yingzhen > > On 10/2/20, 9:43 AM, =22Lsr on behalf of Peter Psenak=22 wrote: > > Gyan, > > On 02/10/2020 18:30, Gyan Mishra wrote: > > All, > > > > With SRv6 and IP based flex algo a generic question as it applies to > > both. Is it possible to have within a single IGP domain different set= s > > of nodes or segments of the network running different algorithms. > > absolutely. > > > =46rom > > both drafts it sounds like all nodes have to agree on same algorithm > > similar to concept of metric and reference bandwidth all have to have= > > the same style metric and play to the same sheet of music. > > all participating nodes need to agree on the definition of the flex-alg= o > and advertise the participation. That's it. > > > If there was > > a way to use multiple algorithms simultaneously based on S=46C or ser= vices > > and instantiation of specific algorithm based on service to be > > rendered. Doing so without causing a routing loop or sub optimal > > routing. > > you can certainly use multiple algorithms simultaneously and use algo > specific paths to forward specific traffic over it. How that is done > from the forwarding perspective depends in which forwarding plane you > use. =46lex-algo control plane is independent of the forwarding plane. > > > > I thought with flex algo that there exists a feature that on > > each hop there is a way to specify which algo to use hop by hop simil= ar > > to a hop by hop policy based routing. > > no, there is no hop-by-hop classification, that is problematic and does= > not scale for high speeds. Classification is done at the ingress only. > > thanks, > Peter > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Lsr mailing list > Lsr=40ietf.org > https://nam11.safelinks.protection.outlook.com/=3Furl=3Dhttps%3A%2=46%2= =46www.ietf.org%2=46mailman%2=46listinfo%2=46lsr&data=3D02%7C01%7Cyin= gzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b= 240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=3DR%2=46I%2B= AUkcw12=46mgDtsh%2=46BOL7zLjP=46%2BwwRpqwnE2Ndv%2=46g%3D&reserved=3D0= > --5f77a8e0_7c83e458_6469 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Yingzhen,

Yes, that=E2=80=99s the case.&=23160;&=23160;The most important property = of an algo computed path is that is has to be consecutive, as either SID = or IP address associated with a particular topology is only known within = that topology.&=23160;
Looking specifically at Ron=E2=80=99s draft (MPLS could be more complex d= ue to potential hierarchy) - the prefix itself defines the context(topolo= gy) and must be globally unique, since IPv4 header can=E2=80=99t have any= additional meta-data attached.&=23160;&=23160;

Cheers,
Jeff
On Oct 2, 2020, 1:15 PM -0700, Ying= zhen Qu <yingzhen.qu=40futurewei.com>, wrote:
Hi Peter,

My understanding of flex-algo is that for traffic destined to a prefix on= a particular algo, it can only be routed on routers belong to that algo,= which also means only routers in that algo calculates how to reach that = prefix and install it into the routing table. It seems to me that using f= lex-algo (section 12 of the draft) it's possible to have a loopback addre= ss associated with only one algo, please correct me if I'm missing or mis= understood something.

Thanks,
Yingzhen

=EF=BB=BFOn 10/2/20, 9:43 AM, =22Lsr on behalf of Peter Psenak=22 <lsr= -bounces=40ietf.org on behalf of ppsenak=3D40cisco.com=40dmarc.ietf.org&g= t; wrote:

Gyan,

On 02/10/2020 18:30, Gyan Mishra wrote:
All,

With SRv6 and IP based flex algo a generic question as it applies to
both. Is it possible to have within a single IGP domain different sets of nodes or segments of the network running different algorithms.

absolutely.

=46rom
both drafts it sounds like all nodes have to agree on same algorithm
similar to concept of metric and reference bandwidth all have to have
the same style metric and play to the same sheet of music.

all participating nodes need to agree on the definition of the flex-algo<= br /> and advertise the participation. That's it.

If there was
a way to use multiple algorithms simultaneously based on S=46C or service= s
and instantiation of specific algorithm based on service to be
rendered. Doing so without causing a routing loop or sub optimal
routing.

you can certainly use multiple algorithms simultaneously and use algo
specific paths to forward specific traffic over it. How that is done
from the forwarding perspective depends in which forwarding plane you
use. =46lex-algo control plane is independent of the forwarding plane.

I thought with flex algo that there exists = a feature that on
each hop there is a way to specify which algo to use hop by hop similar to a hop by hop policy based routing.

no, there is no hop-by-hop classification, that is problematic and does not scale for high speeds. Classification is done at the ingress only.
thanks,
Peter



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Lsr mailing list
Lsr=40ietf.org
https://nam11.safelinks.protection.outlook.com/=3Furl=3Dhttps%3A%2=46%2=46= www.ietf.org%2=46mailman%2=46listinfo%2=46lsr&amp;data=3D02%7C01%7Cyi= ngzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3= b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&amp;sdata=3DR%2=46= I%2BAUkcw12=46mgDtsh%2=46BOL7zLjP=46%2BwwRpqwnE2Ndv%2=46g%3D&amp;rese= rved=3D0

--5f77a8e0_7c83e458_6469-- From nobody Fri Oct 2 15:37:10 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDDA3A1710; Fri, 2 Oct 2020 15:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vFvteilNiDqS; Fri, 2 Oct 2020 15:37:07 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 6F5E43A170B; Fri, 2 Oct 2020 15:37:07 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id e23so1348125vsk.2; Fri, 02 Oct 2020 15:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zu4JgeZjdiu/uhRp+wrsSD2QJ/lH+hOpvBngJ4cg+a4=; b=caqbVyl1NrehaaigGmhrjAdNbDY5BsguW3vbFiFqEex6gck2zmBIZOcOVkFv5UqV8J tkuOa09m1gqxi61m5GZGW8OjmSpZfwvfUOi1H2pG47ZpeskHdbNouFzUpcRT/6VJr6B7 Tmwcbkq1RvZS8b5/xJv/rdhpkHXD3yw7qZ02gHJ+5vGcTeCFwTXZPpcvCV29em3cY8gQ HPPJKUDB8whlQNX/OCL05POD+8CVpE099S1a3wZglgW+apV4O3tMYExoZcEEg+20a5pK b+hBEiibJw2frn6liMPtvEQArPCGY2JjJOKX1e5z+K5+OxGIUAPVZNv9yBlikunXvNeV WHPw== 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=Zu4JgeZjdiu/uhRp+wrsSD2QJ/lH+hOpvBngJ4cg+a4=; b=WwrvlbXqcuJ6LW5QotW/njKShLUKG9JkpR7Y1VYjKdt6rzuIulmnBJhAdZkGtN7I3K TY65a5MZLU2E6uhMn9FTJMhUVyzbvj99I9L0I4mBbUAnMXxMvjiwQohhaJatArVGaJCk gE03nmK404xhQfDnFunMYIUYJC1rJ3djHmi4xno/y04V8EUuxnVhgLRYqXOErDr8ycoV 8xFLfwWqBIfqLe+UhbrZxJrc90iMA+xG7pLm4PJ3AZg0ik6GvCsGr4Vbtpe5lJYcEUXZ 6cYlWP19JXxsMQ+uCASefanF1glSDKF66FFopTpDpT8ocRkoM5wEIDrq9iTVa6d1i+tY 1/Ng== X-Gm-Message-State: AOAM530hxMT337Ki+jLjJbUwENcOEEcPwtMADnB8XvEHviimViFdyuu6 5wuWESXSHJ+y50YLLioZ8JthI4W+LIyMnzEby+s1UroXYQaTHQ== X-Google-Smtp-Source: ABdhPJzxBdqKrNeIDGfIQ+5SAC7PBSh57TZkGRlgY4z8rpy1vctwxNv0pznEiHMLDrCKjbjdz6ff7QowDGJDoC5fMio= X-Received: by 2002:a67:7dc4:: with SMTP id y187mr2729004vsc.58.1601678226248; Fri, 02 Oct 2020 15:37:06 -0700 (PDT) MIME-Version: 1.0 References: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> In-Reply-To: From: Gyan Mishra Date: Fri, 2 Oct 2020 18:36:55 -0400 Message-ID: To: "Les Ginsberg (ginsberg)" Cc: Christian Hopps , "draft-ketant-lsr-ospf-l2bundles.all@ietf.org" , "lsr-chairs@ietf.org" , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b857ca05b0b7c5a5" Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 22:37:09 -0000 --000000000000b857ca05b0b7c5a5 Content-Type: text/plain; charset="UTF-8" I support WG adoption of this draft. I agree that OSPF needs the functionality equivalent to that defined for IS-IS in RFC 8668. I think the draft should include similar to RFC 8668 section 3 parallel layer 3 adjacencies 3 similar Sub TLVs mentioned flag for multiple parallel adjacencies. Also maybe section 4 of RFC 8668 would apply as well to ospf advertisement of L2 bundle Adj sid. Thanks Gyan On Fri, Oct 2, 2020 at 6:11 PM Les Ginsberg (ginsberg) wrote: > I support WG adoption of this draft. > > OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668. > > > > Les > > > > > > > -----Original Message----- > > > From: Lsr On Behalf Of Christian Hopps > > > Sent: Friday, October 02, 2020 5:03 AM > > > To: lsr@ietf.org > > > Cc: lsr-chairs@ietf.org; Christian Hopps ; > draft-ketant- > > > lsr-ospf-l2bundles.all@ietf.org > > > Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 > > > > > > This begins a 2 week WG adoption call for the following draft: > > > > > > https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ > > > > > > Please indicate your support or objection by October 16, 2020. > > > > > > Authors, please respond to the list indicating whether you are aware of > any > > > IPR that applies to this draft. > > > > > > Thanks, > > > Chris and Acee. > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000b857ca05b0b7c5a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I support WG adoption of this draft.

I agree that OSPF needs the funct= ionality equivalent to that defined for IS-IS in RFC 8668.
I think the draft should include similar to RFC 8668 sectio= n 3 parallel layer 3 adjacencies 3 similar Sub TLVs mentioned flag for mult= iple parallel adjacencies.

Also maybe section 4 of RFC 8668 wou= ld apply as well to ospf advertisement of L2 bundle Adj sid.

Thanks=C2=A0
<= br>
Gyan

On Fri, Oct 2, 2020 = at 6:11 PM Les Ginsberg (ginsberg) <ginsberg=3D40cisco.com@dmarc.ietf.org> wrote:
I support WG adoption of this draft.

OSPF needs functi= onality equivalent to that defined for IS-IS in RFC 8668.



= =C2=A0 =C2=A0Les





> -----Original Message-----
=
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Christian Hopps

>= Sent: Friday, October 02, 2020 5:03 AM

> To: lsr@ietf.org

> Cc: lsr-chairs@ietf.org; Chri= stian Hopps <chop= ps@chopps.org>; draft-ketant-

> lsr-ospf-l2bundles.all@ietf.org<= /a>

> Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l= 2bundles-01

>

> This begins a 2 week WG adoption call = for the following draft:

>

>=C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ketant-ls= r-ospf-l2bundles/

>

> Please indicate your support= or objection by October 16, 2020.

>

> Authors, please= respond to the list indicating whether you are aware of any

> IP= R that applies to this draft.

>

> Thanks,

> = Chris and Acee.



____________________________________________= ___

Lsr mailing list

Lsr@ietf.org

https://www.ietf.org/ma= ilman/listinfo/lsr

--

<= a href=3D"http://www.verizon.com/" style=3D"color:rgb(17,85,204);padding-bo= ttom:1em;display:inline-block" target=3D"_blank">

Gyan Mishra

Network Solutions Architect=C2=A0

Content-Type: multipart/alternative; boundary="000000000000f04ac405b0b92041" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 00:14:15 -0000 --000000000000f04ac405b0b92041 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeff >From a domain perspective where you have a group of nodes and associated IP addressed and SID are part of a discrete underlay instance flex algo topology. On those same set of nodes you could have another topology and associated address and SIDs for a different flex algo. How this would work is that the topologies would have to be segregated from each other as different MT instances or routing process instances. Is that correct? Can two nodes that run two different flex algo become ospf or isis neighbors? Kind Regards Gyan On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura wrote: > > > > > > > > > > > > > Hi Yingzhen, > > > > > > Yes, that=E2=80=99s the case. The most important property of an algo com= puted > path is that is has to be consecutive, as either SID or IP address > associated with a particular topology is only known within that topology. > > > Looking specifically at Ron=E2=80=99s draft (MPLS could be more complex d= ue to > potential hierarchy) - the prefix itself defines the context(topology) an= d > must be globally unique, since IPv4 header can=E2=80=99t have any additio= nal > meta-data attached. > > > > > > > > Cheers, > > Jeff > > > > > > > On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu , > wrote: > > > Hi Peter, > > > > > > My understanding of flex-algo is that for traffic destined to a prefix on > a particular algo, it can only be routed on routers belong to that algo, > which also means only routers in that algo calculates how to reach that > prefix and install it into the routing table. It seems to me that using > flex-algo (section 12 of the draft) it's possible to have a loopback > address associated with only one algo, please correct me if I'm missing o= r > misunderstood something. > > > > > > Thanks, > > > Yingzhen > > > > > > =EF=BB=BFOn 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" < > lsr-bounces@ietf.org on behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> > wrote: > > > > > > Gyan, > > > > > > On 02/10/2020 18:30, Gyan Mishra wrote: > > > All, > > > > > > With SRv6 and IP based flex algo a generic question as it applies to > > > both. Is it possible to have within a single IGP domain different sets > > > of nodes or segments of the network running different algorithms. > > > > > > > absolutely. > > > > > > From > > > both drafts it sounds like all nodes have to agree on same algorithm > > > similar to concept of metric and reference bandwidth all have to have > > > the same style metric and play to the same sheet of music. > > > > > > > all participating nodes need to agree on the definition of the flex-algo > > > and advertise the participation. That's it. > > > > > > If there was > > > a way to use multiple algorithms simultaneously based on SFC or services > > > and instantiation of specific algorithm based on service to be > > > rendered. Doing so without causing a routing loop or sub optimal > > > routing. > > > > > > > you can certainly use multiple algorithms simultaneously and use algo > > > specific paths to forward specific traffic over it. How that is done > > > from the forwarding perspective depends in which forwarding plane you > > > use. Flex-algo control plane is independent of the forwarding plane. > > > > > > > > > I thought with flex algo that there exists a feature that on > > > each hop there is a way to specify which algo to use hop by hop similar > > > to a hop by hop policy based routing. > > > > > > > no, there is no hop-by-hop classification, that is problematic and does > > > not scale for high speeds. Classification is done at the ingress only. > > > > > > thanks, > > > Peter > > > > > > > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Flsr&data=3D02%7C01%7Cyingzhen.qu%40futur= ewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591f= edc%7C1%7C0%7C637372537869296887&sdata=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL7z= LjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=3D0 > > > > > > > > > > > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000f04ac405b0b92041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Hi =C2=A0Jeff=C2=A0

From a domain perspective where you have a gro= up of nodes and associated IP addressed and SID are part of a discrete unde= rlay instance flex algo topology.=C2=A0 On those same set of nodes you coul= d have another topology and associated address and SIDs for a different fle= x algo.=C2=A0 How this would work is that the topologies would have to be s= egregated from each other as different MT instances or routing process inst= ances.=C2=A0 Is that correct?

Can two nodes that run two different flex algo become ospf or isis ne= ighbors? =C2=A0

Kind Reg= ards=C2=A0

Gyan

On Fri, Oct 2, 2020 at 6:25= PM Jeff Tantsura <jefftant.i= etf@gmail.com> wrote:










Hi Yingzhen,





Yes, that=E2=80= =99s the case.=C2=A0=C2=A0The most important property of an algo computed p= ath is that is has to be consecutive, as either SID or IP address associate= d with a particular topology is only known within that topology.=C2=A0
<= br>
Looking specifically at Ron=E2=80=99s draft (MPLS could be more comp= lex due to potential hierarchy) - the prefix itself defines the context(top= ology) and must be globally unique, since IPv4 header can=E2=80=99t have an= y additional meta-data attached.=C2=A0=C2=A0







Cheers,

Jef= f






On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu <yingzhen.qu@futurewei.com>, wrote:


Hi Peter,





My understanding of flex-al= go is that for traffic destined to a prefix on a particular algo, it can on= ly be routed on routers belong to that algo, which also means only routers = in that algo calculates how to reach that prefix and install it into the ro= uting table. It seems to me that using flex-algo (section 12 of the draft) = it's possible to have a loopback address associated with only one algo,= please correct me if I'm missing or misunderstood something.




Thanks,


Yingzhen





=EF=BB=BFO= n 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" <lsr-bounces@ietf.org= on behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> wrote:




<= br>Gyan,





On 02/10/2020 18:30, Gyan Mishra wrote:
=

All,





With SRv6 and= IP based flex algo a generic question as it applies to


both. Is= it possible to have within a single IGP domain different sets


o= f nodes or segments of the network running different algorithms.





absolutely.





From


both drafts it sounds like all nodes have to ag= ree on same algorithm


similar to concept of metric and reference= bandwidth all have to have


the same style metric and play to th= e same sheet of music.





all participatin= g nodes need to agree on the definition of the flex-algo


and adv= ertise the participation. That's it.





If there was


a way to use multiple algorithms sim= ultaneously based on SFC or services


and instantiation of specif= ic algorithm based on service to be


rendered. Doing so without c= ausing a routing loop or sub optimal


routing.




you can certainly use multiple algorithms simultaneously = and use algo


specific paths to forward specific traffic over it.= How that is done


from the forwarding perspective depends in whi= ch forwarding plane you


use. Flex-algo control plane is independ= ent of the forwarding plane.








I thought with flex algo that there exists a feature that on=


each hop there is a way to specify which algo to use hop by hop= similar


to a hop by hop policy based routing.
<= br>



no, there is no hop-by-hop classification, that is probl= ematic and does


not scale for high speeds. Classification is don= e at the ingress only.





thanks,


Peter
<= br>







<= br>
_______________________________________________


Lsr maili= ng list


Lsr@ie= tf.org


https://nam11.safelinks.protection.outlook.c= om/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;dat= a=3D02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6= a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&amp;s= data=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&amp;res= erved=3D0








<= br>

--


Gya= n Mishra

Netw= ork Solutions A<= i>rchitect=C2=A0

M 301 502-1347
1= 3101 Columbia Pike=C2=A0
Silver Spring, MD


=
--000000000000f04ac405b0b92041-- From nobody Sat Oct 3 01:20:20 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CFB3A0898 for ; Sat, 3 Oct 2020 01:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 2jJC3moCHSF4 for ; Sat, 3 Oct 2020 01:20:17 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 DD8783A0489 for ; Sat, 3 Oct 2020 01:20:16 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id lw21so905363ejb.6 for ; Sat, 03 Oct 2020 01:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=68onZ1UHp9A7FSda8rUIGElfRmhuYYgeCbU2/r+oEh4=; b=anF8kEep8CHzjrLBV5MLEEKhD42st8Uy31Qie70GU4HWgna9GSEZV7npCAUo7PqOOM pAwfOTmviV436rdZVl6zjkAvpXCwBe99eaNdtKYKGicGjsEbC/YFyXp3wrsUQ05nuI7O bwTzkQAQTecQhOMH4f3B+Y9+m7lUH/zbRPpnOzvQ3sRIyUVY9uZssG0eWxCcVfiDKKCO MZk8B1FLSlMIvS9YnT2TejJ0pXPbwz1G1UEz9EjRWi22Sr4YlSLDTFQmC7drApKprV7L /MbUNBGWrTgIlGJ3aH2ST5AJSfzIBZl+a10QuJDqr+K4sKYWxi5+liYJUa1UFq27ev7E 5h0Q== 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=68onZ1UHp9A7FSda8rUIGElfRmhuYYgeCbU2/r+oEh4=; b=ldnI4afu1nOaZJXK7sMJUvXsXtQBRiDi09IHuiJBvAqBwvDzdU3BctJvA9VVzIBlh7 QvQWs8s9nTiJYVDHaE05Ff7A7F3H5HiG+PzPI0gOq/ACv/urvcO9mCYXPx56rMW3+HXH 1EDJGtkReg+lpqHgW744ZHO3Br26W3laswGriz6Q+rB0o6wUflE+BXQ367h/xhIkdMKw e5mbcVbSx13A1UGfBAoJVBpA/HR5y+BjoQi6MPNPYFdzudzv1chNCdEZR8+UhJKM4AXJ TjpuQFj0LA5jdTbI3wv7XbmohwLuFRQqPHTZ4i+j2t2L22gQNOOVleFyjDlblBH9Un0E yQug== X-Gm-Message-State: AOAM531EDSlKAMuviMVH+BmfAJCCOnQQ+zwbRsIffWwwQ5dJ3Va8Anwx 52/KAEQ7TbnadpKIt8Otla8Y3B3jKfrg7Mr5Ekl0OA== X-Google-Smtp-Source: ABdhPJx8lgANzfIbU4yForxyUhLCoafd+bYj+HAgCJRrUx9wriy7AhK7wQnuv07LDgb68G5o2+fhQemr6qngG7+AdV4= X-Received: by 2002:a17:906:2618:: with SMTP id h24mr5465670ejc.198.1601713215272; Sat, 03 Oct 2020 01:20:15 -0700 (PDT) MIME-Version: 1.0 References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> In-Reply-To: From: Robert Raszuk Date: Sat, 3 Oct 2020 10:20:06 +0200 Message-ID: To: Gyan Mishra Cc: Jeff Tantsura , Ron Bonica , "lsr@ietf.org" , Yingzhen Qu , Peter Psenak Content-Type: multipart/alternative; boundary="0000000000003a93c505b0bfeba9" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 08:20:19 -0000 --0000000000003a93c505b0bfeba9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Can two nodes that run two different flex algo become ospf or isis neighbors? It is my understanding that those nodes always will become ospf neighbours as you still run default topology on all of them. I have not seen a case where flex algo topology can be enabled without default topology. Thx, R. On Sat, Oct 3, 2020 at 2:14 AM Gyan Mishra wrote: > > Hi Jeff > > From a domain perspective where you have a group of nodes and associated > IP addressed and SID are part of a discrete underlay instance flex algo > topology. On those same set of nodes you could have another topology and > associated address and SIDs for a different flex algo. How this would wo= rk > is that the topologies would have to be segregated from each other as > different MT instances or routing process instances. Is that correct? > > Can two nodes that run two different flex algo become ospf or isis > neighbors? > > Kind Regards > > Gyan > > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura > wrote: > >> >> >> >> >> >> >> >> >> >> >> >> >> Hi Yingzhen, >> >> >> >> >> >> Yes, that=E2=80=99s the case. The most important property of an algo co= mputed >> path is that is has to be consecutive, as either SID or IP address >> associated with a particular topology is only known within that topology= . >> >> >> Looking specifically at Ron=E2=80=99s draft (MPLS could be more complex = due to >> potential hierarchy) - the prefix itself defines the context(topology) a= nd >> must be globally unique, since IPv4 header can=E2=80=99t have any additi= onal >> meta-data attached. >> >> >> >> >> >> >> >> Cheers, >> >> Jeff >> >> >> >> >> >> >> On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu , >> wrote: >> >> >> Hi Peter, >> >> >> >> >> >> My understanding of flex-algo is that for traffic destined to a prefix o= n >> a particular algo, it can only be routed on routers belong to that algo, >> which also means only routers in that algo calculates how to reach that >> prefix and install it into the routing table. It seems to me that using >> flex-algo (section 12 of the draft) it's possible to have a loopback >> address associated with only one algo, please correct me if I'm missing = or >> misunderstood something. >> >> >> >> >> >> Thanks, >> >> >> Yingzhen >> >> >> >> >> >> =EF=BB=BFOn 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" < >> lsr-bounces@ietf.org on behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> >> wrote: >> >> >> >> >> >> Gyan, >> >> >> >> >> >> On 02/10/2020 18:30, Gyan Mishra wrote: >> >> >> All, >> >> >> >> >> >> With SRv6 and IP based flex algo a generic question as it applies to >> >> >> both. Is it possible to have within a single IGP domain different sets >> >> >> of nodes or segments of the network running different algorithms. >> >> >> >> >> >> >> absolutely. >> >> >> >> >> >> From >> >> >> both drafts it sounds like all nodes have to agree on same algorithm >> >> >> similar to concept of metric and reference bandwidth all have to have >> >> >> the same style metric and play to the same sheet of music. >> >> >> >> >> >> >> all participating nodes need to agree on the definition of the flex-algo >> >> >> and advertise the participation. That's it. >> >> >> >> >> >> If there was >> >> >> a way to use multiple algorithms simultaneously based on SFC or services >> >> >> and instantiation of specific algorithm based on service to be >> >> >> rendered. Doing so without causing a routing loop or sub optimal >> >> >> routing. >> >> >> >> >> >> >> you can certainly use multiple algorithms simultaneously and use algo >> >> >> specific paths to forward specific traffic over it. How that is done >> >> >> from the forwarding perspective depends in which forwarding plane you >> >> >> use. Flex-algo control plane is independent of the forwarding plane. >> >> >> >> >> >> >> >> >> I thought with flex algo that there exists a feature that on >> >> >> each hop there is a way to specify which algo to use hop by hop similar >> >> >> to a hop by hop policy based routing. >> >> >> >> >> >> >> no, there is no hop-by-hop classification, that is problematic and does >> >> >> not scale for high speeds. Classification is done at the ingress only. >> >> >> >> >> >> thanks, >> >> >> Peter >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Lsr mailing list >> >> >> Lsr@ietf.org >> >> >> >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fmailman%2Flistinfo%2Flsr&data=3D02%7C01%7Cyingzhen.qu%40futu= rewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591= fedc%7C1%7C0%7C637372537869296887&sdata=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL7= zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=3D0 >> >> >> >> >> >> >> >> >> >> >> >> -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --0000000000003a93c505b0bfeba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Can two nodes that run two different f= lex algo become ospf or isis neighbors? =C2=A0=C2=A0=C2=A0

It is my understanding that those nodes always will become ospf neig= hbours as you still run default topology on all of them. I have not seen a = case where flex algo topology can be enabled without default topology.=C2= =A0

Thx,
R.

On Sat, Oct 3, 2020 at 2:14 AM= Gyan Mishra <hayabusagsm@gmail= .com> wrote:

Hi =C2=A0Jeff=C2=A0

From a domain perspective where you have a= group of nodes and associated IP addressed and SID are part of a discrete = underlay instance flex algo topology.=C2=A0 On those same set of nodes you = could have another topology and associated address and SIDs for a different= flex algo.=C2=A0 How this would work is that the topologies would have to = be segregated from each other as different MT instances or routing process = instances.=C2=A0 Is that correct?

Can two nodes that run two different flex algo become ospf or isi= s neighbors? =C2=A0

Kind= Regards=C2=A0

Gyan

On Fri, Oct 2, 2020 at 6:= 25 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:











Hi Yingzhen= ,





Yes, that=E2=80=99s the case.=C2=A0=C2=A0The most = important property of an algo computed path is that is has to be consecutiv= e, as either SID or IP address associated with a particular topology is onl= y known within that topology.=C2=A0


Looking specifically at Ron= =E2=80=99s draft (MPLS could be more complex due to potential hierarchy) - = the prefix itself defines the context(topology) and must be globally unique= , since IPv4 header can=E2=80=99t have any additional meta-data attached.= =C2=A0=C2=A0







Cheers,

Jeff






On Oct 2, 2020, 1:1= 5 PM -0700, Yingzhen Qu <yingzhen.qu@futurewei.com>, wrote:


Hi Peter,





My understanding of flex-algo = is that for traffic destined to a prefix on a particular algo, it can only = be routed on routers belong to that algo, which also means only routers in = that algo calculates how to reach that prefix and install it into the routi= ng table. It seems to me that using flex-algo (section 12 of the draft) it&= #39;s possible to have a loopback address associated with only one algo, pl= ease correct me if I'm missing or misunderstood something.


<= br>

Thanks,


Yingzhen





=EF=BB=BFOn 1= 0/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" <lsr-bounces@ietf.org on b= ehalf of ppsenak=3D40cisco.com@dmarc.ietf.org> wrote:





Gy= an,





On 02/10/2020 18:30, Gyan Mishra wrote:

<= br>
All,





With SRv6 and IP b= ased flex algo a generic question as it applies to


both. Is it p= ossible to have within a single IGP domain different sets


of nod= es or segments of the network running different algorithms.





absolutely.





From


both drafts it sounds like all nodes have to agree o= n same algorithm


similar to concept of metric and reference band= width all have to have


the same style metric and play to the sam= e sheet of music.





all participating nod= es need to agree on the definition of the flex-algo


and advertis= e the participation. That's it.





If there was


a way to use multiple algorithms simultan= eously based on SFC or services


and instantiation of specific al= gorithm based on service to be


rendered. Doing so without causin= g a routing loop or sub optimal


routing.




you can certainly use multiple algorithms simultaneously and u= se algo


specific paths to forward specific traffic over it. How = that is done


from the forwarding perspective depends in which fo= rwarding plane you


use. Flex-algo control plane is independent o= f the forwarding plane.








I thought with flex algo that there exists a feature that on
<= br>
each hop there is a way to specify which algo to use hop by hop simi= lar


to a hop by hop policy based routing.




no, there is no hop-by-hop classification, that is problemati= c and does


not scale for high speeds. Classification is done at = the ingress only.





thanks,


Peter









_______________________________________________


Lsr mailing li= st


Lsr@ietf.or= g


https://nam11.safelinks.protection.outlook.com/= ?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data= =3D02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a= %7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&amp;sd= ata=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&amp;rese= rved=3D0










--


Gyan Mishra

Network Solutions Architect=C2=A0

Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

--0000000000003a93c505b0bfeba9-- From nobody Sat Oct 3 02:45:48 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0753F3A0976 for ; Sat, 3 Oct 2020 02:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgYy7rOuLWe4 for ; Sat, 3 Oct 2020 02:45:45 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7D203A00C9 for ; Sat, 3 Oct 2020 02:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5607; q=dns/txt; s=iport; t=1601718344; x=1602927944; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=p4SYnyFcWkaURlzVaZtUGfAKHQ/rSLtUmYvqI1YXc/Q=; b=Fwhnu4PMV89lEDLwAI8HBKXRcDkHFkx4noR5jYaHZ719RgCh/RlXhffn R6MBEMWDTriIuJk7wOEayxq99TEBGXpGVOw2nbELjXGvjw9LbL80BN1Qa 3/xdN+ubgkkWH67JLyDvsgVnRpGDjKLPIkuXqqGH+XFMpX0dhaHPC7Hya U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQATR3hf/xbLJq1dAxsBAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQFAgU+DGlUBIBIshD2JAogJCCaKEZITCwEBAQ8fEAQ?= =?us-ascii?q?BAYRKAoI3JjgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQIBIw8BBTYJAgU?= =?us-ascii?q?LCwcHCgICIwMCAiElEQYBDAYCAQEXgwsBgksDDiCmQ3aBMoVUglANYoFCgQ4?= =?us-ascii?q?qh2GFa4FBP4ERJwyCXT6CGkIEgX4mglCCYASQHwmWFJBAUoJxgxONBIU/hH8?= =?us-ascii?q?FBwMfgw6KAoUSjnuTE41YkmSBayMNgUozGggbFTuCaQlHGQ2OKxeDTopYPwM?= =?us-ascii?q?wAjUCBgEJAQEDCY5IAQE?= X-IronPort-AV: E=Sophos;i="5.77,331,1596499200"; d="scan'208";a="30024665" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Oct 2020 09:45:40 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 0939jdsQ021737; Sat, 3 Oct 2020 09:45:40 GMT To: Gyan Mishra , Jeff Tantsura Cc: Ron Bonica , Yingzhen Qu , "lsr@ietf.org" References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> From: Peter Psenak Message-ID: <047be764-8203-ca46-7ee1-6f84f7bf2356@cisco.com> Date: Sat, 3 Oct 2020 11:45:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 09:45:47 -0000 Gyan, On 03/10/2020 02:14, Gyan Mishra wrote: > > Hi  Jeff > > From a domain perspective where you have a group of nodes and > associated IP addressed and SID are part of a discrete underlay instance > flex algo topology.  On those same set of nodes you could have another > topology and associated address and SIDs for a different flex algo. above is right. > How > this would work is that the topologies would have to be segregated from > each other as different MT instances or routing process instances.  Is > that correct? no MT at all. You can think of each flex-algo as a set of constraints that is used to calculate the path over the common topology. You can have many such felx-algos running on a common topology. > > Can two nodes that run two different flex algo become ospf or isis > neighbors? absolutely. Peter > > Kind Regards > > Gyan > > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura > wrote: > > > > > > > > > > > > > > Hi Yingzhen, > > > > > > Yes, that’s the case.  The most important property of an algo > computed path is that is has to be consecutive, as either SID or IP > address associated with a particular topology is only known within > that topology. > > > Looking specifically at Ron’s draft (MPLS could be more complex due > to potential hierarchy) - the prefix itself defines the > context(topology) and must be globally unique, since IPv4 header > can’t have any additional meta-data attached. > > > > > > > > Cheers, > > Jeff > > > > > > > On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu > >, wrote: > > >> Hi Peter, >> >> >> >> >> >> My understanding of flex-algo is that for traffic destined to a >> prefix on a particular algo, it can only be routed on routers >> belong to that algo, which also means only routers in that algo >> calculates how to reach that prefix and install it into the >> routing table. It seems to me that using flex-algo (section 12 of >> the draft) it's possible to have a loopback address associated >> with only one algo, please correct me if I'm missing or >> misunderstood something. >> >> >> >> >> >> Thanks, >> >> >> Yingzhen >> >> >> >> >> >> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >> on behalf of >> ppsenak=40cisco.com@dmarc.ietf.org >> > wrote: >> >> >> >> >> >> Gyan, >> >> >> >> >> >> On 02/10/2020 18:30, Gyan Mishra wrote: >> >> >>> All, >>> >>> >>> >>> >>> >>> With SRv6 and IP based flex algo a generic question as it applies to >>> >>> >>> both. Is it possible to have within a single IGP domain different >>> sets >>> >>> >>> of nodes or segments of the network running different algorithms. >> >> >> >> >> >> absolutely. >> >> >> >> >> >>> From >>> >>> >>> both drafts it sounds like all nodes have to agree on same algorithm >>> >>> >>> similar to concept of metric and reference bandwidth all have to have >>> >>> >>> the same style metric and play to the same sheet of music. >> >> >> >> >> >> all participating nodes need to agree on the definition of the >> flex-algo >> >> >> and advertise the participation. That's it. >> >> >> >> >> >>> If there was >>> >>> >>> a way to use multiple algorithms simultaneously based on SFC or >>> services >>> >>> >>> and instantiation of specific algorithm based on service to be >>> >>> >>> rendered. Doing so without causing a routing loop or sub optimal >>> >>> >>> routing. >> >> >> >> >> >> you can certainly use multiple algorithms simultaneously and use algo >> >> >> specific paths to forward specific traffic over it. How that is done >> >> >> from the forwarding perspective depends in which forwarding plane you >> >> >> use. Flex-algo control plane is independent of the forwarding plane. >> >> >> >> >> >> >> >> >>> I thought with flex algo that there exists a feature that on >>> >>> >>> each hop there is a way to specify which algo to use hop by hop >>> similar >>> >>> >>> to a hop by hop policy based routing. >> >> >> >> >> >> no, there is no hop-by-hop classification, that is problematic and >> does >> >> >> not scale for high speeds. Classification is done at the ingress only. >> >> >> >> >> >> thanks, >> >> >> Peter >> >> >> >> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> >> Lsr mailing list >> >> >> Lsr@ietf.org >> >> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=0 >> >> >> > > > > > > > > > -- > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /M 301 502-1347 > 13101 Columbia Pike > /Silver Spring, MD > > From nobody Sat Oct 3 02:47:54 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5523A0977 for ; Sat, 3 Oct 2020 02:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.813 X-Spam-Level: X-Spam-Status: No, score=-9.813 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyRk1aTa5Q9m for ; Sat, 3 Oct 2020 02:47:52 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E0D3A0976 for ; Sat, 3 Oct 2020 02:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3098; q=dns/txt; s=iport; t=1601718471; x=1602928071; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xysBOEb0ey7HDG2Vieibi9w4sSCcsVEB9gzB3Y/f68Y=; b=GnjOqqFTjHjQWArwfYasq4KNsPUcqCtTcG10IHrw14EOF1ky5MirFavb P1GNzssXW5UZ0GW+FLwLtarT7Zhs4G2lArGME1MKkGW7oV4AWV34AJ1qB 8JlSngkhnbKhaUdmWzCtZ3hcrMe/b0+Qqpf5eTmSBIfJNwr8QLJbaRb9z k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAAD6R3hf/xbLJq1gGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFPgxpVASASLIQ9iQKICS6cJAsBAQEPLwQ?= =?us-ascii?q?BAYRKAoI3JjgTAgMBAQsBAQUBAQECAQYEbYVohXIBAQEBAgEjFTYJAhALGAI?= =?us-ascii?q?CJgICVwYBDAYCAQGDIgGCXCCmRHaBMoVUgz+BPAaBDiqJH4QtgUE/gTiCaT6?= =?us-ascii?q?CXASEdIJgBJAfCYJViH6bU4JxgxOXQgUHAx+DDooChRKOe5MToDyBayMNgUo?= =?us-ascii?q?zGggbFTuCaVAZDZxoPwMwAjUCBgoBAQMJjkgBAQ?= X-IronPort-AV: E=Sophos;i="5.77,331,1596499200"; d="scan'208";a="30086407" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Oct 2020 09:47:47 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 0939llKe021953; Sat, 3 Oct 2020 09:47:47 GMT To: Yingzhen Qu , Gyan Mishra , Ron Bonica Cc: "lsr@ietf.org" , Jeff Tantsura References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> From: Peter Psenak Message-ID: <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> Date: Sat, 3 Oct 2020 11:47:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 09:47:54 -0000 Hi Yingzhen, On 02/10/2020 22:15, Yingzhen Qu wrote: > Hi Peter, > > My understanding of flex-algo is that for traffic destined to a prefix on a particular algo, it can only be routed on routers belong to that algo, which also means only routers in that algo calculates how to reach that prefix and install it into the routing table. It seems to me that using flex-algo (section 12 of the draft) it's possible to have a loopback address associated with only one algo, please correct me if I'm missing or misunderstood something. you are right. That is exactly what is being done for flex-algo with SRv6 - locator is associated with a single algo only. The proposal uses the same concept. thanks, Peter > > Thanks, > Yingzhen > > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" wrote: > > Gyan, > > On 02/10/2020 18:30, Gyan Mishra wrote: > > All, > > > > With SRv6 and IP based flex algo a generic question as it applies to > > both. Is it possible to have within a single IGP domain different sets > > of nodes or segments of the network running different algorithms. > > absolutely. > > > From > > both drafts it sounds like all nodes have to agree on same algorithm > > similar to concept of metric and reference bandwidth all have to have > > the same style metric and play to the same sheet of music. > > all participating nodes need to agree on the definition of the flex-algo > and advertise the participation. That's it. > > > If there was > > a way to use multiple algorithms simultaneously based on SFC or services > > and instantiation of specific algorithm based on service to be > > rendered. Doing so without causing a routing loop or sub optimal > > routing. > > you can certainly use multiple algorithms simultaneously and use algo > specific paths to forward specific traffic over it. How that is done > from the forwarding perspective depends in which forwarding plane you > use. Flex-algo control plane is independent of the forwarding plane. > > > >I thought with flex algo that there exists a feature that on > > each hop there is a way to specify which algo to use hop by hop similar > > to a hop by hop policy based routing. > > no, there is no hop-by-hop classification, that is problematic and does > not scale for high speeds. Classification is done at the ingress only. > > thanks, > Peter > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=0 > > > From nobody Sat Oct 3 09:41:35 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C523A0B50 for ; Sat, 3 Oct 2020 09:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 ZhldW98giUyU for ; Sat, 3 Oct 2020 09:41:30 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 7E1F23A0B55 for ; Sat, 3 Oct 2020 09:41:30 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id e23so2043504vsk.2 for ; Sat, 03 Oct 2020 09:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A70utf12A17qXckSQBvvmCvWMsN9GislTj6e8+osqJI=; b=ZrjjICR7+ZTRy/8L3wKPUNWoDROV2hfEOfnzKMZBY4wdR9Ttdlo1GfrlihxWWMauwy axAHfLEGMfl2yPnK8S3YNlr/Ozc+PO8grIoGIl/ZkPWjHrQuFrCiZvLr4O2iZZCOwth+ YhWFNwfU0Vujv56dU+pHJAofGO0D7fQtDIVNJRJpOppuy/mznmJURgWXnus3Gcezp6Ew SnKUu2sc1BZjPgJom02OaXnI3igkb57Idk5Ld9vNL1F1cHidBTrmMPU0HXjbDfmsONMV 6pP/j2vFeQk+QOcA1Qt1Qhf6k9LZfHfJXgyn4PFM1+nDckDyRmGPjryGklETVj1mqMbI YBiA== 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=A70utf12A17qXckSQBvvmCvWMsN9GislTj6e8+osqJI=; b=HKS9eCgLVr/b29PFhXrni7nWCVNOWDxXfU2NF7FPj94b6s46UPOSa6Bm9AZsn0gX6U e+o3hoZZydS4cXU+ni5pM/iCq5SeJc9K1WTLKFYnql7PeX6FgYq39DUrDHDE2gfuugpK x9CM69OUQrhlT5lJwGfpyWzqWxRfVxLP7kOshwfzTM5u2KW0L63AeHd/1tGByyrQR4iF LS47ffJrg3YmbGFOusKc5PrjdRu3uUauXMxsa15t0HQpj2sdONGLUVuJJBXG6DJGl0uz 4eACbn1dAhhgleSqpb4J4adFYErYOkpDoUM66E8hHvj+zPjJv8urKcpYu6dx0KrOrxNV PmUw== X-Gm-Message-State: AOAM532PCozG63pQ3juPm2fYNuD2C2z3qO36u/M/+0tYkpeJtGISHrbh NVtkGiGJnjNPeSFAlPNh3UiTmwAu5Ytb8bwofx8= X-Google-Smtp-Source: ABdhPJxCJLUGA6DupNPKia3rJo+KofHMkKoTLa2FghfqEGDyuITzcdjQcefGPNyTiLWJBknKyczF/qO4KypTUW6KRVc= X-Received: by 2002:a67:e248:: with SMTP id w8mr3913072vse.33.1601743289349; Sat, 03 Oct 2020 09:41:29 -0700 (PDT) MIME-Version: 1.0 References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> In-Reply-To: From: Gyan Mishra Date: Sat, 3 Oct 2020 12:41:18 -0400 Message-ID: To: Robert Raszuk Cc: Jeff Tantsura , Peter Psenak , Ron Bonica , Yingzhen Qu , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c878ea05b0c6ebf1" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 16:41:33 -0000 --000000000000c878ea05b0c6ebf1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 3, 2020 at 4:20 AM Robert Raszuk wrote: > > > Can two nodes that run two different flex algo become ospf or isis > neighbors? > > It is my understanding that those nodes always will become ospf neighbour= s > as you still run default topology on all of them. I have not seen a case > where flex algo topology can be enabled without default topology. > Gyan>. That is what I was thinking as the algo 0 strict spf as the base algo to provide reachability to all nodes within the domain and all neighbors are formed between all nodes in the domain to populate IGP rib providing base connectivity reachability. So then underneath of that you can have any subset of nodes out of the superset all top layer domain nodes level that can run any other algo desired. Basically creating algo layers under the top domain wide layer. I think I am getting it now! =F0=9F=98=80 > > Thx, > R. > > On Sat, Oct 3, 2020 at 2:14 AM Gyan Mishra wrote: > >> >> Hi Jeff >> >> From a domain perspective where you have a group of nodes and associated >> IP addressed and SID are part of a discrete underlay instance flex algo >> topology. On those same set of nodes you could have another topology an= d >> associated address and SIDs for a different flex algo. How this would w= ork >> is that the topologies would have to be segregated from each other as >> different MT instances or routing process instances. Is that correct? >> >> Can two nodes that run two different flex algo become ospf or isis >> neighbors? >> >> Kind Regards >> >> Gyan >> >> On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura >> wrote: >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Hi Yingzhen, >>> >>> >>> >>> >>> >>> Yes, that=E2=80=99s the case. The most important property of an algo c= omputed >>> path is that is has to be consecutive, as either SID or IP address >>> associated with a particular topology is only known within that topolog= y. >>> >>> >>> Looking specifically at Ron=E2=80=99s draft (MPLS could be more complex= due to >>> potential hierarchy) - the prefix itself defines the context(topology) = and >>> must be globally unique, since IPv4 header can=E2=80=99t have any addit= ional >>> meta-data attached. >>> >>> >>> >>> >>> >>> >>> >>> Cheers, >>> >>> Jeff >>> >>> >>> >>> >>> >>> >>> On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu , >>> wrote: >>> >>> >>> Hi Peter, >>> >>> >>> >>> >>> >>> My understanding of flex-algo is that for traffic destined to a prefix >>> on a particular algo, it can only be routed on routers belong to that a= lgo, >>> which also means only routers in that algo calculates how to reach that >>> prefix and install it into the routing table. It seems to me that using >>> flex-algo (section 12 of the draft) it's possible to have a loopback >>> address associated with only one algo, please correct me if I'm missing= or >>> misunderstood something. >>> >>> >>> >>> >>> >>> Thanks, >>> >>> >>> Yingzhen >>> >>> >>> >>> >>> >>> =EF=BB=BFOn 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" < >>> lsr-bounces@ietf.org on behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> >>> wrote: >>> >>> >>> >>> >>> >>> Gyan, >>> >>> >>> >>> >>> >>> On 02/10/2020 18:30, Gyan Mishra wrote: >>> >>> >>> All, >>> >>> >>> >>> >>> >>> With SRv6 and IP based flex algo a generic question as it applies to >>> >>> >>> both. Is it possible to have within a single IGP domain different sets >>> >>> >>> of nodes or segments of the network running different algorithms. >>> >>> >>> >>> >>> >>> >>> absolutely. >>> >>> >>> >>> >>> >>> From >>> >>> >>> both drafts it sounds like all nodes have to agree on same algorithm >>> >>> >>> similar to concept of metric and reference bandwidth all have to have >>> >>> >>> the same style metric and play to the same sheet of music. >>> >>> >>> >>> >>> >>> >>> all participating nodes need to agree on the definition of the flex-alg= o >>> >>> >>> and advertise the participation. That's it. >>> >>> >>> >>> >>> >>> If there was >>> >>> >>> a way to use multiple algorithms simultaneously based on SFC or service= s >>> >>> >>> and instantiation of specific algorithm based on service to be >>> >>> >>> rendered. Doing so without causing a routing loop or sub optimal >>> >>> >>> routing. >>> >>> >>> >>> >>> >>> >>> you can certainly use multiple algorithms simultaneously and use algo >>> >>> >>> specific paths to forward specific traffic over it. How that is done >>> >>> >>> from the forwarding perspective depends in which forwarding plane you >>> >>> >>> use. Flex-algo control plane is independent of the forwarding plane. >>> >>> >>> >>> >>> >>> >>> >>> >>> I thought with flex algo that there exists a feature that on >>> >>> >>> each hop there is a way to specify which algo to use hop by hop similar >>> >>> >>> to a hop by hop policy based routing. >>> >>> >>> >>> >>> >>> >>> no, there is no hop-by-hop classification, that is problematic and does >>> >>> >>> not scale for high speeds. Classification is done at the ingress only. >>> >>> >>> >>> >>> >>> thanks, >>> >>> >>> Peter >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> >>> Lsr mailing list >>> >>> >>> Lsr@ietf.org >>> >>> >>> >>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= .ietf.org%2Fmailman%2Flistinfo%2Flsr&data=3D02%7C01%7Cyingzhen.qu%40fut= urewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d559= 1fedc%7C1%7C0%7C637372537869296887&sdata=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL= 7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=3D0 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >> >> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> >> >> *M 301 502-134713101 Columbia Pike >> *Silver >> Spring, MD >> >> >> >> >> _______________________________________________ >> >> >> Lsr mailing list >> >> >> Lsr@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000c878ea05b0c6ebf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Oct 3, 2020 at 4:20 AM Robert Raszuk <robert@raszuk.net> wrote:

> Can two nodes= that run two different flex algo become ospf or isis neighbors? =C2=A0=C2= =A0=C2=A0

It is my understanding that those nodes al= ways will become ospf neighbours as you still run default topology on all o= f them. I have not seen a case where flex algo topology can be enabled with= out default topology.=C2=A0

=C2=A0 =C2=A0 Gyan>. That is what I wa= s thinking as the algo 0 strict spf as the base algo to provide reachabilit= y to all nodes within the domain and all neighbors are formed between all n= odes in the domain to populate IGP rib providing base connectivity reachabi= lity.=C2=A0 So then underneath of that you can have any subset of nodes out= of the superset all top layer domain nodes level =C2=A0that can run any ot= her algo desired. Basically creating algo layers under the top domain wide = layer.

I think I am gett= ing it now! =F0=9F=98=80

Thx,
R.

On = Sat, Oct 3, 2020 at 2:14 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:
<= /div>

Hi =C2=A0Jeff= =C2=A0

From a domain per= spective where you have a group of nodes and associated IP addressed and SI= D are part of a discrete underlay instance flex algo topology.=C2=A0 On tho= se same set of nodes you could have another topology and associated address= and SIDs for a different flex algo.=C2=A0 How this would work is that the = topologies would have to be segregated from each other as different MT inst= ances or routing process instances.=C2=A0 Is that correct?

Can two nodes that run two different fle= x algo become ospf or isis neighbors? =C2=A0

Kind Regards=C2=A0

Gyan

= On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:




<= br>






Hi Yingzhen,





Yes, that=E2=80=99s the cas= e.=C2=A0=C2=A0The most important property of an algo computed path is that = is has to be consecutive, as either SID or IP address associated with a par= ticular topology is only known within that topology.=C2=A0


Looki= ng specifically at Ron=E2=80=99s draft (MPLS could be more complex due to p= otential hierarchy) - the prefix itself defines the context(topology) and m= ust be globally unique, since IPv4 header can=E2=80=99t have any additional= meta-data attached.=C2=A0=C2=A0







Cheers,

Jeff

<= br>




On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu <yingzhen.qu@futurewei.com>, wrot= e:


Hi Peter,





My underst= anding of flex-algo is that for traffic destined to a prefix on a particula= r algo, it can only be routed on routers belong to that algo, which also me= ans only routers in that algo calculates how to reach that prefix and insta= ll it into the routing table. It seems to me that using flex-algo (section = 12 of the draft) it's possible to have a loopback address associated wi= th only one algo, please correct me if I'm missing or misunderstood som= ething.





Thanks,


Yingzhen



<= br>
=EF=BB=BFOn 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak&qu= ot; <lsr-bounc= es@ietf.org on behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> wrote:




Gyan,





On 02/10/2020 18:30, Gyan Mi= shra wrote:


All,




With SRv6 and IP based flex algo a generic question as it applies to
<= br>
both. Is it possible to have within a single IGP domain different se= ts


of nodes or segments of the network running different algorit= hms.





absolutely.




From


both drafts it sounds like all n= odes have to agree on same algorithm


similar to concept of metri= c and reference bandwidth all have to have


the same style metric= and play to the same sheet of music.





a= ll participating nodes need to agree on the definition of the flex-algo
=

and advertise the participation. That's it.




=
If there was


a way to use multiple= algorithms simultaneously based on SFC or services


and instanti= ation of specific algorithm based on service to be


rendered. Doi= ng so without causing a routing loop or sub optimal


routing.
=





you can certainly use multiple algorithms = simultaneously and use algo


specific paths to forward specific t= raffic over it. How that is done


from the forwarding perspective= depends in which forwarding plane you


use. Flex-algo control pl= ane is independent of the forwarding plane.







=
I thought with flex algo that there exists a = feature that on


each hop there is a way to specify which algo to= use hop by hop similar


to a hop by hop policy based routing.





no, there is no hop-by-hop classification= , that is problematic and does


not scale for high speeds. Classi= fication is done at the ingress only.





thanks,

Peter











_______________________________________________

Lsr mailing list


Lsr@ietf.org


https://nam11.safelinks.prote= ction.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F= lsr&amp;data=3D02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea1= 9b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6373725378692= 96887&amp;sdata=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg= %3D&amp;reserved=3D0






=




--
=


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13= 101 Columbia Pike=C2=A0
Silver Spring, MD




____________________________________= ___________


Lsr mailing list


Lsr@ietf.org


= https://www.ietf.org/mailman/listinfo/lsr




--


Gyan Mishra

Network Solutions Architect=C2=A0

M 30= 1 502-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD

=

--000000000000c878ea05b0c6ebf1-- From nobody Sat Oct 3 09:54:51 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176183A0B5F for ; Sat, 3 Oct 2020 09:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vTFaOayt4U4W for ; Sat, 3 Oct 2020 09:54:47 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 8B2BB3A0B5E for ; Sat, 3 Oct 2020 09:54:47 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id e62so2038259vsc.10 for ; Sat, 03 Oct 2020 09:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eGOlZjoAPlZ2N5i2upzs6oMT6G6Gpzf8Fkrl6FI/7To=; b=kAf6MJfbVXFGxYrsbxLZejWGMNTMV6qup/zg0YMDDAUF3KeneTIT7kldEvkQLw4Kb6 25hqR/oxj6S+MYy/VZzCOv0YzQ/8bngrRQgvo1gK1EQXovngD37YfqYBnPX4EVFB+YBP 1xtQEZccXABZz+AutOoWkv5VOPUrtwxIQ19hpgEiXuDOrOlQLpZAko8ljlgyQIGL9ZTo RKiCwas8ZqXFc4SgIDygiEbEL3GKMdQnJ2POm5jrSlJdrZwEvoSHZbHbgztcHwbsBCN8 sV4cBIu4P28RkBPquhbL4MKrxOuAKnCgf+AJQwVDbj+kOol1h2PvqF7n2lVE5zFXS6w+ u9dw== 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=eGOlZjoAPlZ2N5i2upzs6oMT6G6Gpzf8Fkrl6FI/7To=; b=NJnMmsts6by7KwtJdeHOOunH5MscZtoidpYsxgc8zvoGKvCjMA+/w/brmHmZwhHzC7 KIWCtPPYSTEy+seyLLGuVMflSQlVSVn4JlO2gJbkRReuMzqn48B5sun5M36+cmU0QWEC HP8qpYvEDi4gIesfPF3W+Fuqe/X3k7HqluZzJsh+bGE9hVTpSkqZZnxhS2FLctxVP+7s 49NBZk+z5eATcHtBeAY3ldD7XiznO6JWdFFfOO+mLaDmGNDCLDIhSDSdQaOw9FvRMUAh WwUyIR+APZWesj29H/qgd7jFvh8L07O3HWAv74faaQd24RFOWAfFT31GRR43ywHj0eqT 91Hg== X-Gm-Message-State: AOAM532Kb2ypVoQ/TDsU8dgnpBt/w8ngtbGWQShBt3v6QYPW/TrUGEln VvQ16Ddz27GMTGK4hj+Px+LmGbEJLOsRr2DbKHwtvJ0f43jTLg== X-Google-Smtp-Source: ABdhPJyfUtpO5UT0r10ZAN8DhejPm/iA1+mmhfu1qTMmed5IP9gUxI+0kX4g7Zp/JGUiLiLBZGX1o6pBt5mPLZQHPd0= X-Received: by 2002:a67:e248:: with SMTP id w8mr3926052vse.33.1601744086566; Sat, 03 Oct 2020 09:54:46 -0700 (PDT) MIME-Version: 1.0 References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <047be764-8203-ca46-7ee1-6f84f7bf2356@cisco.com> In-Reply-To: <047be764-8203-ca46-7ee1-6f84f7bf2356@cisco.com> From: Gyan Mishra Date: Sat, 3 Oct 2020 12:54:35 -0400 Message-ID: To: Peter Psenak Cc: Jeff Tantsura , Ron Bonica , Yingzhen Qu , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004d093a05b0c71bff" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 16:54:50 -0000 --0000000000004d093a05b0c71bff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Peter for the responses to help clear up my flex algo understanding!= ! On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak wrote: > Gyan, > > > > On 03/10/2020 02:14, Gyan Mishra wrote: > > > > > > Hi Jeff > > > > > > From a domain perspective where you have a group of nodes and > > > associated IP addressed and SID are part of a discrete underlay instanc= e > > > flex algo topology. On those same set of nodes you could have another > > > topology and associated address and SIDs for a different flex algo. > > > > above is right. > Gyan> So per my response to Robert, what I was thinking is that as the algo 0 strict spf would be used as the base algo to provide reachability to all nodes within the domain and all neighbors are formed between all nodes in the domain to populate IGP rib providing base connectivity reachability. So then underneath of that you can have any subset of nodes out of the superset all top layer domain nodes level that can run any other algo desired. Basically creating algo layers under the top domain wide layer. > > > > > How > > > this would work is that the topologies would have to be segregated from > > > each other as different MT instances or routing process instances. Is > > > that correct? > > > > no MT at all. You can think of each flex-algo as a set of constraints > > that is used to calculate the path over the common topology. You can > > have many such felx-algos running on a common topology. > > Gyan> Is it safe to say that we can think of it as RSVP TE =E2=80=9Clik= e=E2=80=9D cSPF constraints that we are build via traffic engineering PCALC algorithms to run for dynamic LSP dyamic ERO that is built based on IGP constraints from TEDs database of TE link attributes and TE or IGP weights metric constraints to create the dynamic LSP path. So we could think of in TE framework analogy to flex algo In the per VRF TE next hop vpn coloring use case with different loopback next hop rewrite per VRF that normal IGP non TE BAU VPNs traffic would be like the flex algo base strict algo 0 and the non zero discrete algo would be like the per VRF next hop loopback rewrite where each per VRF te loopback rewrite would be a different steering non zero discrete flex algo all running in parallel as ships in the night with the base algo 0. Sorry for the complex analogy but I think I am getting it!!=F0=9F=98=83 Does a flex algo use case draft exist and if not I would not mind using the analogy I said above and build out a use case draft. Cheers! =F0=9F=98=8A > > > > > > > > Can two nodes that run two different flex algo become ospf or isis > > > neighbors? > > > > absolutely. > > > > Peter > > > > > > > > Kind Regards > > > > > > Gyan > > > > > > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Yingzhen, > > > > > > > > > > > > > > > > > > Yes, that=E2=80=99s the case. The most important property of an al= go > > > computed path is that is has to be consecutive, as either SID or IP > > > address associated with a particular topology is only known within > > > that topology. > > > > > > > > > Looking specifically at Ron=E2=80=99s draft (MPLS could be more com= plex due > > > to potential hierarchy) - the prefix itself defines the > > > context(topology) and must be globally unique, since IPv4 header > > > can=E2=80=99t have any additional meta-data attached. > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu > > > >, > wrote: > > > > > > > > >> Hi Peter, > > >> > > >> > > >> > > >> > > >> > > >> My understanding of flex-algo is that for traffic destined to a > > >> prefix on a particular algo, it can only be routed on routers > > >> belong to that algo, which also means only routers in that algo > > >> calculates how to reach that prefix and install it into the > > >> routing table. It seems to me that using flex-algo (section 12 of > > >> the draft) it's possible to have a loopback address associated > > >> with only one algo, please correct me if I'm missing or > > >> misunderstood something. > > >> > > >> > > >> > > >> > > >> > > >> Thanks, > > >> > > >> > > >> Yingzhen > > >> > > >> > > >> > > >> > > >> > > >> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > > >> on behalf of > > >> ppsenak=3D40cisco.com@dmarc.ietf.org > > >> > wrote: > > >> > > >> > > >> > > >> > > >> > > >> Gyan, > > >> > > >> > > >> > > >> > > >> > > >> On 02/10/2020 18:30, Gyan Mishra wrote: > > >> > > >> > > >>> All, > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> With SRv6 and IP based flex algo a generic question as it applies > to > > >>> > > >>> > > >>> both. Is it possible to have within a single IGP domain different > > >>> sets > > >>> > > >>> > > >>> of nodes or segments of the network running different algorithms. > > >> > > >> > > >> > > >> > > >> > > >> absolutely. > > >> > > >> > > >> > > >> > > >> > > >>> From > > >>> > > >>> > > >>> both drafts it sounds like all nodes have to agree on same > algorithm > > >>> > > >>> > > >>> similar to concept of metric and reference bandwidth all have to > have > > >>> > > >>> > > >>> the same style metric and play to the same sheet of music. > > >> > > >> > > >> > > >> > > >> > > >> all participating nodes need to agree on the definition of the > > >> flex-algo > > >> > > >> > > >> and advertise the participation. That's it. > > >> > > >> > > >> > > >> > > >> > > >>> If there was > > >>> > > >>> > > >>> a way to use multiple algorithms simultaneously based on SFC or > > >>> services > > >>> > > >>> > > >>> and instantiation of specific algorithm based on service to be > > >>> > > >>> > > >>> rendered. Doing so without causing a routing loop or sub optimal > > >>> > > >>> > > >>> routing. > > >> > > >> > > >> > > >> > > >> > > >> you can certainly use multiple algorithms simultaneously and use > algo > > >> > > >> > > >> specific paths to forward specific traffic over it. How that is do= ne > > >> > > >> > > >> from the forwarding perspective depends in which forwarding plane > you > > >> > > >> > > >> use. Flex-algo control plane is independent of the forwarding plan= e. > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >>> I thought with flex algo that there exists a feature that on > > >>> > > >>> > > >>> each hop there is a way to specify which algo to use hop by hop > > >>> similar > > >>> > > >>> > > >>> to a hop by hop policy based routing. > > >> > > >> > > >> > > >> > > >> > > >> no, there is no hop-by-hop classification, that is problematic and > > >> does > > >> > > >> > > >> not scale for high speeds. Classification is done at the ingress > only. > > >> > > >> > > >> > > >> > > >> > > >> thanks, > > >> > > >> > > >> Peter > > >> > > >> > > >> > > >> > > >> > > >>> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> > > >> > > >> Lsr mailing list > > >> > > >> > > >> Lsr@ietf.org > > >> > > >> > > >> > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Flsr&data=3D02%7C01%7Cyingzhen.qu%40futur= ewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591f= edc%7C1%7C0%7C637372537869296887&sdata=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL7z= LjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=3D0 > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > *Gyan Mishra* > > > > > > /Network Solutions A//rchitect / > > > > > > /M 301 502-1347 > > > 13101 Columbia Pike > > > /Silver Spring, MD > > > > > > > > > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000004d093a05b0c71bff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Peter for the responses to help cle= ar up my flex algo understanding!!

On Sat, Oct 3, 2020 at 5:45 AM Peter= Psenak <ppsenak@cisco.com> = wrote:
Gyan,



On 03/10/2020 02:14, = Gyan Mishra wrote:

>

> Hi =C2=A0Jeff

>
<= br>>=C2=A0 From a domain perspective where you have a group of nodes and=

> associated IP addressed and SID are part of a discrete underl= ay instance

> flex algo topology.=C2=A0 On those same set of nod= es you could have another

> topology and associated address and = SIDs for a different flex algo.=C2=A0



above is right.

=C2=A0 =C2=A0Gyan&= gt; =C2=A0So per my response to Robert, what=C2=A0=C2=A0I was thinking is that as the= algo 0 strict spf would be used as the base algo to provide reachability t= o all nodes within the domain and all neighbors are formed between all node= s in the domain to populate IGP rib providing base connectivity reachabilit= y.=C2=A0 So then underneath of that you can have any subset of nodes out of= the superset all top layer domain nodes level =C2=A0that can run any other= algo desired. Basically creating algo layers under the top domain wide lay= er.



> How

> this wou= ld work is that the topologies would have to be segregated from

>= ; each other as different MT instances or routing process instances.=C2=A0 = Is

> that correct?



no MT at all. You can think of= each flex-algo as a set of constraints

that is used to calculate t= he path over the common topology. You can

have many such felx-algos= running on a common topology.


=C2=A0 =C2=A0 Gyan> Is it safe to say that we can = think of it as RSVP TE =E2=80=9Clike=E2=80=9D cSPF constraints that we are = build via traffic engineering PCALC algorithms to run for dynamic LSP dyami= c ERO that is built based on IGP constraints from TEDs database of TE link = attributes and TE or IGP weights metric constraints to create the dynamic L= SP path.=C2=A0 So we could think of in TE framework analogy to flex algo In= the per VRF TE next hop vpn coloring use case with different loopback next= hop rewrite per VRF that normal IGP non TE BAU VPNs traffic would be like = the flex algo base strict algo 0 and the non zero discrete algo would be li= ke the per VRF next hop loopback rewrite where each per VRF te loopback rew= rite would be a different steering non zero discrete flex algo all running = in parallel as ships in the night with the base algo 0. =C2=A0 Sorry for th= e complex analogy but I think I am getting it!!=F0=9F=98=83

Does a flex algo use case draft exist= and if not I would not mind using the analogy I said above and build out a= use case draft.=C2=A0 Cheers! =F0=9F=98=8A


<= br>>

> Can two nodes that run two different flex algo become = ospf or isis

> neighbors?



absolutely.


=
Peter



>

> Kind Regards

>
> Gyan

>

> On Fri, Oct 2, 2020 at 6:25 PM Jeff Tan= tsura <jeff= tant.ietf@gmail.com

> <mailto:jefftant.ietf@gmail.com>> wrote= :

>

>

>

>

>

&= gt;

>

>

>

>

>
>

>

>=C2=A0 =C2=A0 =C2=A0Hi Yingzhen,

>= ;

>

>

>

>

>=C2=A0 = =C2=A0 =C2=A0Yes, that=E2=80=99s the case.=C2=A0=C2=A0The most important pr= operty of an algo

>=C2=A0 =C2=A0 =C2=A0computed path is that is h= as to be consecutive, as either SID or IP

>=C2=A0 =C2=A0 =C2=A0ad= dress associated with a particular topology is only known within

>= ;=C2=A0 =C2=A0 =C2=A0that topology.

>

>

>= =C2=A0 =C2=A0 =C2=A0Looking specifically at Ron=E2=80=99s draft (MPLS could= be more complex due

>=C2=A0 =C2=A0 =C2=A0to potential hierarchy)= - the prefix itself defines the

>=C2=A0 =C2=A0 =C2=A0context(top= ology) and must be globally unique, since IPv4 header

>=C2=A0 =C2= =A0 =C2=A0can=E2=80=99t have any additional meta-data attached.

>=

>

>

>

>

>

&= gt;

>=C2=A0 =C2=A0 =C2=A0Cheers,

>

>=C2=A0 = =C2=A0 =C2=A0Jeff

>

>

>

>
>

>

>=C2=A0 =C2=A0 =C2=A0On Oct 2, 2020, 1:15 PM= -0700, Yingzhen Qu

>=C2=A0 =C2=A0 =C2=A0<yingzhen.qu@futurewei.com &l= t;mailto:yin= gzhen.qu@futurewei.com>>, wrote:

>

>
>>=C2=A0 =C2=A0 =C2=A0Hi Peter,

>>

>>
<= br>>>

>>

>>

>>=C2=A0 =C2=A0 = =C2=A0My understanding of flex-algo is that for traffic destined to a
>>=C2=A0 =C2=A0 =C2=A0prefix on a particular algo, it can only be r= outed on routers

>>=C2=A0 =C2=A0 =C2=A0belong to that algo, wh= ich also means only routers in that algo

>>=C2=A0 =C2=A0 =C2= =A0calculates how to reach that prefix and install it into the

>&= gt;=C2=A0 =C2=A0 =C2=A0routing table. It seems to me that using flex-algo (= section 12 of

>>=C2=A0 =C2=A0 =C2=A0the draft) it's possib= le to have a loopback address associated

>>=C2=A0 =C2=A0 =C2= =A0with only one algo, please correct me if I'm missing or

>&= gt;=C2=A0 =C2=A0 =C2=A0misunderstood something.

>>

>= >

>>

>>

>>

>>=C2=A0 = =C2=A0 =C2=A0Thanks,

>>

>>

>>=C2=A0 = =C2=A0 =C2=A0Yingzhen

>>

>>

>>
>>

>>

>>=C2=A0 =C2=A0 =C2=A0On 10/2/20, 9= :43 AM, "Lsr on behalf of Peter Psenak"

>>=C2=A0 =C2= =A0 =C2=A0<lsr= -bounces@ietf.org <mailto:lsr-bounces@ietf.org> on behalf of

>>= =C2=A0 =C2=A0 =C2=A0ppsenak=3D40cisco.com@dmarc.ietf.org

>>=C2=A0 =C2= =A0 =C2=A0<mailto:40cisco.com@dmarc.ietf.org>> wrote:

>>
>>

>>

>>

>>

>&= gt;=C2=A0 =C2=A0 =C2=A0Gyan,

>>

>>

>>= ;

>>

>>

>>=C2=A0 =C2=A0 =C2=A0On 02/= 10/2020 18:30, Gyan Mishra wrote:

>>

>>

&g= t;>>=C2=A0 =C2=A0 =C2=A0All,

>>>

>>><= br>
>>>

>>>

>>>

>>= >=C2=A0 =C2=A0 =C2=A0With SRv6 and IP based flex algo a generic question= as it applies to

>>>

>>>

>>&g= t;=C2=A0 =C2=A0 =C2=A0both. Is it possible to have within a single IGP doma= in different

>>>=C2=A0 =C2=A0 =C2=A0sets

>>>= ;

>>>

>>>=C2=A0 =C2=A0 =C2=A0of nodes or se= gments of the network running different algorithms.

>>

= >>

>>

>>

>>

>>=C2= =A0 =C2=A0 =C2=A0absolutely.

>>

>>

>>= ;

>>

>>

>>>=C2=A0 =C2=A0 =C2=A0Fr= om

>>>

>>>

>>>=C2=A0 =C2=A0= =C2=A0both drafts it sounds like all nodes have to agree on same algorithm=

>>>

>>>

>>>=C2=A0 =C2=A0 = =C2=A0similar to concept of metric and reference bandwidth all have to have=

>>>

>>>

>>>=C2=A0 =C2=A0 = =C2=A0the same style metric and play to the same sheet of music.

>= ;>

>>

>>

>>

>>
>>=C2=A0 =C2=A0 =C2=A0all participating nodes need to agree on the = definition of the

>>=C2=A0 =C2=A0 =C2=A0flex-algo

>&= gt;

>>

>>=C2=A0 =C2=A0 =C2=A0and advertise the pa= rticipation. That's it.

>>

>>

>>=

>>

>>

>>>=C2=A0 =C2=A0 =C2=A0If = there was

>>>

>>>

>>>=C2=A0= =C2=A0 =C2=A0a way to use multiple algorithms simultaneously based on SFC = or

>>>=C2=A0 =C2=A0 =C2=A0services

>>>
<= br>>>>

>>>=C2=A0 =C2=A0 =C2=A0and instantiation of= specific algorithm based on service to be

>>>

>&= gt;>

>>>=C2=A0 =C2=A0 =C2=A0rendered. Doing so without c= ausing a routing loop or sub optimal

>>>

>>>= ;

>>>=C2=A0 =C2=A0 =C2=A0routing.

>>

&g= t;>

>>

>>

>>

>>=C2= =A0 =C2=A0 =C2=A0you can certainly use multiple algorithms simultaneously a= nd use algo

>>

>>

>>=C2=A0 =C2=A0 = =C2=A0specific paths to forward specific traffic over it. How that is done<= br>
>>

>>

>>=C2=A0 =C2=A0 =C2=A0from the= forwarding perspective depends in which forwarding plane you

>&g= t;

>>

>>=C2=A0 =C2=A0 =C2=A0use. Flex-algo contro= l plane is independent of the forwarding plane.

>>

>= >

>>

>>

>>

>>
>>

>>

>>>=C2=A0 =C2=A0 =C2=A0I thought = with flex algo that there exists a feature that on

>>>
<= br>>>>

>>>=C2=A0 =C2=A0 =C2=A0each hop there is a = way to specify which algo to use hop by hop

>>>=C2=A0 =C2= =A0 =C2=A0similar

>>>

>>>

>>&g= t;=C2=A0 =C2=A0 =C2=A0to a hop by hop policy based routing.

>>=

>>

>>

>>

>>

>= ;>=C2=A0 =C2=A0 =C2=A0no, there is no hop-by-hop classification, that is= problematic and

>>=C2=A0 =C2=A0 =C2=A0does

>>
>>

>>=C2=A0 =C2=A0 =C2=A0not scale for high speeds.= Classification is done at the ingress only.

>>

>>= ;

>>

>>

>>

>>=C2=A0 =C2= =A0 =C2=A0thanks,

>>

>>

>>=C2=A0 =C2= =A0 =C2=A0Peter

>>

>>

>>

>= >

>>

>>>

>>

>>
>>

>>

>>

>>=C2=A0 =C2=A0 = =C2=A0_______________________________________________

>>
>>

>>=C2=A0 =C2=A0 =C2=A0Lsr mailing list

>&= gt;

>>

>>=C2=A0 =C2=A0 =C2=A0Lsr@ietf.org <mailto:Lsr@ietf.org>

>>
>>

>>=C2=A0 =C2=A0 =C2=A0h= ttps://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Flsr&amp;data=3D02%7C01%7Cyingzhen.qu%40futu= rewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591= fedc%7C1%7C0%7C637372537869296887&amp;sdata=3DR%2FI%2BAUkcw12FmgDtsh%2F= BOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&amp;reserved=3D0

>>
>>

>>

>

>

>
>

>

>

>

>

> -- <= br>
>

> <http://www.verizon.com/>

>
=
> *Gyan Mishra*

>

> /Network Solutions A//rchit= ect /

>

> /M 301 502-1347

> 13101 Columbia P= ike

> /Silver Spring, MD

>

>


--
--0000000000004d093a05b0c71bff-- From nobody Sat Oct 3 10:45:56 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1071E3A0C9A for ; Sat, 3 Oct 2020 10:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 PP_RXB0WRsB9 for ; Sat, 3 Oct 2020 10:45:52 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 057993A0C94 for ; Sat, 3 Oct 2020 10:45:52 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id e62so2077548vsc.10 for ; Sat, 03 Oct 2020 10:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RmfKJVlLh/c3051kmiG2P+vN96RYV4AvRw/6eJpbYKU=; b=KpbZukmgXbUCL59ZGJWGZ6hoMvW/4sbuFDlv4BnrEqKx+NusIF5+9VLmV4/dIoI4SH qR6TFCu1R7dbjUA5O6ODMZGriKoXnDXAGEMclKlNuNGRl+1yzFFV8rSrdPfOEcHEiFid mLNJS31nx+vp8bx5aRkHo+5ihfX4H4xqG/66wnqGs6KSITjMlzuWjtCX6NWjGOFVU5r+ xgzUsjdVTvkvuxPhj5X3EfkTxuPv+XRWhYoPT2tBeyqCb3zTVDM9kGtn6/bXZMMcDzsp VDMdl7w2NZdT2qp5dJ1ooE1B65UH3DEVfxNVvAg+hEma984fNQWapVt2O7VzERRbmWrR AGeg== 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=RmfKJVlLh/c3051kmiG2P+vN96RYV4AvRw/6eJpbYKU=; b=sIebeJiphCojKUTC6OvwU9Ab7rPM59jVC/bHZ8GKOJkhVdCFzyAM96Tyoc2CaDrrvb xNhrfb6EEiS6fEl1wheBZDvLaiIRd1+qwyv97lM/yk2s9FYh5FYjSKAM+QEhEkFmXfIu N27pN+pPA/CxjcblX6X4f8gMzW5T6volwgs+GjxPofF/hlBF6mkdEoLSXb2Y24iTmeug NdAbVNBzlkq/JjzG1J7fo/GJ8CiMd7QG4jQYGGhXodJQ5sbJm2nhNBalxeDAsuussy22 FSkKSSJaWI+dmlJrNUuLheBvxjI7Pe/qLT8+jmBPsibpALZ1Gx4oCLQJsRfIKw6c8gSC ZLUw== X-Gm-Message-State: AOAM532Zob6wxC+7+A0xwOuvhtMEqeLPQbNAAL69864nph9PqtpjY0Hl oggvSA5ZrYSwj2QwU0tS3VFv3uSYDFPkyoRcvSc= X-Google-Smtp-Source: ABdhPJzTkPmjFFQrhIbL3CE+QPVD5HvYlMT6GbnV99TsB+l150Ki2hrcCl7uMaS7C8PX1eCH0buAH75DOqkiGdlpRbY= X-Received: by 2002:a67:e248:: with SMTP id w8mr3982491vse.33.1601747150984; Sat, 03 Oct 2020 10:45:50 -0700 (PDT) MIME-Version: 1.0 References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <047be764-8203-ca46-7ee1-6f84f7bf2356@cisco.com> In-Reply-To: From: Gyan Mishra Date: Sat, 3 Oct 2020 13:25:51 -0400 Message-ID: To: Peter Psenak Cc: Jeff Tantsura , Ron Bonica , Yingzhen Qu , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f4577f05b0c7d162" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 17:45:55 -0000 --000000000000f4577f05b0c7d162 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would think Ron=E2=80=99s IP data plane based flex algo would work identi= cal to SR data plane based flex algo with the base Strict algo 0 providing top layer all node reachability and would contain let=E2=80=99s say loopback0. = The algo would have algo and algo # definition on the loopback so the nodes are reachability the discrete non zero algo loopback for the corresponding loopbacks that correlate with algo xyz for the xyz topology. In both IP based algo and the SR based algo would the SR locator or IP based algo be in the BAU base to layer topology SRv6-BE let=E2=80=99s say and SRv6-TE SLA= SRH steered would map to non zero algorithms per VRF VPN coloring and would IP based algo do the same. The advent of SR came about filling a much needed gap for operators to provide RSVP TE style per VRF coloring without the added badge of loopback xyz rewrite for the static route coloring issue that you need a separate loopback and static route to RSVP tunnel to steer each per VRF per vpn colored TE tunnel - as you can see with RSVP coloring you have a 1-1 mapping discrete loopback per per VRF steered TE tunnel. So then along came SR to save the day ..end of story.. Back to flex algo ..so SR has the per VRF coloring capability with SR data plane to provide the coloring. I think I maybe confusing to topics as the per VRF TE coloring is using underlay to steer overlay so flex algo is in the underlay so you could do the same SR-TE flex algo steering of underlay thereby steering vpn overlay under pinning of underlay to overlay. How would that be done with IP based flex algo. So with IP based flex algo as well you would be global table routing with no VPN framework. Thanks Gyan On Sat, Oct 3, 2020 at 12:54 PM Gyan Mishra wrote: > > Thanks Peter for the responses to help clear up my flex algo > understanding!! > > On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak wrote: > >> Gyan, >> >> >> >> On 03/10/2020 02:14, Gyan Mishra wrote: >> >> > >> >> > Hi Jeff >> >> > >> >> > From a domain perspective where you have a group of nodes and >> >> > associated IP addressed and SID are part of a discrete underlay >> instance >> >> > flex algo topology. On those same set of nodes you could have another >> >> > topology and associated address and SIDs for a different flex algo. >> >> >> >> above is right. >> > > Gyan> So per my response to Robert, what I was thinking is that as > the algo 0 strict spf would be used as the base algo to provide > reachability to all nodes within the domain and all neighbors are formed > between all nodes in the domain to populate IGP rib providing base > connectivity reachability. So then underneath of that you can have any > subset of nodes out of the superset all top layer domain nodes level tha= t > can run any other algo desired. Basically creating algo layers under the > top domain wide layer. > >> >> >> >> > How >> >> > this would work is that the topologies would have to be segregated fro= m >> >> > each other as different MT instances or routing process instances. Is >> >> > that correct? >> >> >> >> no MT at all. You can think of each flex-algo as a set of constraints >> >> that is used to calculate the path over the common topology. You can >> >> have many such felx-algos running on a common topology. >> >> > Gyan> Is it safe to say that we can think of it as RSVP TE =E2=80=9Cl= ike=E2=80=9D cSPF > constraints that we are build via traffic engineering PCALC algorithms to > run for dynamic LSP dyamic ERO that is built based on IGP constraints fro= m > TEDs database of TE link attributes and TE or IGP weights metric > constraints to create the dynamic LSP path. So we could think of in TE > framework analogy to flex algo In the per VRF TE next hop vpn coloring us= e > case with different loopback next hop rewrite per VRF that normal IGP non > TE BAU VPNs traffic would be like the flex algo base strict algo 0 and th= e > non zero discrete algo would be like the per VRF next hop loopback rewrit= e > where each per VRF te loopback rewrite would be a different steering non > zero discrete flex algo all running in parallel as ships in the night wit= h > the base algo 0. Sorry for the complex analogy but I think I am getting > it!!=F0=9F=98=83 > > Does a flex algo use case draft exist and if not I would not mind using > the analogy I said above and build out a use case draft. Cheers! =F0=9F= =98=8A > >> >> >> >> > >> >> > Can two nodes that run two different flex algo become ospf or isis >> >> > neighbors? >> >> >> >> absolutely. >> >> >> >> Peter >> >> >> >> > >> >> > Kind Regards >> >> > >> >> > Gyan >> >> > >> >> > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura > >> > > wrote: >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > Hi Yingzhen, >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > Yes, that=E2=80=99s the case. The most important property of an a= lgo >> >> > computed path is that is has to be consecutive, as either SID or I= P >> >> > address associated with a particular topology is only known within >> >> > that topology. >> >> > >> >> > >> >> > Looking specifically at Ron=E2=80=99s draft (MPLS could be more co= mplex due >> >> > to potential hierarchy) - the prefix itself defines the >> >> > context(topology) and must be globally unique, since IPv4 header >> >> > can=E2=80=99t have any additional meta-data attached. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > Cheers, >> >> > >> >> > Jeff >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu >> >> > >, >> wrote: >> >> > >> >> > >> >> >> Hi Peter, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> My understanding of flex-algo is that for traffic destined to a >> >> >> prefix on a particular algo, it can only be routed on routers >> >> >> belong to that algo, which also means only routers in that algo >> >> >> calculates how to reach that prefix and install it into the >> >> >> routing table. It seems to me that using flex-algo (section 12 of >> >> >> the draft) it's possible to have a loopback address associated >> >> >> with only one algo, please correct me if I'm missing or >> >> >> misunderstood something. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> >> >> >> >> Yingzhen >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >> >> >> on behalf of >> >> >> ppsenak=3D40cisco.com@dmarc.ietf.org >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Gyan, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 02/10/2020 18:30, Gyan Mishra wrote: >> >> >> >> >> >> >> >> >>> All, >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> With SRv6 and IP based flex algo a generic question as it applie= s >> to >> >> >>> >> >> >>> >> >> >>> both. Is it possible to have within a single IGP domain differen= t >> >> >>> sets >> >> >>> >> >> >>> >> >> >>> of nodes or segments of the network running different algorithms= . >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> absolutely. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> From >> >> >>> >> >> >>> >> >> >>> both drafts it sounds like all nodes have to agree on same >> algorithm >> >> >>> >> >> >>> >> >> >>> similar to concept of metric and reference bandwidth all have to >> have >> >> >>> >> >> >>> >> >> >>> the same style metric and play to the same sheet of music. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> all participating nodes need to agree on the definition of the >> >> >> flex-algo >> >> >> >> >> >> >> >> >> and advertise the participation. That's it. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> If there was >> >> >>> >> >> >>> >> >> >>> a way to use multiple algorithms simultaneously based on SFC or >> >> >>> services >> >> >>> >> >> >>> >> >> >>> and instantiation of specific algorithm based on service to be >> >> >>> >> >> >>> >> >> >>> rendered. Doing so without causing a routing loop or sub optimal >> >> >>> >> >> >>> >> >> >>> routing. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> you can certainly use multiple algorithms simultaneously and use >> algo >> >> >> >> >> >> >> >> >> specific paths to forward specific traffic over it. How that is >> done >> >> >> >> >> >> >> >> >> from the forwarding perspective depends in which forwarding plane >> you >> >> >> >> >> >> >> >> >> use. Flex-algo control plane is independent of the forwarding >> plane. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> I thought with flex algo that there exists a feature that on >> >> >>> >> >> >>> >> >> >>> each hop there is a way to specify which algo to use hop by hop >> >> >>> similar >> >> >>> >> >> >>> >> >> >>> to a hop by hop policy based routing. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> no, there is no hop-by-hop classification, that is problematic an= d >> >> >> does >> >> >> >> >> >> >> >> >> not scale for high speeds. Classification is done at the ingress >> only. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> thanks, >> >> >> >> >> >> >> >> >> Peter >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> >> >> >> >> >> Lsr mailing list >> >> >> >> >> >> >> >> >> Lsr@ietf.org >> >> >> >> >> >> >> >> >> >> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fmailman%2Flistinfo%2Flsr&data=3D02%7C01%7Cyingzhen.qu%40futu= rewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591= fedc%7C1%7C0%7C637372537869296887&sdata=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL7= zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=3D0 >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > >> >> > >> >> > >> >> > *Gyan Mishra* >> >> > >> >> > /Network Solutions A//rchitect / >> >> > >> >> > /M 301 502-1347 >> >> > 13101 Columbia Pike >> >> > /Silver Spring, MD >> >> > >> >> > >> >> >> >> -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000f4577f05b0c7d162 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


I would think = Ron=E2=80=99s IP data plane based flex algo would work identical to SR data= plane based flex algo with the base Strict =C2=A0algo 0 providing top laye= r all node reachability and would contain let=E2=80=99s say loopback0.=C2= =A0 The algo would have algo and algo # definition on the loopback so the n= odes are reachability the discrete non zero algo loopback =C2=A0for the cor= responding loopbacks that correlate with algo xyz for the xyz topology.=C2= =A0 In both IP based algo and the SR based algo would the SR locator or IP = based algo be in the BAU base to layer topology SRv6-BE let=E2=80=99s say a= nd SRv6-TE SLA SRH steered would map to non zero algorithms per VRF VPN col= oring and =C2=A0would IP based algo do the same. =C2=A0

--
The advent of SR came about filling a much = needed gap for operators to provide RSVP TE style per VRF coloring without = the added badge of loopback xyz rewrite for the static route coloring issue= that you need a separate loopback and static route to RSVP tunnel to steer= each per VRF per vpn colored TE tunnel - as you can see with RSVP coloring= you have a 1-1 mapping discrete loopback per per VRF steered TE tunnel.

So then along came SR to s= ave the day ..end of story..

Back to flex algo ..so SR has the per VRF coloring capability with SR = data plane to provide the coloring.

I think I maybe confusing to topics as the per VRF TE coloring = is using underlay to steer overlay so flex algo is in the underlay so you c= ould do the same SR-TE flex algo steering of underlay thereby steering vpn = overlay under pinning of underlay to overlay.

How would that be done with IP based flex algo.=C2=A0=

So with IP based flex a= lgo as well you would be global table routing with no VPN framework.
<= div dir=3D"auto">
Thanks=C2=A0

Gyan

On Sat, Oct 3, 2020 at 12:54 PM = Gyan Mishra <hayabusagsm@gmail.= com> wrote:

Thanks Peter for the responses to help clear up my flex algo understandi= ng!!

On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak <ppsenak@cisco.com> wrote:
Gyan,



On 03/10/2020 02:14, Gyan Mishra = wrote:

>

> Hi =C2=A0Jeff

>

>=C2= =A0 From a domain perspective where you have a group of nodes and

&= gt; associated IP addressed and SID are part of a discrete underlay instanc= e

> flex algo topology.=C2=A0 On those same set of nodes you cou= ld have another

> topology and associated address and SIDs for a= different flex algo.=C2=A0



above is right.

=C2=A0 =C2=A0Gyan> =C2=A0= So per my response to Robert, what=C2=A0=C2=A0I was thinking is that as the algo 0 st= rict spf would be used as the base algo to provide reachability to all node= s within the domain and all neighbors are formed between all nodes in the d= omain to populate IGP rib providing base connectivity reachability.=C2=A0 S= o then underneath of that you can have any subset of nodes out of the super= set all top layer domain nodes level =C2=A0that can run any other algo desi= red. Basically creating algo layers under the top domain wide layer.=



> How

> this would work is= that the topologies would have to be segregated from

> each oth= er as different MT instances or routing process instances.=C2=A0 Is
> that correct?



no MT at all. You can think of each flex= -algo as a set of constraints

that is used to calculate the path ov= er the common topology. You can

have many such felx-algos running o= n a common topology.


=C2=A0 =C2=A0 Gyan> Is it safe to say that we can think of i= t as RSVP TE =E2=80=9Clike=E2=80=9D cSPF constraints that we are build via = traffic engineering PCALC algorithms to run for dynamic LSP dyamic ERO that= is built based on IGP constraints from TEDs database of TE link attributes= and TE or IGP weights metric constraints to create the dynamic LSP path.= =C2=A0 So we could think of in TE framework analogy to flex algo In the per= VRF TE next hop vpn coloring use case with different loopback next hop rew= rite per VRF that normal IGP non TE BAU VPNs traffic would be like the flex= algo base strict algo 0 and the non zero discrete algo would be like the p= er VRF next hop loopback rewrite where each per VRF te loopback rewrite wou= ld be a different steering non zero discrete flex algo all running in paral= lel as ships in the night with the base algo 0. =C2=A0 Sorry for the comple= x analogy but I think I am getting it!!=F0=9F=98=83
=
Does a flex algo use case draft exist and if no= t I would not mind using the analogy I said above and build out a use case = draft.=C2=A0 Cheers! =F0=9F=98=8A



>

> Can two nodes that r= un two different flex algo become ospf or isis

> neighbors?
<= br>

absolutely.



Peter



>

>= ; Kind Regards

>

> Gyan

>

> On Fr= i, Oct 2, 2020 at 6:25 PM Jeff Tantsura <jefftant.ietf@gmail.com

> <= mailto:jefftan= t.ietf@gmail.com>> wrote:

>

>

> <= br>
>

>

>

>

>

>= ;

>

>

>

>

>=C2=A0 = =C2=A0 =C2=A0Hi Yingzhen,

>

>

>

>= ;

>

>=C2=A0 =C2=A0 =C2=A0Yes, that=E2=80=99s the case= .=C2=A0=C2=A0The most important property of an algo

>=C2=A0 =C2= =A0 =C2=A0computed path is that is has to be consecutive, as either SID or = IP

>=C2=A0 =C2=A0 =C2=A0address associated with a particular topo= logy is only known within

>=C2=A0 =C2=A0 =C2=A0that topology.
=
>

>

>=C2=A0 =C2=A0 =C2=A0Looking specifically = at Ron=E2=80=99s draft (MPLS could be more complex due

>=C2=A0 = =C2=A0 =C2=A0to potential hierarchy) - the prefix itself defines the
>=C2=A0 =C2=A0 =C2=A0context(topology) and must be globally unique, sin= ce IPv4 header

>=C2=A0 =C2=A0 =C2=A0can=E2=80=99t have any additi= onal meta-data attached.

>

>

>

>=

>

>

>

>=C2=A0 =C2=A0 =C2=A0Che= ers,

>

>=C2=A0 =C2=A0 =C2=A0Jeff

>

&= gt;

>

>

>

>

>=C2=A0 = =C2=A0 =C2=A0On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu

>=C2=A0 = =C2=A0 =C2=A0<yingzhen.qu@futurewei.com <mailto:yingzhen.qu@futurewei.com>>, wr= ote:

>

>

>>=C2=A0 =C2=A0 =C2=A0Hi Peter,=

>>

>>

>>

>>

>= ;>

>>=C2=A0 =C2=A0 =C2=A0My understanding of flex-algo is t= hat for traffic destined to a

>>=C2=A0 =C2=A0 =C2=A0prefix on = a particular algo, it can only be routed on routers

>>=C2=A0 = =C2=A0 =C2=A0belong to that algo, which also means only routers in that alg= o

>>=C2=A0 =C2=A0 =C2=A0calculates how to reach that prefix an= d install it into the

>>=C2=A0 =C2=A0 =C2=A0routing table. It = seems to me that using flex-algo (section 12 of

>>=C2=A0 =C2= =A0 =C2=A0the draft) it's possible to have a loopback address associate= d

>>=C2=A0 =C2=A0 =C2=A0with only one algo, please correct me = if I'm missing or

>>=C2=A0 =C2=A0 =C2=A0misunderstood some= thing.

>>

>>

>>

>>
<= br>>>

>>=C2=A0 =C2=A0 =C2=A0Thanks,

>>
<= br>>>

>>=C2=A0 =C2=A0 =C2=A0Yingzhen

>>
=
>>

>>

>>

>>

>>= ;=C2=A0 =C2=A0 =C2=A0On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psen= ak"

>>=C2=A0 =C2=A0 =C2=A0<lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org= > on behalf of

>>=C2=A0 =C2=A0 =C2=A0ppsenak=3D40cisco.com@dmarc.ietf.= org

>>=C2=A0 =C2=A0 =C2=A0<mailto:40cisco.com@dmarc.ietf.org&g= t;> wrote:

>>

>>

>>

>&g= t;

>>

>>=C2=A0 =C2=A0 =C2=A0Gyan,

>>=

>>

>>

>>

>>

>= ;>=C2=A0 =C2=A0 =C2=A0On 02/10/2020 18:30, Gyan Mishra wrote:

>= ;>

>>

>>>=C2=A0 =C2=A0 =C2=A0All,

&g= t;>>

>>>

>>>

>>>
<= br>>>>

>>>=C2=A0 =C2=A0 =C2=A0With SRv6 and IP bas= ed flex algo a generic question as it applies to

>>>
>>>

>>>=C2=A0 =C2=A0 =C2=A0both. Is it possible t= o have within a single IGP domain different

>>>=C2=A0 =C2= =A0 =C2=A0sets

>>>

>>>

>>>= =C2=A0 =C2=A0 =C2=A0of nodes or segments of the network running different a= lgorithms.

>>

>>

>>

>><= br>
>>

>>=C2=A0 =C2=A0 =C2=A0absolutely.

>&= gt;

>>

>>

>>

>>

= >>>=C2=A0 =C2=A0 =C2=A0From

>>>

>>>= ;

>>>=C2=A0 =C2=A0 =C2=A0both drafts it sounds like all nod= es have to agree on same algorithm

>>>

>>><= br>
>>>=C2=A0 =C2=A0 =C2=A0similar to concept of metric and ref= erence bandwidth all have to have

>>>

>>>
>>>=C2=A0 =C2=A0 =C2=A0the same style metric and play to the= same sheet of music.

>>

>>

>>
>>

>>

>>=C2=A0 =C2=A0 =C2=A0all participa= ting nodes need to agree on the definition of the

>>=C2=A0 =C2= =A0 =C2=A0flex-algo

>>

>>

>>=C2=A0 = =C2=A0 =C2=A0and advertise the participation. That's it.

>>= ;

>>

>>

>>

>>

&g= t;>>=C2=A0 =C2=A0 =C2=A0If there was

>>>

>&= gt;>

>>>=C2=A0 =C2=A0 =C2=A0a way to use multiple algori= thms simultaneously based on SFC or

>>>=C2=A0 =C2=A0 =C2=A0= services

>>>

>>>

>>>=C2=A0 = =C2=A0 =C2=A0and instantiation of specific algorithm based on service to be=

>>>

>>>

>>>=C2=A0 =C2=A0 = =C2=A0rendered. Doing so without causing a routing loop or sub optimal
<= br>>>>

>>>

>>>=C2=A0 =C2=A0 =C2=A0= routing.

>>

>>

>>

>>
>>

>>=C2=A0 =C2=A0 =C2=A0you can certainly use mult= iple algorithms simultaneously and use algo

>>

>>=

>>=C2=A0 =C2=A0 =C2=A0specific paths to forward specific traf= fic over it. How that is done

>>

>>

>&g= t;=C2=A0 =C2=A0 =C2=A0from the forwarding perspective depends in which forw= arding plane you

>>

>>

>>=C2=A0 =C2= =A0 =C2=A0use. Flex-algo control plane is independent of the forwarding pla= ne.

>>

>>

>>

>>

= >>

>>

>>

>>

>>>= ;=C2=A0 =C2=A0 =C2=A0I thought with flex algo that there exists a feature t= hat on

>>>

>>>

>>>=C2=A0 = =C2=A0 =C2=A0each hop there is a way to specify which algo to use hop by ho= p

>>>=C2=A0 =C2=A0 =C2=A0similar

>>>
>>>

>>>=C2=A0 =C2=A0 =C2=A0to a hop by hop policy= based routing.

>>

>>

>>

>= >

>>

>>=C2=A0 =C2=A0 =C2=A0no, there is no hop= -by-hop classification, that is problematic and

>>=C2=A0 =C2= =A0 =C2=A0does

>>

>>

>>=C2=A0 =C2=A0= =C2=A0not scale for high speeds. Classification is done at the ingress onl= y.

>>

>>

>>

>>

&= gt;>

>>=C2=A0 =C2=A0 =C2=A0thanks,

>>

&= gt;>

>>=C2=A0 =C2=A0 =C2=A0Peter

>>

>= ;>

>>

>>

>>

>>>
>>

>>

>>

>>

>&= gt;

>>=C2=A0 =C2=A0 =C2=A0____________________________________= ___________

>>

>>

>>=C2=A0 =C2=A0 = =C2=A0Lsr mailing list

>>

>>

>>=C2= =A0 =C2=A0 =C2=A0Lsr@ietf= .org <mailto:Lsr@i= etf.org>

>>

>>

>>=C2=A0 =C2= =A0 =C2=A0https://nam11.safelinks.protection.ou= tlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&= amp;data=3D02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d8= 66f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&am= p;amp;sdata=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&= amp;reserved=3D0

>>

>>

>>
>

>

>

>

>

>
=
>

>

> --

>

> <http://ww= w.verizon.com/>

>

> *Gyan Mishra*

> <= br>
> /Network Solutions A//rchitect /

>

> /M 30= 1 502-1347

> 13101 Columbia Pike

> /Silver Spring, MD
>

>



--

=

Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-134713101 Columbia Pike=C2=A0
Silver Spring, MD

<= br>


--
<= p style=3D"color:rgb(34,34,34)">

Gyan Mishra

Network Solutions A= rchitect=C2=A0

M 301 502-1347
13101 Columbia Pike= =C2=A0
Silver Spring, MD


=
--000000000000f4577f05b0c7d162-- From nobody Sat Oct 3 11:08:09 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675A93A0100 for ; Sat, 3 Oct 2020 11:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 HpMvKOX8mBd4 for ; Sat, 3 Oct 2020 11:08:05 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770092.outbound.protection.outlook.com [40.107.77.92]) (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 7BBB03A00E5 for ; Sat, 3 Oct 2020 11:08:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QmvO7+xAGlssmAuwtQcmrbg8ZKqpdlvga3Gx2pGO8Rw8P2i4QwVuOEp0V8w2p8WtcmxSloOb9BbuirKIe8ACuxgp0kDf1J8KpQgg+BW9UEziCNd4qfyzf4c8z43dL67DA44Lz9RsZiUiXRA2Ja6HGqMYKm0hu9/KYdTNWn42BsgdJ9rO8RxLs5EGQGB3tn6c4lTFvJl6L4AK+cRfV1PVP3DmVl4j+Iltu+MAxaUOLi3JdSN2JM6nAlxyQh5CCMZsYHpaswZaZNsDR2ALP87ZJNxzoRshYKBZt3/xBA8vgzupLg7fn0jvnNpW6aLMp5vc59cm9xFyHpCz/aWh7UBgcQ== 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=2T9zkQaVri4AdZASl3ScGWx3LNEtFwgkVi2/xazvKYQ=; b=n+jRRh8SzP4UOMuCOlj+B+e+pb1z6gcDX3N5ShavVf+NN01WRSb/5RrR9fEbENrKRuuqMlsMVll58nSQ6nzTkOkpK7e5PxALWq+Kmg3hSC7uPi5ZpKxwlMf0ikRbXIL+GgpnwxHHKHNd2nbnA23cUvMSKzlkDBLq3+FUBWmxdVd8A9b/3S76OKFx4q7lX11t95jnScgSli/odm9b9mvvVaA3aVbvYR++Q7U+5M/pVyMm7E/EKH5it8qqNb2bQ1mVCDtLMUrbprm3HfGMqbnHSGjOEhtkf2TjPRXreaaOh85X2YyAah7CRVu50S7ziDpQ1UqPPVapEDwNkkT0OhNghg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2T9zkQaVri4AdZASl3ScGWx3LNEtFwgkVi2/xazvKYQ=; b=GsRyT8Y6JedKP0bednQDxv3VuzgrD8jx1KU7vCuik7gFFUHBXBfo1uZtxFXWCIvOeo51JRE2HBt1xEpzroyTmyGpgNgyIVDprD3YdaWTJ51fz01I+YD9VppvenIL54Ay/6l1q8pKbRiQ5ze/8qvoXFQ/MIdE691YGnhW2cWPTV8= Received: from BY5PR13MB3048.namprd13.prod.outlook.com (2603:10b6:a03:188::21) by BY5PR13MB3587.namprd13.prod.outlook.com (2603:10b6:a03:194::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.14; Sat, 3 Oct 2020 18:08:01 +0000 Received: from BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::381e:6640:d3a3:5034]) by BY5PR13MB3048.namprd13.prod.outlook.com ([fe80::381e:6640:d3a3:5034%5]) with mapi id 15.20.3455.016; Sat, 3 Oct 2020 18:08:01 +0000 From: Yingzhen Qu To: Peter Psenak , Gyan Mishra , Ron Bonica CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAGYiICAAB9mMIAA726AgADTSnCAAWzZgIAAAz2A///GWICAAVg7AIAAFmsA Date: Sat, 3 Oct 2020 18:08:01 +0000 Message-ID: <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> In-Reply-To: <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:646:9500:c900:580:ac8a:4587:58a0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bba9cff2-3d5a-4322-5735-08d867c74449 x-ms-traffictypediagnostic: BY5PR13MB3587: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0A5PLkcgYPtKuJTsfOzxYluxfYik9V7rUeedztOzdfZPHYc64oMiebj7lCnBjTClOkpZCLSYPIg2kPF+1dgKOEzepae9bqth+Lc0eq5XbHruIssTuDIxy5LLrsLW3+eAgC3hEmn/qyHvtuqJAxL49O7Z9nDLMqeMVxqUGq+OVfgpdiTghOPBMF2XjtmK21C8aOpsaynFGWvZyoHKVqBbTrZI7sRPIzaPfizd1/uLoBYGniwKH4deB964NLJ7Hj/cClgSYxaNIKIIxKRHLc/FpQVzUw0DRpOeIxxfD9TfkXSW6cn20Ho0zBAe4mksPq0PwjBIq5KJQDI0DZXbeOkuEBM1oi14WOk8Gz4aRiQcquUAxG6Ylv0GcqYz7+T6N8W+TR+G3ui1GckqWQ28FWqWKQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3048.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(136003)(366004)(376002)(39840400004)(186003)(71200400001)(45080400002)(76116006)(6506007)(66946007)(66556008)(64756008)(478600001)(53546011)(6486002)(110136005)(2616005)(66446008)(54906003)(83080400001)(66476007)(2906002)(36756003)(6512007)(8676002)(316002)(44832011)(86362001)(966005)(33656002)(5660300002)(8936002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /jO144ueTRTSm/f+UtleYB4H/JSHPT+jhmBWlDRZsLtfO1nV0z/V1qBUBVjFOFcSZSmAN2bSs08/3Jgtn/QiKlO8WJFvFzk4k3e8O1TQD+mDArPe2jI0rONowifXwz20QCMBqWmzIVdX2k1Xlvc/0RSxWB/1YdsqJeQKz4BySuu1INfJrYokG2k6bJnj514Lg+4wdZvn8xHsceFWDYw13dpe2PMIq5/BJfSTJexXxcfWCfY+/729Hn5FoGyTN5ZxoaRIT5mb79o/9pIL/enXs+C8ED+ZUDvqdY32lP/utxzHGUyU9V4o6vG25jDO9pj7VsYGaNdiukjiF0AnXx26wSl5zXPEsotPqzaw2DIFw/3ZloGaOySMmpl1Pp08LCfOvdj63RpFkDbXFDyDIN3nLEgcrk4dVsvzsYZlfMPVVb01R8HqFH1qd0AWmGFRbqq6HpE5C8C/8fDrR1kP7nie8ZbTMeU31evipzGWpAF9uGGxQJ8xXzlBRLw6K0cy/BU93uOa9nLdkA24uBTfOXznS8p0olzzF4q5T2W0an1KDFBsNKsqtUoiQr2VfNqg8ql3euJHzK20mCQUeuOUo4Aie1jn0cAi6Uqfg+xnE0G2FeGtZhCswWSUksc+jiQPZyY7tIpnleK4qLJlXX/lHxHgsRLIOo8ppzibiHk8IwCKFfbpmtfJwXsqjHzbmMkbUuYZmQ8CUi4Tq1XcxV4gkFkZ7A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3364BF10B7627E47B2714F321F7BBF6F@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3048.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bba9cff2-3d5a-4322-5735-08d867c74449 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2020 18:08:01.1786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Zls9ib+x7uXbNCWejaQY1CiZS9fqGYxxnRDWVQvkl0MRl9S9VMKnolhDMaCTXW33OIt18OOAnofP4O3clzCZKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3587 Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 18:08:07 -0000 SGkgUGV0ZXIsDQoNClVzaW5nIGZsZXgtYWxnbywgYSBTUnY2IGxvY2F0b3IgY2FuIGJlIGFzc29j aWF0ZWQgd2l0aCBhIHNpbmdsZSBhbGdvLCB3aGljaCBtZWFucyBhbiBJUHY2IG9yIElQdjQgYWRk cmVzcyBjYW4gYWxzbyBiZSBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUgYWxnby4gU28gbXkgdW5k ZXJzdGFuZGluZyBpcyBSb24ncyBwcm9wb3NhbCBpcyBtYWtpbmcgdGhlIGNvbmZpZ3VyYXRpb24g b2YgZmxleC1hbGdvIGVhc2llcj8gSW5zdGVhZCBvZiB1c2luZyB0aGUgZXhjbHVkZSBvciBpbmNs dWRlIGxpc3QgeW91IGNhbiBjb25maWd1cmUgYSBsb29wYmFjayBhZGRyZXNzIHRvIGEgZmxleC1h bGdvIGRpcmVjdGx5Pw0KDQpUaGFua3MsDQpZaW5nemhlbg0KDQrvu79PbiAxMC8zLzIwLCAyOjQ3 IEFNLCAiUGV0ZXIgUHNlbmFrIiA8cHBzZW5ha0BjaXNjby5jb20+IHdyb3RlOg0KDQogICAgSGkg WWluZ3poZW4sDQoNCiAgICBPbiAwMi8xMC8yMDIwIDIyOjE1LCBZaW5nemhlbiBRdSB3cm90ZToN CiAgICA+IEhpIFBldGVyLA0KICAgID4gDQogICAgPiBNeSB1bmRlcnN0YW5kaW5nIG9mIGZsZXgt YWxnbyBpcyB0aGF0IGZvciB0cmFmZmljIGRlc3RpbmVkIHRvIGEgcHJlZml4IG9uIGEgcGFydGlj dWxhciBhbGdvLCBpdCBjYW4gb25seSBiZSByb3V0ZWQgb24gcm91dGVycyBiZWxvbmcgdG8gdGhh dCBhbGdvLCB3aGljaCBhbHNvIG1lYW5zIG9ubHkgcm91dGVycyBpbiB0aGF0IGFsZ28gY2FsY3Vs YXRlcyBob3cgdG8gcmVhY2ggdGhhdCBwcmVmaXggYW5kIGluc3RhbGwgaXQgaW50byB0aGUgcm91 dGluZyB0YWJsZS4gSXQgc2VlbXMgdG8gbWUgdGhhdCB1c2luZyBmbGV4LWFsZ28gKHNlY3Rpb24g MTIgb2YgdGhlIGRyYWZ0KSBpdCdzIHBvc3NpYmxlIHRvIGhhdmUgYSBsb29wYmFjayBhZGRyZXNz IGFzc29jaWF0ZWQgd2l0aCBvbmx5IG9uZSBhbGdvLCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJJ20g bWlzc2luZyBvciBtaXN1bmRlcnN0b29kIHNvbWV0aGluZy4NCg0KICAgIHlvdSBhcmUgcmlnaHQu IFRoYXQgaXMgZXhhY3RseSB3aGF0IGlzIGJlaW5nIGRvbmUgZm9yIGZsZXgtYWxnbyB3aXRoIA0K ICAgIFNSdjYgLSBsb2NhdG9yIGlzIGFzc29jaWF0ZWQgd2l0aCBhIHNpbmdsZSBhbGdvIG9ubHku IFRoZSBwcm9wb3NhbCB1c2VzIA0KICAgIHRoZSBzYW1lIGNvbmNlcHQuDQoNCiAgICB0aGFua3Ms DQogICAgUGV0ZXINCg0KICAgID4gDQogICAgPiBUaGFua3MsDQogICAgPiBZaW5nemhlbg0KICAg ID4gDQogICAgPiBPbiAxMC8yLzIwLCA5OjQzIEFNLCAiTHNyIG9uIGJlaGFsZiBvZiBQZXRlciBQ c2VuYWsiIDxsc3ItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcHBzZW5haz00MGNpc2Nv LmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgICAgR3lhbiwNCiAg ICA+IA0KICAgID4gICAgICBPbiAwMi8xMC8yMDIwIDE4OjMwLCBHeWFuIE1pc2hyYSB3cm90ZToN CiAgICA+ICAgICAgPiBBbGwsDQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPiBXaXRoIFNSdjYg YW5kIElQIGJhc2VkIGZsZXggYWxnbyBhIGdlbmVyaWMgcXVlc3Rpb24gYXMgaXQgYXBwbGllcyB0 bw0KICAgID4gICAgICA+IGJvdGguIElzIGl0IHBvc3NpYmxlIHRvIGhhdmUgd2l0aGluIGEgc2lu Z2xlIElHUCBkb21haW4gZGlmZmVyZW50IHNldHMNCiAgICA+ICAgICAgPiBvZiBub2RlcyBvciBz ZWdtZW50cyBvZiB0aGUgbmV0d29yayBydW5uaW5nIGRpZmZlcmVudCBhbGdvcml0aG1zLg0KICAg ID4gDQogICAgPiAgICAgIGFic29sdXRlbHkuDQogICAgPiANCiAgICA+ICAgICAgPiBGcm9tDQog ICAgPiAgICAgID4gYm90aCBkcmFmdHMgaXQgc291bmRzIGxpa2UgYWxsIG5vZGVzIGhhdmUgdG8g YWdyZWUgb24gc2FtZSBhbGdvcml0aG0NCiAgICA+ICAgICAgPiBzaW1pbGFyIHRvIGNvbmNlcHQg b2YgbWV0cmljIGFuZCByZWZlcmVuY2UgYmFuZHdpZHRoIGFsbCBoYXZlIHRvIGhhdmUNCiAgICA+ ICAgICAgPiB0aGUgc2FtZSBzdHlsZSBtZXRyaWMgYW5kIHBsYXkgdG8gdGhlIHNhbWUgc2hlZXQg b2YgbXVzaWMuDQogICAgPiANCiAgICA+ICAgICAgYWxsIHBhcnRpY2lwYXRpbmcgbm9kZXMgbmVl ZCB0byBhZ3JlZSBvbiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgZmxleC1hbGdvDQogICAgPiAgICAg IGFuZCBhZHZlcnRpc2UgdGhlIHBhcnRpY2lwYXRpb24uIFRoYXQncyBpdC4NCiAgICA+IA0KICAg ID4gICAgICA+IElmIHRoZXJlIHdhcw0KICAgID4gICAgICA+IGEgd2F5IHRvIHVzZSBtdWx0aXBs ZSBhbGdvcml0aG1zIHNpbXVsdGFuZW91c2x5IGJhc2VkIG9uIFNGQyBvciBzZXJ2aWNlcw0KICAg ID4gICAgICA+IGFuZCBpbnN0YW50aWF0aW9uIG9mIHNwZWNpZmljIGFsZ29yaXRobSBiYXNlZCBv biBzZXJ2aWNlIHRvIGJlDQogICAgPiAgICAgID4gcmVuZGVyZWQuICBEb2luZyBzbyB3aXRob3V0 IGNhdXNpbmcgYSByb3V0aW5nIGxvb3Agb3Igc3ViIG9wdGltYWwNCiAgICA+ICAgICAgPiByb3V0 aW5nLg0KICAgID4gDQogICAgPiAgICAgIHlvdSBjYW4gY2VydGFpbmx5IHVzZSBtdWx0aXBsZSBh bGdvcml0aG1zIHNpbXVsdGFuZW91c2x5IGFuZCB1c2UgYWxnbw0KICAgID4gICAgICBzcGVjaWZp YyBwYXRocyB0byBmb3J3YXJkIHNwZWNpZmljIHRyYWZmaWMgb3ZlciBpdC4gSG93IHRoYXQgaXMg ZG9uZQ0KICAgID4gICAgICBmcm9tIHRoZSBmb3J3YXJkaW5nIHBlcnNwZWN0aXZlIGRlcGVuZHMg aW4gd2hpY2ggZm9yd2FyZGluZyBwbGFuZSB5b3UNCiAgICA+ICAgICAgdXNlLiBGbGV4LWFsZ28g Y29udHJvbCBwbGFuZSBpcyBpbmRlcGVuZGVudCBvZiB0aGUgZm9yd2FyZGluZyBwbGFuZS4NCiAg ICA+IA0KICAgID4gDQogICAgPiAgICAgID5JIHRob3VnaHQgd2l0aCBmbGV4IGFsZ28gdGhhdCB0 aGVyZSBleGlzdHMgYSBmZWF0dXJlIHRoYXQgb24NCiAgICA+ICAgICAgPiBlYWNoIGhvcCB0aGVy ZSBpcyBhIHdheSB0byBzcGVjaWZ5IHdoaWNoIGFsZ28gdG8gdXNlIGhvcCBieSBob3Agc2ltaWxh cg0KICAgID4gICAgICA+IHRvIGEgaG9wIGJ5IGhvcCBwb2xpY3kgYmFzZWQgcm91dGluZy4NCiAg ICA+IA0KICAgID4gICAgICBubywgdGhlcmUgaXMgbm8gaG9wLWJ5LWhvcCBjbGFzc2lmaWNhdGlv biwgdGhhdCBpcyBwcm9ibGVtYXRpYyBhbmQgZG9lcw0KICAgID4gICAgICBub3Qgc2NhbGUgZm9y IGhpZ2ggc3BlZWRzLiBDbGFzc2lmaWNhdGlvbiBpcyBkb25lIGF0IHRoZSBpbmdyZXNzIG9ubHku DQogICAgPiANCiAgICA+ICAgICAgdGhhbmtzLA0KICAgID4gICAgICBQZXRlcg0KICAgID4gDQog ICAgPiAgICAgID4NCiAgICA+IA0KICAgID4gICAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgICBMc3IgbWFpbGluZyBsaXN0DQogICAg PiAgICAgIExzckBpZXRmLm9yZw0KICAgID4gICAgICBodHRwczovL25hbTExLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZsc3ImYW1wO2RhdGE9MDIlN0MwMSU3Q3lpbmd6aGVuLnF1JTQw ZnV0dXJld2VpLmNvbSU3Q2ZlMDMxMjRjNmU0MTRlMDY3YzIwMDhkODY3ODE2NTQxJTdDMGZlZThm ZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3QzYzNzM3MzE1MjczOTg2NTEyNiZh bXA7c2RhdGE9V0k0OGNFQWFuJTJGT2tEUG1WWEd1ckVBalBJdE5HRjlwOVBEUUlsRDFpcDBnJTNE JmFtcDtyZXNlcnZlZD0wDQogICAgPiANCiAgICA+IA0KICAgID4gDQoNCg0K From nobody Sat Oct 3 13:33:39 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142513A0822 for ; Sat, 3 Oct 2020 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=TsLrIa5K; dkim=pass (1024-bit key) header.d=juniper.net header.b=H2V93fU7 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 bsGLEE8hfyId for ; Sat, 3 Oct 2020 13:33:36 -0700 (PDT) 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 11FBD3A07CE for ; Sat, 3 Oct 2020 13:33:35 -0700 (PDT) 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 093KXW1S029282; Sat, 3 Oct 2020 13:33:32 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=M7uVS3it4mFl101V5gu7um0U9gYQLfY58yr4MpKrNIY=; b=TsLrIa5Ka+VzYBRGsuRcL71+koNhMLBPiOBYXZsDlA1Bv6OwtAgZ1Pm/dTMgcp+lQ10J lqi5j7EM05Zr7jPOHwKELtFFHc78JPG/rocEG+XyCSqfb/AjfF18F6SXzT1ajhG7iuuY FX/k858YCXZpcTz+skVTQfxy4XFj7t2IrFyCn6bLpbGFIrhCnMfSEPc/6rpHAHpQBTL+ 1eMLPQ3LxIF23L5jNjT93X6YemYe+fe7tX/DX3BIZBHYccsGE2irUdV7RSyHvolzOWDE jhFEMZPMOWepg3ie5wrVfxPb2fxbkjXh6OyseVNzM4GE4kus0Mu2dXGU1vaTEIAhxqfp aQ== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2169.outbound.protection.outlook.com [104.47.59.169]) by mx0b-00273201.pphosted.com with ESMTP id 33xq7j0dat-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 03 Oct 2020 13:33:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TQ25bQCJ7ZxlJI2I2tJsAFhaE9sScw0fORBBFDiLLbRWvoUG9ReTZ9DwVzk6pAIns7Zy5rj7HYwADIK6242bJDUw5qx8irntEywVXYD5HhuAqhGjMTYri28f2lNnxkmbOQ1TNC3Qho5s6b8puZaR3iCqshrnqEGvyNWnZ6q0eXFlzAT4whsKx8ST0oRVOwhkhBuFVBC3r7kK2MI2CWqRiZJ9nJbB0l3NXPBq4ChJPg6MFIUMUqff3isUyqbuj7+dGAwpr9K8MMxNowAsoJH57U1Ru8+n2qXDML7RcnmkeLvt9ge0djXs6VsAxcu4qXccs+5ed05nxpl2TVrv3WgPOA== 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=M7uVS3it4mFl101V5gu7um0U9gYQLfY58yr4MpKrNIY=; b=G62SUfaciHx0GBIA/Gj4+RSUvTvDNaVqqOGEG88HtEuBL9dg3gQtseV02+JP42q0Z/KBxiPOBTQKSexN2ZU0usWDZnPq8xj4IC3Pejz3AG4Ct97O9x4ULdm34PsRE2EKeRHr6NPtFrEpSoryWPkJph5mWy5zpXa5kTHx5k58KrUH7ueDrPcAHBCcmce9GTFpzgKgXDmNBE4HNdexpDGFo6IsF9MwBnzUIHJYo0Vyg4sTofdfR8A2gBsZR33QpBYyZar6ZScD5MloCddkxQOvOnWnjyUk6jDUuCgOlUjY2BvAvotaRlQ7jwfZ7ndl/pJ43fh53PRI+UPMg2nX5bU3lw== 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=M7uVS3it4mFl101V5gu7um0U9gYQLfY58yr4MpKrNIY=; b=H2V93fU79jxxGFsQYdw3ccllNPH4hzAhZBfr62yMVNwYUlRYlBKRexQb7hsNfi5j+iieGOIgy1EuaDIA9I9plNqCtIWnjlVq+oS8GfAZum9yd0lqKpU8pGWJ+Xb1ZdSVutry3ivP36hxvPQAoMRYmBR59jcoULHkH4ocCDmvhZc= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM5PR05MB3371.namprd05.prod.outlook.com (2603:10b6:4:45::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Sat, 3 Oct 2020 20:33:30 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782%3]) with mapi id 15.20.3455.016; Sat, 3 Oct 2020 20:33:30 +0000 From: Ron Bonica To: Yingzhen Qu , Peter Psenak , Gyan Mishra CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAGYiICAAB9mMIAA726AgADTSnCAAWzZgIAAAz2A///GWICAAVg7AIAAFmsAgACYCCA= Date: Sat, 3 Oct 2020 20:33:30 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> In-Reply-To: <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-03T20:33:28Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=88f21b67-5478-433b-8af2-b556a3f96bf2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.132.205] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 65080bbc-9787-4b49-f1d6-08d867db9706 x-ms-traffictypediagnostic: DM5PR05MB3371: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9mrytJIGfe6ffx8BtizAGPfDvUrV2chCsWyiZ4UCeFTtg3fHRikqJ94ELfbH2dSvVBJXx9uAe6PG3mboDkB4F47/Mo9ANyQYbFBsoJ8Tu30NP4OwWVJ16kdm3FAa5cZbGq7KNfysosLIKbirqrZSrQtuYYIQ36oMF6lbwNywyrEgTg3pRjw5cQfoh/eW/yTm3oZ1pE+nykWGMspMz0NOZJNs7y2/mav9ag7foi3vnq01WjAA2laGiQWdDE0yK7xvqUH7sCcSgVlMV/xCQWmv7/aTTnUTuZrfhZbLNed1by+kgsxGP+pEIJcapvued529Aymko6O3MNdg0M2qTyHjD2nB/Sq/jAXFoO+sBk4EXSNpsRtdKOVg3n8iB103Cw8PpTVPw2FlmaVIwrJnRY4+LQF7ePRTvyCh5wrsPhewu65YdAZtxBxmz3qYm9mAGnz0YCy6hM1PblSNbp2IcojYZQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(136003)(366004)(346002)(396003)(76116006)(478600001)(110136005)(86362001)(15650500001)(8676002)(45080400002)(8936002)(2906002)(66556008)(71200400001)(66476007)(64756008)(66946007)(66446008)(9686003)(4326008)(26005)(54906003)(33656002)(55016002)(7696005)(52536014)(966005)(186003)(316002)(5660300002)(53546011)(6506007)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: sfk2dy9pz9sddZ9VuSV2aa7sib3pZ5kOMygCcCTsSjHr1yOaXluIFIAlmlrbMjigxC+wRJX8ZOnU4gjBrh2hmgfb7xYqK8o1vc0ofMjUCS3qY8QSRAF2Ik4s+pLeBaT9WotEfHdXkFxgnNIECRoWPuNRjrKFMxLixudjk3f4MZ/pQLZ30P+7POQ6cpVh1+lbXE3R+eE03mlP8VrgRNIYshWiAhEECY8vUCIF2cGaeGir2tCQpssBkNikkJ1nYswA3T6VEyIML86h3taxKfrsvAsOXQu31xVK3Fmc8JPBJ9acU4TlPwJytZB7R45xi8lkclRR9QcGt3/DhtpdQeJwGByhiBf0ryN4aBfepd+/pYdjpXLmDxb9xYAscpkrSPhZucug/eDSqHTlU08MZYxp+WYcEoZjkkDvsFc9f/TPd9grZACQegaQYASrFGCzcCvzhw9eQd0pBVUoOWPdef48UeeJuPY4hdr2JkmC8g9LZL9OovlvbJndQLLclSC75CNdueLcvqUctOf1dgFvrJ9+qRVtfTTsErGKZgqiqiwv4dvdjw6oqRPaCgPYiaMlHiTliXcBX16K5pPprAKydPTPkeMr9kNCSBHU2WnqT/MTdlf50U8Dgjk5krMdmqRyi1rTDaS0lIlu2w25VGlmuZ/Iwg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 65080bbc-9787-4b49-f1d6-08d867db9706 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2020 20:33:30.0929 (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: OfU6WTqEMNaE0lbHduSAyf+Nf/0vNVI/k4NW5kwzIiOdaTIoMlYqPskU0jBhKY24JNfFStC0olFIQBhqfYbezA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3371 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-03_16:2020-10-02, 2020-10-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 spamscore=0 clxscore=1011 priorityscore=1501 suspectscore=0 mlxlogscore=999 impostorscore=0 phishscore=0 lowpriorityscore=0 mlxscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010030171 Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 20:33:38 -0000 SGkgWWluZ3poZW4sDQoNCklQIEZsZXhpYmxlIEFsZ29yaXRobXMgYXJlIGxpa2UgU1IgRmxleGli bGUgQWxnb3JpdGhtcyBpbiB0aGUgZm9sbG93aW5nIHJlc3BlY3RzOg0KDQotIExpbmtzIGhhdmUg SUdQIG1ldHJpY3MsIFRFIG1ldHJpY3MsIGRlbGF5IG1ldHJpY3MgYW5kIGFkbWluaXN0cmF0aXZl IGNvbG9ycw0KLSBGQURzIGRlZmluZSBGbGV4aWJsZSBBbGdvcml0aG1zDQoNCk1vcmUgc3BlY2lm aWNhbGx5LCB0aGUgRkFEOg0KDQotIEluZGljYXRlcyB3aGljaCBtZXRyaWMgdHlwZSB0aGUgRmxl eGlibGUgQWxnb3JpdGhtIHVzZXMNCi0gU3BlY2lmaWVzIGNvbnN0cmFpbnRzIGluIHRlcm1zIG9m IGxpbmsgY29sb3JzIHRoYXQgYXJlIGluY2x1ZGVkIG9yIGV4Y2x1ZGVkIGZyb20gdGhlIEZsZXhp YmxlIEFsZ29yaXRobS4NCg0KVGhlIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgYmV0d2VlbiBJUCBG bGV4aWJsZSBBbGdvcml0aG1zIGFuZCBTUiBGbGV4aWJsZSBBbGdvcml0aG1zIGlzOg0KDQotIFNS IEZsZXhpYmxlIEFsZ29yaXRobXMgYmluZCBGQURzIHRvIHByZWZpeCBTSURzIG9yIFNSdjYgbG9j YXRvcnMNCi0gSVAgRmxleGlibGUgQWxnb3JpdGhtcyBiaW5kIEZBRHMgdG8gSVB2NCBvciBJUHY2 IGFkZHJlc3Nlcy4NCg0KU28sIElQIEZsZXhpYmxlIEFsZ29yaXRobXMgY2FuIGJlIGRlcGxveWVk IGluIGFueSBJUCBuZXR3b3JrLCBldmVuIGluIHRoZSBhYnNlbmNlIG9mIFNSLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KSnVuaXBlciBCdXNpbmVz cyBVc2UgT25seQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWWluZ3poZW4g UXUgPHlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5jb20+IA0KU2VudDogU2F0dXJkYXksIE9jdG9iZXIg MywgMjAyMCAyOjA4IFBNDQpUbzogUGV0ZXIgUHNlbmFrIDxwcHNlbmFrQGNpc2NvLmNvbT47IEd5 YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5jb20+OyBSb24gQm9uaWNhIDxyYm9uaWNhQGp1 bmlwZXIubmV0Pg0KQ2M6IGxzckBpZXRmLm9yZzsgSmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0 ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtYm9uaWNhLWxzci1pcC1mbGV4YWxnby0wMC50eHQNCg0KW0V4dGVybmFs IEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KDQoNCkhpIFBldGVyLA0KDQpVc2luZyBm bGV4LWFsZ28sIGEgU1J2NiBsb2NhdG9yIGNhbiBiZSBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUg YWxnbywgd2hpY2ggbWVhbnMgYW4gSVB2NiBvciBJUHY0IGFkZHJlc3MgY2FuIGFsc28gYmUgYXNz b2NpYXRlZCB3aXRoIGEgc2luZ2xlIGFsZ28uIFNvIG15IHVuZGVyc3RhbmRpbmcgaXMgUm9uJ3Mg cHJvcG9zYWwgaXMgbWFraW5nIHRoZSBjb25maWd1cmF0aW9uIG9mIGZsZXgtYWxnbyBlYXNpZXI/ IEluc3RlYWQgb2YgdXNpbmcgdGhlIGV4Y2x1ZGUgb3IgaW5jbHVkZSBsaXN0IHlvdSBjYW4gY29u ZmlndXJlIGEgbG9vcGJhY2sgYWRkcmVzcyB0byBhIGZsZXgtYWxnbyBkaXJlY3RseT8NCg0KVGhh bmtzLA0KWWluZ3poZW4NCg0K77u/T24gMTAvMy8yMCwgMjo0NyBBTSwgIlBldGVyIFBzZW5hayIg PHBwc2VuYWtAY2lzY28uY29tPiB3cm90ZToNCg0KICAgIEhpIFlpbmd6aGVuLA0KDQogICAgT24g MDIvMTAvMjAyMCAyMjoxNSwgWWluZ3poZW4gUXUgd3JvdGU6DQogICAgPiBIaSBQZXRlciwNCiAg ICA+DQogICAgPiBNeSB1bmRlcnN0YW5kaW5nIG9mIGZsZXgtYWxnbyBpcyB0aGF0IGZvciB0cmFm ZmljIGRlc3RpbmVkIHRvIGEgcHJlZml4IG9uIGEgcGFydGljdWxhciBhbGdvLCBpdCBjYW4gb25s eSBiZSByb3V0ZWQgb24gcm91dGVycyBiZWxvbmcgdG8gdGhhdCBhbGdvLCB3aGljaCBhbHNvIG1l YW5zIG9ubHkgcm91dGVycyBpbiB0aGF0IGFsZ28gY2FsY3VsYXRlcyBob3cgdG8gcmVhY2ggdGhh dCBwcmVmaXggYW5kIGluc3RhbGwgaXQgaW50byB0aGUgcm91dGluZyB0YWJsZS4gSXQgc2VlbXMg dG8gbWUgdGhhdCB1c2luZyBmbGV4LWFsZ28gKHNlY3Rpb24gMTIgb2YgdGhlIGRyYWZ0KSBpdCdz IHBvc3NpYmxlIHRvIGhhdmUgYSBsb29wYmFjayBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCBvbmx5 IG9uZSBhbGdvLCBwbGVhc2UgY29ycmVjdCBtZSBpZiBJJ20gbWlzc2luZyBvciBtaXN1bmRlcnN0 b29kIHNvbWV0aGluZy4NCg0KICAgIHlvdSBhcmUgcmlnaHQuIFRoYXQgaXMgZXhhY3RseSB3aGF0 IGlzIGJlaW5nIGRvbmUgZm9yIGZsZXgtYWxnbyB3aXRoDQogICAgU1J2NiAtIGxvY2F0b3IgaXMg YXNzb2NpYXRlZCB3aXRoIGEgc2luZ2xlIGFsZ28gb25seS4gVGhlIHByb3Bvc2FsIHVzZXMNCiAg ICB0aGUgc2FtZSBjb25jZXB0Lg0KDQogICAgdGhhbmtzLA0KICAgIFBldGVyDQoNCiAgICA+DQog ICAgPiBUaGFua3MsDQogICAgPiBZaW5nemhlbg0KICAgID4NCiAgICA+IE9uIDEwLzIvMjAsIDk6 NDMgQU0sICJMc3Igb24gYmVoYWxmIG9mIFBldGVyIFBzZW5hayIgPGxzci1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiBwcHNlbmFrPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90 ZToNCiAgICA+DQogICAgPiAgICAgIEd5YW4sDQogICAgPg0KICAgID4gICAgICBPbiAwMi8xMC8y MDIwIDE4OjMwLCBHeWFuIE1pc2hyYSB3cm90ZToNCiAgICA+ICAgICAgPiBBbGwsDQogICAgPiAg ICAgID4NCiAgICA+ICAgICAgPiBXaXRoIFNSdjYgYW5kIElQIGJhc2VkIGZsZXggYWxnbyBhIGdl bmVyaWMgcXVlc3Rpb24gYXMgaXQgYXBwbGllcyB0bw0KICAgID4gICAgICA+IGJvdGguIElzIGl0 IHBvc3NpYmxlIHRvIGhhdmUgd2l0aGluIGEgc2luZ2xlIElHUCBkb21haW4gZGlmZmVyZW50IHNl dHMNCiAgICA+ICAgICAgPiBvZiBub2RlcyBvciBzZWdtZW50cyBvZiB0aGUgbmV0d29yayBydW5u aW5nIGRpZmZlcmVudCBhbGdvcml0aG1zLg0KICAgID4NCiAgICA+ICAgICAgYWJzb2x1dGVseS4N CiAgICA+DQogICAgPiAgICAgID4gRnJvbQ0KICAgID4gICAgICA+IGJvdGggZHJhZnRzIGl0IHNv dW5kcyBsaWtlIGFsbCBub2RlcyBoYXZlIHRvIGFncmVlIG9uIHNhbWUgYWxnb3JpdGhtDQogICAg PiAgICAgID4gc2ltaWxhciB0byBjb25jZXB0IG9mIG1ldHJpYyBhbmQgcmVmZXJlbmNlIGJhbmR3 aWR0aCBhbGwgaGF2ZSB0byBoYXZlDQogICAgPiAgICAgID4gdGhlIHNhbWUgc3R5bGUgbWV0cmlj IGFuZCBwbGF5IHRvIHRoZSBzYW1lIHNoZWV0IG9mIG11c2ljLg0KICAgID4NCiAgICA+ICAgICAg YWxsIHBhcnRpY2lwYXRpbmcgbm9kZXMgbmVlZCB0byBhZ3JlZSBvbiB0aGUgZGVmaW5pdGlvbiBv ZiB0aGUgZmxleC1hbGdvDQogICAgPiAgICAgIGFuZCBhZHZlcnRpc2UgdGhlIHBhcnRpY2lwYXRp b24uIFRoYXQncyBpdC4NCiAgICA+DQogICAgPiAgICAgID4gSWYgdGhlcmUgd2FzDQogICAgPiAg ICAgID4gYSB3YXkgdG8gdXNlIG11bHRpcGxlIGFsZ29yaXRobXMgc2ltdWx0YW5lb3VzbHkgYmFz ZWQgb24gU0ZDIG9yIHNlcnZpY2VzDQogICAgPiAgICAgID4gYW5kIGluc3RhbnRpYXRpb24gb2Yg c3BlY2lmaWMgYWxnb3JpdGhtIGJhc2VkIG9uIHNlcnZpY2UgdG8gYmUNCiAgICA+ICAgICAgPiBy ZW5kZXJlZC4gIERvaW5nIHNvIHdpdGhvdXQgY2F1c2luZyBhIHJvdXRpbmcgbG9vcCBvciBzdWIg b3B0aW1hbA0KICAgID4gICAgICA+IHJvdXRpbmcuDQogICAgPg0KICAgID4gICAgICB5b3UgY2Fu IGNlcnRhaW5seSB1c2UgbXVsdGlwbGUgYWxnb3JpdGhtcyBzaW11bHRhbmVvdXNseSBhbmQgdXNl IGFsZ28NCiAgICA+ICAgICAgc3BlY2lmaWMgcGF0aHMgdG8gZm9yd2FyZCBzcGVjaWZpYyB0cmFm ZmljIG92ZXIgaXQuIEhvdyB0aGF0IGlzIGRvbmUNCiAgICA+ICAgICAgZnJvbSB0aGUgZm9yd2Fy ZGluZyBwZXJzcGVjdGl2ZSBkZXBlbmRzIGluIHdoaWNoIGZvcndhcmRpbmcgcGxhbmUgeW91DQog ICAgPiAgICAgIHVzZS4gRmxleC1hbGdvIGNvbnRyb2wgcGxhbmUgaXMgaW5kZXBlbmRlbnQgb2Yg dGhlIGZvcndhcmRpbmcgcGxhbmUuDQogICAgPg0KICAgID4NCiAgICA+ICAgICAgPkkgdGhvdWdo dCB3aXRoIGZsZXggYWxnbyB0aGF0IHRoZXJlIGV4aXN0cyBhIGZlYXR1cmUgdGhhdCBvbg0KICAg ID4gICAgICA+IGVhY2ggaG9wIHRoZXJlIGlzIGEgd2F5IHRvIHNwZWNpZnkgd2hpY2ggYWxnbyB0 byB1c2UgaG9wIGJ5IGhvcCBzaW1pbGFyDQogICAgPiAgICAgID4gdG8gYSBob3AgYnkgaG9wIHBv bGljeSBiYXNlZCByb3V0aW5nLg0KICAgID4NCiAgICA+ICAgICAgbm8sIHRoZXJlIGlzIG5vIGhv cC1ieS1ob3AgY2xhc3NpZmljYXRpb24sIHRoYXQgaXMgcHJvYmxlbWF0aWMgYW5kIGRvZXMNCiAg ICA+ICAgICAgbm90IHNjYWxlIGZvciBoaWdoIHNwZWVkcy4gQ2xhc3NpZmljYXRpb24gaXMgZG9u ZSBhdCB0aGUgaW5ncmVzcyBvbmx5Lg0KICAgID4NCiAgICA+ICAgICAgdGhhbmtzLA0KICAgID4g ICAgICBQZXRlcg0KICAgID4NCiAgICA+ICAgICAgPg0KICAgID4NCiAgICA+ICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgICAgTHNy IG1haWxpbmcgbGlzdA0KICAgID4gICAgICBMc3JAaWV0Zi5vcmcNCiAgICA+ICAgICAgaHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyozQSoyRioyRnd3dy5pZXRmLm9yZyoyRm1haWxtYW4qMkZs aXN0aW5mbyoyRmxzciZhbXA7ZGF0YT0wMio3QzAxKjdDeWluZ3poZW4ucXUqNDBmdXR1cmV3ZWku Y29tKjdDZmUwMzEyNGM2ZTQxNGUwNjdjMjAwOGQ4Njc4MTY1NDEqN0MwZmVlOGZmMmEzYjI0MDE4 OWM3NTNhMWQ1NTkxZmVkYyo3QzEqN0MwKjdDNjM3MzczMTUyNzM5ODY1MTI2JmFtcDtzZGF0YT1X STQ4Y0VBYW4qMkZPa0RQbVZYR3VyRUFqUEl0TkdGOXA5UERRSWxEMWlwMGcqM0QmYW1wO3Jlc2Vy dmVkPTBfXztKU1VsSlNVbEpTVWxKU1VsSlNVbEpRISFORXQ2eU1hTy1nayFYMWZSbG45TWppbWVK Y1JFVUVJeWRyLThJSWJ0Tm9uWE1zODNlb1h2Und3NnhrYVFmVlVkTmgwa0s0NTJHUC1HJA0KICAg ID4NCiAgICA+DQogICAgPg0KDQo= From nobody Sat Oct 3 20:34:47 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1DD3A0ADC; Sat, 3 Oct 2020 20:34:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <160178247676.6161.10725609076157911041@ietfa.amsl.com> Date: Sat, 03 Oct 2020 20:34:36 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-ttz-01.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 03:34:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Topology-Transparent Zone Authors : Huaimo Chen Richard Li Yi Yang Yanhe Fan Ning So Vic Liu Mehmet Toy Lei Liu Kiran Makhijani Filename : draft-ietf-lsr-isis-ttz-01.txt Pages : 21 Date : 2020-10-03 Abstract: This document specifies a topology-transparent zone in an area. A zone is a subset (block/piece) of an area, which comprises a group of routers and a number of circuits connecting them. It is abstracted as a virtual entity such as a single virtual node or zone edges mesh. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-isis-ttz-01 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-ttz-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-ttz-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 Sun Oct 4 02:51:52 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BA83A1374 for ; Sun, 4 Oct 2020 02:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.813 X-Spam-Level: X-Spam-Status: No, score=-9.813 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYw45vGx6Wjt for ; Sun, 4 Oct 2020 02:51:47 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3B43A1372 for ; Sun, 4 Oct 2020 02:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12172; q=dns/txt; s=iport; t=1601805106; x=1603014706; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=fftYwqozee/LqeA6tElKGLqRYC74y4HuBb3CgHk8YoI=; b=AGSkBlUNRUx/WuYwcVyMKsbwfVp4qZpEBQ1NSlzjnF9vhI5h1D+lRCin ZmhThCidNd4fkQ7Kst7frMvkJxpTiq46eKtzSLUO+cFnH7x7cmtIw3oMk hGrzdwogClKoow++T4sSEcSGs/guLy2KRA2CoPtzUkwdXNSHBXHd7V3Qa Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAACPmnlf/xbLJq1dAxwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIE+BAEBCwGDGVUBMiyEPYkCiAouihGSFQsBAQEPHxAEAQG?= =?us-ascii?q?ESgKCNyY3Bg4CAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgEjDwEFNgkCBQs?= =?us-ascii?q?JAgcHCgICIwMCAiElEQYNBgIBAReDCwGCSwMOIIsymwV2gTKFVIJQDWKBQoE?= =?us-ascii?q?OKgGHYIVrgUE/gRABJ4JpPoIaQgSBfgsbglCCYASQHgklgjCTP5BAUoJxgxO?= =?us-ascii?q?NBIU/hH8FBwMfgw6KAoUTjnygbJJmgWokDTeBEzMaCBsVO4JpCUcZDY4rBRK?= =?us-ascii?q?DTopYPwMwAjUCBgEJAQEDCY5IAQE?= X-IronPort-AV: E=Sophos;i="5.77,335,1596499200"; d="scan'208";a="30100700" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Oct 2020 09:51:42 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 0949pfdU026116; Sun, 4 Oct 2020 09:51:42 GMT To: Gyan Mishra Cc: Jeff Tantsura , Ron Bonica , Yingzhen Qu , "lsr@ietf.org" References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <047be764-8203-ca46-7ee1-6f84f7bf2356@cisco.com> From: Peter Psenak Message-ID: Date: Sun, 4 Oct 2020 11:51:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 09:51:50 -0000 Hi Gyan, On 03/10/2020 18:54, Gyan Mishra wrote: > > Thanks Peter for the responses to help clear up my flex algo understanding!! > > On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak > wrote: > > Gyan, > > > > On 03/10/2020 02:14, Gyan Mishra wrote: > > > > > > Hi  Jeff > > > > > >  From a domain perspective where you have a group of nodes and > > > associated IP addressed and SID are part of a discrete underlay > instance > > > flex algo topology.  On those same set of nodes you could have > another > > > topology and associated address and SIDs for a different flex algo. > > > > above is right. > > >    Gyan>  So per my response to Robert, what  I was thinking is that as > the algo 0 strict spf would be used as the base algo to provide > reachability to all nodes within the domain and all neighbors are formed > between all nodes in the domain to populate IGP rib providing base > connectivity reachability.  So then underneath of that you can have any > subset of nodes out of the superset all top layer domain nodes level >  that can run any other algo desired. Basically creating algo layers > under the top domain wide layer. pretty much. > > > > > > How > > > this would work is that the topologies would have to be > segregated from > > > each other as different MT instances or routing process > instances.  Is > > > that correct? > > > > no MT at all. You can think of each flex-algo as a set of constraints > > that is used to calculate the path over the common topology. You can > > have many such felx-algos running on a common topology. > > >     Gyan> Is it safe to say that we can think of it as RSVP TE “like” > cSPF constraints that we are build via traffic engineering PCALC > algorithms to run for dynamic LSP dyamic ERO that is built based on IGP > constraints from TEDs database of TE link attributes and TE or IGP > weights metric constraints to create the dynamic LSP path. you can think of a flex-algo as a TE like solution, but there are some major differences to RSVP-TE: - automatic calculation of flex-algo constrained based paths from any source to any destination. This is in contrast to p2p nature of RSVP-TE. - there is no TED, all information is stored in IGP LSDB. > So we could > think of in TE framework analogy to flex algo In the per VRF TE next hop > vpn coloring use case with different loopback next hop rewrite per VRF > that normal IGP non TE BAU VPNs traffic would be like the flex algo base > strict algo 0 and the non zero discrete algo would be like the per VRF > next hop loopback rewrite where each per VRF te loopback rewrite would > be a different steering non zero discrete flex algo all running in > parallel as ships in the night with the base algo 0.   Sorry for the > complex analogy but I think I am getting it!!😃 steering the traffic to flex-algo paths can be done using different methods - per-destination, per flow, etc. Various coloring mechanism can be used as well, if needed. > > Does a flex algo use case draft exist and if not I would not mind using > the analogy I said above and build out a use case draft.  Cheers! 😊 I'm not a fan of use case drafts. These should be vendor specific documents, no need to make them standards. thanks, Peter > > > > > > > > > Can two nodes that run two different flex algo become ospf or isis > > > neighbors? > > > > absolutely. > > > > Peter > > > > > > > > Kind Regards > > > > > > Gyan > > > > > > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     Hi Yingzhen, > > > > > > > > > > > > > > > > > >     Yes, that’s the case.  The most important property of an algo > > >     computed path is that is has to be consecutive, as either SID > or IP > > >     address associated with a particular topology is only known > within > > >     that topology. > > > > > > > > >     Looking specifically at Ron’s draft (MPLS could be more > complex due > > >     to potential hierarchy) - the prefix itself defines the > > >     context(topology) and must be globally unique, since IPv4 header > > >     can’t have any additional meta-data attached. > > > > > > > > > > > > > > > > > > > > > > > >     Cheers, > > > > > >     Jeff > > > > > > > > > > > > > > > > > > > > >     On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu > > >      > >>, wrote: > > > > > > > > >>     Hi Peter, > > >> > > >> > > >> > > >> > > >> > > >>     My understanding of flex-algo is that for traffic destined to a > > >>     prefix on a particular algo, it can only be routed on routers > > >>     belong to that algo, which also means only routers in that algo > > >>     calculates how to reach that prefix and install it into the > > >>     routing table. It seems to me that using flex-algo (section > 12 of > > >>     the draft) it's possible to have a loopback address associated > > >>     with only one algo, please correct me if I'm missing or > > >>     misunderstood something. > > >> > > >> > > >> > > >> > > >> > > >>     Thanks, > > >> > > >> > > >>     Yingzhen > > >> > > >> > > >> > > >> > > >> > > >>     On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > > >>      > > on behalf of > > >>     ppsenak=40cisco.com@dmarc.ietf.org > > > >>      >> wrote: > > >> > > >> > > >> > > >> > > >> > > >>     Gyan, > > >> > > >> > > >> > > >> > > >> > > >>     On 02/10/2020 18:30, Gyan Mishra wrote: > > >> > > >> > > >>>     All, > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>     With SRv6 and IP based flex algo a generic question as it > applies to > > >>> > > >>> > > >>>     both. Is it possible to have within a single IGP domain > different > > >>>     sets > > >>> > > >>> > > >>>     of nodes or segments of the network running different > algorithms. > > >> > > >> > > >> > > >> > > >> > > >>     absolutely. > > >> > > >> > > >> > > >> > > >> > > >>>     From > > >>> > > >>> > > >>>     both drafts it sounds like all nodes have to agree on same > algorithm > > >>> > > >>> > > >>>     similar to concept of metric and reference bandwidth all > have to have > > >>> > > >>> > > >>>     the same style metric and play to the same sheet of music. > > >> > > >> > > >> > > >> > > >> > > >>     all participating nodes need to agree on the definition of the > > >>     flex-algo > > >> > > >> > > >>     and advertise the participation. That's it. > > >> > > >> > > >> > > >> > > >> > > >>>     If there was > > >>> > > >>> > > >>>     a way to use multiple algorithms simultaneously based on SFC or > > >>>     services > > >>> > > >>> > > >>>     and instantiation of specific algorithm based on service to be > > >>> > > >>> > > >>>     rendered. Doing so without causing a routing loop or sub > optimal > > >>> > > >>> > > >>>     routing. > > >> > > >> > > >> > > >> > > >> > > >>     you can certainly use multiple algorithms simultaneously and > use algo > > >> > > >> > > >>     specific paths to forward specific traffic over it. How that > is done > > >> > > >> > > >>     from the forwarding perspective depends in which forwarding > plane you > > >> > > >> > > >>     use. Flex-algo control plane is independent of the > forwarding plane. > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >>>     I thought with flex algo that there exists a feature that on > > >>> > > >>> > > >>>     each hop there is a way to specify which algo to use hop by hop > > >>>     similar > > >>> > > >>> > > >>>     to a hop by hop policy based routing. > > >> > > >> > > >> > > >> > > >> > > >>     no, there is no hop-by-hop classification, that is > problematic and > > >>     does > > >> > > >> > > >>     not scale for high speeds. Classification is done at the > ingress only. > > >> > > >> > > >> > > >> > > >> > > >>     thanks, > > >> > > >> > > >>     Peter > > >> > > >> > > >> > > >> > > >> > > >>> > > >> > > >> > > >> > > >> > > >> > > >>     _______________________________________________ > > >> > > >> > > >>     Lsr mailing list > > >> > > >> > > >> Lsr@ietf.org > > > >> > > >> > > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=0 > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > *Gyan Mishra* > > > > > > /Network Solutions A//rchitect / > > > > > > /M 301 502-1347 > > > 13101 Columbia Pike > > > /Silver Spring, MD > > > > > > > > > > -- > > > > *Gyan Mishra* > > /Network Solutions A//rchitect / > > /M 301 502-1347 > 13101 Columbia Pike > /Silver Spring, MD > > From nobody Sun Oct 4 02:54:58 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F69F3A0977 for ; Sun, 4 Oct 2020 02:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pqkjRW6EZ-B for ; Sun, 4 Oct 2020 02:54:54 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36703A0976 for ; Sun, 4 Oct 2020 02:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4230; q=dns/txt; s=iport; t=1601805294; x=1603014894; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=cCEMDeX32/Bl327Kzd3YlyoHkXqvT7bDTKoSNNHB+ZE=; b=HAwaQha62jDKbUKBK47y0h5jZp9ooEGD/UWkuggG26/NR83P1WamKb4Y LnT6xIsGydz4b6jz2NKVejWT0p7sOzVYIMvfZ3MqHzgNtOiHQ+vrSOA3V 04J9q9TvoXnnbs75DL57DW9E7aXprC0U7oDIkxgzAOTWCJFwx9rbhk5R5 I=; X-IPAS-Result: =?us-ascii?q?A0AgAAAZm3lf/xbLJq1gGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBPQQBAQELAYMZVQEyLIQ9iQKICQgmmimBfQsBAQEPLwQBAYRKAoI3J?= =?us-ascii?q?jYHDgIDAQEBAwIDAQEBAQUBAQECAQYEbYVohXIBAQEBAgEjFTYJAgULCxgCA?= =?us-ascii?q?iYCAlcGAQwGAgEBgyIBglwgpjd2gTKFVIM/gTwGgQ4qAYkehC2BQT+BOAyCX?= =?us-ascii?q?T6CXASEdIJgBJAeCYJViH6bU4JxgxOXQgUHAx+DDooChROOfJMUoD6BWwsoD?= =?us-ascii?q?YFKMxoIGxU7gmlQGQ2caD8DMAI1AgYKAQEDCY5IAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,335,1596499200"; d="scan'208";a="27663068" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Oct 2020 09:54:49 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 0949snBj018345; Sun, 4 Oct 2020 09:54:49 GMT To: Yingzhen Qu , Gyan Mishra , Ron Bonica Cc: "lsr@ietf.org" , Jeff Tantsura References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> From: Peter Psenak Message-ID: <4996ea17-e0ac-9219-8f02-624cd61788c5@cisco.com> Date: Sun, 4 Oct 2020 11:54:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 09:54:56 -0000 Yingzhen, On 03/10/2020 20:08, Yingzhen Qu wrote: > Hi Peter, > > Using flex-algo, a SRv6 locator can be associated with a single algo, which means an IPv6 or IPv4 address can also be associated with a single algo. So my understanding is Ron's proposal is making the configuration of flex-algo easier? no. > Instead of using the exclude or include list you can configure a loopback address to a flex-algo directly? above has been done for SRv6 locators already. Now you can make that association for regular ipv4 and ipv6 prefixes. thanks, Peter > > Thanks, > Yingzhen > > On 10/3/20, 2:47 AM, "Peter Psenak" wrote: > > Hi Yingzhen, > > On 02/10/2020 22:15, Yingzhen Qu wrote: > > Hi Peter, > > > > My understanding of flex-algo is that for traffic destined to a prefix on a particular algo, it can only be routed on routers belong to that algo, which also means only routers in that algo calculates how to reach that prefix and install it into the routing table. It seems to me that using flex-algo (section 12 of the draft) it's possible to have a loopback address associated with only one algo, please correct me if I'm missing or misunderstood something. > > you are right. That is exactly what is being done for flex-algo with > SRv6 - locator is associated with a single algo only. The proposal uses > the same concept. > > thanks, > Peter > > > > > Thanks, > > Yingzhen > > > > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" wrote: > > > > Gyan, > > > > On 02/10/2020 18:30, Gyan Mishra wrote: > > > All, > > > > > > With SRv6 and IP based flex algo a generic question as it applies to > > > both. Is it possible to have within a single IGP domain different sets > > > of nodes or segments of the network running different algorithms. > > > > absolutely. > > > > > From > > > both drafts it sounds like all nodes have to agree on same algorithm > > > similar to concept of metric and reference bandwidth all have to have > > > the same style metric and play to the same sheet of music. > > > > all participating nodes need to agree on the definition of the flex-algo > > and advertise the participation. That's it. > > > > > If there was > > > a way to use multiple algorithms simultaneously based on SFC or services > > > and instantiation of specific algorithm based on service to be > > > rendered. Doing so without causing a routing loop or sub optimal > > > routing. > > > > you can certainly use multiple algorithms simultaneously and use algo > > specific paths to forward specific traffic over it. How that is done > > from the forwarding perspective depends in which forwarding plane you > > use. Flex-algo control plane is independent of the forwarding plane. > > > > > > >I thought with flex algo that there exists a feature that on > > > each hop there is a way to specify which algo to use hop by hop similar > > > to a hop by hop policy based routing. > > > > no, there is no hop-by-hop classification, that is problematic and does > > not scale for high speeds. Classification is done at the ingress only. > > > > thanks, > > Peter > > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cfe03124c6e414e067c2008d867816541%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637373152739865126&sdata=WI48cEAan%2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g%3D&reserved=0 > > > > > > > > > > From nobody Sun Oct 4 06:48:51 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CAC3A08B8 for ; Sun, 4 Oct 2020 06:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 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, T_REMOTE_IMAGE=0.01, T_SPF_HELO_TEMPERROR=0.01, 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=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 JiNElLg2y6ym for ; Sun, 4 Oct 2020 06:48:39 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 EB7523A08B1 for ; Sun, 4 Oct 2020 06:48:38 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id r21so92000uaw.10 for ; Sun, 04 Oct 2020 06:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y+pOQuJapU0NmA338z1jQtwfBOaeQUU8lH1+xcYXH4Y=; b=loAfC5UpwluJd6d9GapuI1XqQNDckdimrwFK2SslP8+5DbLiTZrriU2zCs9Yy1anfD VqZWnCBzoL6bwy2UG+t+DbjLIQXsMleNMmzzvPy232gxfpGpqFw3ht6ZXw4L6ptoaAns e37m5zSXOFkYswfevMtJFgQmJ52h+7aoq6WQVN/CAXPKkqa9OI7wILSK3lvqV4Up9SiG LqUTXZvmJHwa/+lviLSGRSxc6kfhkfHneCQ7cac6ouS2NR/+iElCMqxKm7c7Dojeb2I8 fZBdrgSQRuJTQalcWLC2Sr7JopQMfFrObWmFTz2h4oLDIWw0J4GP/Ch5bfa8T53dSnBV bR3w== 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=y+pOQuJapU0NmA338z1jQtwfBOaeQUU8lH1+xcYXH4Y=; b=B57VvBdukJffV+JE6j4/XHZr1eFDr4WNBgYWdfbtn5TJsFoatz5GkWAIcidVkT/Z93 B90cdCQ8iHGhuKhkv4EjCPpFsjYkgdWsuFVeXLFEFkBl1TXGMTtgSvg/lYrMsMJNXAT+ DRPGA2CZ/JMPfnVuz5+zEP4TDa4pugjJPBAr12HZ4HDW4YBJIocL/xLPBr9/GQOecPlT /OBLPynkYbv5KrYLPb22ToiOcBtjBRc4jvvmLXpJEYe0nNuoQm9D7uq3zP7hlz1HmZvf 238IsCQlE5PScxNbWfOpWeCXaQD73XAAgvx5UjtUI1HDzVV7lT2dn/4mRDaJHC3U9yRm nszA== X-Gm-Message-State: AOAM531dpzbzKScUGck9KuvWqKEFQM2vMRPgX2U1R5mYYyjKE8OmnWRx L+4715O98iWGgULbGC5BPUO4GeQiiDBeZ+MJ8RI= X-Google-Smtp-Source: ABdhPJzlU20g0BF7B2DJK77pZ0Q580EnWdD/smpUZRVvzfGMIjLIPmG/CUQza2wiqF5ncvhMj+ekpdURXDEU6QhrUoY= X-Received: by 2002:ab0:c11:: with SMTP id a17mr4851561uak.141.1601819317668; Sun, 04 Oct 2020 06:48:37 -0700 (PDT) MIME-Version: 1.0 References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <047be764-8203-ca46-7ee1-6f84f7bf2356@cisco.com> In-Reply-To: From: Gyan Mishra Date: Sun, 4 Oct 2020 09:48:26 -0400 Message-ID: To: Peter Psenak Cc: Jeff Tantsura , Ron Bonica , Yingzhen Qu , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006c8e4c05b0d89fb4" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 13:48:49 -0000 --0000000000006c8e4c05b0d89fb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Peter! On Sun, Oct 4, 2020 at 5:51 AM Peter Psenak wrote: > Hi Gyan, > > > > On 03/10/2020 18:54, Gyan Mishra wrote: > > > > > > Thanks Peter for the responses to help clear up my flex algo > understanding!! > > > > > > On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak > > > wrote: > > > > > > Gyan, > > > > > > > > > > > > On 03/10/2020 02:14, Gyan Mishra wrote: > > > > > > > > > > > > > > Hi Jeff > > > > > > > > > > > > > > From a domain perspective where you have a group of nodes and > > > > > > > associated IP addressed and SID are part of a discrete underlay > > > instance > > > > > > > flex algo topology. On those same set of nodes you could have > > > another > > > > > > > topology and associated address and SIDs for a different flex > algo. > > > > > > > > > > > > above is right. > > > > > > > > > Gyan> So per my response to Robert, what I was thinking is that a= s > > > the algo 0 strict spf would be used as the base algo to provide > > > reachability to all nodes within the domain and all neighbors are forme= d > > > between all nodes in the domain to populate IGP rib providing base > > > connectivity reachability. So then underneath of that you can have any > > > subset of nodes out of the superset all top layer domain nodes level > > > that can run any other algo desired. Basically creating algo layers > > > under the top domain wide layer. > > > > pretty much. > > > > > > > > > > > > > > > > > > > > How > > > > > > > this would work is that the topologies would have to be > > > segregated from > > > > > > > each other as different MT instances or routing process > > > instances. Is > > > > > > > that correct? > > > > > > > > > > > > no MT at all. You can think of each flex-algo as a set of constrain= ts > > > > > > that is used to calculate the path over the common topology. You ca= n > > > > > > have many such felx-algos running on a common topology. > > > > > > > > > Gyan> Is it safe to say that we can think of it as RSVP TE =E2=80= =9Clike=E2=80=9D > > > cSPF constraints that we are build via traffic engineering PCALC > > > algorithms to run for dynamic LSP dyamic ERO that is built based on IGP > > > constraints from TEDs database of TE link attributes and TE or IGP > > > weights metric constraints to create the dynamic LSP path. > > > > you can think of a flex-algo as a TE like solution, but there are some > > major differences to RSVP-TE: > > > > - automatic calculation of flex-algo constrained based paths from any > > source to any destination. This is in contrast to p2p nature of RSVP-TE. > > > > - there is no TED, all information is stored in IGP LSDB. > > > > > > > > > > > So we could > > > think of in TE framework analogy to flex algo In the per VRF TE next ho= p > > > vpn coloring use case with different loopback next hop rewrite per VRF > > > that normal IGP non TE BAU VPNs traffic would be like the flex algo bas= e > > > strict algo 0 and the non zero discrete algo would be like the per VRF > > > next hop loopback rewrite where each per VRF te loopback rewrite would > > > be a different steering non zero discrete flex algo all running in > > > parallel as ships in the night with the base algo 0. Sorry for the > > > complex analogy but I think I am getting it!!=F0=9F=98=83 > > > > steering the traffic to flex-algo paths can be done using different > > methods - per-destination, per flow, etc. Various coloring mechanism can > > be used as well, if needed. > > > > > > > > > > Does a flex algo use case draft exist and if not I would not mind using > > > the analogy I said above and build out a use case draft. Cheers! =F0= =9F=98=8A > > > > > > I'm not a fan of use case drafts. These should be vendor specific > > documents, no need to make them standards. > > > > thanks, > > Peter > > > > > > > > > > > > > > > > > > > > > > > Can two nodes that run two different flex algo become ospf or is= is > > > > > > > neighbors? > > > > > > > > > > > > absolutely. > > > > > > > > > > > > Peter > > > > > > > > > > > > > > > > > > > > Kind Regards > > > > > > > > > > > > > > Gyan > > > > > > > > > > > > > > On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Yingzhen, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, that=E2=80=99s the case. The most important property o= f an algo > > > > > > > computed path is that is has to be consecutive, as either SI= D > > > or IP > > > > > > > address associated with a particular topology is only known > > > within > > > > > > > that topology. > > > > > > > > > > > > > > > > > > > > > Looking specifically at Ron=E2=80=99s draft (MPLS could be m= ore > > > complex due > > > > > > > to potential hierarchy) - the prefix itself defines the > > > > > > > context(topology) and must be globally unique, since IPv4 > header > > > > > > > can=E2=80=99t have any additional meta-data attached. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu > > > > > > > > > > > > >>, wrote: > > > > > > > > > > > > > > > > > > > > >> Hi Peter, > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> My understanding of flex-algo is that for traffic destined > to a > > > > > > >> prefix on a particular algo, it can only be routed on route= rs > > > > > > >> belong to that algo, which also means only routers in that > algo > > > > > > >> calculates how to reach that prefix and install it into the > > > > > > >> routing table. It seems to me that using flex-algo (section > > > 12 of > > > > > > >> the draft) it's possible to have a loopback address > associated > > > > > > >> with only one algo, please correct me if I'm missing or > > > > > > >> misunderstood something. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> Thanks, > > > > > > >> > > > > > > >> > > > > > > >> Yingzhen > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > > > > > > >> > > > > on > behalf of > > > > > > >> ppsenak=3D40cisco.com@dmarc.ietf.org > > > > > > > > > >> > > >> wrote: > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> Gyan, > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> On 02/10/2020 18:30, Gyan Mishra wrote: > > > > > > >> > > > > > > >> > > > > > > >>> All, > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> With SRv6 and IP based flex algo a generic question as it > > > applies to > > > > > > >>> > > > > > > >>> > > > > > > >>> both. Is it possible to have within a single IGP domain > > > different > > > > > > >>> sets > > > > > > >>> > > > > > > >>> > > > > > > >>> of nodes or segments of the network running different > > > algorithms. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> absolutely. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>> From > > > > > > >>> > > > > > > >>> > > > > > > >>> both drafts it sounds like all nodes have to agree on same > > > algorithm > > > > > > >>> > > > > > > >>> > > > > > > >>> similar to concept of metric and reference bandwidth all > > > have to have > > > > > > >>> > > > > > > >>> > > > > > > >>> the same style metric and play to the same sheet of music. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> all participating nodes need to agree on the definition of > the > > > > > > >> flex-algo > > > > > > >> > > > > > > >> > > > > > > >> and advertise the participation. That's it. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>> If there was > > > > > > >>> > > > > > > >>> > > > > > > >>> a way to use multiple algorithms simultaneously based on > SFC or > > > > > > >>> services > > > > > > >>> > > > > > > >>> > > > > > > >>> and instantiation of specific algorithm based on service t= o > be > > > > > > >>> > > > > > > >>> > > > > > > >>> rendered. Doing so without causing a routing loop or sub > > > optimal > > > > > > >>> > > > > > > >>> > > > > > > >>> routing. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> you can certainly use multiple algorithms simultaneously an= d > > > use algo > > > > > > >> > > > > > > >> > > > > > > >> specific paths to forward specific traffic over it. How tha= t > > > is done > > > > > > >> > > > > > > >> > > > > > > >> from the forwarding perspective depends in which forwarding > > > plane you > > > > > > >> > > > > > > >> > > > > > > >> use. Flex-algo control plane is independent of the > > > forwarding plane. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>> I thought with flex algo that there exists a feature that = on > > > > > > >>> > > > > > > >>> > > > > > > >>> each hop there is a way to specify which algo to use hop b= y > hop > > > > > > >>> similar > > > > > > >>> > > > > > > >>> > > > > > > >>> to a hop by hop policy based routing. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> no, there is no hop-by-hop classification, that is > > > problematic and > > > > > > >> does > > > > > > >> > > > > > > >> > > > > > > >> not scale for high speeds. Classification is done at the > > > ingress only. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> thanks, > > > > > > >> > > > > > > >> > > > > > > >> Peter > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> > > > > > > >> > > > > > > >> Lsr mailing list > > > > > > >> > > > > > > >> > > > > > > >> Lsr@ietf.org > > > > > > > > > >> > > > > > > >> > > > > > > >> > > > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Flsr&data=3D02%7C01%7Cyingzhen.qu%40futur= ewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591f= edc%7C1%7C0%7C637372537869296887&sdata=3DR%2FI%2BAUkcw12FmgDtsh%2FBOL7z= LjPF%2BwwRpqwnE2Ndv%2Fg%3D&reserved=3D0 > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Gyan Mishra* > > > > > > > > > > > > > > /Network Solutions A//rchitect / > > > > > > > > > > > > > > /M 301 502-1347 > > > > > > > 13101 Columbia Pike > > > > > > > /Silver Spring, MD > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > *Gyan Mishra* > > > > > > /Network Solutions A//rchitect / > > > > > > /M 301 502-1347 > > > 13101 Columbia Pike > > > /Silver Spring, MD > > > > > > > > > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000006c8e4c05b0d89fb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Peter!

On Sun, Oct 4, 2020 at 5= :51 AM Peter Psenak <ppsenak@cisco.= com> wrote:
Hi Gyan,

=

On 03/10/2020 18:54, Gyan Mishra wrote:

>

> Th= anks Peter for the responses to help clear up my flex algo understanding!!<= br>
>

> On Sat, Oct 3, 2020 at 5:45 AM Peter Psenak <ppsenak@cisco.com =

> <mailto:ppsenak@cisco.com>> wrote:

>

>=C2=A0 =C2= =A0 =C2=A0Gyan,

>

>

>

>=C2=A0 = =C2=A0 =C2=A0On 03/10/2020 02:14, Gyan Mishra wrote:

>

&g= t;=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 &g= t; Hi =C2=A0Jeff

>

>=C2=A0 =C2=A0 =C2=A0 >

&= gt;

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 From a domain perspective w= here you have a group of nodes and

>

>=C2=A0 =C2=A0 = =C2=A0 > associated IP addressed and SID are part of a discrete underlay=

>=C2=A0 =C2=A0 =C2=A0instance

>

>=C2=A0 =C2= =A0 =C2=A0 > flex algo topology.=C2=A0 On those same set of nodes you co= uld have

>=C2=A0 =C2=A0 =C2=A0another

>

>=C2= =A0 =C2=A0 =C2=A0 > topology and associated address and SIDs for a diffe= rent flex algo.

>

>

>

>=C2=A0 = =C2=A0 =C2=A0above is right.

>

>

>=C2=A0 = =C2=A0 =C2=A0Gyan> =C2=A0So per my response to Robert, what =C2=A0I was = thinking is that as

> the algo 0 strict spf would be used as the= base algo to provide

> reachability to all nodes within the dom= ain and all neighbors are formed

> between all nodes in the doma= in to populate IGP rib providing base

> connectivity reachabilit= y.=C2=A0 So then underneath of that you can have any

> subset of= nodes out of the superset all top layer domain nodes level

>=C2= =A0 =C2=A0that can run any other algo desired. Basically creating algo laye= rs

> under the top domain wide layer.



pretty much= .





>

>

>

>
>=C2=A0 =C2=A0 =C2=A0 > How

>

>=C2=A0 =C2=A0 = =C2=A0 > this would work is that the topologies would have to be

= >=C2=A0 =C2=A0 =C2=A0segregated from

>

>=C2=A0 =C2= =A0 =C2=A0 > each other as different MT instances or routing process
=
>=C2=A0 =C2=A0 =C2=A0instances.=C2=A0 Is

>

>=C2= =A0 =C2=A0 =C2=A0 > that correct?

>

>

> =

>=C2=A0 =C2=A0 =C2=A0no MT at all. You can think of each flex-al= go as a set of constraints

>

>=C2=A0 =C2=A0 =C2=A0that= is used to calculate the path over the common topology. You can

>= ;

>=C2=A0 =C2=A0 =C2=A0have many such felx-algos running on a co= mmon topology.

>

>

>=C2=A0 =C2=A0 =C2=A0 Gy= an> Is it safe to say that we can think of it as RSVP TE =E2=80=9Clike= =E2=80=9D

> cSPF constraints that we are build via traffic engin= eering PCALC

> algorithms to run for dynamic LSP dyamic ERO that= is built based on IGP

> constraints from TEDs database of TE li= nk attributes and TE or IGP

> weights metric constraints to crea= te the dynamic LSP path.=C2=A0



you can think of a flex-algo= as a TE like solution, but there are some

major differences to RSV= P-TE:



- automatic calculation of flex-algo constrained based= paths from any

source to any destination. This is in contrast to p= 2p nature of RSVP-TE.



- there is no TED, all information is = stored in IGP LSDB.









> So we could=

> think of in TE framework analogy to flex algo In the per VRF = TE next hop

> vpn coloring use case with different loopback next= hop rewrite per VRF

> that normal IGP non TE BAU VPNs traffic w= ould be like the flex algo base

> strict algo 0 and the non zero= discrete algo would be like the per VRF

> next hop loopback rew= rite where each per VRF te loopback rewrite would

> be a differe= nt steering non zero discrete flex algo all running in

> paralle= l as ships in the night with the base algo 0. =C2=A0 Sorry for the

= > complex analogy but I think I am getting it!!=F0=9F=98=83


<= br>steering the traffic to flex-algo paths can be done using different
=
methods - per-destination, per flow, etc. Various coloring mechanism ca= n

be used as well, if needed.





>

&= gt; Does a flex algo use case draft exist and if not I would not mind using=

> the analogy I said above and build out a use case draft.=C2= =A0 Cheers! =F0=9F=98=8A





I'm not a fan of use ca= se drafts. These should be vendor specific

documents, no need to ma= ke them standards.



thanks,

Peter

>

= >

>

>

>=C2=A0 =C2=A0 =C2=A0 >
>

>=C2=A0 =C2=A0 =C2=A0 > Can two nodes that run two diff= erent flex algo become ospf or isis

>

>=C2=A0 =C2=A0 = =C2=A0 > neighbors?

>

>

>

>= =C2=A0 =C2=A0 =C2=A0absolutely.

>

>

>
<= br>>=C2=A0 =C2=A0 =C2=A0Peter

>

>

>
=
>=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2= =A0 > Kind Regards

>

>=C2=A0 =C2=A0 =C2=A0 >
=
>

>=C2=A0 =C2=A0 =C2=A0 > Gyan

>

>= ;=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >= ; On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura

>=C2=A0 =C2=A0 =C2= =A0<jefftan= t.ietf@gmail.com <mailto:jefftant.ietf@gmail.com>

>

>= =C2=A0 =C2=A0 =C2=A0 > <mailto:jefftant.ietf@gmail.com

>=C2=A0 =C2=A0= =C2=A0<mailto:jefftant.ietf@gmail.com>>> wrote:

>

>= =C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >=

>

>=C2=A0 =C2=A0 =C2=A0 >

>

>= =C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >=

>

>=C2=A0 =C2=A0 =C2=A0 >

>

>= =C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >=

>

>=C2=A0 =C2=A0 =C2=A0 >

>

>= =C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >=

>

>=C2=A0 =C2=A0 =C2=A0 >

>

>= =C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >= =C2=A0 =C2=A0 =C2=A0Hi Yingzhen,

>

>=C2=A0 =C2=A0 =C2= =A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >

>
=
>=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2= =A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >

>
=
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Yes, that=E2=80=99s th= e case.=C2=A0=C2=A0The most important property of an algo

>
<= br>>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0computed path is that i= s has to be consecutive, as either SID

>=C2=A0 =C2=A0 =C2=A0or IP=

>

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0addre= ss associated with a particular topology is only known

>=C2=A0 = =C2=A0 =C2=A0within

>

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0= =C2=A0 =C2=A0that topology.

>

>=C2=A0 =C2=A0 =C2=A0 &= gt;

>

>=C2=A0 =C2=A0 =C2=A0 >

>

&= gt;=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Looking specifically at Ron= =E2=80=99s draft (MPLS could be more

>=C2=A0 =C2=A0 =C2=A0complex= due

>

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= o potential hierarchy) - the prefix itself defines the

>

= >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0context(topology) and must= be globally unique, since IPv4 header

>

>=C2=A0 =C2= =A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0can=E2=80=99t have any additional meta-d= ata attached.

>

>=C2=A0 =C2=A0 =C2=A0 >

>=

>=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2= =A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >

&g= t;

>=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2= =A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >

&g= t;

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Cheers,

= >

>=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 = =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Jeff

>

>=C2=A0 = =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >
>

>=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 = =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >
>

>=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 = =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On Oct 2, 2020, 1:15 PM -0700, Yingzh= en Qu

>

>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0= <yingzhen= .qu@futurewei.com <mailto:yingzhen.qu@futurewei.com>

>=C2=A0 = =C2=A0 =C2=A0<mailto:yingzhen.qu@futurewei.com

>=C2=A0 =C2=A0 =C2=A0&l= t;mailto:yin= gzhen.qu@futurewei.com>>>, wrote:

>

>=C2= =A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >
>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Hi P= eter,

>

>=C2=A0 =C2=A0 =C2=A0 >>

>
>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2= =A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>
>

>=C2=A0 =C2=A0 =C2=A0 >>

>

&g= t;=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0My understanding of flex= -algo is that for traffic destined to a

>

>=C2=A0 =C2= =A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0prefix on a particular algo, it can = only be routed on routers

>

>=C2=A0 =C2=A0 =C2=A0 >= >=C2=A0 =C2=A0 =C2=A0belong to that algo, which also means only routers = in that algo

>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 = =C2=A0 =C2=A0calculates how to reach that prefix and install it into the
>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0rout= ing table. It seems to me that using flex-algo (section

>=C2=A0 = =C2=A0 =C2=A012 of

>

>=C2=A0 =C2=A0 =C2=A0 >>=C2= =A0 =C2=A0 =C2=A0the draft) it's possible to have a loopback address as= sociated

>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0= =C2=A0with only one algo, please correct me if I'm missing or

&= gt;

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0misunderst= ood something.

>

>=C2=A0 =C2=A0 =C2=A0 >>
>

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2= =A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >= ;>

>

>=C2=A0 =C2=A0 =C2=A0 >>

>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Thanks,

&g= t;

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0= =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >&g= t;=C2=A0 =C2=A0 =C2=A0Yingzhen

>

>=C2=A0 =C2=A0 =C2=A0= >>

>

>=C2=A0 =C2=A0 =C2=A0 >>

>=

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 = =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>= ;

>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0= On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak"

> =

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<lsr-bounces@ietf.org &l= t;mailto:lsr-boun= ces@ietf.org>

>=C2=A0 =C2=A0 =C2=A0<mailto:lsr-bounces@ietf.org <= mailto:lsr-bounce= s@ietf.org>> on behalf of

>

>=C2=A0 =C2=A0 = =C2=A0 >>=C2=A0 =C2=A0 =C2=A0ppsenak=3D40cisco.com@dmarc.ietf.org

>= ;=C2=A0 =C2=A0 =C2=A0<mailto:40cisco.com@dmarc.ietf.org>

>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0<mailto:40cisco.com@dmarc.iet= f.org

>=C2=A0 =C2=A0 =C2=A0<mailto:40cisco.com@dmarc.ietf.org>= >> wrote:

>

>=C2=A0 =C2=A0 =C2=A0 >>
>

>=C2=A0 =C2=A0 =C2=A0 >>

>

>= =C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 = >>

>

>=C2=A0 =C2=A0 =C2=A0 >>

> =

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Gyan,

&= gt;

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2= =A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >= ;>

>

>=C2=A0 =C2=A0 =C2=A0 >>

>
>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2= =A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0On 02/10/2020 18:30, Gyan Mishra wro= te:

>

>=C2=A0 =C2=A0 =C2=A0 >>

>
<= br>>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 = =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0All,

>

>=C2=A0 = =C2=A0 =C2=A0 >>>

>

>=C2=A0 =C2=A0 =C2=A0 >= ;>>

>

>=C2=A0 =C2=A0 =C2=A0 >>>

= >

>=C2=A0 =C2=A0 =C2=A0 >>>

>

>= =C2=A0 =C2=A0 =C2=A0 >>>

>

>=C2=A0 =C2=A0 =C2= =A0 >>>=C2=A0 =C2=A0 =C2=A0With SRv6 and IP based flex algo a gene= ric question as it

>=C2=A0 =C2=A0 =C2=A0applies to

>
>=C2=A0 =C2=A0 =C2=A0 >>>

>

>=C2=A0 = =C2=A0 =C2=A0 >>>

>

>=C2=A0 =C2=A0 =C2=A0 >= ;>>=C2=A0 =C2=A0 =C2=A0both. Is it possible to have within a single I= GP domain

>=C2=A0 =C2=A0 =C2=A0different

>

>= =C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0sets

>
<= br>>=C2=A0 =C2=A0 =C2=A0 >>>

>

>=C2=A0 =C2= =A0 =C2=A0 >>>

>

>=C2=A0 =C2=A0 =C2=A0 >&g= t;>=C2=A0 =C2=A0 =C2=A0of nodes or segments of the network running diffe= rent

>=C2=A0 =C2=A0 =C2=A0algorithms.

>

>=C2= =A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >= ;>

>

>=C2=A0 =C2=A0 =C2=A0 >>

>
>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2= =A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>= =C2=A0 =C2=A0 =C2=A0absolutely.

>

>=C2=A0 =C2=A0 =C2= =A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>

&= gt;

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2= =A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >= ;>

>

>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2= =A0 =C2=A0From

>

>=C2=A0 =C2=A0 =C2=A0 >>>
>

>=C2=A0 =C2=A0 =C2=A0 >>>

>
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0both drafts it so= unds like all nodes have to agree on same

>=C2=A0 =C2=A0 =C2=A0al= gorithm

>

>=C2=A0 =C2=A0 =C2=A0 >>>

&g= t;

>=C2=A0 =C2=A0 =C2=A0 >>>

>

>= =C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0similar to concept of = metric and reference bandwidth all

>=C2=A0 =C2=A0 =C2=A0have to h= ave

>

>=C2=A0 =C2=A0 =C2=A0 >>>

> <= br>
>=C2=A0 =C2=A0 =C2=A0 >>>

>

>=C2=A0= =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0the same style metric and pl= ay to the same sheet of music.

>

>=C2=A0 =C2=A0 =C2=A0= >>

>

>=C2=A0 =C2=A0 =C2=A0 >>

>=

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 = =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>= ;

>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0= all participating nodes need to agree on the definition of the

> =

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0flex-algo
<= br>>

>=C2=A0 =C2=A0 =C2=A0 >>

>

>= =C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 = >>=C2=A0 =C2=A0 =C2=A0and advertise the participation. That's it.=

>

>=C2=A0 =C2=A0 =C2=A0 >>

>

= >=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2= =A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>

&= gt;

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2= =A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0If there was

> =

>=C2=A0 =C2=A0 =C2=A0 >>>

>

>=C2= =A0 =C2=A0 =C2=A0 >>>

>

>=C2=A0 =C2=A0 =C2=A0= >>>=C2=A0 =C2=A0 =C2=A0a way to use multiple algorithms simultane= ously based on SFC or

>

>=C2=A0 =C2=A0 =C2=A0 >>= >=C2=A0 =C2=A0 =C2=A0services

>

>=C2=A0 =C2=A0 =C2= =A0 >>>

>

>=C2=A0 =C2=A0 =C2=A0 >>><= br>
>

>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2= =A0and instantiation of specific algorithm based on service to be

&g= t;

>=C2=A0 =C2=A0 =C2=A0 >>>

>

>= =C2=A0 =C2=A0 =C2=A0 >>>

>

>=C2=A0 =C2=A0 =C2= =A0 >>>=C2=A0 =C2=A0 =C2=A0rendered. Doing so without causing a ro= uting loop or sub

>=C2=A0 =C2=A0 =C2=A0optimal

>
>=C2=A0 =C2=A0 =C2=A0 >>>

>

>=C2=A0 =C2= =A0 =C2=A0 >>>

>

>=C2=A0 =C2=A0 =C2=A0 >&g= t;>=C2=A0 =C2=A0 =C2=A0routing.

>

>=C2=A0 =C2=A0 = =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>
>

>=C2=A0 =C2=A0 =C2=A0 >>

>

>= =C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 = >>

>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0= =C2=A0you can certainly use multiple algorithms simultaneously and

= >=C2=A0 =C2=A0 =C2=A0use algo

>

>=C2=A0 =C2=A0 =C2= =A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>

&= gt;

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0specific p= aths to forward specific traffic over it. How that

>=C2=A0 =C2=A0= =C2=A0is done

>

>=C2=A0 =C2=A0 =C2=A0 >>
>

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2= =A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0from the forwarding perspecti= ve depends in which forwarding

>=C2=A0 =C2=A0 =C2=A0plane you
=
>

>=C2=A0 =C2=A0 =C2=A0 >>

>

>= =C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 = >>=C2=A0 =C2=A0 =C2=A0use. Flex-algo control plane is independent of = the

>=C2=A0 =C2=A0 =C2=A0forwarding plane.

>

&g= t;=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2= =A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>

&= gt;

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2= =A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >= ;>

>

>=C2=A0 =C2=A0 =C2=A0 >>

>
>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2= =A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0I thought with flex algo that th= ere exists a feature that on

>

>=C2=A0 =C2=A0 =C2=A0 &= gt;>>

>

>=C2=A0 =C2=A0 =C2=A0 >>>
>

>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0eac= h hop there is a way to specify which algo to use hop by hop

>
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0similar
<= br>>

>=C2=A0 =C2=A0 =C2=A0 >>>

>

&= gt;=C2=A0 =C2=A0 =C2=A0 >>>

>

>=C2=A0 =C2=A0 = =C2=A0 >>>=C2=A0 =C2=A0 =C2=A0to a hop by hop policy based routing= .

>

>=C2=A0 =C2=A0 =C2=A0 >>

>
>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 = =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>
>

>=C2=A0 =C2=A0 =C2=A0 >>

>

>= =C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0no, there is no hop-by-hop= classification, that is

>=C2=A0 =C2=A0 =C2=A0problematic and
=
>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0does<= br>
>

>=C2=A0 =C2=A0 =C2=A0 >>

>

&= gt;=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2= =A0 >>=C2=A0 =C2=A0 =C2=A0not scale for high speeds. Classification i= s done at the

>=C2=A0 =C2=A0 =C2=A0ingress only.

>
=
>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0= =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>
<= br>>

>=C2=A0 =C2=A0 =C2=A0 >>

>

>= =C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 = >>=C2=A0 =C2=A0 =C2=A0thanks,

>

>=C2=A0 =C2=A0 = =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>
>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Peter
>

>=C2=A0 =C2=A0 =C2=A0 >>

>

&g= t;=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2= =A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>

&= gt;

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2= =A0 =C2=A0 =C2=A0 >>>

>

>=C2=A0 =C2=A0 =C2=A0= >>

>

>=C2=A0 =C2=A0 =C2=A0 >>

>=

>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 = =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>= ;

>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0= _______________________________________________

>

>=C2= =A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >= ;>

>

>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 = =C2=A0Lsr mailing list

>

>=C2=A0 =C2=A0 =C2=A0 >>= ;

>

>=C2=A0 =C2=A0 =C2=A0 >>

>
>=C2=A0 =C2=A0 =C2=A0 >> Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org

>=C2=A0 =C2=A0 =C2=A0<m= ailto:Lsr@ietf.org>= ;>

>

>=C2=A0 =C2=A0 =C2=A0 >>

>
>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2= =A0 =C2=A0 >>

>=C2=A0 =C2=A0 =C2=A0https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= .ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=3D02%7C01%7Cyingzhen.qu%4= 0futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1= d5591fedc%7C1%7C0%7C637372537869296887&amp;sdata=3DR%2FI%2BAUkcw12FmgDt= sh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&amp;reserved=3D0

> <= br>
>=C2=A0 =C2=A0 =C2=A0 >>

>

>=C2=A0 =C2= =A0 =C2=A0 >>

>

>=C2=A0 =C2=A0 =C2=A0 >>
>

>=C2=A0 =C2=A0 =C2=A0 >

>

>= =C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >=

>

>=C2=A0 =C2=A0 =C2=A0 >

>

>= =C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >=

>

>=C2=A0 =C2=A0 =C2=A0 >

>

>= =C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >= --

>

>=C2=A0 =C2=A0 =C2=A0 >

>

&= gt;=C2=A0 =C2=A0 =C2=A0 > <http://www.verizon.com/>

> =

>=C2=A0 =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0= =C2=A0 > *Gyan Mishra*

>

>=C2=A0 =C2=A0 =C2=A0 >= ;

>

>=C2=A0 =C2=A0 =C2=A0 > /Network Solutions A//r= chitect /

>

>=C2=A0 =C2=A0 =C2=A0 >

>
>=C2=A0 =C2=A0 =C2=A0 > /M 301 502-1347

>

>= =C2=A0 =C2=A0 =C2=A0 > 13101 Columbia Pike

>

>=C2= =A0 =C2=A0 =C2=A0 > /Silver Spring, MD

>

>=C2=A0 = =C2=A0 =C2=A0 >

>

>=C2=A0 =C2=A0 =C2=A0 >
>

>

>

> --

>

> &= lt;http://www.verizon.com/>

>

> *Gyan Mishra*
=
>

> /Network Solutions A//rchitect /

>

= > /M 301 502-1347

> 13101 Columbia Pike

> /Silver Sp= ring, MD

>

>



= --


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
<= /i>Silver Spring, MD


=
--0000000000006c8e4c05b0d89fb4-- From nobody Sun Oct 4 22:19:36 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9379B3A0D84; Sun, 4 Oct 2020 22:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=Xz+Klf02; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EoKrj+oB 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 MrL-8eLEmu5n; Sun, 4 Oct 2020 22:19:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AA73A0D82; Sun, 4 Oct 2020 22:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=781; q=dns/txt; s=iport; t=1601875172; x=1603084772; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yZOpDkTohn+vvaDubJdmOgrWWN+uD5JNVOsbcNnEwyw=; b=Xz+Klf025He6vPbI5vA94CvShygNfPOzNMWPo7CSiDYHQAAEwGdOkv9T qiTmnxqHapEW4QZyx3CeM5FseEVOWDI4swa73/du6rBOt5ytnD+WU7fvu iELAZ+vGSM3bGfSLL+/yXHzBJGQmvT6ks9H1+BMx5gMHg5XY/tZO7IxLE w=; IronPort-PHdr: =?us-ascii?q?9a23=3ASfGSnRJudOweMbeEDtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKs/h1/ORZ3ArfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBteGMHmf0aUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlCQCLrHpf/4kNJK1ggQmDIVEHcFk?= =?us-ascii?q?vLAqHeQONcJh7glMDVQsBAQENAQEjCgIEAQGESgKCNgIlOBMCAwEBCwEBBQE?= =?us-ascii?q?BAQIBBgRthVwMhXIBAQEBAxILHQYBATcBCwQCAQgOAwQBAR8QMh0IAgQBDQU?= =?us-ascii?q?IGoMFgksDLgEOnBwCgTmIYXSBNIMBAQEFgUdBgwwYghADBoE4gnKKPxuBQT+?= =?us-ascii?q?BVIJNPoJcAgMBgV2DSIItt1EKgmeIfpIFgw6KApQPkg4MeopulSgCBAIEBQI?= =?us-ascii?q?OAQEFgWsjgVdwFTuCaVAXAg2SEIUUhUJ0NwIGCgEBAwl8jDsBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.77,338,1596499200"; d="scan'208";a="807105058" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Oct 2020 05:19:28 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0955JSdm019717 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2020 05:19:28 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 00:19:28 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 00:19:27 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 5 Oct 2020 00:19:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cjebtiRE0xFlrIQN4b1Dggg48PTm43FspBJvBJGrM1Y3N0Nf8YoZ2g6iK/RHWRUrDseJrpT1uPOJw6Pxd07FdmmZt4kttkIO5nA29hEqbEmrKxt9QdG0pCSEXqx2giBfLyHcSlbC61PuCi8VBnLF0fzbtqPtEzG5ShroPZy+zlfi1f+e9kybFbvZ0OWTICIEBjwyek73u5iJ0ih9getT9qhFpu6KgjcO2GWSPTMyZ8rMmJ+gxW2dVuvef8pVNKylqfDd6dyEOS9uErW6tag3llHfWrK60YtslKvOAw8anInslfqc+rpcVN0vG80WWFNIcFt9/EXmhm0Xo9e78Rm+7g== 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=r6SH6YQOnr49g/PCR8MNNkOL4CAUVbfxDTzkKyDGCOc=; b=hMvwmrYQ9KihhjpYNG4oFi/JKQkJuKqxq/cEORKpptCBs6sILdoN9FusGD1LaG5LKo4UzlEi+Xz8mZVDmAq6mqH6m5xfrTXM0cPdXHTmqvnYcMJ5NDhjeBaH3uifM9JY9XrYAXfQ9LEptRMfhb9VSIM04j4Es8yxI7+4Liyg5aAkWsskGH7U0ygG2anvLvW6RwkmgkZYECh+uApnqlfRqWRj206hsQ9JSPfNkx+FpyncU1PQsQHIlbKg8O4+F9RihUYOPhKKqMOtj0tp/yv5/RJQ2qaEpFWi65OeFcz30afcir59loN0SYD7ssPi/qfJ1zJOTxp4oIAsNWZk8WUywg== 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=r6SH6YQOnr49g/PCR8MNNkOL4CAUVbfxDTzkKyDGCOc=; b=EoKrj+oB84zEkSoA2QA8K0lw8HIv3KB0MIgiCjznnaupUAsPxb/FKWZDCmAiv9LuT6Slpe5PqLOtvlbziJL0+DvNIwjpxQTMZmCu8ajYizPdaaEkltus55JMyLAnaVz/yDYSlF0X7GzqoitqXo2BjWv+45hvIGrBcSwgnVXcAsg= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB4931.namprd11.prod.outlook.com (2603:10b6:303:9d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.34; Mon, 5 Oct 2020 05:19:26 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3433.044; Mon, 5 Oct 2020 05:19:26 +0000 From: "Ketan Talaulikar (ketant)" To: Christian Hopps , "lsr@ietf.org" CC: "lsr-chairs@ietf.org" , "draft-ketant-lsr-ospf-l2bundles.all@ietf.org" Thread-Topic: WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 Thread-Index: AQHWmLQdTktsY4Cyrk21SHl6G08Z+KmIfIog Date: Mon, 5 Oct 2020 05:19:26 +0000 Message-ID: References: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> In-Reply-To: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.25] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 97d2ea29-589d-4bca-410f-08d868ee3a6b x-ms-traffictypediagnostic: CO1PR11MB4931: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: riXxlnwfjW7g4vo4Us/lOZoC4ES/rWVWKWI5jBeCTVcv1x2Ejn6nkIQsTo5A1kh2nS9ssUZaadXrfOltdqDwaMAuklqYmKEsOhfh2kjWRSOOqL89b+xt9T10qePJoFjZ68diExDgnvFEfW6rib6TfeS4N+FO/o72Az+SxFuwMv548MJ+VqeJ27Ms2b1iM0nHPZxmGyifgtBCn7mpKvXjasE6AHL8AYgBB3cRriGb4zJmIjNhX+Sr5fwb3F6cNiHsCmgIcKUTWoIXiqBNd2xQHmcp8E8EmueYe1NRaieIxGIjkUogMoLLkpUni2VsL1wxfNkjEQjjs+kJ/UKa5zQg/Bf1d0BJRICLANm08ZgSPatR90DrUMMRiXhblJBOzog9LDlq4bYe3hcC42pVYjICMA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(39860400002)(346002)(396003)(136003)(71200400001)(966005)(9686003)(76116006)(316002)(55016002)(4326008)(54906003)(110136005)(8936002)(8676002)(478600001)(86362001)(83380400001)(83080400001)(7696005)(33656002)(53546011)(64756008)(2906002)(26005)(66446008)(66556008)(6506007)(66476007)(186003)(52536014)(5660300002)(66946007)(4744005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ytZS2i7gmvzDTQx/RxEkEVACB2Ubw8wfgSJLvmlBdN4nbqKwbe8lGCckdmmrxCgmeWlaDD13VNT9Y5vIBIi3WP0e+Uml1Nc+TkIgD1YbUOX+FzwjUrGzWhmH8uyKOeJpVMykJ2VPeh4KWlnbIuikN7KD9UI8VlLDisb7DFIvOcTO2i05HRy85q+i0iLNNwiuxg1R8OT4L85ZzzcRg7X0qyfyXNvU/OBbJNbPtsA9yswqY5OHUhfp3kHUux6ZEE9YwJ52GSTogxhxM0FDkRU4OO/9JRbTUrf/d8LoFdhWjKz9e3KvT+IvLzoXFebjLRNAwxX50DQnY24kE/qjCpHKqlcWTc/Dv0zkFjqEiicS+v6x6Yay4grZ3NPWFMfdeji9rV5AoBBVNiknl3nEXpHje/g2sBoLyU76t+OpARg3kJyi32FgH93lBrsWUubBc9ZXodHWbIlpJOdKwEXtPZq6MWzv1655WuxeEZWd9GOyfzv86w4H2WZXLTTp9iA8dcPCgSd78erN2/U7F5tBw5eZuy2kwM3j4chV7KgRdi4XZkr+wC1e0opy2Omz4L2mqVOQYQW31+L6K8i6gpX7zNfs/5NfzqjXxfz002yeuQG80/MgXTd8DM7TfxNSMhyu2Npu7tDoCdnUCDeIxTxWTzoeJg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97d2ea29-589d-4bca-410f-08d868ee3a6b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2020 05:19:26.3193 (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: UXNWuemBjG+WwEMe1GrqSllZBwPXpBf3PitjKoUMFX4uwzKoxtnMdsvReAYEK1ZUnRkGfq8DjpSE+KcUOOEvBQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4931 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 05:19:35 -0000 I support the adoption of this document by the WG and as an author, I am no= t aware of any IPR associated with it. Thanks, Ketan -----Original Message----- From: Christian Hopps =20 Sent: 02 October 2020 17:33 To: lsr@ietf.org Cc: Christian Hopps ; lsr-chairs@ietf.org; draft-ketant-= lsr-ospf-l2bundles.all@ietf.org Subject: WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 This begins a 2 week WG adoption call for the following draft: https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ Please indicate your support or objection by October 16, 2020. Authors, please respond to the list indicating whether you are aware of any= IPR that applies to this draft. Thanks, Chris and Acee. From nobody Sun Oct 4 22:29:40 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78363A0D86; Sun, 4 Oct 2020 22:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.586 X-Spam-Level: X-Spam-Status: No, score=-9.586 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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=DerLOy8n; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PW4CHlkK 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 JaSQDAR-1_j8; Sun, 4 Oct 2020 22:29:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C7E3A0C32; Sun, 4 Oct 2020 22:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16860; q=dns/txt; s=iport; t=1601875776; x=1603085376; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4nRukunFTV75fxpfNOLE+yba6pdFY/hm0mdo6B54XjY=; b=DerLOy8niFjhEY2a5pS+rBKgVhWZfe5O36fsvlu1B+cIHsSjLiMfTTDi FIm9ZGNdcpa4GnVct7NyQgbg4dfaLXU/Je7cRIGTDlWk/xboTcJwnuIab BcQkwkz/2BO39IFXwxAIOyMj73jsr1+9jgnXZvN1t4IWrQ/v6mkfU0Tph 8=; IronPort-PHdr: =?us-ascii?q?9a23=3A82CYphdZsM4F4OOBIuw0O8W6lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMCgBarnpf/4UNJK1dA4N7L1EHcFk?= =?us-ascii?q?vLAqEM4NGA41vlAyEb4FCgREDVQsBAQENAQEYAQoKAgQBAYRKAheCHwIlOBM?= =?us-ascii?q?CAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgEBARALBgoTAQEsCwEEBwQCAQg?= =?us-ascii?q?HBwMEAQEoAwICAiULFAkIAgQBDQUIEweDBYF+TQMOIAEOnBUCgTmIYXaBMoM?= =?us-ascii?q?BAQEFgTMBE0GDEBiCEAmBIReCcoNphlYbgUE/gRBEgk0+glwBAQIBAYEmARI?= =?us-ascii?q?BIxUKBQcJCAmCUBccgi2TPYcCnRIKgmeIfpIFgw6KApQPkTJcDHqKbpUoAgQ?= =?us-ascii?q?CBAUCDgEBBYFrI2dwcBU7gmkJRxcCDY4rF4NOhRSFQnQCNQIGAQkBAQMJfIw?= =?us-ascii?q?7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,338,1596499200"; d="scan'208,217";a="562543530" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Oct 2020 05:29:35 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0955TZ5M013583 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2020 05:29:35 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 00:29:35 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 01:29:34 -0400 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 5 Oct 2020 00:29:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aUPnpvm2VbBzat3SwJ+Q2x702tB0EspRoxkJAIovpU5aeXo5emkEKXK8Lm9uVs3m8cIWqJjP2vhGXuQL8+42qxjbrn1XLTC/uJPGpJx5Izi7/14sJK++pD+leTlbMeF9Mts4oOBygiEqgHUOQC3iUXp4eWVtrBGagds7KlqTVh4oTZsuwnFIr+s8W9bV0TWz3gHukQJg+zLAc4qbSai8q6+YymvQEFYY8leURv/IGdF4d5kPMVNaAZjWnxplsivAZ7Bv98E4dfJ1WkNJqB8feNg3RmwU0CIDvVgdw6wJAmM0MJP8DOdn6dYeA420Wpv3pEAa1Kf+n752P08RmT52OA== 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=4nRukunFTV75fxpfNOLE+yba6pdFY/hm0mdo6B54XjY=; b=Eml8hMozwOZAt3Lqxpg5Is6Lu7/1W6RNripKx0d08ydhk5uZ4bT4CYq/7PQd50xCYPQcWuoMtyiOZoLYzmwzEUpOpxeZHPrT0+Q6AW0sGHq5gQxq6O+Jnp6EweUnfPYi9mzQhxiDshXxqnvgjapC9RZCq06bb58Rzbj4agDeZMzjBrh7nsAXCQuwmz/Bz++HFecwcLIL3fGkTbUJKedmZ4SSsNgmZ1CN3oOMkbxvkg5ja2CpBdPD8b9BA2th3Xro6ZTiosNWBmQ7L+TCXIqrA9HP7A6kFouTneF3v98MUDULrvPihKfCCCXcQ8fV+RhPk16iH8kUqQEbv8klvMeshw== 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=4nRukunFTV75fxpfNOLE+yba6pdFY/hm0mdo6B54XjY=; b=PW4CHlkKdYzWwf7OV/o6VaUqhjTAGu8sFyWSG5Gxlrt5gdauFSP/VhwF3f5dZYXhKQKFc3j4eYc9pOyHE22ZiuupzkFDwJfpwQTejSiLSuDpljEF8sTOgV/NEPIwY0Sdl/cEMJSDnHSdKunnSx+mC9WhtqcPb4vXuuCRkN0qsWA= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2270.namprd11.prod.outlook.com (2603:10b6:301:54::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38; Mon, 5 Oct 2020 05:29:32 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3433.044; Mon, 5 Oct 2020 05:29:32 +0000 From: "Ketan Talaulikar (ketant)" To: Gyan Mishra , "Les Ginsberg (ginsberg)" CC: "lsr@ietf.org" , "draft-ketant-lsr-ospf-l2bundles.all@ietf.org" , Christian Hopps , "lsr-chairs@ietf.org" Thread-Topic: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 Thread-Index: AQHWmLQdTktsY4Cyrk21SHl6G08Z+KmE4ICAgAAHJ4CAA5YzUA== Date: Mon, 5 Oct 2020 05:29:32 +0000 Message-ID: References: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.25] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 113d8b3b-9c60-4dba-df78-08d868efa3d9 x-ms-traffictypediagnostic: MWHPR1101MB2270: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: I1ptZkjUdvPeWGflTSdRxXuY5Drz0zPVHAW96Zciul+7uMCBDGRROXkxEqUyWk+cX72GLkFJwFzJ+L34wHq2UU5YSNy2gmoqsmd/hX6nPnGUeSi7LRFdXUkv3BHvkkv0M5Re4SthR+RJiaAZxnGrXi7c6G7A3jifYqN0HNzYr6ZcHSDPjCL2Bb7c+DbKmqsdDVJ1ahKtrllAOtUhuCOuKOxjbNDOqmDUWVqeX3+7lTmAdDGaeAy3EIJeNL/hoc7KhNslj7wiKmgVhjI35PjWENXfyfgGgTgzFPLYsGgsA1oPr3Pyaoo2oeu1jHZAOiEfArDrCFA14ZiqIt4j/7KaZtMLg8ykZN4v3TD+G/yXLbNCp3mhBbychNAxdFlelfA2BwCbvORgkh+1zH9+fRw1mg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(376002)(136003)(39860400002)(346002)(2906002)(966005)(33656002)(478600001)(316002)(7696005)(6506007)(186003)(110136005)(26005)(53546011)(54906003)(9326002)(71200400001)(5660300002)(86362001)(83380400001)(9686003)(83080400001)(8676002)(55016002)(66476007)(66946007)(64756008)(66556008)(8936002)(166002)(4326008)(66446008)(52536014)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: jBvichiMXY2pZfuCsD2kWe3ABxOkHcen9ySUqNIteDUz0Tbkx9KV8Cf1/ul9CrGtIsAC/B+X6+2ZXDiUWWH59FkqVaMaMxQ4yyggRXz7aFJBDYvT1Gka8Pg0eRzhv3VRzPCskgqrJL3F4BN6epOPWogpTZ/zq/FjXpY4Y8YwiNFUOnIAgNq5WR621VZTHZmQjKjGWrJxBQ77jwxoLKJ/cz3usgYbEeWIQKGl7cSO5gTl5nHzklDby62igDmVBbRyWr4a8/0OmqSeC8lzfn7QvyC4DDJLRxOOAeIyH+u4iy14Fpi0GW8V6rHIKZbEWgyabp+YClTlJguC5smRiCSP18vu9vHp72Vc5j8iohWG1j5VKXSJPC6pO6NOjrMdMTVoa69/3o9sLFxHCtzG8eZd8CC87fHqZVXQSjNgcM+4a1vJKx1Zt7WZzLCLCDj2v7SQTex4Oo0LWokeE3yYsuhfaT1vVHiL3dfbZM5Eonu3x/1Y73fG7xyOAtepBDGpv1cOf+mQrAC+KGSoPT+cYWFWb96J8ojfBIAXEhiUQ7uKtNcp//cgypC6H1eEu868eQObFR5jOC3OY0St/F73A6KXeJRq3rHGRATjcKNyA/+tEzoVt+sSbGr5lW8q9ZFlmyb351KLz6LtW6I1z3TScGOxvA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570AA3B8E2327C50884B71DC10C0MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 113d8b3b-9c60-4dba-df78-08d868efa3d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2020 05:29:32.7446 (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: ni3pXNnAzhtThd9lrkHG8WJWNnuXF/3mynEe+SIwF1agXIsgqR/pkth0xXhawK5wFtYU/DmdxOZiibjeHmdU4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2270 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 05:29:39 -0000 --_000_MW3PR11MB4570AA3B8E2327C50884B71DC10C0MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3lhbiwNCg0KVGhhbmtzIGZvciB5b3VyIHN1cHBvcnQgYW5kIGNvbW1lbnRzIG9uIHRoZSBk cmFmdC4NCg0KVGhlIHByb3Bvc2VkIGVuY29kaW5nIGZvciBMMiBCdW5kbGUgbWVtYmVycyBhbmQg dGhlaXIgYXR0cmlidXRlcyBpbiBPU1BGIGlzIGRpZmZlcmVudCB0aGFuIHRoZSBJU0lTIGVuY29k aW5ncyBpbiBSRkM4NjY4LiBJU0lTIGVuY29kaW5ncyBoYXZlIOKAnHRpZ2h0ZXLigJ0gTFNQIHNw YWNlIGNvbnNpZGVyYXRpb25zIHRoYXQgT1NQRi4gVGhlIGF1dGhvcnMgaGF2ZSBwcm9wb3NlZCBh IHNpbXBsZXIgZW5jb2Rpbmcgc2NoZW1lIGZvciBPU1BGIOKAkyBmZWVkYmFjay9pbnB1dHMgYXJl IHdlbGNvbWUuDQoNClRoZSBsaXN0IG9mIGF0dHJpYnV0ZXMgaW4gRmlndXJlIDIgYW5kIDMgYWxz byBpbmNsdWRlcyBMMiBCdW5kbGUgbWVtYmVyIEFkaiBTSUQuIFNpbmNlIHRoZSBlbmNvZGluZyBz Y2hlbWUgaXMgc2ltaWxhciB0byBMYXllciAzIGF0dHJpYnV0ZXMsIHdlIGNhbiByZS11c2UgdGhl IHNhbWUgc3ViLVRMVnMuDQoNClRoYW5rcywNCktldGFuDQoNCkZyb206IExzciA8bHNyLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBHeWFuIE1pc2hyYQ0KU2VudDogMDMgT2N0b2JlciAy MDIwIDA0OjA3DQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnPTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPg0KQ2M6IGxzckBpZXRmLm9yZzsgZHJhZnQta2V0YW50LWxzci1v c3BmLWwyYnVuZGxlcy5hbGxAaWV0Zi5vcmc7IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bw cy5vcmc+OyBsc3ItY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0xzcl0gV0cgYWRvcHRp b24gY2FsbCBmb3IgZHJhZnQta2V0YW50LWxzci1vc3BmLWwyYnVuZGxlcy0wMQ0KDQoNCkkgc3Vw cG9ydCBXRyBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpJIGFncmVlIHRoYXQgT1NQRiBuZWVk cyB0aGUgZnVuY3Rpb25hbGl0eSBlcXVpdmFsZW50IHRvIHRoYXQgZGVmaW5lZCBmb3IgSVMtSVMg aW4gUkZDIDg2NjguDQoNCkkgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBpbmNsdWRlIHNpbWlsYXIg dG8gUkZDIDg2Njggc2VjdGlvbiAzIHBhcmFsbGVsIGxheWVyIDMgYWRqYWNlbmNpZXMgMyBzaW1p bGFyIFN1YiBUTFZzIG1lbnRpb25lZCBmbGFnIGZvciBtdWx0aXBsZSBwYXJhbGxlbCBhZGphY2Vu Y2llcy4NCg0KQWxzbyBtYXliZSBzZWN0aW9uIDQgb2YgUkZDIDg2Njggd291bGQgYXBwbHkgYXMg d2VsbCB0byBvc3BmIGFkdmVydGlzZW1lbnQgb2YgTDIgYnVuZGxlIEFkaiBzaWQuDQoNClRoYW5r cw0KDQpHeWFuDQoNCk9uIEZyaSwgT2N0IDIsIDIwMjAgYXQgNjoxMSBQTSBMZXMgR2luc2Jlcmcg KGdpbnNiZXJnKSA8Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQw Y2lzY28uY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpJIHN1cHBvcnQgV0cgYWRvcHRpb24g b2YgdGhpcyBkcmFmdC4NCg0KT1NQRiBuZWVkcyBmdW5jdGlvbmFsaXR5IGVxdWl2YWxlbnQgdG8g dGhhdCBkZWZpbmVkIGZvciBJUy1JUyBpbiBSRkMgODY2OC4NCg0KDQoNCiAgIExlcw0KDQoNCg0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPiBGcm9tOiBMc3IgPGxzci1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBD aHJpc3RpYW4gSG9wcHMNCg0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMDIsIDIwMjAgNTowMyBB TQ0KDQo+IFRvOiBsc3JAaWV0Zi5vcmc8bWFpbHRvOmxzckBpZXRmLm9yZz4NCg0KPiBDYzogbHNy LWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bHNyLWNoYWlyc0BpZXRmLm9yZz47IENocmlzdGlhbiBI b3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc8bWFpbHRvOmNob3Bwc0BjaG9wcHMub3JnPj47IGRyYWZ0 LWtldGFudC0NCg0KPiBsc3Itb3NwZi1sMmJ1bmRsZXMuYWxsQGlldGYub3JnPG1haWx0bzpsc3It b3NwZi1sMmJ1bmRsZXMuYWxsQGlldGYub3JnPg0KDQo+IFN1YmplY3Q6IFtMc3JdIFdHIGFkb3B0 aW9uIGNhbGwgZm9yIGRyYWZ0LWtldGFudC1sc3Itb3NwZi1sMmJ1bmRsZXMtMDENCg0KPg0KDQo+ IFRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yIHRoZSBmb2xsb3dpbmcg ZHJhZnQ6DQoNCj4NCg0KPiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWtldGFudC1sc3Itb3NwZi1sMmJ1bmRsZXMvDQoNCj4NCg0KPiBQbGVhc2UgaW5kaWNhdGUgeW91 ciBzdXBwb3J0IG9yIG9iamVjdGlvbiBieSBPY3RvYmVyIDE2LCAyMDIwLg0KDQo+DQoNCj4gQXV0 aG9ycywgcGxlYXNlIHJlc3BvbmQgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyB3aGV0aGVyIHlvdSBh cmUgYXdhcmUgb2YgYW55DQoNCj4gSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Lg0KDQo+ DQoNCj4gVGhhbmtzLA0KDQo+IENocmlzIGFuZCBBY2VlLg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTHNyIG1haWxpbmcgbGlzdA0KDQpM c3JAaWV0Zi5vcmc8bWFpbHRvOkxzckBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sc3INCi0tDQoNCltodHRwOi8vc3M3LnZ6dy5jb20vaXMvaW1hZ2Uv VmVyaXpvbldpcmVsZXNzL3Z6LWxvZ28tZW1haWxdPGh0dHA6Ly93d3cudmVyaXpvbi5jb20vPg0K DQpHeWFuIE1pc2hyYQ0KDQpOZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QNCg0KTSAzMDEgNTAy LTEzNDcNCjEzMTAxIENvbHVtYmlhIFBpa2UNClNpbHZlciBTcHJpbmcsIE1EDQoNCg== --_000_MW3PR11MB4570AA3B8E2327C50884B71DC10C0MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2VvcmdpYTsN CglwYW5vc2UtMToyIDQgNSAyIDUgNCA1IDIgMyAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6SGVsdmV0aWNhTmV1ZTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUlOIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEd5YW4sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlRoYW5rcyBmb3IgeW91ciBzdXBwb3J0IGFuZCBjb21tZW50cyBvbiB0aGUgZHJhZnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlRoZSBwcm9wb3NlZCBlbmNvZGluZyBmb3IgTDIgQnVuZGxlIG1lbWJlcnMgYW5kIHRoZWly IGF0dHJpYnV0ZXMgaW4gT1NQRiBpcyBkaWZmZXJlbnQgdGhhbiB0aGUgSVNJUyBlbmNvZGluZ3Mg aW4gUkZDODY2OC4gSVNJUyBlbmNvZGluZ3MgaGF2ZSDigJx0aWdodGVy4oCdIExTUCBzcGFjZSBj b25zaWRlcmF0aW9ucyB0aGF0IE9TUEYuIFRoZSBhdXRob3JzDQogaGF2ZSBwcm9wb3NlZCBhIHNp bXBsZXIgZW5jb2Rpbmcgc2NoZW1lIGZvciBPU1BGIOKAkyBmZWVkYmFjay9pbnB1dHMgYXJlIHdl bGNvbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlRoZSBsaXN0IG9mIGF0dHJpYnV0ZXMgaW4gRmlndXJlIDIgYW5kIDMgYWxz byBpbmNsdWRlcyBMMiBCdW5kbGUgbWVtYmVyIEFkaiBTSUQuIFNpbmNlIHRoZSBlbmNvZGluZyBz Y2hlbWUgaXMgc2ltaWxhciB0byBMYXllciAzIGF0dHJpYnV0ZXMsIHdlIGNhbiByZS11c2UgdGhl IHNhbWUgc3ViLVRMVnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PktldGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4g THNyICZsdDtsc3ItYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+R3lh biBNaXNocmE8YnI+DQo8Yj5TZW50OjwvYj4gMDMgT2N0b2JlciAyMDIwIDA0OjA3PGJyPg0KPGI+ VG86PC9iPiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSAmbHQ7Z2luc2Jlcmc9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBsc3JAaWV0Zi5vcmc7IGRyYWZ0LWtl dGFudC1sc3Itb3NwZi1sMmJ1bmRsZXMuYWxsQGlldGYub3JnOyBDaHJpc3RpYW4gSG9wcHMgJmx0 O2Nob3Bwc0BjaG9wcHMub3JnJmd0OzsgbHNyLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW0xzcl0gV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQta2V0YW50LWxzci1v c3BmLWwyYnVuZGxlcy0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iYm9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBjbSI+SSBzdXBwb3J0IFdHIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2FOZXVlJnF1b3Q7LHNlcmlmIj48YnI+DQo8 YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImJvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzowY20iPkkgYWdyZWUgdGhhdCBPU1BGIG5lZWRzIHRoZSBmdW5jdGlvbmFsaXR5IGVxdWl2 YWxlbnQgdG8gdGhhdCBkZWZpbmVkIGZvciBJUy1JUyBpbiBSRkMgODY2OC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNt Ij5JIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgaW5jbHVkZSBzaW1pbGFyIHRvIFJGQyA4NjY4IHNl Y3Rpb24gMyBwYXJhbGxlbCBsYXllciAzIGFkamFjZW5jaWVzIDMgc2ltaWxhciBTdWIgVExWcyBt ZW50aW9uZWQgZmxhZyBmb3IgbXVsdGlwbGUgcGFyYWxsZWwgYWRqYWNlbmNpZXMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZSBibGFjayAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtiYWNrZ3JvdW5kLWNvbG9yOnJnYmEoMCwwLDAsMCki Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lIGJsYWNrIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNt O2JhY2tncm91bmQtY29sb3I6cmdiYSgwLDAsMCwwKSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRk aW5nOjBjbSI+QWxzbyBtYXliZSBzZWN0aW9uIDQgb2YgUkZDIDg2Njggd291bGQgYXBwbHkgYXMg d2VsbCB0byBvc3BmIGFkdmVydGlzZW1lbnQgb2YgTDIgYnVuZGxlIEFkaiBzaWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZSBibGFjayAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtiYWNrZ3JvdW5kLWNvbG9yOnJnYmEoMCwwLDAsMCki Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImJvcmRlcjpu b25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPkd5YW48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBPY3QgMiwg MjAyMCBhdCA2OjExIFBNIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpICZsdDtnaW5zYmVyZz08YSBo cmVmPSJtYWlsdG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciPjQwY2lzY28uY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkg c3VwcG9ydCBXRyBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NCk9TUEYgbmVlZHMg ZnVuY3Rpb25hbGl0eSBlcXVpdmFsZW50IHRvIHRoYXQgZGVmaW5lZCBmb3IgSVMtSVMgaW4gUkZD IDg2NjguPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0xlczxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQo8YnI+DQomZ3Q7IEZyb206IExzciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxzci1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bHNyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBP biBCZWhhbGYgT2YgQ2hyaXN0aWFuIEhvcHBzPGJyPg0KPGJyPg0KJmd0OyBTZW50OiBGcmlkYXks IE9jdG9iZXIgMDIsIDIwMjAgNTowMyBBTTxicj4NCjxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1h aWx0bzpsc3JAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sc3JAaWV0Zi5vcmc8L2E+PGJyPg0K PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOmxzci1jaGFpcnNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5sc3ItY2hhaXJzQGlldGYub3JnPC9hPjsgQ2hyaXN0aWFuIEhvcHBzICZsdDs8 YSBocmVmPSJtYWlsdG86Y2hvcHBzQGNob3Bwcy5vcmciIHRhcmdldD0iX2JsYW5rIj5jaG9wcHNA Y2hvcHBzLm9yZzwvYT4mZ3Q7OyBkcmFmdC1rZXRhbnQtPGJyPg0KPGJyPg0KJmd0OyA8YSBocmVm PSJtYWlsdG86bHNyLW9zcGYtbDJidW5kbGVzLmFsbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pmxzci1vc3BmLWwyYnVuZGxlcy5hbGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGJyPg0KJmd0OyBTdWJq ZWN0OiBbTHNyXSBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1rZXRhbnQtbHNyLW9zcGYtbDJi dW5kbGVzLTAxPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQomZ3Q7IFRoaXMgYmVnaW5zIGEg MiB3ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yIHRoZSBmb2xsb3dpbmcgZHJhZnQ6PGJyPg0KPGJy Pg0KJmd0OyA8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtldGFudC1sc3Itb3NwZi1sMmJ1bmRsZXMvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V0 YW50LWxzci1vc3BmLWwyYnVuZGxlcy88L2E+PGJyPg0KPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQom Z3Q7IFBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9uIGJ5IE9jdG9iZXIg MTYsIDIwMjAuPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQomZ3Q7IEF1dGhvcnMsIHBsZWFz ZSByZXNwb25kIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9m IGFueTxicj4NCjxicj4NCiZndDsgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ljxicj4N Cjxicj4NCiZndDsgPGJyPg0KPGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KPGJyPg0KJmd0OyBDaHJp cyBhbmQgQWNlZS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4NCkxzciBtYWlsaW5nIGxpc3Q8YnI+ DQo8YnI+DQo8YSBocmVmPSJtYWlsdG86THNyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+THNy QGlldGYub3JnPC9hPjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHNyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sc3I8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cD48YSBocmVmPSJodHRwOi8vd3d3LnZlcml6b24uY29tLyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjojMTE1NUNDO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJv cmRlcj0iMCIgd2lkdGg9IjgxIiBoZWlnaHQ9IjE4IiBzdHlsZT0id2lkdGg6Ljg0MTZpbjtoZWln aHQ6LjE5MTZpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJodHRwOi8vc3M3LnZ6dy5jb20vaXMv aW1hZ2UvVmVyaXpvbldpcmVsZXNzL3Z6LWxvZ28tZW1haWwiPjwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImNvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGNtO21zby1saW5lLWhlaWdodC1hbHQ6OS43NXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+R3lhbiBNaXNo cmE8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBjbTttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPk5ldHdvcmsg U29sdXRpb25zIEFyY2hpdGVjdCZuYnNwOzwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOiMy MjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21zby1s aW5lLWhlaWdodC1hbHQ6OS43NXB0Ij48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+TSAzMDEgNTAyLTEzNDc8YnI+DQoxMzEw MSBDb2x1bWJpYSBQaWtlJm5ic3A7PGJyPg0KPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlNpbHZlciBTcHJpbmcsIE1EPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MW3PR11MB4570AA3B8E2327C50884B71DC10C0MW3PR11MB4570namp_-- From nobody Mon Oct 5 04:55:14 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8F33A086E; Mon, 5 Oct 2020 04:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.587 X-Spam-Level: X-Spam-Status: No, score=-9.587 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=nBSTDL2i; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zNBcW0Cq 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 3Siooz4y32DO; Mon, 5 Oct 2020 04:55:09 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA7E3A0869; Mon, 5 Oct 2020 04:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20171; q=dns/txt; s=iport; t=1601898909; x=1603108509; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MBxHuQrynsV8OCfibuEiVvZEjFlWeUsCCl4ajBmdNGY=; b=nBSTDL2ifInONNyS01+u4apCsUuzaTnNZeRZXVVmE6kz4saHs2TajGMA KPbjqyCRjkLl8B+AC0IfgXVdRHMf7yELCWBZd3mXlETRT7ADz5YgBWL66 sK6FZnRLETF1NtBxuPj7nN01gKuhEmJY9GMe6xTs2iba2FrL1hCfsr+SW s=; IronPort-PHdr: =?us-ascii?q?9a23=3AHP3TBRfEHCXxOg2UwL6bo7calGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfQ6ulPjKzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutbFzJqXr05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaQAC5CHtf/5BdJa1dAxYHAQE8AQU?= =?us-ascii?q?FAQIBCQGBWggBAwGBIBsCElEHcFkvLAqEM4NGA41JJooRiXuEb4FCgREDVQs?= =?us-ascii?q?BAQENAQEYAQoKAgQBAYRKAheCIQIlOQUNAgMBAQsBAQUBAQECAQYEbYVcDIV?= =?us-ascii?q?yAQEBAQIBAQEQCwYKEwEBLAsBBAcEAgEIBwoDAQEBCR8DAgICHwUBCxQJCAI?= =?us-ascii?q?EAQ0EARsHgwQBgX5NAw4gAQ6cJgKBOYhhdoEygwEBAQWBR0GDFg0LghAJgTY?= =?us-ascii?q?CAQGCcINpgQaFUBuCAIEQKAwQgk0+ghpCAQEBAQEBgUExCQEFBwkICYJQM4I?= =?us-ascii?q?tkz2HApxAUgqCZ4h+jFiFCwMfgw6KApQPkTJcDHqKboJqkj4CBAIEBQIOAQE?= =?us-ascii?q?FgWwigVdwFTsqAYI+CUcXAg2OKxeDToUUhUJ0AjUCBgEJAQEDCXyMOwGBEAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.77,338,1596499200"; d="scan'208,217";a="554566094" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Oct 2020 11:55:08 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 095Bt1ko014000 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2020 11:55:07 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 06:55:04 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 06:55:03 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 5 Oct 2020 06:55:03 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h8E+/LWHAUjkZriN/Pjv9CWA68hPHsY5LBQPoO8dHpca9iyccYmJEwDG+op0cJJ5i2FADAkeeaJbsZgnSc0A/t1cZvUmF1J97kdDmPbu/+/wZtz7G60U4x+PUCv3/Q3XmuqCrGLTXiG2Ty+k4KdoxLeuAZTWvzRNyyLx5YJ0bvlCyunaPzHqjO0mhw2SNkRS8pBYsMxubJqz+O7pDdXx58aDU1SFBYdX3KQpH07Zj+qSrUEm8ymb7OkzIMWShdKfuU37pb6Y9sH2R3SD8ISNu27zHilUQZBIw5JuhRPrWrp2WUl8Yv0OQZxUjGHSyHCGQrkYSHvt7IElJxZ4c0AG0g== 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=MBxHuQrynsV8OCfibuEiVvZEjFlWeUsCCl4ajBmdNGY=; b=HldSulLkNXTbv9YJKYWBrFoVW0TYNo1jbpoqKpgXiaQTHKI5pdN2smR68XsN6LWBRS0RU3tf1Pw8riiUQsxZEzrXStr3zUxiqLzQy5VHDLq6vgmv8HA9STTgqczESxsFb0OnXXXbWQIcfswKyB7TqjioJTDTahSowzgRQ/PMIkrOsbKfDMzKItNtfeOSEj594H33odh3jDap23T/O5HzKsFH/ahTTuEclz/B0jpxuC3/HJhDzQeVbsSuOx+TiyCyL4Ykm/XWH7/702mXD+xgjbHavCdK+KAUwl4SHoLPylnC8lyxz0FqbT45TY/EmljYT39HRDhdwzi0/Q+OspkJeQ== 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=MBxHuQrynsV8OCfibuEiVvZEjFlWeUsCCl4ajBmdNGY=; b=zNBcW0CqPOfRSzYtM57SciA0JTbeahu4/+0pNzH42OKOaFltdjvVkvczt8rtAXYjs8sqivead3fn5ymwfeFEz6ZNSk5VT81TwBDGIG588/kRr4TMTtzHGY385pHg6Q8gacdMrdOxM40jEb69lVWvMmYeU9azUyLNsRGySelnZ1w= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3848.namprd11.prod.outlook.com (2603:10b6:a03:fd::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.42; Mon, 5 Oct 2020 11:55:02 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3433.044; Mon, 5 Oct 2020 11:55:02 +0000 From: "Acee Lindem (acee)" To: "Ketan Talaulikar (ketant)" , Gyan Mishra , "Les Ginsberg (ginsberg)" CC: "lsr@ietf.org" , "draft-ketant-lsr-ospf-l2bundles.all@ietf.org" , Christian Hopps , "lsr-chairs@ietf.org" Thread-Topic: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 Thread-Index: AQHWmLROhn60mItAckuZlw3AF7BykqmE4H+AgAAHJ4CAA5fzAIAAKKQA Date: Mon, 5 Oct 2020 11:55:02 +0000 Message-ID: <5700EA34-8E0C-4404-AECE-E3E599F21AD2@cisco.com> References: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52282cc1-6e25-45f8-d72e-08d869257e12 x-ms-traffictypediagnostic: BYAPR11MB3848: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5woQlJ5PnJg+qayZ6Pu91dDaqZHs4+akLRPgV6tYkglAdcrsyhQr8AHjCe+0hT1jWI5h0cB7YXyZii3ww5X32/KoQgkqzqKMD4uQVSTRaI4C2uEbNtJhg2JVeK1eJ6VPFaJqeJ22UC7Wy+YetZ3bjtcoas3SP2apJiLXum9s/UcnXra+tK8x0ZfriLE/c5bA6lbV3rE7wJljsnWpXIugYSRArsVHYa0AjwupJWU5XDWK+/diIpletOVPgv6Y2lIOaOB78v9+McZhJ0rTPLKlShAV1HcWI0FyL10pziIP2xgUF2uLTqlNM46K5nvY0/y7XLmg3PeU+vXXCSPL8fzGmxnKfVXscO/ZjfUf3qZkDt4XEj3+VEaN3nWNCbHrJ93pNPb+TwuEEWRJQavNrwiHRA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(396003)(366004)(376002)(136003)(6486002)(2616005)(316002)(8676002)(64756008)(76116006)(6506007)(4326008)(66446008)(66476007)(66556008)(66946007)(9326002)(71200400001)(53546011)(5660300002)(86362001)(26005)(478600001)(966005)(83380400001)(186003)(166002)(54906003)(83080400001)(110136005)(8936002)(6512007)(2906002)(33656002)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6gVX/9eN24oavXlCY1j3bbPYopWWVdZywN+XnGZfxabIcTBjL/MDmNA0sulifetJejTHhQlHx9BTwq/QSCGIid0gbVI0yMoj4otqHOMwbeKVhgJghluwpEpow2nxacU1AVw9RV5DXLvpn4921ChPxugxT5yPxWAFTdyzz3TR35HzawWwCiNBs2ew2Ne3Qw8azhtwqXPr+KpDrzIeMxjSfE6yGnaZQyk8/alre12/k7VSbb3Iq0ubs21dzJC3ieY5rnOrLgmu6MPw27cwkc72ZrfejrygpYYIL0yphAMBK7EFyEkJTJOdZWzbdNOnryF/RVIUl6W6127oAz3zwhUQiO2cLAIJQlA63E64tFoNGTsBUVfDvDSu4g9SUW/dphk03d6mcDts5bbqDKA02jdVDQackba7xHyZ3KBlqA180I119yVTT3ezdKZN8RbPdK9nRo6BbRKgi9tTk0OVsa03IjyY1wnPKA+z6HSkNGZqNJQ46MFdJzimqzkwwjq8FU5WBd4YikfMG/fKU5Kugi/evx2weFeeaqckIwDSuhOavu25ThmJu6mHIlAD/JmaXMblSresnWyhx1c8vCQG61Nr3UQN6TrVSC+ZLsBXfpJCdaVK3iuxbyTmK+LhCRSG5s4+SzlbdGyZW4JsiKbPZQf1sw== Content-Type: multipart/alternative; boundary="_000_5700EA348E0C4404AECEE3E599F21AD2ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52282cc1-6e25-45f8-d72e-08d869257e12 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2020 11:55:02.1426 (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: UUrnwUW/uCiXfOwQMCwPqhuKtpG9HqG+cjj5kePjuL/HireQQq6bo902M9Sd6o4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3848 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 11:55:12 -0000 --_000_5700EA348E0C4404AECEE3E599F21AD2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2V0YW4sDQoNCkZyb206ICJLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIiA8a2V0YW50QGNp c2NvLmNvbT4NCkRhdGU6IE1vbmRheSwgT2N0b2JlciA1LCAyMDIwIGF0IDE6MjkgQU0NClRvOiBH eWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPiwgIkxlcyBHaW5zYmVyZyAoZ2luc2Jl cmcpIiA8Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogImxzckBpZXRm Lm9yZyIgPGxzckBpZXRmLm9yZz4sICJkcmFmdC1rZXRhbnQtbHNyLW9zcGYtbDJidW5kbGVzLmFs bEBpZXRmLm9yZyIgPGRyYWZ0LWtldGFudC1sc3Itb3NwZi1sMmJ1bmRsZXMuYWxsQGlldGYub3Jn PiwgQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz4sICJsc3ItY2hhaXJzQGlldGYu b3JnIiA8bHNyLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbTHNyXSBXRyBhZG9wdGlv biBjYWxsIGZvciBkcmFmdC1rZXRhbnQtbHNyLW9zcGYtbDJidW5kbGVzLTAxDQpSZXNlbnQtRnJv bTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc+DQpSZXNlbnQtVG86IENocmlzdGlhbiBIb3BwcyA8 Y2hvcHBzQGNob3Bwcy5vcmc+LCBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb20+LCBZaW5nemhl biBRdSA8eWluZ3poZW4uaWV0ZkBnbWFpbC5jb20+DQpSZXNlbnQtRGF0ZTogTW9uZGF5LCBPY3Rv YmVyIDUsIDIwMjAgYXQgMToyOSBBTQ0KDQpIaSBHeWFuLA0KDQpUaGFua3MgZm9yIHlvdXIgc3Vw cG9ydCBhbmQgY29tbWVudHMgb24gdGhlIGRyYWZ0Lg0KDQpUaGUgcHJvcG9zZWQgZW5jb2Rpbmcg Zm9yIEwyIEJ1bmRsZSBtZW1iZXJzIGFuZCB0aGVpciBhdHRyaWJ1dGVzIGluIE9TUEYgaXMgZGlm ZmVyZW50IHRoYW4gdGhlIElTSVMgZW5jb2RpbmdzIGluIFJGQzg2NjguIElTSVMgZW5jb2Rpbmdz IGhhdmUg4oCcdGlnaHRlcuKAnSBMU1Agc3BhY2UgY29uc2lkZXJhdGlvbnMgdGhhdCBPU1BGLiBU aGUgYXV0aG9ycyBoYXZlIHByb3Bvc2VkIGEgc2ltcGxlciBlbmNvZGluZyBzY2hlbWUgZm9yIE9T UEYg4oCTIGZlZWRiYWNrL2lucHV0cyBhcmUgd2VsY29tZS4NCg0KWW91IGhhdmUgdGhlIGJ1bmRs ZSBtZW1iZXIgc3ViLVRMVnMgaW4gdGhlIHJpZ2h0IHBsYWNlIGZvciBPU1BGdjIgYW5kIE9TUEZ2 My4NCg0KVGhhbmtzLA0KQWNlZQ0KDQpUaGUgbGlzdCBvZiBhdHRyaWJ1dGVzIGluIEZpZ3VyZSAy IGFuZCAzIGFsc28gaW5jbHVkZXMgTDIgQnVuZGxlIG1lbWJlciBBZGogU0lELiBTaW5jZSB0aGUg ZW5jb2Rpbmcgc2NoZW1lIGlzIHNpbWlsYXIgdG8gTGF5ZXIgMyBhdHRyaWJ1dGVzLCB3ZSBjYW4g cmUtdXNlIHRoZSBzYW1lIHN1Yi1UTFZzLg0KDQpUaGFua3MsDQpLZXRhbg0KDQpGcm9tOiBMc3Ig PGxzci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgR3lhbiBNaXNocmENClNlbnQ6IDAz IE9jdG9iZXIgMjAyMCAwNDowNw0KVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIDxnaW5zYmVy Zz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBsc3JAaWV0Zi5vcmc7IGRyYWZ0LWtl dGFudC1sc3Itb3NwZi1sMmJ1bmRsZXMuYWxsQGlldGYub3JnOyBDaHJpc3RpYW4gSG9wcHMgPGNo b3Bwc0BjaG9wcHMub3JnPjsgbHNyLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMc3Jd IFdHIGFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWtldGFudC1sc3Itb3NwZi1sMmJ1bmRsZXMtMDEN Cg0KDQpJIHN1cHBvcnQgV0cgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4NCg0KSSBhZ3JlZSB0aGF0 IE9TUEYgbmVlZHMgdGhlIGZ1bmN0aW9uYWxpdHkgZXF1aXZhbGVudCB0byB0aGF0IGRlZmluZWQg Zm9yIElTLUlTIGluIFJGQyA4NjY4Lg0KDQpJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgaW5jbHVk ZSBzaW1pbGFyIHRvIFJGQyA4NjY4IHNlY3Rpb24gMyBwYXJhbGxlbCBsYXllciAzIGFkamFjZW5j aWVzIDMgc2ltaWxhciBTdWIgVExWcyBtZW50aW9uZWQgZmxhZyBmb3IgbXVsdGlwbGUgcGFyYWxs ZWwgYWRqYWNlbmNpZXMuDQoNCkFsc28gbWF5YmUgc2VjdGlvbiA0IG9mIFJGQyA4NjY4IHdvdWxk IGFwcGx5IGFzIHdlbGwgdG8gb3NwZiBhZHZlcnRpc2VtZW50IG9mIEwyIGJ1bmRsZSBBZGogc2lk Lg0KDQpUaGFua3MNCg0KR3lhbg0KDQpPbiBGcmksIE9jdCAyLCAyMDIwIGF0IDY6MTEgUE0gTGVz IEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSSBzdXBwb3J0IFdH IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQoNCk9TUEYgbmVlZHMgZnVuY3Rpb25hbGl0eSBlcXVp dmFsZW50IHRvIHRoYXQgZGVmaW5lZCBmb3IgSVMtSVMgaW4gUkZDIDg2NjguDQoNCg0KDQogICBM ZXMNCg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogTHNy IDxsc3ItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBC ZWhhbGYgT2YgQ2hyaXN0aWFuIEhvcHBzDQoNCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDAyLCAy MDIwIDU6MDMgQU0NCg0KPiBUbzogbHNyQGlldGYub3JnPG1haWx0bzpsc3JAaWV0Zi5vcmc+DQoN Cj4gQ2M6IGxzci1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmxzci1jaGFpcnNAaWV0Zi5vcmc+OyBD aHJpc3RpYW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPG1haWx0bzpjaG9wcHNAY2hvcHBzLm9y Zz4+OyBkcmFmdC1rZXRhbnQtDQoNCj4gbHNyLW9zcGYtbDJidW5kbGVzLmFsbEBpZXRmLm9yZzxt YWlsdG86bHNyLW9zcGYtbDJidW5kbGVzLmFsbEBpZXRmLm9yZz4NCg0KPiBTdWJqZWN0OiBbTHNy XSBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1rZXRhbnQtbHNyLW9zcGYtbDJidW5kbGVzLTAx DQoNCj4NCg0KPiBUaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciB0aGUg Zm9sbG93aW5nIGRyYWZ0Og0KDQo+DQoNCj4gICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1rZXRhbnQtbHNyLW9zcGYtbDJidW5kbGVzLw0KDQo+DQoNCj4gUGxlYXNlIGlu ZGljYXRlIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb24gYnkgT2N0b2JlciAxNiwgMjAyMC4NCg0K Pg0KDQo+IEF1dGhvcnMsIHBsZWFzZSByZXNwb25kIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgd2hl dGhlciB5b3UgYXJlIGF3YXJlIG9mIGFueQ0KDQo+IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBk cmFmdC4NCg0KPg0KDQo+IFRoYW5rcywNCg0KPiBDaHJpcyBhbmQgQWNlZS4NCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkxzciBtYWlsaW5n IGxpc3QNCg0KTHNyQGlldGYub3JnPG1haWx0bzpMc3JAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQotLQ0KDQpbSW1hZ2UgcmVtb3ZlZCBieSBz ZW5kZXIuXTxodHRwOi8vd3d3LnZlcml6b24uY29tLz4NCg0KR3lhbiBNaXNocmENCg0KTmV0d29y ayBTb2x1dGlvbnMgQXJjaGl0ZWN0DQoNCk0gMzAxIDUwMi0xMzQ3DQoxMzEwMSBDb2x1bWJpYSBQ aWtlDQpTaWx2ZXIgU3ByaW5nLCBNRA0KDQo= --_000_5700EA348E0C4404AECEE3E599F21AD2ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2VvcmdpYTsN CglwYW5vc2UtMToyIDQgNSAyIDUgNCA1IDIgMyAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6SGVsdmV0aWNhTmV1ZTsNCglwYW5vc2UtMToyIDAgNSAzIDAgMCAwIDIgMCA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLZXRhbiwgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPiZxdW90O0tldGFuIFRhbGF1bGlrYXIgKGtldGFudCkmcXVvdDsgJmx0O2tldGFudEBjaXNj by5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgT2N0b2JlciA1LCAyMDIwIGF0IDE6 MjkgQU08YnI+DQo8Yj5UbzogPC9iPkd5YW4gTWlzaHJhICZsdDtoYXlhYnVzYWdzbUBnbWFpbC5j b20mZ3Q7LCAmcXVvdDtMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSZxdW90OyAmbHQ7Z2luc2Jlcmc9 NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtsc3JA aWV0Zi5vcmcmcXVvdDsgJmx0O2xzckBpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0LWtldGFudC1s c3Itb3NwZi1sMmJ1bmRsZXMuYWxsQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1rZXRhbnQtbHNy LW9zcGYtbDJidW5kbGVzLmFsbEBpZXRmLm9yZyZndDssIENocmlzdGlhbiBIb3BwcyAmbHQ7Y2hv cHBzQGNob3Bwcy5vcmcmZ3Q7LCAmcXVvdDtsc3ItY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDts c3ItY2hhaXJzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogW0xzcl0gV0cg YWRvcHRpb24gY2FsbCBmb3IgZHJhZnQta2V0YW50LWxzci1vc3BmLWwyYnVuZGxlcy0wMTxicj4N CjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+UmVzZW50LVRvOiA8L2I+Q2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9yZyZn dDssIEFjZWUgTGluZGVtICZsdDthY2VlQGNpc2NvLmNvbSZndDssIFlpbmd6aGVuIFF1ICZsdDt5 aW5nemhlbi5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5SZXNlbnQtRGF0ZTogPC9iPk1vbmRh eSwgT2N0b2JlciA1LCAyMDIwIGF0IDE6MjkgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5IaSBHeWFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYW5rcyBmb3Ig eW91ciBzdXBwb3J0IGFuZCBjb21tZW50cyBvbiB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ VGhlIHByb3Bvc2VkIGVuY29kaW5nIGZvciBMMiBCdW5kbGUgbWVtYmVycyBhbmQgdGhlaXIgYXR0 cmlidXRlcyBpbiBPU1BGIGlzIGRpZmZlcmVudCB0aGFuIHRoZSBJU0lTIGVuY29kaW5ncyBpbiBS RkM4NjY4LiBJU0lTIGVuY29kaW5ncyBoYXZlIOKAnHRpZ2h0ZXLigJ0gTFNQIHNwYWNlIGNvbnNp ZGVyYXRpb25zIHRoYXQgT1NQRi4gVGhlIGF1dGhvcnMgaGF2ZSBwcm9wb3NlZA0KIGEgc2ltcGxl ciBlbmNvZGluZyBzY2hlbWUgZm9yIE9TUEYg4oCTIGZlZWRiYWNrL2lucHV0cyBhcmUgd2VsY29t ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGhhdmUgdGhlIGJ1bmRsZSBtZW1iZXIgc3Vi LVRMVnMgaW4gdGhlIHJpZ2h0IHBsYWNlIGZvciBPU1BGdjIgYW5kIE9TUEZ2My4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPGJyPg0KQWNlZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBs aXN0IG9mIGF0dHJpYnV0ZXMgaW4gRmlndXJlIDIgYW5kIDMgYWxzbyBpbmNsdWRlcyBMMiBCdW5k bGUgbWVtYmVyIEFkaiBTSUQuIFNpbmNlIHRoZSBlbmNvZGluZyBzY2hlbWUgaXMgc2ltaWxhciB0 byBMYXllciAzIGF0dHJpYnV0ZXMsIHdlIGNhbiByZS11c2UgdGhlIHNhbWUgc3ViLVRMVnMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPktldGFuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+RnJvbTo8L2I+IExzciAmbHQ7bHNyLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkd5YW4gTWlzaHJhPGJyPg0KPGI+U2VudDo8 L2I+IDAzIE9jdG9iZXIgMjAyMCAwNDowNzxicj4NCjxiPlRvOjwvYj4gTGVzIEdpbnNiZXJnIChn aW5zYmVyZykgJmx0O2dpbnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4N CjxiPkNjOjwvYj4gbHNyQGlldGYub3JnOyBkcmFmdC1rZXRhbnQtbHNyLW9zcGYtbDJidW5kbGVz LmFsbEBpZXRmLm9yZzsgQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9yZyZndDs7 IGxzci1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtMc3JdIFdHIGFk b3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWtldGFudC1sc3Itb3NwZi1sMmJ1bmRsZXMtMDE8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iYm9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiI+SSBzdXBw b3J0IFdHIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpIZWx2ZXRpY2FOZXVlIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImJvcmRl cjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkkgYWdyZWUgdGhhdCBPU1BGIG5l ZWRzIHRoZSBmdW5jdGlvbmFsaXR5IGVxdWl2YWxlbnQgdG8gdGhhdCBkZWZpbmVkIGZvciBJUy1J UyBpbiBSRkMgODY2OC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO2JvcmRlcjpub25lIHdpbmRvd3Rl eHQgMS4wcHQ7cGFkZGluZzowaW4iPkkgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBpbmNsdWRlIHNp bWlsYXIgdG8gUkZDIDg2Njggc2VjdGlvbiAzIHBhcmFsbGVsIGxheWVyIDMgYWRqYWNlbmNpZXMg MyBzaW1pbGFyIFN1YiBUTFZzIG1lbnRpb25lZCBmbGFnIGZvciBtdWx0aXBsZSBwYXJhbGxlbA0K IGFkamFjZW5jaWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4 dCAxLjBwdDtwYWRkaW5nOjBpbiI+QWxzbyBtYXliZSBzZWN0aW9uIDQgb2YgUkZDIDg2Njggd291 bGQgYXBwbHkgYXMgd2VsbCB0byBvc3BmIGFkdmVydGlzZW1lbnQgb2YgTDIgYnVuZGxlIEFkaiBz aWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PlRoYW5rcyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGlu Ij5HeWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+T24gRnJpLCBPY3QgMiwgMjAyMCBhdCA2OjExIFBNIExlcyBHaW5zYmVyZyAoZ2luc2Jlcmcp ICZsdDtnaW5zYmVyZz08YSBocmVmPSJtYWlsdG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmci PjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCkkg c3VwcG9ydCBXRyBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NCk9TUEYgbmVlZHMg ZnVuY3Rpb25hbGl0eSBlcXVpdmFsZW50IHRvIHRoYXQgZGVmaW5lZCBmb3IgSVMtSVMgaW4gUkZD IDg2NjguPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0xlczxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQo8YnI+DQomZ3Q7IEZyb206IExzciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxzci1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bHNyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBP biBCZWhhbGYgT2YgQ2hyaXN0aWFuIEhvcHBzPGJyPg0KPGJyPg0KJmd0OyBTZW50OiBGcmlkYXks IE9jdG9iZXIgMDIsIDIwMjAgNTowMyBBTTxicj4NCjxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1h aWx0bzpsc3JAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sc3JAaWV0Zi5vcmc8L2E+PGJyPg0K PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOmxzci1jaGFpcnNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5sc3ItY2hhaXJzQGlldGYub3JnPC9hPjsgQ2hyaXN0aWFuIEhvcHBzICZsdDs8 YSBocmVmPSJtYWlsdG86Y2hvcHBzQGNob3Bwcy5vcmciIHRhcmdldD0iX2JsYW5rIj5jaG9wcHNA Y2hvcHBzLm9yZzwvYT4mZ3Q7OyBkcmFmdC1rZXRhbnQtPGJyPg0KPGJyPg0KJmd0OyA8YSBocmVm PSJtYWlsdG86bHNyLW9zcGYtbDJidW5kbGVzLmFsbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pmxzci1vc3BmLWwyYnVuZGxlcy5hbGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGJyPg0KJmd0OyBTdWJq ZWN0OiBbTHNyXSBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1rZXRhbnQtbHNyLW9zcGYtbDJi dW5kbGVzLTAxPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQomZ3Q7IFRoaXMgYmVnaW5zIGEg MiB3ZWVrIFdHIGFkb3B0aW9uIGNhbGwgZm9yIHRoZSBmb2xsb3dpbmcgZHJhZnQ6PGJyPg0KPGJy Pg0KJmd0OyA8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtldGFudC1sc3Itb3NwZi1sMmJ1bmRsZXMvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta2V0 YW50LWxzci1vc3BmLWwyYnVuZGxlcy88L2E+PGJyPg0KPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQom Z3Q7IFBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9uIGJ5IE9jdG9iZXIg MTYsIDIwMjAuPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQomZ3Q7IEF1dGhvcnMsIHBsZWFz ZSByZXNwb25kIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9m IGFueTxicj4NCjxicj4NCiZndDsgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ljxicj4N Cjxicj4NCiZndDsgPGJyPg0KPGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KPGJyPg0KJmd0OyBDaHJp cyBhbmQgQWNlZS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4NCkxzciBtYWlsaW5nIGxpc3Q8YnI+ DQo8YnI+DQo8YSBocmVmPSJtYWlsdG86THNyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+THNy QGlldGYub3JnPC9hPjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHNyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sc3I8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxhIGhyZWY9Imh0dHA6Ly93d3cudmVyaXpvbi5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxzcGFuIHN0eWxl PSJjb2xvcjojMTE1NUNDO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGlu Ij48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjgxIiBoZWlnaHQ9IjE4IiBzdHlsZT0id2lkdGg6Ljg0 MzdpbjtoZWlnaHQ6LjE4NzVpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6fldSRDAwMDIu anBnIiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiI+PC9zcGFuPjwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bXNvLWxpbmUtaGVpZ2h0 LWFsdDo5Ljc1cHQiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkd5YW4gTWlzaHJhPC9zcGFuPjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttc28tbGluZS1oZWlnaHQtYWx0 OjkuNzVwdCI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90 OyxzZXJpZjtjb2xvcjpibGFjayI+TmV0d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0Jm5ic3A7PC9z cGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttc28t bGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+TSAzMDEgNTAyLTEzNDc8YnI+DQox MzEwMSBDb2x1bWJpYSBQaWtlJm5ic3A7PGJyPg0KPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlNpbHZlciBTcHJpbmcsIE1EPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_5700EA348E0C4404AECEE3E599F21AD2ciscocom_-- From nobody Tue Oct 6 01:51:31 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB953A12E7; Tue, 6 Oct 2020 01:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvUHldRT8bOU; Tue, 6 Oct 2020 01:51:29 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543653A12E6; Tue, 6 Oct 2020 01:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=602; q=dns/txt; s=iport; t=1601974288; x=1603183888; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5LT0V3IGIAqqAE/RvOolEDkhsluQ4Wr0Toue15foZwg=; b=l8z1VP0z9rGgjyC6SS8IaiUoGOZ2LBQXl1MYGVIIRE7b85qGyRz/b7sN cahF4hY/Mdw2WA8GZt8r94o8tnCfgbwCnHoUksdPt/Q9YiOpTL489i244 Kx27xl60uC6zvDkJhRTVgYjvaIUIrwMD1v2ID69ByHzuloJI0u/s+IMId 4=; X-IPAS-Result: =?us-ascii?q?A0BDBACbL3xf/xbLJq1gHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U8CgxhVASAShGmJAogJLpwmCwEBAQ8jDAQBAYRKAoIJJjkFDQIDAQEBAwIDA?= =?us-ascii?q?QEBAQUBAQECAQYEbYVcDIVzAQUdBhVBEAsYAgImAgJXBwwIAQGDIgGCfA+nK?= =?us-ascii?q?XaBMoRPQUSDQ4E8BoEOKokfhC2BQT+BOIJpPoJcAgMBhHKCYASbfJtTgnGDF?= =?us-ascii?q?IVrkVkFBwMfgnwSigOFE459kg8MeopulVGBbCKBVzMaCBsVO4JqTxkNlySFR?= =?us-ascii?q?D8DZwIGCgEBAwmOSAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,342,1596499200"; d="scan'208";a="27704850" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Oct 2020 08:51:00 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 0968p0tF018970; Tue, 6 Oct 2020 08:51:00 GMT To: chopps@chopps.org, lsr@ietf.org Cc: lsr-chairs@ietf.org, draft-ketant-lsr-ospf-l2bundles.all@ietf.org References: From: Peter Psenak Message-ID: <793e7a41-07c4-71f3-aea6-d2f7526842ad@cisco.com> Date: Tue, 6 Oct 2020 10:50:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 08:51:30 -0000 Hi Chris, I support the adoption of this document by the WG and as a co-author. I am not aware of any IPR associated with it. thanks, Peter On 02/10/2020 14:03, Christian Hoppsprotocol= application/pgp-signature wrote: > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ > > Please indicate your support or objection by October 16, 2020. > > Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft. > > Thanks, > Chris and Acee. > From nobody Tue Oct 6 10:26:27 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FFE3A0E59; Tue, 6 Oct 2020 10:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 7xFHHPTouVMH; Tue, 6 Oct 2020 10:26:22 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 AF43D3A0E0F; Tue, 6 Oct 2020 10:26:22 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id x185so1933136vsb.1; Tue, 06 Oct 2020 10:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1Xbqhlyim6Jokt9Bx0EPzo4/FEQZgTDzyDzSMk5XipQ=; b=sc9842neHGs0AAXOgOTu0fh/6NmIvx4k8BRYxMYWXjGngUIhicefDSWUHNv3Or8zyc +jZCDfxyoAsy14k3rpu2xsC+wSzNRg/WLNynQKJt3PVhzX6Ize4SC/uUSHduTkoGvDAy dWMhbGdIz4k5QS/8sGef4rulBvLoBOo4Z1HM+jlwVkBq7JKcWmV7lgw8Udshve1lxJ0y SgMDafjxr//3MlicSQaichNUJOOzBkh9N+EF42Yz2oD+O1Yeo2s+NRt1brAcrGMbQC0H m9D4NkRynkkrVRKUfjq3XN3AOgc9NJGb4JYEqxnFpNEuZDqlT/R3Onssfkm6SfxNLU4n Sygw== 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=1Xbqhlyim6Jokt9Bx0EPzo4/FEQZgTDzyDzSMk5XipQ=; b=oUHR7sKCcmvw0D3BrZEafo2s95mBhwSuwqYKV2LTKj+OSxr2sAtopcB45mMAiRwJhL 2/tyN4odTFXVGoVCxRsqkkkxkW+i/QIpm5RLZhZSbwXwphghVN5YehI2GsVG4p0bWbdV +17/oc48CsqzzLhuwH5Rm86Y2NSTUcDEXpAmiRoXFrUBcM0yT0Ezp7FDYzQKf5wVxOTv d8bo5CIJIGoKeIlUmFu8rcjf2t/2N1KBXlO/jBjdPWGc13HbEukbTuun6RLNOQ+qUWc/ Z+nnNHngdiCl5T3G6IJ7zMo1NpIi03g3OR41QyNQRCu8QLhyuKJs3n5ST2Vx1L1R6Kqc XOoA== X-Gm-Message-State: AOAM532mPUA2XKYb9VHPyqbMZ6PSG12HJcPSjM53y2m7m0w5+GPUnOBG LAobCaE1/duZVyQwAEzA/zq4bK3S5HW/Mv5qQzc= X-Google-Smtp-Source: ABdhPJxj+J+ZZUUCCpK40f9njSx1NzQuH4vt/DI1THu2MKgg7PLnwTSGBAUWu1jRHQRc20P75aUZbtQY35hMDVNSSjA= X-Received: by 2002:a67:f3cb:: with SMTP id j11mr4058219vsn.60.1602005181656; Tue, 06 Oct 2020 10:26:21 -0700 (PDT) MIME-Version: 1.0 References: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> In-Reply-To: From: Gyan Mishra Date: Tue, 6 Oct 2020 13:26:10 -0400 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: Christian Hopps , "Les Ginsberg (ginsberg)" , "draft-ketant-lsr-ospf-l2bundles.all@ietf.org" , "lsr-chairs@ietf.org" , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c7f5a605b103e50a" Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 17:26:26 -0000 --000000000000c7f5a605b103e50a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ketan! On Mon, Oct 5, 2020 at 1:29 AM Ketan Talaulikar (ketant) wrote: > Hi Gyan, > > > > Thanks for your support and comments on the draft. > > > > The proposed encoding for L2 Bundle members and their attributes in OSPF > is different than the ISIS encodings in RFC8668. ISIS encodings have > =E2=80=9Ctighter=E2=80=9D LSP space considerations that OSPF. The authors= have proposed a > simpler encoding scheme for OSPF =E2=80=93 feedback/inputs are welcome. > > > > The list of attributes in Figure 2 and 3 also includes L2 Bundle member > Adj SID. Since the encoding scheme is similar to Layer 3 attributes, we c= an > re-use the same sub-TLVs. > > Gyan> Makes sense. So were able to reuse existing TLVs which makes it > easier then ISIS encoding with OSPFv2 RFC 7684 Extended prefix opaque LSA > and OSPFv3 RFC 8362 TLV extensibility. The primary goal of this draft is > for PCE to be able to instantiation of flows over LAG L2 member links. = I > was wondering if this same member link TLV extension can be used for > control of costs associated with bundle and flow instantiation over a > member link in a distributed manual model. Basically same functionality > provided to controller be able to leverage in a distributed model. > Thanks, > > Ketan > > > > *From:* Lsr *On Behalf Of *Gyan Mishra > *Sent:* 03 October 2020 04:07 > *To:* Les Ginsberg (ginsberg) > *Cc:* lsr@ietf.org; draft-ketant-lsr-ospf-l2bundles.all@ietf.org; > Christian Hopps ; lsr-chairs@ietf.org > *Subject:* Re: [Lsr] WG adoption call for > draft-ketant-lsr-ospf-l2bundles-01 > > > > > > I support WG adoption of this draft. > > I agree that OSPF needs the functionality equivalent to that defined for > IS-IS in RFC 8668. > > > > I think the draft should include similar to RFC 8668 section 3 parallel > layer 3 adjacencies 3 similar Sub TLVs mentioned flag for multiple parall= el > adjacencies. > > > > Also maybe section 4 of RFC 8668 would apply as well to ospf advertisemen= t > of L2 bundle Adj sid. > > > > Thanks > > > > Gyan > > > > On Fri, Oct 2, 2020 at 6:11 PM Les Ginsberg (ginsberg) 40cisco.com@dmarc.ietf.org> wrote: > > I support WG adoption of this draft. > > OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668= . > > > > Les > > > > > > > -----Original Message----- > > > From: Lsr On Behalf Of Christian Hopps > > > Sent: Friday, October 02, 2020 5:03 AM > > > To: lsr@ietf.org > > > Cc: lsr-chairs@ietf.org; Christian Hopps ; > draft-ketant- > > > lsr-ospf-l2bundles.all@ietf.org > > > Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 > > > > > > This begins a 2 week WG adoption call for the following draft: > > > > > > https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ > > > > > > Please indicate your support or objection by October 16, 2020. > > > > > > Authors, please respond to the list indicating whether you are aware of > any > > > IPR that applies to this draft. > > > > > > Thanks, > > > Chris and Acee. > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > -- > > > > > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 Columbia Pike > > *Silver Spring, MD > > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000c7f5a605b103e50a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ketan!

On Mon, Oct 5, 2020 at 1:29 AM Ketan Ta= laulikar (ketant) <ketant@cisco.com<= /a>> wrote:

Hi Gyan,

=C2=A0

Thanks for your support and comments on the dr= aft.

=C2=A0

The proposed encoding for L2 Bundle members an= d their attributes in OSPF is different than the ISIS encodings in RFC8668.= ISIS encodings have =E2=80=9Ctighter=E2=80=9D LSP space considerations tha= t OSPF. The authors have proposed a simpler encoding scheme for OSPF =E2=80=93 feedback/inputs= are welcome.

=C2=A0

The list of attributes in Figure 2 and 3 also = includes L2 Bundle member Adj SID. Since the encoding scheme is similar to = Layer 3 attributes, we can re-use the same sub-TLVs.

Gyan> Makes sense.=C2= =A0 So were able to reuse existing TLVs which makes it easier then ISIS enc= oding with OSPFv2 RFC 7684 Extended prefix opaque LSA and OSPFv3 RFC 8362 T= LV extensibility.=C2=A0 The primary goal of this draft is for PCE to be abl= e to instantiation of flows over =C2=A0LAG L2 member links.=C2=A0 I was won= dering if this same member link TLV extension can be used for control of co= sts associated with bundle and flow instantiation over a member link in a d= istributed manual model.=C2=A0 Basically same functionality provided to con= troller be able to leverage in a distributed model.

<= /blockquote>

Thanks,

Ketan

=C2=A0

From: Lsr <lsr-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: 03 October 2020 04:07
To: Les Ginsberg (ginsberg) <ginsberg=3D40cisco.com@dmarc.ietf.org> Cc: lsr@ietf.org; draft-ketant-lsr-ospf-l2bundles.all@ietf.org; Christian Hop= ps <chopps@chopps= .org>; lsr-= chairs@ietf.org
Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bund= les-01

=C2=A0

=C2=A0

I support WG adoption of this draft.

I agree that = OSPF needs the functionality equivalent to that defined for IS-IS in RFC 86= 68.

=C2=A0

I think the draft should include similar to RFC 8668 section= 3 parallel layer 3 adjacencies 3 similar Sub TLVs mentioned flag for multi= ple parallel adjacencies.

=C2=A0

Also maybe section 4 of RFC 8668 would apply as well to ospf= advertisement of L2 bundle Adj sid.

=C2=A0

Thanks=C2=A0

=C2=A0

Gyan

=C2=A0

On Fri, Oct 2, 2020 at 6:11 PM Les Ginsberg (ginsber= g) <ginsberg=3D40cisco.com@dmarc.ietf.org> wrote:

I support WG adoption o= f this draft.

OSPF needs functionality equivalent to that defined for IS-IS in RFC 8668.<= br>


=C2=A0 =C2=A0Les





> -----Original Message-----

> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Christian Hopps

> Sent: Friday, October 02, 2020 5:03 AM

> To: lsr@ietf.org=

> Cc: lsr-chair= s@ietf.org; Christian Hopps <chopps@chopps.org>; draft-ketant-

> l= sr-ospf-l2bundles.all@ietf.org

> Subject: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01=

>

> This begins a 2 week WG adoption call for the following draft:

>

>=C2=A0 =C2=A0https://datatracker.ietf.org/doc/draf= t-ketant-lsr-ospf-l2bundles/

>

> Please indicate your support or objection by October 16, 2020.

>

> Authors, please respond to the list indicating whether you are aware o= f any

> IPR that applies to this draft.

>

> Thanks,

> Chris and Acee.



_______________________________________________

Lsr mailing list

Lsr@ietf.org

htt= ps://www.ietf.org/mailman/listinfo/lsr

--

Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD

=C2=A0

--000000000000c7f5a605b103e50a-- From nobody Tue Oct 6 14:57:13 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765E43A1505 for ; Tue, 6 Oct 2020 14:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 spi8qP5LosG5 for ; Tue, 6 Oct 2020 14:57:09 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2091.outbound.protection.outlook.com [40.107.93.91]) (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 974933A09C4 for ; Tue, 6 Oct 2020 14:57:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=daBrWrKysgSSHss0cxTs69bd+kQvkAAilMkJI5GFmCDD3LQrwMwG79A92QURihmHXo+Q5E1cZm0hgBX69c2pPxXRX/aHwtO+cQ2pZfqVe41N1z+x85Npc/XM3sy2LQysraqDi6//Wd/kAvUS0NGwfFx0DMp4zgkT7kNYEWxQIqEsXlBGuxJJepyTFv/3MiZVp1Oh5N9EkvNyh6FTBMrz0jUf8B5/z2N9g7cN9Px7vyMTZh6d4N912QpxcQk5MqF7TxPW+ZBUoks2rWBOe/u+mFiSXGOAzKcEcxuItbn1ty0MiUBWvMCaCQAYN48bg/2YFcgXxagc8XNTZUwP2xpT0A== 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=LUyVZ811Zp5zoYmSmZlt1HcZyRxoJmIDk6NOH2oXAyY=; b=XCh6WhfGH4Vk7EtBe1FWrz6ZKzFCAok9NlEhGWhgz0pJIz7Sn8FsmzqFjd9EptO37hGmfVZttDFdXJZVCO5MtFav+3goQIgLpYKLQpEIeVhc6cSvgUf62aKeZvvbI454DmyJMrmjV2ui/5OAEYWX1ENWf67wzpQq4+vZ75tWppbKRF7SFtXN74GcrSrwGEhmgxMduLC7wbFVAjS2lZ0Q8sizhqWFwSi/U6lNH5riKoKN5k6qDWvPXKDX7Oo3NC9fqChaA6ffZBhCvRFhHTyhlwrd0eAMU2fmvIVjqp20L0YHMlNCjEW6ktr0z2tmO+oBsP8HxPulB52gb2fRek/3Fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LUyVZ811Zp5zoYmSmZlt1HcZyRxoJmIDk6NOH2oXAyY=; b=b+vqcOWWGyTuF07RzbC5aulBPAr9RWV0fmL8xrpRrLG9WSKE3Z5h4555nGJ+/u7DxdttaTAmZZ2Xpt9aQAlm+MmAvE/XIYh+twtx41/pZZo3pX+igwOJnLQ211xRTIv9nTpHa5KhfJC4UuH+Ey7XB4OJFliSbX1Bi0G15RaFAeM= Received: from MN2PR13MB3117.namprd13.prod.outlook.com (2603:10b6:208:13a::20) by MN2PR13MB2814.namprd13.prod.outlook.com (2603:10b6:208:f5::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.13; Tue, 6 Oct 2020 21:57:06 +0000 Received: from MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::3cc6:662d:2447:1f2]) by MN2PR13MB3117.namprd13.prod.outlook.com ([fe80::3cc6:662d:2447:1f2%6]) with mapi id 15.20.3455.021; Tue, 6 Oct 2020 21:57:06 +0000 From: Huaimo Chen To: "lsr@ietf.org" Thread-Topic: draft-zhu-lsr-isis-sr-vtn-flexalgo-01 Thread-Index: AQHWnCuhBu5Xdzweg0eHU56yeYA18w== Date: Tue, 6 Oct 2020 21:57:06 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <047be764-8203-ca46-7ee1-6f84f7bf2356@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [73.114.233.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 641212b7-f754-4610-76a5-08d86a42c424 x-ms-traffictypediagnostic: MN2PR13MB2814: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YZH6A1BDUhE2kLUg8KqoG60QQfQ15/V3Ff9sBoraOe0JSjWip7bN8/cc6+jcsZP11sEP8y2bN4imQTqwGkLrn0qeI1DsAuwpYTSzviDGbW8awpQ6jWG+cIeqzdDkPI9++qKbbhIePS34ay47+aD8OSwkoqS4BZa6YAySBUHV5tWIEwSAB2d/pW+Ko1s9G2Ls8O6bcSQodW2tCj4cQjrSl59rbpeTS2vZ50teX+FkaJV4nbtLFOu4uO4qxpkasgM/3kGMJEeS7lFah8DXkv87tSPnuD6mjer3JQ2nReRyybrffd7kJoV9rSnbnKMXVL7P x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3117.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(136003)(346002)(376002)(396003)(366004)(2906002)(44832011)(55016002)(8936002)(5660300002)(9686003)(66446008)(66476007)(76116006)(8676002)(66946007)(64756008)(66556008)(91956017)(26005)(6916009)(86362001)(33656002)(52536014)(71200400001)(83380400001)(478600001)(7696005)(316002)(6506007)(186003)(19627405001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: XwXqUG3gQzonDmWD5qrdsbaDzREp5ypRGOuGEJOHW4cIhWS97UAEl4thE+CKGyKjDp09ZLyxnyaZL3EhrRNquC7n3jL0RA6OqVYg6nCbsRK068ppP3FgkbidzJ+1dRdpRcRSPL/U5NfyMVZM63/88N7BTQBMLyxA947BGvJ+LziIa4NcimW2uztnw0MCbbVC5AWLXpF/QLH8wLnu1oL/cxyKxp0Tnza82L83OeTFU3KesMtRgby5DskqjDpm+HcDCA9PCFdRj0iTp8Ag5qbcSOeGmBESGnGDW51bwz1M1B+9Qme3I7fv114G484Y+OTTb4Iy4WlaClqYj2xgtDwY5zSWlop/ig8m1bOpJQuxgh2cV3qLJUlb/0p42p3rHAJnrjodcPkbP1zm/OsNsqkRvJPuq5uSKuz1fFUJ5VBmXV3dTXBtcsPwNBLvzm3n0IddGfnTDaLAAvr5E7jM/EZeOKud09aixOIL1WaIqVzGIpzo0MdUrvQy3qXSCAwsYW2ifirfcDp9NDIrgNRwd348zFjMq0Am+3ojwe+R0f+r0/wbDQQgdkPl3RGAv+wpV3S0E9DAdxSz3KzHPGuJOKg1ncMMPqM2+6PHUZi4/SLqiOVudJB2qFItoHX0agQRDQD0XHLKAjOfp1i1mI93DGk6Dw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3117442307E6038B3F15F248F20D0MN2PR13MB3117namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3117.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 641212b7-f754-4610-76a5-08d86a42c424 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2020 21:57:06.1526 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nMfqVyE80ckBk6kb6C4jOuVaprMHzckF9FZgactjhcwwgrBBKogmdn1LQCKpEH6njZY2BY6w9x/LgExmUcl0Fw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2814 Archived-At: Subject: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:57:11 -0000 --_000_MN2PR13MB3117442307E6038B3F15F248F20D0MN2PR13MB3117namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Authors, I have the following comments/questions on the draft. In section 2 "Advertisement of SR VTN Topology Attribute", for the last sentence "..., the Flex-Algo identifier could be reused as the identifier of the VTN in control plane.", How do you reuse the Flex-Algo identifier? Does every VTN have a Flex-Algo identifier? If so, where does the Flex-Algo identifier of every VTN come from? In section 3 "Advertisement of SR VTN Resource Attribute", is new flag "V" (Virtual) defined in this draft as an extension to RFC = 8668? If so, should an IANA request/action in section "IANA Considerations" be added for this extension? If not (i.e., it is defined in another draft), it is better to remove the definition of flag "V" from this draft and add a reference to another draft. In this case, it seems that there is no IANA request from this draft. It would be better to change the intended status of the draft from the standards track to informational. Some nits: In section 2, the second sentence of the last paragraph, should "to used" be changed to "to use"? In section 3, the first sentence of the second paragraph, should "was defined to advertise" be changed to "defines the advertisement of"? Best Regards, Huaimo --_000_MN2PR13MB3117442307E6038B3F15F248F20D0MN2PR13MB3117namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Authors,

    I have the following comments/questions on the draft.
 
    In section 2 "Advertisement of SR VTN Topology Attr= ibute",
for the last sentence "..., the Flex-Algo identifier could be reu= sed
as the identifier of the VTN in control plane.",

    How do you reuse the Flex-Algo identifier?
    Does every VTN have a Flex-Algo identifier?
    If so, where does the Flex-Algo identifier of every VTN come = from?

    In section 3 "Advertisement of SR VTN Resource Attribute= ",
    is new flag "V" (Virtual) defined in this draf= t as an extension to RFC 8668?

    If so, should an IANA request/action in section "IA= NA Considerations" 
be added for this extension?

    If not (i.e., it is defined in another draft),
it is better to remove the definition of flag "V" from
this draft and add a reference to another draft.
    In this case, it seems that there is no IANA request fro= m this draft.
It would be better to change the intended status of the draft from the standards track to informational.

Some nits:
In section 2, the second sentence of the last paragraph,
should "to used" be changed to "to use"?

In section 3, the first sentence of the second paragraph,
should "was defined to advertise" be changed to
"defines the advertisement of"?
    
Best Regards,
Huaimo
--_000_MN2PR13MB3117442307E6038B3F15F248F20D0MN2PR13MB3117namp_-- From nobody Wed Oct 7 08:20:17 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE423A0A0B; Wed, 7 Oct 2020 08:20:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <160208401453.4313.11157559474750373754@ietfa.amsl.com> Date: Wed, 07 Oct 2020 08:20:14 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-12.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 15:20:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IGP Flexible Algorithm Authors : Peter Psenak Shraddha Hegde Clarence Filsfils Ketan Talaulikar Arkadiy Gulko Filename : draft-ietf-lsr-flex-algo-12.txt Pages : 37 Date : 2020-10-07 Abstract: IGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document proposes a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-12 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-flex-algo-12 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 Oct 8 04:55:34 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398013A09C6; Thu, 8 Oct 2020 04:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=gGwMIKVr; dkim=pass (1024-bit key) header.d=juniper.net header.b=BGg5mtjE 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 biecBJmmZcSh; Thu, 8 Oct 2020 04:55:30 -0700 (PDT) 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 D63383A0820; Thu, 8 Oct 2020 04:55:26 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 098BqYMG011284; Thu, 8 Oct 2020 04:55:25 -0700 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=SIdevIcLLO/z16NbJwGECUK1Elb05GFHF9E7t0TToqA=; b=gGwMIKVrYGDcUpcrwklsfoC6PA96pb4lqQDbP8kzIgKFTKnsUNh6coWIxt6pUUGWsEna pXWrfM+zZI3Ay0dU9poamu+YOeOfLN9p/LtQi294FMnW8ziarWqEL9oK13EgSBerX6LP FT5M1OpHh8rtsMWRdgFcPQ6YaO7JwDSnguULUYnH///LDR56Jppal3LMFkA+rjwthQG7 CIWEziOgwxqTWEzqNoGM8rmygr9sjgWPqeyyEC3aMyJdN/ii0s/LdYGWNIUYC8Iyk7Qa y3bQW/DNRkxQyAC8nD5ckKBkwLw/0QP/JLMt0GUeGwgSIR5uhiThEwhmFujueBtzza2w yw== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2176.outbound.protection.outlook.com [104.47.58.176]) by mx0b-00273201.pphosted.com with ESMTP id 340x3nu3m7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Oct 2020 04:55:25 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jYoYcrSFgq8/zWQjQd65nrvHvshx8Thw4VwCIRsNVsgZox01B05/NyNYXWHnz3hRQPEoJM3H5ZMxL4x+y/Mp1XO1Kv2r0Q0A4cpNEHqEbNYXfjAKkkxmAEagRA6dV2lwYj4noKGKQpGZoe2nDXWq/DWLgu97BHkOzmYdvQCjluyc2H75qstMV+N0SzYPEpWTPcXDxj5XpfnUWAliUAKocmHsKIxswvRI81NNNJ2qrVOH2MfDmQPhan/AIk+3cfYKRC7sDoORsWoyH5w6flb6cH96PJWNr2F59MAYl74a1B0F5HLKsttSNVxxQr9Vwn7OFh4eg9WTm18BQO6yqN68TA== 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=SIdevIcLLO/z16NbJwGECUK1Elb05GFHF9E7t0TToqA=; b=V/tC/pMyT63Ie4GRYJUNie+m5n3Ha+B1pigSNNH/Yy3u/nMnDVISpzc2gZaizkr2rVakbvjbycMxN/Srx87SiUXgykqlyWqnfwoHOfTFNRMi9BBHG0OPHEsgioC5HFAbahfneK/UcLHt+5gv40eMWNzN4fZtWlD6nVwrDmxJD/cyQvmReU/DezoN2XqjfslGGHUPc6VwKP0RVv31vuu5zm0dSTGcIodPdNr5idFv3oE0JnVesrhWmwOoRN75JjPsAkBGq3tBjtCyg+AVZc89L3M/6LFnrv7D9+WHl0CYPfO65BlaqgojWjPTR1CE46WrY6jXFJ44UZp0FCOkQ0+/Ww== 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=SIdevIcLLO/z16NbJwGECUK1Elb05GFHF9E7t0TToqA=; b=BGg5mtjEMtbW+4D2bxg8Zelcs27Wm3fiNAgqZa/+nCQUcfg6wh4VpDoWBkz+4TVh0lalIYDqlp9O6mgr0IlbWi4hF0idzE4WLekwFuwN9s6aGr+/9YcDuhJ6GHcRxNn5V5jx5q5SQDc4J3QCfbIOAFLF9g0hj1UDpx8utS50uy4= Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY1PR05MB2683.namprd05.prod.outlook.com (2a01:111:e400:c638::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Thu, 8 Oct 2020 11:55:22 +0000 Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::4c41:220e:4f09:3157]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::4c41:220e:4f09:3157%7]) with mapi id 15.20.3455.016; Thu, 8 Oct 2020 11:55:22 +0000 From: Shraddha Hegde To: "Acee Lindem (acee)" , "draft-ietf-lsr-flex-algo@ietf.org" CC: "lsr@ietf.org" Thread-Topic: IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt Thread-Index: AQHWmDDNhkw+5hrRJ0Oa3/xXMwvRhKmNo1Xg Date: Thu, 8 Oct 2020 11:55:22 +0000 Message-ID: References: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> In-Reply-To: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-08T11:55:18Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=fecf345f-3ddf-41cb-873b-d3ce52561248; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [116.197.184.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ebcfa117-2b06-42b7-7c25-08d86b810943 x-ms-traffictypediagnostic: CY1PR05MB2683: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qZQVQNKWA5ueMzvg0ee8e1otR4+PuPH0X1fpBVn8s0d4RbiPffzX7FJHLdG1hWxby5Sk2HI7yE84G7U1bVw0GUh5+OQH/WtLr6LsThFdwkl1e+Qm5+NWPHqK0IA5+fI9Rbv5cqDtHJmxNNkLbpnBh2xNgvLiwy8ZZNozIJIcxyCLuXE0HkqlqBXF97jabc5WVLLVSTGg7qOUW44Z7loUpGETelTHl6jt9zMuZNN4C+NFwPy6b6R2BZI0/eHsWW8WgbnK0eOAIG3RWJ7ePeCyOooD9BioIHX6Bq50y9QM3EeTqprdZ/aMZuuS7f3DK65whfkGzGwUfMVIcOmCJm65KuO0HJDhjS1ouZZnmCP2EM85zrMoWkoHjzcpsRjT53eIxB4b78SNuEPp/5OcuxCgzQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(346002)(376002)(396003)(366004)(52536014)(71200400001)(53546011)(9686003)(26005)(478600001)(66476007)(6506007)(64756008)(66556008)(86362001)(66946007)(76116006)(186003)(66446008)(966005)(2906002)(5660300002)(316002)(8936002)(4326008)(83380400001)(7696005)(110136005)(33656002)(55016002)(83080400001)(166002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: xyt1WsOoKOF0VRr+a8mn3uLXdaaLnRo4aLY9PruEcKvtfQ30inOiUVjnGZ6/VI3ajXvZ/x5IT3o2Ukk6Kd+hnN87kCbQwguJ62W+wDvgLg9siQsOaTMGChOk3kYpgfiKlgPWLV/HoesZjrmndZfoMQhcThOGHohIR19dilb1TtMhzh+Dcy7YvazO3jKZQaGer69sHFpOfo6fbz/yBv4k+QpZfM6oHEq09c30ExMBI03gVovPqkzpq/lIu5WUKg2r1Rj5/KzHqPWTnSGfSuhDhHRhdjQXmcr6CjLFyiQVaTt+PXHZzAhKl63F4WheT2qdPLnLY7nXrkkhM5qHJNHHmuoRLldctJadfP6dutvVGpQ8lWxWGdUgZp3wRZAvufplu1BdV0YxIobkY6HFcpwptc/fmJ7I8SpwsNOJymI/eMbMx6VkfD4XZLJOLnbMnAd0PcV0+WrLA4/YJiriQt8PfMjQwcHVcamZpmggfqQ+hgBVDUTTfqn5owQuQOzNmXIPhA5+1MB+6iZiFf97S4Y4zKurOVqBSbOUWTOj/xzAlqFFB2Ne/eRJZb8Cn8FN8Fq+ISCVA4Ha34IN6wuxfPX2y/UfB2ZH0f6FPwXK2CLCB947kQOTbjm8SY5zJ4O+Cw7+Sof8YquJ6X9G71DHpaTSJA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3576CAF959D1A51E999D79EFD50B0CY4PR05MB3576namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebcfa117-2b06-42b7-7c25-08d86b810943 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 11:55:22.2146 (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: O78jhTGo/SS/2AMCpkUquRxLHA24oycANZTtPy8BdSbZP3qjMNNo/SkPTrFxV8DREmeF7Wamr6M09bIpkpNBaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2683 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-08_07:2020-10-08, 2020-10-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 adultscore=0 malwarescore=0 clxscore=1011 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010080089 Archived-At: Subject: Re: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 11:55:32 -0000 --_000_CY4PR05MB3576CAF959D1A51E999D79EFD50B0CY4PR05MB3576namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR. Juniper Business Use Only From: Acee Lindem (acee) Sent: Friday, October 2, 2020 1:54 AM To: draft-ietf-lsr-flex-algo@ietf.org Cc: lsr@ietf.org Subject: IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11= .txt [External Email. Be cautious of content] Authors, The following IPR has been disclosed (excerpted from https://datatracker.ie= tf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-lsr-flex-algo): Date ID Statement 2018-08-08 3248 Cisco's Statement about IPR related to draft-ietf-lsr-flex-algo 2019-12-05 3910 Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-lsr= -flex-algo Are you aware of any other IPR that applies to draft-ietf-lsr-flex-algo? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the LSR WG mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the LSR WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Acee --_000_CY4PR05MB3576CAF959D1A51E999D79EFD50B0CY4PR05MB3576namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of a= ny IPR.

 

 

Juniper Business Use Only

From:= Acee Lindem (acee) <acee@cisco.com>
Sent: Friday, October 2, 2020 1:54 AM
To: draft-ietf-lsr-flex-algo@ietf.org
Cc: lsr@ietf.org
Subject: IPR Call on "IGP Flexible Algorithm" - draft-ietf= -lsr-flex-algo-11.txt

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Authors= , 

&n= bsp;

The fol= lowing IPR has been disclosed (excerpted from https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -lsr-flex-algo):

&n= bsp;

Date

ID<= /b>

Statement<= /span>

2018-08-08

3248

Cisco's Statem= ent about IPR related to draft-ietf-lsr-flex-algo

2019-12-05

3910

Huawei Technol= ogies Co.,Ltd's Statement about IPR related to draft-ietf-lsr-flex-algo

 =

 <= /span>

Are you= aware of any other IPR that applies to draft-ietf-lsr-flex-algo?

 <= /span>

If so, = has this IPR been disclosed in compliance with IETF IPR rules <= span style=3D"color:black">

(see RF= Cs 3979, 4879, 3669 and 5378 for more details).

 <= /span>

If you = are listed as a document author or contributor please respond

to this= email regardless of whether or not you are aware of any

relevan= t IPR. *The response needs to be sent to the LSR WG mailing

list.* = The document will not advance to the next stage until a

respons= e has been received from each author and contributor.

 <= /span>

If you = are on the LSR WG email list but are not listed as an author or

contrib= utor, then please explicitly respond only if you are aware of

any IPR= that has not yet been disclosed in conformance with IETF rules.=

&n= bsp;

Thanks,=

Acee

 

 

--_000_CY4PR05MB3576CAF959D1A51E999D79EFD50B0CY4PR05MB3576namp_-- From nobody Thu Oct 8 05:13:48 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3A33A0A1F; Thu, 8 Oct 2020 05:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 0stKXeLGc44E; Thu, 8 Oct 2020 05:13:45 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 950B33A0A1E; Thu, 8 Oct 2020 05:13:45 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id y1so265158uac.13; Thu, 08 Oct 2020 05:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7qcuxvPoOQLxoEUrxN35XEgwjgb5AYAlu225rcL4kus=; b=bsEHDjQlCpjtQeoBMONasR+i01YM7CGhp4YBwz/BDFMvOtqi7yfGW2dCV81BWMmYA8 6uIqJdnpYudlM9TKlbFo6D1zBoaB0w6fxMB+ktKMOj/BYJFP6gpqixb1ZhJq0fuKvsGi f5YlfouNKHJVGgK+9W/o2Ni/Q7Tfm9K33YbZaw+m4/W603jgbsGO9EtgB0V9QTnLMh/h toDcIcSrk24pNFOG5B3ff1UpsZOcduGmvWvfPvWbuSU/BCPdLnqZKFSICaoTlVrwdGRi 3jmqTfnvIhVQ8JFBN31EKiHCia6CGyWkvmCyV91ySXzS2ZZ69uNcZB7nFil5mprN8b8K fJsw== 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=7qcuxvPoOQLxoEUrxN35XEgwjgb5AYAlu225rcL4kus=; b=c7YggM2yu4geEyz8wg8RZ4bX0uaHbb8nOETH/RTVgvXv1hPtXdwFf2KEcrw3Nm9Djw uLEjHFNLXdkaQugUTiV/ZkGAnvZj1qG8w01J1TDNXAMsbTPZ4wt7hgjav2ZZzO51+v2u 0FKpnS5DMW6hB1fr/JnJ6eBzkdO0S363qTmvqOiYDykhZ59yDdgU1raA9olRTdnwh+Ir fb9ny3YCDe8HP60V5zQoZA/LrYpp0gvXeGL4Mfehm3ZAmvd3cLZnWdhrUu+iliej3pGc 9lPoqsei0zWJORyFUUYLb+KUs1D9+6f8hbWc5gIYDnHpF05HP81NA9VaSPiUTIXTW/gE gboQ== X-Gm-Message-State: AOAM530k34h22kNf4FUT4ZFomDHBfYfTZTLh/BSAeSajq2g9DiVwsc6F boWWK85dZ1tPgPI6QRnIC+AW1wgqFXjWNh6mYw== X-Google-Smtp-Source: ABdhPJw67odt/iOSjI9yzCsuvXeAwQ0PYnypxl/eDv4VnGhuS93xdo/hPqZqnqIa0LGbqo/Ntb8Q2lafo4CbzI4GeBo= X-Received: by 2002:ab0:5ac1:: with SMTP id x1mr4168435uae.20.1602159224602; Thu, 08 Oct 2020 05:13:44 -0700 (PDT) MIME-Version: 1.0 References: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> In-Reply-To: From: Arkadiy Gulko Date: Thu, 8 Oct 2020 08:13:33 -0400 Message-ID: To: Shraddha Hegde Cc: "Acee Lindem (acee)" , "draft-ietf-lsr-flex-algo@ietf.org" , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="00000000000074c50805b127c381" Archived-At: Subject: Re: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 12:13:47 -0000 --00000000000074c50805b127c381 Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR. On Thu, Oct 8, 2020 at 7:55 AM Shraddha Hegde wrote: > I am not aware of any IPR. > > > > > > Juniper Business Use Only > > *From:* Acee Lindem (acee) > *Sent:* Friday, October 2, 2020 1:54 AM > *To:* draft-ietf-lsr-flex-algo@ietf.org > *Cc:* lsr@ietf.org > *Subject:* IPR Call on "IGP Flexible Algorithm" - > draft-ietf-lsr-flex-algo-11.txt > > > > *[External Email. Be cautious of content]* > > > > Authors, > > > > The following IPR has been disclosed (excerpted from > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-lsr-flex-algo > ): > > > > > *Date* > > *ID* > > *Statement* > > 2018-08-08 > > 3248 > > Cisco's Statement about IPR related to draft-ietf-lsr-flex-algo > > > 2019-12-05 > > 3910 > > Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-lsr-flex-algo > > > > > > > Are you aware of any other IPR that applies to draft-ietf-lsr-flex-algo? > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > > > If you are listed as a document author or contributor please respond > > to this email regardless of whether or not you are aware of any > > relevant IPR. *The response needs to be sent to the LSR WG mailing > > list.* The document will not advance to the next stage until a > > response has been received from each author and contributor. > > > > If you are on the LSR WG email list but are not listed as an author or > > contributor, then please explicitly respond only if you are aware of > > any IPR that has not yet been disclosed in conformance with IETF rules. > > > > Thanks, > > Acee > > > > > --00000000000074c50805b127c381 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not aware of any IPR.

On Thu, Oct 8, = 2020 at 7:55 AM Shraddha Hegde <= shraddha@juniper.net> wrote:

=C2=A0

Authors= ,=C2=A0

= =C2=A0

The fol= lowing IPR has been disclosed (excerpted from https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf= -lsr-flex-algo):

= =C2=A0

Date

ID

Statement

2018-08-08=

3248

Cisco's Statement about IPR related to draft-ietf-lsr-flex-algo=

2019-12-05=

3910

Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-lsr-flex-algo

=C2=A0

=C2=A0<= /span>

Are you= aware of any other IPR that applies to=C2=A0draft-ietf-lsr-flex-algo?

=C2=A0<= /span>

If so, = has this IPR been disclosed in compliance with IETF IPR rules=C2=A0<= span style=3D"color:black">

(see RF= Cs 3979, 4879, 3669 and 5378 for more details).

=C2=A0<= /span>

If you = are listed as a document author or contributor please respond

to this= email regardless of whether or not you are aware of any

relevan= t IPR. *The response needs to be sent to the LSR WG mailing

list.* = The document will not advance to the next stage until a

respons= e has been received from each author and contributor.

=C2=A0<= /span>

If you = are on the LSR WG email list but are not listed as an author or

contrib= utor, then please explicitly respond only if you are aware of

any IPR= that has not yet been disclosed in conformance with IETF rules.<= /u>

= =C2=A0

Thanks,=

Acee

=C2=A0

=C2=A0

--00000000000074c50805b127c381-- From nobody Thu Oct 8 06:25:37 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853EE3A0B5C; Thu, 8 Oct 2020 06:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=GFgGXHKl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=C6890MKF 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 2dMv0GFFYnfG; Thu, 8 Oct 2020 06:25:34 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97E03A0B5A; Thu, 8 Oct 2020 06:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14194; q=dns/txt; s=iport; t=1602163533; x=1603373133; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UqbuSV8eYeb0gvHNvMnmq9GKtpwyI8TOjlDwG47YW2c=; b=GFgGXHKleRbmh4uddapg6ucRLR/6BiPN5HEzqWa2uHek8PLt2YWuzDUZ tZ6ltOlyrCb61g9NMII2ZxeciYW3Gv8rIoKxJqI+K29s6VM+ARxo25qEV RslPOSwCPArRBmeZvDLnziMXNN8ubk3kj4L66IzxxonJW+7ygwXBUFg/5 U=; IronPort-PHdr: =?us-ascii?q?9a23=3AF6xwuBH2oD6hJ4fu97/yNp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QObVoTA4PUCgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS83/fFbV5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKCQAVEn9f/5tdJa1gHgEBCxIMgzI?= =?us-ascii?q?vUQdwWS8sCoQzg0YDjVGUDIRvgUKBEQNVCwEBAQ0BASUIAgQBAYRKAheBcwI?= =?us-ascii?q?lOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAxIRChMBASwGBQEPAgEIEQQ?= =?us-ascii?q?BASsCAgIwHQgCBAENBQgagwWBfk0DLgEOngECgTmIYXaBMoMBAQEFgTMBg20?= =?us-ascii?q?YghADBoE4gnKDa4ZWG4FBP4FUgk0+glwCAgEWgREBEgEjFRaCajOCLZAQgzS?= =?us-ascii?q?HBZ0UCoJoiQCSCYMTigWUF5IUDHqKcJUsAgQCBAUCDgEBBYFrI2dwcBU7gml?= =?us-ascii?q?QFwINjh+DcYUUhUJ0DygCBgoBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,350,1596499200"; d="scan'208,217";a="557327743" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2020 13:25:32 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 098DPWYi013943 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2020 13:25:32 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 08:25:32 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 08:25:32 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 8 Oct 2020 08:25:31 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X7p5rrlZqqI93mEcgaPfSE9hLlW4ObU4V6BilTxmpGInnRgFRdFuh5Z4CmdvkX0Oc9cnPkARWI/6v9eyY+5RxifAleEicLJ+pU/ZN+8CPx8Y3JfB/Rz1ET+7e1SQgTpTZINASvolbISRbMdzznnjIoBHSbX0ctUI9ColIZMHiq7+sMaSGyIbYksUiXiUNWu3M9QIvjoUEI5FQKRn8ngiH/NEWnzQBacUczHb7oztokJhCBxnnuyqxtrhIHPRQV5EQHiStUkxM0OPnngLEzFdsDJQ7SCfdFPMGfcHbQ/2n1y3sJzYva9FBQZpeJeUKw9rpRkegbbXg/QXAEeZa22feg== 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=UqbuSV8eYeb0gvHNvMnmq9GKtpwyI8TOjlDwG47YW2c=; b=ePKnykuhkYaq01W3FKd0h/YkJjvMO6jIY6XInxCBHdcJ9SWotXh0d7K7efJUSgyyfkbuDGl/xi8pSjqttcHaHid56dox5CEt8+SAEG9kS/sHtmLmUQx7Ej4itUxSd4oXtlhQxDEocjSqbb05Bz1ZYgr9pdZyP44JbDvpRembmhY3zKMD6hjV39VWldW4TVq8eBgHVzEYilyl5mavI290T3ow6XPJEfP+FD2ePsKbDTbo5e7QQqO9T0v7B0rkFUmS7spDkV7G0+0AC4tsw1ZZVwZgM1hb04mQDcbmYBUFxgVbVT485DlkRmsGTdnhe3EIMFrH6ii09bMT14TaWhP0dw== 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=UqbuSV8eYeb0gvHNvMnmq9GKtpwyI8TOjlDwG47YW2c=; b=C6890MKFo4dsyRqbQGaraSvza96KODZ6L9VAnizOkzJQHFSf8jE4pTFkrDeTNI8/pxuCBHukaAGP9jYZa7sSmNioLi+4pmLEOSjZ/GjWraOdhroScWUtiJ4zJ4CslcTBqFn7uDH+GTkqMnifq2VRz60MzyQw6FTgKMb2rba4+K0= Received: from DM5PR11MB1289.namprd11.prod.outlook.com (2603:10b6:3:b::9) by DM6PR11MB3019.namprd11.prod.outlook.com (2603:10b6:5:67::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.22; Thu, 8 Oct 2020 13:25:31 +0000 Received: from DM5PR11MB1289.namprd11.prod.outlook.com ([fe80::89d6:2f80:8910:784b]) by DM5PR11MB1289.namprd11.prod.outlook.com ([fe80::89d6:2f80:8910:784b%11]) with mapi id 15.20.3433.045; Thu, 8 Oct 2020 13:25:31 +0000 From: "Clarence Filsfils (cfilsfil)" To: "Acee Lindem (acee)" , "draft-ietf-lsr-flex-algo@ietf.org" CC: "lsr@ietf.org" Thread-Topic: IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt Thread-Index: AQHWmDDNhkw+5hrRJ0Oa3/xXMwvRhKmNvIVA Date: Thu, 8 Oct 2020 13:25:31 +0000 Message-ID: References: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> In-Reply-To: <561B9BA4-9638-4030-89D4-E7A25F89EE51@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.57] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 859a3ed2-568e-487d-7bfd-08d86b8da144 x-ms-traffictypediagnostic: DM6PR11MB3019: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q8NA8Q+ag0lrCms5Dd5TDxMoAUGaMa5HljVSiHgYNXWzt7oqixZOlc8Bd95btaZMTWzoKcy7rBDknp9HpfF6glDHfsfGVa60W4mMqD/YqZchxZHMOR91AslZhwprF2DniyuMIY/gRVHvP6/PKz3rvQAYkwHLtT3NCMIrd/wsNfVss7R1OULGZXxr8QjkJs+riaDxbUaJLjYrIGJed4TjVkJKtcS/CGZXIYqNvotgymVw0sQVa/0Q3x5CyRA5n1Pm7WFTtiTMHfaDPmo+88KGGeCbX9YsfOyLE9g4Julgg5XXrj1hR8vgT3BN9ptx5zX6Ees3C8HKeZRftURizQyyATC960C9d4/8kzWseXNuhXg5WXXX19rKp6FzVA/+4rqvgTMjBnddBjF5aDKbLO2mkg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1289.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(136003)(396003)(376002)(39860400002)(110136005)(9686003)(316002)(4326008)(53546011)(26005)(966005)(71200400001)(186003)(33656002)(83380400001)(6506007)(55016002)(450100002)(478600001)(66446008)(64756008)(66476007)(2906002)(66946007)(86362001)(76116006)(5660300002)(166002)(7696005)(83080400001)(52536014)(8936002)(8676002)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DBDgHZ++boc9CMJ4vyNigHU9XmMIm8WuqZUcXONk1vRn4Hh2cSO6gOQuQXq3cN+QQZUaAqDq6zTEeYhxnIQ/zcde6xhcAfHsxTCtJofOdIxWL8P7oCFI/ITrVNmaL8gtuM6HbfuRIf11/g2s0pbjf+dpCTjAgAU7/CaBCtUY41oT4Jg1DG8/C0Sqn5I7jrpRF+xSZspFcyfzmB81jnfF21D7vXBxHNhxDnHCbGqh8UAf6FF3I33ijYw6qU9qKip1bGGK9zhyFBzX/4iGFOsPNYY/IDd1UxtL5+RN7AbjXXGENloFZQBj87fOiCbXzFv2hZGcdkZWY6AjymEKugNxyibCedCzLxAhyMwdxvInPNkyedDcBb1e3KKB8N3fYuFWCjXFTDlXksSn87re+eJf2hrl0o9FB518sJf1gF6gQtz5CcRq8Qcvuw1ddBlWtYgqMMn0Win5mkqBEd1+PuLk6RsRmZAToLFxiHOQFbSQ98DPRGtNCHzg1as8ETRn0+8BQ2dxJn9zrBtOODIXyW+gcBPPAB9GuE+OwfSKULBy7ZHCSvml//7wjlda1yng/qIVWIU+3/hqIC7Yby5LUJ66gDHOxNmgbsJC1GX5yuE3ucJL/ULkcGx/wt8pySx/UqXIRP+lNg++70a8eY6hFvUyCQ== Content-Type: multipart/alternative; boundary="_000_DM5PR11MB12890008E0938DC72569BF28D00B0DM5PR11MB1289namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB1289.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 859a3ed2-568e-487d-7bfd-08d86b8da144 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 13:25:31.1336 (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: K7sYiGRMKGhWYM5lz+A5zEw/1g40VadydbtaMvOIjTpR4rAiWAVDxGI9qzA2GWeeBYcop4A57BKfr6PmRL9mIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3019 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Lsr] IPR Call on "IGP Flexible Algorithm" - draft-ietf-lsr-flex-algo-11.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 13:25:36 -0000 --_000_DM5PR11MB12890008E0938DC72569BF28D00B0DM5PR11MB1289namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWNlZSwNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiBvdGhlciB0aGFuIHRoZSBvbmUgYWxy ZWFkeSBkaXNjbG9zZWQgYmVsb3cuDQoNCkNoZWVycywNCkNsYXJlbmNlDQoNCg0KRnJvbTogQWNl ZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVy IDEsIDIwMjAgMjI6MjQNClRvOiBkcmFmdC1pZXRmLWxzci1mbGV4LWFsZ29AaWV0Zi5vcmcNCkNj OiBsc3JAaWV0Zi5vcmcNClN1YmplY3Q6IElQUiBDYWxsIG9uICJJR1AgRmxleGlibGUgQWxnb3Jp dGhtIiAtIGRyYWZ0LWlldGYtbHNyLWZsZXgtYWxnby0xMS50eHQNCg0KQXV0aG9ycywNCg0KVGhl IGZvbGxvd2luZyBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIChleGNlcnB0ZWQgZnJvbSBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP3N1Ym1pdD1kcmFmdCZpZD1kcmFmdC1p ZXRmLWxzci1mbGV4LWFsZ28pOg0KDQpEYXRlDQpJRA0KU3RhdGVtZW50DQoyMDE4LTA4LTA4DQoz MjQ4DQpDaXNjbydzIFN0YXRlbWVudCBhYm91dCBJUFIgcmVsYXRlZCB0byBkcmFmdC1pZXRmLWxz ci1mbGV4LWFsZ288aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMzI0OC8+DQoyMDE5 LTEyLTA1DQozOTEwDQpIdWF3ZWkgVGVjaG5vbG9naWVzIENvLixMdGQncyBTdGF0ZW1lbnQgYWJv dXQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdvPGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByLzM5MTAvPg0KDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IG90aGVy IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdvPw0KDQpJZiBzbywg aGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy dWxlcw0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cykuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1 dG9yIHBsZWFzZSByZXNwb25kDQp0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBv ciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkNCnJlbGV2YW50IElQUi4gKlRoZSByZXNwb25zZSBu ZWVkcyB0byBiZSBzZW50IHRvIHRoZSBMU1IgV0cgbWFpbGluZw0KbGlzdC4qIFRoZSBkb2N1bWVu dCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGENCnJlc3BvbnNlIGhh cyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5 b3UgYXJlIG9uIHRoZSBMU1IgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4g YXV0aG9yIG9yDQpjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9u bHkgaWYgeW91IGFyZSBhd2FyZSBvZg0KYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlz Y2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCg0KVGhhbmtzLA0KQWNlZQ0K DQoNCg== --_000_DM5PR11MB12890008E0938DC72569BF28D00B0DM5PR11MB1289namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5BY2VlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIG90aGVy IHRoYW4gdGhlIG9uZSBhbHJlYWR5IGRpc2Nsb3NlZCBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xhcmVu Y2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4gQWNlZSBMaW5kZW0gKGFjZWUpICZsdDthY2VlQGNpc2NvLmNvbSZndDsNCjxicj4NCjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAxLCAyMDIwIDIyOjI0PGJyPg0KPGI+VG86PC9iPiBk cmFmdC1pZXRmLWxzci1mbGV4LWFsZ29AaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGxzckBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBJUFIgQ2FsbCBvbiAmcXVvdDtJR1AgRmxleGlibGUg QWxnb3JpdGhtJnF1b3Q7IC0gZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdvLTExLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5BdXRob3JzLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+VGhlIGZv bGxvd2luZyBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIChleGNlcnB0ZWQgZnJvbQ0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9zdWJtaXQ9ZHJhZnQmYW1w O2lkPWRyYWZ0LWlldGYtbHNyLWZsZXgtYWxnbyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2lwci9zZWFyY2gvP3N1Ym1pdD1kcmFmdCZhbXA7aWQ9ZHJhZnQtaWV0Zi1sc3ItZmxleC1h bGdvPC9hPik6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMzM3IiBzdHlsZT0id2lkdGg6 MTAwMi43NXB0O2JhY2tncm91bmQ6d2hpdGU7Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlIj4NCjx0 aGVhZD4NCjx0cj4NCjx0ZCB2YWxpZ249ImJvdHRvbSIgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1ib3R0b206c29saWQgI0RERERERCAxLjVwdDtwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ RGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0iYm90dG9t IiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjREREREREIDEuNXB0O3Bh ZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JRDxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8 L3RkPg0KPHRkIHZhbGlnbj0iYm90dG9tIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRv bTpzb2xpZCAjREREREREIDEuNXB0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TdGF0ZW1l bnQ8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3RoZWFkPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9ImJhY2tncm91bmQ6 I0Y5RjlGOTtwYWRkaW5nOjIuMjVwdCAyLjI1cHQgMi4yNXB0IDIuMjVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIwMTgtMDgtMDg8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0iYmFja2dyb3VuZDoj RjlGOUY5O3BhZGRpbmc6Mi4yNXB0IDIuMjVwdCAyLjI1cHQgMi4yNXB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MzI0ODxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGOUY5Rjk7 cGFkZGluZzoyLjI1cHQgMi4yNXB0IDIuMjVwdCAyLjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2lwci8zMjQ4LyI+Q2lzY28ncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQg dG8gZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0RERERERCAxLjBwdDtwYWRkaW5nOjIuMjVwdCAyLjI1 cHQgMi4yNXB0IDIuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjIwMTktMTItMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHZh bGlnbj0idG9wIiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjREREREREIDEu MHB0O3BhZGRpbmc6Mi4yNXB0IDIuMjVwdCAyLjI1cHQgMi4yNXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MzkxMDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNEREREREQgMS4wcHQ7cGFkZGluZzoyLjI1cHQgMi4yNXB0IDIuMjVwdCAyLjI1cHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8zOTEwLyI+SHVhd2VpIFRlY2hub2xv Z2llcyBDby4sTHRkJ3MgU3RhdGVtZW50IGFib3V0IElQUiByZWxhdGVkIHRvIGRyYWZ0LWlldGYt bHNyLWZsZXgtYWxnbzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwv dGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si PkFyZSB5b3UgYXdhcmUgb2YgYW55IG90aGVyIElQUiB0aGF0IGFwcGxpZXMgdG8mbmJzcDtkcmFm dC1pZXRmLWxzci1mbGV4LWFsZ28/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5JZiBzbywgaGFzIHRoaXMg SVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj4oc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRh aWxzKS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQg YXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPnRvIHRoaXMgZW1haWwg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueTwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5y ZWxldmFudCBJUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTFNSIFdH IG1haWxpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjpibGFjayI+bGlzdC4qIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRo ZSBuZXh0IHN0YWdlIHVudGlsIGE8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+cmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJv bSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5JZiB5b3Ug YXJlIG9uIHRoZSBMU1IgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0 aG9yIG9yPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPmNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQg b25seSBpZiB5b3UgYXJlIGF3YXJlIG9mPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPmFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBi ZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkFjZWU8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_DM5PR11MB12890008E0938DC72569BF28D00B0DM5PR11MB1289namp_-- From nobody Thu Oct 8 06:37:09 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC3A3A0BA6; Thu, 8 Oct 2020 06:37:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <160216422471.2885.16929963446344941714@ietfa.amsl.com> Date: Thu, 08 Oct 2020 06:37:04 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-11.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 13:37:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Extension to Support Segment Routing over IPv6 Dataplane Authors : Peter Psenak Clarence Filsfils Ahmed Bashandy Bruno Decraene Zhibo Hu Filename : draft-ietf-lsr-isis-srv6-extensions-11.txt Pages : 25 Date : 2020-10-08 Abstract: Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-11 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-srv6-extensions-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-srv6-extensions-11 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 Oct 8 06:38:22 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55173A02BC; Thu, 8 Oct 2020 06:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8zVsCzZWtWu; Thu, 8 Oct 2020 06:38:17 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EAAC3A0DDD; Thu, 8 Oct 2020 06:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4956; q=dns/txt; s=iport; t=1602164288; x=1603373888; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=G4LLWEN3M2AgcnoLc2YdWIR7GBh+z04leLJFYiQKPYE=; b=g10XFEBRP6Yvl1oz/Sp1m4cUAyhdUKEuIVSf2+HuXV71Mol9r35ISdbL KJsCYNS0KesqQSsn9Kk4GwvH5a0+RYQK5ov1FBYj3t5e7Fxm9ZF2pMtLS PiYJwIoFmki72RIsJXRqDbjyH26Sd0gyjBmdrS20MbMm60y7dcNjMJQza s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQD+FH9f/xbLJq1gGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBT4F7gR9VATIshD2JAodqCCaaPYFpCwEBAQ8YCww?= =?us-ascii?q?EAQGESgKCCyY4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQECAQEBIQQRNgs?= =?us-ascii?q?QCxgCAiYCAicwBgEMBgIBAYMiAYJcIA+oJnZ/M4RPQUSDTIE8BoEOKokhhC2?= =?us-ascii?q?BQT+BEAEBJgyCXT6CXAEBAgEBgUGDMYJgBJwEikGRFIJygxSFbIZaiwEFBwM?= =?us-ascii?q?fgxOKBYUWjwGTGoF6iHaVVIFrI4FXMxoIGxU7gmlQGQ2OKxeBAgEJh1aFRD8?= =?us-ascii?q?DMAI1AgYKAQEDCY5IAQE?= X-IronPort-AV: E=Sophos;i="5.77,350,1596499200"; d="scan'208";a="30200436" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2020 13:38:04 +0000 Received: from [10.147.24.38] ([10.147.24.38]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 098Dc4oH006734; Thu, 8 Oct 2020 13:38:04 GMT To: chopps@chopps.org, Peter Psenak Cc: draft-ietf-lsr-isis-srv6-extensions@ietf.org, lsr@ietf.org References: From: Peter Psenak Message-ID: <4794a984-38fe-0a85-9622-fb62d12bdb31@cisco.com> Date: Thu, 8 Oct 2020 15:38:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.147.24.38, [10.147.24.38] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Lsr] Pre-writeup review comments X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 13:38:20 -0000 Hi Chris, please see inline: On 02/10/2020 12:32, Christian Hoppsprotocol= application/pgp-signature wrote: > Thanks for the update, a couple issues remain. > > [ ] 7.1 and 8.1 > > The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" are > defined differently (and probably incorrectly) than the other reserved bits. > Reserved bits "MUST" be set to zero, not "SHOULD", I believe. fixed. > > [ ] 11. Implementation Status > > I know you mentioned that the section should be removed, but how about adding a note to the editor in the next revision e.g., "RFC Ed.: Please remove this section prior to publication"? done > > [ ] 12.5. Sub-Sub-TLVs for SID Sub-TLVs > > This section needs to better conform to registry creation standards (see > https://tools.ietf.org/html/rfc8126). In particular there is no guidance. I have modified the section 12.5. > > It looks like there is more discussion from Joel on this draft, so I will hold off on submission for that to resolve. I have removed the END.T in the latest version. The discussion with Joel is closed. thanks, Peter > > Thanks, > Chris. > >> On Sep 23, 2020, at 4:36 PM, Peter Psenak wrote: >> >> Hi Chris, >> >> thanks for your comments. >> >> Please see inline (##PP): >> >> On 18/09/2020 16:08, Christian Hoppsprotocol= application/pgp-signature wrote: >>> During my review and while doing the Shepherd writeup for https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I came up with the following comments: >>> 4.3 - Maximum H.Encaps MSD Type: >>> - what is the default if not advertised? >> >> ##PP >> added "or no value is advertised" as for other MSD types. >> >>> 6. Advertising Anycast Property >>> Should "Locator that is advertised..." be: >>> "An SRv6 Locator that is advertised..."? >>> or: >>> "A prefix/SRv6 Locator that is advertised..."? >> >> ##PP >> fixed. >> >>> 7.1 SRv6 Locator TLV Format >>> The R fields and their handling, are not defined. >> >> ##PP >> added >> >> >>> 8. Advertising SRv6 Adjacency SIDs >>> "must be" "in order to be correctly applied" -> "are" and ""? >> >> ##PP >> I replaced with: >> >> Certain SRv6 Endpoint behaviors [I-D.ietf-spring-srv6-network-programming] are associated with a particular adjacency. >> >> >>> 8.1. SRv6 End.X SID sub-TLV >>> "Other bits" -> "Reserved bits" -- labels should match >> >> ##PP >> fixed. >> >>> 8.2. SRv6 LAN End.X SID sub-TLV >>> I'm sympathetic to Bruno's comment, and so I think it would be better to say: >>> Diagram: "System ID (1-6 octets)" and in text: >>> "6 octets" -> "System ID: 1-6 octets" >>> I see no reason to mess with this even if the commonly-implemented value is 6 at >>> this point. IS-IS implementations that only support 6 octets are free to only >>> support 6 in this sub-TLV as well. They won't be talking with other IS-IS >>> routers that are configured to have a non-6 octet system ID value. What other >>> extension RFCs may or may-not do WRT this doesn't really matter I think. >> >> ##PP >> I have updated the text to match what is being used in RFC8667, section 2.2.2 >> >> >>> "Other bits" -> "Reserved bits" -- labels should match >> >> ##PP >> fixed >> >>> 11. Implementation Status >>> Does this section need a "RFC Ed.: Please Remove prior to publications"? It >>> seems pretty wrong to document current status of implementations permanently in >>> an Standards Track RFC. >> >> ##PP >> yes this section will be removed prior to publication. This is a standard procedure we follow. >> >>> 12. IANA Considerations >>> An odd space between "sub- TLV". >> >> ##PP >> fixed >> >>> 12.5. Sub-Sub-TLVs for SID Sub-TLVs >>> This section needs to better conform to registry creation standards (see >>> https://tools.ietf.org/html/rfc8126). >> >> ##PP >> I updated the IANA section format similar to RFC8667. >> >> >>> ID-NITS: >>> There are 19 instances of too long lines in the document, the longest one >>> being 5 characters in excess of 72. >> >> ##PP >> fixed. >> >>> References: >>> Normative: >>> Published: RFC 8754 draft-6man-segment-routing-header >> >> ##PP >> fixed. >> >> >>> Out of date reference: [I-D.ietf-6man-spring-srv6-oam] >>> Out of date reference: [I-D.ietf-spring-srv6-network-programming] >> >> ##PP >> Whenever the new version of draft-ietf-lsr-isis-srv6-extension is published it picks the latest version, but as these drafts keep changing the reference may get out of date quickly. >> >> >> >>> Informative: >>> Published: RFC 8402 draft-ietf-spring-segment-routing >> >> ##PP >> fixed >> >> thanks, >> Peter >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > > From nobody Thu Oct 8 08:00:47 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3103A0B56; Thu, 8 Oct 2020 08:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 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, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUedGWfnvaT3; Thu, 8 Oct 2020 08:00:43 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1973A096C; Thu, 8 Oct 2020 08:00:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4C6ZBz4gLtz1nyBg; Thu, 8 Oct 2020 08:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1602169243; bh=dCnDcSyjse5yPvtIchdb+mk5Je2vgIMA49OH0kBT1ZE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ZwGQGvgPHyiiGswLnVFmrX6PfLNY9zmrGxejCb29xkvERJ0x2ZEYVRx4OnFR1insa Td6GB2iOnbAj8GpsiW7WOHPmMT1MxRgp33ZXGHYISm6zG9m91U4Ro2blTa2dXMaSu7 mO9AbY9E4Cx6ORj+OGR1fi2fbGzJgeSvzLooluq0= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4C6ZBy6fg3z1nvn7; Thu, 8 Oct 2020 08:00:42 -0700 (PDT) To: Peter Psenak , chopps@chopps.org Cc: lsr@ietf.org, draft-ietf-lsr-isis-srv6-extensions@ietf.org References: <4794a984-38fe-0a85-9622-fb62d12bdb31@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 8 Oct 2020 11:00:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <4794a984-38fe-0a85-9622-fb62d12bdb31@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Lsr] Pre-writeup review comments X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 15:00:46 -0000 Just to confirm, yes, that change Peter has made removing END.T resolves my concerns. Thanks, Joel On 10/8/2020 9:38 AM, Peter Psenak wrote: > Hi Chris, > > please see inline: > > On 02/10/2020 12:32, Christian Hoppsprotocol= application/pgp-signature > wrote: >> Thanks for the update, a couple issues remain. >> >> [ ] 7.1 and 8.1 >> >> The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID sub-TLV" are >> defined differently (and probably incorrectly) than the other reserved >> bits. >> Reserved bits "MUST" be set to zero, not "SHOULD", I believe. > > fixed. > >> >> [ ] 11.  Implementation Status >> >> I know you mentioned that the section should be removed, but how about >> adding a note to the editor in the next revision e.g., "RFC Ed.: >> Please remove this section prior to publication"? > > done > >> >> [ ] 12.5.  Sub-Sub-TLVs for SID Sub-TLVs >> >> This section needs to better conform to registry creation standards (see >> https://tools.ietf.org/html/rfc8126). In particular there is no guidance. > > I have modified the section 12.5. > > >> >> It looks like there is more discussion from Joel on this draft, so I >> will hold off on submission for that to resolve. > > I have removed the END.T in the latest version. The discussion with Joel > is closed. > > thanks, > Peter > >> >> Thanks, >> Chris. >> >>> On Sep 23, 2020, at 4:36 PM, Peter Psenak >>> wrote: >>> >>> Hi Chris, >>> >>> thanks for your comments. >>> >>> Please see inline (##PP): >>> >>> On 18/09/2020 16:08, Christian Hoppsprotocol= >>> application/pgp-signature wrote: >>>> During my review and while doing the Shepherd writeup for >>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I >>>> came up with the following comments: >>>> 4.3 - Maximum H.Encaps MSD Type: >>>>    - what is the default if not advertised? >>> >>> ##PP >>> added "or no value is advertised" as for other MSD types. >>> >>>> 6.  Advertising Anycast Property >>>> Should "Locator that is advertised..." be: >>>>    "An SRv6 Locator that is advertised..."? >>>> or: >>>>    "A prefix/SRv6 Locator that is advertised..."? >>> >>> ##PP >>> fixed. >>> >>>> 7.1 SRv6 Locator TLV Format >>>> The R fields and their handling, are not defined. >>> >>> ##PP >>> added >>> >>> >>>> 8.  Advertising SRv6 Adjacency SIDs >>>> "must be" "in order to be correctly applied" -> "are" and ""? >>> >>> ##PP >>> I replaced with: >>> >>> Certain SRv6 Endpoint behaviors >>> [I-D.ietf-spring-srv6-network-programming] are associated with a >>> particular adjacency. >>> >>> >>>> 8.1.  SRv6 End.X SID sub-TLV >>>> "Other bits" -> "Reserved bits" -- labels should match >>> >>> ##PP >>> fixed. >>> >>>> 8.2.  SRv6 LAN End.X SID sub-TLV >>>> I'm sympathetic to Bruno's comment, and so I think it would be >>>> better to say: >>>> Diagram: "System ID (1-6 octets)" and in text: >>>> "6 octets" -> "System ID: 1-6 octets" >>>> I see no reason to mess with this even if the commonly-implemented >>>> value is 6 at >>>> this point. IS-IS implementations that only support 6 octets are >>>> free to only >>>> support 6 in this sub-TLV as well. They won't be talking with other >>>> IS-IS >>>> routers that are configured to have a non-6 octet system ID value. >>>> What other >>>> extension RFCs may or may-not do WRT this doesn't really matter I >>>> think. >>> >>> ##PP >>> I have updated the text to match what is being used in RFC8667, >>> section 2.2.2 >>> >>> >>>> "Other bits" -> "Reserved bits" -- labels should match >>> >>> ##PP >>> fixed >>> >>>> 11.  Implementation Status >>>> Does this section need a "RFC Ed.: Please Remove prior to >>>> publications"? It >>>> seems pretty wrong to document current status of implementations >>>> permanently in >>>> an Standards Track RFC. >>> >>> ##PP >>> yes this section will be removed prior to publication. This is a >>> standard procedure we follow. >>> >>>> 12. IANA Considerations >>>> An odd space between "sub- TLV". >>> >>> ##PP >>> fixed >>> >>>> 12.5.  Sub-Sub-TLVs for SID Sub-TLVs >>>> This section needs to better conform to registry creation standards >>>> (see >>>> https://tools.ietf.org/html/rfc8126). >>> >>> ##PP >>> I updated the IANA section format similar to RFC8667. >>> >>> >>>> ID-NITS: >>>>    There are 19 instances of too long lines in the document, the >>>> longest one >>>>    being 5 characters in excess of 72. >>> >>> ##PP >>> fixed. >>> >>>> References: >>>>    Normative: >>>>      Published: RFC 8754 draft-6man-segment-routing-header >>> >>> ##PP >>> fixed. >>> >>> >>>>      Out of date reference: [I-D.ietf-6man-spring-srv6-oam] >>>>      Out of date reference: [I-D.ietf-spring-srv6-network-programming] >>> >>> ##PP >>> Whenever the new version of draft-ietf-lsr-isis-srv6-extension is >>> published it picks the latest version, but as these drafts keep >>> changing the reference may get out of date quickly. >>> >>> >>> >>>>    Informative: >>>>      Published: RFC 8402 draft-ietf-spring-segment-routing >>> >>> ##PP >>> fixed >>> >>> thanks, >>> Peter >>> >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >>> >> >> > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Thu Oct 8 08:11:21 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EB63A0AD6; Thu, 8 Oct 2020 08:11:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Hopps via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Cc: chopps@chopps.org, iesg-secretary@ietf.org, Christian Hopps , lsr@ietf.org, lsr-chairs@ietf.org Message-ID: <160216987927.6669.3181438825187905963@ietfa.amsl.com> Date: Thu, 08 Oct 2020 08:11:19 -0700 Archived-At: Subject: [Lsr] Publication has been requested for draft-ietf-lsr-isis-srv6-extensions-11 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 15:11:19 -0000 Christian Hopps has requested publication of draft-ietf-lsr-isis-srv6-extensions-11 as Proposed Standard on behalf of the LSR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ From nobody Thu Oct 8 08:18:40 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920973A0E6F; Thu, 8 Oct 2020 08:18:36 -0700 (PDT) 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=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 KJ2qxaHXiYUq; Thu, 8 Oct 2020 08:18:31 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BCA4F3A0A70; Thu, 8 Oct 2020 08:18:25 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0AB1F61671; Thu, 8 Oct 2020 15:18:24 +0000 (UTC) From: Christian Hopps Message-Id: <565C0708-CAC6-485F-B1C8-5D63EA849372@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_C61A757E-D885-44BC-977B-8F5C60EB02A9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 8 Oct 2020 11:18:23 -0400 In-Reply-To: Cc: Christian Hopps , Peter Psenak , lsr@ietf.org, draft-ietf-lsr-isis-srv6-extensions@ietf.org To: "Joel M. Halpern" References: <4794a984-38fe-0a85-9622-fb62d12bdb31@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Lsr] WG last call complete draft-ietf-lsr-isis-srv6-extensions-11 [Re: Pre-writeup review comments] X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 15:18:38 -0000 --Apple-Mail=_C61A757E-D885-44BC-977B-8F5C60EB02A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Joel, Peter, et al. The WG last call is now complete (it was mainly being held during the = appeal on the base document, and was ready a while ago). The document = improved in the meantime which is great. I have completed the write-up and the document has been submitted to the = IESG for publication. Thanks, Chris. > On Oct 8, 2020, at 11:00 AM, Joel M. Halpern = wrote: >=20 > Just to confirm, yes, that change Peter has made removing END.T = resolves my concerns. > Thanks, > Joel >=20 > On 10/8/2020 9:38 AM, Peter Psenak wrote: >> Hi Chris, >> please see inline: >> On 02/10/2020 12:32, Christian Hoppsprotocol=3D = application/pgp-signature wrote: >>> Thanks for the update, a couple issues remain. >>>=20 >>> [ ] 7.1 and 8.1 >>>=20 >>> The reserved bits for "SRv6 Locator TLV" and "SRv6 End.X SID = sub-TLV" are >>> defined differently (and probably incorrectly) than the other = reserved bits. >>> Reserved bits "MUST" be set to zero, not "SHOULD", I believe. >> fixed. >>>=20 >>> [ ] 11. Implementation Status >>>=20 >>> I know you mentioned that the section should be removed, but how = about adding a note to the editor in the next revision e.g., "RFC Ed.: = Please remove this section prior to publication"? >> done >>>=20 >>> [ ] 12.5. Sub-Sub-TLVs for SID Sub-TLVs >>>=20 >>> This section needs to better conform to registry creation standards = (see >>> https://tools.ietf.org/html/rfc8126). In particular there is no = guidance. >> I have modified the section 12.5. >>>=20 >>> It looks like there is more discussion from Joel on this draft, so I = will hold off on submission for that to resolve. >> I have removed the END.T in the latest version. The discussion with = Joel is closed. >> thanks, >> Peter >>>=20 >>> Thanks, >>> Chris. >>>=20 >>>> On Sep 23, 2020, at 4:36 PM, Peter Psenak = wrote: >>>>=20 >>>> Hi Chris, >>>>=20 >>>> thanks for your comments. >>>>=20 >>>> Please see inline (##PP): >>>>=20 >>>> On 18/09/2020 16:08, Christian Hoppsprotocol=3D = application/pgp-signature wrote: >>>>> During my review and while doing the Shepherd writeup for = https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ I = came up with the following comments: >>>>> 4.3 - Maximum H.Encaps MSD Type: >>>>> - what is the default if not advertised? >>>>=20 >>>> ##PP >>>> added "or no value is advertised" as for other MSD types. >>>>=20 >>>>> 6. Advertising Anycast Property >>>>> Should "Locator that is advertised..." be: >>>>> "An SRv6 Locator that is advertised..."? >>>>> or: >>>>> "A prefix/SRv6 Locator that is advertised..."? >>>>=20 >>>> ##PP >>>> fixed. >>>>=20 >>>>> 7.1 SRv6 Locator TLV Format >>>>> The R fields and their handling, are not defined. >>>>=20 >>>> ##PP >>>> added >>>>=20 >>>>=20 >>>>> 8. Advertising SRv6 Adjacency SIDs >>>>> "must be" "in order to be correctly applied" -> "are" and ""? >>>>=20 >>>> ##PP >>>> I replaced with: >>>>=20 >>>> Certain SRv6 Endpoint behaviors = [I-D.ietf-spring-srv6-network-programming] are associated with a = particular adjacency. >>>>=20 >>>>=20 >>>>> 8.1. SRv6 End.X SID sub-TLV >>>>> "Other bits" -> "Reserved bits" -- labels should match >>>>=20 >>>> ##PP >>>> fixed. >>>>=20 >>>>> 8.2. SRv6 LAN End.X SID sub-TLV >>>>> I'm sympathetic to Bruno's comment, and so I think it would be = better to say: >>>>> Diagram: "System ID (1-6 octets)" and in text: >>>>> "6 octets" -> "System ID: 1-6 octets" >>>>> I see no reason to mess with this even if the commonly-implemented = value is 6 at >>>>> this point. IS-IS implementations that only support 6 octets are = free to only >>>>> support 6 in this sub-TLV as well. They won't be talking with = other IS-IS >>>>> routers that are configured to have a non-6 octet system ID value. = What other >>>>> extension RFCs may or may-not do WRT this doesn't really matter I = think. >>>>=20 >>>> ##PP >>>> I have updated the text to match what is being used in RFC8667, = section 2.2.2 >>>>=20 >>>>=20 >>>>> "Other bits" -> "Reserved bits" -- labels should match >>>>=20 >>>> ##PP >>>> fixed >>>>=20 >>>>> 11. Implementation Status >>>>> Does this section need a "RFC Ed.: Please Remove prior to = publications"? It >>>>> seems pretty wrong to document current status of implementations = permanently in >>>>> an Standards Track RFC. >>>>=20 >>>> ##PP >>>> yes this section will be removed prior to publication. This is a = standard procedure we follow. >>>>=20 >>>>> 12. IANA Considerations >>>>> An odd space between "sub- TLV". >>>>=20 >>>> ##PP >>>> fixed >>>>=20 >>>>> 12.5. Sub-Sub-TLVs for SID Sub-TLVs >>>>> This section needs to better conform to registry creation = standards (see >>>>> https://tools.ietf.org/html/rfc8126). >>>>=20 >>>> ##PP >>>> I updated the IANA section format similar to RFC8667. >>>>=20 >>>>=20 >>>>> ID-NITS: >>>>> There are 19 instances of too long lines in the document, the = longest one >>>>> being 5 characters in excess of 72. >>>>=20 >>>> ##PP >>>> fixed. >>>>=20 >>>>> References: >>>>> Normative: >>>>> Published: RFC 8754 draft-6man-segment-routing-header >>>>=20 >>>> ##PP >>>> fixed. >>>>=20 >>>>=20 >>>>> Out of date reference: [I-D.ietf-6man-spring-srv6-oam] >>>>> Out of date reference: = [I-D.ietf-spring-srv6-network-programming] >>>>=20 >>>> ##PP >>>> Whenever the new version of draft-ietf-lsr-isis-srv6-extension is = published it picks the latest version, but as these drafts keep changing = the reference may get out of date quickly. >>>>=20 >>>>=20 >>>>=20 >>>>> Informative: >>>>> Published: RFC 8402 draft-ietf-spring-segment-routing >>>>=20 >>>> ##PP >>>> fixed >>>>=20 >>>> thanks, >>>> Peter >>>>=20 >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >>>>=20 >>>=20 >>>=20 >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr --Apple-Mail=_C61A757E-D885-44BC-977B-8F5C60EB02A9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl9/Lb8ACgkQLh2DDte4 MCW6Sw//QafPSMPe4n9fgWq3g4AtGOusyxUZ0IPjk9XtXcrY5l2auI50NXeZ6n9A zwKD5B65/PcQquApeOedxv0DE7P+JPu8Ou151qgyM6mdP2Tha6YobmhOApTkh/3x aOGXZH5vfUNf0c2qCgiH2y2FsRFpDPP4V8N3Op4JDUVME7pMSWius3M9gmO4chUh joujanod+w21l98ERkZTBkjn3G+mmJdma+R4T/ty/SrOzZiipIZs9lrMoYCurDZL gC2OeAnqPL3MeToChI5ygGZkMCdvVSvpi00qsKkgO9xcaKDwT5P+PE76ZW2hJqpE 9wBKX90zucle9lbVIWFHtt4XYoZmLAdGYBop1UmrbjzimNx/K2CCNcF8XRDuCMv7 VRNIUAf5kZQh8Z0GB2PadCI8S9LkVgAcERWbO610PyupcCkQFj0naxN6ZaissRtG l4mWlpuBDhxoqOeZcwQgSvcUa0H2AO9zzNLGz8nrhDiCMP8jPPTsBvnr5Z3/aOAW wHH4y8epkm9oUBiPrwtlwG3hJXXoVYqct6BCgplALL/0jT7EHWzLGL3P28+R8GDh QDgLXI48sd8Hnfb5aTJERqv8HDKhM+GDIUaMobvKkgQjhYm7WP+0kABfRysckeMW J85mrRc32aKupInMhOK7sEU3ncv78T81m5EDUaMorBPPrGzvOw4= =CwKB -----END PGP SIGNATURE----- --Apple-Mail=_C61A757E-D885-44BC-977B-8F5C60EB02A9-- From nobody Thu Oct 8 19:59:11 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E023A12B6 for ; Thu, 8 Oct 2020 19:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 aXv0UFJoZ8Cv for ; Thu, 8 Oct 2020 19:59:07 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641723A12C4 for ; Thu, 8 Oct 2020 19:59:07 -0700 (PDT) Received: from lhreml718-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 1A276E9291CF1A8F47F5; Fri, 9 Oct 2020 03:59:06 +0100 (IST) Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Fri, 9 Oct 2020 03:59:05 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Fri, 9 Oct 2020 10:59:03 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Fri, 9 Oct 2020 10:59:03 +0800 From: "Dongjie (Jimmy)" To: Ron Bonica , Yingzhen Qu , Peter Psenak , Gyan Mishra CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAESbICAACKHAIAA7E2AgADTYwCAAWy/gIAAAz6AgAA7sgCAAOLhAIAAi8SAgAAopgCAA1loEA== Date: Fri, 9 Oct 2020 02:59:03 +0000 Message-ID: <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 02:59:10 -0000 SGkgUm9uLCANCg0KVGhhbmtzIGZvciBleHBsYWluaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4g SVAgRmxleC1BbGdvIGFuZCBTUiBGbGV4LWFsZ28uIEFzIHlvdSBzYWlkLCB0aGUgbWFqb3IgZGlm ZmVyZW5jZSBpcyB0aGUgZGF0YSBwbGFuZS4NCg0KSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3Jy ZWN0LCBmb3Igb25lIEZsZXgtQWxnbyB0byBiZSB1c2VkIGNvcnJlY3RseSwgdGhlIHNldCBvZiBu b2RlcyBuZWVkIHRvIGFwcGx5IGNvbnNpc3RlbnQgY29uc3RyYWludHMgaW4gY29tcHV0YXRpb24s IGFuZCBiaW5kIHRoZSBGQUQgdG8gdGhlIHNhbWUgZGF0YSBwbGFuZS4NCg0KSXMgaXQgcG9zc2li bGUgdGhhdCBkaWZmZXJlbnQgbm9kZXMgbWF5IHVzZSB0aGUgc2FtZSBGbGV4LUFsZ28gd2l0aCBk aWZmZXJlbnQgZGF0YSBwbGFuZSwgZS5nLiBzb21lIHdpdGggU1ItTVBMUywgc29tZSB3aXRoIFNS djYsIGFuZCBzb21lIHdpdGggcHVyZSBJUCBldGMuLCBvciBlYWNoIEZsZXgtQWxnbyBpcyBhbHdh eXMgYXNzb2NpYXRlZCB3aXRoIG9ubHkgb25lIGRhdGEgcGxhbmU/IEluIHRoZSBmb3JtZXIgY2Fz ZSwgc2hvdWxkIHRoZSBmbGV4LWFsZ28gZGVmaW5pdGlvbiBhbHNvIGluZGljYXRlIHRoZSBkYXRh IHBsYW5lKHMpIHRvIGJlIHVzZWQgd2l0aCB0aGUgZmxleC1hbGdvPw0KDQpCZXN0IHJlZ2FyZHMs DQpKaWUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMc3IgW21haWx0 bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBCb25pY2ENCj4gU2VudDog U3VuZGF5LCBPY3RvYmVyIDQsIDIwMjAgNDozNCBBTQ0KPiBUbzogWWluZ3poZW4gUXUgPHlpbmd6 aGVuLnF1QGZ1dHVyZXdlaS5jb20+OyBQZXRlciBQc2VuYWsNCj4gPHBwc2VuYWtAY2lzY28uY29t PjsgR3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT4NCj4gQ2M6IGxzckBpZXRmLm9y ZzsgSmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+DQo+IFN1YmplY3Q6IFJl OiBbTHNyXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1ib25pY2Et bHNyLWlwLWZsZXhhbGdvLTAwLnR4dA0KPiANCj4gSGkgWWluZ3poZW4sDQo+IA0KPiBJUCBGbGV4 aWJsZSBBbGdvcml0aG1zIGFyZSBsaWtlIFNSIEZsZXhpYmxlIEFsZ29yaXRobXMgaW4gdGhlIGZv bGxvd2luZyByZXNwZWN0czoNCj4gDQo+IC0gTGlua3MgaGF2ZSBJR1AgbWV0cmljcywgVEUgbWV0 cmljcywgZGVsYXkgbWV0cmljcyBhbmQgYWRtaW5pc3RyYXRpdmUgY29sb3JzDQo+IC0gRkFEcyBk ZWZpbmUgRmxleGlibGUgQWxnb3JpdGhtcw0KPiANCj4gTW9yZSBzcGVjaWZpY2FsbHksIHRoZSBG QUQ6DQo+IA0KPiAtIEluZGljYXRlcyB3aGljaCBtZXRyaWMgdHlwZSB0aGUgRmxleGlibGUgQWxn b3JpdGhtIHVzZXMNCj4gLSBTcGVjaWZpZXMgY29uc3RyYWludHMgaW4gdGVybXMgb2YgbGluayBj b2xvcnMgdGhhdCBhcmUgaW5jbHVkZWQgb3IgZXhjbHVkZWQgZnJvbQ0KPiB0aGUgRmxleGlibGUg QWxnb3JpdGhtLg0KPiANCj4gVGhlIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgYmV0d2VlbiBJUCBG bGV4aWJsZSBBbGdvcml0aG1zIGFuZCBTUiBGbGV4aWJsZQ0KPiBBbGdvcml0aG1zIGlzOg0KPiAN Cj4gLSBTUiBGbGV4aWJsZSBBbGdvcml0aG1zIGJpbmQgRkFEcyB0byBwcmVmaXggU0lEcyBvciBT UnY2IGxvY2F0b3JzDQo+IC0gSVAgRmxleGlibGUgQWxnb3JpdGhtcyBiaW5kIEZBRHMgdG8gSVB2 NCBvciBJUHY2IGFkZHJlc3Nlcy4NCj4gDQo+IFNvLCBJUCBGbGV4aWJsZSBBbGdvcml0aG1zIGNh biBiZSBkZXBsb3llZCBpbiBhbnkgSVAgbmV0d29yaywgZXZlbiBpbiB0aGUNCj4gYWJzZW5jZSBv ZiBTUi4NCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24N Cj4gDQo+IA0KPiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBZaW5nemhlbiBRdSA8eWluZ3poZW4ucXVAZnV0dXJld2Vp LmNvbT4NCj4gU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMywgMjAyMCAyOjA4IFBNDQo+IFRvOiBQ ZXRlciBQc2VuYWsgPHBwc2VuYWtAY2lzY28uY29tPjsgR3lhbiBNaXNocmENCj4gPGhheWFidXNh Z3NtQGdtYWlsLmNvbT47IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+DQo+IENjOiBs c3JAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPg0KPiBT dWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJh ZnQtYm9uaWNhLWxzci1pcC1mbGV4YWxnby0wMC50eHQNCj4gDQo+IFtFeHRlcm5hbCBFbWFpbC4g QmUgY2F1dGlvdXMgb2YgY29udGVudF0NCj4gDQo+IA0KPiBIaSBQZXRlciwNCj4gDQo+IFVzaW5n IGZsZXgtYWxnbywgYSBTUnY2IGxvY2F0b3IgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHNpbmds ZSBhbGdvLCB3aGljaA0KPiBtZWFucyBhbiBJUHY2IG9yIElQdjQgYWRkcmVzcyBjYW4gYWxzbyBi ZSBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUgYWxnby4gU28gbXkNCj4gdW5kZXJzdGFuZGluZyBp cyBSb24ncyBwcm9wb3NhbCBpcyBtYWtpbmcgdGhlIGNvbmZpZ3VyYXRpb24gb2YgZmxleC1hbGdv IGVhc2llcj8NCj4gSW5zdGVhZCBvZiB1c2luZyB0aGUgZXhjbHVkZSBvciBpbmNsdWRlIGxpc3Qg eW91IGNhbiBjb25maWd1cmUgYSBsb29wYmFjaw0KPiBhZGRyZXNzIHRvIGEgZmxleC1hbGdvIGRp cmVjdGx5Pw0KPiANCj4gVGhhbmtzLA0KPiBZaW5nemhlbg0KPiANCj4g77u/T24gMTAvMy8yMCwg Mjo0NyBBTSwgIlBldGVyIFBzZW5hayIgPHBwc2VuYWtAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+ ICAgICBIaSBZaW5nemhlbiwNCj4gDQo+ICAgICBPbiAwMi8xMC8yMDIwIDIyOjE1LCBZaW5nemhl biBRdSB3cm90ZToNCj4gICAgID4gSGkgUGV0ZXIsDQo+ICAgICA+DQo+ICAgICA+IE15IHVuZGVy c3RhbmRpbmcgb2YgZmxleC1hbGdvIGlzIHRoYXQgZm9yIHRyYWZmaWMgZGVzdGluZWQgdG8gYSBw cmVmaXggb24gYQ0KPiBwYXJ0aWN1bGFyIGFsZ28sIGl0IGNhbiBvbmx5IGJlIHJvdXRlZCBvbiBy b3V0ZXJzIGJlbG9uZyB0byB0aGF0IGFsZ28sIHdoaWNoIGFsc28NCj4gbWVhbnMgb25seSByb3V0 ZXJzIGluIHRoYXQgYWxnbyBjYWxjdWxhdGVzIGhvdyB0byByZWFjaCB0aGF0IHByZWZpeCBhbmQg aW5zdGFsbA0KPiBpdCBpbnRvIHRoZSByb3V0aW5nIHRhYmxlLiBJdCBzZWVtcyB0byBtZSB0aGF0 IHVzaW5nIGZsZXgtYWxnbyAoc2VjdGlvbiAxMiBvZiB0aGUNCj4gZHJhZnQpIGl0J3MgcG9zc2li bGUgdG8gaGF2ZSBhIGxvb3BiYWNrIGFkZHJlc3MgYXNzb2NpYXRlZCB3aXRoIG9ubHkgb25lIGFs Z28sDQo+IHBsZWFzZSBjb3JyZWN0IG1lIGlmIEknbSBtaXNzaW5nIG9yIG1pc3VuZGVyc3Rvb2Qg c29tZXRoaW5nLg0KPiANCj4gICAgIHlvdSBhcmUgcmlnaHQuIFRoYXQgaXMgZXhhY3RseSB3aGF0 IGlzIGJlaW5nIGRvbmUgZm9yIGZsZXgtYWxnbyB3aXRoDQo+ICAgICBTUnY2IC0gbG9jYXRvciBp cyBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUgYWxnbyBvbmx5LiBUaGUgcHJvcG9zYWwgdXNlcw0K PiAgICAgdGhlIHNhbWUgY29uY2VwdC4NCj4gDQo+ICAgICB0aGFua3MsDQo+ICAgICBQZXRlcg0K PiANCj4gICAgID4NCj4gICAgID4gVGhhbmtzLA0KPiAgICAgPiBZaW5nemhlbg0KPiAgICAgPg0K PiAgICAgPiBPbiAxMC8yLzIwLCA5OjQzIEFNLCAiTHNyIG9uIGJlaGFsZiBvZiBQZXRlciBQc2Vu YWsiDQo+IDxsc3ItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcHBzZW5haz00MGNpc2Nv LmNvbUBkbWFyYy5pZXRmLm9yZz4NCj4gd3JvdGU6DQo+ICAgICA+DQo+ICAgICA+ICAgICAgR3lh biwNCj4gICAgID4NCj4gICAgID4gICAgICBPbiAwMi8xMC8yMDIwIDE4OjMwLCBHeWFuIE1pc2hy YSB3cm90ZToNCj4gICAgID4gICAgICA+IEFsbCwNCj4gICAgID4gICAgICA+DQo+ICAgICA+ICAg ICAgPiBXaXRoIFNSdjYgYW5kIElQIGJhc2VkIGZsZXggYWxnbyBhIGdlbmVyaWMgcXVlc3Rpb24g YXMgaXQgYXBwbGllcw0KPiB0bw0KPiAgICAgPiAgICAgID4gYm90aC4gSXMgaXQgcG9zc2libGUg dG8gaGF2ZSB3aXRoaW4gYSBzaW5nbGUgSUdQIGRvbWFpbiBkaWZmZXJlbnQNCj4gc2V0cw0KPiAg ICAgPiAgICAgID4gb2Ygbm9kZXMgb3Igc2VnbWVudHMgb2YgdGhlIG5ldHdvcmsgcnVubmluZyBk aWZmZXJlbnQNCj4gYWxnb3JpdGhtcy4NCj4gICAgID4NCj4gICAgID4gICAgICBhYnNvbHV0ZWx5 Lg0KPiAgICAgPg0KPiAgICAgPiAgICAgID4gRnJvbQ0KPiAgICAgPiAgICAgID4gYm90aCBkcmFm dHMgaXQgc291bmRzIGxpa2UgYWxsIG5vZGVzIGhhdmUgdG8gYWdyZWUgb24gc2FtZQ0KPiBhbGdv cml0aG0NCj4gICAgID4gICAgICA+IHNpbWlsYXIgdG8gY29uY2VwdCBvZiBtZXRyaWMgYW5kIHJl ZmVyZW5jZSBiYW5kd2lkdGggYWxsIGhhdmUgdG8NCj4gaGF2ZQ0KPiAgICAgPiAgICAgID4gdGhl IHNhbWUgc3R5bGUgbWV0cmljIGFuZCBwbGF5IHRvIHRoZSBzYW1lIHNoZWV0IG9mIG11c2ljLg0K PiAgICAgPg0KPiAgICAgPiAgICAgIGFsbCBwYXJ0aWNpcGF0aW5nIG5vZGVzIG5lZWQgdG8gYWdy ZWUgb24gdGhlIGRlZmluaXRpb24gb2YgdGhlDQo+IGZsZXgtYWxnbw0KPiAgICAgPiAgICAgIGFu ZCBhZHZlcnRpc2UgdGhlIHBhcnRpY2lwYXRpb24uIFRoYXQncyBpdC4NCj4gICAgID4NCj4gICAg ID4gICAgICA+IElmIHRoZXJlIHdhcw0KPiAgICAgPiAgICAgID4gYSB3YXkgdG8gdXNlIG11bHRp cGxlIGFsZ29yaXRobXMgc2ltdWx0YW5lb3VzbHkgYmFzZWQgb24gU0ZDDQo+IG9yIHNlcnZpY2Vz DQo+ICAgICA+ICAgICAgPiBhbmQgaW5zdGFudGlhdGlvbiBvZiBzcGVjaWZpYyBhbGdvcml0aG0g YmFzZWQgb24gc2VydmljZSB0byBiZQ0KPiAgICAgPiAgICAgID4gcmVuZGVyZWQuICBEb2luZyBz byB3aXRob3V0IGNhdXNpbmcgYSByb3V0aW5nIGxvb3Agb3Igc3ViDQo+IG9wdGltYWwNCj4gICAg ID4gICAgICA+IHJvdXRpbmcuDQo+ICAgICA+DQo+ICAgICA+ICAgICAgeW91IGNhbiBjZXJ0YWlu bHkgdXNlIG11bHRpcGxlIGFsZ29yaXRobXMgc2ltdWx0YW5lb3VzbHkgYW5kIHVzZQ0KPiBhbGdv DQo+ICAgICA+ICAgICAgc3BlY2lmaWMgcGF0aHMgdG8gZm9yd2FyZCBzcGVjaWZpYyB0cmFmZmlj IG92ZXIgaXQuIEhvdyB0aGF0IGlzIGRvbmUNCj4gICAgID4gICAgICBmcm9tIHRoZSBmb3J3YXJk aW5nIHBlcnNwZWN0aXZlIGRlcGVuZHMgaW4gd2hpY2ggZm9yd2FyZGluZw0KPiBwbGFuZSB5b3UN Cj4gICAgID4gICAgICB1c2UuIEZsZXgtYWxnbyBjb250cm9sIHBsYW5lIGlzIGluZGVwZW5kZW50 IG9mIHRoZSBmb3J3YXJkaW5nDQo+IHBsYW5lLg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiAg ICAgID5JIHRob3VnaHQgd2l0aCBmbGV4IGFsZ28gdGhhdCB0aGVyZSBleGlzdHMgYSBmZWF0dXJl IHRoYXQgb24NCj4gICAgID4gICAgICA+IGVhY2ggaG9wIHRoZXJlIGlzIGEgd2F5IHRvIHNwZWNp Znkgd2hpY2ggYWxnbyB0byB1c2UgaG9wIGJ5IGhvcA0KPiBzaW1pbGFyDQo+ICAgICA+ICAgICAg PiB0byBhIGhvcCBieSBob3AgcG9saWN5IGJhc2VkIHJvdXRpbmcuDQo+ICAgICA+DQo+ICAgICA+ ICAgICAgbm8sIHRoZXJlIGlzIG5vIGhvcC1ieS1ob3AgY2xhc3NpZmljYXRpb24sIHRoYXQgaXMg cHJvYmxlbWF0aWMgYW5kDQo+IGRvZXMNCj4gICAgID4gICAgICBub3Qgc2NhbGUgZm9yIGhpZ2gg c3BlZWRzLiBDbGFzc2lmaWNhdGlvbiBpcyBkb25lIGF0IHRoZSBpbmdyZXNzIG9ubHkuDQo+ICAg ICA+DQo+ICAgICA+ICAgICAgdGhhbmtzLA0KPiAgICAgPiAgICAgIFBldGVyDQo+ICAgICA+DQo+ ICAgICA+ICAgICAgPg0KPiAgICAgPg0KPiAgICAgPiAgICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICA+ICAgICAgTHNyIG1haWxpbmcgbGlz dA0KPiAgICAgPiAgICAgIExzckBpZXRmLm9yZw0KPiAgICAgPg0KPiBodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8NCj4gP3VybD1odHRwcyozQSoyRioyRnd3dy5pZXRmLm9yZyoyRm1haWxtYW4qMkZsaXN0aW5m byoyRmxzciZhbXA7ZGF0YT0wMg0KPiAqN0MwMSo3Q3lpbmd6aGVuLnF1KjQwZnV0dXJld2VpLmNv bSo3Q2ZlMDMxMjRjNmU0MTRlMDY3YzIwMDhkODY3ODENCj4gNjU0MSo3QzBmZWU4ZmYyYTNiMjQw MTg5Yzc1M2ExZDU1OTFmZWRjKjdDMSo3QzAqN0M2MzczNzMxNTI3Mzk4Ng0KPiA1MTI2JmFtcDtz ZGF0YT1XSTQ4Y0VBYW4qMkZPa0RQbVZYR3VyRUFqUEl0TkdGOXA5UERRSWxEMWlwMGcqM0QNCj4g JmFtcDtyZXNlcnZlZD0wX187SlNVbEpTVWxKU1VsSlNVbEpTVWxKUSEhTkV0NnlNYU8tZ2shWDFm UmxuOU1qaW1lSmNSDQo+IEVVRUl5ZHItOElJYnROb25YTXM4M2VvWHZSd3c2eGthUWZWVWROaDBr SzQ1MkdQLUckDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMc3IgbWFpbGluZyBsaXN0DQo+ IExzckBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xz cg0K From nobody Thu Oct 8 20:08:43 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723CC3A12D2 for ; Thu, 8 Oct 2020 20:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 2EIQCODDTwLz for ; Thu, 8 Oct 2020 20:08:37 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A6D3A12D1 for ; Thu, 8 Oct 2020 20:08:37 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 32F77473A2; Fri, 9 Oct 2020 11:08:32 +0800 (CST) From: "Aijun Wang" To: "'Acee Lindem \(acee\)'" , "'Peter Psenak \(ppsenak\)'" , "'Aijun Wang'" Cc: References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> In-Reply-To: <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> Date: Fri, 9 Oct 2020 11:08:31 +0800 Message-ID: <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01D69E2C.86634290" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIJ+mWorx9ReexromEfqpSgpX3kFwEFLd5+AaLg+ScCZ8Mz1AFBnbZFAnYY+uECbteHkajOKCew Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTU1CTh4fTB1JTEIdVkpNS0lJSklCSklOT0lVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PSI6GAw6OD8pAkwRPUIRAhAD GioaCx9VSlVKTUtJSUpJQkpIS0JNVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQU5KSk5JNwY+ X-HM-Tid: 0a750b54dcf99865kuuu32f77473a2 Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 03:08:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001D_01D69E2C.86634290 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Acee: Sorry for the previous pruned mail. Let's reply you again along your = original question. Please see inline.[WAJ] =20 -----Original Message----- = = =20 From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Acee Lindem (acee) Sent: Wednesday, September 30, 2020 7:47 PM To: Aijun Wang ; Peter Psenak (ppsenak) = ; 'Aijun Wang' Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Hi Aijun,=20 Other than your ill-conceived topology discovery heuristic [WAJ] The topology discovery heuristic is not suitable for the corner = use case when the unnumbered interface is used, as explained in = https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appe= ndix-B. If you don=E2=80=99t agree, would you like to illustrate other = non-applicable scenarios? =20 what other possible reason would there be for associating the passive = attribute with a prefix?=20 [WAJ] To know the boundary of the IGP domain. After knowing the = boundary, the controller can safely apply and check the network security = policy, the inbound traffic control policy etc. =20 Thanks, Acee =20 =EF=BB=BFOn 9/29/20, 10:39 PM, "Aijun Wang" < = wangaijun@tsinghua.org.cn> wrote: =20 Hi, Acee and Peter: Passive interface is mainly used at the edge of the network, where = the unnumbered interface will not be used.=20 And the information to flag the passive interfaces is for = positioning the area boundary, not conflict with the abstract = capabilities of the area inside. =20 =20 Best Regards =20 Aijun Wang China Telecom =20 -----Original Message----- From: lsr-bounces@ietf.org [ = mailto:lsr-bounces@ietf.org] On Behalf Of = Acee Lindem (acee) Sent: Tuesday, September 29, 2020 9:16 PM To: Peter Psenak < = ppsenak=3D40cisco.com@dmarc.ietf.org>; Aijun Wang < = wangaijun@tsinghua.org.cn>; 'Aijun = Wang' < wangaj3@chinatelecom.cn> Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Speaking as WG member: =20 Hi Aijun, Peter,=20 I agree with Peter - one of the main motivations for having areas is = to abstract the topology within the area. Now you're trying to supplant = this - one topological detail at a time with ill-conceived IGP = features. Thanks, Acee =20 On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" < = lsr-bounces@ietf.org on behalf of = ppsenak=3D40cisco.com@dmarc.ietf.org> wrote: =20 Hi Aijun, =20 On 29/09/2020 11:07, Aijun Wang wrote: > Hi, Peter: >=20 > Thanks for your comments. > 1. For BGP-LS deployment, there normally only be one router = that within the > IGP domain to report the topology information, this router = should know such > passive links which exists mainly on other border routers via = the IGP > protocol. This is main reason to extension the IGP protocol. > = 2. For the solution, normally, the link within the IGP connect two=20 ends, but > passive interface is special and not fall in this space. We = have studied the > current TLVs that for link, and find no suitable container to = append this > information. This is the reason that we select the TLVs that = associated with > Prefix. =20 if the link is unnumbered, your solution does not work. As I = said, if=20 you need a knowledge about the link, you can not advertise it as = a prefix. =20 thanks, Peter =20 =20 >=20 >>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix = LSA", which > isolate the prefix information that associated with link into = this > container, contains the stub link, local interface information = etc. Put such > attribute along with the prefix is then acceptable? >=20 >=20 > Best Regards >=20 > Aijun Wang > China Telecom >=20 > -----Original Message----- > From: lsr-bounces@ietf.org [ = mailto:lsr-bounces@ietf.org] On Behalf Of = Peter > Psenak > Sent: Tuesday, September 29, 2020 4:29 PM > To: Aijun Wang < = wangaj3@chinatelecom.cn> > Cc: lsr@ietf.org > Subject: Re: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt >=20 > Hi Aijun, >=20 > here's my comments: >=20 > The purpose of this draft is to advertise passive links. >=20 > 1. I'm not sure the problem needs to be solved by IGPs. I tend = to believe > ietf-idr-bgpls-inter-as-topology-ext is sufficient. >=20 > 2. the solution that you proposed is wrong. You are trying to = derive > topological data about the passive links from the prefix = advertisement. > This is semantically incorrect and only works under very = specific condition. > If you need to advertise a link, advertise it as a "special" > link, not as a "special" prefix. >=20 > thanks, > Peter >=20 > On 29/09/2020 03:17, Aijun Wang wrote: >> Hi, Peter: >> >> Would you like to review and give comments on the updates = version of this > draft? >> We have also added the protocol extension proposal for = OSPFv3. >> >> The update version of this draft can refer to >> = = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface >> -attribute >> Thanks in advance. >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >>> -----Original Message----- >>> From: = internet-drafts@ietf.org [ = mailto:internet-drafts@ietf.org] >>> Sent: Monday, September 28, 2020 3:17 PM >>> To: Zhibo Hu < = huzhibo@huawei.com>; Gyan Mishra >>> < = gyan.s.mishra@verizon.com>; Aijun Wang < = wangaj3@chinatelecom.cn>; >>> Gyan S. Mishra < = gyan.s.mishra@verizon.com> >>> Subject: New Version Notification for >>> draft-wang-lsr-passive-interface-attribute-04.txt >>> >>> >>> A new version of I-D, >>> draft-wang-lsr-passive-interface-attribute-04.txt >>> has been successfully submitted by Aijun Wang and posted to = the IETF >>> repository. >>> >>> Name: = draft-wang-lsr-passive-interface-attribute >>> Revision: 04 >>> Title: Passive Interface Attribute >>> Document date: 2020-09-28 >>> Group: Individual Submission >>> Pages: 7 >>> URL: >>> = = https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04. >>> txt >>> Status: >>> = = https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att >>> r >>> ibute/ >>> Htmlized: >>> = = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac >>> e >>> -attribut >>> e >>> Htmlized: >>> = = https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut >>> e >>> -04 >>> Diff: >>> = = https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-interface-at >>> t >>> ribute-04 >>> >>> Abstract: >>> This document describes the mechanism that can be used = to >>> differentiate the passive interfaces from the normal = interfaces >>> within ISIS or OSPF domain. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >> >> >> >> >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > = https://www.ietf.org/mailman/listinfo/lsr >=20 >=20 >=20 =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr =20 =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr ------=_NextPart_000_001D_01D69E2C.86634290 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, = Acee:

Sorry for the previous pruned mail. Let's reply you again = along your original question.

Please see = inline.[WAJ]

 

-----Original = Message-----=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
From: lsr-bounces@ietf.org = [mailto:lsr-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: = Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang = <wangaijun@tsinghua.org.cn>; Peter Psenak (ppsenak) = <ppsenak@cisco.com>; 'Aijun Wang' = <wangaj3@chinatelecom.cn>
Cc: lsr@ietf.org
Subject: Re: = [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Hi Aijun, =

Other = than your ill-conceived topology discovery = heuristic

[WAJ] The topology discovery heuristic is not suitable for = the corner use case when the unnumbered interface is used, as explained = in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-or= iginator-06#appendix-B. =C2=A0If you don=E2=80=99t = agree, would you like to illustrate other non-applicable = scenarios?

 

what other possible reason would there be for associating = the passive attribute with a prefix?

[WAJ] To = know the boundary of the IGP domain. After knowing the boundary, the = controller can safely apply and check the network security policy, the = inbound traffic control policy etc.

 

Thanks,

Acee

 

=EF=BB=BFOn 9/29/20, 10:39 PM, "Aijun Wang" <wangaijun@tsinghua.org.cn= > wrote:

 

=C2=A0=C2=A0=C2=A0 Hi, Acee and = Peter:

=C2=A0=C2=A0=C2=A0 Passive interface is mainly used at the = edge of the network, where the unnumbered interface will not be used. =

=C2=A0=C2=A0=C2=A0=C2=A0And the information to flag the = passive interfaces is for positioning the area boundary, not conflict = with the abstract capabilities of the area = inside.

 

 

=C2=A0=C2=A0=C2=A0 Best Regards

 

=C2=A0=C2=A0=C2=A0 Aijun = Wang

=C2=A0=C2=A0=C2=A0 China Telecom

 

=C2=A0=C2=A0=C2=A0 -----Original = Message-----

=C2=A0=C2=A0=C2=A0 From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.o= rg] On Behalf Of Acee Lindem (acee)

=C2=A0=C2=A0=C2=A0 Sent: = Tuesday, September 29, 2020 9:16 PM

=C2=A0=C2=A0=C2=A0 To: Peter = Psenak <ppsenak=3D40cisco.com@dma= rc.ietf.org>; Aijun Wang <wangaijun@tsinghua.org.cn= >; 'Aijun Wang' <wangaj3@chinatelecom.cn>

=C2=A0=C2=A0=C2=A0 Cc: lsr@ietf.org

=C2=A0=C2=A0=C2=A0 Subject: Re: [Lsr] FW: New Version = Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

=C2=A0=C2=A0=C2=A0 Speaking as = WG member:

 

=C2=A0=C2=A0=C2=A0 Hi Aijun, Peter, =

=C2=A0=C2=A0=C2=A0=C2=A0I agree with Peter - one of the = main motivations for having areas is to abstract the topology within the = area. Now you're trying to supplant this =C2=A0- one topological detail = at a time with ill-conceived IGP features.

=C2=A0=C2=A0=C2=A0 = Thanks,

=C2=A0=C2=A0=C2=A0 Acee

 

=C2=A0=C2=A0=C2=A0 On 9/29/20, = 5:15 AM, "Lsr on behalf of Peter Psenak" <lsr-bounces@ietf.org on = behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> = wrote:

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi = Aijun,

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On 29/09/2020 = 11:07, Aijun Wang wrote:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Hi, = Peter:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Thanks = for your comments.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 1. For = BGP-LS deployment, there normally only be one router that within = the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > IGP domain = to report the topology information, this router should know = such

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > passive = links which exists mainly on other border routers via the = IGP

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > protocol. = This is main reason to extension the IGP protocol. > 2. For the = solution, normally, the link within the IGP connect two =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ends, = but

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > passive = interface is special and not fall in this space. We have studied = the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > current = TLVs that for link, and find no suitable container to append = this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = information. This is the reason that we select the TLVs that associated = with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = Prefix.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if the link is = unnumbered, your solution does not work. As I said, if =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0you need a = knowledge about the link, you can not advertise it as a = prefix.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Peter

 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>From= other POV, the OSPFv3 defines now the "Intra-Area-Prefix = LSA", which

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > isolate the = prefix information that associated with link into = this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > container, = contains the stub link, local interface information etc. Put = such

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > attribute = along with the prefix is then acceptable?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Best = Regards

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Aijun = Wang

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > China = Telecom

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> = -----Original Message-----

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.o= rg] On Behalf Of Peter

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = Psenak

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Sent: = Tuesday, September 29, 2020 4:29 PM

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > To: Aijun = Wang <wangaj3@chinatelecom.cn>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Cc: lsr@ietf.org

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Subject: = Re: [Lsr] FW: New Version Notification for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = draft-wang-lsr-passive-interface-attribute-04.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Hi = Aijun,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> here's = my comments:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> The = purpose of this draft is to advertise passive = links.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> 1. I'm = not sure the problem needs to be solved by IGPs. I tend to = believe

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = ietf-idr-bgpls-inter-as-topology-ext is = sufficient.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> 2. the = solution that you proposed is wrong. You are trying to = derive

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological = data about the passive links from the prefix = advertisement.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > This is = semantically incorrect and only works under very specific = condition.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > If you need = to advertise a link, advertise it as a = "special"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > link, not = as a "special" prefix.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> = thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = Peter

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> On = 29/09/2020 03:17, Aijun Wang wrote:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Hi, = Peter:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Would = you like to review and give comments on the updates version of = this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = draft?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> We have = also added the protocol extension proposal for = OSPFv3.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> The = update version of this draft can refer to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> https://datatracker.ietf.= org/doc/html/draft-wang-lsr-passive-interface

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> = -attribute

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Thanks = in advance.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Best = Regards

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Aijun = Wang

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> China = Telecom

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = -----Original Message-----

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = From: internet-drafts@ietf.org<= /span> [mailto:internet-drafts@ie= tf.org]

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0>>> = Sent: Monday, September 28, 2020 3:17 PM

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> To: = Zhibo Hu <huzhibo@huawei.com= >; Gyan Mishra

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = <gyan.s.mishra@verizon.com= >; Aijun Wang <wangaj3@chinatelecom.cn>;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Gyan S. Mishra <gyan.s.mishra@verizon.com= >

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Subject: New Version Notification for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = draft-wang-lsr-passive-interface-attribute-04.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> A = new version of I-D,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = draft-wang-lsr-passive-interface-attribute-04.txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> has = been successfully submitted by Aijun Wang and posted to the = IETF

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = repository.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 = draft-wang-lsr-passive-interface-attribute

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Revision:=C2=A0=C2=A0 04

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Passive Interface = Attribute

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Document date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 2020-09-28

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Individual Submission

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 7

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = URL:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://www.ietf.org/id/d= raft-wang-lsr-passive-interface-attribute-04.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = txt

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Status:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://datatracker.ietf.= org/doc/draft-wang-lsr-passive-interface-att=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = r

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = ibute/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Htmlized:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://datatracker.ietf.= org/doc/html/draft-wang-lsr-passive-interfac=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = e

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = -attribut

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = e

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Htmlized:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://tools.ietf.org/ht= ml/draft-wang-lsr-passive-interface-attribut=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = e

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = -04

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Diff:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://www.ietf.org/rfcd= iff?url2=3Ddraft-wang-lsr-passive-interface-at

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = t

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = ribute-04

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Abstract:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This document describes the = mechanism that can be used to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 differentiate the passive = interfaces from the normal interfaces

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 within ISIS or OSPF = domain.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = Please note that it may take a couple of minutes from the time = of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> = submission until the htmlized version and diff are available = at

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > = tools.ietf.org.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> The = IETF Secretariat

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = >>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> = _______________________________________________

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Lsr mailing = list

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Lsr@ietf.org

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mail= man/listinfo/lsr

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> =

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = _______________________________________________

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lsr mailing = list

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lsr@ietf.org

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mail= man/listinfo/lsr

 

=C2=A0=C2=A0=C2=A0 = _______________________________________________

=C2=A0=C2=A0=C2=A0 Lsr mailing = list

=C2=A0=C2=A0=C2=A0 Lsr@ietf.org

=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mail= man/listinfo/lsr

 

 

_______________________________________________

Lsr mailing = list

Lsr@ietf.org

https://www.ietf.org/mail= man/listinfo/lsr

------=_NextPart_000_001D_01D69E2C.86634290-- From nobody Thu Oct 8 23:33:05 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950293A09CF for ; Thu, 8 Oct 2020 23:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 K6qc9aSCThzo for ; Thu, 8 Oct 2020 23:33:00 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.219]) by ietfa.amsl.com (Postfix) with ESMTP id 051A53A0846 for ; Thu, 8 Oct 2020 23:32:59 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:2168.1863574955 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-120.88.10.46?logid-55ad9888b1be4333bdfb83e70c742fdd (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 6DC5E2800A3; Fri, 9 Oct 2020 14:32:44 +0800 (CST) X-189-SAVE-TO-SEND: 44031110@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id 55ad9888b1be4333bdfb83e70c742fdd for huaimo.chen@futurewei.com; Fri Oct 9 14:32:46 2020 X-Transaction-ID: 55ad9888b1be4333bdfb83e70c742fdd X-filter-score: filter<0> X-Real-From: zhuyq8@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Sender: zhuyq8@chinatelecom.cn From: To: "'Huaimo Chen'" , References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <047be764-8203-ca46-7ee1-6f84f7bf2356@cisco.com> , In-Reply-To: Date: Fri, 9 Oct 2020 14:32:44 +0800 Message-ID: <002501d69e06$01084580$0318d080$@chinatelecom.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01D69E49.0F3F82B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGKD7LFtv7e4JvKKSLeoBEBPZfcqAF3GgshAhtpkQ0CZ2c23QJFk5K4AiG0AhkBayX8DwEyA2XiAsh2sogBxUNl4QKQWbEGAt9qosQBTy1ERgEQ2QqnAgWoeQkCXt015ak5553A Content-Language: zh-cn Archived-At: Subject: [Lsr] =?gb2312?b?u9i4tDogIGRyYWZ0LXpodS1sc3ItaXNpcy1zci12dG4t?= =?gb2312?b?ZmxleGFsZ28tMDE=?= X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 06:33:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0026_01D69E49.0F3F82B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Huaimo,=20 =20 Thanks for your review comments, please see some replies inline with = [YQ]: =20 =20 =B7=A2=BC=FE=C8=CB: Lsr =B4=FA=B1=ED Huaimo Chen =B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA10=D4=C27=C8=D5 5:57 =CA=D5=BC=FE=C8=CB: lsr@ietf.org =D6=F7=CC=E2: [Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo-01 =20 Hi Authors, =20 I have the following comments/questions on the draft. =20 In section 2 "Advertisement of SR VTN Topology Attribute",=20 for the last sentence "..., the Flex-Algo identifier could be reused=20 as the identifier of the VTN in control plane.", =20 How do you reuse the Flex-Algo identifier? [YQ] The =A1=B0reuse=A1=B1 here means to make use of the existing = Flex-Algo identifier to represent VTN, rather than defining a new identifier.=20 Does every VTN have a Flex-Algo identifier? If so, where does the Flex-Algo identifier of every VTN come from? [YQ] Yes, every VTN needs to be represented with a unique Flex-Algo identifier. The Flex-Algo identifier comes from network planning.=20 In section 3 "Advertisement of SR VTN Resource Attribute",=20 is new flag "V" (Virtual) defined in this draft as an extension to = RFC 8668? [YQ] Yes, this is an extension to RFC 8668.=20 If so, should an IANA request/action in section "IANA = Considerations"=20 be added for this extension? [YQ] Currently there is no IANA registry for the flags of L2 Bundle = Member Attributes TLV defined in RFC 8668, thus this new flag is described in = the text only. While a new registry may be created if the WG believe it is helpful.=20 If not (i.e., it is defined in another draft),=20 it is better to remove the definition of flag "V" from=20 this draft and add a reference to another draft. In this case, it seems that there is no IANA request from this = draft.=20 It would be better to change the intended status of the draft from=20 the standards track to informational.=20 [YQ] As explained above, a new flag is proposed in this document, thus = it is appropriate to make it standard track. Some nits:=20 In section 2, the second sentence of the last paragraph, should "to used" be changed to "to use"? =20 In section 3, the first sentence of the second paragraph, should "was defined to advertise" be changed to=20 "defines the advertisement of"? [YQ] Thanks for catching the nits, we will fix them in next revision.=20 =20 Best regards, Yongqing Zhu =20 Best Regards, Huaimo ------=_NextPart_000_0026_01D69E49.0F3F82B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Huaimo, =

 

Thanks for your review = comments, please see some replies inline with = [YQ]:

 <= /p>

 <= /p>

=B7=A2=BC=FE=C8=CB: Lsr <lsr-bounces@ietf.org> = =B4=FA=B1=ED = Huaimo = Chen
=B7=A2=CB=CD=CA=B1=BC=E4: 2020=C4=EA10=D4=C27=C8=D5 5:57
=CA=D5=BC=FE=C8=CB: = lsr@ietf.org
=D6=F7=CC=E2: [Lsr] = draft-zhu-lsr-isis-sr-vtn-flexalgo-01

<= /div>

 

Hi = Authors,

 

=

    I have the = following comments/questions on the = draft.

 

=

    In section 2 = "Advertisement of SR VTN Topology Attribute", =

for the last sentence "..., = the Flex-Algo identifier could be reused =

as the identifier of the VTN in = control plane.",

 

=

How do you reuse the = Flex-Algo identifier?

[YQ] The = =A1=B0reuse=A1=B1 here means to make use of the existing Flex-Algo = identifier to represent VTN, rather than defining a new identifier. =

    Does every VTN have = a Flex-Algo identifier?

    If so, where does = the Flex-Algo identifier of every VTN come = from?

[YQ] Yes, every = VTN needs to be represented with a unique Flex-Algo identifier. The = Flex-Algo identifier comes from network planning.

<= p class=3DMsoNormal>    In section 3 = "Advertisement of SR VTN Resource Attribute", =

    is new flag = "V" (Virtual) defined in this draft as an extension to RFC = 8668?

[YQ] Yes, this is = an extension to RFC 8668.

<= p class=3DMsoNormal>    If so, should an = IANA request/action in section "IANA = Considerations" 

be added for this = extension?

[YQ] Currently = there is no IANA registry for the flags of L2 Bundle Member Attributes = TLV defined in RFC 8668, thus this new flag is described in the text = only. While a new registry may be created if the WG believe it is = helpful.

<= p class=3DMsoNormal>    If not (i.e., it is = defined in another draft),

it is better to remove the = definition of flag "V" from =

this draft and add a reference to = another draft.

    In this case, it = seems that there is no IANA request from this draft. =

It would be better to change the = intended status of the draft from

the standards track to = informational.

[YQ] As explained above, a new = flag is proposed in this document, thus it is appropriate to make it = standard track.

<= p class=3DMsoNormal>Some nits: =

In section 2, the second sentence = of the last paragraph,

should "to used" be = changed to "to use"?

 

=

In section 3, the first sentence = of the second paragraph,

should "was defined to = advertise" be changed to

"defines the advertisement = of"?

  [YQ] Thanks for = catching the nits, we will fix them in next revision. =

 

Best = regards,

Yongqing = Zhu

  

=

Best = Regards,

Huaimo

=
------=_NextPart_000_0026_01D69E49.0F3F82B0-- From nobody Fri Oct 9 08:57:48 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E923A09F6 for ; Fri, 9 Oct 2020 08:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0sS4rYiwuQA for ; Fri, 9 Oct 2020 08:57:44 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1A93A09F4 for ; Fri, 9 Oct 2020 08:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7174; q=dns/txt; s=iport; t=1602259064; x=1603468664; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3EeqCAH4gZlWoUdb6yRymmXy3taILdGj6bkHad/W7qc=; b=kcqZZttgTa9rRNnXmoEyKXf4UQJTBFH/I84Vi7i0BIjbIn/HNbgXs/n4 cPrf5tYVNeQI1p/rNZWa2E15OMAaTp+6VYv0kf05hFR9XIiiTZaKRlxPJ ay5OIbl+ummn6l0lf2RT2cmm/aDDVB48k5egxKGX1ImQQNbMB6Ndgsivu k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQCZh4Bf/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgT4EAQELAYMZVQEgEiyEPYkCh2oIJooRkCyBaQsBAQEPGA0?= =?us-ascii?q?KBAEBgWyCXgKCFCY3Bg4CAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgEBASE?= =?us-ascii?q?VNgkCDAQLEQQBAQECAiMDAgIhBh8JCAYBDAYCAQGDHQQBAYJLAw4gD6hsdoE?= =?us-ascii?q?yhVSCagMKYoE8BoEOKgGNT4FBP4ERJwyCXT6CGkIBAQKBKAESAYM4gmAEkCY?= =?us-ascii?q?JglWJAZsDUoJygxSFbIxchH8FBwMfgxOKCIUYjwOTHIpwgmySbYFqJA1acDM?= =?us-ascii?q?aCBsVO4I1ATNQGQ2OKxeDToUUhUQ/AzACAQEzAgYKAQEDCY5IAQE?= X-IronPort-AV: E=Sophos;i="5.77,355,1596499200"; d="scan'208";a="30230753" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Oct 2020 15:57:39 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 099FvdvC007771; Fri, 9 Oct 2020 15:57:39 GMT To: "Dongjie (Jimmy)" , Ron Bonica , Yingzhen Qu , Gyan Mishra Cc: "lsr@ietf.org" , Jeff Tantsura References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> From: Peter Psenak Message-ID: Date: Fri, 9 Oct 2020 17:57:39 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 15:57:46 -0000 Hi Jimmy, On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > Hi Ron, > > Thanks for explaining the difference between IP Flex-Algo and SR Flex-algo. As you said, the major difference is the data plane. > > If my understanding is correct, for one Flex-Algo to be used correctly, the set of nodes need to apply consistent constraints in computation, and bind the FAD to the same data plane. > > Is it possible that different nodes may use the same Flex-Algo with different data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure IP etc., or each Flex-Algo is always associated with only one data plane? In the former case, should the flex-algo definition also indicate the data plane(s) to be used with the flex-algo? let me respond to this query, as this is not specific to Ron's draft. FAD is data plane agnostic and is used by all of them. thanks, Peter > > Best regards, > Jie > >> -----Original Message----- >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >> Sent: Sunday, October 4, 2020 4:34 AM >> To: Yingzhen Qu ; Peter Psenak >> ; Gyan Mishra >> Cc: lsr@ietf.org; Jeff Tantsura >> Subject: Re: [Lsr] FW: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> >> Hi Yingzhen, >> >> IP Flexible Algorithms are like SR Flexible Algorithms in the following respects: >> >> - Links have IGP metrics, TE metrics, delay metrics and administrative colors >> - FADs define Flexible Algorithms >> >> More specifically, the FAD: >> >> - Indicates which metric type the Flexible Algorithm uses >> - Specifies constraints in terms of link colors that are included or excluded from >> the Flexible Algorithm. >> >> The significant difference between IP Flexible Algorithms and SR Flexible >> Algorithms is: >> >> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators >> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. >> >> So, IP Flexible Algorithms can be deployed in any IP network, even in the >> absence of SR. >> >> Ron >> >> >> Juniper Business Use Only >> >> -----Original Message----- >> From: Yingzhen Qu >> Sent: Saturday, October 3, 2020 2:08 PM >> To: Peter Psenak ; Gyan Mishra >> ; Ron Bonica >> Cc: lsr@ietf.org; Jeff Tantsura >> Subject: Re: [Lsr] FW: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> >> [External Email. Be cautious of content] >> >> >> Hi Peter, >> >> Using flex-algo, a SRv6 locator can be associated with a single algo, which >> means an IPv6 or IPv4 address can also be associated with a single algo. So my >> understanding is Ron's proposal is making the configuration of flex-algo easier? >> Instead of using the exclude or include list you can configure a loopback >> address to a flex-algo directly? >> >> Thanks, >> Yingzhen >> >> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: >> >> Hi Yingzhen, >> >> On 02/10/2020 22:15, Yingzhen Qu wrote: >> > Hi Peter, >> > >> > My understanding of flex-algo is that for traffic destined to a prefix on a >> particular algo, it can only be routed on routers belong to that algo, which also >> means only routers in that algo calculates how to reach that prefix and install >> it into the routing table. It seems to me that using flex-algo (section 12 of the >> draft) it's possible to have a loopback address associated with only one algo, >> please correct me if I'm missing or misunderstood something. >> >> you are right. That is exactly what is being done for flex-algo with >> SRv6 - locator is associated with a single algo only. The proposal uses >> the same concept. >> >> thanks, >> Peter >> >> > >> > Thanks, >> > Yingzhen >> > >> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >> >> wrote: >> > >> > Gyan, >> > >> > On 02/10/2020 18:30, Gyan Mishra wrote: >> > > All, >> > > >> > > With SRv6 and IP based flex algo a generic question as it applies >> to >> > > both. Is it possible to have within a single IGP domain different >> sets >> > > of nodes or segments of the network running different >> algorithms. >> > >> > absolutely. >> > >> > > From >> > > both drafts it sounds like all nodes have to agree on same >> algorithm >> > > similar to concept of metric and reference bandwidth all have to >> have >> > > the same style metric and play to the same sheet of music. >> > >> > all participating nodes need to agree on the definition of the >> flex-algo >> > and advertise the participation. That's it. >> > >> > > If there was >> > > a way to use multiple algorithms simultaneously based on SFC >> or services >> > > and instantiation of specific algorithm based on service to be >> > > rendered. Doing so without causing a routing loop or sub >> optimal >> > > routing. >> > >> > you can certainly use multiple algorithms simultaneously and use >> algo >> > specific paths to forward specific traffic over it. How that is done >> > from the forwarding perspective depends in which forwarding >> plane you >> > use. Flex-algo control plane is independent of the forwarding >> plane. >> > >> > >> > >I thought with flex algo that there exists a feature that on >> > > each hop there is a way to specify which algo to use hop by hop >> similar >> > > to a hop by hop policy based routing. >> > >> > no, there is no hop-by-hop classification, that is problematic and >> does >> > not scale for high speeds. Classification is done at the ingress only. >> > >> > thanks, >> > Peter >> > >> > > >> > >> > _______________________________________________ >> > Lsr mailing list >> > Lsr@ietf.org >> > >> https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/ >> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data=02 >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D >> &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR >> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ >> > >> > >> > >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > From nobody Fri Oct 9 10:13:19 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FB33A0D21 for ; Fri, 9 Oct 2020 10:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (2048-bit key) header.d=juniper.net header.b=hS1YNoL1; dkim=pass (1024-bit key) header.d=juniper.net header.b=HVW/5nXr 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 1Ko9CuUyvfF1 for ; Fri, 9 Oct 2020 10:13:15 -0700 (PDT) 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 AF8043A0D22 for ; Fri, 9 Oct 2020 10:13:15 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 099HCDmN013473; Fri, 9 Oct 2020 10:12:43 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=UlZtxE4eQqOwdmbNWK/CaNC2zRn7E3suZCq9GNx/prE=; b=hS1YNoL144iEPKOUf/qWlWL5DxcpCduy4Bvh4qKgUE2Gp0+eN999zCHOtZ6Nis6rzDmC TIq7Djsry8tBVfJCcQD+VRRrXN2FKWa4OsT5wZCOCDnyqoJjTkUwuHHWY4pc2mlWtrMl PI/d0ueqU7KhHKNRltfP2AaTmfLOvky/Q4W+bJ0/+dlSXWnSVx3yXvzemlX4DC0KTz3X S3gYKfsdsooNXe8SM+6/DsGHvYLQhwyhhFN9ONy61NBcVH22EIwA3VPRZ3pbk0FYcBON ediEmNBJR2D2Lk6DxcAZVibBWepURVQXt1rVrSRIVPRhpOrR9ajovOJakwvlBviu+4dR GQ== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2177.outbound.protection.outlook.com [104.47.59.177]) by mx0a-00273201.pphosted.com with ESMTP id 3429kx9qsw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Oct 2020 10:12:43 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ggz/qlkShNNtHQsuKkKPqa2Brg9q4Xu1G5XTq1pR9P7q4tle8asnOIeEMUmav+qgkKFgjpgQDPHClx6Qe/Z88KMXjVYn8c0ehjomr2k1aFY49gatV5VyVOT82TaXqLpVqT3kvIZOnMPG44pmuJh3YOlbZ5Pfrm+flDegBoUyJNBkdcDKvo7KIykrQY/CfGwdc2qPbIYQ3WlI93ZvzF0T/V88d9aWgqWr2yvzct2c0lB9J5L84rZfRCA7XbIX96gyp9kDVT7VAdVerVrDqpBEw4GK5ORcf8hIAu5JMtlExXfhp1TjVjDwRRcLoD5dMaac6GyXkCf/gk/c7Vgm6hCswQ== 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=UlZtxE4eQqOwdmbNWK/CaNC2zRn7E3suZCq9GNx/prE=; b=iAqQ8QnJfTmaHEcwj/e4nVV/2yqIo8I3vbGtWSXuDxYEkF1pJ1G9iDB2IlLkPYtJreTQIo3hYshEFKxn6rA6BKbVo1PhSa+KWkDlemgbrgXu0TAGwD8mRx73Vg0S5x4M+1yuQ3HqFidtSuK5tygwRvcvcmXU5lrhu6wJ/DWRF5e9QT0IfdbUfsSHbsLYSja2y5BrwmGVVAhRZI38BWHC2rPsFvdgllPxyx9XUy+LcNxl+gCP0gQQ492LnJg7yq/+IhFjDlbTROwI8NkkK7y6mLdiVkd4VwHKylCi6KzFRp5sbI+IR1eTqUo2lj4WUHBhmI3xv718bYaQRIkmeiHknA== 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=UlZtxE4eQqOwdmbNWK/CaNC2zRn7E3suZCq9GNx/prE=; b=HVW/5nXr4ancERKKSRpVq18cnrWs2awF2LRmSMm2yjCR8y+Rp4EQRC61I8n5UaxxKgpLs4xv//IOcBjIEj/2XKmCLHFf88rfuRlCwnY02Omd+Xw86+G1WIUOKlWIXxO6wPfb5nv1Crd1UPqGM5/5YH3w7RMP/CG0uI8b+53EaaU= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5178.namprd05.prod.outlook.com (2603:10b6:5:33::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Fri, 9 Oct 2020 17:12:41 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782%3]) with mapi id 15.20.3477.011; Fri, 9 Oct 2020 17:12:41 +0000 From: Ron Bonica To: Peter Psenak , "Dongjie (Jimmy)" , Yingzhen Qu , Gyan Mishra CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAGYiICAAB9mMIAA726AgADTSnCAAWzZgIAAAz2A///GWICAAVg7AIAAFmsAgACYCCCACE1YgIAA2YqAgAAU6TA= Date: Fri, 9 Oct 2020 17:12:41 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-09T17:12:39Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=1d0b1503-0400-4485-b64a-5cc95b178af2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.115.7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 07378ee4-b2a9-46f7-d440-08d86c768811 x-ms-traffictypediagnostic: DM6PR05MB5178: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Fm/JlB/nDBCXvlvfagsoD12bEanSGkdZX7RjWcdACjyHr4caqKm3QBgKvo35LnCVUYG/1JSChjYjzZThWrrlgFtvPDl53fBWsmkEbgdPgkwfqvQa2neeGsRBXqhuGB6gn+uZkhEszjySGPzV+lT2s23r0Ew8EnsA7UIWEcQiMfbHeKrgKgbhTKREoBFNqa04hyRcnX+iA1ffYwOub5j1+hxr+zDxCvYEbHJ0ZRnIch/crCzeKGtQSu28hZ+tYmbWQ263eWaOhxSsz53asXjlVyLMGDtPRa6P1nSCD1HH/ON2z2TBuumuol23eiu7hHphqTqpT+Q9hGNYBleK0zqe7ooMgdif3tQG7AyWj9f8XGPRewIu7Ujp7A6Ky6YbQ2omU8pJPmyP+XjzgwqTqGXlvQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(376002)(346002)(136003)(366004)(5660300002)(9686003)(54906003)(53546011)(110136005)(6506007)(15650500001)(316002)(186003)(26005)(52536014)(76116006)(64756008)(66446008)(66556008)(66476007)(66946007)(2906002)(8676002)(4326008)(45080400002)(55016002)(8936002)(86362001)(83380400001)(83080400001)(966005)(33656002)(7696005)(71200400001)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: o7pjkav90Qe7V1pxQBm9I2qkn8aZKUK1kEx/1cNtNDx4pYVMReF6BQD2BLgHt4DAI1UPIFUybrl+HuBdC2Hv6659e2hMeBzISGxH/q//tIfuGPj8tqCXmL5KebmeJc86ygDi28KudT6Ky5U8P7u5+Kc+x+8bEkFITyaknw9OgwyWUUhXWNTj/GvzJJT/DzFFyoJCUEOP6lnooZY4QNrLJxj1Nfvbyzi9bej34K6AThk1BlQH5CjkOjVOIA61K6zYSaUF5tX+1jNcjfsgZuIvN1BcNMDZnoWEit0/uERrB/0t7JyvMNeNbCX41orevtk772VzwFHM81ObC0d6GziCSpcQlCiw8VlgcUI8ZiCsR+G/fSKHQYJwouhhdvsF9zipDcnFjQXjevE/G06M6yeb9s5KbYg/YfFyrgR1bLeR+G/4NIPrUC+nFmxGY+aOdmAvXdnsZPp61C53T4GwH4NNbhEx+8DEkbP0L+CK1jSwpc+GNyvoujbl1VHoMsxXkoxZDn2HWsWWVHmECfDTIPry4vkI6jeHvTULDXsYw4zH7qOTuJyZCATHLGQPUpjf8J49gqKDXraFfZkGxv2qKgT6i/mcS3ghrE9Dmle+zjv+FIPCacFmT+lrfPZhVreEI6IUh76ejCh1ULos5lTljZ/4uw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 07378ee4-b2a9-46f7-d440-08d86c768811 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2020 17:12:41.6646 (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: CbA0lnh7uHfvrRJVMiwSxO6GZbtVbzfpLQhODgdOYKdCpqYtg1mfb9P63FhvbhKd92fOVDSNlnrMtBtSjOEWNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5178 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-09_09:2020-10-09, 2020-10-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 impostorscore=0 bulkscore=0 clxscore=1011 adultscore=0 suspectscore=0 mlxscore=0 spamscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010090127 Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 17:13:18 -0000 KzENCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBQZXRlciBQc2VuYWsgPHBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMuaWV0 Zi5vcmc+IA0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDksIDIwMjAgMTE6NTggQU0NClRvOiBEb25n amllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb20+OyBSb24gQm9uaWNhIDxyYm9uaWNhQGp1 bmlwZXIubmV0PjsgWWluZ3poZW4gUXUgPHlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5jb20+OyBHeWFu IE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPg0KQ2M6IGxzckBpZXRmLm9yZzsgSmVmZiBU YW50c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW0xzcl0gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYm9uaWNhLWxzci1pcC1mbGV4YWxn by0wMC50eHQNCg0KW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KDQoN CkhpIEppbW15LA0KDQoNCiAgT24gMDkvMTAvMjAyMCAwNDo1OSwgRG9uZ2ppZSAoSmltbXkpIHdy b3RlOg0KPiBIaSBSb24sDQo+DQo+IFRoYW5rcyBmb3IgZXhwbGFpbmluZyB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIElQIEZsZXgtQWxnbyBhbmQgU1IgRmxleC1hbGdvLiBBcyB5b3Ugc2FpZCwgdGhl IG1ham9yIGRpZmZlcmVuY2UgaXMgdGhlIGRhdGEgcGxhbmUuDQo+DQo+IElmIG15IHVuZGVyc3Rh bmRpbmcgaXMgY29ycmVjdCwgZm9yIG9uZSBGbGV4LUFsZ28gdG8gYmUgdXNlZCBjb3JyZWN0bHks IHRoZSBzZXQgb2Ygbm9kZXMgbmVlZCB0byBhcHBseSBjb25zaXN0ZW50IGNvbnN0cmFpbnRzIGlu IGNvbXB1dGF0aW9uLCBhbmQgYmluZCB0aGUgRkFEIHRvIHRoZSBzYW1lIGRhdGEgcGxhbmUuDQo+ DQo+IElzIGl0IHBvc3NpYmxlIHRoYXQgZGlmZmVyZW50IG5vZGVzIG1heSB1c2UgdGhlIHNhbWUg RmxleC1BbGdvIHdpdGggZGlmZmVyZW50IGRhdGEgcGxhbmUsIGUuZy4gc29tZSB3aXRoIFNSLU1Q TFMsIHNvbWUgd2l0aCBTUnY2LCBhbmQgc29tZSB3aXRoIHB1cmUgSVAgZXRjLiwgb3IgZWFjaCBG bGV4LUFsZ28gaXMgYWx3YXlzIGFzc29jaWF0ZWQgd2l0aCBvbmx5IG9uZSBkYXRhIHBsYW5lPyBJ biB0aGUgZm9ybWVyIGNhc2UsIHNob3VsZCB0aGUgZmxleC1hbGdvIGRlZmluaXRpb24gYWxzbyBp bmRpY2F0ZSB0aGUgZGF0YSBwbGFuZShzKSB0byBiZSB1c2VkIHdpdGggdGhlIGZsZXgtYWxnbz8N Cg0KbGV0IG1lIHJlc3BvbmQgdG8gdGhpcyBxdWVyeSwgYXMgdGhpcyBpcyBub3Qgc3BlY2lmaWMg dG8gUm9uJ3MgZHJhZnQuDQoNCkZBRCBpcyBkYXRhIHBsYW5lIGFnbm9zdGljIGFuZCBpcyB1c2Vk IGJ5IGFsbCBvZiB0aGVtLg0KDQp0aGFua3MsDQpQZXRlcg0KDQo+DQo+IEJlc3QgcmVnYXJkcywN Cj4gSmllDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogTHNyIFtt YWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24gQm9uaWNhDQo+PiBT ZW50OiBTdW5kYXksIE9jdG9iZXIgNCwgMjAyMCA0OjM0IEFNDQo+PiBUbzogWWluZ3poZW4gUXUg PHlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5jb20+OyBQZXRlciBQc2VuYWsgDQo+PiA8cHBzZW5ha0Bj aXNjby5jb20+OyBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPg0KPj4gQ2M6IGxz ckBpZXRmLm9yZzsgSmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+DQo+PiBT dWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+PiBk cmFmdC1ib25pY2EtbHNyLWlwLWZsZXhhbGdvLTAwLnR4dA0KPj4NCj4+IEhpIFlpbmd6aGVuLA0K Pj4NCj4+IElQIEZsZXhpYmxlIEFsZ29yaXRobXMgYXJlIGxpa2UgU1IgRmxleGlibGUgQWxnb3Jp dGhtcyBpbiB0aGUgZm9sbG93aW5nIHJlc3BlY3RzOg0KPj4NCj4+IC0gTGlua3MgaGF2ZSBJR1Ag bWV0cmljcywgVEUgbWV0cmljcywgZGVsYXkgbWV0cmljcyBhbmQgDQo+PiBhZG1pbmlzdHJhdGl2 ZSBjb2xvcnMNCj4+IC0gRkFEcyBkZWZpbmUgRmxleGlibGUgQWxnb3JpdGhtcw0KPj4NCj4+IE1v cmUgc3BlY2lmaWNhbGx5LCB0aGUgRkFEOg0KPj4NCj4+IC0gSW5kaWNhdGVzIHdoaWNoIG1ldHJp YyB0eXBlIHRoZSBGbGV4aWJsZSBBbGdvcml0aG0gdXNlcw0KPj4gLSBTcGVjaWZpZXMgY29uc3Ry YWludHMgaW4gdGVybXMgb2YgbGluayBjb2xvcnMgdGhhdCBhcmUgaW5jbHVkZWQgb3IgDQo+PiBl eGNsdWRlZCBmcm9tIHRoZSBGbGV4aWJsZSBBbGdvcml0aG0uDQo+Pg0KPj4gVGhlIHNpZ25pZmlj YW50IGRpZmZlcmVuY2UgYmV0d2VlbiBJUCBGbGV4aWJsZSBBbGdvcml0aG1zIGFuZCBTUiANCj4+ IEZsZXhpYmxlIEFsZ29yaXRobXMgaXM6DQo+Pg0KPj4gLSBTUiBGbGV4aWJsZSBBbGdvcml0aG1z IGJpbmQgRkFEcyB0byBwcmVmaXggU0lEcyBvciBTUnY2IGxvY2F0b3JzDQo+PiAtIElQIEZsZXhp YmxlIEFsZ29yaXRobXMgYmluZCBGQURzIHRvIElQdjQgb3IgSVB2NiBhZGRyZXNzZXMuDQo+Pg0K Pj4gU28sIElQIEZsZXhpYmxlIEFsZ29yaXRobXMgY2FuIGJlIGRlcGxveWVkIGluIGFueSBJUCBu ZXR3b3JrLCBldmVuIGluIA0KPj4gdGhlIGFic2VuY2Ugb2YgU1IuDQo+Pg0KPj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCj4+DQo+Pg0KPj4gSnVuaXBlciBC dXNpbmVzcyBVc2UgT25seQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBZaW5nemhlbiBRdSA8eWluZ3poZW4ucXVAZnV0dXJld2VpLmNvbT4NCj4+IFNlbnQ6IFNh dHVyZGF5LCBPY3RvYmVyIDMsIDIwMjAgMjowOCBQTQ0KPj4gVG86IFBldGVyIFBzZW5hayA8cHBz ZW5ha0BjaXNjby5jb20+OyBHeWFuIE1pc2hyYSANCj4+IDxoYXlhYnVzYWdzbUBnbWFpbC5jb20+ OyBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KPj4gQ2M6IGxzckBpZXRmLm9yZzsg SmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+DQo+PiBTdWJqZWN0OiBSZTog W0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+PiBkcmFmdC1ib25pY2Et bHNyLWlwLWZsZXhhbGdvLTAwLnR4dA0KPj4NCj4+IFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlv dXMgb2YgY29udGVudF0NCj4+DQo+Pg0KPj4gSGkgUGV0ZXIsDQo+Pg0KPj4gVXNpbmcgZmxleC1h bGdvLCBhIFNSdjYgbG9jYXRvciBjYW4gYmUgYXNzb2NpYXRlZCB3aXRoIGEgc2luZ2xlIGFsZ28s IA0KPj4gd2hpY2ggbWVhbnMgYW4gSVB2NiBvciBJUHY0IGFkZHJlc3MgY2FuIGFsc28gYmUgYXNz b2NpYXRlZCB3aXRoIGEgDQo+PiBzaW5nbGUgYWxnby4gU28gbXkgdW5kZXJzdGFuZGluZyBpcyBS b24ncyBwcm9wb3NhbCBpcyBtYWtpbmcgdGhlIGNvbmZpZ3VyYXRpb24gb2YgZmxleC1hbGdvIGVh c2llcj8NCj4+IEluc3RlYWQgb2YgdXNpbmcgdGhlIGV4Y2x1ZGUgb3IgaW5jbHVkZSBsaXN0IHlv dSBjYW4gY29uZmlndXJlIGEgDQo+PiBsb29wYmFjayBhZGRyZXNzIHRvIGEgZmxleC1hbGdvIGRp cmVjdGx5Pw0KPj4NCj4+IFRoYW5rcywNCj4+IFlpbmd6aGVuDQo+Pg0KPj4gT24gMTAvMy8yMCwg Mjo0NyBBTSwgIlBldGVyIFBzZW5hayIgPHBwc2VuYWtAY2lzY28uY29tPiB3cm90ZToNCj4+DQo+ PiAgICAgIEhpIFlpbmd6aGVuLA0KPj4NCj4+ICAgICAgT24gMDIvMTAvMjAyMCAyMjoxNSwgWWlu Z3poZW4gUXUgd3JvdGU6DQo+PiAgICAgID4gSGkgUGV0ZXIsDQo+PiAgICAgID4NCj4+ICAgICAg PiBNeSB1bmRlcnN0YW5kaW5nIG9mIGZsZXgtYWxnbyBpcyB0aGF0IGZvciB0cmFmZmljIGRlc3Rp bmVkIHRvIA0KPj4gYSBwcmVmaXggb24gYSBwYXJ0aWN1bGFyIGFsZ28sIGl0IGNhbiBvbmx5IGJl IHJvdXRlZCBvbiByb3V0ZXJzIA0KPj4gYmVsb25nIHRvIHRoYXQgYWxnbywgd2hpY2ggYWxzbyBt ZWFucyBvbmx5IHJvdXRlcnMgaW4gdGhhdCBhbGdvIA0KPj4gY2FsY3VsYXRlcyBob3cgdG8gcmVh Y2ggdGhhdCBwcmVmaXggYW5kIGluc3RhbGwgaXQgaW50byB0aGUgcm91dGluZyANCj4+IHRhYmxl LiBJdCBzZWVtcyB0byBtZSB0aGF0IHVzaW5nIGZsZXgtYWxnbyAoc2VjdGlvbiAxMiBvZiB0aGUN Cj4+IGRyYWZ0KSBpdCdzIHBvc3NpYmxlIHRvIGhhdmUgYSBsb29wYmFjayBhZGRyZXNzIGFzc29j aWF0ZWQgd2l0aCBvbmx5IA0KPj4gb25lIGFsZ28sIHBsZWFzZSBjb3JyZWN0IG1lIGlmIEknbSBt aXNzaW5nIG9yIG1pc3VuZGVyc3Rvb2Qgc29tZXRoaW5nLg0KPj4NCj4+ICAgICAgeW91IGFyZSBy aWdodC4gVGhhdCBpcyBleGFjdGx5IHdoYXQgaXMgYmVpbmcgZG9uZSBmb3IgZmxleC1hbGdvIHdp dGgNCj4+ICAgICAgU1J2NiAtIGxvY2F0b3IgaXMgYXNzb2NpYXRlZCB3aXRoIGEgc2luZ2xlIGFs Z28gb25seS4gVGhlIHByb3Bvc2FsIHVzZXMNCj4+ICAgICAgdGhlIHNhbWUgY29uY2VwdC4NCj4+ DQo+PiAgICAgIHRoYW5rcywNCj4+ICAgICAgUGV0ZXINCj4+DQo+PiAgICAgID4NCj4+ICAgICAg PiBUaGFua3MsDQo+PiAgICAgID4gWWluZ3poZW4NCj4+ICAgICAgPg0KPj4gICAgICA+IE9uIDEw LzIvMjAsIDk6NDMgQU0sICJMc3Igb24gYmVoYWxmIG9mIFBldGVyIFBzZW5hayINCj4+IDxsc3It Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgDQo+PiBwcHNlbmFrPTQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnPg0KPj4gd3JvdGU6DQo+PiAgICAgID4NCj4+ICAgICAgPiAgICAgIEd5YW4s DQo+PiAgICAgID4NCj4+ICAgICAgPiAgICAgIE9uIDAyLzEwLzIwMjAgMTg6MzAsIEd5YW4gTWlz aHJhIHdyb3RlOg0KPj4gICAgICA+ICAgICAgPiBBbGwsDQo+PiAgICAgID4gICAgICA+DQo+PiAg ICAgID4gICAgICA+IFdpdGggU1J2NiBhbmQgSVAgYmFzZWQgZmxleCBhbGdvIGEgZ2VuZXJpYyBx dWVzdGlvbiBhcyBpdCBhcHBsaWVzDQo+PiB0bw0KPj4gICAgICA+ICAgICAgPiBib3RoLiBJcyBp dCBwb3NzaWJsZSB0byBoYXZlIHdpdGhpbiBhIHNpbmdsZSBJR1AgZG9tYWluIGRpZmZlcmVudA0K Pj4gc2V0cw0KPj4gICAgICA+ICAgICAgPiBvZiBub2RlcyBvciBzZWdtZW50cyBvZiB0aGUgbmV0 d29yayBydW5uaW5nIGRpZmZlcmVudA0KPj4gYWxnb3JpdGhtcy4NCj4+ICAgICAgPg0KPj4gICAg ICA+ICAgICAgYWJzb2x1dGVseS4NCj4+ICAgICAgPg0KPj4gICAgICA+ICAgICAgPiBGcm9tDQo+ PiAgICAgID4gICAgICA+IGJvdGggZHJhZnRzIGl0IHNvdW5kcyBsaWtlIGFsbCBub2RlcyBoYXZl IHRvIGFncmVlIG9uIHNhbWUNCj4+IGFsZ29yaXRobQ0KPj4gICAgICA+ICAgICAgPiBzaW1pbGFy IHRvIGNvbmNlcHQgb2YgbWV0cmljIGFuZCByZWZlcmVuY2UgYmFuZHdpZHRoIGFsbCBoYXZlIHRv DQo+PiBoYXZlDQo+PiAgICAgID4gICAgICA+IHRoZSBzYW1lIHN0eWxlIG1ldHJpYyBhbmQgcGxh eSB0byB0aGUgc2FtZSBzaGVldCBvZiBtdXNpYy4NCj4+ICAgICAgPg0KPj4gICAgICA+ICAgICAg YWxsIHBhcnRpY2lwYXRpbmcgbm9kZXMgbmVlZCB0byBhZ3JlZSBvbiB0aGUgZGVmaW5pdGlvbiBv ZiB0aGUNCj4+IGZsZXgtYWxnbw0KPj4gICAgICA+ICAgICAgYW5kIGFkdmVydGlzZSB0aGUgcGFy dGljaXBhdGlvbi4gVGhhdCdzIGl0Lg0KPj4gICAgICA+DQo+PiAgICAgID4gICAgICA+IElmIHRo ZXJlIHdhcw0KPj4gICAgICA+ICAgICAgPiBhIHdheSB0byB1c2UgbXVsdGlwbGUgYWxnb3JpdGht cyBzaW11bHRhbmVvdXNseSBiYXNlZCBvbiBTRkMNCj4+IG9yIHNlcnZpY2VzDQo+PiAgICAgID4g ICAgICA+IGFuZCBpbnN0YW50aWF0aW9uIG9mIHNwZWNpZmljIGFsZ29yaXRobSBiYXNlZCBvbiBz ZXJ2aWNlIHRvIGJlDQo+PiAgICAgID4gICAgICA+IHJlbmRlcmVkLiAgRG9pbmcgc28gd2l0aG91 dCBjYXVzaW5nIGEgcm91dGluZyBsb29wIG9yIHN1Yg0KPj4gb3B0aW1hbA0KPj4gICAgICA+ICAg ICAgPiByb3V0aW5nLg0KPj4gICAgICA+DQo+PiAgICAgID4gICAgICB5b3UgY2FuIGNlcnRhaW5s eSB1c2UgbXVsdGlwbGUgYWxnb3JpdGhtcyBzaW11bHRhbmVvdXNseSBhbmQgdXNlDQo+PiBhbGdv DQo+PiAgICAgID4gICAgICBzcGVjaWZpYyBwYXRocyB0byBmb3J3YXJkIHNwZWNpZmljIHRyYWZm aWMgb3ZlciBpdC4gSG93IHRoYXQgaXMgZG9uZQ0KPj4gICAgICA+ICAgICAgZnJvbSB0aGUgZm9y d2FyZGluZyBwZXJzcGVjdGl2ZSBkZXBlbmRzIGluIHdoaWNoIGZvcndhcmRpbmcNCj4+IHBsYW5l IHlvdQ0KPj4gICAgICA+ICAgICAgdXNlLiBGbGV4LWFsZ28gY29udHJvbCBwbGFuZSBpcyBpbmRl cGVuZGVudCBvZiB0aGUgZm9yd2FyZGluZw0KPj4gcGxhbmUuDQo+PiAgICAgID4NCj4+ICAgICAg Pg0KPj4gICAgICA+ICAgICAgPkkgdGhvdWdodCB3aXRoIGZsZXggYWxnbyB0aGF0IHRoZXJlIGV4 aXN0cyBhIGZlYXR1cmUgdGhhdCBvbg0KPj4gICAgICA+ICAgICAgPiBlYWNoIGhvcCB0aGVyZSBp cyBhIHdheSB0byBzcGVjaWZ5IHdoaWNoIGFsZ28gdG8gdXNlIGhvcCBieSBob3ANCj4+IHNpbWls YXINCj4+ICAgICAgPiAgICAgID4gdG8gYSBob3AgYnkgaG9wIHBvbGljeSBiYXNlZCByb3V0aW5n Lg0KPj4gICAgICA+DQo+PiAgICAgID4gICAgICBubywgdGhlcmUgaXMgbm8gaG9wLWJ5LWhvcCBj bGFzc2lmaWNhdGlvbiwgdGhhdCBpcyBwcm9ibGVtYXRpYyBhbmQNCj4+IGRvZXMNCj4+ICAgICAg PiAgICAgIG5vdCBzY2FsZSBmb3IgaGlnaCBzcGVlZHMuIENsYXNzaWZpY2F0aW9uIGlzIGRvbmUg YXQgdGhlIGluZ3Jlc3Mgb25seS4NCj4+ICAgICAgPg0KPj4gICAgICA+ICAgICAgdGhhbmtzLA0K Pj4gICAgICA+ICAgICAgUGV0ZXINCj4+ICAgICAgPg0KPj4gICAgICA+ICAgICAgPg0KPj4gICAg ICA+DQo+PiAgICAgID4gICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gICAgICA+ICAgICAgTHNyIG1haWxpbmcgbGlzdA0KPj4gICAgICA+ICAg ICAgTHNyQGlldGYub3JnDQo+PiAgICAgID4NCj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvbw0KPj4gay5jb20vDQo+ PiA/dXJsPWh0dHBzKjNBKjJGKjJGd3d3LmlldGYub3JnKjJGbWFpbG1hbioyRmxpc3RpbmZvKjJG bHNyJmFtcDtkYXRhPTANCj4+IDINCj4+ICo3QzAxKjdDeWluZ3poZW4ucXUqNDBmdXR1cmV3ZWku Y29tKjdDZmUwMzEyNGM2ZTQxNGUwNjdjMjAwOGQ4Njc4MQ0KPj4gNjU0MSo3QzBmZWU4ZmYyYTNi MjQwMTg5Yzc1M2ExZDU1OTFmZWRjKjdDMSo3QzAqN0M2MzczNzMxNTI3Mzk4Ng0KPj4gNTEyNiZh bXA7c2RhdGE9V0k0OGNFQWFuKjJGT2tEUG1WWEd1ckVBalBJdE5HRjlwOVBEUUlsRDFpcDBnKjNE DQo+PiAmYW1wO3Jlc2VydmVkPTBfXztKU1VsSlNVbEpTVWxKU1VsSlNVbEpRISFORXQ2eU1hTy1n ayFYMWZSbG45TWppbWVKY1INCj4+IEVVRUl5ZHItOElJYnROb25YTXM4M2VvWHZSd3c2eGthUWZW VWROaDBrSzQ1MkdQLUckDQo+PiAgICAgID4NCj4+ICAgICAgPg0KPj4gICAgICA+DQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IExzciBt YWlsaW5nIGxpc3QNCj4+IExzckBpZXRmLm9yZw0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo+PiBfXzshIU5F dDZ5TWFPLWdrIVMzRFpHcl9EYkNRSVJzbnEyaEFnQXRiMlJseEVydmQ4VDBXRzdWSHYyMWpERlVf WkZEaHcNCj4+IGg3cVZNX1ZVT0xnSiQNCj4NCj4NCg== From nobody Fri Oct 9 12:48:21 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637B23A1516 for ; Fri, 9 Oct 2020 12:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.587 X-Spam-Level: X-Spam-Status: No, score=-9.587 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=HeTzKgZ1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gyF6ekGA 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 S1avbdmgwHdr for ; Fri, 9 Oct 2020 12:48:16 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CDF3A1512 for ; Fri, 9 Oct 2020 12:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66869; q=dns/txt; s=iport; t=1602272896; x=1603482496; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=StfLI6maYda+LZOERzdhQFZatcwcoOPc1phAl/R8uNc=; b=HeTzKgZ1/8b7tnNOAzWPw2BkeHwTL+O0RTdl0v6MM0tuSIPQImnXlcED ArLEdNlTChFd9zIFOHoHtghBragZ3Hdmj+c82zYVzZ7LOFv0c/zCvTYjs DtCw8lF4Dk5tCSm96fQOfi3coopcOjHFZulIjbyTY7HDdV+4YJB8fiMBK k=; IronPort-PHdr: =?us-ascii?q?9a23=3A6nFeoxY0BUjsweeStk7uqLX/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWXD5nA6vRLi/ff9af6VioL58XJvHMDdclKUB?= =?us-ascii?q?kIwYUTkhc7CcGIQUv8MLbxbiM8EcgDMT0t/3yyPUVPXsqrYVrUry6u9j8UFR?= =?us-ascii?q?XiPExyPOuzEYiBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrBQCXvYBf/4MNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCD4EjL1EHcFkvLAqEM4NGA41SmHuCUwNQBQsBAQENAQEYAQw?= =?us-ascii?q?IAgQBAYRKAheBfAIlOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgEBARA?= =?us-ascii?q?RHQEBLAkCAQQHBAIBCBEDAQEBIQEGAwICAiULFAkIAgQBDQUbB4MEAYF+TQM?= =?us-ascii?q?OIAEOniYCgTmIYXaBMoMBAQEFgTcCDkGDExiCEAmBOIJyg22GVhuCAIE4HIJ?= =?us-ascii?q?NPoIaQgEBAgEBFYEkAQE3CQ0JCIJZM4ItkAODQocFJpxuCoJoiQCOfYJqAx+?= =?us-ascii?q?DE4EqiF6UG5McgXqIdpUxAgQCBAUCDgEBBYFrI4FXcBUaISoBgj4JRxcCDY4?= =?us-ascii?q?fDBcUgzqFFIVCdAIBNAIGAQkBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,355,1596499200"; d="scan'208,217";a="571932052" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Oct 2020 19:48:10 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 099Jm5FM023923 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Oct 2020 19:48:08 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 9 Oct 2020 14:48:06 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 9 Oct 2020 15:48:05 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 9 Oct 2020 14:48:05 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gwiNwhLtsvCzLOa9cOC8t9fHCz5qrpjoLTbxSl4JQ7Msj3ez7UgFC1bca9gfWf31UP3iUQe8m5FyIwG7NStOkBTVuEstJ8kwvskG9fIEzYq/KUupzvuaCOrTpV6g9nTXaoVjtT3DHtwMFCwdEAfnUgOoZWNrkX8B2gI15BbQSvLsmL9X6VtB8HL4C5pdrh52uH45OPeNPEA4ZALPF6z39yMEIY8O1LnHhsKxAArWZUnyrRX6QThkezyZ7QwMS7fltqdc+UNRUuH76GEx183QxPq9rqpR092K6klnzkTvh127R7O0NH5aSsE2VIGIDKk1QpqugJPvmxuOf2Th34+7jw== 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=StfLI6maYda+LZOERzdhQFZatcwcoOPc1phAl/R8uNc=; b=Exv5eNJOLGqM+jIADOG3ZQmOoi2c9+uxUeIeHZYodioR1YaqrPj58c/iTX5F1Wf5P9U/eLYxy9D1mKvu4kXUKyyafGJUUFF8Bd/y+m8XnJlghOAnl8A/WMD6RuublAyQwsJ4SamX8RAmEdA8UJIlEmiD35OQFnHw0OgY4TBQnlpwnj9Gb8ljoNtybvvxs3Xa+9P/8W5ZXye743DjJYW1xB4znSbUnNh8ViSCpmTm0leHLQN0fLKr3fQr/qhlJ+x4Frigd1ttYxojx1X7IZQ1qdcUEUCy6S5S11PNQhu9c2ws7/i4OfQeEtiXITnvom5m1oGsoNRUA4a2KuPsBmi55Q== 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=StfLI6maYda+LZOERzdhQFZatcwcoOPc1phAl/R8uNc=; b=gyF6ekGAEnY6wAu6fbjh4bG99dOf8cMdARVkIIi8zZOLQlNa8x9AXhX21fDjoPx29SGUlvwunL/AYwbCEOqjvgKgGItLQX3ipxZF6YHUmM49BvC+6VPA7E/avQk98I4v15ptAsecUMsm3/dQbsmRH9pTtibFsve4JdCS32zhKTk= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3575.namprd11.prod.outlook.com (2603:10b6:a03:b3::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.24; Fri, 9 Oct 2020 19:48:03 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3455.027; Fri, 9 Oct 2020 19:48:03 +0000 From: "Acee Lindem (acee)" To: Aijun Wang , "Peter Psenak (ppsenak)" , "'Aijun Wang'" CC: "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt Thread-Index: AQHWljqhPwTJc6J3hEmS7XUA0fh0y6l/U3AAgAACPQCAAABHAIABIzwAgABWLoCADdcbgIAA1DUA Date: Fri, 9 Oct 2020 19:48:03 +0000 Message-ID: <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> In-Reply-To: <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c9701add-0fda-4b9f-f971-08d86c8c3c2a x-ms-traffictypediagnostic: BYAPR11MB3575: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UfibLsqMigVfkAkWgLUymHvBuH5kD4q/CXI6nQYH7bnOxSU7u1k7wjifbyfDwlYx6n/cO2XCBtO+jmszyp9714o2dGHyRaQssL84C9X4X5iJPmJzuTqTzrKGbWMtrvsmWt2lrxsTNPZ0n4yjGpKN/x67P2DLgI1res9CA2mHD5nETkzMCqfxcFoq09V0yu3CX6FMXgv+5cODTIABqtTbGpTBlHstciy5vLLROZ/YyGrPt2zPavwXLfXGPxZa8P+9UUewmgJiDqiGSXGnlP+WxDmDZgRebbnK7q+LopkQtIGAfKaE3EWen6oD62xgmMQLsVSTCuGVTkg42kVbDkm5hmz/EPRYosVf9frt/yHLp93GFQVMw36a6uvHViFvG4Oo6+X6Ubglo96VaZan1omLEw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(396003)(136003)(366004)(376002)(33656002)(83080400001)(8936002)(966005)(2906002)(478600001)(166002)(6486002)(66574015)(64756008)(76116006)(6512007)(66556008)(83380400001)(66446008)(66946007)(66476007)(2616005)(15650500001)(5660300002)(36756003)(316002)(86362001)(110136005)(4326008)(71200400001)(53546011)(6506007)(186003)(26005)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: GprkaidP5r9SbirAoYx/BiUHSLhXrfyyzLEdIppP/k8s/VcgR1mBYPqnbXRJcxuaeC+frvzgVnMc/yuNncKmVlpYM/OKzBQ8fPnT+fbaHhiTjY/x7NfSNdv5NMKfPI9pORRhZA7Ot8tHHlekQbBU2RIFLQf8Z7jBzbP8P/OfTjCVdO/7o/bpxTbJw2na2LkCTW55oXhnIVOZay1F0YJ6wgTTsrw9BCgiRY7JOaWzIj4lODxDl0CdAVZ3ehL37GUjmlVoKvBdOmP+7EWU1d/4t1tzL3uk6YfmvNIby8ltkYFgH0Ta8623huggdLRbOeCwn5YP4EZtdqF8QnhDHHopCGl0xLjvJ3MdExK5PLsdE6xk7ozB4ROcZijqhBTT1LmxhgqUsVw8tBQZMKFP9kwCGwVsB3HVqMglK7y+6QnoEwyCxczvZBDMAZj4q9UsvtHm4sBhQa5r7DgCoVJ/SbsY2FtsHIDKAMI64bl1iyJsUjxhYAo8+Wcd435hGQIWF+ygIMwyNJurLn3e/ljQieHHbY6uZOSIlQ+i5DHEkMXbeiuutNbe970OanVNy3+KgJj/5TEEiJpc1cOQ5FReFDaEr720hxOa9rZo5QoWH4pCv2PIOae0aBpqP9ZUZzWOSMithK2b6RYLL2cdQ/FKE0cPgw== Content-Type: multipart/alternative; boundary="_000_4C885AD13E04476BB779C83023B9B7D5ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c9701add-0fda-4b9f-f971-08d86c8c3c2a X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2020 19:48:03.2136 (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: nnM2wa7Lt2spnggs6zk5srvVNfjzQDTZUQ0CUreUojRULx0umSs+vx3pi4yZqrKi X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3575 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 19:48:19 -0000 --_000_4C885AD13E04476BB779C83023B9B7D5ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlYWtpbmcgYXMgV0cgbWVtYmVyOg0KDQpIaSBBaWp1biwNCg0KRnJvbTogQWlqdW4gV2FuZyA8 d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4NCkRhdGU6IFRodXJzZGF5LCBPY3RvYmVyIDgsIDIw MjAgYXQgMTE6MDkgUE0NClRvOiBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb20+LCAiUGV0ZXIg UHNlbmFrIChwcHNlbmFrKSIgPHBwc2VuYWtAY2lzY28uY29tPiwgJ0FpanVuIFdhbmcnIDx3YW5n YWozQGNoaW5hdGVsZWNvbS5jbj4NCkNjOiAibHNyQGlldGYub3JnIiA8bHNyQGlldGYub3JnPg0K U3ViamVjdDogUkU6IFtMc3JdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQNCg0KDQpIaSwgQWNl ZToNCg0KU29ycnkgZm9yIHRoZSBwcmV2aW91cyBwcnVuZWQgbWFpbC4gTGV0J3MgcmVwbHkgeW91 IGFnYWluIGFsb25nIHlvdXIgb3JpZ2luYWwgcXVlc3Rpb24uDQoNClBsZWFzZSBzZWUgaW5saW5l LltXQUpdDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbHNyLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFj ZWUgTGluZGVtIChhY2VlKQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMjAgNzo0 NyBQTQ0KVG86IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+OyBQZXRlciBQ c2VuYWsgKHBwc2VuYWspIDxwcHNlbmFrQGNpc2NvLmNvbT47ICdBaWp1biBXYW5nJyA8d2FuZ2Fq M0BjaGluYXRlbGVjb20uY24+DQpDYzogbHNyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0xzcl0g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1p bnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dA0KDQoNCg0KSGkgQWlqdW4sDQoNCk90aGVyIHRoYW4g eW91ciBpbGwtY29uY2VpdmVkIHRvcG9sb2d5IGRpc2NvdmVyeSBoZXVyaXN0aWMNCg0KW1dBSl0g VGhlIHRvcG9sb2d5IGRpc2NvdmVyeSBoZXVyaXN0aWMgaXMgbm90IHN1aXRhYmxlIGZvciB0aGUg Y29ybmVyIHVzZSBjYXNlIHdoZW4gdGhlIHVubnVtYmVyZWQgaW50ZXJmYWNlIGlzIHVzZWQsIGFz IGV4cGxhaW5lZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sc3It b3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNiNhcHBlbmRpeC1CLiAgSWYgeW91IGRvbuKAmXQgYWdy ZWUsIHdvdWxkIHlvdSBsaWtlIHRvIGlsbHVzdHJhdGUgb3RoZXIgbm9uLWFwcGxpY2FibGUgc2Nl bmFyaW9zPw0KDQoNCg0KUmlnaHQg4oCTIGFuZCBub2JvZHkgb3RoZXIgdGhhbiB5b3Vyc2VsZiBi ZWxpZXZlcyB0aGUgSUdQcyBzaG91bGQgYmUgbW9kaWZpZWQgdG8gZXhwb3NlIHRoZSBhYnN0cmFj dGVkIHRvcG9sb2d5IG9mIGFuIGFyZWEgb3V0c2lkZSB0aGF0IGFyZWEuIFlvdSBjYW4gc29sdmUg dGhlIHByb2JsZW0gd2l0aCBCR1AtTFMgc2Vzc2lvbihzKSBiZXR3ZWVuIHRoZSByb3V0ZXIgd2l0 aCBhIEJHUC1MUyBzZXNzaW9uIHRvIHRoZSBjb250cm9sbGVyIGFuZCBhIHJvdXRlciBpbiBlYWNo IGFyZWEgdy9vICBhIHJvdXRlciB3aXRoIGEgQkdQLUxTIHNlc3Npb24gdG8gdGhlIGNvbnRyb2xs ZXIuDQoNCg0KDQp3aGF0IG90aGVyIHBvc3NpYmxlIHJlYXNvbiB3b3VsZCB0aGVyZSBiZSBmb3Ig YXNzb2NpYXRpbmcgdGhlIHBhc3NpdmUgYXR0cmlidXRlIHdpdGggYSBwcmVmaXg/DQoNCltXQUpd IFRvIGtub3cgdGhlIGJvdW5kYXJ5IG9mIHRoZSBJR1AgZG9tYWluLiBBZnRlciBrbm93aW5nIHRo ZSBib3VuZGFyeSwgdGhlIGNvbnRyb2xsZXIgY2FuIHNhZmVseSBhcHBseSBhbmQgY2hlY2sgdGhl IG5ldHdvcmsgc2VjdXJpdHkgcG9saWN5LCB0aGUgaW5ib3VuZCB0cmFmZmljIGNvbnRyb2wgcG9s aWN5IGV0Yy4NCg0KDQoNCkl0IHJlYWxseSBpc27igJl0IHJlbGV2YW50LCBidXQgSSBoYXZlIHRv IGFza+KApi4gSG93IGRvZXMgdGhlIHByZXNlbmNlIG9mIGEgcHJlZml4IGFzc29jaWF0ZWQgd2l0 aCBhIHBhc3NpdmUgaW50ZXJmYWNlIGFsbG93IHlvdSB0byBtYWtlIHRoaXMgZGVkdWN0aW9uPw0K DQoNCg0KVGhhbmtzLA0KDQpBY2VlDQoNCg0KDQpUaGFua3MsDQoNCkFjZWUNCg0KDQoNCk9uIDkv MjkvMjAsIDEwOjM5IFBNLCAiQWlqdW4gV2FuZyIgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY248 bWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+PiB3cm90ZToNCg0KDQoNCiAgICBIaSwg QWNlZSBhbmQgUGV0ZXI6DQoNCiAgICBQYXNzaXZlIGludGVyZmFjZSBpcyBtYWlubHkgdXNlZCBh dCB0aGUgZWRnZSBvZiB0aGUgbmV0d29yaywgd2hlcmUgdGhlIHVubnVtYmVyZWQgaW50ZXJmYWNl IHdpbGwgbm90IGJlIHVzZWQuDQoNCiAgICBBbmQgdGhlIGluZm9ybWF0aW9uIHRvIGZsYWcgdGhl IHBhc3NpdmUgaW50ZXJmYWNlcyBpcyBmb3IgcG9zaXRpb25pbmcgdGhlIGFyZWEgYm91bmRhcnks IG5vdCBjb25mbGljdCB3aXRoIHRoZSBhYnN0cmFjdCBjYXBhYmlsaXRpZXMgb2YgdGhlIGFyZWEg aW5zaWRlLg0KDQoNCg0KDQoNCiAgICBCZXN0IFJlZ2FyZHMNCg0KDQoNCiAgICBBaWp1biBXYW5n DQoNCiAgICBDaGluYSBUZWxlY29tDQoNCg0KDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCg0KICAgIEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsc3ItYm91bmNlc0Bp ZXRmLm9yZz4gW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFjZWUg TGluZGVtIChhY2VlKQ0KDQogICAgU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDI5LCAyMDIwIDk6 MTYgUE0NCg0KICAgIFRvOiBQZXRlciBQc2VuYWsgPHBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmc8bWFpbHRvOnBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+PjsgQWlq dW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjxtYWlsdG86d2FuZ2FpanVuQHRzaW5n aHVhLm9yZy5jbj4+OyAnQWlqdW4gV2FuZycgPHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuPG1haWx0 bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbj4+DQoNCiAgICBDYzogbHNyQGlldGYub3JnPG1haWx0 bzpsc3JAaWV0Zi5vcmc+DQoNCiAgICBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmli dXRlLTA0LnR4dA0KDQoNCg0KICAgIFNwZWFraW5nIGFzIFdHIG1lbWJlcjoNCg0KDQoNCiAgICBI aSBBaWp1biwgUGV0ZXIsDQoNCiAgICBJIGFncmVlIHdpdGggUGV0ZXIgLSBvbmUgb2YgdGhlIG1h aW4gbW90aXZhdGlvbnMgZm9yIGhhdmluZyBhcmVhcyBpcyB0byBhYnN0cmFjdCB0aGUgdG9wb2xv Z3kgd2l0aGluIHRoZSBhcmVhLiBOb3cgeW91J3JlIHRyeWluZyB0byBzdXBwbGFudCB0aGlzICAt IG9uZSB0b3BvbG9naWNhbCBkZXRhaWwgYXQgYSB0aW1lIHdpdGggaWxsLWNvbmNlaXZlZCBJR1Ag ZmVhdHVyZXMuDQoNCiAgICBUaGFua3MsDQoNCiAgICBBY2VlDQoNCg0KDQogICAgT24gOS8yOS8y MCwgNToxNSBBTSwgIkxzciBvbiBiZWhhbGYgb2YgUGV0ZXIgUHNlbmFrIiA8bHNyLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIHBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnJTIwb24lMjBiZWhhbGYlMjBvZiUyMHBwc2VuYWs9 NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KDQoNCiAgICAgICAgSGkgQWlq dW4sDQoNCg0KDQogICAgICAgIE9uIDI5LzA5LzIwMjAgMTE6MDcsIEFpanVuIFdhbmcgd3JvdGU6 DQoNCiAgICAgICAgPiBIaSwgUGV0ZXI6DQoNCiAgICAgICAgPg0KDQogICAgICAgID4gVGhhbmtz IGZvciB5b3VyIGNvbW1lbnRzLg0KDQogICAgICAgID4gMS4gRm9yIEJHUC1MUyBkZXBsb3ltZW50 LCB0aGVyZSBub3JtYWxseSBvbmx5IGJlIG9uZSByb3V0ZXIgdGhhdCB3aXRoaW4gdGhlDQoNCiAg ICAgICAgPiBJR1AgZG9tYWluIHRvIHJlcG9ydCB0aGUgdG9wb2xvZ3kgaW5mb3JtYXRpb24sIHRo aXMgcm91dGVyIHNob3VsZCBrbm93IHN1Y2gNCg0KICAgICAgICA+IHBhc3NpdmUgbGlua3Mgd2hp Y2ggZXhpc3RzIG1haW5seSBvbiBvdGhlciBib3JkZXIgcm91dGVycyB2aWEgdGhlIElHUA0KDQog ICAgICAgID4gcHJvdG9jb2wuIFRoaXMgaXMgbWFpbiByZWFzb24gdG8gZXh0ZW5zaW9uIHRoZSBJ R1AgcHJvdG9jb2wuID4gMi4gRm9yIHRoZSBzb2x1dGlvbiwgbm9ybWFsbHksIHRoZSBsaW5rIHdp dGhpbiB0aGUgSUdQIGNvbm5lY3QgdHdvDQoNCiAgICAgICAgZW5kcywgYnV0DQoNCiAgICAgICAg PiBwYXNzaXZlIGludGVyZmFjZSBpcyBzcGVjaWFsIGFuZCBub3QgZmFsbCBpbiB0aGlzIHNwYWNl LiBXZSBoYXZlIHN0dWRpZWQgdGhlDQoNCiAgICAgICAgPiBjdXJyZW50IFRMVnMgdGhhdCBmb3Ig bGluaywgYW5kIGZpbmQgbm8gc3VpdGFibGUgY29udGFpbmVyIHRvIGFwcGVuZCB0aGlzDQoNCiAg ICAgICAgPiBpbmZvcm1hdGlvbi4gVGhpcyBpcyB0aGUgcmVhc29uIHRoYXQgd2Ugc2VsZWN0IHRo ZSBUTFZzIHRoYXQgYXNzb2NpYXRlZCB3aXRoDQoNCiAgICAgICAgPiBQcmVmaXguDQoNCg0KDQog ICAgICAgIGlmIHRoZSBsaW5rIGlzIHVubnVtYmVyZWQsIHlvdXIgc29sdXRpb24gZG9lcyBub3Qg d29yay4gQXMgSSBzYWlkLCBpZg0KDQogICAgICAgIHlvdSBuZWVkIGEga25vd2xlZGdlIGFib3V0 IHRoZSBsaW5rLCB5b3UgY2FuIG5vdCBhZHZlcnRpc2UgaXQgYXMgYSBwcmVmaXguDQoNCg0KDQog ICAgICAgIHRoYW5rcywNCg0KICAgICAgICBQZXRlcg0KDQoNCg0KDQoNCiAgICAgICAgPg0KDQog ICAgICAgID4+RnJvbSBvdGhlciBQT1YsIHRoZSBPU1BGdjMgZGVmaW5lcyBub3cgdGhlICJJbnRy YS1BcmVhLVByZWZpeCBMU0EiLCB3aGljaA0KDQogICAgICAgID4gaXNvbGF0ZSB0aGUgcHJlZml4 IGluZm9ybWF0aW9uIHRoYXQgYXNzb2NpYXRlZCB3aXRoIGxpbmsgaW50byB0aGlzDQoNCiAgICAg ICAgPiBjb250YWluZXIsIGNvbnRhaW5zIHRoZSBzdHViIGxpbmssIGxvY2FsIGludGVyZmFjZSBp bmZvcm1hdGlvbiBldGMuIFB1dCBzdWNoDQoNCiAgICAgICAgPiBhdHRyaWJ1dGUgYWxvbmcgd2l0 aCB0aGUgcHJlZml4IGlzIHRoZW4gYWNjZXB0YWJsZT8NCg0KICAgICAgICA+DQoNCiAgICAgICAg Pg0KDQogICAgICAgID4gQmVzdCBSZWdhcmRzDQoNCiAgICAgICAgPg0KDQogICAgICAgID4gQWlq dW4gV2FuZw0KDQogICAgICAgID4gQ2hpbmEgVGVsZWNvbQ0KDQogICAgICAgID4NCg0KICAgICAg ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCiAgICAgICAgPiBGcm9tOiBsc3ItYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bHNyLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlcg0KDQogICAgICAgID4gUHNlbmFrDQoN CiAgICAgICAgPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMjAgNDoyOSBQTQ0KDQog ICAgICAgID4gVG86IEFpanVuIFdhbmcgPHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuPG1haWx0bzp3 YW5nYWozQGNoaW5hdGVsZWNvbS5jbj4+DQoNCiAgICAgICAgPiBDYzogbHNyQGlldGYub3JnPG1h aWx0bzpsc3JAaWV0Zi5vcmc+DQoNCiAgICAgICAgPiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCg0KICAgICAgICA+IGRyYWZ0LXdhbmctbHNyLXBh c3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQNCg0KICAgICAgICA+DQoNCiAgICAgICAg PiBIaSBBaWp1biwNCg0KICAgICAgICA+DQoNCiAgICAgICAgPiBoZXJlJ3MgbXkgY29tbWVudHM6 DQoNCiAgICAgICAgPg0KDQogICAgICAgID4gVGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFmdCBpcyB0 byBhZHZlcnRpc2UgcGFzc2l2ZSBsaW5rcy4NCg0KICAgICAgICA+DQoNCiAgICAgICAgPiAxLiBJ J20gbm90IHN1cmUgdGhlIHByb2JsZW0gbmVlZHMgdG8gYmUgc29sdmVkIGJ5IElHUHMuIEkgdGVu ZCB0byBiZWxpZXZlDQoNCiAgICAgICAgPiBpZXRmLWlkci1iZ3Bscy1pbnRlci1hcy10b3BvbG9n eS1leHQgaXMgc3VmZmljaWVudC4NCg0KICAgICAgICA+DQoNCiAgICAgICAgPiAyLiB0aGUgc29s dXRpb24gdGhhdCB5b3UgcHJvcG9zZWQgaXMgd3JvbmcuIFlvdSBhcmUgdHJ5aW5nIHRvIGRlcml2 ZQ0KDQogICAgICAgID4gdG9wb2xvZ2ljYWwgZGF0YSBhYm91dCB0aGUgcGFzc2l2ZSBsaW5rcyBm cm9tIHRoZSBwcmVmaXggYWR2ZXJ0aXNlbWVudC4NCg0KICAgICAgICA+IFRoaXMgaXMgc2VtYW50 aWNhbGx5IGluY29ycmVjdCBhbmQgb25seSB3b3JrcyB1bmRlciB2ZXJ5IHNwZWNpZmljIGNvbmRp dGlvbi4NCg0KICAgICAgICA+IElmIHlvdSBuZWVkIHRvIGFkdmVydGlzZSBhIGxpbmssIGFkdmVy dGlzZSBpdCBhcyBhICJzcGVjaWFsIg0KDQogICAgICAgID4gbGluaywgbm90IGFzIGEgInNwZWNp YWwiIHByZWZpeC4NCg0KICAgICAgICA+DQoNCiAgICAgICAgPiB0aGFua3MsDQoNCiAgICAgICAg PiBQZXRlcg0KDQogICAgICAgID4NCg0KICAgICAgICA+IE9uIDI5LzA5LzIwMjAgMDM6MTcsIEFp anVuIFdhbmcgd3JvdGU6DQoNCiAgICAgICAgPj4gSGksIFBldGVyOg0KDQogICAgICAgID4+DQoN CiAgICAgICAgPj4gV291bGQgeW91IGxpa2UgdG8gcmV2aWV3IGFuZCBnaXZlIGNvbW1lbnRzIG9u IHRoZSB1cGRhdGVzIHZlcnNpb24gb2YgdGhpcw0KDQogICAgICAgID4gZHJhZnQ/DQoNCiAgICAg ICAgPj4gV2UgaGF2ZSBhbHNvIGFkZGVkIHRoZSBwcm90b2NvbCBleHRlbnNpb24gcHJvcG9zYWwg Zm9yIE9TUEZ2My4NCg0KICAgICAgICA+Pg0KDQogICAgICAgID4+IFRoZSB1cGRhdGUgdmVyc2lv biBvZiB0aGlzIGRyYWZ0IGNhbiByZWZlciB0bw0KDQogICAgICAgID4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UN Cg0KICAgICAgICA+PiAtYXR0cmlidXRlDQoNCiAgICAgICAgPj4gVGhhbmtzIGluIGFkdmFuY2Uu DQoNCiAgICAgICAgPj4NCg0KICAgICAgICA+Pg0KDQogICAgICAgID4+IEJlc3QgUmVnYXJkcw0K DQogICAgICAgID4+DQoNCiAgICAgICAgPj4gQWlqdW4gV2FuZw0KDQogICAgICAgID4+IENoaW5h IFRlbGVjb20NCg0KICAgICAgICA+Pg0KDQogICAgICAgID4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KDQogICAgICAgID4+PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddDQoNCiAgICAgICAgPj4+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI4LCAyMDIwIDM6 MTcgUE0NCg0KICAgICAgICA+Pj4gVG86IFpoaWJvIEh1IDxodXpoaWJvQGh1YXdlaS5jb208bWFp bHRvOmh1emhpYm9AaHVhd2VpLmNvbT4+OyBHeWFuIE1pc2hyYQ0KDQogICAgICAgID4+PiA8Z3lh bi5zLm1pc2hyYUB2ZXJpem9uLmNvbTxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbT4+ OyBBaWp1biBXYW5nIDx3YW5nYWozQGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86d2FuZ2FqM0BjaGlu YXRlbGVjb20uY24+PjsNCg0KICAgICAgICA+Pj4gR3lhbiBTLiBNaXNocmEgPGd5YW4ucy5taXNo cmFAdmVyaXpvbi5jb208bWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20+Pg0KDQogICAg ICAgID4+PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQoNCiAgICAgICAg Pj4+IGRyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQNCg0K ICAgICAgICA+Pj4NCg0KICAgICAgICA+Pj4NCg0KICAgICAgICA+Pj4gQSBuZXcgdmVyc2lvbiBv ZiBJLUQsDQoNCiAgICAgICAgPj4+IGRyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0 dHJpYnV0ZS0wNC50eHQNCg0KICAgICAgICA+Pj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBBaWp1biBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCg0KICAgICAgICA+Pj4g cmVwb3NpdG9yeS4NCg0KICAgICAgICA+Pj4NCg0KICAgICAgICA+Pj4gTmFtZTogICAgICAgICAg ICAgICBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUNCg0KICAgICAg ICA+Pj4gUmV2aXNpb246ICAgMDQNCg0KICAgICAgICA+Pj4gVGl0bGU6ICAgICAgICAgUGFzc2l2 ZSBJbnRlcmZhY2UgQXR0cmlidXRlDQoNCiAgICAgICAgPj4+IERvY3VtZW50IGRhdGU6ICAgICAg IDIwMjAtMDktMjgNCg0KICAgICAgICA+Pj4gR3JvdXA6ICAgICAgICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQoNCiAgICAgICAgPj4+IFBhZ2VzOiAgICAgICAgICAgICAgIDcNCg0KICAg ICAgICA+Pj4gVVJMOg0KDQogICAgICAgID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFm dC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUtMDQuDQoNCiAgICAgICAgPj4+ IHR4dA0KDQogICAgICAgID4+PiBTdGF0dXM6DQoNCiAgICAgICAgPj4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0dA0K DQogICAgICAgID4+PiByDQoNCiAgICAgICAgPj4+IGlidXRlLw0KDQogICAgICAgID4+PiBIdG1s aXplZDoNCg0KICAgICAgICA+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjDQoNCiAgICAgICAgPj4+IGUNCg0KICAg ICAgICA+Pj4gLWF0dHJpYnV0DQoNCiAgICAgICAgPj4+IGUNCg0KICAgICAgICA+Pj4gSHRtbGl6 ZWQ6DQoNCiAgICAgICAgPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5n LWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dA0KDQogICAgICAgID4+PiBlDQoNCiAgICAg ICAgPj4+IC0wNA0KDQogICAgICAgID4+PiBEaWZmOg0KDQogICAgICAgID4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2Ut YXQNCg0KICAgICAgICA+Pj4gdA0KDQogICAgICAgID4+PiByaWJ1dGUtMDQNCg0KICAgICAgICA+ Pj4NCg0KICAgICAgICA+Pj4gQWJzdHJhY3Q6DQoNCiAgICAgICAgPj4+ICAgICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgdGhlIG1lY2hhbmlzbSB0aGF0IGNhbiBiZSB1c2VkIHRvDQoNCiAgICAg ICAgPj4+ICAgICAgZGlmZmVyZW50aWF0ZSB0aGUgcGFzc2l2ZSBpbnRlcmZhY2VzIGZyb20gdGhl IG5vcm1hbCBpbnRlcmZhY2VzDQoNCiAgICAgICAgPj4+ICAgICAgd2l0aGluIElTSVMgb3IgT1NQ RiBkb21haW4uDQoNCiAgICAgICAgPj4+DQoNCiAgICAgICAgPj4+DQoNCiAgICAgICAgPj4+DQoN CiAgICAgICAgPj4+DQoNCiAgICAgICAgPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQoNCiAgICAgICAgPj4+IHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dA0KDQogICAgICAgID4gdG9vbHMuaWV0Zi5vcmcuDQoNCiAgICAgICAgPj4+DQoNCiAgICAgICAg Pj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCiAgICAgICAgPj4+DQoNCiAgICAgICAgPj4NCg0K ICAgICAgICA+Pg0KDQogICAgICAgID4+DQoNCiAgICAgICAgPj4NCg0KICAgICAgICA+DQoNCiAg ICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQogICAgICAgID4gTHNyIG1haWxpbmcgbGlzdA0KDQogICAgICAgID4gTHNyQGlldGYub3JnPG1h aWx0bzpMc3JAaWV0Zi5vcmc+DQoNCiAgICAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xzcg0KDQogICAgICAgID4NCg0KICAgICAgICA+DQoNCiAgICAgICAgPg0K DQoNCg0KICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQogICAgICAgIExzciBtYWlsaW5nIGxpc3QNCg0KICAgICAgICBMc3JAaWV0Zi5vcmc8 bWFpbHRvOkxzckBpZXRmLm9yZz4NCg0KICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xzcg0KDQoNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCiAgICBMc3IgbWFpbGluZyBsaXN0DQoNCiAgICBMc3JAaWV0 Zi5vcmc8bWFpbHRvOkxzckBpZXRmLm9yZz4NCg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHNyDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KTHNyIG1haWxpbmcgbGlzdA0KDQpMc3JAaWV0Zi5vcmc8 bWFpbHRvOkxzckBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sc3INCg== --_000_4C885AD13E04476BB779C83023B9B7D5ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0K CWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6RGVuZ1hpYW47fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFp blRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJZm9udC1zaXplOjEw LjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNwZWFraW5nIGFzIFdHIG1lbWJlcjo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+SGkgQWlqdW4sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkFpanVuIFdhbmcgJmx0O3dhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlRodXJzZGF5LCBPY3RvYmVyIDgsIDIwMjAgYXQgMTE6MDkgUE08YnI+DQo8Yj5Ubzog PC9iPkFjZWUgTGluZGVtICZsdDthY2VlQGNpc2NvLmNvbSZndDssICZxdW90O1BldGVyIFBzZW5h ayAocHBzZW5haykmcXVvdDsgJmx0O3Bwc2VuYWtAY2lzY28uY29tJmd0OywgJ0FpanVuIFdhbmcn ICZsdDt3YW5nYWozQGNoaW5hdGVsZWNvbS5jbiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2xz ckBpZXRmLm9yZyZxdW90OyAmbHQ7bHNyQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SRTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1s c3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SGksIEFjZWU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+U29ycnkgZm9yIHRoZSBwcmV2aW91cyBwcnVu ZWQgbWFpbC4gTGV0J3MgcmVwbHkgeW91IGFnYWluIGFsb25nIHlvdXIgb3JpZ2luYWwgcXVlc3Rp b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+UGxlYXNlIHNlZSBpbmxpbmUuW1dBSl08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPGJyPg0KRnJvbTogbHNyLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFjZWUgTGluZGVtIChhY2Vl KTxicj4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDMwLCAyMDIwIDc6NDcgUE08YnI+DQpU bzogQWlqdW4gV2FuZyAmbHQ7d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbiZndDs7IFBldGVyIFBz ZW5hayAocHBzZW5haykgJmx0O3Bwc2VuYWtAY2lzY28uY29tJmd0OzsgJ0FpanVuIFdhbmcnICZs dDt3YW5nYWozQGNoaW5hdGVsZWNvbS5jbiZndDs8YnI+DQpDYzogbHNyQGlldGYub3JnPGJyPg0K U3ViamVjdDogUmU6IFtMc3JdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5IaSBBaWp1biwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T3RoZXIgdGhhbiB5b3VyIGlsbC1jb25jZWl2 ZWQgdG9wb2xvZ3kgZGlzY292ZXJ5IGhldXJpc3RpYzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPltXQUpdIFRoZSB0b3BvbG9n eSBkaXNjb3ZlcnkgaGV1cmlzdGljIGlzIG5vdCBzdWl0YWJsZSBmb3IgdGhlIGNvcm5lciB1c2Ug Y2FzZSB3aGVuIHRoZSB1bm51bWJlcmVkIGludGVyZmFjZSBpcyB1c2VkLCBhcyBleHBsYWluZWQg aW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxzci1v c3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2I2FwcGVuZGl4LUIiPg0KaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYjYXBwZW5k aXgtQjwvYT4uICZuYnNwO0lmIHlvdSBkb248c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPuKAmTwvc3Bhbj50IGFncmVlLCB3b3VsZCB5b3UgbGlrZSB0byBp bGx1c3RyYXRlIG90aGVyIG5vbi1hcHBsaWNhYmxlIHNjZW5hcmlvcz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmlnaHQg4oCTIGFuZCBub2JvZHkgb3RoZXIgdGhh biB5b3Vyc2VsZiBiZWxpZXZlcyB0aGUgSUdQcyBzaG91bGQgYmUgbW9kaWZpZWQgdG8gZXhwb3Nl IHRoZSBhYnN0cmFjdGVkIHRvcG9sb2d5IG9mIGFuIGFyZWEgb3V0c2lkZSB0aGF0IGFyZWEuIFlv dSBjYW4gc29sdmUgdGhlIHByb2JsZW0gd2l0aCBCR1AtTFMgc2Vzc2lvbihzKSBiZXR3ZWVuIHRo ZSByb3V0ZXINCiB3aXRoIGEgQkdQLUxTIHNlc3Npb24gdG8gdGhlIGNvbnRyb2xsZXIgYW5kIGEg cm91dGVyIGluIGVhY2ggYXJlYSB3L28gJm5ic3A7YSByb3V0ZXIgd2l0aCBhIEJHUC1MUyBzZXNz aW9uIHRvIHRoZSBjb250cm9sbGVyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPndo YXQgb3RoZXIgcG9zc2libGUgcmVhc29uIHdvdWxkIHRoZXJlIGJlIGZvciBhc3NvY2lhdGluZyB0 aGUgcGFzc2l2ZSBhdHRyaWJ1dGUgd2l0aCBhIHByZWZpeD8NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+W1dBSl0gVG8ga25vdyB0aGUgYm91bmRhcnkgb2YgdGhlIElHUCBkb21h aW4uIEFmdGVyIGtub3dpbmcgdGhlIGJvdW5kYXJ5LCB0aGUgY29udHJvbGxlciBjYW4gc2FmZWx5 IGFwcGx5IGFuZCBjaGVjayB0aGUgbmV0d29yayBzZWN1cml0eSBwb2xpY3ksIHRoZSBpbmJvdW5k IHRyYWZmaWMgY29udHJvbCBwb2xpY3kgZXRjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+SXQgcmVhbGx5IGlzbuKAmXQgcmVsZXZhbnQsIGJ1dCBJIGhh dmUgdG8gYXNr4oCmLiBIb3cgZG9lcyB0aGUgcHJlc2VuY2Ugb2YgYSBwcmVmaXggYXNzb2NpYXRl ZCB3aXRoIGEgcGFzc2l2ZSBpbnRlcmZhY2UgYWxsb3cgeW91IHRvIG1ha2UgdGhpcyBkZWR1Y3Rp b24/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFua3MsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QWNl ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIDkvMjkvMjAsIDEwOjM5IFBNLCAmcXVvdDtBaWp1 biBXYW5nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5j biI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPndh bmdhaWp1bkB0c2luZ2h1YS5vcmcuY248L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpLCBBY2VlIGFuZCBQZXRlcjo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDsmbmJzcDsmbmJzcDsgUGFzc2l2ZSBpbnRlcmZhY2UgaXMgbWFpbmx5IHVzZWQgYXQg dGhlIGVkZ2Ugb2YgdGhlIG5ldHdvcmssIHdoZXJlIHRoZSB1bm51bWJlcmVkIGludGVyZmFjZSB3 aWxsIG5vdCBiZSB1c2VkLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QW5kIHRo ZSBpbmZvcm1hdGlvbiB0byBmbGFnIHRoZSBwYXNzaXZlIGludGVyZmFjZXMgaXMgZm9yIHBvc2l0 aW9uaW5nIHRoZSBhcmVhIGJvdW5kYXJ5LCBub3QgY29uZmxpY3Qgd2l0aCB0aGUgYWJzdHJhY3Qg Y2FwYWJpbGl0aWVzIG9mIHRoZSBhcmVhIGluc2lkZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgQmVzdCBSZWdhcmRzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFpanVuIFdhbmc8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm bmJzcDsmbmJzcDsgQ2hpbmEgVGVsZWNvbTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOyBGcm9tOiA8YSBocmVmPSJtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmciPg0KPHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmxzci1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT4gWzxhIGhyZWY9Im1haWx0bzpsc3ItYm91bmNlc0BpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pm1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSBPbiBCZWhhbGYgT2YgQWNl ZSBMaW5kZW0gKGFjZWUpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlbnQ6IFR1ZXNkYXks IFNlcHRlbWJlciAyOSwgMjAyMCA5OjE2IFBNPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRv OiBQZXRlciBQc2VuYWsgJmx0OzxhIGhyZWY9Im1haWx0bzpwcHNlbmFrPTQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+cHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+Jmd0 OzsgQWlqdW4gV2FuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcu Y24iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj53 YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9zcGFuPjwvYT4mZ3Q7Ow0KICdBaWp1biBXYW5nJyAm bHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNuIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+d2FuZ2FqM0BjaGluYXRlbGVj b20uY248L3NwYW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgQ2M6IDxhIGhy ZWY9Im1haWx0bzpsc3JAaWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmxzckBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IFN1YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUtMDQu dHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNwZWFraW5nIGFz IFdHIG1lbWJlcjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgSGkg QWlqdW4sIFBldGVyLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJIGFncmVlIHdp dGggUGV0ZXIgLSBvbmUgb2YgdGhlIG1haW4gbW90aXZhdGlvbnMgZm9yIGhhdmluZyBhcmVhcyBp cyB0byBhYnN0cmFjdCB0aGUgdG9wb2xvZ3kgd2l0aGluIHRoZSBhcmVhLiBOb3cgeW91J3JlIHRy eWluZyB0byBzdXBwbGFudCB0aGlzICZuYnNwOy0gb25lIHRvcG9sb2dpY2FsIGRldGFpbCBhdCBh IHRpbWUgd2l0aCBpbGwtY29uY2VpdmVkIElHUA0KIGZlYXR1cmVzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyBUaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFjZWU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgT24gOS8yOS8yMCwgNToxNSBBTSwg JnF1b3Q7THNyIG9uIGJlaGFsZiBvZiBQZXRlciBQc2VuYWsmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZyUyMG9uJTIwYmVoYWxmJTIwb2YlMjBwcHNlbmFrPTQw Y2lzY28uY29tQGRtYXJjLmlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+bHNyLWJvdW5jZXNAaWV0Zi5vcmcNCiBvbiBiZWhhbGYgb2Yg cHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSGkgQWlqdW4sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIDI5LzA5LzIwMjAgMTE6MDcsIEFpanVuIFdh bmcgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgSGksIFBldGVyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDEuIEZvciBC R1AtTFMgZGVwbG95bWVudCwgdGhlcmUgbm9ybWFsbHkgb25seSBiZSBvbmUgcm91dGVyIHRoYXQg d2l0aGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IElHUCBkb21haW4gdG8gcmVwb3J0IHRoZSB0b3BvbG9neSBpbmZvcm1hdGlvbiwg dGhpcyByb3V0ZXIgc2hvdWxkIGtub3cgc3VjaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHBhc3NpdmUgbGlua3Mgd2hpY2ggZXhpc3RzIG1h aW5seSBvbiBvdGhlciBib3JkZXIgcm91dGVycyB2aWEgdGhlIElHUDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHByb3RvY29sLiBUaGlzIGlz IG1haW4gcmVhc29uIHRvIGV4dGVuc2lvbiB0aGUgSUdQIHByb3RvY29sLiAmZ3Q7IDIuIEZvciB0 aGUgc29sdXRpb24sIG5vcm1hbGx5LCB0aGUgbGluayB3aXRoaW4gdGhlIElHUCBjb25uZWN0IHR3 bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ZW5kcywgYnV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgcGFzc2l2ZSBpbnRlcmZhY2UgaXMgc3BlY2lhbCBhbmQgbm90IGZhbGwgaW4g dGhpcyBzcGFjZS4gV2UgaGF2ZSBzdHVkaWVkIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGN1cnJlbnQgVExWcyB0aGF0IGZvciBsaW5r LCBhbmQgZmluZCBubyBzdWl0YWJsZSBjb250YWluZXIgdG8gYXBwZW5kIHRoaXM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpbmZvcm1hdGlv bi4gVGhpcyBpcyB0aGUgcmVhc29uIHRoYXQgd2Ugc2VsZWN0IHRoZSBUTFZzIHRoYXQgYXNzb2Np YXRlZCB3aXRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgUHJlZml4LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZiB0aGUgbGluayBpcyB1bm51bWJlcmVkLCB5b3Vy IHNvbHV0aW9uIGRvZXMgbm90IHdvcmsuIEFzIEkgc2FpZCwgaWYNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3lvdSBuZWVkIGEga25vd2xl ZGdlIGFib3V0IHRoZSBsaW5rLCB5b3UgY2FuIG5vdCBhZHZlcnRpc2UgaXQgYXMgYSBwcmVmaXgu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUGV0ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7Jmd0O0Zy b20gb3RoZXIgUE9WLCB0aGUgT1NQRnYzIGRlZmluZXMgbm93IHRoZSAmcXVvdDtJbnRyYS1BcmVh LVByZWZpeCBMU0EmcXVvdDssIHdoaWNoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgaXNvbGF0ZSB0aGUgcHJlZml4IGluZm9ybWF0aW9uIHRo YXQgYXNzb2NpYXRlZCB3aXRoIGxpbmsgaW50byB0aGlzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgY29udGFpbmVyLCBjb250YWlucyB0aGUg c3R1YiBsaW5rLCBsb2NhbCBpbnRlcmZhY2UgaW5mb3JtYXRpb24gZXRjLiBQdXQgc3VjaDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGF0dHJp YnV0ZSBhbG9uZyB3aXRoIHRoZSBwcmVmaXggaXMgdGhlbiBhY2NlcHRhYmxlPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBC ZXN0IFJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmZ3Q7IEFpanVuIFdhbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBDaGluYSBUZWxlY29tPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZyI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bHNy LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPiBbPGEgaHJlZj0ibWFpbHRvOmxzci1ib3VuY2Vz QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+bWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dIE9uIEJlaGFsZiBP ZiBQZXRlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IFBzZW5hazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyOSwgMjAyMCA0OjI5IFBNPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgVG86 IEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbiI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPndhbmdh ajNAY2hpbmF0ZWxlY29tLmNuPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpsc3JA aWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmxzckBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgU3ViamVjdDogUmU6IFtMc3JdIEZXOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2Ut YXR0cmlidXRlLTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZndDsgSGkgQWlqdW4sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBoZXJlJ3MgbXkgY29tbWVudHM6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0 OyBUaGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0IGlzIHRvIGFkdmVydGlzZSBwYXNzaXZlIGxpbmtz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZndDsgMS4gSSdtIG5vdCBzdXJlIHRoZSBwcm9ibGVtIG5lZWRzIHRvIGJlIHNvbHZlZCBieSBJ R1BzLiBJIHRlbmQgdG8gYmVsaWV2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGlldGYtaWRyLWJncGxzLWludGVyLWFzLXRvcG9sb2d5LWV4 dCBpcyBzdWZmaWNpZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZndDsgMi4gdGhlIHNvbHV0aW9uIHRoYXQgeW91IHByb3Bvc2VkIGlz IHdyb25nLiBZb3UgYXJlIHRyeWluZyB0byBkZXJpdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0b3BvbG9naWNhbCBkYXRhIGFib3V0IHRo ZSBwYXNzaXZlIGxpbmtzIGZyb20gdGhlIHByZWZpeCBhZHZlcnRpc2VtZW50LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFRoaXMgaXMgc2Vt YW50aWNhbGx5IGluY29ycmVjdCBhbmQgb25seSB3b3JrcyB1bmRlciB2ZXJ5IHNwZWNpZmljIGNv bmRpdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBJZiB5b3UgbmVlZCB0byBhZHZlcnRpc2UgYSBsaW5rLCBhZHZlcnRpc2UgaXQgYXMg YSAmcXVvdDtzcGVjaWFsJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgbGluaywgbm90IGFzIGEgJnF1b3Q7c3BlY2lhbCZxdW90OyBw cmVmaXguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jmd0OyB0aGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgUGV0ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IE9uIDI5LzA5LzIwMjAgMDM6MTcsIEFpanVuIFdh bmcgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7IEhpLCBQZXRlcjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgV291bGQgeW91IGxpa2UgdG8gcmV2aWV3IGFu ZCBnaXZlIGNvbW1lbnRzIG9uIHRoZSB1cGRhdGVzIHZlcnNpb24gb2YgdGhpczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGRyYWZ0PzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBX ZSBoYXZlIGFsc28gYWRkZWQgdGhlIHByb3RvY29sIGV4dGVuc2lvbiBwcm9wb3NhbCBmb3IgT1NQ RnYzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyBUaGUgdXBkYXRlIHZlcnNpb24gb2YgdGhpcyBkcmFmdCBjYW4gcmVmZXIgdG88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13 YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZTwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IC1hdHRy aWJ1dGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsgVGhhbmtzIGluIGFkdmFuY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IEJlc3QgUmVnYXJkczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBB aWp1biBXYW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7IENoaW5hIFRlbGVjb208bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPiBbPGEgaHJlZj0ibWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+ PC9hPl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jmd0OyZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI4LCAyMDIwIDM6MTcgUE08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7IFRvOiBaaGlibyBIdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1emhpYm9AaHVhd2VpLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh1emhp Ym9AaHVhd2VpLmNvbTwvc3Bhbj48L2E+Jmd0OzsgR3lhbiBNaXNocmE8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmd5YW4ucy5taXNocmFAdmVyaXpvbi5j b208L3NwYW4+PC9hPiZndDs7IEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWoz QGNoaW5hdGVsZWNvbS5jbiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPC9zcGFuPjwvYT4mZ3Q7OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsgR3lhbiBTLiBNaXNocmEgJmx0OzxhIGhyZWY9Im1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6 b24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgZHJhZnQtd2FuZy1sc3ItcGFz c2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBBIG5l dyB2ZXJzaW9uIG9mIEktRCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGRyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNl LWF0dHJpYnV0ZS0wNC50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgQWlqdW4gV2FuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyByZXBvc2l0b3J5Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmZ3Q7IE5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LXdhbmct bHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgUmV2aXNpb246Jm5ic3A7Jm5i c3A7IDA0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyBUaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUGFzc2l2ZSBJbnRlcmZhY2UgQXR0cmlidXRlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBEb2N1bWVudCBk YXRlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDIwLTA5LTI4PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyBHcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyBQYWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgVVJMOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtd2FuZy1sc3ItcGFz c2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC13 YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUtMDQ8L3NwYW4+PC9hPi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 IHR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsgU3RhdHVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0Ij4NCjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1h dHQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsgcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgaWJ1dGUvPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBIdG1saXplZDo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt d2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhYyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7IC1hdHRyaWJ1dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgSHRtbGl6ZWQ6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRl cmZhY2UtYXR0cmlidXQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5nLWxzci1w YXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyAtMDQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7IERpZmY6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXQiPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdDwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyB0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyByaWJ1dGUtMDQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBBYnN0cmFjdDo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHRoZSBtZWNoYW5pc20gdGhhdCBjYW4gYmUgdXNlZCB0bzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgZGlmZmVyZW50aWF0ZSB0aGUgcGFzc2l2ZSBpbnRlcmZhY2VzIGZy b20gdGhlIG5vcm1hbCBpbnRlcmZhY2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB3aXRoaW4gSVNJUyBvciBPU1BGIGRvbWFpbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsgVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IExzciBtYWlsaW5nIGxpc3Q8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8 YSBocmVmPSJtYWlsdG86THNyQGlldGYub3JnIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5Mc3JAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMc3IgbWFpbGluZyBsaXN0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhy ZWY9Im1haWx0bzpMc3JAaWV0Zi5vcmciPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkxzckBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xzcjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IExzciBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4m bmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkxzckBpZXRmLm9yZyI+DQo8c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+THNyQGlldGYub3Jn PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3IiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHNyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkxzciBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YSBocmVmPSJtYWlsdG86THNyQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ THNyQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzciI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHNyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_4C885AD13E04476BB779C83023B9B7D5ciscocom_-- From nobody Fri Oct 9 18:58:31 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3B43A1634 for ; Fri, 9 Oct 2020 18:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 z9VofriV7H3L for ; Fri, 9 Oct 2020 18:58:23 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BAA3A1267 for ; Fri, 9 Oct 2020 18:58:22 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 78D754580F; Sat, 10 Oct 2020 09:58:17 +0800 (CST) From: "Aijun Wang" To: "'Acee Lindem \(acee\)'" , "'Peter Psenak \(ppsenak\)'" , "'Aijun Wang'" Cc: References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> In-Reply-To: <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> Date: Sat, 10 Oct 2020 09:58:16 +0800 Message-ID: <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008A_01D69EEB.E03BB1C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIJ+mWorx9ReexromEfqpSgpX3kFwEFLd5+AaLg+ScCZ8Mz1AFBnbZFAnYY+uECbteHkQJR6V6DAmQjRUmoqetLAA== Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSR9LSUIfHh9KThlJVkpNS0lJQk5LQkxDQ0JVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6N006Sxw6Sj8oCkMOCjY6KzBC ATIKC0JVSlVKTUtJSUJOS0JDT01NVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUxOSEpDNwY+ X-HM-Tid: 0a75103ae9299865kuuu78d754580f Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 01:58:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008A_01D69EEB.E03BB1C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Acee: =20 From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Acee Lindem (acee) Sent: Saturday, October 10, 2020 3:48 AM To: Aijun Wang ; Peter Psenak (ppsenak) = ; 'Aijun Wang' Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Speaking as WG member: =20 Hi Aijun,=20 =20 From: Aijun Wang > Date: Thursday, October 8, 2020 at 11:09 PM To: Acee Lindem >, "Peter Psenak = (ppsenak)" >, 'Aijun Wang' = > Cc: "lsr@ietf.org " > Subject: RE: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Hi, Acee: Sorry for the previous pruned mail. Let's reply you again along your = original question. Please see inline.[WAJ] =20 -----Original Message----- = = =20 From: lsr-bounces@ietf.org = [mailto:lsr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Wednesday, September 30, 2020 7:47 PM To: Aijun Wang >; Peter Psenak (ppsenak) = >; 'Aijun Wang' = > Cc: lsr@ietf.org =20 Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Hi Aijun,=20 Other than your ill-conceived topology discovery heuristic [WAJ] The topology discovery heuristic is not suitable for the corner = use case when the unnumbered interface is used, as explained in = https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appe= ndix-B. If you don=E2=80=99t agree, would you like to illustrate other = non-applicable scenarios? =20 Right =E2=80=93 and nobody other than yourself believes the IGPs should = be modified to expose the abstracted topology of an area outside that = area.=20 [WAJ] The modification doesn=E2=80=99t change the way and complexity of = route calculation within IGP. It just piggyback some extra information, = the bulk of the reconstruction work is done by the controller. Such = extra information can also have other usage, as described in = https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#sect= ion-1 And, the proposal described in = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-at= tribute-04 is different with the problem you concerned. It has no = relation with the abstracted topology of an area. Maybe you are = confused by these two drafts? =20 =20 You can solve the problem with BGP-LS session(s) between the router with = a BGP-LS session to the controller and a router in each area w/o a = router with a BGP-LS session to the controller.=20 [WAJ] This is possible, but not efficient. For operation, we must also = consider the configuration/administration overhead. BGP-LS is designed = mainly for the northbound protocol, not east-west protocol. =20 what other possible reason would there be for associating the passive = attribute with a prefix?=20 [WAJ] To know the boundary of the IGP domain. After knowing the = boundary, the controller can safely apply and check the network security = policy, the inbound traffic control policy etc. =20 It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How does = the presence of a prefix associated with a passive interface allow you = to make this deduction?=20 [WAJ] Passive interfaces are deployed mainly at the boundary of IGP = domain. Is there any other exception? =20 Thanks, Acee =20 Thanks, Acee =20 On 9/29/20, 10:39 PM, "Aijun Wang" < = wangaijun@tsinghua.org.cn> wrote: =20 Hi, Acee and Peter: Passive interface is mainly used at the edge of the network, where = the unnumbered interface will not be used.=20 And the information to flag the passive interfaces is for = positioning the area boundary, not conflict with the abstract = capabilities of the area inside. =20 =20 Best Regards =20 Aijun Wang China Telecom =20 -----Original Message----- From: lsr-bounces@ietf.org [ = mailto:lsr-bounces@ietf.org] On Behalf Of = Acee Lindem (acee) Sent: Tuesday, September 29, 2020 9:16 PM To: Peter Psenak < = ppsenak=3D40cisco.com@dmarc.ietf.org>; Aijun Wang < = wangaijun@tsinghua.org.cn>; 'Aijun = Wang' < wangaj3@chinatelecom.cn> Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Speaking as WG member: =20 Hi Aijun, Peter,=20 I agree with Peter - one of the main motivations for having areas is = to abstract the topology within the area. Now you're trying to supplant = this - one topological detail at a time with ill-conceived IGP = features. Thanks, Acee =20 On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" < = lsr-bounces@ietf.org on behalf of = ppsenak=3D40cisco.com@dmarc.ietf.org> wrote: =20 Hi Aijun, =20 On 29/09/2020 11:07, Aijun Wang wrote: > Hi, Peter: >=20 > Thanks for your comments. > 1. For BGP-LS deployment, there normally only be one router = that within the > IGP domain to report the topology information, this router = should know such > passive links which exists mainly on other border routers via = the IGP > protocol. This is main reason to extension the IGP protocol. > = 2. For the solution, normally, the link within the IGP connect two=20 ends, but > passive interface is special and not fall in this space. We = have studied the > current TLVs that for link, and find no suitable container to = append this > information. This is the reason that we select the TLVs that = associated with > Prefix. =20 if the link is unnumbered, your solution does not work. As I = said, if=20 you need a knowledge about the link, you can not advertise it as = a prefix. =20 thanks, Peter =20 =20 >=20 >>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix = LSA", which > isolate the prefix information that associated with link into = this > container, contains the stub link, local interface information = etc. Put such > attribute along with the prefix is then acceptable? >=20 >=20 > Best Regards >=20 > Aijun Wang > China Telecom >=20 > -----Original Message----- > From: lsr-bounces@ietf.org [ = mailto:lsr-bounces@ietf.org] On Behalf Of = Peter > Psenak > Sent: Tuesday, September 29, 2020 4:29 PM > To: Aijun Wang < = wangaj3@chinatelecom.cn> > Cc: lsr@ietf.org > Subject: Re: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt >=20 > Hi Aijun, >=20 > here's my comments: >=20 > The purpose of this draft is to advertise passive links. >=20 > 1. I'm not sure the problem needs to be solved by IGPs. I tend = to believe > ietf-idr-bgpls-inter-as-topology-ext is sufficient. >=20 > 2. the solution that you proposed is wrong. You are trying to = derive > topological data about the passive links from the prefix = advertisement. > This is semantically incorrect and only works under very = specific condition. > If you need to advertise a link, advertise it as a "special" > link, not as a "special" prefix. >=20 > thanks, > Peter >=20 > On 29/09/2020 03:17, Aijun Wang wrote: >> Hi, Peter: >> >> Would you like to review and give comments on the updates = version of this > draft? >> We have also added the protocol extension proposal for = OSPFv3. >> >> The update version of this draft can refer to >> = = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface >> -attribute >> Thanks in advance. >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >>> -----Original Message----- >>> From: = internet-drafts@ietf.org [ = mailto:internet-drafts@ietf.org] >>> Sent: Monday, September 28, 2020 3:17 PM >>> To: Zhibo Hu < = huzhibo@huawei.com>; Gyan Mishra >>> < = gyan.s.mishra@verizon.com>; Aijun Wang < = wangaj3@chinatelecom.cn>; >>> Gyan S. Mishra < = gyan.s.mishra@verizon.com> >>> Subject: New Version Notification for >>> draft-wang-lsr-passive-interface-attribute-04.txt >>> >>> >>> A new version of I-D, >>> draft-wang-lsr-passive-interface-attribute-04.txt >>> has been successfully submitted by Aijun Wang and posted to = the IETF >>> repository. >>> >>> Name: = draft-wang-lsr-passive-interface-attribute >>> Revision: 04 >>> Title: Passive Interface Attribute >>> Document date: 2020-09-28 >>> Group: Individual Submission >>> Pages: 7 >>> URL: >>> = = https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04. >>> txt >>> Status: >>> = = https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att >>> r >>> ibute/ >>> Htmlized: >>> = = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac >>> e >>> -attribut >>> e >>> Htmlized: >>> = = https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut >>> e >>> -04 >>> Diff: >>> = = https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-interface-at >>> t >>> ribute-04 >>> >>> Abstract: >>> This document describes the mechanism that can be used = to >>> differentiate the passive interfaces from the normal = interfaces >>> within ISIS or OSPF domain. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >> >> >> >> >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > = https://www.ietf.org/mailman/listinfo/lsr >=20 >=20 >=20 =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr =20 =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr ------=_NextPart_000_008A_01D69EEB.E03BB1C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, = Acee:

 

<= b>From:<= /b> = lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Acee Lindem (acee)
Sent: Saturday, October 10, 2020 3:48 = AM
To: Aijun Wang <wangaijun@tsinghua.org.cn>; Peter = Psenak (ppsenak) <ppsenak@cisco.com>; 'Aijun Wang' = <wangaj3@chinatelecom.cn>
Cc: = lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification = for = draft-wang-lsr-passive-interface-attribute-04.txt

<= span lang=3DEN-US> 

Speaking as = WG member:

 

Hi Aijun, =

 

From: = Aijun Wang <wangaijun@tsinghua.org.cn&g= t;
Date: Thursday, October 8, 2020 at 11:09 PM
To: = Acee Lindem <acee@cisco.com>, "Peter = Psenak (ppsenak)" <ppsenak@cisco.com>, 'Aijun = Wang' <wangaj3@chinatelecom.cn>Cc: "lsr@ietf.org" <lsr@ietf.org>
Subject: RE: = [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Hi, Acee:

Sorry for the previous pruned mail. Let's reply you again = along your original question.

Please see inline.[WAJ]

 

-----Original = Message-----          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;         
From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On = Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 = PM
To: Aijun Wang <wangaijun@tsinghua.org.cn&g= t;; Peter Psenak (ppsenak) <ppsenak@cisco.com>; 'Aijun = Wang' <wangaj3@chinatelecom.cn>Cc: lsr@ietf.org
Subject: Re: = [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Hi Aijun,

Other than your ill-conceived topology discovery = heuristic

[WAJ] The topology discovery heuristic is not suitable for = the corner use case when the unnumbered interface is used, as explained = in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-or= iginator-06#appendix-B.  If you don=E2=80=99t = agree, would you like to illustrate other non-applicable = scenarios?

 

Right =E2=80=93 and nobody other = than yourself believes the IGPs should be modified to expose the = abstracted topology of an area outside that area.

[WAJ] =C2=A0The = modification doesn=E2=80=99t change the way and complexity of route = calculation within IGP. It just piggyback some extra information, the = bulk of the reconstruction work is done by the controller. =C2=A0Such = extra information can also have other usage, as described in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-ori= ginator-06#section-1

And, = the proposal described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-= passive-interface-attribute-04 is different with the problem you = concerned. =C2=A0It has no relation with the abstracted topology of an = area.=C2=A0 Maybe you are confused by these two = drafts?

 <= /span>

 <= /span>

You can solve the problem with = BGP-LS session(s) between the router with a BGP-LS session to the = controller and a router in each area w/o  a router with a BGP-LS = session to the controller.

[WAJ] This is = possible, but not efficient. For operation, we must also consider the = configuration/administration overhead. =C2=A0BGP-LS is designed mainly = for the northbound protocol, not east-west protocol.=

 

what other possible reason would there be for associating = the passive attribute with a prefix?

[WAJ] To know the boundary of the IGP = domain. After knowing the boundary, the controller can safely apply and = check the network security policy, the inbound traffic control policy = etc.

 

It really isn=E2=80=99t = relevant, but I have to ask=E2=80=A6. How does the presence of a prefix = associated with a passive interface allow you to make this deduction? =

[WAJ] Passive = interfaces are deployed mainly at the boundary of IGP domain. =C2=A0Is = there any other exception?=

 

Thanks,

Acee

 

Thanks,

Acee

 

On 9/29/20, 10:39 PM, "Aijun Wang" <wangaijun@tsinghua.org.cn= > wrote:

 

    Hi, Acee and = Peter:

    Passive interface is mainly used at the = edge of the network, where the unnumbered interface will not be used. =

    And the information to flag the = passive interfaces is for positioning the area boundary, not conflict = with the abstract capabilities of the area = inside.

 

 

    Best Regards

 

    Aijun Wang

    China Telecom

 

    -----Original = Message-----

    From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.o= rg] On Behalf Of Acee Lindem (acee)

    Sent: Tuesday, September 29, 2020 9:16 = PM

    To: Peter Psenak <ppsenak=3D40cisco.com@dma= rc.ietf.org>; Aijun Wang <wangaijun@tsinghua.org.cn= >; 'Aijun Wang' <wangaj3@chinatelecom.cn>

    Cc: lsr@ietf.org

    Subject: Re: [Lsr] FW: New Version = Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

    Speaking as WG = member:

 

    Hi Aijun, Peter, =

    I agree with Peter - one of the = main motivations for having areas is to abstract the topology within the = area. Now you're trying to supplant this  - one topological detail = at a time with ill-conceived IGP features.

    Thanks,

    Acee

 

    On 9/29/20, 5:15 AM, "Lsr on behalf = of Peter Psenak" <lsr-bounces@ietf.org on = behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> = wrote:

 

        Hi = Aijun,

 

        On 29/09/2020 = 11:07, Aijun Wang wrote:

        > Hi, = Peter:

        > =

        > Thanks = for your comments.

        > 1. For = BGP-LS deployment, there normally only be one router that within = the

        > IGP domain = to report the topology information, this router should know = such

        > passive = links which exists mainly on other border routers via the = IGP

        > protocol. = This is main reason to extension the IGP protocol. > 2. For the = solution, normally, the link within the IGP connect two =

        ends, = but

        > passive = interface is special and not fall in this space. We have studied = the

        > current = TLVs that for link, and find no suitable container to append = this

        > = information. This is the reason that we select the TLVs that associated = with

        > = Prefix.

 

        if the link is = unnumbered, your solution does not work. As I said, if =

        you need a = knowledge about the link, you can not advertise it as a = prefix.

 

        = thanks,

        = Peter

 

 

        > =

        >>From= other POV, the OSPFv3 defines now the "Intra-Area-Prefix = LSA", which

        > isolate the = prefix information that associated with link into = this

        > container, = contains the stub link, local interface information etc. Put = such

        > attribute = along with the prefix is then acceptable?

        > =

        > =

        > Best = Regards

        > =

        > Aijun = Wang

        > China = Telecom

        > =

        > = -----Original Message-----

        > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.o= rg] On Behalf Of Peter

        > = Psenak

        > Sent: = Tuesday, September 29, 2020 4:29 PM

        > To: Aijun = Wang <wangaj3@chinatelecom.cn>

        > Cc: lsr@ietf.org

        > Subject: = Re: [Lsr] FW: New Version Notification for

        > = draft-wang-lsr-passive-interface-attribute-04.txt

        > =

        > Hi = Aijun,

        > =

        > here's = my comments:

        > =

        > The = purpose of this draft is to advertise passive = links.

        > =

        > 1. I'm = not sure the problem needs to be solved by IGPs. I tend to = believe

        > = ietf-idr-bgpls-inter-as-topology-ext is = sufficient.

        > =

        > 2. the = solution that you proposed is wrong. You are trying to = derive

        > topological = data about the passive links from the prefix = advertisement.

        > This is = semantically incorrect and only works under very specific = condition.

        > If you need = to advertise a link, advertise it as a = "special"

        > link, not = as a "special" prefix.

        > =

        > = thanks,

        > = Peter

        > =

        > On = 29/09/2020 03:17, Aijun Wang wrote:

        >> Hi, = Peter:

        = >>

        >> Would = you like to review and give comments on the updates version of = this

        > = draft?

        >> We have = also added the protocol extension proposal for = OSPFv3.

        = >>

        >> The = update version of this draft can refer to

        >> https://datatracker.ietf.= org/doc/html/draft-wang-lsr-passive-interface

        >> = -attribute

        >> Thanks = in advance.

        = >>

        = >>

        >> Best = Regards

        = >>

        >> Aijun = Wang

        >> China = Telecom

        = >>

        >>> = -----Original Message-----

        >>> = From: internet-drafts@ietf.org<= /span> [mailto:internet-drafts@ie= tf.org]

        >>> = Sent: Monday, September 28, 2020 3:17 PM

        >>> To: = Zhibo Hu <huzhibo@huawei.com= >; Gyan Mishra

        >>> = <gyan.s.mishra@verizon.com= >; Aijun Wang <wangaj3@chinatelecom.cn>;

        >>> = Gyan S. Mishra <gyan.s.mishra@verizon.com= >

        >>> = Subject: New Version Notification for

        >>> = draft-wang-lsr-passive-interface-attribute-04.txt

        = >>>

        = >>>

        >>> A = new version of I-D,

        >>> = draft-wang-lsr-passive-interface-attribute-04.txt

        >>> has = been successfully submitted by Aijun Wang and posted to the = IETF

        >>> = repository.

        = >>>

        >>> = Name:           &n= bsp;   = draft-wang-lsr-passive-interface-attribute

        >>> = Revision:   04

        >>> = Title:         Passive Interface = Attribute

        >>> = Document date:       = 2020-09-28

        >>> = Group:           &= nbsp;   Individual Submission

        >>> = Pages:           &= nbsp;   7

        >>> = URL:

        >>> https://www.ietf.org/id/d= raft-wang-lsr-passive-interface-attribute-04.

        >>> = txt

        >>> = Status:

        >>> https://datatracker.ietf.= org/doc/draft-wang-lsr-passive-interface-att=

        >>> = r

        >>> = ibute/

        >>> = Htmlized:

        >>> https://datatracker.ietf.= org/doc/html/draft-wang-lsr-passive-interfac=

        >>> = e

        >>> = -attribut

        >>> = e

        >>> = Htmlized:

        >>> https://tools.ietf.org/ht= ml/draft-wang-lsr-passive-interface-attribut=

        >>> = e

        >>> = -04

        >>> = Diff:

        >>> https://www.ietf.org/rfcd= iff?url2=3Ddraft-wang-lsr-passive-interface-at

        >>> = t

        >>> = ribute-04

        = >>>

        >>> = Abstract:

        = >>>      This document describes the = mechanism that can be used to

        = >>>      differentiate the passive = interfaces from the normal interfaces

        = >>>      within ISIS or OSPF = domain.

        = >>>

        = >>>

        = >>>

        = >>>

        >>> = 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.

        = >>>

        >>> The = IETF Secretariat

        = >>>

        = >>

        = >>

        = >>

        = >>

        > =

        > = _______________________________________________

        > Lsr mailing = list

        > Lsr@ietf.org

        > https://www.ietf.org/mail= man/listinfo/lsr

        > =

        > =

        > =

 

        = _______________________________________________

        Lsr mailing = list

        Lsr@ietf.org

        https://www.ietf.org/mail= man/listinfo/lsr

 

    = _______________________________________________

    Lsr mailing list

    Lsr@ietf.org

    https://www.ietf.org/mail= man/listinfo/lsr

 

 

_______________________________________________

Lsr mailing list

Lsr@ietf.org

https://www.ietf.org/mail= man/listinfo/lsr

------=_NextPart_000_008A_01D69EEB.E03BB1C0-- From nobody Fri Oct 9 20:05:44 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD4B3A175F for ; Fri, 9 Oct 2020 20:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 bBBjsWtS49bh for ; Fri, 9 Oct 2020 20:05:39 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C373A175D for ; Fri, 9 Oct 2020 20:05:39 -0700 (PDT) Received: from lhreml728-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 793C2E8D08F73064BA8A; Sat, 10 Oct 2020 04:05:37 +0100 (IST) Received: from dggeme753-chm.china.huawei.com (10.3.19.99) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Sat, 10 Oct 2020 04:05:36 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme753-chm.china.huawei.com (10.3.19.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sat, 10 Oct 2020 11:05:34 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Sat, 10 Oct 2020 11:05:34 +0800 From: "Dongjie (Jimmy)" To: Peter Psenak , Ron Bonica , Yingzhen Qu , Gyan Mishra CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAESbICAACKHAIAA7E2AgADTYwCAAWy/gIAAAz6AgAA7sgCAAOLhAIAAi8SAgAAopgCAA1loEIAFx4OAgAExPQA= Date: Sat, 10 Oct 2020 03:05:34 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 03:05:43 -0000 Hi Peter,=20 Thanks for your reply. It aligns with my understanding of FAD, which is jus= t a set of constraints for path computation. Thus one Flex-Algo ID could be= used with multiple different data planes. Is this understanding correct? If so, my question is about the scenario below:=20 A group of nodes in a network support FA-128, a sub-group of them bind FA-1= 28 to SR SIDs, another sub-group of them bind FA-128 to IP address. When on= e node compute an SR path to a destination, can it compute the path to only= pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bin= d FA-128 to IP address? If so, how could this node know the binding of FA t= o different data planes on other nodes? Best regards, Jie > -----Original Message----- > From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > Sent: Friday, October 9, 2020 11:58 PM > To: Dongjie (Jimmy) ; Ron Bonica > ; Yingzhen Qu > ; Gyan Mishra > Cc: lsr@ietf.org; Jeff Tantsura > Subject: Re: [Lsr] FW: New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt >=20 > Hi Jimmy, >=20 >=20 > On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > > Hi Ron, > > > > Thanks for explaining the difference between IP Flex-Algo and SR Flex-a= lgo. As > you said, the major difference is the data plane. > > > > If my understanding is correct, for one Flex-Algo to be used correctly,= the set > of nodes need to apply consistent constraints in computation, and bind th= e FAD > to the same data plane. > > > > Is it possible that different nodes may use the same Flex-Algo with dif= ferent > data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure IP > etc., or each Flex-Algo is always associated with only one data plane? In= the > former case, should the flex-algo definition also indicate the data plane= (s) to be > used with the flex-algo? >=20 > let me respond to this query, as this is not specific to Ron's draft. >=20 > FAD is data plane agnostic and is used by all of them. >=20 > thanks, > Peter >=20 > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica > >> Sent: Sunday, October 4, 2020 4:34 AM > >> To: Yingzhen Qu ; Peter Psenak > >> ; Gyan Mishra > >> Cc: lsr@ietf.org; Jeff Tantsura > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> Hi Yingzhen, > >> > >> IP Flexible Algorithms are like SR Flexible Algorithms in the followin= g > respects: > >> > >> - Links have IGP metrics, TE metrics, delay metrics and > >> administrative colors > >> - FADs define Flexible Algorithms > >> > >> More specifically, the FAD: > >> > >> - Indicates which metric type the Flexible Algorithm uses > >> - Specifies constraints in terms of link colors that are included or > >> excluded from the Flexible Algorithm. > >> > >> The significant difference between IP Flexible Algorithms and SR > >> Flexible Algorithms is: > >> > >> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators > >> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > >> > >> So, IP Flexible Algorithms can be deployed in any IP network, even in > >> the absence of SR. > >> > >> Ron > >> > >> > >> Juniper Business Use Only > >> > >> -----Original Message----- > >> From: Yingzhen Qu > >> Sent: Saturday, October 3, 2020 2:08 PM > >> To: Peter Psenak ; Gyan Mishra > >> ; Ron Bonica > >> Cc: lsr@ietf.org; Jeff Tantsura > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> [External Email. Be cautious of content] > >> > >> > >> Hi Peter, > >> > >> Using flex-algo, a SRv6 locator can be associated with a single algo, > >> which means an IPv6 or IPv4 address can also be associated with a > >> single algo. So my understanding is Ron's proposal is making the > configuration of flex-algo easier? > >> Instead of using the exclude or include list you can configure a > >> loopback address to a flex-algo directly? > >> > >> Thanks, > >> Yingzhen > >> > >> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: > >> > >> Hi Yingzhen, > >> > >> On 02/10/2020 22:15, Yingzhen Qu wrote: > >> > Hi Peter, > >> > > >> > My understanding of flex-algo is that for traffic destined to > >> a prefix on a particular algo, it can only be routed on routers > >> belong to that algo, which also means only routers in that algo > >> calculates how to reach that prefix and install it into the routing > >> table. It seems to me that using flex-algo (section 12 of the > >> draft) it's possible to have a loopback address associated with only > >> one algo, please correct me if I'm missing or misunderstood something. > >> > >> you are right. That is exactly what is being done for flex-algo w= ith > >> SRv6 - locator is associated with a single algo only. The proposa= l uses > >> the same concept. > >> > >> thanks, > >> Peter > >> > >> > > >> > Thanks, > >> > Yingzhen > >> > > >> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > >> >> ppsenak=3D40cisco.com@dmarc.ietf.org> > >> wrote: > >> > > >> > Gyan, > >> > > >> > On 02/10/2020 18:30, Gyan Mishra wrote: > >> > > All, > >> > > > >> > > With SRv6 and IP based flex algo a generic question as i= t > applies > >> to > >> > > both. Is it possible to have within a single IGP domain > different > >> sets > >> > > of nodes or segments of the network running different > >> algorithms. > >> > > >> > absolutely. > >> > > >> > > From > >> > > both drafts it sounds like all nodes have to agree on sa= me > >> algorithm > >> > > similar to concept of metric and reference bandwidth all > have to > >> have > >> > > the same style metric and play to the same sheet of musi= c. > >> > > >> > all participating nodes need to agree on the definition of= the > >> flex-algo > >> > and advertise the participation. That's it. > >> > > >> > > If there was > >> > > a way to use multiple algorithms simultaneously based on > SFC > >> or services > >> > > and instantiation of specific algorithm based on service= to > be > >> > > rendered. Doing so without causing a routing loop or su= b > >> optimal > >> > > routing. > >> > > >> > you can certainly use multiple algorithms simultaneously a= nd > use > >> algo > >> > specific paths to forward specific traffic over it. How th= at is > done > >> > from the forwarding perspective depends in which > forwarding > >> plane you > >> > use. Flex-algo control plane is independent of the forward= ing > >> plane. > >> > > >> > > >> > >I thought with flex algo that there exists a feature that= on > >> > > each hop there is a way to specify which algo to use hop= by > hop > >> similar > >> > > to a hop by hop policy based routing. > >> > > >> > no, there is no hop-by-hop classification, that is problem= atic > and > >> does > >> > not scale for high speeds. Classification is done at the > ingress only. > >> > > >> > thanks, > >> > Peter > >> > > >> > > > >> > > >> > _______________________________________________ > >> > Lsr mailing list > >> > Lsr@ietf.org > >> > > >> https://urldefense.com/v3/__https://nam11.safelinks.protection.outloo > >> k.com/ > >> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data= =3D > 0 > >> 2 > >> > *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 > >> > 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >> > 5126&sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >> > &reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR > >> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > >> > > >> > > >> > > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Sat Oct 10 03:29:36 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919093A13B1 for ; Sat, 10 Oct 2020 03:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.587 X-Spam-Level: X-Spam-Status: No, score=-9.587 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=DW1JquGy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yE8eEIyG 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 UjBytiTe0MK0 for ; Sat, 10 Oct 2020 03:29:31 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6EE93A13AE for ; Sat, 10 Oct 2020 03:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=99373; q=dns/txt; s=iport; t=1602325770; x=1603535370; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=maooBvJwoXtBBXJm3pd6rk47h5zKCXhVOIzf1LJopb0=; b=DW1JquGyIMu5RD+GLB9pFh440XM+uWgnjnLKHAW2tdjy3ieFz8825azH 2zuTqPtIHNkfRxmzDubSxDSEAgoCXcCGulgFvEOb0fL3wv0jT9ixrJE6+ e/OY6Kj0l4irltnVLBT/Rq5ZwSR3j4uhj4+8umbdVCjX74fgoeSwfgY97 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AqsBJLBNiCF72nmxoVJIl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvK8z3kPSXIPU6+9Nze3MvObrXz9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7OuXy04j4PE1?= =?us-ascii?q?P4LwUzLeKmUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwR?= =?us-ascii?q?rSqXwOcONTlm4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiBQD/i4Ff/4kNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCD4EjL1EHcFkvLAqEM4NGA41QmHuCUwNQBQsBAQENAQEYAQw?= =?us-ascii?q?IAgQBAYRKAheBfAIlOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEDAQEBEAg?= =?us-ascii?q?JHQEBLAQFAgEEBwQCAQgRAwEBASEBBgMCAgIlCxQJCAIEAQ0FGweDBAGBfk0?= =?us-ascii?q?DDiABDp0JAoE5iGF2gTKDAQEBBYE3Ag5BgnoYghAJgTiCcoNthlYbggCBOBy?= =?us-ascii?q?CTT6CGkIBAQIBARWBHQcBATcJDQkIglkzgi2QBoNChwUmnG4KgmiJAY59gmo?= =?us-ascii?q?DH4MUgSqIXpQbkx6Be4h2lTMCBAIEBQIOAQEFgWsjgVdwFRohKgGCPglHFwI?= =?us-ascii?q?Njh8MFxSDOoUUhUJ0AgE0AgYBCQEBAwl8iwaBNQGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,358,1596499200"; d="scan'208,217";a="578637915" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Oct 2020 10:29:28 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 09AATSYC026949 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 10 Oct 2020 10:29:28 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 10 Oct 2020 05:29:27 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 10 Oct 2020 05:29:27 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 10 Oct 2020 05:29:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FWzmSWrEhQ+dNfnkcXv6PDLXNDU+m99nt7/TJFqRph0rF6hfuT5JskfxIkqrjJ8p/lI0Jz3o+cczfnMF3ySzQVBDUJh8frg/3cQ6Swmfg+oECSj4NnROkYymyHFMUQuhL0MPG0TscCpPsa9d6ikBPDztfcKfA3VwLaVlFQpdVTe7Scj5zwRep/S3A8eglVI8AzMd6aZu/bkqggIH8KHqBXzAyQfQkXGZjOsBvmYrktXYJI4tKxP4o7VhVWGF+fTsvk9ePeuhnOw9PU6wb8ccbXz3CjI7jNKTmvUOax/TtAtKfW+Fti83H7fQfJ2wufj9C81rIp6lszhcrlucy1t5iw== 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=maooBvJwoXtBBXJm3pd6rk47h5zKCXhVOIzf1LJopb0=; b=eLIFoR+g3dPfdCGlu+t/ZzXswuw32KTG6ZU8k+K3Etx9pr/RX9RFcL5RWayUIf6Z6OIPpW0VYjumJonq9eoJ3J3jVhh0hCUNBadZoSYuMPkpwDhqnJ3AuTQvz81cpnJaQ6sGwz6DlrZFQd9msgWWTU5IgvK0bbq++k9QdVPmMRo6yuoLISvVTsivJtxa2L8O5uNIHfnEIRtH+APHl/Y/I108SymHjJL9U4gJ6Hox4ryLX1e3j3KWo9/PhiaUGosC49UZHFMStav0eLv348zgpOW/fAmVTvEdscR0YZoyPBOag5pRHMtM6JiM//Pa0L2IVR4og3TdAJHfkL2nK0WAjg== 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=maooBvJwoXtBBXJm3pd6rk47h5zKCXhVOIzf1LJopb0=; b=yE8eEIyGUkZlfy+R9YTiqgfotMh8yKjlGnPu/V5qaxukoorxM8rm+pO/zngHllAVUVYJpClboyk/3Yt0b6IJ3W4/re1Bj2Oge7Y2VQ6iXgV1TevverQL1/pEOmn8Vk+MKfvPMIkYmYHemjvhOf2d0EeJ7mIUNjQL+xnVOEXmIvA= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB2869.namprd11.prod.outlook.com (2603:10b6:a02:c0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Sat, 10 Oct 2020 10:29:23 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3455.027; Sat, 10 Oct 2020 10:29:23 +0000 From: "Acee Lindem (acee)" To: Aijun Wang , "Peter Psenak (ppsenak)" , "'Aijun Wang'" CC: "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt Thread-Index: AQHWljqhPwTJc6J3hEmS7XUA0fh0y6l/U3AAgAACPQCAAABHAIABIzwAgABWLoCADdcbgIAA1DUAgACqfwCAAEu2gA== Date: Sat, 10 Oct 2020 10:29:23 +0000 Message-ID: <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> In-Reply-To: <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b95c6b5e-6bd0-4db1-7ed1-08d86d075b51 x-ms-traffictypediagnostic: BYAPR11MB2869: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2276; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IhdzThp5cbf7KgzjMp0RrRX3nNsTsZXv60ITo2ahbCU9jTRQWZdIHPbfKM0gLKnzThmlKO+7Wyh2Ophtkz1oIuccRRhItdl+znoG/iIvOYRqT4Hp61WmUccRTJZEZlepXOa+Z8dLVxnHeBFpEaBvIeJherqUre/siFMHoXOCyQTQjOPpE8Eb1gXfaHJHGf/MGnpEcpYGyNnqa3BSA9y4u6FMBX3vvRIwH4/LPVKknFHLVoY4HDyMMb4HsUtWMKgmtFtjhq/MD/4Gk6wTfRK3oXIRUe5wErMBafnDPHHzPmkI7rFR5nfrOHM2R/EpIg1sNRKpOZGx7bZlf4X7h2DByWUsiODEjVuxRc9T4t7kMMo21lXX6jSqgbeJD/yezN30dpaJ5G5Gn6B522ygZgeIiQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(39860400002)(396003)(376002)(366004)(66476007)(316002)(66946007)(30864003)(36756003)(86362001)(66446008)(4326008)(2616005)(33656002)(5660300002)(83380400001)(110136005)(186003)(15650500001)(66574015)(64756008)(76116006)(53546011)(6506007)(66556008)(26005)(2906002)(71200400001)(966005)(6512007)(166002)(9326002)(8936002)(8676002)(6486002)(478600001)(83080400001)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 15iX1JRqW5VvYnS0Gvv8FdfQjWYxXPr42WoSPYf1kOnFFc8wpOkIhk7++YUTco8YCv+RiPhh9LngK0WR0BcCN0fJ1jgbUIcZwF1UWb6U+86pv8KKRkWt7nvzfUctTei8yZO1EJbKJadIXK7ILydJM946qXBumRUqDk4hZ+9GfZk66/dhpGgxJVvjxGjzZdmqk0dsAKcbISlv0us0m4hN9fW8pkrEtHV5SxuoW+STKT/5xIpJfXCwRLYDnaYoGY/BMCdqNJf9LKNIQYSc8JORvAv+Nr5rX8q2BG7Rp8Wnc+h3TSkfV6R9WJvDRMevC5Z807qgv5E+cP2unVLgwe3GupsKo1I1b9eMZmj5/2sR8/0Wkpw1ZHK5jY1FqegZRtNpFYfKlLrRCos14/4sALKLAC4Kg/UoVK47LogRu+XkPqKZ3AHbyezTGFUBEJv3Jd02e+nCYBgNOyMECEAoYnxt9nzgQDbc4mfnHXO+FOolDRUbvA2g6vyskwlEQxK0bh2uVrIkRT7c8UWU5MZNyWeaRHOrEklHo9b+4H2rI+wxVQ/p9dQreMJuwmARTWBjFdJYhgwpNIg0wEMCrRdTUmeJYuiDwQZprPAP/vlHjjXwJBZlCkeiObdFnKrTrD1r9BPkBwxQcwwiCQiK+8i0pGyZsw== Content-Type: multipart/alternative; boundary="_000_92C4AB955CE64BFFBDFB5F6322952994ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b95c6b5e-6bd0-4db1-7ed1-08d86d075b51 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2020 10:29:23.5322 (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: 8M+FnNhwyJrYDvUpwW4InkbXUcnF/DJZU94IzUAWRxMYuuSKJNNhp/SsiCzj6+NX X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2869 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 10:29:35 -0000 --_000_92C4AB955CE64BFFBDFB5F6322952994ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWlqdW4sDQoNCkZyb206IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+ DQpEYXRlOiBGcmlkYXksIE9jdG9iZXIgOSwgMjAyMCBhdCA5OjU4IFBNDQpUbzogQWNlZSBMaW5k ZW0gPGFjZWVAY2lzY28uY29tPiwgIlBldGVyIFBzZW5hayAocHBzZW5haykiIDxwcHNlbmFrQGNp c2NvLmNvbT4sICdBaWp1biBXYW5nJyA8d2FuZ2FqM0BjaGluYXRlbGVjb20uY24+DQpDYzogImxz ckBpZXRmLm9yZyIgPGxzckBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbTHNyXSBGVzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1h dHRyaWJ1dGUtMDQudHh0DQoNCkhpLCBBY2VlOg0KDQpGcm9tOiBsc3ItYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0g KGFjZWUpDQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciAxMCwgMjAyMCAzOjQ4IEFNDQpUbzogQWlq dW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj47IFBldGVyIFBzZW5hayAocHBzZW5h aykgPHBwc2VuYWtAY2lzY28uY29tPjsgJ0FpanVuIFdhbmcnIDx3YW5nYWozQGNoaW5hdGVsZWNv bS5jbj4NCkNjOiBsc3JAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRy aWJ1dGUtMDQudHh0DQoNClNwZWFraW5nIGFzIFdHIG1lbWJlcjoNCg0KSGkgQWlqdW4sDQoNCkZy b206IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY248bWFpbHRvOndhbmdhaWp1 bkB0c2luZ2h1YS5vcmcuY24+Pg0KRGF0ZTogVGh1cnNkYXksIE9jdG9iZXIgOCwgMjAyMCBhdCAx MTowOSBQTQ0KVG86IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNj by5jb20+PiwgIlBldGVyIFBzZW5hayAocHBzZW5haykiIDxwcHNlbmFrQGNpc2NvLmNvbTxtYWls dG86cHBzZW5ha0BjaXNjby5jb20+PiwgJ0FpanVuIFdhbmcnIDx3YW5nYWozQGNoaW5hdGVsZWNv bS5jbjxtYWlsdG86d2FuZ2FqM0BjaGluYXRlbGVjb20uY24+Pg0KQ2M6ICJsc3JAaWV0Zi5vcmc8 bWFpbHRvOmxzckBpZXRmLm9yZz4iIDxsc3JAaWV0Zi5vcmc8bWFpbHRvOmxzckBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSRTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dA0KDQoNCkhpLCBB Y2VlOg0KDQpTb3JyeSBmb3IgdGhlIHByZXZpb3VzIHBydW5lZCBtYWlsLiBMZXQncyByZXBseSB5 b3UgYWdhaW4gYWxvbmcgeW91ciBvcmlnaW5hbCBxdWVzdGlvbi4NCg0KUGxlYXNlIHNlZSBpbmxp bmUuW1dBSl0NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBsc3ItYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bHNyLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBY2VlIExpbmRlbSAoYWNlZSkNClNlbnQ6IFdl ZG5lc2RheSwgU2VwdGVtYmVyIDMwLCAyMDIwIDc6NDcgUE0NClRvOiBBaWp1biBXYW5nIDx3YW5n YWlqdW5AdHNpbmdodWEub3JnLmNuPG1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPj47 IFBldGVyIFBzZW5hayAocHBzZW5haykgPHBwc2VuYWtAY2lzY28uY29tPG1haWx0bzpwcHNlbmFr QGNpc2NvLmNvbT4+OyAnQWlqdW4gV2FuZycgPHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuPG1haWx0 bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbj4+DQpDYzogbHNyQGlldGYub3JnPG1haWx0bzpsc3JA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dA0K DQoNCg0KSGkgQWlqdW4sDQoNCk90aGVyIHRoYW4geW91ciBpbGwtY29uY2VpdmVkIHRvcG9sb2d5 IGRpc2NvdmVyeSBoZXVyaXN0aWMNCg0KW1dBSl0gVGhlIHRvcG9sb2d5IGRpc2NvdmVyeSBoZXVy aXN0aWMgaXMgbm90IHN1aXRhYmxlIGZvciB0aGUgY29ybmVyIHVzZSBjYXNlIHdoZW4gdGhlIHVu bnVtYmVyZWQgaW50ZXJmYWNlIGlzIHVzZWQsIGFzIGV4cGxhaW5lZCBpbiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNiNh cHBlbmRpeC1CLiAgSWYgeW91IGRvbuKAmXQgYWdyZWUsIHdvdWxkIHlvdSBsaWtlIHRvIGlsbHVz dHJhdGUgb3RoZXIgbm9uLWFwcGxpY2FibGUgc2NlbmFyaW9zPw0KDQoNCg0KUmlnaHQg4oCTIGFu ZCBub2JvZHkgb3RoZXIgdGhhbiB5b3Vyc2VsZiBiZWxpZXZlcyB0aGUgSUdQcyBzaG91bGQgYmUg bW9kaWZpZWQgdG8gZXhwb3NlIHRoZSBhYnN0cmFjdGVkIHRvcG9sb2d5IG9mIGFuIGFyZWEgb3V0 c2lkZSB0aGF0IGFyZWEuDQoNCltXQUpdICBUaGUgbW9kaWZpY2F0aW9uIGRvZXNu4oCZdCBjaGFu Z2UgdGhlIHdheSBhbmQgY29tcGxleGl0eSBvZiByb3V0ZSBjYWxjdWxhdGlvbiB3aXRoaW4gSUdQ LiBJdCBqdXN0IHBpZ2d5YmFjayBzb21lIGV4dHJhIGluZm9ybWF0aW9uLCB0aGUgYnVsayBvZiB0 aGUgcmVjb25zdHJ1Y3Rpb24gd29yayBpcyBkb25lIGJ5IHRoZSBjb250cm9sbGVyLiAgU3VjaCBl eHRyYSBpbmZvcm1hdGlvbiBjYW4gYWxzbyBoYXZlIG90aGVyIHVzYWdlLCBhcyBkZXNjcmliZWQg aW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4 LW9yaWdpbmF0b3ItMDYjc2VjdGlvbi0xDQoNCkFuZCwgdGhlIHByb3Bvc2FsIGRlc2NyaWJlZCBp biBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdhbmctbHNyLXBh c3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNCBpcyBkaWZmZXJlbnQgd2l0aCB0aGUgcHJvYmxl bSB5b3UgY29uY2VybmVkLiAgSXQgaGFzIG5vIHJlbGF0aW9uIHdpdGggdGhlIGFic3RyYWN0ZWQg dG9wb2xvZ3kgb2YgYW4gYXJlYS4gIE1heWJlIHlvdSBhcmUgY29uZnVzZWQgYnkgdGhlc2UgdHdv IGRyYWZ0cz8NCg0KDQoNCkl0IGlzIGEgc2ltaWxhciBwcm9ibGVtLiBZb3UgYXJlIHN0aWxsIHRy eWluZyB0byBvdmVybG9hZCB0aGUgcHJlZml4IGFkdmVydGlzZW1lbnRzIHdpdGggYSBsaW5rIGF0 dHJpYnV0ZSAocGFzc2l2ZSBpbnRlcmZhY2UpIHNvIHRoYXQgaXQgY2FuIGJlIGNvbnZleWVkIG91 dHNpZGUgdGhlIGRvbWFpbi4gV2UgY2VydGFpbmx5IHdvdWxkbuKAmXQgd2FzdGUgYSBsaW1pdGVk IHByZWZpeCBmbGFnIG9uIHRoaXMgcGFyb2NoaWFsIGFwcGxpY2F0aW9uLg0KDQoNCg0KDQoNCllv dSBjYW4gc29sdmUgdGhlIHByb2JsZW0gd2l0aCBCR1AtTFMgc2Vzc2lvbihzKSBiZXR3ZWVuIHRo ZSByb3V0ZXIgd2l0aCBhIEJHUC1MUyBzZXNzaW9uIHRvIHRoZSBjb250cm9sbGVyIGFuZCBhIHJv dXRlciBpbiBlYWNoIGFyZWEgdy9vICBhIHJvdXRlciB3aXRoIGEgQkdQLUxTIHNlc3Npb24gdG8g dGhlIGNvbnRyb2xsZXIuDQoNCltXQUpdIFRoaXMgaXMgcG9zc2libGUsIGJ1dCBub3QgZWZmaWNp ZW50LiBGb3Igb3BlcmF0aW9uLCB3ZSBtdXN0IGFsc28gY29uc2lkZXIgdGhlIGNvbmZpZ3VyYXRp b24vYWRtaW5pc3RyYXRpb24gb3ZlcmhlYWQuICBCR1AtTFMgaXMgZGVzaWduZWQgbWFpbmx5IGZv ciB0aGUgbm9ydGhib3VuZCBwcm90b2NvbCwgbm90IGVhc3Qtd2VzdCBwcm90b2NvbC4NCg0KDQoN CndoYXQgb3RoZXIgcG9zc2libGUgcmVhc29uIHdvdWxkIHRoZXJlIGJlIGZvciBhc3NvY2lhdGlu ZyB0aGUgcGFzc2l2ZSBhdHRyaWJ1dGUgd2l0aCBhIHByZWZpeD8NCg0KW1dBSl0gVG8ga25vdyB0 aGUgYm91bmRhcnkgb2YgdGhlIElHUCBkb21haW4uIEFmdGVyIGtub3dpbmcgdGhlIGJvdW5kYXJ5 LCB0aGUgY29udHJvbGxlciBjYW4gc2FmZWx5IGFwcGx5IGFuZCBjaGVjayB0aGUgbmV0d29yayBz ZWN1cml0eSBwb2xpY3ksIHRoZSBpbmJvdW5kIHRyYWZmaWMgY29udHJvbCBwb2xpY3kgZXRjLg0K DQoNCg0KSXQgcmVhbGx5IGlzbuKAmXQgcmVsZXZhbnQsIGJ1dCBJIGhhdmUgdG8gYXNr4oCmLiBI b3cgZG9lcyB0aGUgcHJlc2VuY2Ugb2YgYSBwcmVmaXggYXNzb2NpYXRlZCB3aXRoIGEgcGFzc2l2 ZSBpbnRlcmZhY2UgYWxsb3cgeW91IHRvIG1ha2UgdGhpcyBkZWR1Y3Rpb24/DQoNCltXQUpdIFBh c3NpdmUgaW50ZXJmYWNlcyBhcmUgZGVwbG95ZWQgbWFpbmx5IGF0IHRoZSBib3VuZGFyeSBvZiBJ R1AgZG9tYWluLiAgSXMgdGhlcmUgYW55IG90aGVyIGV4Y2VwdGlvbj8NCg0KV2hpbGUgcGFzc2l2 ZSBpbnRlcmZhY2VzIGFyZSBub3Qgc3RhbmRhcmRpemVkLCB0aGVyZSBpcyBub3RoaW5nIHRoYXQg bGltaXRzIHRoZWlyIHVzYWdlIHRvIGFuIElHUCBib3VuZGFyeS4gVGhleSBjYW4gYW5kIGFyZSBk ZXBsb3llZCBvbiBhbnkgaW50ZXJmYWNlIHdoZXJlIGFkamFjZW5jaWVzIGFyZSBub3QgdG8gYmUg Zm9ybWVkIChlLmcuLCBhIHN0dWIgc3VibmV0IGNvbnRhaW5pbmcgaG9zdHMpLg0KDQoNCg0KVGhh bmtzLA0KQWNlZQ0KDQoNCg0KVGhhbmtzLA0KDQpBY2VlDQoNCg0KDQpUaGFua3MsDQoNCkFjZWUN Cg0KDQoNCk9uIDkvMjkvMjAsIDEwOjM5IFBNLCAiQWlqdW4gV2FuZyIgPHdhbmdhaWp1bkB0c2lu Z2h1YS5vcmcuY248bWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+PiB3cm90ZToNCg0K DQoNCiAgICBIaSwgQWNlZSBhbmQgUGV0ZXI6DQoNCiAgICBQYXNzaXZlIGludGVyZmFjZSBpcyBt YWlubHkgdXNlZCBhdCB0aGUgZWRnZSBvZiB0aGUgbmV0d29yaywgd2hlcmUgdGhlIHVubnVtYmVy ZWQgaW50ZXJmYWNlIHdpbGwgbm90IGJlIHVzZWQuDQoNCiAgICBBbmQgdGhlIGluZm9ybWF0aW9u IHRvIGZsYWcgdGhlIHBhc3NpdmUgaW50ZXJmYWNlcyBpcyBmb3IgcG9zaXRpb25pbmcgdGhlIGFy ZWEgYm91bmRhcnksIG5vdCBjb25mbGljdCB3aXRoIHRoZSBhYnN0cmFjdCBjYXBhYmlsaXRpZXMg b2YgdGhlIGFyZWEgaW5zaWRlLg0KDQoNCg0KDQoNCiAgICBCZXN0IFJlZ2FyZHMNCg0KDQoNCiAg ICBBaWp1biBXYW5nDQoNCiAgICBDaGluYSBUZWxlY29tDQoNCg0KDQogICAgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCg0KICAgIEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzps c3ItYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFjZWUgTGluZGVtIChhY2VlKQ0KDQogICAgU2VudDogVHVlc2RheSwgU2VwdGVtYmVy IDI5LCAyMDIwIDk6MTYgUE0NCg0KICAgIFRvOiBQZXRlciBQc2VuYWsgPHBwc2VuYWs9NDBjaXNj by5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMuaWV0 Zi5vcmc+PjsgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjxtYWlsdG86d2Fu Z2FpanVuQHRzaW5naHVhLm9yZy5jbj4+OyAnQWlqdW4gV2FuZycgPHdhbmdhajNAY2hpbmF0ZWxl Y29tLmNuPG1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbj4+DQoNCiAgICBDYzogbHNyQGll dGYub3JnPG1haWx0bzpsc3JAaWV0Zi5vcmc+DQoNCiAgICBTdWJqZWN0OiBSZTogW0xzcl0gRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRl cmZhY2UtYXR0cmlidXRlLTA0LnR4dA0KDQoNCg0KICAgIFNwZWFraW5nIGFzIFdHIG1lbWJlcjoN Cg0KDQoNCiAgICBIaSBBaWp1biwgUGV0ZXIsDQoNCiAgICBJIGFncmVlIHdpdGggUGV0ZXIgLSBv bmUgb2YgdGhlIG1haW4gbW90aXZhdGlvbnMgZm9yIGhhdmluZyBhcmVhcyBpcyB0byBhYnN0cmFj dCB0aGUgdG9wb2xvZ3kgd2l0aGluIHRoZSBhcmVhLiBOb3cgeW91J3JlIHRyeWluZyB0byBzdXBw bGFudCB0aGlzICAtIG9uZSB0b3BvbG9naWNhbCBkZXRhaWwgYXQgYSB0aW1lIHdpdGggaWxsLWNv bmNlaXZlZCBJR1AgZmVhdHVyZXMuDQoNCiAgICBUaGFua3MsDQoNCiAgICBBY2VlDQoNCg0KDQog ICAgT24gOS8yOS8yMCwgNToxNSBBTSwgIkxzciBvbiBiZWhhbGYgb2YgUGV0ZXIgUHNlbmFrIiA8 bHNyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHBwc2VuYWs9NDBjaXNjby5jb21AZG1h cmMuaWV0Zi5vcmc8bWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnJTIwb24lMjBiZWhhbGYlMjBv ZiUyMHBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCg0KDQoNCiAg ICAgICAgSGkgQWlqdW4sDQoNCg0KDQogICAgICAgIE9uIDI5LzA5LzIwMjAgMTE6MDcsIEFpanVu IFdhbmcgd3JvdGU6DQoNCiAgICAgICAgPiBIaSwgUGV0ZXI6DQoNCiAgICAgICAgPg0KDQogICAg ICAgID4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KDQogICAgICAgID4gMS4gRm9yIEJHUC1M UyBkZXBsb3ltZW50LCB0aGVyZSBub3JtYWxseSBvbmx5IGJlIG9uZSByb3V0ZXIgdGhhdCB3aXRo aW4gdGhlDQoNCiAgICAgICAgPiBJR1AgZG9tYWluIHRvIHJlcG9ydCB0aGUgdG9wb2xvZ3kgaW5m b3JtYXRpb24sIHRoaXMgcm91dGVyIHNob3VsZCBrbm93IHN1Y2gNCg0KICAgICAgICA+IHBhc3Np dmUgbGlua3Mgd2hpY2ggZXhpc3RzIG1haW5seSBvbiBvdGhlciBib3JkZXIgcm91dGVycyB2aWEg dGhlIElHUA0KDQogICAgICAgID4gcHJvdG9jb2wuIFRoaXMgaXMgbWFpbiByZWFzb24gdG8gZXh0 ZW5zaW9uIHRoZSBJR1AgcHJvdG9jb2wuID4gMi4gRm9yIHRoZSBzb2x1dGlvbiwgbm9ybWFsbHks IHRoZSBsaW5rIHdpdGhpbiB0aGUgSUdQIGNvbm5lY3QgdHdvDQoNCiAgICAgICAgZW5kcywgYnV0 DQoNCiAgICAgICAgPiBwYXNzaXZlIGludGVyZmFjZSBpcyBzcGVjaWFsIGFuZCBub3QgZmFsbCBp biB0aGlzIHNwYWNlLiBXZSBoYXZlIHN0dWRpZWQgdGhlDQoNCiAgICAgICAgPiBjdXJyZW50IFRM VnMgdGhhdCBmb3IgbGluaywgYW5kIGZpbmQgbm8gc3VpdGFibGUgY29udGFpbmVyIHRvIGFwcGVu ZCB0aGlzDQoNCiAgICAgICAgPiBpbmZvcm1hdGlvbi4gVGhpcyBpcyB0aGUgcmVhc29uIHRoYXQg d2Ugc2VsZWN0IHRoZSBUTFZzIHRoYXQgYXNzb2NpYXRlZCB3aXRoDQoNCiAgICAgICAgPiBQcmVm aXguDQoNCg0KDQogICAgICAgIGlmIHRoZSBsaW5rIGlzIHVubnVtYmVyZWQsIHlvdXIgc29sdXRp b24gZG9lcyBub3Qgd29yay4gQXMgSSBzYWlkLCBpZg0KDQogICAgICAgIHlvdSBuZWVkIGEga25v d2xlZGdlIGFib3V0IHRoZSBsaW5rLCB5b3UgY2FuIG5vdCBhZHZlcnRpc2UgaXQgYXMgYSBwcmVm aXguDQoNCg0KDQogICAgICAgIHRoYW5rcywNCg0KICAgICAgICBQZXRlcg0KDQoNCg0KDQoNCiAg ICAgICAgPg0KDQogICAgICAgID4+RnJvbSBvdGhlciBQT1YsIHRoZSBPU1BGdjMgZGVmaW5lcyBu b3cgdGhlICJJbnRyYS1BcmVhLVByZWZpeCBMU0EiLCB3aGljaA0KDQogICAgICAgID4gaXNvbGF0 ZSB0aGUgcHJlZml4IGluZm9ybWF0aW9uIHRoYXQgYXNzb2NpYXRlZCB3aXRoIGxpbmsgaW50byB0 aGlzDQoNCiAgICAgICAgPiBjb250YWluZXIsIGNvbnRhaW5zIHRoZSBzdHViIGxpbmssIGxvY2Fs IGludGVyZmFjZSBpbmZvcm1hdGlvbiBldGMuIFB1dCBzdWNoDQoNCiAgICAgICAgPiBhdHRyaWJ1 dGUgYWxvbmcgd2l0aCB0aGUgcHJlZml4IGlzIHRoZW4gYWNjZXB0YWJsZT8NCg0KICAgICAgICA+ DQoNCiAgICAgICAgPg0KDQogICAgICAgID4gQmVzdCBSZWdhcmRzDQoNCiAgICAgICAgPg0KDQog ICAgICAgID4gQWlqdW4gV2FuZw0KDQogICAgICAgID4gQ2hpbmEgVGVsZWNvbQ0KDQogICAgICAg ID4NCg0KICAgICAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCiAgICAgICAgPiBG cm9tOiBsc3ItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IFtt YWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZXRlcg0KDQogICAgICAg ID4gUHNlbmFrDQoNCiAgICAgICAgPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMjAg NDoyOSBQTQ0KDQogICAgICAgID4gVG86IEFpanVuIFdhbmcgPHdhbmdhajNAY2hpbmF0ZWxlY29t LmNuPG1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbj4+DQoNCiAgICAgICAgPiBDYzogbHNy QGlldGYub3JnPG1haWx0bzpsc3JAaWV0Zi5vcmc+DQoNCiAgICAgICAgPiBTdWJqZWN0OiBSZTog W0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCg0KICAgICAgICA+IGRyYWZ0 LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQNCg0KICAgICAgICA+ DQoNCiAgICAgICAgPiBIaSBBaWp1biwNCg0KICAgICAgICA+DQoNCiAgICAgICAgPiBoZXJlJ3Mg bXkgY29tbWVudHM6DQoNCiAgICAgICAgPg0KDQogICAgICAgID4gVGhlIHB1cnBvc2Ugb2YgdGhp cyBkcmFmdCBpcyB0byBhZHZlcnRpc2UgcGFzc2l2ZSBsaW5rcy4NCg0KICAgICAgICA+DQoNCiAg ICAgICAgPiAxLiBJJ20gbm90IHN1cmUgdGhlIHByb2JsZW0gbmVlZHMgdG8gYmUgc29sdmVkIGJ5 IElHUHMuIEkgdGVuZCB0byBiZWxpZXZlDQoNCiAgICAgICAgPiBpZXRmLWlkci1iZ3Bscy1pbnRl ci1hcy10b3BvbG9neS1leHQgaXMgc3VmZmljaWVudC4NCg0KICAgICAgICA+DQoNCiAgICAgICAg PiAyLiB0aGUgc29sdXRpb24gdGhhdCB5b3UgcHJvcG9zZWQgaXMgd3JvbmcuIFlvdSBhcmUgdHJ5 aW5nIHRvIGRlcml2ZQ0KDQogICAgICAgID4gdG9wb2xvZ2ljYWwgZGF0YSBhYm91dCB0aGUgcGFz c2l2ZSBsaW5rcyBmcm9tIHRoZSBwcmVmaXggYWR2ZXJ0aXNlbWVudC4NCg0KICAgICAgICA+IFRo aXMgaXMgc2VtYW50aWNhbGx5IGluY29ycmVjdCBhbmQgb25seSB3b3JrcyB1bmRlciB2ZXJ5IHNw ZWNpZmljIGNvbmRpdGlvbi4NCg0KICAgICAgICA+IElmIHlvdSBuZWVkIHRvIGFkdmVydGlzZSBh IGxpbmssIGFkdmVydGlzZSBpdCBhcyBhICJzcGVjaWFsIg0KDQogICAgICAgID4gbGluaywgbm90 IGFzIGEgInNwZWNpYWwiIHByZWZpeC4NCg0KICAgICAgICA+DQoNCiAgICAgICAgPiB0aGFua3Ms DQoNCiAgICAgICAgPiBQZXRlcg0KDQogICAgICAgID4NCg0KICAgICAgICA+IE9uIDI5LzA5LzIw MjAgMDM6MTcsIEFpanVuIFdhbmcgd3JvdGU6DQoNCiAgICAgICAgPj4gSGksIFBldGVyOg0KDQog ICAgICAgID4+DQoNCiAgICAgICAgPj4gV291bGQgeW91IGxpa2UgdG8gcmV2aWV3IGFuZCBnaXZl IGNvbW1lbnRzIG9uIHRoZSB1cGRhdGVzIHZlcnNpb24gb2YgdGhpcw0KDQogICAgICAgID4gZHJh ZnQ/DQoNCiAgICAgICAgPj4gV2UgaGF2ZSBhbHNvIGFkZGVkIHRoZSBwcm90b2NvbCBleHRlbnNp b24gcHJvcG9zYWwgZm9yIE9TUEZ2My4NCg0KICAgICAgICA+Pg0KDQogICAgICAgID4+IFRoZSB1 cGRhdGUgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IGNhbiByZWZlciB0bw0KDQogICAgICAgID4+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd2FuZy1sc3ItcGFzc2l2 ZS1pbnRlcmZhY2UNCg0KICAgICAgICA+PiAtYXR0cmlidXRlDQoNCiAgICAgICAgPj4gVGhhbmtz IGluIGFkdmFuY2UuDQoNCiAgICAgICAgPj4NCg0KICAgICAgICA+Pg0KDQogICAgICAgID4+IEJl c3QgUmVnYXJkcw0KDQogICAgICAgID4+DQoNCiAgICAgICAgPj4gQWlqdW4gV2FuZw0KDQogICAg ICAgID4+IENoaW5hIFRlbGVjb20NCg0KICAgICAgICA+Pg0KDQogICAgICAgID4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQogICAgICAgID4+PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddDQoNCiAgICAgICAgPj4+IFNlbnQ6IE1vbmRheSwgU2VwdGVtYmVy IDI4LCAyMDIwIDM6MTcgUE0NCg0KICAgICAgICA+Pj4gVG86IFpoaWJvIEh1IDxodXpoaWJvQGh1 YXdlaS5jb208bWFpbHRvOmh1emhpYm9AaHVhd2VpLmNvbT4+OyBHeWFuIE1pc2hyYQ0KDQogICAg ICAgID4+PiA8Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2 ZXJpem9uLmNvbT4+OyBBaWp1biBXYW5nIDx3YW5nYWozQGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86 d2FuZ2FqM0BjaGluYXRlbGVjb20uY24+PjsNCg0KICAgICAgICA+Pj4gR3lhbiBTLiBNaXNocmEg PGd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208bWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5j b20+Pg0KDQogICAgICAgID4+PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y DQoNCiAgICAgICAgPj4+IGRyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0 ZS0wNC50eHQNCg0KICAgICAgICA+Pj4NCg0KICAgICAgICA+Pj4NCg0KICAgICAgICA+Pj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsDQoNCiAgICAgICAgPj4+IGRyYWZ0LXdhbmctbHNyLXBhc3NpdmUt aW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQNCg0KICAgICAgICA+Pj4gaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBBaWp1biBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCg0K ICAgICAgICA+Pj4gcmVwb3NpdG9yeS4NCg0KICAgICAgICA+Pj4NCg0KICAgICAgICA+Pj4gTmFt ZTogICAgICAgICAgICAgICBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1 dGUNCg0KICAgICAgICA+Pj4gUmV2aXNpb246ICAgMDQNCg0KICAgICAgICA+Pj4gVGl0bGU6ICAg ICAgICAgUGFzc2l2ZSBJbnRlcmZhY2UgQXR0cmlidXRlDQoNCiAgICAgICAgPj4+IERvY3VtZW50 IGRhdGU6ICAgICAgIDIwMjAtMDktMjgNCg0KICAgICAgICA+Pj4gR3JvdXA6ICAgICAgICAgICAg ICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQoNCiAgICAgICAgPj4+IFBhZ2VzOiAgICAgICAgICAg ICAgIDcNCg0KICAgICAgICA+Pj4gVVJMOg0KDQogICAgICAgID4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUtMDQuDQoN CiAgICAgICAgPj4+IHR4dA0KDQogICAgICAgID4+PiBTdGF0dXM6DQoNCiAgICAgICAgPj4+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50 ZXJmYWNlLWF0dA0KDQogICAgICAgID4+PiByDQoNCiAgICAgICAgPj4+IGlidXRlLw0KDQogICAg ICAgID4+PiBIdG1saXplZDoNCg0KICAgICAgICA+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjDQoNCiAgICAgICAg Pj4+IGUNCg0KICAgICAgICA+Pj4gLWF0dHJpYnV0DQoNCiAgICAgICAgPj4+IGUNCg0KICAgICAg ICA+Pj4gSHRtbGl6ZWQ6DQoNCiAgICAgICAgPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dA0KDQogICAgICAgID4+ PiBlDQoNCiAgICAgICAgPj4+IC0wNA0KDQogICAgICAgID4+PiBEaWZmOg0KDQogICAgICAgID4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd2FuZy1sc3ItcGFzc2l2 ZS1pbnRlcmZhY2UtYXQNCg0KICAgICAgICA+Pj4gdA0KDQogICAgICAgID4+PiByaWJ1dGUtMDQN Cg0KICAgICAgICA+Pj4NCg0KICAgICAgICA+Pj4gQWJzdHJhY3Q6DQoNCiAgICAgICAgPj4+ICAg ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG1lY2hhbmlzbSB0aGF0IGNhbiBiZSB1c2Vk IHRvDQoNCiAgICAgICAgPj4+ICAgICAgZGlmZmVyZW50aWF0ZSB0aGUgcGFzc2l2ZSBpbnRlcmZh Y2VzIGZyb20gdGhlIG5vcm1hbCBpbnRlcmZhY2VzDQoNCiAgICAgICAgPj4+ICAgICAgd2l0aGlu IElTSVMgb3IgT1NQRiBkb21haW4uDQoNCiAgICAgICAgPj4+DQoNCiAgICAgICAgPj4+DQoNCiAg ICAgICAgPj4+DQoNCiAgICAgICAgPj4+DQoNCiAgICAgICAgPj4+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQoNCiAgICAg ICAgPj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdA0KDQogICAgICAgID4gdG9vbHMuaWV0Zi5vcmcuDQoNCiAgICAgICAgPj4+ DQoNCiAgICAgICAgPj4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCiAgICAgICAgPj4+DQoNCiAg ICAgICAgPj4NCg0KICAgICAgICA+Pg0KDQogICAgICAgID4+DQoNCiAgICAgICAgPj4NCg0KICAg ICAgICA+DQoNCiAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQogICAgICAgID4gTHNyIG1haWxpbmcgbGlzdA0KDQogICAgICAgID4gTHNy QGlldGYub3JnPG1haWx0bzpMc3JAaWV0Zi5vcmc+DQoNCiAgICAgICAgPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0KDQogICAgICAgID4NCg0KICAgICAgICA+DQoN CiAgICAgICAgPg0KDQoNCg0KICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQogICAgICAgIExzciBtYWlsaW5nIGxpc3QNCg0KICAgICAgICBM c3JAaWV0Zi5vcmc8bWFpbHRvOkxzckBpZXRmLm9yZz4NCg0KICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0KDQoNCg0KICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCiAgICBMc3IgbWFpbGluZyBsaXN0DQoN CiAgICBMc3JAaWV0Zi5vcmc8bWFpbHRvOkxzckBpZXRmLm9yZz4NCg0KICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KTHNyIG1haWxpbmcgbGlzdA0KDQpM c3JAaWV0Zi5vcmc8bWFpbHRvOkxzckBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sc3INCg== --_000_92C4AB955CE64BFFBDFB5F6322952994ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWls eTpEZW5nWGlhbjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJZm9udC1zaXplOjEwLjVwdDsNCglm b250LWZhbWlseTpEZW5nWGlhbjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWls U3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1 aW4gMS4waW4gMS4yNWluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkhpIEFpanVuLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206 DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5B aWp1biBXYW5nICZsdDt3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5GcmlkYXksIE9jdG9iZXIgOSwgMjAyMCBhdCA5OjU4IFBNPGJyPg0KPGI+VG86IDwvYj5B Y2VlIExpbmRlbSAmbHQ7YWNlZUBjaXNjby5jb20mZ3Q7LCAmcXVvdDtQZXRlciBQc2VuYWsgKHBw c2VuYWspJnF1b3Q7ICZsdDtwcHNlbmFrQGNpc2NvLmNvbSZndDssICdBaWp1biBXYW5nJyAmbHQ7 d2FuZ2FqM0BjaGluYXRlbGVjb20uY24mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtsc3JAaWV0 Zi5vcmcmcXVvdDsgJmx0O2xzckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6 IFtMc3JdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctbHNyLXBh c3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSwgQWNlZTo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0ibGVmdCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU3LjBwdDt0ZXh0LWFsaWduOmxlZnQiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGxzci1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkFjZWUgTGluZGVtIChhY2VlKTxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0 b2JlciAxMCwgMjAyMCAzOjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBBaWp1biBXYW5nICZsdDt3YW5n YWlqdW5AdHNpbmdodWEub3JnLmNuJmd0OzsgUGV0ZXIgUHNlbmFrIChwcHNlbmFrKSAmbHQ7cHBz ZW5ha0BjaXNjby5jb20mZ3Q7OyAnQWlqdW4gV2FuZycgJmx0O3dhbmdhajNAY2hpbmF0ZWxlY29t LmNuJmd0Ozxicj4NCjxiPkNjOjwvYj4gbHNyQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLWxz ci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUtMDQudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6NTcuMHB0O3RleHQtYWxpZ246bGVmdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTcuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlNwZWFraW5nIGFzIFdHIG1lbWJlcjo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTcuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1Ny4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgQWlqdW4s DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6NTcuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+QWlqdW4gV2FuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhaWp1 bkB0c2luZ2h1YS5vcmcuY24iPndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY248L2E+Jmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgT2N0b2JlciA4LCAyMDIwIGF0IDExOjA5IFBNPGJyPg0K PGI+VG86IDwvYj5BY2VlIExpbmRlbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28uY29t Ij5hY2VlQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDtQZXRlciBQc2VuYWsgKHBwc2VuYWspJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cHBzZW5ha0BjaXNjby5jb20iPnBwc2VuYWtAY2lzY28u Y29tPC9hPiZndDssICdBaWp1biBXYW5nJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhajNAY2hp bmF0ZWxlY29tLmNuIj53YW5nYWozQGNoaW5hdGVsZWNvbS5jbjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bHNyQGlldGYub3JnIj5sc3JAaWV0Zi5vcmc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bHNyQGlldGYub3JnIj5sc3JAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0 LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpLCBBY2VlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlNvcnJ5IGZvciB0aGUgcHJldmlvdXMgcHJ1bmVkIG1haWwuIExldCdzIHJlcGx5 IHlvdSBhZ2FpbiBhbG9uZyB5b3VyIG9yaWdpbmFsIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlBsZWFzZSBzZWUgaW5saW5lLltXQUpdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzps c3ItYm91bmNlc0BpZXRmLm9yZyI+bHNyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJt YWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZzwv YT5dIE9uIEJlaGFsZiBPZiBBY2VlIExpbmRlbSAoYWNlZSk8YnI+DQpTZW50OiBXZWRuZXNkYXks IFNlcHRlbWJlciAzMCwgMjAyMCA3OjQ3IFBNPGJyPg0KVG86IEFpanVuIFdhbmcgJmx0OzxhIGhy ZWY9Im1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuIj53YW5nYWlqdW5AdHNpbmdodWEu b3JnLmNuPC9hPiZndDs7IFBldGVyIFBzZW5hayAocHBzZW5haykgJmx0OzxhIGhyZWY9Im1haWx0 bzpwcHNlbmFrQGNpc2NvLmNvbSI+cHBzZW5ha0BjaXNjby5jb208L2E+Jmd0OzsgJ0FpanVuIFdh bmcnICZsdDs8YSBocmVmPSJtYWlsdG86d2FuZ2FqM0BjaGluYXRlbGVjb20uY24iPndhbmdhajNA Y2hpbmF0ZWxlY29tLmNuPC9hPiZndDs8YnI+DQpDYzogPGEgaHJlZj0ibWFpbHRvOmxzckBpZXRm Lm9yZyI+bHNyQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1h dHRyaWJ1dGUtMDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SGkgQWlqdW4sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PdGhlciB0aGFuIHlvdXIgaWxsLWNvbmNlaXZl ZCB0b3BvbG9neSBkaXNjb3ZlcnkgaGV1cmlzdGljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1dBSl0gVGhl IHRvcG9sb2d5IGRpc2NvdmVyeSBoZXVyaXN0aWMgaXMgbm90IHN1aXRhYmxlIGZvciB0aGUgY29y bmVyIHVzZSBjYXNlIHdoZW4gdGhlIHVubnVtYmVyZWQgaW50ZXJmYWNlIGlzIHVzZWQsIGFzIGV4 cGxhaW5lZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYjYXBwZW5kaXgtQiI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0w NiNhcHBlbmRpeC1CPC9hPi4gJm5ic3A7SWYgeW91IGRvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAmTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj50IGFncmVlLCB3b3Vs ZCB5b3UgbGlrZSB0byBpbGx1c3RyYXRlIG90aGVyIG5vbi1hcHBsaWNhYmxlDQogc2NlbmFyaW9z PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDo1Ny4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDo1Ny4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmlnaHQg4oCTIGFuZCBub2JvZHkgb3RoZXIgdGhh biB5b3Vyc2VsZiBiZWxpZXZlcyB0aGUgSUdQcyBzaG91bGQgYmUgbW9kaWZpZWQgdG8gZXhwb3Nl IHRoZSBhYnN0cmFjdGVkIHRvcG9sb2d5IG9mIGFuIGFyZWEgb3V0c2lkZSB0aGF0IGFyZWEuDQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjU3LjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PltXQUpdICZuYnNwO1RoZSBtb2RpZmljYXRpb24gZG9lc27igJl0IGNoYW5nZSB0aGUgd2F5IGFu ZCBjb21wbGV4aXR5IG9mIHJvdXRlIGNhbGN1bGF0aW9uIHdpdGhpbiBJR1AuIEl0IGp1c3QgcGln Z3liYWNrIHNvbWUgZXh0cmEgaW5mb3JtYXRpb24sIHRoZSBidWxrIG9mIHRoZSByZWNvbnN0cnVj dGlvbiB3b3JrDQogaXMgZG9uZSBieSB0aGUgY29udHJvbGxlci4gJm5ic3A7U3VjaCBleHRyYSBp bmZvcm1hdGlvbiBjYW4gYWxzbyBoYXZlIG90aGVyIHVzYWdlLCBhcyBkZXNjcmliZWQgaW4NCjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxzci1vc3BmLXBy ZWZpeC1vcmlnaW5hdG9yLTA2I3NlY3Rpb24tMSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNiNzZWN0aW9uLTE8L2E+ PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU3LjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkFuZCwgdGhlIHByb3Bvc2FsIGRlc2NyaWJlZCBpbg0KPGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWlu dGVyZmFjZS1hdHRyaWJ1dGUtMDQiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUtMDQ8L2E+IGlz IGRpZmZlcmVudCB3aXRoIHRoZSBwcm9ibGVtIHlvdSBjb25jZXJuZWQuICZuYnNwO0l0IGhhcyBu byByZWxhdGlvbiB3aXRoIHRoZSBhYnN0cmFjdGVkIHRvcG9sb2d5IG9mIGFuIGFyZWEuJm5ic3A7 IE1heWJlIHlvdSBhcmUgY29uZnVzZWQgYnkgdGhlc2UgdHdvIGRyYWZ0cz88L3NwYW4+PG86cD48 L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JdCBpcyBhIHNpbWlsYXIgcHJvYmxlbS4gWW91IGFyZSBzdGlsbCB0 cnlpbmcgdG8gb3ZlcmxvYWQgdGhlIHByZWZpeCBhZHZlcnRpc2VtZW50cyB3aXRoIGEgbGluayBh dHRyaWJ1dGUgKHBhc3NpdmUgaW50ZXJmYWNlKSBzbyB0aGF0IGl0IGNhbiBiZSBjb252ZXllZCBv dXRzaWRlIHRoZSBkb21haW4uDQogV2UgY2VydGFpbmx5IHdvdWxkbuKAmXQgd2FzdGUgYSBsaW1p dGVkIHByZWZpeCBmbGFnIG9uIHRoaXMgcGFyb2NoaWFsIGFwcGxpY2F0aW9uLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjU3LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NTcuMHB0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjU3LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Zb3UgY2FuIHNvbHZl IHRoZSBwcm9ibGVtIHdpdGggQkdQLUxTIHNlc3Npb24ocykgYmV0d2VlbiB0aGUgcm91dGVyIHdp dGggYSBCR1AtTFMgc2Vzc2lvbiB0byB0aGUgY29udHJvbGxlciBhbmQgYSByb3V0ZXIgaW4gZWFj aCBhcmVhIHcvbyAmbmJzcDthIHJvdXRlcg0KIHdpdGggYSBCR1AtTFMgc2Vzc2lvbiB0byB0aGUg Y29udHJvbGxlci4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo1Ny4wcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5bV0FKXSBUaGlzIGlzIHBvc3NpYmxlLCBidXQgbm90IGVmZmljaWVudC4g Rm9yIG9wZXJhdGlvbiwgd2UgbXVzdCBhbHNvIGNvbnNpZGVyIHRoZSBjb25maWd1cmF0aW9uL2Fk bWluaXN0cmF0aW9uIG92ZXJoZWFkLiAmbmJzcDtCR1AtTFMgaXMgZGVzaWduZWQgbWFpbmx5IGZv ciB0aGUgbm9ydGhib3VuZCBwcm90b2NvbCwNCiBub3QgZWFzdC13ZXN0IHByb3RvY29sLjwvc3Bh bj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPndoYXQg b3RoZXIgcG9zc2libGUgcmVhc29uIHdvdWxkIHRoZXJlIGJlIGZvciBhc3NvY2lhdGluZyB0aGUg cGFzc2l2ZSBhdHRyaWJ1dGUgd2l0aCBhIHByZWZpeD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPltXQUpdIFRvIGtub3cgdGhlIGJvdW5kYXJ5IG9mIHRoZSBJR1AgZG9tYWluLiBBZnRl ciBrbm93aW5nIHRoZSBib3VuZGFyeSwgdGhlIGNvbnRyb2xsZXIgY2FuIHNhZmVseSBhcHBseSBh bmQgY2hlY2sgdGhlIG5ldHdvcmsgc2VjdXJpdHkgcG9saWN5LCB0aGUNCiBpbmJvdW5kIHRyYWZm aWMgY29udHJvbCBwb2xpY3kgZXRjLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTcuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTcuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkl0 IHJlYWxseSBpc27igJl0IHJlbGV2YW50LCBidXQgSSBoYXZlIHRvIGFza+KApi4gSG93IGRvZXMg dGhlIHByZXNlbmNlIG9mIGEgcHJlZml4IGFzc29jaWF0ZWQgd2l0aCBhIHBhc3NpdmUgaW50ZXJm YWNlIGFsbG93IHlvdSB0byBtYWtlIHRoaXMgZGVkdWN0aW9uPw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo1 Ny4wcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bV0FKXSBQYXNzaXZlIGlu dGVyZmFjZXMgYXJlIGRlcGxveWVkIG1haW5seSBhdCB0aGUgYm91bmRhcnkgb2YgSUdQIGRvbWFp bi4gJm5ic3A7SXMgdGhlcmUgYW55IG90aGVyIGV4Y2VwdGlvbj88L3NwYW4+PG86cD48L286cD48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2hp bGUgcGFzc2l2ZSBpbnRlcmZhY2VzIGFyZSBub3Qgc3RhbmRhcmRpemVkLCB0aGVyZSBpcyBub3Ro aW5nIHRoYXQgbGltaXRzIHRoZWlyIHVzYWdlIHRvIGFuIElHUCBib3VuZGFyeS4gVGhleSBjYW4g YW5kIGFyZSBkZXBsb3llZCBvbiBhbnkgaW50ZXJmYWNlIHdoZXJlIGFkamFjZW5jaWVzDQogYXJl IG5vdCB0byBiZSBmb3JtZWQgKGUuZy4sIGEgc3R1YiBzdWJuZXQgY29udGFpbmluZyBob3N0cyku IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MsPGJyPg0KQWNlZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo1Ny4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo1Ny4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+VGhhbmtzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTcuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkFjZWU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BY2VlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojkz LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+T24gOS8yOS8yMCwgMTA6MzkgUE0sICZxdW90 O0FpanVuIFdhbmcmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEu b3JnLmNuIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9u ZSI+d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjwvc3Bhbj48L2E+Jmd0Ow0KIHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBI aSwgQWNlZSBhbmQgUGV0ZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBh c3NpdmUgaW50ZXJmYWNlIGlzIG1haW5seSB1c2VkIGF0IHRoZSBlZGdlIG9mIHRoZSBuZXR3b3Jr LCB3aGVyZSB0aGUgdW5udW1iZXJlZCBpbnRlcmZhY2Ugd2lsbCBub3QgYmUgdXNlZC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FuZCB0aGUgaW5mb3JtYXRpb24g dG8gZmxhZyB0aGUgcGFzc2l2ZSBpbnRlcmZhY2VzIGlzIGZvciBwb3NpdGlvbmluZyB0aGUgYXJl YSBib3VuZGFyeSwgbm90IGNvbmZsaWN0IHdpdGggdGhlIGFic3RyYWN0IGNhcGFiaWxpdGllcyBv ZiB0aGUgYXJlYSBpbnNpZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlc3QgUmVnYXJk czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyBBaWp1biBXYW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoaW5h IFRlbGVjb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsgRnJvbToNCjxhIGhyZWY9Im1haWx0bzpsc3ItYm91bmNlc0BpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUi Pmxzci1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4gWzxhIGhyZWY9Im1haWx0bzpsc3ItYm91 bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPm1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSBPbiBCZWhh bGYNCiBPZiBBY2VlIExpbmRlbSAoYWNlZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsgU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDI5LCAyMDIwIDk6MTYgUE08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgVG86IFBldGVyIFBzZW5hayAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5wcHNlbmFrPTQwY2lzY28uY29t QGRtYXJjLmlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7Ow0KIEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9 Im1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjwv c3Bhbj48L2E+Jmd0OzsgJ0FpanVuIFdhbmcnICZsdDs8YSBocmVmPSJtYWlsdG86d2FuZ2FqM0Bj aGluYXRlbGVjb20uY24iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3Jh dGlvbjpub25lIj53YW5nYWozQGNoaW5hdGVsZWNvbS5jbjwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBDYzoNCjxhIGhyZWY9Im1haWx0bzpsc3JAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5sc3JAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBTcGVh a2luZyBhcyBXRyBtZW1iZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpIEFpanVuLCBQZXRlciwNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0kgYWdyZWUgd2l0aCBQZXRlciAtIG9uZSBvZiB0aGUg bWFpbiBtb3RpdmF0aW9ucyBmb3IgaGF2aW5nIGFyZWFzIGlzIHRvIGFic3RyYWN0IHRoZSB0b3Bv bG9neSB3aXRoaW4gdGhlIGFyZWEuIE5vdyB5b3UncmUgdHJ5aW5nIHRvIHN1cHBsYW50IHRoaXMg Jm5ic3A7LSBvbmUgdG9wb2xvZ2ljYWwNCiBkZXRhaWwgYXQgYSB0aW1lIHdpdGggaWxsLWNvbmNl aXZlZCBJR1AgZmVhdHVyZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsgQWNlZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5 My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBPbiA5LzI5 LzIwLCA1OjE1IEFNLCAmcXVvdDtMc3Igb24gYmVoYWxmIG9mIFBldGVyIFBzZW5hayZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnJTIwb24lMjBiZWhhbGYlMjBv ZiUyMHBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5sc3ItYm91bmNlc0BpZXRmLm9yZw0K IG9uIGJlaGFsZiBvZiBwcHNlbmFrPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9zcGFuPjwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIaSBBaWp1biw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gMjkvMDkvMjAyMCAxMTowNywgQWlqdW4gV2FuZyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyBIaSwgUGV0ZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgVGhhbmtzIGZvciB5 b3VyIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDEuIEZvciBCR1AtTFMgZGVwbG95bWVudCwgdGhlcmUgbm9y bWFsbHkgb25seSBiZSBvbmUgcm91dGVyIHRoYXQgd2l0aGluIHRoZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IElHUCBkb21h aW4gdG8gcmVwb3J0IHRoZSB0b3BvbG9neSBpbmZvcm1hdGlvbiwgdGhpcyByb3V0ZXIgc2hvdWxk IGtub3cgc3VjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IHBhc3NpdmUgbGlua3Mgd2hpY2ggZXhpc3RzIG1haW5seSBvbiBv dGhlciBib3JkZXIgcm91dGVycyB2aWEgdGhlIElHUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHByb3RvY29sLiBUaGlzIGlz IG1haW4gcmVhc29uIHRvIGV4dGVuc2lvbiB0aGUgSUdQIHByb3RvY29sLiAmZ3Q7IDIuIEZvciB0 aGUgc29sdXRpb24sIG5vcm1hbGx5LCB0aGUgbGluayB3aXRoaW4gdGhlIElHUCBjb25uZWN0IHR3 bw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ZW5kcywgYnV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcGFzc2l2ZSBpbnRlcmZhY2UgaXMgc3BlY2lh bCBhbmQgbm90IGZhbGwgaW4gdGhpcyBzcGFjZS4gV2UgaGF2ZSBzdHVkaWVkIHRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGN1cnJlbnQgVExWcyB0aGF0IGZvciBsaW5rLCBhbmQgZmluZCBubyBzdWl0YWJsZSBjb250YWlu ZXIgdG8gYXBwZW5kIHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpbmZvcm1hdGlvbi4gVGhpcyBpcyB0aGUgcmVhc29u IHRoYXQgd2Ugc2VsZWN0IHRoZSBUTFZzIHRoYXQgYXNzb2NpYXRlZCB3aXRoPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojkz LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgUHJl Zml4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZiB0aGUgbGluayBpcyB1bm51bWJlcmVk LCB5b3VyIHNvbHV0aW9uIGRvZXMgbm90IHdvcmsuIEFzIEkgc2FpZCwgaWYNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5 My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3lv dSBuZWVkIGEga25vd2xlZGdlIGFib3V0IHRoZSBsaW5rLCB5b3UgY2FuIG5vdCBhZHZlcnRpc2Ug aXQgYXMgYSBwcmVmaXguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYW5rcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGV0 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jmd0OyZndDtGcm9tIG90aGVyIFBPViwgdGhlIE9TUEZ2MyBkZWZpbmVzIG5v dyB0aGUgJnF1b3Q7SW50cmEtQXJlYS1QcmVmaXggTFNBJnF1b3Q7LCB3aGljaDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5 My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGlz b2xhdGUgdGhlIHByZWZpeCBpbmZvcm1hdGlvbiB0aGF0IGFzc29jaWF0ZWQgd2l0aCBsaW5rIGlu dG8gdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IGNvbnRhaW5lciwgY29udGFpbnMgdGhlIHN0dWIgbGluaywgbG9jYWwg aW50ZXJmYWNlIGluZm9ybWF0aW9uIGV0Yy4gUHV0IHN1Y2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBhdHRyaWJ1dGUgYWxv bmcgd2l0aCB0aGUgcHJlZml4IGlzIHRoZW4gYWNjZXB0YWJsZT88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jmd0OyBCZXN0IFJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBB aWp1biBXYW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgQ2hpbmEgVGVsZWNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgRnJvbToNCjxhIGhyZWY9Im1haWx0bzps c3ItYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmxzci1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4gWzxhIGhyZWY9 Im1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+XSBPbiBCZWhhbGYNCiBPZiBQZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFBzZW5hazxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFNlbnQ6 IFR1ZXNkYXksIFNlcHRlbWJlciAyOSwgMjAyMCA0OjI5IFBNPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgVG86IEFpanVuIFdh bmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbiI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPndhbmdhajNAY2hpbmF0 ZWxlY29tLmNuPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgQ2M6DQo8YSBocmVmPSJtYWlsdG86bHNy QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+bHNyQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBTdWJqZWN0OiBSZTogW0xzcl0g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBkcmFmdC13YW5nLWxzci1w YXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUtMDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsg SGkgQWlqdW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgaGVyZSdzIG15IGNvbW1lbnRzOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmZ3Q7IFRoZSBwdXJwb3NlIG9mIHRoaXMgZHJhZnQgaXMgdG8gYWR2ZXJ0 aXNlIHBhc3NpdmUgbGlua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgMS4gSSdtIG5vdCBzdXJl IHRoZSBwcm9ibGVtIG5lZWRzIHRvIGJlIHNvbHZlZCBieSBJR1BzLiBJIHRlbmQgdG8gYmVsaWV2 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IGlldGYtaWRyLWJncGxzLWludGVyLWFzLXRvcG9sb2d5LWV4dCBpcyBzdWZmaWNp ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IDIuIHRoZSBzb2x1dGlvbiB0aGF0IHlvdSBwcm9w b3NlZCBpcyB3cm9uZy4gWW91IGFyZSB0cnlpbmcgdG8gZGVyaXZlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdG9wb2xvZ2lj YWwgZGF0YSBhYm91dCB0aGUgcGFzc2l2ZSBsaW5rcyBmcm9tIHRoZSBwcmVmaXggYWR2ZXJ0aXNl bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBUaGlzIGlzIHNlbWFudGljYWxseSBpbmNvcnJlY3QgYW5kIG9ubHkgd29y a3MgdW5kZXIgdmVyeSBzcGVjaWZpYyBjb25kaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSWYgeW91IG5lZWQgdG8g YWR2ZXJ0aXNlIGEgbGluaywgYWR2ZXJ0aXNlIGl0IGFzIGEgJnF1b3Q7c3BlY2lhbCZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IGxpbmssIG5vdCBhcyBhICZxdW90O3NwZWNpYWwmcXVvdDsgcHJlZml4LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmZ3Q7IHRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBQZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm Z3Q7IE9uIDI5LzA5LzIwMjAgMDM6MTcsIEFpanVuIFdhbmcgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IEhp LCBQZXRlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgV291bGQgeW91IGxpa2UgdG8gcmV2aWV3 IGFuZCBnaXZlIGNvbW1lbnRzIG9uIHRoZSB1cGRhdGVzIHZlcnNpb24gb2YgdGhpczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGRyYWZ0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyBXZSBoYXZlIGFsc28gYWRkZWQgdGhlIHByb3RvY29sIGV4dGVu c2lvbiBwcm9wb3NhbCBmb3IgT1NQRnYzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBUaGUgdXBk YXRlIHZlcnNpb24gb2YgdGhpcyBkcmFmdCBjYW4gcmVmZXIgdG88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsNCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtd2FuZy1sc3It cGFzc2l2ZS1pbnRlcmZhY2UiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2U8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyAtYXR0 cmlidXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7IFRoYW5rcyBpbiBhZHZhbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyBCZXN0IFJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgQWlq dW4gV2FuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyBDaGluYSBUZWxlY29tPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojkz LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgRnJvbToNCjxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8L3NwYW4+PC9hPiBbPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPm1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZndDsmZ3Q7IFNl bnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI4LCAyMDIwIDM6MTcgUE08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IFRv OiBaaGlibyBIdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1emhpYm9AaHVhd2VpLmNvbSI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh1emhpYm9AaHVh d2VpLmNvbTwvc3Bhbj48L2E+Jmd0OzsgR3lhbiBNaXNocmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbSI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmd5YW4ucy5taXNocmFAdmVyaXpv bi5jb208L3NwYW4+PC9hPiZndDs7IEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5n YWozQGNoaW5hdGVsZWNvbS5jbiI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPC9zcGFuPjwvYT4mZ3Q7Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsgR3lhbiBTLiBNaXNocmEgJmx0OzxhIGhyZWY9Im1haWx0bzpneWFuLnMu bWlzaHJhQHZlcml6b24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTwvc3Bhbj48L2E+Jmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7Jmd0OyZndDsgU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0 LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBBIG5l dyB2ZXJzaW9uIG9mIEktRCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGRyYWZ0LXdhbmctbHNyLXBhc3NpdmUt aW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgQWlqdW4gV2FuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 IE5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LXdhbmctbHNyLXBhc3NpdmUt aW50ZXJmYWNlLWF0dHJpYnV0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgUmV2aXNpb246Jm5ic3A7Jm5ic3A7 IDA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBUaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUGFzc2l2ZSBJbnRlcmZhY2UgQXR0cmlidXRlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojkz LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyBEb2N1bWVudCBkYXRlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAy MDIwLTA5LTI4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBHcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBQYWdlczombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgVVJMOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsN CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXdhbmctbHNyLXBhc3NpdmUt aW50ZXJmYWNlLWF0dHJpYnV0ZS0wNCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXdhbmctbHNy LXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNDwvc3Bhbj48L2E+LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsgdHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBTdGF0dXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ow0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1p bnRlcmZhY2UtYXR0Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRp b246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1sc3It cGFzc2l2ZS1pbnRlcmZhY2UtYXR0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IHI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7IGlidXRlLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgSHRtbGl6ZWQ6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 Ow0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13 YW5nLWxzci1wYXNzaXZlLWludGVyZmFjIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7IGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7IC1hdHRyaWJ1dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsgSHRtbGl6ZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ow0KPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0 Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNl LWF0dHJpYnV0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IC0w NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDsgRGlmZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZh Y2UtYXQiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd2FuZy1sc3ItcGFzc2l2 ZS1pbnRlcmZhY2UtYXQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsgcmlidXRlLTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgQWJzdHJhY3Q6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyB0aGUgbWVjaGFuaXNtIHRoYXQgY2FuIGJlIHVzZWQgdG88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpZmZlcmVudGlhdGUgdGhlIHBhc3Np dmUgaW50ZXJmYWNlcyBmcm9tIHRoZSBub3JtYWwgaW50ZXJmYWNlczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0aGluIElTSVMgb3IgT1NQRiBkb21haW4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmZ3Q7IHRvb2xzLmlldGYub3JnLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IFRo ZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5 My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgTHNyIG1haWxp bmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7DQo8YSBocmVmPSJtYWlsdG86THNyQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+THNyQGlldGYub3JnPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0Ow0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sc3IiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcjwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBMc3IgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJtYWlsdG86THNyQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+THNy QGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHNyIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3I8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyBMc3IgbWFpbGluZyBsaXN0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJtYWlsdG86THNy QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+THNyQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJz cDsmbmJzcDsNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHNyIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3I8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjkzLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+THNyIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1h aWx0bzpMc3JAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lIj5Mc3JAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3I8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_92C4AB955CE64BFFBDFB5F6322952994ciscocom_-- From nobody Sat Oct 10 05:48:18 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AC13A14A2 for ; Sat, 10 Oct 2020 05:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=MbvRs6zP; dkim=pass (1024-bit key) header.d=juniper.net header.b=cDJwgice 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 Nln6jVVz8aC1 for ; Sat, 10 Oct 2020 05:48:14 -0700 (PDT) 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 3AE933A0EAD for ; Sat, 10 Oct 2020 05:48:14 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09AClsCq027814; Sat, 10 Oct 2020 05:47:54 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=Rc4VKPoW15sLbKGvZf/fhppj7NoJMnvscioF2IdLFQg=; b=MbvRs6zP8GZbzGJD1r3snFKFQX+seLFE7E1XI/cJXx09MrwvASEn92MHpyr42ao+K32i FJWHsBEKxEH/q+m1K5QtP7+gzgRD+rDIId1Gdxl9mlAb1Pg3EKGi6NR/stQz8jyBZaig z/JgEJ6x+LNJf7JSrucmmRo1RaqUwdsUiPdfQfz6B+nwJmXC8sIQnzZ1dp56y7BhygL9 184PyimN4jLSRb4xZ7ZO5EiJJHm1IsjMGKLFdVse8HF2gqm+sMjYV+Vllm8W49UTGqcS PhpgyftRpP4B+kbE4x4ZR27aIKSbu5Bg9c2PLXZm/9oCKH94payRZN70R1R+3jX2utI5 jg== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2174.outbound.protection.outlook.com [104.47.58.174]) by mx0b-00273201.pphosted.com with ESMTP id 343b79g30d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Oct 2020 05:47:54 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cdcopq4j5gHKevcQ4onl9G9xIRIHrmcFJVRNcL1tQ77d03QJ5iAp6oU1726tVwQbOi1odnpuPuF78LlKRPcGqHSLm39XBdfB13r30uvy59fxt9gfOHoXQdQG9Wt/UPNhg3UK8uPjYEWHzbQ8MN30jCqm8orbcZCpAfssy09LPU2pggd2llYEVm9VzM66jBBRvaFiiUmFGbgeluxqtek0P0PAohsgOXl4V6flzw2OxUD45CU2f4/gSBUWqmwGuYbSkK+tQQapCqT1d2Exx0GVqOGWdz1fC/jB26J8ssX29XJqzfeHb+HdObm30bkKLBOfbZN47rVrey2mgloc55S5oA== 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=Rc4VKPoW15sLbKGvZf/fhppj7NoJMnvscioF2IdLFQg=; b=Kw2lQAk0rGPHjCYiT9Sm1hV4I8d0cj7cjV7iq+//XrDkxZwYXYDAPNpBtqexSB7n1eVXnMyYhn8+y3GC5PO4xur0QE2ZMrA02wBp8bpAo4G+BWyLgoiV8NnpcQCWoB/cgoGD1YVonA8HUsOkbh9JVKLTkUMsU2tJT0qA47DxYqWnZVg68ePrA9tGO6svvh9eEWaHM4W/SQnCfqZlsr24XaUjvp0sZlIPFsc1JLDH0AQImPe8ywHkLlHiuzNuhiIxiY2AnLoDhraZgby1jR7vVrmeE8m96jHILn2zZi9Ie7TS0jDh16YvX//hwQ8guFsMEf9mLWwFVJf0MfSoM+OUcg== 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=Rc4VKPoW15sLbKGvZf/fhppj7NoJMnvscioF2IdLFQg=; b=cDJwgice+cppi+OyqCt21N+39irkCHZNBmWUeEu1b+pt32bV9rECPbUCMP5avYb3zqC1q3oPJulFTFUG4llHxWaiY09sluuc6BfwCQ4R4NrIXPsCtICvp6LcPZz5Enp234mBWFO4n9I/0MyA53MxFpRpjsS2Bft/Dust2cJt/KA= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB6508.namprd05.prod.outlook.com (2603:10b6:5:12e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Sat, 10 Oct 2020 12:47:49 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782%3]) with mapi id 15.20.3477.011; Sat, 10 Oct 2020 12:47:49 +0000 From: Ron Bonica To: "Dongjie (Jimmy)" , Peter Psenak , Yingzhen Qu , Gyan Mishra CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAGYiICAAB9mMIAA726AgADTSnCAAWzZgIAAAz2A///GWICAAVg7AIAAFmsAgACYCCCACE1YgIAA2YqAgAC6nQCAAJ/jwA== Date: Sat, 10 Oct 2020 12:47:49 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-10T12:47:48Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=02ffa1fd-246e-42ae-81d4-1738dfd4c0a1; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.115.7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ad5f72a4-6527-49f6-94da-08d86d1ab20e x-ms-traffictypediagnostic: DM6PR05MB6508: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 00V3htqd6pRnb9VRiDFo/Q9uFEkNoVfYTa2MFkQ/6IVtILO9IUAJHlnUyVZvrGpM3nMnBmYN6FeKBxWV2oBxr/IB1btY7+O9esvqzxDAyiLPsYGQLVIEqDc8YWhZvNGgp4X/vOUU/1qnXfqJ3Tl7HaK6ksTK3O7sU4SsdMCxu/yGbYPN9sOS/IsKz7j90e7FRxOMW69wYIk3bdrGsfFk2FwjxlmnqBj1Cm82MuCXZgyVand0+JYvZYd1ev3UWSs/qSaQecAyIsQa09r1OLAKNuVWiS34o8WfLy8tBaWaH9kxaqjZs7Fk3vQ1rx2vHeg56oJrDoRr1O24kwvBYoKAlPuTb4Zf5npWrXNvWobvePeFzyR7/OtmUJyQOGeKalURa4ly5Wtz2qhEpMObJXpUkg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(346002)(366004)(376002)(39860400002)(8676002)(4326008)(76116006)(8936002)(64756008)(66556008)(66476007)(66446008)(66946007)(2906002)(83380400001)(52536014)(54906003)(110136005)(5660300002)(316002)(33656002)(478600001)(966005)(15650500001)(7696005)(45080400002)(55016002)(186003)(26005)(9686003)(83080400001)(71200400001)(86362001)(6506007)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: mKjTg7Mky9mXLiCh1Rc/7120xdX/OJaW8Ufg9T8cGpdLtrmPTwq8PF07o83LGrMOkaihGNch931AS5GkSs1ogEA9EEaD3Jvs4H6/lEMSD85EqTVaAHC74mYdy3ifUUWE7DzfyNMK3ctJJnVeL3V5kY4V/gxq0nrYSAWO4e5vbhdAlsTJvkR3N2/k7g4GdrTLxc6Hsft3SW/a3U3HKtmeqIxv4wAbfiocL/eaXSlHTXMk0JfvB/JnAe7fezQMLfHXFfQXgEX3qJkIAUW8MafXqCWlb4FNNgMuF3BNU83OR/rcQE/9Mk3nOs12f5FHNM49kTJzJQv1fvOTTtjZVhEsrYMMXPW9dTkMjUPo446ec73E5WIfR9NDNFquEXNu4wJxytUZD4FodMjmsdDrfVoh5AAA5X0epTrysD7/aSwbfzWsne3VCkTcgI1TjrmvWgRemZCbTYxXesruyZytL0TO+qn4dYP2VK10AGOjrjQpXFBlLqXiqDJ84DYpiyn+/tteNA94m7tMxaCRM6NutHIRUwfF8VM6mrSeIw1dLJ2Y3pClYbR39qcf5MX+HmeHaFEzGS/h31HLKW18rosKYnSTEAbm7vr1edmOjsWuyCKJolF99lbkp1qTR2lXW9CZ2cmzDmBFUahmP7K3o16E5UWzdA== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ad5f72a4-6527-49f6-94da-08d86d1ab20e X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2020 12:47:49.5763 (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: 1yRJRmfEs2t3wFRSis6529yVKiHdLSFDuq5qwCEnMRlYhzoD8+1rK/haSL7fCHqrCtWuunyoDUTNS7RSxyx06A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6508 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-10_07:2020-10-09, 2020-10-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 mlxscore=0 phishscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 spamscore=0 clxscore=1015 mlxlogscore=999 priorityscore=1501 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010100120 Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 12:48:17 -0000 Hi Jimmie, Inline..... Ron Juniper Business Use Only -----Original Message----- From: Dongjie (Jimmy) =20 Sent: Friday, October 9, 2020 11:06 PM To: Peter Psenak ; Ron Bonica ; Yin= gzhen Qu ; Gyan Mishra Cc: lsr@ietf.org; Jeff Tantsura Subject: RE: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-fle= xalgo-00.txt [External Email. Be cautious of content] Hi Peter, Thanks for your reply. It aligns with my understanding of FAD, which is jus= t a set of constraints for path computation. Thus one Flex-Algo ID could be= used with multiple different data planes. Is this understanding correct? [RB] I never thought about this. Is there a use-case? I think that it will = work, but I would have to try it before saying for sure. If so, my question is about the scenario below: A group of nodes in a network support FA-128, a sub-group of them bind FA-1= 28 to SR SIDs, another sub-group of them bind FA-128 to IP address. When on= e node compute an SR path to a destination, can it compute the path to only= pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bin= d FA-128 to IP address?=20 [RB] I don't think so. However, you could achieve the same outcome using li= nk colors. If so, how could this node know the binding of FA to different data planes = on other nodes? Best regards, Jie > -----Original Message----- > From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > Sent: Friday, October 9, 2020 11:58 PM > To: Dongjie (Jimmy) ; Ron Bonica=20 > ; Yingzhen Qu=20 > ; Gyan Mishra > Cc: lsr@ietf.org; Jeff Tantsura > Subject: Re: [Lsr] FW: New Version Notification for=20 > draft-bonica-lsr-ip-flexalgo-00.txt > > Hi Jimmy, > > > On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > > Hi Ron, > > > > Thanks for explaining the difference between IP Flex-Algo and SR=20 > > Flex-algo. As > you said, the major difference is the data plane. > > > > If my understanding is correct, for one Flex-Algo to be used=20 > > correctly, the set > of nodes need to apply consistent constraints in computation, and bind=20 > the FAD to the same data plane. > > > > Is it possible that different nodes may use the same Flex-Algo with=20 > > different > data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure=20 > IP etc., or each Flex-Algo is always associated with only one data=20 > plane? In the former case, should the flex-algo definition also=20 > indicate the data plane(s) to be used with the flex-algo? > > let me respond to this query, as this is not specific to Ron's draft. > > FAD is data plane agnostic and is used by all of them. > > thanks, > Peter > > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica > >> Sent: Sunday, October 4, 2020 4:34 AM > >> To: Yingzhen Qu ; Peter Psenak=20 > >> ; Gyan Mishra > >> Cc: lsr@ietf.org; Jeff Tantsura > >> Subject: Re: [Lsr] FW: New Version Notification for=20 > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> Hi Yingzhen, > >> > >> IP Flexible Algorithms are like SR Flexible Algorithms in the=20 > >> following > respects: > >> > >> - Links have IGP metrics, TE metrics, delay metrics and=20 > >> administrative colors > >> - FADs define Flexible Algorithms > >> > >> More specifically, the FAD: > >> > >> - Indicates which metric type the Flexible Algorithm uses > >> - Specifies constraints in terms of link colors that are included=20 > >> or excluded from the Flexible Algorithm. > >> > >> The significant difference between IP Flexible Algorithms and SR=20 > >> Flexible Algorithms is: > >> > >> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators > >> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > >> > >> So, IP Flexible Algorithms can be deployed in any IP network, even=20 > >> in the absence of SR. > >> > >> Ron > >> > >> > >> Juniper Business Use Only > >> > >> -----Original Message----- > >> From: Yingzhen Qu > >> Sent: Saturday, October 3, 2020 2:08 PM > >> To: Peter Psenak ; Gyan Mishra=20 > >> ; Ron Bonica > >> Cc: lsr@ietf.org; Jeff Tantsura > >> Subject: Re: [Lsr] FW: New Version Notification for=20 > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> [External Email. Be cautious of content] > >> > >> > >> Hi Peter, > >> > >> Using flex-algo, a SRv6 locator can be associated with a single=20 > >> algo, which means an IPv6 or IPv4 address can also be associated=20 > >> with a single algo. So my understanding is Ron's proposal is making=20 > >> the > configuration of flex-algo easier? > >> Instead of using the exclude or include list you can configure a=20 > >> loopback address to a flex-algo directly? > >> > >> Thanks, > >> Yingzhen > >> > >> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: > >> > >> Hi Yingzhen, > >> > >> On 02/10/2020 22:15, Yingzhen Qu wrote: > >> > Hi Peter, > >> > > >> > My understanding of flex-algo is that for traffic destined=20 > >> to a prefix on a particular algo, it can only be routed on routers=20 > >> belong to that algo, which also means only routers in that algo=20 > >> calculates how to reach that prefix and install it into the routing=20 > >> table. It seems to me that using flex-algo (section 12 of the > >> draft) it's possible to have a loopback address associated with=20 > >> only one algo, please correct me if I'm missing or misunderstood somet= hing. > >> > >> you are right. That is exactly what is being done for flex-algo w= ith > >> SRv6 - locator is associated with a single algo only. The proposa= l uses > >> the same concept. > >> > >> thanks, > >> Peter > >> > >> > > >> > Thanks, > >> > Yingzhen > >> > > >> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > >> >> ppsenak=3D40cisco.com@dmarc.ietf.org> > >> wrote: > >> > > >> > Gyan, > >> > > >> > On 02/10/2020 18:30, Gyan Mishra wrote: > >> > > All, > >> > > > >> > > With SRv6 and IP based flex algo a generic question as i= t > applies > >> to > >> > > both. Is it possible to have within a single IGP domain > different > >> sets > >> > > of nodes or segments of the network running different > >> algorithms. > >> > > >> > absolutely. > >> > > >> > > From > >> > > both drafts it sounds like all nodes have to agree on sa= me > >> algorithm > >> > > similar to concept of metric and reference bandwidth all > have to > >> have > >> > > the same style metric and play to the same sheet of musi= c. > >> > > >> > all participating nodes need to agree on the definition of= the > >> flex-algo > >> > and advertise the participation. That's it. > >> > > >> > > If there was > >> > > a way to use multiple algorithms simultaneously based on > SFC > >> or services > >> > > and instantiation of specific algorithm based on service= to > be > >> > > rendered. Doing so without causing a routing loop or su= b > >> optimal > >> > > routing. > >> > > >> > you can certainly use multiple algorithms simultaneously a= nd > use > >> algo > >> > specific paths to forward specific traffic over it. How th= at is > done > >> > from the forwarding perspective depends in which > forwarding > >> plane you > >> > use. Flex-algo control plane is independent of the forward= ing > >> plane. > >> > > >> > > >> > >I thought with flex algo that there exists a feature that= on > >> > > each hop there is a way to specify which algo to use hop= by > hop > >> similar > >> > > to a hop by hop policy based routing. > >> > > >> > no, there is no hop-by-hop classification, that is problem= atic > and > >> does > >> > not scale for high speeds. Classification is done at the > ingress only. > >> > > >> > thanks, > >> > Peter > >> > > >> > > > >> > > >> > _______________________________________________ > >> > Lsr mailing list > >> > Lsr@ietf.org > >> > > >> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl > >> oo > >> k.com/ > >> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data > >> =3D > 0 > >> 2 > >> > *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 > >> > 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >> > 5126&sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >> > &reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR > >> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > >> > > >> > > >> > > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l > >> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H > >> z218CE8S8XzlIxAA$ > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218CE > 8S8XzlIxAA$ From nobody Sat Oct 10 12:13:47 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6683A1387 for ; Sat, 10 Oct 2020 12:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 PLFbJVkmw7On for ; Sat, 10 Oct 2020 12:13:43 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6393A1149 for ; Sat, 10 Oct 2020 12:13:43 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id x16so10200993pgj.3 for ; Sat, 10 Oct 2020 12:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=JbRw/3ZOMx76qZtbEZ7CkVbvz29jrNd1+NshiOCJsGE=; b=jBQF1LabZg7Nta9ADvVo9IAAbgP64L+ADcMW71v68b3MvjdTTiaSD0Jgv6aC+jbMkx WpqRtZfbrVVCRezfrdNG8MwKACQUmQirs5l3n3eRs4urJnLhhOgCSwVY8xHO0noQ3rqM C2Rp82v/262s5FLIo3ipW1cnXFIY5O5qoI4L47fhEJc5RBykh5LmWRFS0gpMUaTBKyuw JOjodbjyrO7LESKhuOjV0GLjUtr6WyeqBJWRFmvkhMhWsjw5R/GDBXm6H43c7nFBwOVe J59FLuZRvQB+TwnfHAbTMbXq9ubXsGNT7fgn7fpygtlvHLfTBnGZgzDT5W443j0UVY8M T3nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=JbRw/3ZOMx76qZtbEZ7CkVbvz29jrNd1+NshiOCJsGE=; b=ftatd4iDExITTAT59DI0cNepxkQKNT9wJGXyb6XgAKNPE3VZBrYHm501//fFZqQjee V4MXYMotQrHLDGtdj1jlQxx4peRRqzxGCDE/hF7CE2oYcw4KU1wFqU2rmf9kJnF3SwSX uDprOKz5gvcPjazfBisrhURSfMxNcXRhcrPNupyF8c1swjjmGNZlMwHrZ7KRe26cb8Jr F5yskMzXWcUPuQk1YWnfyK58ve6qEQtTxLttg6R6HZIGXsHHI2irEKiMgzmv5m2IimNQ H/pvlnkWriP+cxq9qowKqDX7xj0upj36rZhgKMkYhEGIU9mEUEaKjOH3SqH4va5a4xMi KgQg== X-Gm-Message-State: AOAM5322iVqmFRZzRMUqRQIZTjauAkCwHW7Hie0nvC2sxkgS68ek5a/U UOPakIfa8eHkFNk8SdXI/IY= X-Google-Smtp-Source: ABdhPJyno8JWtVhi7ANPfhBuw8tzB9zqSh1qXpMUQREYQeRErihUtJYXi+NV+09ykprdofQprdTOFA== X-Received: by 2002:a17:90a:b902:: with SMTP id p2mr11278692pjr.15.1602357223093; Sat, 10 Oct 2020 12:13:43 -0700 (PDT) Received: from [192.168.1.18] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id s186sm48681pfs.51.2020.10.10.12.13.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2020 12:13:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jeff Tantsura Mime-Version: 1.0 (1.0) Date: Sat, 10 Oct 2020 12:13:38 -0700 Message-Id: <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.com> References: Cc: "Dongjie (Jimmy)" , Peter Psenak , Yingzhen Qu , Gyan Mishra , lsr@ietf.org In-Reply-To: To: Ron Bonica X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 19:13:46 -0000 Jie, The scoop is different, for SR data plane entry uniqueness is in context of S= R domain (SID =3D value + context), while for IP it is global to the routing domain, FIB entry is a destination,= nothing more. Regards, Jeff > On Oct 10, 2020, at 05:47, Ron Bonica wrote: >=20 > =EF=BB=BFHi Jimmie, >=20 > Inline..... >=20 > Ron >=20 >=20 > Juniper Business Use Only >=20 > -----Original Message----- > From: Dongjie (Jimmy) =20 > Sent: Friday, October 9, 2020 11:06 PM > To: Peter Psenak ; Ron Bonica ; Yi= ngzhen Qu ; Gyan Mishra > Cc: lsr@ietf.org; Jeff Tantsura > Subject: RE: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-fl= exalgo-00.txt >=20 > [External Email. Be cautious of content] >=20 >=20 > Hi Peter, >=20 > Thanks for your reply. It aligns with my understanding of FAD, which is ju= st a set of constraints for path computation. Thus one Flex-Algo ID could be= used with multiple different data planes. Is this understanding correct? >=20 > [RB] I never thought about this. Is there a use-case? I think that it will= work, but I would have to try it before saying for sure. >=20 > If so, my question is about the scenario below: >=20 > A group of nodes in a network support FA-128, a sub-group of them bind FA-= 128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When on= e node compute an SR path to a destination, can it compute the path to only p= ass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA= -128 to IP address?=20 >=20 > [RB] I don't think so. However, you could achieve the same outcome using l= ink colors. >=20 > If so, how could this node know the binding of FA to different data planes= on other nodes? >=20 > Best regards, > Jie >=20 >> -----Original Message----- >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak >> Sent: Friday, October 9, 2020 11:58 PM >> To: Dongjie (Jimmy) ; Ron Bonica=20 >> ; Yingzhen Qu=20 >> ; Gyan Mishra >> Cc: lsr@ietf.org; Jeff Tantsura >> Subject: Re: [Lsr] FW: New Version Notification for=20 >> draft-bonica-lsr-ip-flexalgo-00.txt >>=20 >> Hi Jimmy, >>=20 >>=20 >>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: >>> Hi Ron, >>>=20 >>> Thanks for explaining the difference between IP Flex-Algo and SR=20 >>> Flex-algo. As >> you said, the major difference is the data plane. >>>=20 >>> If my understanding is correct, for one Flex-Algo to be used=20 >>> correctly, the set >> of nodes need to apply consistent constraints in computation, and bind=20= >> the FAD to the same data plane. >>>=20 >>> Is it possible that different nodes may use the same Flex-Algo with=20 >>> different >> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure=20= >> IP etc., or each Flex-Algo is always associated with only one data=20 >> plane? In the former case, should the flex-algo definition also=20 >> indicate the data plane(s) to be used with the flex-algo? >>=20 >> let me respond to this query, as this is not specific to Ron's draft. >>=20 >> FAD is data plane agnostic and is used by all of them. >>=20 >> thanks, >> Peter >>=20 >>>=20 >>> Best regards, >>> Jie >>>=20 >>>> -----Original Message----- >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >>>> Sent: Sunday, October 4, 2020 4:34 AM >>>> To: Yingzhen Qu ; Peter Psenak=20 >>>> ; Gyan Mishra >>>> Cc: lsr@ietf.org; Jeff Tantsura >>>> Subject: Re: [Lsr] FW: New Version Notification for=20 >>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>=20 >>>> Hi Yingzhen, >>>>=20 >>>> IP Flexible Algorithms are like SR Flexible Algorithms in the=20 >>>> following >> respects: >>>>=20 >>>> - Links have IGP metrics, TE metrics, delay metrics and=20 >>>> administrative colors >>>> - FADs define Flexible Algorithms >>>>=20 >>>> More specifically, the FAD: >>>>=20 >>>> - Indicates which metric type the Flexible Algorithm uses >>>> - Specifies constraints in terms of link colors that are included=20 >>>> or excluded from the Flexible Algorithm. >>>>=20 >>>> The significant difference between IP Flexible Algorithms and SR=20 >>>> Flexible Algorithms is: >>>>=20 >>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators >>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. >>>>=20 >>>> So, IP Flexible Algorithms can be deployed in any IP network, even=20 >>>> in the absence of SR. >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> Juniper Business Use Only >>>>=20 >>>> -----Original Message----- >>>> From: Yingzhen Qu >>>> Sent: Saturday, October 3, 2020 2:08 PM >>>> To: Peter Psenak ; Gyan Mishra=20 >>>> ; Ron Bonica >>>> Cc: lsr@ietf.org; Jeff Tantsura >>>> Subject: Re: [Lsr] FW: New Version Notification for=20 >>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>=20 >>>> [External Email. Be cautious of content] >>>>=20 >>>>=20 >>>> Hi Peter, >>>>=20 >>>> Using flex-algo, a SRv6 locator can be associated with a single=20 >>>> algo, which means an IPv6 or IPv4 address can also be associated=20 >>>> with a single algo. So my understanding is Ron's proposal is making=20 >>>> the >> configuration of flex-algo easier? >>>> Instead of using the exclude or include list you can configure a=20 >>>> loopback address to a flex-algo directly? >>>>=20 >>>> Thanks, >>>> Yingzhen >>>>=20 >>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: >>>>=20 >>>> Hi Yingzhen, >>>>=20 >>>> On 02/10/2020 22:15, Yingzhen Qu wrote: >>>>> Hi Peter, >>>>>=20 >>>>> My understanding of flex-algo is that for traffic destined=20 >>>> to a prefix on a particular algo, it can only be routed on routers=20 >>>> belong to that algo, which also means only routers in that algo=20 >>>> calculates how to reach that prefix and install it into the routing=20 >>>> table. It seems to me that using flex-algo (section 12 of the >>>> draft) it's possible to have a loopback address associated with=20 >>>> only one algo, please correct me if I'm missing or misunderstood someth= ing. >>>>=20 >>>> you are right. That is exactly what is being done for flex-algo wit= h >>>> SRv6 - locator is associated with a single algo only. The proposal u= ses >>>> the same concept. >>>>=20 >>>> thanks, >>>> Peter >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Yingzhen >>>>>=20 >>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >>>> >>> ppsenak=3D40cisco.com@dmarc.ietf.org> >>>> wrote: >>>>>=20 >>>>> Gyan, >>>>>=20 >>>>> On 02/10/2020 18:30, Gyan Mishra wrote: >>>>>> All, >>>>>>=20 >>>>>> With SRv6 and IP based flex algo a generic question as it >> applies >>>> to >>>>>> both. Is it possible to have within a single IGP domain >> different >>>> sets >>>>>> of nodes or segments of the network running different >>>> algorithms. >>>>>=20 >>>>> absolutely. >>>>>=20 >>>>>> From >>>>>> both drafts it sounds like all nodes have to agree on same >>>> algorithm >>>>>> similar to concept of metric and reference bandwidth all >> have to >>>> have >>>>>> the same style metric and play to the same sheet of music. >>>>>=20 >>>>> all participating nodes need to agree on the definition of the >>>> flex-algo >>>>> and advertise the participation. That's it. >>>>>=20 >>>>>> If there was >>>>>> a way to use multiple algorithms simultaneously based on >> SFC >>>> or services >>>>>> and instantiation of specific algorithm based on service to >> be >>>>>> rendered. Doing so without causing a routing loop or sub >>>> optimal >>>>>> routing. >>>>>=20 >>>>> you can certainly use multiple algorithms simultaneously and >> use >>>> algo >>>>> specific paths to forward specific traffic over it. How that is >> done >>>>> from the forwarding perspective depends in which >> forwarding >>>> plane you >>>>> use. Flex-algo control plane is independent of the forwarding >>>> plane. >>>>>=20 >>>>>=20 >>>>>> I thought with flex algo that there exists a feature that on >>>>>> each hop there is a way to specify which algo to use hop by >> hop >>>> similar >>>>>> to a hop by hop policy based routing. >>>>>=20 >>>>> no, there is no hop-by-hop classification, that is problematic >> and >>>> does >>>>> not scale for high speeds. Classification is done at the >> ingress only. >>>>>=20 >>>>> thanks, >>>>> Peter >>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Lsr mailing list >>>>> Lsr@ietf.org >>>>>=20 >>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl >>>> oo >>>> k.com/ >>>> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data >>>> =3D >> 0 >>>> 2 >>>>=20 >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 >>>>=20 >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >>>>=20 >> 5126&sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D >>>>=20 >> &reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR >>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H >>>> z218CE8S8XzlIxAA$ >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ >> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218CE >> 8S8XzlIxAA$ From nobody Sat Oct 10 12:32:54 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F083A16A9; Sat, 10 Oct 2020 12:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3J2Equ1DT48J; Sat, 10 Oct 2020 12:32:44 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 B04DB3A16A8; Sat, 10 Oct 2020 12:32:44 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id j15so4190590uaa.8; Sat, 10 Oct 2020 12:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=C4XmRFX1FdrrRzHy07a2GSoJiSgJ3YIKxx06VY1GuZo=; b=l/wT/6n79CIUOTv4pqm/K8lEE1kblzGre8C3S9aI7zSBJSmtJtUkXa/Oc2X7cZrOxx tPG2GJZoI2BMACc1gCsxIdz4YToMqMoSiCzoBOXZPBAtIM/mvFoZSlI6hqOFLS5jg1Z2 Tn1IB8Ni9ZZ9w4UcCTLTxD+js/PiGn9/vJIqaS3P8k0mW8zTeMHon59vKRFGdL99a7Mz z49KwWP4jw1O8WfZ744LzDfDiYMziEm5Z6jBczBBrcgqxSc0THiTQ9+j/JPgn4iJOa9b ZUXIpTTk9q9nULW4NCnLFgXSn9305pRe9vlJ2k5Lja7dEYCZvR5r9gYqUvFa83eGG7x4 ImPw== 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=C4XmRFX1FdrrRzHy07a2GSoJiSgJ3YIKxx06VY1GuZo=; b=VQermoRALA2KkWdwNg3v0Wd8mG3BGjMcsKBz8tBv5rs6bHe3vgmdL/W3s0C/rLYBmH NLTaIbEVzS5S3fxhM9+oZ+6it9RBwSlp3ItoXDo/zgMKEXei9Bmmix/KmV74EAp84tjw ceCQYp3IkfPZjvLG/56tpdNaZDoYJaaqoeDCpxpZTvX9AgkZh2PHoIusavRIHB6sPX5T BDWzcq/GlQQm2W/gHoEggJI9xsRYtzPrATsTSE5H3j/oZCyMKSs3wDgB7qxBs1nZEpDM WabvICI5TRX8tnwaj8K1VnxnFRlFTnGCp9wvtnzDinwCg3sL9jCiATAFGsrCG/1EOYwM 6olQ== X-Gm-Message-State: AOAM530ZTFK9LllVcyFQIYSmvsFSzqlT1QKc/OsV+gDiO5RTaLggDjuN W1jk7PR6/EwQ1fUgdIum7KMQm1nSHVMl+ZV5R+xteQMvxX6Q/Q== X-Google-Smtp-Source: ABdhPJyZ1k487MCskVdLlZNFlktDkewQsyuThKUxkuffWPOYTUDMTHhIxwhcpLmJa3JAeOY/f4u9n3FFMi/gmCi+dCc= X-Received: by 2002:a9f:25c3:: with SMTP id 61mr10691059uaf.111.1602358363286; Sat, 10 Oct 2020 12:32:43 -0700 (PDT) MIME-Version: 1.0 From: Gyan Mishra Date: Sat, 10 Oct 2020 15:26:56 -0400 Message-ID: To: TEAS WG , pce@ietf.org, IDR List , lsr , BESS , BIER WG , SPRING WG Content-Type: multipart/alternative; boundary="0000000000000bf09f05b15621d5" Archived-At: Subject: [Lsr] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2020 19:32:47 -0000 --0000000000000bf09f05b15621d5 Content-Type: text/plain; charset="UTF-8" Dear TEAS, PCE, IDR, LSR, BESS, BIER Spring Working Groups, I have noticed that after reviewing many drafts across many WGs it seems in the industry that the lines seem to be blurred between a PCE controller, ODL or Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X provisioning. As this is a software sitting on a server you can have a swiss army knife server that does everything from PCE path computation to Netconf/Yang ZTP & Day N provisioning as well as any SDN Controller ODL or Openflow controller type functions as well. How this comes into play and realization of the lines being blurred is the use of BGP-LS in building the IGP topological graph of the network which was designed for PCEP and PCE & PCC active & passive off line path computation for both RSVP-TE or SR-TE path instantiation. However now BGP-LS can also be used for other functions now such as usage as I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use BGP-LS to gather the elements internals within BIER using the same BGP-LS data structures to populate with BIER specific information to graph the BIER topology. So here we are not doing any path computations as we are using in this use case for NMS type function to gather data for ZTP & Day N provisioning. Similarly other use cases such as with TEAS TS-Transport slice and being able to provision TS and capturing the TS Enhanced VPN RT & resource information and leveraging BGP-LS to do the same data gathering & ZTP like controller style provisioning. It does seem as though BGP-LS as its a means of "data gathering" "dump truck" of anything with the kitchen sink included to build any type of topological graph of literally anything under the sun. I see that is a nice to leverage but it does in fact blur the lines of NMS Netconf/Yang Controller based functionality and PCE path computation functionality and SDN controller based ZTP functionality into a single ubiquitous server that can do all of the above and use BGP-LS to accomplish the "kitchen sink" tasks. It does however transform BGP to be an NMS tool but a "tool" and not just the original function which it was intended NLRI network reachability. Am I off base and please let me know as its BGP-LS is being way over leveraged. There are pros & cons to everything but I thought I would bring up to the WG as an important discussion point. Lots of food for thought. Welcome all comments as well as concerns related to this topic. Kind Regards, *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000000bf09f05b15621d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear TEAS, PCE, IDR, LSR, BESS, BIER=C2=A0 = Spring Working Groups,

I have noticed that after reviewi= ng many drafts across many WGs it seems in the industry that the lines seem= to be blurred between a PCE controller, ODL or Openflow SDN Controller and= a Netconf/Yang NMS Controller ZTP & Day X provisioning.

=
As this is a software sitting on a server you can have a swiss a= rmy knife server that does everything from PCE path computation to=C2=A0 Ne= tconf/Yang ZTP & Day N provisioning as well as any SDN Controller ODL o= r Openflow controller type functions as well.

How = this comes into play and realization of the lines being blurred is the use = of BGP-LS in building the IGP topological graph of the network which was de= signed for PCEP and PCE & PCC active & passive off line path comput= ation for both RSVP-TE or SR-TE path instantiation.=C2=A0=C2=A0
<= br>
However now BGP-LS can also be used for other functions now s= uch as usage as I am a Shepherd reviewing a draft for BGP-LS usage for BIER= to use BGP-LS to gather the elements internals within BIER using the same = BGP-LS data structures to populate with BIER specific information to graph = the BIER topology.=C2=A0 So here we are not doing any path computations as = we are using in this use case=C2=A0 for NMS type function to gather data fo= r ZTP & Day N provisioning.

Similarly other us= e cases such as with TEAS TS-Transport slice and being able to provision TS= and capturing the TS Enhanced VPN RT & resource information and levera= ging BGP-LS to do the same data gathering & ZTP like controller style p= rovisioning.=C2=A0

It does seem as though BGP-LS a= s its a means of "data gathering" "dump truck" of anyth= ing with the kitchen sink included to build any type of topological graph o= f literally anything under the sun.=C2=A0 I see that is a nice to leverage = but it does in fact blur the lines of NMS Netconf/Yang Controller based fun= ctionality and=C2=A0 PCE path computation functionality and SDN controller = based ZTP functionality into a single ubiquitous server that can do all of = the above and use BGP-LS to accomplish the "kitchen sink" tasks.= =C2=A0 It does however transform BGP to be an NMS tool but a "tool&quo= t; and not just the original function which it was intended NLRI network re= achability.

Am I off base and please let me k= now as its BGP-LS is being way over leveraged.=C2=A0 There are pros & c= ons to everything but I thought I would bring up to the WG as an important = discussion point.

Lots of food for thought.=C2=A0 = Welcome all comments as well as concerns related to this topic.
<= br>
Kind Regards,

Gyan Mishra

=

Network Solutions A<= /i>rchitect=C2=A0=

M 301 502-1347
13101 Columbia Pi= ke=C2=A0
Silver Spring, MD


--0000000000000bf09f05b15621d5-- From nobody Sun Oct 11 09:42:16 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D983A3A095F for ; Sun, 11 Oct 2020 09:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=B4pSmQ8a; dkim=pass (1024-bit key) header.d=juniper.net header.b=GZ2cjpv0 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 BcVOTvFH6Q6K for ; Sun, 11 Oct 2020 09:42:13 -0700 (PDT) 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 CF0EB3A0EC4 for ; Sun, 11 Oct 2020 09:42:12 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09BGfoc9023470; Sun, 11 Oct 2020 09:41:50 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=c+QWdqCNa1spRiODO8F0fdZN2uarj19v+ndGC+jfCz0=; b=B4pSmQ8avurRU0QX/pyJNJxfWZUsr2QE31ANBjtenZEQif8YKB/sJJn3KQuJanuahpOM uEmEUUDVkw65Bd7ktCbSvSOm9ZsbAfvApauHYDTLsgwa9PSL2XdEBxl5VtqMNE6qgeSN ag0FO1PF0NubRwCJ93m1feTzcayo5Z3ea9NeSjxwDpCRTqvVTuRnhlG8A9ETMzPSxhVF hnfesa8FDtjWivLff9CqCVe7xI42ZXJgnLq8mGyo2PyHOxcTfb+HKqmYgN8rYc+bjBmt DJbtD/bgVGaTGbqTV9T21hxxYManCZJEMdQIyyYnu2a0yHT2tiaHhJOPChUw7rmfzFLI CQ== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2053.outbound.protection.outlook.com [104.47.38.53]) by mx0b-00273201.pphosted.com with ESMTP id 343b79h8ce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 11 Oct 2020 09:41:49 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JQQkMZITGSq0TnKJZpFUsCn1ZFduL5+dNrFvWfLLlaeljxivY73G8wbq4WDovB8d2gtLv0UVNfGNih6ItKQpfqK2QIu03IXYfrBQy8X9tkVD33scVXKJABaw4PTC3Aro1HXemUqE7tR9CxpbB5G7NjN69qxGm1FoyhkAIWMQ///dozzK3/9YlQQRFR9no65ITO6y+93mP3kSgIOArmT2wj62GgJmXNz6WzGzkK8PZg9TjIB+vfTfBuBotulauy5iESexuo7Qg8nT9dQDBf62n4kgKIqRyzaGLfOqaVc1B++xn5HrpFKb5Aa7xpCOMPtD7jX0xV9WXHHaIfqDw46CzQ== 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=c+QWdqCNa1spRiODO8F0fdZN2uarj19v+ndGC+jfCz0=; b=bMqmkVh5gtYpvp/EONHJhzuj6hO4Sk2V1QNQY2RzZBHf6wPc5NpFyvEyurgUCDD/X2XBkUUIAFgwdJleMoF22746nZafEbvmWOn7J5e+HDYMp9Fc+r/+YWwRb6d6MfSv2s6BmfKCtZ1E+bIfyInYDrKS4SzBNlWql5TwwVnXj9uXu1FsucA6r1e+MOE/6Xo9ceK0SHo21buigB2C2cmx6RtP7MxJRING7ftZfBif2OJMAQrC/aA5DW5hlHdXnhxBGnE5c94qBj2AgZF6922ed9Tq2cy+YC2VNJgXX3Y409lbJW0obTO0Cot2G1U0tZLjQx4medUb5SfVqKTuWbvTTA== 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=c+QWdqCNa1spRiODO8F0fdZN2uarj19v+ndGC+jfCz0=; b=GZ2cjpv0fASHdZ5x1g53Zktr2h/fTFy6jYtKPysiuFlRKd0fjeLWRuC2+/LAlnr7uAKahW7/JoYlRsu9A3tQPXww0n9tMseVV6Vvt7SiyOVCYR+pOo1XXLNfA+650Ct+TnkjbvAuzB8ONdheayNMoxqVJOwYEbbUCFSAr/vYNU8= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5769.namprd05.prod.outlook.com (2603:10b6:5:102::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Sun, 11 Oct 2020 16:41:48 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::79ec:53dd:43c6:2782%3]) with mapi id 15.20.3477.017; Sun, 11 Oct 2020 16:41:48 +0000 From: Ron Bonica To: Jeff Tantsura CC: "Dongjie (Jimmy)" , Peter Psenak , Yingzhen Qu , Gyan Mishra , "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAGYiICAAB9mMIAA726AgADTSnCAAWzZgIAAAz2A///GWICAAVg7AIAAFmsAgACYCCCACE1YgIAA2YqAgAC6nQCAAJ/jwIAAbpcAgAFnkDA= Date: Sun, 11 Oct 2020 16:41:47 +0000 Message-ID: References: <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.com> In-Reply-To: <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-11T16:41:46Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=0724538e-6f99-4375-b46d-3469e55e4656; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.115.7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: de50527d-ae74-412a-1b1b-08d86e048bfa x-ms-traffictypediagnostic: DM6PR05MB5769: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TtR9PTD6qRulL6XaoY0X7GRMbRb5lm7VsaiII0VYAc9Rr3VRyTIFvgYWSojoHvqQO5RWyA6XCu9lt7PHE7aY8cKG+e/dPVxyM8KY7GaZdtLX5Ky1UTZeMDNLQpqlT2i3jk0ujc+GfzITw7ebkQgt6BsWA12ff4NSkjLcp25gtf7RIzOcktKRV3pHQhNWdRW5Nn0veOnRwEeaQDLa8BZzCmecaV5Z1anXgRZYlMW9Xid1NIsk+JYDnPasKwvBl2wOy/J0ammVpavc8w+XZfRpnVdgsaLqb02xtm5gMDiHxzvjKDolL6dqibGpQgch21PDGVQqVuGhrzh8i5RKX+CjI1jQwvZ1zG0MY0OtIqbplvGKFxQXeCnun598Dl7KJkP2FD55Y7eS/8hYLMAmNNPvhg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(376002)(136003)(39860400002)(396003)(7696005)(4326008)(15650500001)(54906003)(52536014)(45080400002)(966005)(186003)(26005)(83080400001)(9686003)(6916009)(478600001)(8936002)(2906002)(316002)(71200400001)(53546011)(83380400001)(64756008)(66556008)(66446008)(5660300002)(86362001)(66946007)(76116006)(66476007)(33656002)(6506007)(8676002)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: E/Q8QvSPTlL+2hGN8lpouNa+d6CERcfTOUWxF6z/oUK1YZQEzwEJ9ltql9miLShTkmKs8d2FDpkCcakhDzbaJ5+guHa4AboR9ig7Yol4gR3c5k8LKgHiDSEZyZOpYWXea++3k7wmiUWrOaC6h4gH+CPEgB1BCcPxjVef0JN6+8BQUjnOMFvmZs7Cmc3mXSoBiej/AG0IK7GWQgj0o8tEjBwFaGrGUONEOAs2vU4UOVfTlyi3zIoH+EpE0DG+eDezVEkli9bOAOmt7vwRfnaVzYnATVkPRfnRi915rpIKYl4u69zX5g1GHGwE6ReqOe619MZo0aA/MANTQR6sk7Iw94lhaLE1PxrmIY0Q1d0PFvncKaCOEGBXVBKoAS+RuG38181ThBGwncKSTt7RRSy1YowfE8ZZ1r/pW81oCHQlnveyXdnxP/1qJPu3+l1N3453QApujKgTL3RotyPYF9uAcDjsFaCJZCI/ypIJm/9ozxa78RNjwFvqxERGjgzX+XBT66zL5SFqgP4ggvYonLir6SquxkfouqaozVEeNmobNLMKMDKkD84MfWRQioul5TyhlFNSnvOSPlWvLT5a8xC6NG+8ZL5++Li6ElARuMM3uS73HofoOByiKu2gJ5AsjTxdOtyQ3ashtiPdhCJSyHyyiw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: de50527d-ae74-412a-1b1b-08d86e048bfa X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2020 16:41:47.9074 (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: 2XuXkIO3u9MPmcmwNBBSofJcj+3p3xig7EytKPQ7LLJU7ASrFB56wByPjYTpGB3K/qWSQ4obDB+Y03ZrDJJNsQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5769 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-11_12:2020-10-09, 2020-10-11 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 mlxscore=0 phishscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 spamscore=0 clxscore=1015 mlxlogscore=999 priorityscore=1501 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010110157 Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 16:42:15 -0000 SmVmZiwNCg0KSSB0aGluayB0aGF0IHlvdSBtZWFuIHRoZSBzY29wZSBpcyBkaWZmZXJlbnQuLi4u LiANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCg0KSnVu aXBlciBCdXNpbmVzcyBVc2UgT25seQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogSmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+IA0KU2VudDogU2F0dXJk YXksIE9jdG9iZXIgMTAsIDIwMjAgMzoxNCBQTQ0KVG86IFJvbiBCb25pY2EgPHJib25pY2FAanVu aXBlci5uZXQ+DQpDYzogRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29tPjsgUGV0 ZXIgUHNlbmFrIDxwcHNlbmFrQGNpc2NvLmNvbT47IFlpbmd6aGVuIFF1IDx5aW5nemhlbi5xdUBm dXR1cmV3ZWkuY29tPjsgR3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT47IGxzckBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMc3JdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDAudHh0DQoNCltFeHRlcm5hbCBFbWFp bC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCg0KDQpKaWUsDQoNClRoZSBzY29vcCBpcyBkaWZm ZXJlbnQsIGZvciBTUiBkYXRhIHBsYW5lIGVudHJ5IHVuaXF1ZW5lc3MgaXMgaW4gY29udGV4dCBv ZiBTUiBkb21haW4gKFNJRCA9IHZhbHVlICsgY29udGV4dCksIHdoaWxlIGZvciBJUCBpdCBpcyBn bG9iYWwgdG8gdGhlIHJvdXRpbmcgZG9tYWluLCBGSUIgZW50cnkgaXMgYSBkZXN0aW5hdGlvbiwg bm90aGluZyBtb3JlLg0KDQpSZWdhcmRzLA0KSmVmZg0KDQo+IE9uIE9jdCAxMCwgMjAyMCwgYXQg MDU6NDcsIFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+IHdyb3RlOg0KPg0KPiDvu79I aSBKaW1taWUsDQo+DQo+IElubGluZS4uLi4uDQo+DQo+ICAgICAgICAgICAgICAgICAgICBSb24N Cj4NCj4NCj4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb20+ DQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciA5LCAyMDIwIDExOjA2IFBNDQo+IFRvOiBQZXRlciBQ c2VuYWsgPHBwc2VuYWtAY2lzY28uY29tPjsgUm9uIEJvbmljYSANCj4gPHJib25pY2FAanVuaXBl ci5uZXQ+OyBZaW5nemhlbiBRdSA8eWluZ3poZW4ucXVAZnV0dXJld2VpLmNvbT47IEd5YW4gDQo+ IE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPg0KPiBDYzogbHNyQGlldGYub3JnOyBKZWZm IFRhbnRzdXJhIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4NCj4gU3ViamVjdDogUkU6IFtMc3Jd IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiBkcmFmdC1ib25pY2EtbHNyLWlw LWZsZXhhbGdvLTAwLnR4dA0KPg0KPiBbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNv bnRlbnRdDQo+DQo+DQo+IEhpIFBldGVyLA0KPg0KPiBUaGFua3MgZm9yIHlvdXIgcmVwbHkuIEl0 IGFsaWducyB3aXRoIG15IHVuZGVyc3RhbmRpbmcgb2YgRkFELCB3aGljaCBpcyBqdXN0IGEgc2V0 IG9mIGNvbnN0cmFpbnRzIGZvciBwYXRoIGNvbXB1dGF0aW9uLiBUaHVzIG9uZSBGbGV4LUFsZ28g SUQgY291bGQgYmUgdXNlZCB3aXRoIG11bHRpcGxlIGRpZmZlcmVudCBkYXRhIHBsYW5lcy4gSXMg dGhpcyB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQo+DQo+IFtSQl0gSSBuZXZlciB0aG91Z2h0IGFi b3V0IHRoaXMuIElzIHRoZXJlIGEgdXNlLWNhc2U/IEkgdGhpbmsgdGhhdCBpdCB3aWxsIHdvcmss IGJ1dCBJIHdvdWxkIGhhdmUgdG8gdHJ5IGl0IGJlZm9yZSBzYXlpbmcgZm9yIHN1cmUuDQo+DQo+ IElmIHNvLCBteSBxdWVzdGlvbiBpcyBhYm91dCB0aGUgc2NlbmFyaW8gYmVsb3c6DQo+DQo+IEEg Z3JvdXAgb2Ygbm9kZXMgaW4gYSBuZXR3b3JrIHN1cHBvcnQgRkEtMTI4LCBhIHN1Yi1ncm91cCBv ZiB0aGVtIGJpbmQgRkEtMTI4IHRvIFNSIFNJRHMsIGFub3RoZXIgc3ViLWdyb3VwIG9mIHRoZW0g YmluZCBGQS0xMjggdG8gSVAgYWRkcmVzcy4gV2hlbiBvbmUgbm9kZSBjb21wdXRlIGFuIFNSIHBh dGggdG8gYSBkZXN0aW5hdGlvbiwgY2FuIGl0IGNvbXB1dGUgdGhlIHBhdGggdG8gb25seSBwYXNz IHRoZSBub2RlcyB3aGljaCBiaW5kIEZBLTEyOCB0byBTUiBTSURzLCBhbmQgYXZvaWQgdGhlIG5v ZGVzIHdoaWNoIGJpbmQgRkEtMTI4IHRvIElQIGFkZHJlc3M/DQo+DQo+IFtSQl0gSSBkb24ndCB0 aGluayBzby4gSG93ZXZlciwgeW91IGNvdWxkIGFjaGlldmUgdGhlIHNhbWUgb3V0Y29tZSB1c2lu ZyBsaW5rIGNvbG9ycy4NCj4NCj4gSWYgc28sIGhvdyBjb3VsZCB0aGlzIG5vZGUga25vdyB0aGUg YmluZGluZyBvZiBGQSB0byBkaWZmZXJlbnQgZGF0YSBwbGFuZXMgb24gb3RoZXIgbm9kZXM/DQo+ DQo+IEJlc3QgcmVnYXJkcywNCj4gSmllDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gRnJvbTogTHNyIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBQZXRlciBQc2VuYWsNCj4+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciA5LCAyMDIwIDExOjU4IFBN DQo+PiBUbzogRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29tPjsgUm9uIEJvbmlj YSANCj4+IDxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+OyBZaW5nemhlbiBR dSANCj4+IDx5aW5nemhlbi5xdUBmdXR1cmV3ZWkuY29tPjsgR3lhbiBNaXNocmEgPGhheWFidXNh Z3NtQGdtYWlsLmNvbT4NCj4+IENjOiBsc3JAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmEgPGplZmZ0 YW50LmlldGZAZ21haWwuY29tPg0KPj4gU3ViamVjdDogUmU6IFtMc3JdIEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIA0KPj4gZHJhZnQtYm9uaWNhLWxzci1pcC1mbGV4YWxnby0wMC50 eHQNCj4+DQo+PiBIaSBKaW1teSwNCj4+DQo+Pg0KPj4+ICBPbiAwOS8xMC8yMDIwIDA0OjU5LCBE b25namllIChKaW1teSkgd3JvdGU6DQo+Pj4gSGkgUm9uLA0KPj4+DQo+Pj4gVGhhbmtzIGZvciBl eHBsYWluaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gSVAgRmxleC1BbGdvIGFuZCBTUiANCj4+ PiBGbGV4LWFsZ28uIEFzDQo+PiB5b3Ugc2FpZCwgdGhlIG1ham9yIGRpZmZlcmVuY2UgaXMgdGhl IGRhdGEgcGxhbmUuDQo+Pj4NCj4+PiBJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIGZv ciBvbmUgRmxleC1BbGdvIHRvIGJlIHVzZWQgDQo+Pj4gY29ycmVjdGx5LCB0aGUgc2V0DQo+PiBv ZiBub2RlcyBuZWVkIHRvIGFwcGx5IGNvbnNpc3RlbnQgY29uc3RyYWludHMgaW4gY29tcHV0YXRp b24sIGFuZCANCj4+IGJpbmQgdGhlIEZBRCB0byB0aGUgc2FtZSBkYXRhIHBsYW5lLg0KPj4+DQo+ Pj4gSXMgaXQgcG9zc2libGUgdGhhdCBkaWZmZXJlbnQgbm9kZXMgbWF5IHVzZSB0aGUgc2FtZSBG bGV4LUFsZ28gd2l0aCANCj4+PiBkaWZmZXJlbnQNCj4+IGRhdGEgcGxhbmUsIGUuZy4gc29tZSB3 aXRoIFNSLU1QTFMsIHNvbWUgd2l0aCBTUnY2LCBhbmQgc29tZSB3aXRoIA0KPj4gcHVyZSBJUCBl dGMuLCBvciBlYWNoIEZsZXgtQWxnbyBpcyBhbHdheXMgYXNzb2NpYXRlZCB3aXRoIG9ubHkgb25l IA0KPj4gZGF0YSBwbGFuZT8gSW4gdGhlIGZvcm1lciBjYXNlLCBzaG91bGQgdGhlIGZsZXgtYWxn byBkZWZpbml0aW9uIGFsc28gDQo+PiBpbmRpY2F0ZSB0aGUgZGF0YSBwbGFuZShzKSB0byBiZSB1 c2VkIHdpdGggdGhlIGZsZXgtYWxnbz8NCj4+DQo+PiBsZXQgbWUgcmVzcG9uZCB0byB0aGlzIHF1 ZXJ5LCBhcyB0aGlzIGlzIG5vdCBzcGVjaWZpYyB0byBSb24ncyBkcmFmdC4NCj4+DQo+PiBGQUQg aXMgZGF0YSBwbGFuZSBhZ25vc3RpYyBhbmQgaXMgdXNlZCBieSBhbGwgb2YgdGhlbS4NCj4+DQo+ PiB0aGFua3MsDQo+PiBQZXRlcg0KPj4NCj4+Pg0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBKaWUN Cj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBMc3IgW21h aWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBCb25pY2ENCj4+Pj4g U2VudDogU3VuZGF5LCBPY3RvYmVyIDQsIDIwMjAgNDozNCBBTQ0KPj4+PiBUbzogWWluZ3poZW4g UXUgPHlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5jb20+OyBQZXRlciBQc2VuYWsgDQo+Pj4+IDxwcHNl bmFrQGNpc2NvLmNvbT47IEd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5jb20+DQo+Pj4+ IENjOiBsc3JAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29t Pg0KPj4+PiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgDQo+Pj4+IGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDAudHh0DQo+Pj4+DQo+Pj4+ IEhpIFlpbmd6aGVuLA0KPj4+Pg0KPj4+PiBJUCBGbGV4aWJsZSBBbGdvcml0aG1zIGFyZSBsaWtl IFNSIEZsZXhpYmxlIEFsZ29yaXRobXMgaW4gdGhlIA0KPj4+PiBmb2xsb3dpbmcNCj4+IHJlc3Bl Y3RzOg0KPj4+Pg0KPj4+PiAtIExpbmtzIGhhdmUgSUdQIG1ldHJpY3MsIFRFIG1ldHJpY3MsIGRl bGF5IG1ldHJpY3MgYW5kIA0KPj4+PiBhZG1pbmlzdHJhdGl2ZSBjb2xvcnMNCj4+Pj4gLSBGQURz IGRlZmluZSBGbGV4aWJsZSBBbGdvcml0aG1zDQo+Pj4+DQo+Pj4+IE1vcmUgc3BlY2lmaWNhbGx5 LCB0aGUgRkFEOg0KPj4+Pg0KPj4+PiAtIEluZGljYXRlcyB3aGljaCBtZXRyaWMgdHlwZSB0aGUg RmxleGlibGUgQWxnb3JpdGhtIHVzZXMNCj4+Pj4gLSBTcGVjaWZpZXMgY29uc3RyYWludHMgaW4g dGVybXMgb2YgbGluayBjb2xvcnMgdGhhdCBhcmUgaW5jbHVkZWQgDQo+Pj4+IG9yIGV4Y2x1ZGVk IGZyb20gdGhlIEZsZXhpYmxlIEFsZ29yaXRobS4NCj4+Pj4NCj4+Pj4gVGhlIHNpZ25pZmljYW50 IGRpZmZlcmVuY2UgYmV0d2VlbiBJUCBGbGV4aWJsZSBBbGdvcml0aG1zIGFuZCBTUiANCj4+Pj4g RmxleGlibGUgQWxnb3JpdGhtcyBpczoNCj4+Pj4NCj4+Pj4gLSBTUiBGbGV4aWJsZSBBbGdvcml0 aG1zIGJpbmQgRkFEcyB0byBwcmVmaXggU0lEcyBvciBTUnY2IGxvY2F0b3JzDQo+Pj4+IC0gSVAg RmxleGlibGUgQWxnb3JpdGhtcyBiaW5kIEZBRHMgdG8gSVB2NCBvciBJUHY2IGFkZHJlc3Nlcy4N Cj4+Pj4NCj4+Pj4gU28sIElQIEZsZXhpYmxlIEFsZ29yaXRobXMgY2FuIGJlIGRlcGxveWVkIGlu IGFueSBJUCBuZXR3b3JrLCBldmVuIA0KPj4+PiBpbiB0aGUgYWJzZW5jZSBvZiBTUi4NCj4+Pj4N Cj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KPj4+Pg0K Pj4+Pg0KPj4+PiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+Pj4+DQo+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFlpbmd6aGVuIFF1IDx5aW5nemhlbi5xdUBm dXR1cmV3ZWkuY29tPg0KPj4+PiBTZW50OiBTYXR1cmRheSwgT2N0b2JlciAzLCAyMDIwIDI6MDgg UE0NCj4+Pj4gVG86IFBldGVyIFBzZW5hayA8cHBzZW5ha0BjaXNjby5jb20+OyBHeWFuIE1pc2hy YSANCj4+Pj4gPGhheWFidXNhZ3NtQGdtYWlsLmNvbT47IFJvbiBCb25pY2EgPHJib25pY2FAanVu aXBlci5uZXQ+DQo+Pj4+IENjOiBsc3JAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmEgPGplZmZ0YW50 LmlldGZAZ21haWwuY29tPg0KPj4+PiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgDQo+Pj4+IGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDAu dHh0DQo+Pj4+DQo+Pj4+IFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0N Cj4+Pj4NCj4+Pj4NCj4+Pj4gSGkgUGV0ZXIsDQo+Pj4+DQo+Pj4+IFVzaW5nIGZsZXgtYWxnbywg YSBTUnY2IGxvY2F0b3IgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHNpbmdsZSANCj4+Pj4gYWxn bywgd2hpY2ggbWVhbnMgYW4gSVB2NiBvciBJUHY0IGFkZHJlc3MgY2FuIGFsc28gYmUgYXNzb2Np YXRlZCANCj4+Pj4gd2l0aCBhIHNpbmdsZSBhbGdvLiBTbyBteSB1bmRlcnN0YW5kaW5nIGlzIFJv bidzIHByb3Bvc2FsIGlzIG1ha2luZyANCj4+Pj4gdGhlDQo+PiBjb25maWd1cmF0aW9uIG9mIGZs ZXgtYWxnbyBlYXNpZXI/DQo+Pj4+IEluc3RlYWQgb2YgdXNpbmcgdGhlIGV4Y2x1ZGUgb3IgaW5j bHVkZSBsaXN0IHlvdSBjYW4gY29uZmlndXJlIGEgDQo+Pj4+IGxvb3BiYWNrIGFkZHJlc3MgdG8g YSBmbGV4LWFsZ28gZGlyZWN0bHk/DQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4gWWluZ3poZW4N Cj4+Pj4NCj4+Pj4gT24gMTAvMy8yMCwgMjo0NyBBTSwgIlBldGVyIFBzZW5hayIgPHBwc2VuYWtA Y2lzY28uY29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4gICAgIEhpIFlpbmd6aGVuLA0KPj4+Pg0KPj4+ PiAgICAgT24gMDIvMTAvMjAyMCAyMjoxNSwgWWluZ3poZW4gUXUgd3JvdGU6DQo+Pj4+PiBIaSBQ ZXRlciwNCj4+Pj4+DQo+Pj4+PiBNeSB1bmRlcnN0YW5kaW5nIG9mIGZsZXgtYWxnbyBpcyB0aGF0 IGZvciB0cmFmZmljIGRlc3RpbmVkDQo+Pj4+IHRvIGEgcHJlZml4IG9uIGEgcGFydGljdWxhciBh bGdvLCBpdCBjYW4gb25seSBiZSByb3V0ZWQgb24gcm91dGVycyANCj4+Pj4gYmVsb25nIHRvIHRo YXQgYWxnbywgd2hpY2ggYWxzbyBtZWFucyBvbmx5IHJvdXRlcnMgaW4gdGhhdCBhbGdvIA0KPj4+ PiBjYWxjdWxhdGVzIGhvdyB0byByZWFjaCB0aGF0IHByZWZpeCBhbmQgaW5zdGFsbCBpdCBpbnRv IHRoZSByb3V0aW5nIA0KPj4+PiB0YWJsZS4gSXQgc2VlbXMgdG8gbWUgdGhhdCB1c2luZyBmbGV4 LWFsZ28gKHNlY3Rpb24gMTIgb2YgdGhlDQo+Pj4+IGRyYWZ0KSBpdCdzIHBvc3NpYmxlIHRvIGhh dmUgYSBsb29wYmFjayBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCANCj4+Pj4gb25seSBvbmUgYWxn bywgcGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdtIG1pc3Npbmcgb3IgbWlzdW5kZXJzdG9vZCBzb21l dGhpbmcuDQo+Pj4+DQo+Pj4+ICAgICB5b3UgYXJlIHJpZ2h0LiBUaGF0IGlzIGV4YWN0bHkgd2hh dCBpcyBiZWluZyBkb25lIGZvciBmbGV4LWFsZ28gd2l0aA0KPj4+PiAgICAgU1J2NiAtIGxvY2F0 b3IgaXMgYXNzb2NpYXRlZCB3aXRoIGEgc2luZ2xlIGFsZ28gb25seS4gVGhlIHByb3Bvc2FsIHVz ZXMNCj4+Pj4gICAgIHRoZSBzYW1lIGNvbmNlcHQuDQo+Pj4+DQo+Pj4+ICAgICB0aGFua3MsDQo+ Pj4+ICAgICBQZXRlcg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoYW5rcywNCj4+Pj4+IFlpbmd6aGVu DQo+Pj4+Pg0KPj4+Pj4gT24gMTAvMi8yMCwgOTo0MyBBTSwgIkxzciBvbiBiZWhhbGYgb2YgUGV0 ZXIgUHNlbmFrIg0KPj4+PiA8bHNyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mDQo+Pj4+ IHBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+DQo+Pj4+IHdyb3RlOg0KPj4+Pj4N Cj4+Pj4+ICAgICBHeWFuLA0KPj4+Pj4NCj4+Pj4+ICAgICBPbiAwMi8xMC8yMDIwIDE4OjMwLCBH eWFuIE1pc2hyYSB3cm90ZToNCj4+Pj4+PiBBbGwsDQo+Pj4+Pj4NCj4+Pj4+PiBXaXRoIFNSdjYg YW5kIElQIGJhc2VkIGZsZXggYWxnbyBhIGdlbmVyaWMgcXVlc3Rpb24gYXMgaXQNCj4+IGFwcGxp ZXMNCj4+Pj4gdG8NCj4+Pj4+PiBib3RoLiBJcyBpdCBwb3NzaWJsZSB0byBoYXZlIHdpdGhpbiBh IHNpbmdsZSBJR1AgZG9tYWluDQo+PiBkaWZmZXJlbnQNCj4+Pj4gc2V0cw0KPj4+Pj4+IG9mIG5v ZGVzIG9yIHNlZ21lbnRzIG9mIHRoZSBuZXR3b3JrIHJ1bm5pbmcgZGlmZmVyZW50DQo+Pj4+IGFs Z29yaXRobXMuDQo+Pj4+Pg0KPj4+Pj4gICAgIGFic29sdXRlbHkuDQo+Pj4+Pg0KPj4+Pj4+IEZy b20NCj4+Pj4+PiBib3RoIGRyYWZ0cyBpdCBzb3VuZHMgbGlrZSBhbGwgbm9kZXMgaGF2ZSB0byBh Z3JlZSBvbiBzYW1lDQo+Pj4+IGFsZ29yaXRobQ0KPj4+Pj4+IHNpbWlsYXIgdG8gY29uY2VwdCBv ZiBtZXRyaWMgYW5kIHJlZmVyZW5jZSBiYW5kd2lkdGggYWxsDQo+PiBoYXZlIHRvDQo+Pj4+IGhh dmUNCj4+Pj4+PiB0aGUgc2FtZSBzdHlsZSBtZXRyaWMgYW5kIHBsYXkgdG8gdGhlIHNhbWUgc2hl ZXQgb2YgbXVzaWMuDQo+Pj4+Pg0KPj4+Pj4gICAgIGFsbCBwYXJ0aWNpcGF0aW5nIG5vZGVzIG5l ZWQgdG8gYWdyZWUgb24gdGhlIGRlZmluaXRpb24gb2YgdGhlDQo+Pj4+IGZsZXgtYWxnbw0KPj4+ Pj4gICAgIGFuZCBhZHZlcnRpc2UgdGhlIHBhcnRpY2lwYXRpb24uIFRoYXQncyBpdC4NCj4+Pj4+ DQo+Pj4+Pj4gSWYgdGhlcmUgd2FzDQo+Pj4+Pj4gYSB3YXkgdG8gdXNlIG11bHRpcGxlIGFsZ29y aXRobXMgc2ltdWx0YW5lb3VzbHkgYmFzZWQgb24NCj4+IFNGQw0KPj4+PiBvciBzZXJ2aWNlcw0K Pj4+Pj4+IGFuZCBpbnN0YW50aWF0aW9uIG9mIHNwZWNpZmljIGFsZ29yaXRobSBiYXNlZCBvbiBz ZXJ2aWNlIHRvDQo+PiBiZQ0KPj4+Pj4+IHJlbmRlcmVkLiAgRG9pbmcgc28gd2l0aG91dCBjYXVz aW5nIGEgcm91dGluZyBsb29wIG9yIHN1Yg0KPj4+PiBvcHRpbWFsDQo+Pj4+Pj4gcm91dGluZy4N Cj4+Pj4+DQo+Pj4+PiAgICAgeW91IGNhbiBjZXJ0YWlubHkgdXNlIG11bHRpcGxlIGFsZ29yaXRo bXMgc2ltdWx0YW5lb3VzbHkgYW5kDQo+PiB1c2UNCj4+Pj4gYWxnbw0KPj4+Pj4gICAgIHNwZWNp ZmljIHBhdGhzIHRvIGZvcndhcmQgc3BlY2lmaWMgdHJhZmZpYyBvdmVyIGl0LiBIb3cgdGhhdCAN Cj4+Pj4+IGlzDQo+PiBkb25lDQo+Pj4+PiAgICAgZnJvbSB0aGUgZm9yd2FyZGluZyBwZXJzcGVj dGl2ZSBkZXBlbmRzIGluIHdoaWNoDQo+PiBmb3J3YXJkaW5nDQo+Pj4+IHBsYW5lIHlvdQ0KPj4+ Pj4gICAgIHVzZS4gRmxleC1hbGdvIGNvbnRyb2wgcGxhbmUgaXMgaW5kZXBlbmRlbnQgb2YgdGhl IGZvcndhcmRpbmcNCj4+Pj4gcGxhbmUuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+PiBJIHRob3VnaHQg d2l0aCBmbGV4IGFsZ28gdGhhdCB0aGVyZSBleGlzdHMgYSBmZWF0dXJlIHRoYXQgb24gZWFjaCAN Cj4+Pj4+PiBob3AgdGhlcmUgaXMgYSB3YXkgdG8gc3BlY2lmeSB3aGljaCBhbGdvIHRvIHVzZSBo b3AgYnkNCj4+IGhvcA0KPj4+PiBzaW1pbGFyDQo+Pj4+Pj4gdG8gYSBob3AgYnkgaG9wIHBvbGlj eSBiYXNlZCByb3V0aW5nLg0KPj4+Pj4NCj4+Pj4+ICAgICBubywgdGhlcmUgaXMgbm8gaG9wLWJ5 LWhvcCBjbGFzc2lmaWNhdGlvbiwgdGhhdCBpcyBwcm9ibGVtYXRpYw0KPj4gYW5kDQo+Pj4+IGRv ZXMNCj4+Pj4+ICAgICBub3Qgc2NhbGUgZm9yIGhpZ2ggc3BlZWRzLiBDbGFzc2lmaWNhdGlvbiBp cyBkb25lIGF0IHRoZQ0KPj4gaW5ncmVzcyBvbmx5Lg0KPj4+Pj4NCj4+Pj4+ICAgICB0aGFua3Ms DQo+Pj4+PiAgICAgUGV0ZXINCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+ICAgICBMc3Ig bWFpbGluZyBsaXN0DQo+Pj4+PiAgICAgTHNyQGlldGYub3JnDQo+Pj4+Pg0KPj4+PiBodHRwczov L3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsDQo+Pj4+IG9vDQo+Pj4+IGsuY29tLw0KPj4+PiA/dXJsPWh0dHBzKjNBKjJGKjJGd3d3Lmll dGYub3JnKjJGbWFpbG1hbioyRmxpc3RpbmZvKjJGbHNyJmFtcDtkYXRhDQo+Pj4+ID0NCj4+IDAN Cj4+Pj4gMg0KPj4+Pg0KPj4gKjdDMDEqN0N5aW5nemhlbi5xdSo0MGZ1dHVyZXdlaS5jb20qN0Nm ZTAzMTI0YzZlNDE0ZTA2N2MyMDA4ZDg2NzgxDQo+Pj4+DQo+PiA2NTQxKjdDMGZlZThmZjJhM2Iy NDAxODljNzUzYTFkNTU5MWZlZGMqN0MxKjdDMCo3QzYzNzM3MzE1MjczOTg2DQo+Pj4+DQo+PiA1 MTI2JmFtcDtzZGF0YT1XSTQ4Y0VBYW4qMkZPa0RQbVZYR3VyRUFqUEl0TkdGOXA5UERRSWxEMWlw MGcqM0QNCj4+Pj4NCj4+ICZhbXA7cmVzZXJ2ZWQ9MF9fO0pTVWxKU1VsSlNVbEpTVWxKU1VsSlEh IU5FdDZ5TWFPLWdrIVgxZlJsbjlNamltZUpjUg0KPj4+PiBFVUVJeWRyLThJSWJ0Tm9uWE1zODNl b1h2Und3NnhrYVFmVlVkTmgwa0s0NTJHUC1HJA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0K Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ PiBMc3IgbWFpbGluZyBsaXN0DQo+Pj4+IExzckBpZXRmLm9yZw0KPj4+PiBodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sDQo+ Pj4+IHNyX187ISFORXQ2eU1hTy1nayFUZUhnSUtNNGxVWmhrWW50X2VGdDNTc2hHSnRsbjhQVHFo Q3VadE9Eb21VUVdDX0gNCj4+Pj4gejIxOENFOFM4WHpsSXhBQSQNCj4+Pg0KPj4+DQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IExzciBt YWlsaW5nIGxpc3QNCj4+IExzckBpZXRmLm9yZw0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo+PiBfIA0KPj4g XzshIU5FdDZ5TWFPLWdrIVRlSGdJS000bFVaaGtZbnRfZUZ0M1NzaEdKdGxuOFBUcWhDdVp0T0Rv bVVRV0NfSHoyMThDDQo+PiBFDQo+PiA4UzhYemxJeEFBJA0K From nobody Sun Oct 11 10:38:45 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29783A0EF2 for ; Sun, 11 Oct 2020 10:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 EupFo3IUx2-Y for ; Sun, 11 Oct 2020 10:38:41 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E313A0EF1 for ; Sun, 11 Oct 2020 10:38:41 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id r10so11749914pgb.10 for ; Sun, 11 Oct 2020 10:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=RM4e5oJXtlmw5SQQTfvZb2iXZBeY8i18OMOpdZ64g7E=; b=dsro/nPkdUgbDkou3hQagVUu6fyxlYieNxUED6vR1FNi70JKhq8saCApvTl3NXe7lV q7r2ybnBnDJUiRLi+YD/jn1BAcMHfXCHEJs7ErUKrgdjt53P66q8EjU0B2MNqUDK9MaY hdKWzLgWfuBx4FLE8xK21MtAJD91p1UH5oq+i0NxDZSSNh3Hyoxo2Pj2oB6xVkIcauK5 YuEjX1Hwuk6uN+ntp12DxIfS3y1RvfI73HlR/ZyenTiT8jyD/cIOKgmUJgKnMVkiPUau SFSh+ba+GyY44HGptxARzUyLtHT/FRY0C9Lyc20aiU1rWwcoBto+DAkSAVLsMuks5uS3 2EyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=RM4e5oJXtlmw5SQQTfvZb2iXZBeY8i18OMOpdZ64g7E=; b=WHda9IfGBN7F+dah+pcq4YHHIlAdl1zI7ZTijsV7xRfJIxszvdKK0ScvrYmrHgdQAf 0E5FQuK8jjpRwBIkPZ+8JX+Ta/9v/v7cvDxpOOQVIdiWUop/mvVUT+VSto8FbiJECtfB nV/XF5VTA/ITjhUQ5pQGe3kchOVTu98mTzO3VetfXZwxkQ0ufFakg1fmIViNZkhWmgTu XuzRJ8Ha7ql90N+WC0GAhG+lMV0ChRRaGJHYetG6nP5BnA+kHJFkMa+7A4VHCbwpfyXP hkXruu/ZUfyjc6ZUbL+pnIff3EVYrSactlQAA+ZCmXx+QN8jmCLI60+7OG0f3gGcZkrW 3Pag== X-Gm-Message-State: AOAM533eG//lX1qdq0g3UijoygN25v1Qvd1zI9lE5qblk3s69fuVRsTJ dOzIuILlhgycFaQ6OwvNny0= X-Google-Smtp-Source: ABdhPJyZ8keKv852P3lHr/+TtdOz+687s8GQD2al/xuboiCAou0AH2KYfhq9ojTJHcLR2z18+pAiyg== X-Received: by 2002:a17:90b:4d0d:: with SMTP id mw13mr13387818pjb.36.1602437920840; Sun, 11 Oct 2020 10:38:40 -0700 (PDT) Received: from [192.168.1.18] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id k3sm17071781pff.71.2020.10.11.10.38.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 11 Oct 2020 10:38:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jeff Tantsura Mime-Version: 1.0 (1.0) Date: Sun, 11 Oct 2020 10:38:37 -0700 Message-Id: References: Cc: "Dongjie (Jimmy)" , Peter Psenak , Yingzhen Qu , Gyan Mishra , lsr@ietf.org In-Reply-To: To: Ron Bonica X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 17:38:44 -0000 Thanks Ron, indeed! Autocorrect works in mysterious ways ;-) Regards, Jeff > On Oct 11, 2020, at 09:41, Ron Bonica wrote: >=20 > =EF=BB=BFJeff, >=20 > I think that you mean the scope is different.....=20 >=20 > Ron >=20 >=20 >=20 > Juniper Business Use Only >=20 > -----Original Message----- > From: Jeff Tantsura =20 > Sent: Saturday, October 10, 2020 3:14 PM > To: Ron Bonica > Cc: Dongjie (Jimmy) ; Peter Psenak ; Yingzhen Qu ; Gyan Mishra ; lsr@ietf.org > Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-fl= exalgo-00.txt >=20 > [External Email. Be cautious of content] >=20 >=20 > Jie, >=20 > The scoop is different, for SR data plane entry uniqueness is in context o= f SR domain (SID =3D value + context), while for IP it is global to the rout= ing domain, FIB entry is a destination, nothing more. >=20 > Regards, > Jeff >=20 >> On Oct 10, 2020, at 05:47, Ron Bonica wrote: >>=20 >> =EF=BB=BFHi Jimmie, >>=20 >> Inline..... >>=20 >> Ron >>=20 >>=20 >> Juniper Business Use Only >>=20 >> -----Original Message----- >> From: Dongjie (Jimmy) >> Sent: Friday, October 9, 2020 11:06 PM >> To: Peter Psenak ; Ron Bonica >> ; Yingzhen Qu ; Gyan=20 >> Mishra >> Cc: lsr@ietf.org; Jeff Tantsura >> Subject: RE: [Lsr] FW: New Version Notification for=20 >> draft-bonica-lsr-ip-flexalgo-00.txt >>=20 >> [External Email. Be cautious of content] >>=20 >>=20 >> Hi Peter, >>=20 >> Thanks for your reply. It aligns with my understanding of FAD, which is j= ust a set of constraints for path computation. Thus one Flex-Algo ID could b= e used with multiple different data planes. Is this understanding correct? >>=20 >> [RB] I never thought about this. Is there a use-case? I think that it wil= l work, but I would have to try it before saying for sure. >>=20 >> If so, my question is about the scenario below: >>=20 >> A group of nodes in a network support FA-128, a sub-group of them bind FA= -128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When o= ne node compute an SR path to a destination, can it compute the path to only= pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind= FA-128 to IP address? >>=20 >> [RB] I don't think so. However, you could achieve the same outcome using l= ink colors. >>=20 >> If so, how could this node know the binding of FA to different data plane= s on other nodes? >>=20 >> Best regards, >> Jie >>=20 >>> -----Original Message----- >>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak >>> Sent: Friday, October 9, 2020 11:58 PM >>> To: Dongjie (Jimmy) ; Ron Bonica=20 >>> ; Yingzhen Qu=20 >>> ; Gyan Mishra >>> Cc: lsr@ietf.org; Jeff Tantsura >>> Subject: Re: [Lsr] FW: New Version Notification for=20 >>> draft-bonica-lsr-ip-flexalgo-00.txt >>>=20 >>> Hi Jimmy, >>>=20 >>>=20 >>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: >>>>> Hi Ron, >>>>>=20 >>>>> Thanks for explaining the difference between IP Flex-Algo and SR=20 >>>>> Flex-algo. As >>> you said, the major difference is the data plane. >>>>=20 >>>> If my understanding is correct, for one Flex-Algo to be used=20 >>>> correctly, the set >>> of nodes need to apply consistent constraints in computation, and=20 >>> bind the FAD to the same data plane. >>>>=20 >>>> Is it possible that different nodes may use the same Flex-Algo with=20 >>>> different >>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with=20 >>> pure IP etc., or each Flex-Algo is always associated with only one=20 >>> data plane? In the former case, should the flex-algo definition also=20 >>> indicate the data plane(s) to be used with the flex-algo? >>>=20 >>> let me respond to this query, as this is not specific to Ron's draft. >>>=20 >>> FAD is data plane agnostic and is used by all of them. >>>=20 >>> thanks, >>> Peter >>>=20 >>>>=20 >>>> Best regards, >>>> Jie >>>>=20 >>>>> -----Original Message----- >>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >>>>> Sent: Sunday, October 4, 2020 4:34 AM >>>>> To: Yingzhen Qu ; Peter Psenak=20 >>>>> ; Gyan Mishra >>>>> Cc: lsr@ietf.org; Jeff Tantsura >>>>> Subject: Re: [Lsr] FW: New Version Notification for=20 >>>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>>=20 >>>>> Hi Yingzhen, >>>>>=20 >>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the=20 >>>>> following >>> respects: >>>>>=20 >>>>> - Links have IGP metrics, TE metrics, delay metrics and=20 >>>>> administrative colors >>>>> - FADs define Flexible Algorithms >>>>>=20 >>>>> More specifically, the FAD: >>>>>=20 >>>>> - Indicates which metric type the Flexible Algorithm uses >>>>> - Specifies constraints in terms of link colors that are included=20 >>>>> or excluded from the Flexible Algorithm. >>>>>=20 >>>>> The significant difference between IP Flexible Algorithms and SR=20 >>>>> Flexible Algorithms is: >>>>>=20 >>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators >>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. >>>>>=20 >>>>> So, IP Flexible Algorithms can be deployed in any IP network, even=20 >>>>> in the absence of SR. >>>>>=20 >>>>> Ron >>>>>=20 >>>>>=20 >>>>> Juniper Business Use Only >>>>>=20 >>>>> -----Original Message----- >>>>> From: Yingzhen Qu >>>>> Sent: Saturday, October 3, 2020 2:08 PM >>>>> To: Peter Psenak ; Gyan Mishra=20 >>>>> ; Ron Bonica >>>>> Cc: lsr@ietf.org; Jeff Tantsura >>>>> Subject: Re: [Lsr] FW: New Version Notification for=20 >>>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>>=20 >>>>> [External Email. Be cautious of content] >>>>>=20 >>>>>=20 >>>>> Hi Peter, >>>>>=20 >>>>> Using flex-algo, a SRv6 locator can be associated with a single=20 >>>>> algo, which means an IPv6 or IPv4 address can also be associated=20 >>>>> with a single algo. So my understanding is Ron's proposal is making=20= >>>>> the >>> configuration of flex-algo easier? >>>>> Instead of using the exclude or include list you can configure a=20 >>>>> loopback address to a flex-algo directly? >>>>>=20 >>>>> Thanks, >>>>> Yingzhen >>>>>=20 >>>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: >>>>>=20 >>>>> Hi Yingzhen, >>>>>=20 >>>>> On 02/10/2020 22:15, Yingzhen Qu wrote: >>>>>> Hi Peter, >>>>>>=20 >>>>>> My understanding of flex-algo is that for traffic destined >>>>> to a prefix on a particular algo, it can only be routed on routers=20 >>>>> belong to that algo, which also means only routers in that algo=20 >>>>> calculates how to reach that prefix and install it into the routing=20= >>>>> table. It seems to me that using flex-algo (section 12 of the >>>>> draft) it's possible to have a loopback address associated with >>>>> only one algo, please correct me if I'm missing or misunderstood somet= hing. >>>>>=20 >>>>> you are right. That is exactly what is being done for flex-algo wit= h >>>>> SRv6 - locator is associated with a single algo only. The proposal u= ses >>>>> the same concept. >>>>>=20 >>>>> thanks, >>>>> Peter >>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Yingzhen >>>>>>=20 >>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >>>>> >>>> ppsenak=3D40cisco.com@dmarc.ietf.org> >>>>> wrote: >>>>>>=20 >>>>>> Gyan, >>>>>>=20 >>>>>> On 02/10/2020 18:30, Gyan Mishra wrote: >>>>>>> All, >>>>>>>=20 >>>>>>> With SRv6 and IP based flex algo a generic question as it >>> applies >>>>> to >>>>>>> both. Is it possible to have within a single IGP domain >>> different >>>>> sets >>>>>>> of nodes or segments of the network running different >>>>> algorithms. >>>>>>=20 >>>>>> absolutely. >>>>>>=20 >>>>>>> From >>>>>>> both drafts it sounds like all nodes have to agree on same >>>>> algorithm >>>>>>> similar to concept of metric and reference bandwidth all >>> have to >>>>> have >>>>>>> the same style metric and play to the same sheet of music. >>>>>>=20 >>>>>> all participating nodes need to agree on the definition of the >>>>> flex-algo >>>>>> and advertise the participation. That's it. >>>>>>=20 >>>>>>> If there was >>>>>>> a way to use multiple algorithms simultaneously based on >>> SFC >>>>> or services >>>>>>> and instantiation of specific algorithm based on service to >>> be >>>>>>> rendered. Doing so without causing a routing loop or sub >>>>> optimal >>>>>>> routing. >>>>>>=20 >>>>>> you can certainly use multiple algorithms simultaneously and >>> use >>>>> algo >>>>>> specific paths to forward specific traffic over it. How that=20 >>>>>> is >>> done >>>>>> from the forwarding perspective depends in which >>> forwarding >>>>> plane you >>>>>> use. Flex-algo control plane is independent of the forwarding >>>>> plane. >>>>>>=20 >>>>>>=20 >>>>>>> I thought with flex algo that there exists a feature that on each=20= >>>>>>> hop there is a way to specify which algo to use hop by >>> hop >>>>> similar >>>>>>> to a hop by hop policy based routing. >>>>>>=20 >>>>>> no, there is no hop-by-hop classification, that is problematic >>> and >>>>> does >>>>>> not scale for high speeds. Classification is done at the >>> ingress only. >>>>>>=20 >>>>>> thanks, >>>>>> Peter >>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>>=20 >>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl >>>>> oo >>>>> k.com/ >>>>> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data >>>>> =3D >>> 0 >>>>> 2 >>>>>=20 >>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 >>>>>=20 >>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >>>>>=20 >>> 5126&sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D >>>>>=20 >>> &reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR >>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Lsr mailing list >>>>> Lsr@ietf.org >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H >>>>> z218CE8S8XzlIxAA$ >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >>> _=20 >>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218C >>> E >>> 8S8XzlIxAA$ From nobody Sun Oct 11 11:21:44 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0B43A0F1E for ; Sun, 11 Oct 2020 11:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 gmU_epZ8XHre for ; Sun, 11 Oct 2020 11:21:40 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 D8B0E3A0F1D for ; Sun, 11 Oct 2020 11:21:39 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id r21so4763385uaw.10 for ; Sun, 11 Oct 2020 11:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NBGIpDuFpCA9D4XU19t1IS18wuGQYHi47EU/1o2ZDdQ=; b=sdvnX28hUy7FXcyKQmgmuC7CSfIUv9NvL0vmP2BkPJ2J1Emj/B3hc0xZpMvMYAg7Mb EK9VPLOVXybZ/b6nI6pMzHuXf7eNpf6/0OTpwdyfwoPc1mooGtSGB8WhtLg+Vxk2Xjtq AQdfHrzqyp58BLl2Qvs+Fvug1poKNVJ9+AThA/rZdMehaxzX4jyB6xCXPko++P88+5cq +WZbH+uY9oE/Xn5LWpggaAtGxn/+lJUjNs/AcPhsA4lEANpi5A73pP7Jpzf6bgiafKjj h9tRb5mlJ8KQracDReujCFZf92v4thlCd75wOrRcaHZbGLqpdggHDNrITbdhrPUZZOeW AZhA== 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=NBGIpDuFpCA9D4XU19t1IS18wuGQYHi47EU/1o2ZDdQ=; b=HQLzBU8cgN9f0GLnEgeTPaYU8x7ctEqh/5W74QLGLdinwnrQ4jscbeJes8F14KGdgs tc5XJo07bIwR2T3fUCPxkf+zTBfc7qsWKTOa7ZL0ugYPiGLy3Oc240Wsn1y8vv3KIJih n1t2poeQ9d2nTgOf9VE7N27ukCyvmBfMY8iIZtUBEBPjQYsSuGJm2sQjGjvKwseHc1Fv 8/Pswrqh5Iw/AHZzEczBtC2ADa6q+Os/+OntfsjIuxWHRBzlvh76hWn5hfCDY76suAdO Mof/c5sVtmHIAZVTOh/S84Wwpi8vfKQhG80ibpS7tPS/3dfSCUDmb4jofW0bNEDkLTCd URBQ== X-Gm-Message-State: AOAM532tGZhf5mdQAREX1XaMFnBxO7XF8xd1Uwj6YQdBXV9MqVGcNY/t M/lw9ls5QpbRqgq+BlTu/XEbDtNiGTGByhp5JmM= X-Google-Smtp-Source: ABdhPJzpxd25E+MqFN4FKfpV7ulhKlrIuEVpr/DUHYeYm1dbDIojmAQD/mSlsxrportRlZZcO2GhKr4OjCaSZLD5e6s= X-Received: by 2002:ab0:c11:: with SMTP id a17mr11599577uak.141.1602440498497; Sun, 11 Oct 2020 11:21:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sun, 11 Oct 2020 14:21:27 -0400 Message-ID: To: Jeff Tantsura Cc: "Dongjie (Jimmy)" , Peter Psenak , Ron Bonica , Yingzhen Qu , lsr@ietf.org Content-Type: multipart/alternative; boundary="000000000000afce4305b1694069" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 18:21:43 -0000 --000000000000afce4305b1694069 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeff So basically as SR Flex Algo uses SR data plane (SID ,context) uniqueness for SR-MPLS label uniqueness and SRv6 Locator uniqueness as compare to IP Flex Algo IP Data plane is destination prefix based. So you could literally have both IP flex algo and SR flex also data plane as mutually exclusive data plane work in parallel as two ships in the night. SRv6 uses Longest prefix match and in SRv6-BE w/o SRH which would be destination based IP and SRv6-BE in parallel to IP Flex algo would not work as they would collide on the IPv6 data plane. Kind Regards Gyan On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura wrote: > Thanks Ron, indeed! Autocorrect works in mysterious ways ;-) > > Regards, > Jeff > > > On Oct 11, 2020, at 09:41, Ron Bonica wrote: > > > > =EF=BB=BFJeff, > > > > I think that you mean the scope is different..... > > > > Ron > > > > > > > > Juniper Business Use Only > > > > -----Original Message----- > > From: Jeff Tantsura > > Sent: Saturday, October 10, 2020 3:14 PM > > To: Ron Bonica > > Cc: Dongjie (Jimmy) ; Peter Psenak < > ppsenak@cisco.com>; Yingzhen Qu ; Gyan Mishra = < > hayabusagsm@gmail.com>; lsr@ietf.org > > Subject: Re: [Lsr] FW: New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt > > > > [External Email. Be cautious of content] > > > > > > Jie, > > > > The scoop is different, for SR data plane entry uniqueness is in contex= t > of SR domain (SID =3D value + context), while for IP it is global to the > routing domain, FIB entry is a destination, nothing more. > > > > Regards, > > Jeff > > > >> On Oct 10, 2020, at 05:47, Ron Bonica wrote: > >> > >> =EF=BB=BFHi Jimmie, > >> > >> Inline..... > >> > >> Ron > >> > >> > >> Juniper Business Use Only > >> > >> -----Original Message----- > >> From: Dongjie (Jimmy) > >> Sent: Friday, October 9, 2020 11:06 PM > >> To: Peter Psenak ; Ron Bonica > >> ; Yingzhen Qu ; Gyan > >> Mishra > >> Cc: lsr@ietf.org; Jeff Tantsura > >> Subject: RE: [Lsr] FW: New Version Notification for > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> [External Email. Be cautious of content] > >> > >> > >> Hi Peter, > >> > >> Thanks for your reply. It aligns with my understanding of FAD, which i= s > just a set of constraints for path computation. Thus one Flex-Algo ID cou= ld > be used with multiple different data planes. Is this understanding correc= t? > >> > >> [RB] I never thought about this. Is there a use-case? I think that it > will work, but I would have to try it before saying for sure. > >> > >> If so, my question is about the scenario below: > >> > >> A group of nodes in a network support FA-128, a sub-group of them bind > FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. > When one node compute an SR path to a destination, can it compute the pat= h > to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes > which bind FA-128 to IP address? > >> > >> [RB] I don't think so. However, you could achieve the same outcome > using link colors. > >> > >> If so, how could this node know the binding of FA to different data > planes on other nodes? > >> > >> Best regards, > >> Jie > >> > >>> -----Original Message----- > >>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > >>> Sent: Friday, October 9, 2020 11:58 PM > >>> To: Dongjie (Jimmy) ; Ron Bonica > >>> ; Yingzhen Qu > >>> ; Gyan Mishra > >>> Cc: lsr@ietf.org; Jeff Tantsura > >>> Subject: Re: [Lsr] FW: New Version Notification for > >>> draft-bonica-lsr-ip-flexalgo-00.txt > >>> > >>> Hi Jimmy, > >>> > >>> > >>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > >>>>> Hi Ron, > >>>>> > >>>>> Thanks for explaining the difference between IP Flex-Algo and SR > >>>>> Flex-algo. As > >>> you said, the major difference is the data plane. > >>>> > >>>> If my understanding is correct, for one Flex-Algo to be used > >>>> correctly, the set > >>> of nodes need to apply consistent constraints in computation, and > >>> bind the FAD to the same data plane. > >>>> > >>>> Is it possible that different nodes may use the same Flex-Algo with > >>>> different > >>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with > >>> pure IP etc., or each Flex-Algo is always associated with only one > >>> data plane? In the former case, should the flex-algo definition also > >>> indicate the data plane(s) to be used with the flex-algo? > >>> > >>> let me respond to this query, as this is not specific to Ron's draft. > >>> > >>> FAD is data plane agnostic and is used by all of them. > >>> > >>> thanks, > >>> Peter > >>> > >>>> > >>>> Best regards, > >>>> Jie > >>>> > >>>>> -----Original Message----- > >>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica > >>>>> Sent: Sunday, October 4, 2020 4:34 AM > >>>>> To: Yingzhen Qu ; Peter Psenak > >>>>> ; Gyan Mishra > >>>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>> > >>>>> Hi Yingzhen, > >>>>> > >>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the > >>>>> following > >>> respects: > >>>>> > >>>>> - Links have IGP metrics, TE metrics, delay metrics and > >>>>> administrative colors > >>>>> - FADs define Flexible Algorithms > >>>>> > >>>>> More specifically, the FAD: > >>>>> > >>>>> - Indicates which metric type the Flexible Algorithm uses > >>>>> - Specifies constraints in terms of link colors that are included > >>>>> or excluded from the Flexible Algorithm. > >>>>> > >>>>> The significant difference between IP Flexible Algorithms and SR > >>>>> Flexible Algorithms is: > >>>>> > >>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators > >>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > >>>>> > >>>>> So, IP Flexible Algorithms can be deployed in any IP network, even > >>>>> in the absence of SR. > >>>>> > >>>>> Ron > >>>>> > >>>>> > >>>>> Juniper Business Use Only > >>>>> > >>>>> -----Original Message----- > >>>>> From: Yingzhen Qu > >>>>> Sent: Saturday, October 3, 2020 2:08 PM > >>>>> To: Peter Psenak ; Gyan Mishra > >>>>> ; Ron Bonica > >>>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>> > >>>>> [External Email. Be cautious of content] > >>>>> > >>>>> > >>>>> Hi Peter, > >>>>> > >>>>> Using flex-algo, a SRv6 locator can be associated with a single > >>>>> algo, which means an IPv6 or IPv4 address can also be associated > >>>>> with a single algo. So my understanding is Ron's proposal is making > >>>>> the > >>> configuration of flex-algo easier? > >>>>> Instead of using the exclude or include list you can configure a > >>>>> loopback address to a flex-algo directly? > >>>>> > >>>>> Thanks, > >>>>> Yingzhen > >>>>> > >>>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: > >>>>> > >>>>> Hi Yingzhen, > >>>>> > >>>>> On 02/10/2020 22:15, Yingzhen Qu wrote: > >>>>>> Hi Peter, > >>>>>> > >>>>>> My understanding of flex-algo is that for traffic destined > >>>>> to a prefix on a particular algo, it can only be routed on routers > >>>>> belong to that algo, which also means only routers in that algo > >>>>> calculates how to reach that prefix and install it into the routing > >>>>> table. It seems to me that using flex-algo (section 12 of the > >>>>> draft) it's possible to have a loopback address associated with > >>>>> only one algo, please correct me if I'm missing or misunderstood > something. > >>>>> > >>>>> you are right. That is exactly what is being done for flex-algo > with > >>>>> SRv6 - locator is associated with a single algo only. The > proposal uses > >>>>> the same concept. > >>>>> > >>>>> thanks, > >>>>> Peter > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Yingzhen > >>>>>> > >>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > >>>>> >>>>> ppsenak=3D40cisco.com@dmarc.ietf.org> > >>>>> wrote: > >>>>>> > >>>>>> Gyan, > >>>>>> > >>>>>> On 02/10/2020 18:30, Gyan Mishra wrote: > >>>>>>> All, > >>>>>>> > >>>>>>> With SRv6 and IP based flex algo a generic question as it > >>> applies > >>>>> to > >>>>>>> both. Is it possible to have within a single IGP domain > >>> different > >>>>> sets > >>>>>>> of nodes or segments of the network running different > >>>>> algorithms. > >>>>>> > >>>>>> absolutely. > >>>>>> > >>>>>>> From > >>>>>>> both drafts it sounds like all nodes have to agree on same > >>>>> algorithm > >>>>>>> similar to concept of metric and reference bandwidth all > >>> have to > >>>>> have > >>>>>>> the same style metric and play to the same sheet of music. > >>>>>> > >>>>>> all participating nodes need to agree on the definition of the > >>>>> flex-algo > >>>>>> and advertise the participation. That's it. > >>>>>> > >>>>>>> If there was > >>>>>>> a way to use multiple algorithms simultaneously based on > >>> SFC > >>>>> or services > >>>>>>> and instantiation of specific algorithm based on service to > >>> be > >>>>>>> rendered. Doing so without causing a routing loop or sub > >>>>> optimal > >>>>>>> routing. > >>>>>> > >>>>>> you can certainly use multiple algorithms simultaneously and > >>> use > >>>>> algo > >>>>>> specific paths to forward specific traffic over it. How that > >>>>>> is > >>> done > >>>>>> from the forwarding perspective depends in which > >>> forwarding > >>>>> plane you > >>>>>> use. Flex-algo control plane is independent of the forwarding > >>>>> plane. > >>>>>> > >>>>>> > >>>>>>> I thought with flex algo that there exists a feature that on each > >>>>>>> hop there is a way to specify which algo to use hop by > >>> hop > >>>>> similar > >>>>>>> to a hop by hop policy based routing. > >>>>>> > >>>>>> no, there is no hop-by-hop classification, that is problematic > >>> and > >>>>> does > >>>>>> not scale for high speeds. Classification is done at the > >>> ingress only. > >>>>>> > >>>>>> thanks, > >>>>>> Peter > >>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Lsr mailing list > >>>>>> Lsr@ietf.org > >>>>>> > >>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl > >>>>> oo > >>>>> k.com/ > >>>>> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&da= ta > >>>>> =3D > >>> 0 > >>>>> 2 > >>>>> > >>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 > >>>>> > >>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >>>>> > >>> 5126&sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >>>>> > >>> &reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJ= cR > >>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Lsr mailing list > >>>>> Lsr@ietf.org > >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l > >>>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H > >>>>> z218CE8S8XzlIxAA$ > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Lsr mailing list > >>> Lsr@ietf.org > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > >>> _ > >>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218C > >>> E > >>> 8S8XzlIxAA$ > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000afce4305b1694069 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Jeff

So basically as SR Flex Algo uses SR data plane (SID ,context= ) uniqueness for SR-MPLS label uniqueness and SRv6 Locator uniqueness as co= mpare to IP Flex Algo IP Data plane is destination prefix based. =C2=A0

So you could literally have= both IP flex algo and SR flex also data plane as mutually exclusive data p= lane work in parallel as two ships in the night. =C2=A0

SRv6 uses Longest prefix match and in SRv6-= BE w/o SRH which would be destination based IP and SRv6-BE in parallel to I= P Flex algo would not work as they would collide on the IPv6 data plane.

Kind Regards=C2=A0

Gyan

On Sun, Oct 11, 2020= at 1:38 PM Jeff Tantsura <je= fftant.ietf@gmail.com> wrote:
rbonica@juniper.net> wrote:
>
> =EF=BB=BFJeff,
>
> I think that you mean the scope is different.....
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Jeff Tantsura <jefftant.ietf@gmail.com>
> Sent: Saturday, October 10, 2020 3:14 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Peter Psenak <ppsenak@cisco.com>; Yingzhen Q= u <yingzh= en.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com>; lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-i= p-flexalgo-00.txt
>
> [External Email. Be cautious of content]
>
>
> Jie,
>
> The scoop is different, for SR data plane entry uniqueness is in conte= xt of SR domain (SID =3D value + context), while for IP it is global to the= routing domain, FIB entry is a destination, nothing more.
>
> Regards,
> Jeff
>
>> On Oct 10, 2020, at 05:47, Ron Bonica <rbonica@juniper.net> wrote:
>>
>> =EF=BB=BFHi Jimmie,
>>
>> Inline.....
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Ron
>>
>>
>> Juniper Business Use Only
>>
>> -----Original Message-----
>> From: Dongjie (Jimmy) <jie.dong@huawei.com>
>> Sent: Friday, October 9, 2020 11:06 PM
>> To: Peter Psenak <ppsenak@cisco.com>; Ron Bonica
>> <rboni= ca@juniper.net>; Yingzhen Qu <yingzhen.qu@futurewei.com>; Gyan
>> Mishra <hayabusagsm@gmail.com>
>> Cc: lsr@ietf.org= ; Jeff Tantsura <jefftant.ietf@gmail.com>
>> Subject: RE: [Lsr] FW: New Version Notification for
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> Hi Peter,
>>
>> Thanks for your reply. It aligns with my understanding of FAD, whi= ch is just a set of constraints for path computation. Thus one Flex-Algo ID= could be used with multiple different data planes. Is this understanding c= orrect?
>>
>> [RB] I never thought about this. Is there a use-case? I think that= it will work, but I would have to try it before saying for sure.
>>
>> If so, my question is about the scenario below:
>>
>> A group of nodes in a network support FA-128, a sub-group of them = bind FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address= . When one node compute an SR path to a destination, can it compute the pat= h to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes = which bind FA-128 to IP address?
>>
>> [RB] I don't think so. However, you could achieve the same out= come using link colors.
>>
>> If so, how could this node know the binding of FA to different dat= a planes on other nodes?
>>
>> Best regards,
>> Jie
>>
>>> -----Original Message-----
>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
>>> Sent: Friday, October 9, 2020 11:58 PM
>>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Ron Bonica
>>> <rbonica=3D40juniper.net@dmarc.ietf.org>; Yingzhen Qu
>>> <yingzhen.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com>
>>> Cc: lsr@ietf= .org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>> Subject: Re: [Lsr] FW: New Version Notification for
>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>
>>> Hi Jimmy,
>>>
>>>
>>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
>>>>> Hi Ron,
>>>>>
>>>>> Thanks for explaining the difference between IP Flex-A= lgo and SR
>>>>> Flex-algo. As
>>> you said, the major difference is the data plane.
>>>>
>>>> If my understanding is correct, for one Flex-Algo to be us= ed
>>>> correctly, the set
>>> of nodes need to apply consistent constraints in computation, = and
>>> bind the FAD to the same data plane.
>>>>
>>>> Is it possible that different nodes may use the same Flex-= Algo with
>>>> different
>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some w= ith
>>> pure IP etc., or each Flex-Algo is always associated with only= one
>>> data plane? In the former case, should the flex-algo definitio= n also
>>> indicate the data plane(s) to be used with the flex-algo?
>>>
>>> let me respond to this query, as this is not specific to Ron&#= 39;s draft.
>>>
>>> FAD is data plane agnostic and is used by all of them.
>>>
>>> thanks,
>>> Peter
>>>
>>>>
>>>> Best regards,
>>>> Jie
>>>>
>>>>> -----Original Message-----
>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica
>>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>>> To: Yingzhen Qu <yingzhen.qu@futurewei.com>; Peter Psena= k
>>>>> <ppsenak@cisco.com>; Gyan Mishra <hayabusagsm@gmail.com>
>>>>> Cc: = lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>
>>>>> Hi Yingzhen,
>>>>>
>>>>> IP Flexible Algorithms are like SR Flexible Algorithms= in the
>>>>> following
>>> respects:
>>>>>
>>>>> - Links have IGP metrics, TE metrics, delay metrics an= d
>>>>> administrative colors
>>>>> - FADs define Flexible Algorithms
>>>>>
>>>>> More specifically, the FAD:
>>>>>
>>>>> - Indicates which metric type the Flexible Algorithm u= ses
>>>>> - Specifies constraints in terms of link colors that a= re included
>>>>> or excluded from the Flexible Algorithm.
>>>>>
>>>>> The significant difference between IP Flexible Algorit= hms and SR
>>>>> Flexible Algorithms is:
>>>>>
>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or S= Rv6 locators
>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 add= resses.
>>>>>
>>>>> So, IP Flexible Algorithms can be deployed in any IP n= etwork, even
>>>>> in the absence of SR.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Ron
>>>>>
>>>>>
>>>>> Juniper Business Use Only
>>>>>
>>>>> -----Original Message-----
>>>>> From: Yingzhen Qu <yingzhen.qu@futurewei.com>
>>>>> Sent: Saturday, October 3, 2020 2:08 PM
>>>>> To: Peter Psenak <ppsenak@cisco.com>; Gyan Mishra
>>>>> <hayabusagsm@gmail.com>; Ron Bonica <rbonica@juniper.net>
>>>>> Cc: = lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>
>>>>> [External Email. Be cautious of content]
>>>>>
>>>>>
>>>>> Hi Peter,
>>>>>
>>>>> Using flex-algo, a SRv6 locator can be associated with= a single
>>>>> algo, which means an IPv6 or IPv4 address can also be = associated
>>>>> with a single algo. So my understanding is Ron's p= roposal is making
>>>>> the
>>> configuration of flex-algo easier?
>>>>> Instead of using the exclude or include list you can c= onfigure a
>>>>> loopback address to a flex-algo directly?
>>>>>
>>>>> Thanks,
>>>>> Yingzhen
>>>>>
>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" <ppsenak@cisco.com>= ; wrote:
>>>>>
>>>>>=C2=A0 =C2=A0 Hi Yingzhen,
>>>>>
>>>>>=C2=A0 =C2=A0 On 02/10/2020 22:15, Yingzhen Qu wrote: >>>>>> Hi Peter,
>>>>>>
>>>>>> My understanding of flex-algo is that for traffic = destined
>>>>> to a prefix on a particular algo, it can only be route= d on routers
>>>>> belong to that algo, which also means only routers in = that algo
>>>>> calculates how to reach that prefix and install it int= o the routing
>>>>> table. It seems to me that using flex-algo (section 12= of the
>>>>> draft) it's possible to have a loopback address as= sociated with
>>>>> only one algo, please correct me if I'm missing or= misunderstood something.
>>>>>
>>>>>=C2=A0 =C2=A0 you are right. That is exactly what is be= ing done for flex-algo with
>>>>>=C2=A0 =C2=A0 SRv6 - locator is associated with a singl= e algo only. The proposal uses
>>>>>=C2=A0 =C2=A0 the same concept.
>>>>>
>>>>>=C2=A0 =C2=A0 thanks,
>>>>>=C2=A0 =C2=A0 Peter
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Yingzhen
>>>>>>
>>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter = Psenak"
>>>>> <lsr-bounces@ietf.org on behalf of
>>>>> ppsenak=3D40cisco.com@dmarc.ietf.org>
>>>>> wrote:
>>>>>>
>>>>>>=C2=A0 =C2=A0 Gyan,
>>>>>>
>>>>>>=C2=A0 =C2=A0 On 02/10/2020 18:30, Gyan Mishra wrot= e:
>>>>>>> All,
>>>>>>>
>>>>>>> With SRv6 and IP based flex algo a generic que= stion as it
>>> applies
>>>>> to
>>>>>>> both. Is it possible to have within a single I= GP domain
>>> different
>>>>> sets
>>>>>>> of nodes or segments of the network running di= fferent
>>>>> algorithms.
>>>>>>
>>>>>>=C2=A0 =C2=A0 absolutely.
>>>>>>
>>>>>>> From
>>>>>>> both drafts it sounds like all nodes have to a= gree on same
>>>>> algorithm
>>>>>>> similar to concept of metric and reference ban= dwidth all
>>> have to
>>>>> have
>>>>>>> the same style metric and play to the same she= et of music.
>>>>>>
>>>>>>=C2=A0 =C2=A0 all participating nodes need to agree= on the definition of the
>>>>> flex-algo
>>>>>>=C2=A0 =C2=A0 and advertise the participation. That= 's it.
>>>>>>
>>>>>>> If there was
>>>>>>> a way to use multiple algorithms simultaneousl= y based on
>>> SFC
>>>>> or services
>>>>>>> and instantiation of specific algorithm based = on service to
>>> be
>>>>>>> rendered.=C2=A0 Doing so without causing a rou= ting loop or sub
>>>>> optimal
>>>>>>> routing.
>>>>>>
>>>>>>=C2=A0 =C2=A0 you can certainly use multiple algori= thms simultaneously and
>>> use
>>>>> algo
>>>>>>=C2=A0 =C2=A0 specific paths to forward specific tr= affic over it. How that
>>>>>> is
>>> done
>>>>>>=C2=A0 =C2=A0 from the forwarding perspective depen= ds in which
>>> forwarding
>>>>> plane you
>>>>>>=C2=A0 =C2=A0 use. Flex-algo control plane is indep= endent of the forwarding
>>>>> plane.
>>>>>>
>>>>>>
>>>>>>> I thought with flex algo that there exists a f= eature that on each
>>>>>>> hop there is a way to specify which algo to us= e hop by
>>> hop
>>>>> similar
>>>>>>> to a hop by hop policy based routing.
>>>>>>
>>>>>>=C2=A0 =C2=A0 no, there is no hop-by-hop classifica= tion, that is problematic
>>> and
>>>>> does
>>>>>>=C2=A0 =C2=A0 not scale for high speeds. Classifica= tion is done at the
>>> ingress only.
>>>>>>
>>>>>>=C2=A0 =C2=A0 thanks,
>>>>>>=C2=A0 =C2=A0 Peter
>>>>>>
>>>>>>>
>>>>>>
>>>>>>=C2=A0 =C2=A0 _____________________________________= __________
>>>>>>=C2=A0 =C2=A0 Lsr mailing list
>>>>>>=C2=A0 =C2=A0 Lsr@ietf.org
>>>>>>
>>>>> https://urld= efense.com/v3/__https://nam11.safelinks.protection.outl
>>>>> oo
>>>>> k.com/
>>>>> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo= *2Flsr&amp;data
>>>>> =3D
>>> 0
>>>>> 2
>>>>>
>>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d= 86781
>>>>>
>>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637373152739= 86
>>>>>
>>> 5126&amp;sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1= ip0g*3D
>>>>>
>>> &amp;reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1= fRln9MjimeJcR
>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lsr mailing list
>>>>> Lsr@= ietf.org
>>>>> https://urld= efense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhC= uZtODomUQWC_H
>>>>> z218CE8S8XzlIxAA$
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org=
>>> https://urldefense= .com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>>> _
>>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC= _Hz218C
>>> E
>>> 8S8XzlIxAA$
--
--000000000000afce4305b1694069-- From nobody Sun Oct 11 11:23:35 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3223A0F1E for ; Sun, 11 Oct 2020 11:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=k3i+Ogeg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FEs+O/2v 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 5Zy4XDiTSoMz for ; Sun, 11 Oct 2020 11:23:31 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7CE3A0F1D for ; Sun, 11 Oct 2020 11:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17550; q=dns/txt; s=iport; t=1602440610; x=1603650210; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3l2N/cTjKs2wVznC03x4DfFGeYkZS9QUzNF+5GWtglA=; b=k3i+OgegDR4c8yT42zYJb2mcK8i6jJ9xPBAt3AI7zzj3ysN5d9TU6M9P 6oMUq3kj8VD2XujbTUTnhoWUnh9R2yFeKZPJcyK4s3GSuT5x8Ra04lvOa WGUBYcOjhJRsYB/5HlC0/WNQm2QGOU7bEapv+6z9MXDG9iPZ22YQqEtnc A=; IronPort-PHdr: =?us-ascii?q?9a23=3AiYePBBzezhKvgNPXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWDt/pohV7NG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK0NEFUHID1YFiB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSBgBuTINf/4YNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BUlEHcFkvLAqEM4NGA40qJooRjmqBQoERA1ULAQEBDQE?= =?us-ascii?q?BGAsKAgQBAYRKAheBfAIlOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgE?= =?us-ascii?q?BARAREQwBASwJAgELBAIBCBEEAQEBAgIjAwICAh8GCxQBCAgCBAENBSKDBAG?= =?us-ascii?q?CSwMOIAEOnU4CgTmIYXaBMoMBAQEFhQMNC4IQAwaBDiqCcoNugkSEEhuCAIE?= =?us-ascii?q?RJwwQgk0+ghpCAQECgSgBEgEhF4MAM4ItkAQrCYJVATyjSFIKgmiJAYxdhQs?= =?us-ascii?q?DH4MVigiUHZMiinGCbJJIAgQCBAUCDgEBBYFrI2dwcBU7KgGCPlAXAg2OHww?= =?us-ascii?q?Xg06FFIVCdAIBNAIGAQkBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,363,1596499200"; d="scan'208";a="579547665" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Oct 2020 18:23:28 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 09BINSjx018204 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 11 Oct 2020 18:23:28 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 11 Oct 2020 13:23:27 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 11 Oct 2020 13:23:27 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 11 Oct 2020 13:23:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UqYNUEvjuhPfrQrA0B2ye/wEJNVA6jOw+DwDbOvMEhEBiF9gMgvPZ9xnqQZ2HN11hvAJ1C4/SMJea+iZk76fnGeNmW14y9ZpNnsPKWHAwLrC5tRgOtR7NvoOqttsZOvC0y9ODXT1KuPZVANldbBAgpovmmeYjHu6KUU83jRQiHXDDhcYIOKHbSczlp1RqSDhf/KezyBxy9CFavG+dpirMT8lZhBPo5D74LC1HU8VKcWgR5f1ldZlAHZiU6aw5AiAgzhde0tdv5FcEwIxa5J9750uT4RUI0pifTeZLiyq1bm1oGRTK8uIWSz4+YeoN8eERIfATSrUQh+WHe0kkh1t9g== 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=3l2N/cTjKs2wVznC03x4DfFGeYkZS9QUzNF+5GWtglA=; b=LiItW06Oq+0U/g2v4aGsAU+s7QJtAZo0V3gmBZDxKcVsNFS1WMYYAk8wDclQusnpc3TV7/JCokQIGAyPW6bHnZgiQGmVaA4CM6tUNvHM7MHFi8wegkuZcYeiDTf6sHKBm/rPiGVR7sp2WWmvpDGg4qgOTURUQebvwR+vumLW8Qu0S5e2IIywzYGpxu0ZTB3gdX4Xjb1d9uddsUKeD6oteq+pSZHDOM5oXWCeTBwYH3pe5004PmjdB2aXfdit6aY9CKnFU8HeFcc1DuHu5pc4O1/ec3UspNjglAU73XFbXRP6Wh3bxpAIG+hJoe2DSMzRcXeucXP6Ezc6Bdpiye8zQQ== 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=3l2N/cTjKs2wVznC03x4DfFGeYkZS9QUzNF+5GWtglA=; b=FEs+O/2v1bhd26IMr/eUtaGRdfQ5c50HlAo3rbMuqddIHmlGJ7zjgyP4mzVoy4XMjpUst0iyNFCrhqzw5qMouacu+wEcwcq90WsnfA23KQiB94MEFSWdDoFJWlS5IHA0ajPHQBTMMVEgjhkyTuqFXgVYfd3XTV8kViTrwFS6Ppo= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by SJ0PR11MB5087.namprd11.prod.outlook.com (2603:10b6:a03:2ad::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.29; Sun, 11 Oct 2020 18:23:24 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3455.027; Sun, 11 Oct 2020 18:23:24 +0000 From: "Acee Lindem (acee)" To: Jeff Tantsura , Ron Bonica CC: "lsr@ietf.org" , "Dongjie (Jimmy)" , Gyan Mishra , Yingzhen Qu , "Peter Psenak (ppsenak)" Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAGYiICAAB9mMIAA726AgADTSnCAAWzZgIAAAz2A///GWICAAVg7AIAAFmsAgACYCCCACE1YgIAA2YqAgAC6nQCAAJ/jwIAAbpcAgAFnkDCAABA4gP//yXMA Date: Sun, 11 Oct 2020 18:23:23 +0000 Message-ID: <68195BFF-47A2-4253-9353-A306239057BD@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89fc490b-c4d5-49c5-baf3-08d86e12bd8f x-ms-traffictypediagnostic: SJ0PR11MB5087: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K/esP1SfGMSwjtSJJ2KPRZyOWW3Nm0eWcC2l2DxRBWnTF8VxFySHr5jUDWfblj8gt1sU3rE9QPdSgFNP1e7bDKmIYeGYtkxQ3C/XjeO6SPRWkwZcZvZoAy3sl4MMrhXzY+P9pl7Alq54E4CUUtBwAl/vGZ+aow46UjXJgNfurSCr6OpXv+9NSrTG7MMZIW+QskrDK3OBQSbdph17prqlAVe3K4DrmgIGG2bWdQW5NLxXG4pvss0eaGcfZeVntevcoJzlX0/mv2jgjAcW8KOsdwdDxC9CPjnv+s3UA+TRKIus4rV57tSUO2MOHODq/8lVKj6HiBOEte0YrFS+/m9sqQv45m+sxFBw2+lp3l3nh+CFSOn2/9p1oxs175rMCsddiXd4gfY2PULrRi1SMdtq4A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(376002)(396003)(346002)(966005)(2906002)(71200400001)(186003)(53546011)(54906003)(6512007)(15650500001)(110136005)(6506007)(30864003)(478600001)(86362001)(45080400002)(8676002)(83080400001)(316002)(36756003)(4326008)(8936002)(33656002)(5660300002)(6486002)(83380400001)(76116006)(66446008)(2616005)(64756008)(66556008)(66946007)(66476007)(26005)(107886003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 5o/4iCc5L0oGzVuwIS6KYLSz3Tl3mbapeetJK8oXGn9nIKRKcuQcEjcx52vwgDxo8XOpKJIVsJ3U3Cs1uB8Lgb0vEQrnbZmewEsDZWEN/wuEcsPPsy8rZzGxYSNITsINHNV2n92xPjiUVzDL4VLWQ+NHtSggh7e4qX3DfBi6EJ+RMXHlA3V0OdV4ehe8ZEXMy7AOiga+GNb/iH7wvvsLXN8iIi7BGpgh5DjZ9YhJpibg0hS/2BXXylKSXI5NqXXv7VgZKsEvdLMTrnmvD0+XP0ZZJN9zU0oXYvXOHVmEEMGmrZ/9WxjBRYvcaI4+7rhmLVQi0FBrypZhO/LmyRvKCc7vTFn4IGhNb/iDZXD5c6ZedYoDln/AeIKjhCxHDUDXj55+xP1xPMj/M9StFO1aixdSFVp5g/k36HgaFfTDStODhGWgC/Z3I0gweWNsHWNxBN9wSrqx1aozZupalK2aOJShsXbgeCoHbWoLidC3Mqp0Mf1O/k06KRJSODbu82QXt1ghlfBp4xcAYwqfRXsG4UIoYoou8v4xsV5AS9asotm5Xbaf/KTrIhe7zDk9E3fWTtZreU465qdYkHfG2qXfWqVPrtrrU8DUc9Sr9DTJB62YSisn9nyQ5363Docw9VK4Gr/QSk6vl86XzD/0JyT7ng== Content-Type: text/plain; charset="utf-8" Content-ID: <6D8DCF32216C7C419EB102489F67AD2E@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89fc490b-c4d5-49c5-baf3-08d86e12bd8f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2020 18:23:23.9566 (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: rTfpSzjL+kNMGRrP6rDL+Pbtd4UIFFF3TIaugH2gu/S++shCY92Sy3HceHJrvzYu X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5087 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 18:23:34 -0000 T3IgcG9zc2libHkgdGhlIHByb3NwZWN0IG9mIEZsZXggQWxnbyBmbGF2b3JzIG1hZGUgeW91IGh1 bmdyeSA7XjAuIA0KDQpBY2VlDQoNCu+7v09uIDEwLzExLzIwLCAxOjM5IFBNLCAiTHNyIG9uIGJl aGFsZiBvZiBKZWZmIFRhbnRzdXJhIiA8bHNyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGplZmZ0YW50LmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIFRoYW5rcyBSb24sIGluZGVl ZCEgIEF1dG9jb3JyZWN0IHdvcmtzIGluIG15c3RlcmlvdXMgd2F5cyAgOy0pDQoNCiAgICBSZWdh cmRzLA0KICAgIEplZmYNCg0KICAgID4gT24gT2N0IDExLCAyMDIwLCBhdCAwOTo0MSwgUm9uIEJv bmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD4gd3JvdGU6DQogICAgPiANCiAgICA+IEplZmYsDQog ICAgPiANCiAgICA+IEkgdGhpbmsgdGhhdCB5b3UgbWVhbiB0aGUgc2NvcGUgaXMgZGlmZmVyZW50 Li4uLi4gDQogICAgPiANCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFJvbg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gSnVuaXBlciBCdXNpbmVzcyBVc2Ug T25seQ0KICAgID4gDQogICAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJv bTogSmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+IA0KICAgID4gU2VudDog U2F0dXJkYXksIE9jdG9iZXIgMTAsIDIwMjAgMzoxNCBQTQ0KICAgID4gVG86IFJvbiBCb25pY2Eg PHJib25pY2FAanVuaXBlci5uZXQ+DQogICAgPiBDYzogRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9u Z0BodWF3ZWkuY29tPjsgUGV0ZXIgUHNlbmFrIDxwcHNlbmFrQGNpc2NvLmNvbT47IFlpbmd6aGVu IFF1IDx5aW5nemhlbi5xdUBmdXR1cmV3ZWkuY29tPjsgR3lhbiBNaXNocmEgPGhheWFidXNhZ3Nt QGdtYWlsLmNvbT47IGxzckBpZXRmLm9yZw0KICAgID4gU3ViamVjdDogUmU6IFtMc3JdIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxleGFsZ28t MDAudHh0DQogICAgPiANCiAgICA+IFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29u dGVudF0NCiAgICA+IA0KICAgID4gDQogICAgPiBKaWUsDQogICAgPiANCiAgICA+IFRoZSBzY29v cCBpcyBkaWZmZXJlbnQsIGZvciBTUiBkYXRhIHBsYW5lIGVudHJ5IHVuaXF1ZW5lc3MgaXMgaW4g Y29udGV4dCBvZiBTUiBkb21haW4gKFNJRCA9IHZhbHVlICsgY29udGV4dCksIHdoaWxlIGZvciBJ UCBpdCBpcyBnbG9iYWwgdG8gdGhlIHJvdXRpbmcgZG9tYWluLCBGSUIgZW50cnkgaXMgYSBkZXN0 aW5hdGlvbiwgbm90aGluZyBtb3JlLg0KICAgID4gDQogICAgPiBSZWdhcmRzLA0KICAgID4gSmVm Zg0KICAgID4gDQogICAgPj4gT24gT2N0IDEwLCAyMDIwLCBhdCAwNTo0NywgUm9uIEJvbmljYSA8 cmJvbmljYUBqdW5pcGVyLm5ldD4gd3JvdGU6DQogICAgPj4gDQogICAgPj4gSGkgSmltbWllLA0K ICAgID4+IA0KICAgID4+IElubGluZS4uLi4uDQogICAgPj4gDQogICAgPj4gICAgICAgICAgICAg ICAgICAgUm9uDQogICAgPj4gDQogICAgPj4gDQogICAgPj4gSnVuaXBlciBCdXNpbmVzcyBVc2Ug T25seQ0KICAgID4+IA0KICAgID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPj4g RnJvbTogRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29tPg0KICAgID4+IFNlbnQ6 IEZyaWRheSwgT2N0b2JlciA5LCAyMDIwIDExOjA2IFBNDQogICAgPj4gVG86IFBldGVyIFBzZW5h ayA8cHBzZW5ha0BjaXNjby5jb20+OyBSb24gQm9uaWNhDQogICAgPj4gPHJib25pY2FAanVuaXBl ci5uZXQ+OyBZaW5nemhlbiBRdSA8eWluZ3poZW4ucXVAZnV0dXJld2VpLmNvbT47IEd5YW4gDQog ICAgPj4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5jb20+DQogICAgPj4gQ2M6IGxzckBpZXRm Lm9yZzsgSmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+DQogICAgPj4gU3Vi amVjdDogUkU6IFtMc3JdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KICAgID4+ IGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDAudHh0DQogICAgPj4gDQogICAgPj4gW0V4 dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KICAgID4+IA0KICAgID4+IA0K ICAgID4+IEhpIFBldGVyLA0KICAgID4+IA0KICAgID4+IFRoYW5rcyBmb3IgeW91ciByZXBseS4g SXQgYWxpZ25zIHdpdGggbXkgdW5kZXJzdGFuZGluZyBvZiBGQUQsIHdoaWNoIGlzIGp1c3QgYSBz ZXQgb2YgY29uc3RyYWludHMgZm9yIHBhdGggY29tcHV0YXRpb24uIFRodXMgb25lIEZsZXgtQWxn byBJRCBjb3VsZCBiZSB1c2VkIHdpdGggbXVsdGlwbGUgZGlmZmVyZW50IGRhdGEgcGxhbmVzLiBJ cyB0aGlzIHVuZGVyc3RhbmRpbmcgY29ycmVjdD8NCiAgICA+PiANCiAgICA+PiBbUkJdIEkgbmV2 ZXIgdGhvdWdodCBhYm91dCB0aGlzLiBJcyB0aGVyZSBhIHVzZS1jYXNlPyBJIHRoaW5rIHRoYXQg aXQgd2lsbCB3b3JrLCBidXQgSSB3b3VsZCBoYXZlIHRvIHRyeSBpdCBiZWZvcmUgc2F5aW5nIGZv ciBzdXJlLg0KICAgID4+IA0KICAgID4+IElmIHNvLCBteSBxdWVzdGlvbiBpcyBhYm91dCB0aGUg c2NlbmFyaW8gYmVsb3c6DQogICAgPj4gDQogICAgPj4gQSBncm91cCBvZiBub2RlcyBpbiBhIG5l dHdvcmsgc3VwcG9ydCBGQS0xMjgsIGEgc3ViLWdyb3VwIG9mIHRoZW0gYmluZCBGQS0xMjggdG8g U1IgU0lEcywgYW5vdGhlciBzdWItZ3JvdXAgb2YgdGhlbSBiaW5kIEZBLTEyOCB0byBJUCBhZGRy ZXNzLiBXaGVuIG9uZSBub2RlIGNvbXB1dGUgYW4gU1IgcGF0aCB0byBhIGRlc3RpbmF0aW9uLCBj YW4gaXQgY29tcHV0ZSB0aGUgcGF0aCB0byBvbmx5IHBhc3MgdGhlIG5vZGVzIHdoaWNoIGJpbmQg RkEtMTI4IHRvIFNSIFNJRHMsIGFuZCBhdm9pZCB0aGUgbm9kZXMgd2hpY2ggYmluZCBGQS0xMjgg dG8gSVAgYWRkcmVzcz8NCiAgICA+PiANCiAgICA+PiBbUkJdIEkgZG9uJ3QgdGhpbmsgc28uIEhv d2V2ZXIsIHlvdSBjb3VsZCBhY2hpZXZlIHRoZSBzYW1lIG91dGNvbWUgdXNpbmcgbGluayBjb2xv cnMuDQogICAgPj4gDQogICAgPj4gSWYgc28sIGhvdyBjb3VsZCB0aGlzIG5vZGUga25vdyB0aGUg YmluZGluZyBvZiBGQSB0byBkaWZmZXJlbnQgZGF0YSBwbGFuZXMgb24gb3RoZXIgbm9kZXM/DQog ICAgPj4gDQogICAgPj4gQmVzdCByZWdhcmRzLA0KICAgID4+IEppZQ0KICAgID4+IA0KICAgID4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4+PiBGcm9tOiBMc3IgW21haWx0bzps c3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBldGVyIFBzZW5haw0KICAgID4+PiBT ZW50OiBGcmlkYXksIE9jdG9iZXIgOSwgMjAyMCAxMTo1OCBQTQ0KICAgID4+PiBUbzogRG9uZ2pp ZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29tPjsgUm9uIEJvbmljYSANCiAgICA+Pj4gPHJi b25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz47IFlpbmd6aGVuIFF1IA0KICAgID4+ PiA8eWluZ3poZW4ucXVAZnV0dXJld2VpLmNvbT47IEd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBn bWFpbC5jb20+DQogICAgPj4+IENjOiBsc3JAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmEgPGplZmZ0 YW50LmlldGZAZ21haWwuY29tPg0KICAgID4+PiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQogICAgPj4+IGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxl eGFsZ28tMDAudHh0DQogICAgPj4+IA0KICAgID4+PiBIaSBKaW1teSwNCiAgICA+Pj4gDQogICAg Pj4+IA0KICAgID4+Pj4+IE9uIDA5LzEwLzIwMjAgMDQ6NTksIERvbmdqaWUgKEppbW15KSB3cm90 ZToNCiAgICA+Pj4+PiBIaSBSb24sDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gVGhhbmtzIGZvciBl eHBsYWluaW5nIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gSVAgRmxleC1BbGdvIGFuZCBTUiANCiAg ICA+Pj4+PiBGbGV4LWFsZ28uIEFzDQogICAgPj4+IHlvdSBzYWlkLCB0aGUgbWFqb3IgZGlmZmVy ZW5jZSBpcyB0aGUgZGF0YSBwbGFuZS4NCiAgICA+Pj4+IA0KICAgID4+Pj4gSWYgbXkgdW5kZXJz dGFuZGluZyBpcyBjb3JyZWN0LCBmb3Igb25lIEZsZXgtQWxnbyB0byBiZSB1c2VkIA0KICAgID4+ Pj4gY29ycmVjdGx5LCB0aGUgc2V0DQogICAgPj4+IG9mIG5vZGVzIG5lZWQgdG8gYXBwbHkgY29u c2lzdGVudCBjb25zdHJhaW50cyBpbiBjb21wdXRhdGlvbiwgYW5kIA0KICAgID4+PiBiaW5kIHRo ZSBGQUQgdG8gdGhlIHNhbWUgZGF0YSBwbGFuZS4NCiAgICA+Pj4+IA0KICAgID4+Pj4gSXMgaXQg cG9zc2libGUgdGhhdCBkaWZmZXJlbnQgbm9kZXMgbWF5IHVzZSB0aGUgc2FtZSBGbGV4LUFsZ28g d2l0aCANCiAgICA+Pj4+IGRpZmZlcmVudA0KICAgID4+PiBkYXRhIHBsYW5lLCBlLmcuIHNvbWUg d2l0aCBTUi1NUExTLCBzb21lIHdpdGggU1J2NiwgYW5kIHNvbWUgd2l0aCANCiAgICA+Pj4gcHVy ZSBJUCBldGMuLCBvciBlYWNoIEZsZXgtQWxnbyBpcyBhbHdheXMgYXNzb2NpYXRlZCB3aXRoIG9u bHkgb25lIA0KICAgID4+PiBkYXRhIHBsYW5lPyBJbiB0aGUgZm9ybWVyIGNhc2UsIHNob3VsZCB0 aGUgZmxleC1hbGdvIGRlZmluaXRpb24gYWxzbyANCiAgICA+Pj4gaW5kaWNhdGUgdGhlIGRhdGEg cGxhbmUocykgdG8gYmUgdXNlZCB3aXRoIHRoZSBmbGV4LWFsZ28/DQogICAgPj4+IA0KICAgID4+ PiBsZXQgbWUgcmVzcG9uZCB0byB0aGlzIHF1ZXJ5LCBhcyB0aGlzIGlzIG5vdCBzcGVjaWZpYyB0 byBSb24ncyBkcmFmdC4NCiAgICA+Pj4gDQogICAgPj4+IEZBRCBpcyBkYXRhIHBsYW5lIGFnbm9z dGljIGFuZCBpcyB1c2VkIGJ5IGFsbCBvZiB0aGVtLg0KICAgID4+PiANCiAgICA+Pj4gdGhhbmtz LA0KICAgID4+PiBQZXRlcg0KICAgID4+PiANCiAgICA+Pj4+IA0KICAgID4+Pj4gQmVzdCByZWdh cmRzLA0KICAgID4+Pj4gSmllDQogICAgPj4+PiANCiAgICA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KICAgID4+Pj4+IEZyb206IExzciBbbWFpbHRvOmxzci1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgUm9uIEJvbmljYQ0KICAgID4+Pj4+IFNlbnQ6IFN1bmRheSwgT2N0 b2JlciA0LCAyMDIwIDQ6MzQgQU0NCiAgICA+Pj4+PiBUbzogWWluZ3poZW4gUXUgPHlpbmd6aGVu LnF1QGZ1dHVyZXdlaS5jb20+OyBQZXRlciBQc2VuYWsgDQogICAgPj4+Pj4gPHBwc2VuYWtAY2lz Y28uY29tPjsgR3lhbiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNvbT4NCiAgICA+Pj4+PiBD YzogbHNyQGlldGYub3JnOyBKZWZmIFRhbnRzdXJhIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4N CiAgICA+Pj4+PiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgDQogICAgPj4+Pj4gZHJhZnQtYm9uaWNhLWxzci1pcC1mbGV4YWxnby0wMC50eHQNCiAg ICA+Pj4+PiANCiAgICA+Pj4+PiBIaSBZaW5nemhlbiwNCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBJ UCBGbGV4aWJsZSBBbGdvcml0aG1zIGFyZSBsaWtlIFNSIEZsZXhpYmxlIEFsZ29yaXRobXMgaW4g dGhlIA0KICAgID4+Pj4+IGZvbGxvd2luZw0KICAgID4+PiByZXNwZWN0czoNCiAgICA+Pj4+PiAN CiAgICA+Pj4+PiAtIExpbmtzIGhhdmUgSUdQIG1ldHJpY3MsIFRFIG1ldHJpY3MsIGRlbGF5IG1l dHJpY3MgYW5kIA0KICAgID4+Pj4+IGFkbWluaXN0cmF0aXZlIGNvbG9ycw0KICAgID4+Pj4+IC0g RkFEcyBkZWZpbmUgRmxleGlibGUgQWxnb3JpdGhtcw0KICAgID4+Pj4+IA0KICAgID4+Pj4+IE1v cmUgc3BlY2lmaWNhbGx5LCB0aGUgRkFEOg0KICAgID4+Pj4+IA0KICAgID4+Pj4+IC0gSW5kaWNh dGVzIHdoaWNoIG1ldHJpYyB0eXBlIHRoZSBGbGV4aWJsZSBBbGdvcml0aG0gdXNlcw0KICAgID4+ Pj4+IC0gU3BlY2lmaWVzIGNvbnN0cmFpbnRzIGluIHRlcm1zIG9mIGxpbmsgY29sb3JzIHRoYXQg YXJlIGluY2x1ZGVkIA0KICAgID4+Pj4+IG9yIGV4Y2x1ZGVkIGZyb20gdGhlIEZsZXhpYmxlIEFs Z29yaXRobS4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBUaGUgc2lnbmlmaWNhbnQgZGlmZmVyZW5j ZSBiZXR3ZWVuIElQIEZsZXhpYmxlIEFsZ29yaXRobXMgYW5kIFNSIA0KICAgID4+Pj4+IEZsZXhp YmxlIEFsZ29yaXRobXMgaXM6DQogICAgPj4+Pj4gDQogICAgPj4+Pj4gLSBTUiBGbGV4aWJsZSBB bGdvcml0aG1zIGJpbmQgRkFEcyB0byBwcmVmaXggU0lEcyBvciBTUnY2IGxvY2F0b3JzDQogICAg Pj4+Pj4gLSBJUCBGbGV4aWJsZSBBbGdvcml0aG1zIGJpbmQgRkFEcyB0byBJUHY0IG9yIElQdjYg YWRkcmVzc2VzLg0KICAgID4+Pj4+IA0KICAgID4+Pj4+IFNvLCBJUCBGbGV4aWJsZSBBbGdvcml0 aG1zIGNhbiBiZSBkZXBsb3llZCBpbiBhbnkgSVAgbmV0d29yaywgZXZlbiANCiAgICA+Pj4+PiBp biB0aGUgYWJzZW5jZSBvZiBTUi4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiANCiAg ICA+Pj4+PiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQogICAgPj4+Pj4gDQogICAgPj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICA+Pj4+PiBGcm9tOiBZaW5nemhlbiBRdSA8 eWluZ3poZW4ucXVAZnV0dXJld2VpLmNvbT4NCiAgICA+Pj4+PiBTZW50OiBTYXR1cmRheSwgT2N0 b2JlciAzLCAyMDIwIDI6MDggUE0NCiAgICA+Pj4+PiBUbzogUGV0ZXIgUHNlbmFrIDxwcHNlbmFr QGNpc2NvLmNvbT47IEd5YW4gTWlzaHJhIA0KICAgID4+Pj4+IDxoYXlhYnVzYWdzbUBnbWFpbC5j b20+OyBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KICAgID4+Pj4+IENjOiBsc3JA aWV0Zi5vcmc7IEplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPg0KICAgID4+ Pj4+IFN1YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciAN CiAgICA+Pj4+PiBkcmFmdC1ib25pY2EtbHNyLWlwLWZsZXhhbGdvLTAwLnR4dA0KICAgID4+Pj4+ IA0KICAgID4+Pj4+IFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCiAg ICA+Pj4+PiANCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBIaSBQZXRlciwNCiAgICA+Pj4+PiANCiAg ICA+Pj4+PiBVc2luZyBmbGV4LWFsZ28sIGEgU1J2NiBsb2NhdG9yIGNhbiBiZSBhc3NvY2lhdGVk IHdpdGggYSBzaW5nbGUgDQogICAgPj4+Pj4gYWxnbywgd2hpY2ggbWVhbnMgYW4gSVB2NiBvciBJ UHY0IGFkZHJlc3MgY2FuIGFsc28gYmUgYXNzb2NpYXRlZCANCiAgICA+Pj4+PiB3aXRoIGEgc2lu Z2xlIGFsZ28uIFNvIG15IHVuZGVyc3RhbmRpbmcgaXMgUm9uJ3MgcHJvcG9zYWwgaXMgbWFraW5n IA0KICAgID4+Pj4+IHRoZQ0KICAgID4+PiBjb25maWd1cmF0aW9uIG9mIGZsZXgtYWxnbyBlYXNp ZXI/DQogICAgPj4+Pj4gSW5zdGVhZCBvZiB1c2luZyB0aGUgZXhjbHVkZSBvciBpbmNsdWRlIGxp c3QgeW91IGNhbiBjb25maWd1cmUgYSANCiAgICA+Pj4+PiBsb29wYmFjayBhZGRyZXNzIHRvIGEg ZmxleC1hbGdvIGRpcmVjdGx5Pw0KICAgID4+Pj4+IA0KICAgID4+Pj4+IFRoYW5rcywNCiAgICA+ Pj4+PiBZaW5nemhlbg0KICAgID4+Pj4+IA0KICAgID4+Pj4+IE9uIDEwLzMvMjAsIDI6NDcgQU0s ICJQZXRlciBQc2VuYWsiIDxwcHNlbmFrQGNpc2NvLmNvbT4gd3JvdGU6DQogICAgPj4+Pj4gDQog ICAgPj4+Pj4gICAgSGkgWWluZ3poZW4sDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gICAgT24gMDIv MTAvMjAyMCAyMjoxNSwgWWluZ3poZW4gUXUgd3JvdGU6DQogICAgPj4+Pj4+IEhpIFBldGVyLA0K ICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4gTXkgdW5kZXJzdGFuZGluZyBvZiBmbGV4LWFsZ28gaXMg dGhhdCBmb3IgdHJhZmZpYyBkZXN0aW5lZA0KICAgID4+Pj4+IHRvIGEgcHJlZml4IG9uIGEgcGFy dGljdWxhciBhbGdvLCBpdCBjYW4gb25seSBiZSByb3V0ZWQgb24gcm91dGVycyANCiAgICA+Pj4+ PiBiZWxvbmcgdG8gdGhhdCBhbGdvLCB3aGljaCBhbHNvIG1lYW5zIG9ubHkgcm91dGVycyBpbiB0 aGF0IGFsZ28gDQogICAgPj4+Pj4gY2FsY3VsYXRlcyBob3cgdG8gcmVhY2ggdGhhdCBwcmVmaXgg YW5kIGluc3RhbGwgaXQgaW50byB0aGUgcm91dGluZyANCiAgICA+Pj4+PiB0YWJsZS4gSXQgc2Vl bXMgdG8gbWUgdGhhdCB1c2luZyBmbGV4LWFsZ28gKHNlY3Rpb24gMTIgb2YgdGhlDQogICAgPj4+ Pj4gZHJhZnQpIGl0J3MgcG9zc2libGUgdG8gaGF2ZSBhIGxvb3BiYWNrIGFkZHJlc3MgYXNzb2Np YXRlZCB3aXRoDQogICAgPj4+Pj4gb25seSBvbmUgYWxnbywgcGxlYXNlIGNvcnJlY3QgbWUgaWYg SSdtIG1pc3Npbmcgb3IgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcuDQogICAgPj4+Pj4gDQogICAg Pj4+Pj4gICAgeW91IGFyZSByaWdodC4gVGhhdCBpcyBleGFjdGx5IHdoYXQgaXMgYmVpbmcgZG9u ZSBmb3IgZmxleC1hbGdvIHdpdGgNCiAgICA+Pj4+PiAgICBTUnY2IC0gbG9jYXRvciBpcyBhc3Nv Y2lhdGVkIHdpdGggYSBzaW5nbGUgYWxnbyBvbmx5LiBUaGUgcHJvcG9zYWwgdXNlcw0KICAgID4+ Pj4+ICAgIHRoZSBzYW1lIGNvbmNlcHQuDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gICAgdGhhbmtz LA0KICAgID4+Pj4+ICAgIFBldGVyDQogICAgPj4+Pj4gDQogICAgPj4+Pj4+IA0KICAgID4+Pj4+ PiBUaGFua3MsDQogICAgPj4+Pj4+IFlpbmd6aGVuDQogICAgPj4+Pj4+IA0KICAgID4+Pj4+PiBP biAxMC8yLzIwLCA5OjQzIEFNLCAiTHNyIG9uIGJlaGFsZiBvZiBQZXRlciBQc2VuYWsiDQogICAg Pj4+Pj4gPGxzci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0KICAgID4+Pj4+IHBwc2Vu YWs9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+DQogICAgPj4+Pj4gd3JvdGU6DQogICAgPj4+ Pj4+IA0KICAgID4+Pj4+PiAgICBHeWFuLA0KICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4gICAgT24g MDIvMTAvMjAyMCAxODozMCwgR3lhbiBNaXNocmEgd3JvdGU6DQogICAgPj4+Pj4+PiBBbGwsDQog ICAgPj4+Pj4+PiANCiAgICA+Pj4+Pj4+IFdpdGggU1J2NiBhbmQgSVAgYmFzZWQgZmxleCBhbGdv IGEgZ2VuZXJpYyBxdWVzdGlvbiBhcyBpdA0KICAgID4+PiBhcHBsaWVzDQogICAgPj4+Pj4gdG8N CiAgICA+Pj4+Pj4+IGJvdGguIElzIGl0IHBvc3NpYmxlIHRvIGhhdmUgd2l0aGluIGEgc2luZ2xl IElHUCBkb21haW4NCiAgICA+Pj4gZGlmZmVyZW50DQogICAgPj4+Pj4gc2V0cw0KICAgID4+Pj4+ Pj4gb2Ygbm9kZXMgb3Igc2VnbWVudHMgb2YgdGhlIG5ldHdvcmsgcnVubmluZyBkaWZmZXJlbnQN CiAgICA+Pj4+PiBhbGdvcml0aG1zLg0KICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4gICAgYWJzb2x1 dGVseS4NCiAgICA+Pj4+Pj4gDQogICAgPj4+Pj4+PiBGcm9tDQogICAgPj4+Pj4+PiBib3RoIGRy YWZ0cyBpdCBzb3VuZHMgbGlrZSBhbGwgbm9kZXMgaGF2ZSB0byBhZ3JlZSBvbiBzYW1lDQogICAg Pj4+Pj4gYWxnb3JpdGhtDQogICAgPj4+Pj4+PiBzaW1pbGFyIHRvIGNvbmNlcHQgb2YgbWV0cmlj IGFuZCByZWZlcmVuY2UgYmFuZHdpZHRoIGFsbA0KICAgID4+PiBoYXZlIHRvDQogICAgPj4+Pj4g aGF2ZQ0KICAgID4+Pj4+Pj4gdGhlIHNhbWUgc3R5bGUgbWV0cmljIGFuZCBwbGF5IHRvIHRoZSBz YW1lIHNoZWV0IG9mIG11c2ljLg0KICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4gICAgYWxsIHBhcnRp Y2lwYXRpbmcgbm9kZXMgbmVlZCB0byBhZ3JlZSBvbiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUNCiAg ICA+Pj4+PiBmbGV4LWFsZ28NCiAgICA+Pj4+Pj4gICAgYW5kIGFkdmVydGlzZSB0aGUgcGFydGlj aXBhdGlvbi4gVGhhdCdzIGl0Lg0KICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4+IElmIHRoZXJlIHdh cw0KICAgID4+Pj4+Pj4gYSB3YXkgdG8gdXNlIG11bHRpcGxlIGFsZ29yaXRobXMgc2ltdWx0YW5l b3VzbHkgYmFzZWQgb24NCiAgICA+Pj4gU0ZDDQogICAgPj4+Pj4gb3Igc2VydmljZXMNCiAgICA+ Pj4+Pj4+IGFuZCBpbnN0YW50aWF0aW9uIG9mIHNwZWNpZmljIGFsZ29yaXRobSBiYXNlZCBvbiBz ZXJ2aWNlIHRvDQogICAgPj4+IGJlDQogICAgPj4+Pj4+PiByZW5kZXJlZC4gIERvaW5nIHNvIHdp dGhvdXQgY2F1c2luZyBhIHJvdXRpbmcgbG9vcCBvciBzdWINCiAgICA+Pj4+PiBvcHRpbWFsDQog ICAgPj4+Pj4+PiByb3V0aW5nLg0KICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4gICAgeW91IGNhbiBj ZXJ0YWlubHkgdXNlIG11bHRpcGxlIGFsZ29yaXRobXMgc2ltdWx0YW5lb3VzbHkgYW5kDQogICAg Pj4+IHVzZQ0KICAgID4+Pj4+IGFsZ28NCiAgICA+Pj4+Pj4gICAgc3BlY2lmaWMgcGF0aHMgdG8g Zm9yd2FyZCBzcGVjaWZpYyB0cmFmZmljIG92ZXIgaXQuIEhvdyB0aGF0IA0KICAgID4+Pj4+PiBp cw0KICAgID4+PiBkb25lDQogICAgPj4+Pj4+ICAgIGZyb20gdGhlIGZvcndhcmRpbmcgcGVyc3Bl Y3RpdmUgZGVwZW5kcyBpbiB3aGljaA0KICAgID4+PiBmb3J3YXJkaW5nDQogICAgPj4+Pj4gcGxh bmUgeW91DQogICAgPj4+Pj4+ICAgIHVzZS4gRmxleC1hbGdvIGNvbnRyb2wgcGxhbmUgaXMgaW5k ZXBlbmRlbnQgb2YgdGhlIGZvcndhcmRpbmcNCiAgICA+Pj4+PiBwbGFuZS4NCiAgICA+Pj4+Pj4g DQogICAgPj4+Pj4+IA0KICAgID4+Pj4+Pj4gSSB0aG91Z2h0IHdpdGggZmxleCBhbGdvIHRoYXQg dGhlcmUgZXhpc3RzIGEgZmVhdHVyZSB0aGF0IG9uIGVhY2ggDQogICAgPj4+Pj4+PiBob3AgdGhl cmUgaXMgYSB3YXkgdG8gc3BlY2lmeSB3aGljaCBhbGdvIHRvIHVzZSBob3AgYnkNCiAgICA+Pj4g aG9wDQogICAgPj4+Pj4gc2ltaWxhcg0KICAgID4+Pj4+Pj4gdG8gYSBob3AgYnkgaG9wIHBvbGlj eSBiYXNlZCByb3V0aW5nLg0KICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4gICAgbm8sIHRoZXJlIGlz IG5vIGhvcC1ieS1ob3AgY2xhc3NpZmljYXRpb24sIHRoYXQgaXMgcHJvYmxlbWF0aWMNCiAgICA+ Pj4gYW5kDQogICAgPj4+Pj4gZG9lcw0KICAgID4+Pj4+PiAgICBub3Qgc2NhbGUgZm9yIGhpZ2gg c3BlZWRzLiBDbGFzc2lmaWNhdGlvbiBpcyBkb25lIGF0IHRoZQ0KICAgID4+PiBpbmdyZXNzIG9u bHkuDQogICAgPj4+Pj4+IA0KICAgID4+Pj4+PiAgICB0aGFua3MsDQogICAgPj4+Pj4+ICAgIFBl dGVyDQogICAgPj4+Pj4+IA0KICAgID4+Pj4+Pj4gDQogICAgPj4+Pj4+IA0KICAgID4+Pj4+PiAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+ Pj4+PiAgICBMc3IgbWFpbGluZyBsaXN0DQogICAgPj4+Pj4+ICAgIExzckBpZXRmLm9yZw0KICAg ID4+Pj4+PiANCiAgICA+Pj4+PiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9u YW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsDQogICAgPj4+Pj4gb28NCiAgICA+Pj4+PiBr LmNvbS8NCiAgICA+Pj4+PiA/dXJsPWh0dHBzKjNBKjJGKjJGd3d3LmlldGYub3JnKjJGbWFpbG1h bioyRmxpc3RpbmZvKjJGbHNyJmFtcDtkYXRhDQogICAgPj4+Pj4gPQ0KICAgID4+PiAwDQogICAg Pj4+Pj4gMg0KICAgID4+Pj4+IA0KICAgID4+PiAqN0MwMSo3Q3lpbmd6aGVuLnF1KjQwZnV0dXJl d2VpLmNvbSo3Q2ZlMDMxMjRjNmU0MTRlMDY3YzIwMDhkODY3ODENCiAgICA+Pj4+PiANCiAgICA+ Pj4gNjU0MSo3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjKjdDMSo3QzAqN0M2Mzcz NzMxNTI3Mzk4Ng0KICAgID4+Pj4+IA0KICAgID4+PiA1MTI2JmFtcDtzZGF0YT1XSTQ4Y0VBYW4q MkZPa0RQbVZYR3VyRUFqUEl0TkdGOXA5UERRSWxEMWlwMGcqM0QNCiAgICA+Pj4+PiANCiAgICA+ Pj4gJmFtcDtyZXNlcnZlZD0wX187SlNVbEpTVWxKU1VsSlNVbEpTVWxKUSEhTkV0NnlNYU8tZ2sh WDFmUmxuOU1qaW1lSmNSDQogICAgPj4+Pj4gRVVFSXlkci04SUlidE5vblhNczgzZW9YdlJ3dzZ4 a2FRZlZVZE5oMGtLNDUyR1AtRyQNCiAgICA+Pj4+Pj4gDQogICAgPj4+Pj4+IA0KICAgID4+Pj4+ PiANCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgID4+Pj4+IExzciBtYWlsaW5nIGxpc3QNCiAgICA+Pj4+PiBM c3JAaWV0Zi5vcmcNCiAgICA+Pj4+PiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sDQogICAgPj4+Pj4gc3JfXzshIU5FdDZ5 TWFPLWdrIVRlSGdJS000bFVaaGtZbnRfZUZ0M1NzaEdKdGxuOFBUcWhDdVp0T0RvbVVRV0NfSA0K ICAgID4+Pj4+IHoyMThDRThTOFh6bEl4QUEkDQogICAgPj4+PiANCiAgICA+Pj4+IA0KICAgID4+ PiANCiAgICA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICA+Pj4gTHNyIG1haWxpbmcgbGlzdA0KICAgID4+PiBMc3JAaWV0Zi5vcmcNCiAgICA+ Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHNyDQogICAgPj4+IF8gDQogICAgPj4+IF87ISFORXQ2eU1hTy1nayFUZUhn SUtNNGxVWmhrWW50X2VGdDNTc2hHSnRsbjhQVHFoQ3VadE9Eb21VUVdDX0h6MjE4Qw0KICAgID4+ PiBFDQogICAgPj4+IDhTOFh6bEl4QUEkDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIExzciBtYWlsaW5nIGxpc3QNCiAgICBMc3JAaWV0 Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0KDQo= From nobody Sun Oct 11 12:19:39 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E9B3A03EE for ; Sun, 11 Oct 2020 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=0.01, 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 hxhKUh3CD60h for ; Sun, 11 Oct 2020 12:19:26 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 7FA053A02DC for ; Sun, 11 Oct 2020 12:19:26 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id u74so7951946vsc.2 for ; Sun, 11 Oct 2020 12:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TBGXaWMNxNcJAJgnWhAVDNCZ9FZxNsvxtT0E0YflN/U=; b=a7ZP+OEDjNr75ruOXwP0rfY1ucB2bmOK3vBiC76OfKBw0OsXewNtNGyS06E+UCuR3W K9lT49gIJGiWEgM0fePaa8D2+UtRGVLIMOStVIQ6TJdY3sYYTR6eRGkJjyoYrrL+eLN1 k9mw4IJe16ZG937tgyr/+aJHd8xsSME86mcN1/lLx9rSBvvP6IfUjKUCKS7276vCACAn pfw7zk3+HvIlZlyF7HNbZRA2ktHGFI3lqGu/Gugkh6NFnlMWL3RFat2AvYUENtqG6zwY tcM4J4ewsE6S/2Bma6q+47NyaBAuaC6QGh5DK24c4AKcFcvpmBbQ5Wka64NZCvOdySbL Hzxw== 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=TBGXaWMNxNcJAJgnWhAVDNCZ9FZxNsvxtT0E0YflN/U=; b=j/PDwh/R/pXeCf9Y9suof0U7oVblgfOF6EJu6E6DBvKPzA0x8OCFQ8/XzgLVfCbRJN e55g41xR4J0m3RdH5A8bmJ35NT+WKu6Td/dt1gswY00fMTxSTBYVlpKyXsnnHTNYI27J /oNQ15SIPjuU/poOyrRkKLTBJ88x1VmSabv8QqrbeMEfEwc3p+U5sf/HyBeZ8isCXsgn O0kAlqsCDIw9H0Oq8QLjwhxVltvVXFurv63GGGloTlW0s02zSrDzMKP17wSME7hnQUYO lCeHLqm4UweTLFKDglbFB4/zCyyZJvH27vh7Ks51V/MoD3k2Kx9jTNGiKz74CGA6pXTI ruuQ== X-Gm-Message-State: AOAM531kbBbM9tUY9C03yDf39Sd8bvdm4Yn2TD6Ov+odfOD+vw8R6uPO yWHyaYgAKLZcV2qjUz7C4F5ytMJjuvjru+wPt2U= X-Google-Smtp-Source: ABdhPJxcE8fbbEGur3H/iTNAwnKcglx/V78GG/4hS6ZlIazfwdAT7Fc8LISuZCKdOnH+Q7v4ak0Jcl+o0GPZVxVZbgg= X-Received: by 2002:a67:fc59:: with SMTP id p25mr563281vsq.5.1602443965353; Sun, 11 Oct 2020 12:19:25 -0700 (PDT) MIME-Version: 1.0 References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> In-Reply-To: <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> From: Gyan Mishra Date: Sun, 11 Oct 2020 15:19:14 -0400 Message-ID: To: "Acee Lindem (acee)" Cc: Aijun Wang , Aijun Wang , "Peter Psenak (ppsenak)" , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="00000000000053d25805b16a0f3b" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 19:19:38 -0000 --00000000000053d25805b16a0f3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Acee I believe what Aijun is trying to explain is that the primary purpose of PCE for active or passive path computation is for inter-as RSVP-TE PCALC path computation or SR-TE path computation. So PCE is solving a well known PCALC bin packing problem due to pcalc over subscribing RSVP tunnel bandwidth which is inherent an RSVP issue, but a bigger problematic issue is with being able to build an inter-as TE path with a single or multiple PCE controllers that can take the LSDB link attributes in the TEDs dB opaque LSAs in the ospf case and ISIS TE TLVs and rebuild the topology topology from each TE domain to be able to build a congruent end to end RSVP TE or SR-TE traffic steered path instantiation. Without the use of PCE controllers as the LSDB link attribute information is not known as RSVP loose ERO static lsp is built or SR SR-TE prefix sid loose path is built, failover due to crank back is impacted for reroute, due to not having a complete depiction of the other AS Link state topology by the head end or SR source node. So to build that entire end to end inter-as path for that end to end RSVP TE or SR-TE path instantiation it is critical to indentify the inter-as link eBGP tie link that may have static routes or BGP LU for RSVP head end to tail end reachability and SR-TE reachability to build out the end to end path instantiation. So the BGP-LS task to rebuild the lsdb topology of each inter connected AS that the RSVP TE or SR-TE steered path traverses, we need the accurate depiction and that includes the Identification of the critical inter-as tie link eBGP peering link that is passive for the PCE path computation logic for the end to end inter-as path instantiation. As for other interfaces using passive in the context of a operator service provider or enterprise core P and PE routers all links are transit with neighbors except the inter-as tie so having this new IGP TLV will help to that end. In the operator =E2=80=9Ccore=E2=80=9D network if there are othe= r interfaces that don=E2=80=99t need to be advertised as stub, they can easily be exclud= ed from being added into IGP. Kind Regards Gyan On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) wrote: > Hi Aijun, > > > > *From: *Aijun Wang > *Date: *Friday, October 9, 2020 at 9:58 PM > *To: *Acee Lindem , "Peter Psenak (ppsenak)" < > ppsenak@cisco.com>, 'Aijun Wang' > *Cc: *"lsr@ietf.org" > *Subject: *RE: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt > > > > Hi, Acee: > > > > *From:* lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] *On Behalf Of = *Acee > Lindem (acee) > *Sent:* Saturday, October 10, 2020 3:48 AM > *To:* Aijun Wang ; Peter Psenak (ppsenak) < > ppsenak@cisco.com>; 'Aijun Wang' > *Cc:* lsr@ietf.org > *Subject:* Re: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt > > > > Speaking as WG member: > > > > Hi Aijun, > > > > *From: *Aijun Wang > *Date: *Thursday, October 8, 2020 at 11:09 PM > *To: *Acee Lindem , "Peter Psenak (ppsenak)" < > ppsenak@cisco.com>, 'Aijun Wang' > *Cc: *"lsr@ietf.org" > *Subject: *RE: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt > > > > Hi, Acee: > > Sorry for the previous pruned mail. Let's reply you again along your > original question. > > Please see inline.[WAJ] > > > > -----Original > Message----- > > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org > ] On Behalf Of Acee Lindem (acee) > Sent: Wednesday, September 30, 2020 7:47 PM > To: Aijun Wang ; Peter Psenak (ppsenak) < > ppsenak@cisco.com>; 'Aijun Wang' > Cc: lsr@ietf.org > Subject: Re: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt > > > > Hi Aijun, > > Other than your ill-conceived topology discovery heuristic > > [WAJ] The topology discovery heuristic is not suitable for the corner use > case when the unnumbered interface is used, as explained in > https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appe= ndix-B. > If you don=E2=80=99t agree, would you like to illustrate other non-applic= able > scenarios? > > > > Right =E2=80=93 and nobody other than yourself believes the IGPs should b= e > modified to expose the abstracted topology of an area outside that area. > > *[WAJ] The modification doesn=E2=80=99t change the way and complexity of= route > calculation within IGP. It just piggyback some extra information, the bul= k > of the reconstruction work is done by the controller. Such extra > information can also have other usage, as described in > https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#sect= ion-1 > * > > *And, the proposal described in > https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-at= tribute-04 > > is different with the problem you concerned. It has no relation with the > abstracted topology of an area. Maybe you are confused by these two > drafts?* > > > > It is a similar problem. You are still trying to overload the prefix > advertisements with a link attribute (passive interface) so that it can b= e > conveyed outside the domain. We certainly wouldn=E2=80=99t waste a limite= d prefix > flag on this parochial application. > > > > > > You can solve the problem with BGP-LS session(s) between the router with = a > BGP-LS session to the controller and a router in each area w/o a router > with a BGP-LS session to the controller. > > *[WAJ] This is possible, but not efficient. For operation, we must also > consider the configuration/administration overhead. BGP-LS is designed > mainly for the northbound protocol, not east-west protocol.* > > > > what other possible reason would there be for associating the passive > attribute with a prefix? > > [WAJ] To know the boundary of the IGP domain. After knowing the boundary, > the controller can safely apply and check the network security policy, th= e > inbound traffic control policy etc. > > > > It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How does th= e presence of a > prefix associated with a passive interface allow you to make this > deduction? > > *[WAJ] Passive interfaces are deployed mainly at the boundary of IGP > domain. Is there any other exception?* > > While passive interfaces are not standardized, there is nothing that > limits their usage to an IGP boundary. They can and are deployed on any > interface where adjacencies are not to be formed (e.g., a stub subnet > containing hosts). > > > > Thanks, > Acee > > > > Thanks, > > Acee > > > > Thanks, > > Acee > > > > On 9/29/20, 10:39 PM, "Aijun Wang" wrote: > > > > Hi, Acee and Peter: > > Passive interface is mainly used at the edge of the network, where th= e > unnumbered interface will not be used. > > And the information to flag the passive interfaces is for positioning > the area boundary, not conflict with the abstract capabilities of the are= a > inside. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > -----Original Message----- > > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org > ] On Behalf Of Acee Lindem (acee) > > Sent: Tuesday, September 29, 2020 9:16 PM > > To: Peter Psenak ; Aijun Wang < > wangaijun@tsinghua.org.cn>; 'Aijun Wang' > > Cc: lsr@ietf.org > > Subject: Re: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt > > > > Speaking as WG member: > > > > Hi Aijun, Peter, > > I agree with Peter - one of the main motivations for having areas is > to abstract the topology within the area. Now you're trying to supplant > this - one topological detail at a time with ill-conceived IGP features. > > Thanks, > > Acee > > > > On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" on behalf of ppsenak=3D40cisco.com@dmarc.ietf.org > > > wrote: > > > > Hi Aijun, > > > > On 29/09/2020 11:07, Aijun Wang wrote: > > > Hi, Peter: > > > > > > Thanks for your comments. > > > 1. For BGP-LS deployment, there normally only be one router tha= t > within the > > > IGP domain to report the topology information, this router > should know such > > > passive links which exists mainly on other border routers via > the IGP > > > protocol. This is main reason to extension the IGP protocol. > > 2. For the solution, normally, the link within the IGP connect two > > ends, but > > > passive interface is special and not fall in this space. We hav= e > studied the > > > current TLVs that for link, and find no suitable container to > append this > > > information. This is the reason that we select the TLVs that > associated with > > > Prefix. > > > > if the link is unnumbered, your solution does not work. As I said= , > if > > you need a knowledge about the link, you can not advertise it as = a > prefix. > > > > thanks, > > Peter > > > > > > > > > >>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix > LSA", which > > > isolate the prefix information that associated with link into > this > > > container, contains the stub link, local interface information > etc. Put such > > > attribute along with the prefix is then acceptable? > > > > > > > > > Best Regards > > > > > > Aijun Wang > > > China Telecom > > > > > > -----Original Message----- > > > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org > ] On Behalf Of Peter > > > Psenak > > > Sent: Tuesday, September 29, 2020 4:29 PM > > > To: Aijun Wang > > > Cc: lsr@ietf.org > > > Subject: Re: [Lsr] FW: New Version Notification for > > > draft-wang-lsr-passive-interface-attribute-04.txt > > > > > > Hi Aijun, > > > > > > here's my comments: > > > > > > The purpose of this draft is to advertise passive links. > > > > > > 1. I'm not sure the problem needs to be solved by IGPs. I tend > to believe > > > ietf-idr-bgpls-inter-as-topology-ext is sufficient. > > > > > > 2. the solution that you proposed is wrong. You are trying to > derive > > > topological data about the passive links from the prefix > advertisement. > > > This is semantically incorrect and only works under very > specific condition. > > > If you need to advertise a link, advertise it as a "special" > > > link, not as a "special" prefix. > > > > > > thanks, > > > Peter > > > > > > On 29/09/2020 03:17, Aijun Wang wrote: > > >> Hi, Peter: > > >> > > >> Would you like to review and give comments on the updates > version of this > > > draft? > > >> We have also added the protocol extension proposal for OSPFv3. > > >> > > >> The update version of this draft can refer to > > >> > https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface > > >> -attribute > > >> Thanks in advance. > > >> > > >> > > >> Best Regards > > >> > > >> Aijun Wang > > >> China Telecom > > >> > > >>> -----Original Message----- > > >>> From: internet-drafts@ietf.org [ > mailto:internet-drafts@ietf.org ] > > >>> Sent: Monday, September 28, 2020 3:17 PM > > >>> To: Zhibo Hu ; Gyan Mishra > > >>> ; Aijun Wang < > wangaj3@chinatelecom.cn>; > > >>> Gyan S. Mishra > > >>> Subject: New Version Notification for > > >>> draft-wang-lsr-passive-interface-attribute-04.txt > > >>> > > >>> > > >>> A new version of I-D, > > >>> draft-wang-lsr-passive-interface-attribute-04.txt > > >>> has been successfully submitted by Aijun Wang and posted to > the IETF > > >>> repository. > > >>> > > >>> Name: draft-wang-lsr-passive-interface-attribut= e > > >>> Revision: 04 > > >>> Title: Passive Interface Attribute > > >>> Document date: 2020-09-28 > > >>> Group: Individual Submission > > >>> Pages: 7 > > >>> URL: > > >>> > https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04. > > >>> txt > > >>> Status: > > >>> > https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att > > >>> r > > >>> ibute/ > > >>> Htmlized: > > >>> > https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac > > >>> e > > >>> -attribut > > >>> e > > >>> Htmlized: > > >>> > https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut > > >>> e > > >>> -04 > > >>> Diff: > > >>> > https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-interface-at > > >>> t > > >>> ribute-04 > > >>> > > >>> Abstract: > > >>> This document describes the mechanism that can be used t= o > > >>> differentiate the passive interfaces from the normal > interfaces > > >>> within ISIS or OSPF domain. > > >>> > > >>> > > >>> > > >>> > > >>> Please note that it may take a couple of minutes from the tim= e > of > > >>> submission until the htmlized version and diff are available = at > > > tools.ietf.org. > > >>> > > >>> The IETF Secretariat > > >>> > > >> > > >> > > >> > > >> > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000053d25805b16a0f3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Acee

<= div dir=3D"auto">I believe what Aijun is trying to explain is that the prim= ary purpose of PCE for active or passive path computation is for inter-as R= SVP-TE PCALC path computation or SR-TE path computation.=C2=A0 So PCE is so= lving a well known PCALC bin packing problem due to pcalc over subscribing = RSVP tunnel bandwidth which is inherent an RSVP issue, but a bigger problem= atic issue is with being able to build an inter-as TE path with a single or= multiple PCE controllers that can take the LSDB link attributes in the TED= s dB opaque LSAs in the ospf case and ISIS TE TLVs and rebuild the topology= topology from each TE domain to be able to build a congruent end to end RS= VP TE or SR-TE traffic steered path instantiation.


As for other interfaces using passive in the context o= f a operator service provider or enterprise core P and PE routers all links= are transit with neighbors except the inter-as tie so having this new IGP = TLV will help to that end.=C2=A0 In the operator =E2=80=9Ccore=E2=80=9D net= work if there are other =C2=A0interfaces that don=E2=80=99t need to be adve= rtised as stub, they can easily be excluded from being added into IGP. =C2= =A0

Kind Regards=C2=A0

Gyan

On Sat, Oct 10, = 2020 at 6:29 AM Acee Lindem (acee) <acee=3D40cisco.com@dmarc.ietf.org> wrote:

Hi Aijun,

=C2=A0

From: Aijun Wang <wangaijun@tsingh= ua.org.cn>
Date: Friday, October 9, 2020 at 9:58 PM
To: Acee Lindem <acee@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, = 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: "lsr@ietf= .org" <lsr@ie= tf.org>
Subject: RE: [Lsr] FW: New Version Notification for draft-wang-lsr-p= assive-interface-attribute-04.txt

=C2=A0

Hi, Acee:

=C2=A0

=C2=A0

Speaking as WG member:=

=C2=A0

Hi Aijun,

=C2=A0

From: Aijun Wang <wangaijun@tsingh= ua.org.cn>
Date: Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem <acee@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, = 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: "lsr@ietf= .org" <lsr@ie= tf.org>
Subject: RE: [Lsr] FW: New Version Notification for draft-wang-lsr-p= assive-interface-attribute-04.txt

=C2=A0

Hi, Acee:

Sorry for the = previous pruned mail. Let's reply you again along your original questio= n.

Please see inl= ine.[WAJ]

=C2=A0<= u>

-----Original = Message-----=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
From: lsr-bounces= @ietf.org [ma= ilto:lsr-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn>; Peter Psenak (ppsenak) <ppsenak@cisco.com>;= 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-= interface-attribute-04.txt

=C2=A0<= u>

Hi Aijun,

Other than you= r ill-conceived topology discovery heuristic

[WAJ] The topo= logy discovery heuristic is not suitable for the corner use case when the u= nnumbered interface is used, as explained in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#append= ix-B.=C2=A0 If you don=E2=80=99t agree, would you like to illustrate other non-applicable scenarios?

=C2=A0=

Right =E2=80=93 and nobody other than yourself believes the IGPs should = be modified to expose the abstracted topology of an area outside that area.

[WAJ] =C2=A0The modification doesn=E2= =80=99t change the way and complexity of route calculation within IGP. It j= ust piggyback some extra information, the bulk of the reconstruction work is done by the controller.=C2=A0 Such extra information can also have othe= r usage, as described in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#sectio= n-1

And, the proposal described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attr= ibute-04 is different with the problem you concerned.=C2=A0 It has no r= elation with the abstracted topology of an area.=C2=A0 Maybe you are confus= ed by these two drafts?

=C2=A0

It is a similar problem. You= are still trying to overload the prefix advertisements with a link attribu= te (passive interface) so that it can be conveyed outside the domain. We certainly wouldn=E2=80=99t waste a limited prefix flag on this parochia= l application.

=C2=A0

=C2=A0

You can solve the problem with BGP-LS session(s) between the router with= a BGP-LS session to the controller and a router in each area w/o =C2=A0a r= outer with a BGP-LS session to the controller.

[WAJ] This is possible, but not effic= ient. For operation, we must also consider the configuration/administration= overhead.=C2=A0 BGP-LS is designed mainly for the northbound protocol, not east-west protocol.

=C2=A0<= u>

what other pos= sible reason would there be for associating the passive attribute with a pr= efix?

[W= AJ] To know the boundary of the IGP domain. After knowing the boundary, the= controller can safely apply and check the network security policy, the inbound traffic control policy etc.

=C2=A0=

It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How does t= he presence of a prefix associated with a passive interface allow you to ma= ke this deduction?

[WAJ] Passive interfaces are deployed= mainly at the boundary of IGP domain.=C2=A0 Is there any other exception?<= /span>

While passive interfaces a= re not standardized, there is nothing that limits their usage to an IGP bou= ndary. They can and are deployed on any interface where adjacencies are not to be formed (e.g., a stub subnet containing hosts).

=C2=A0

Thanks,
Acee

=C2=A0=

Thanks,

Acee

= =C2=A0=

Thanks,=

Acee=

=C2=A0<= u>

On 9/29/20, 10= :39 PM, "Aijun Wang" <wangaijun@tsinghua.org.cn> wrote:

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0 Hi, Acee and Peter:

=C2=A0=C2=A0= =C2=A0 Passive interface is mainly used at the edge of the network, where t= he unnumbered interface will not be used.

=C2=A0=C2=A0= =C2=A0=C2=A0And the information to flag the passive interfaces is for posit= ioning the area boundary, not conflict with the abstract capabilities of th= e area inside.

=C2=A0<= u>

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0 Best Regards

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0 Aijun Wang

=C2=A0=C2=A0= =C2=A0 China Telecom

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0 -----Original Message-----

=C2=A0=C2=A0= =C2=A0 From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On = Behalf Of Acee Lindem (acee)

=C2=A0=C2=A0= =C2=A0 Sent: Tuesday, September 29, 2020 9:16 PM

=C2=A0=C2=A0= =C2=A0 To: Peter Psenak <ppsenak=3D40cisco.com@dmarc.ietf.org>; Aijun Wang <wangaijun@tsinghu= a.org.cn>; 'Aijun Wang' <wangaj3@chinatelecom.cn><= /p>

=C2=A0=C2=A0= =C2=A0 Cc: lsr@ietf.org

=C2=A0=C2=A0= =C2=A0 Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-p= assive-interface-attribute-04.txt

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0 Speaking as WG member:

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0 Hi Aijun, Peter,

=C2=A0=C2=A0= =C2=A0=C2=A0I agree with Peter - one of the main motivations for having are= as is to abstract the topology within the area. Now you're trying to su= pplant this =C2=A0- one topological detail at a time with ill-conceived IGP features.

=C2=A0=C2=A0= =C2=A0 Thanks,

=C2=A0=C2=A0= =C2=A0 Acee

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0 On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" <<= a href=3D"mailto:lsr-bounces@ietf.org%20on%20behalf%20of%20ppsenak=3D40cisc= o.com@dmarc.ietf.org" target=3D"_blank">lsr-bounces@ietf.org on behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> wrote:=

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi Aijun,

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On 29/09/2020 11:07, Aijun Wang wrote:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Hi, Peter:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Thanks for your comments.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 1. For BGP-LS deployment, there normall= y only be one router that within the

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > IGP domain to report the topology infor= mation, this router should know such

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > passive links which exists mainly on ot= her border routers via the IGP

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > protocol. This is main reason to extens= ion the IGP protocol. > 2. For the solution, normally, the link within t= he IGP connect two

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ends, but

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > passive interface is special and not fa= ll in this space. We have studied the

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > current TLVs that for link, and find no= suitable container to append this

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information. This is the reason that we= select the TLVs that associated with

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Prefix.

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if the link is unnumbered, your solution doe= s not work. As I said, if

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0you need a knowledge about the link, yo= u can not advertise it as a prefix.

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 thanks,

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Peter

=C2=A0<= u>

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>From other POV, the OSPFv3 defi= nes now the "Intra-Area-Prefix LSA", which

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > isolate the prefix information that ass= ociated with link into this

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > container, contains the stub link, loca= l interface information etc. Put such

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > attribute along with the prefix is then= acceptable?

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Best Regards<= /p>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Aijun Wang

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > China Telecom

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> -----Original Message-----<= u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On = Behalf Of Peter

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Psenak

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Sent: Tuesday, September 29, 2020 4:29 = PM

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > To: Aijun Wang <wangaj3@chinatelecom.cn>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Cc: lsr@ietf.org

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Subject: Re: [Lsr] FW: New Version Noti= fication for

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > draft-wang-lsr-passive-interface-attrib= ute-04.txt

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Hi Aijun,

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> here's my comments:<= /u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> The purpose of this draft is to ad= vertise passive links.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> 1. I'm not sure the problem ne= eds to be solved by IGPs. I tend to believe

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > ietf-idr-bgpls-inter-as-topology-ext is= sufficient.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> 2. the solution that you proposed = is wrong. You are trying to derive

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological data about the passive link= s from the prefix advertisement.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > This is semantically incorrect and only= works under very specific condition.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > If you need to advertise a link, advert= ise it as a "special"

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > link, not as a "special" pref= ix.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> thanks,

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Peter

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> On 29/09/2020 03:17, Aijun Wang wr= ote:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Hi, Peter:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Would you like to review and give c= omments on the updates version of this

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > draft?

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> We have also added the protocol ext= ension proposal for OSPFv3.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> The update version of this draft ca= n refer to

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> https://datatracker.i= etf.org/doc/html/draft-wang-lsr-passive-interface<= /span>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> -attribute

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Thanks in advance.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Best Regards

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Aijun Wang

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> China Telecom<= /p>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> -----Original Message-----

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@ietf.o= rg]

=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0>>> Sent: Monday, September 28, 202= 0 3:17 PM

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> To: Zhibo Hu <huzhibo@huawei.com>; Gyan Mishra<= u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> <gyan.s.mishra@verizon.com>; Aijun Wang <wangaj3@chinatelecom.cn>= ;

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Gyan S. Mishra <gyan.s.mishra@verizon.com>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Subject: New Version Notificati= on for

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> draft-wang-lsr-passive-interfac= e-attribute-04.txt

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> A new version of I-D,=

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> draft-wang-lsr-passive-interfac= e-attribute-04.txt

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> has been successfully submitted= by Aijun Wang and posted to the IETF

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> repository.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Name:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-wang-lsr= -passive-interface-attribute

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Revision:=C2=A0=C2=A0 04=

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Title:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Passive Interface Attribute

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Document date:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 2020-09-28

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Group:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individual Sub= mission

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Pages:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> URL:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> txt

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Status:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> r

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> ibute/

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Htmlized:<= /p>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> e

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> -attribut<= /p>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> e

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Htmlized:<= /p>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> e

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> -04

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Diff:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-interface-= at

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> t

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> ribute-04<= /p>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Abstract:<= /p>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T= his document describes the mechanism that can be used to

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 d= ifferentiate the passive interfaces from the normal interfaces

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 w= ithin ISIS or OSPF domain.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Please note that it may take a = couple of minutes from the time of

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> submission until the htmlized v= ersion and diff are available at

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > tools.ietf.org.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> The IETF Secretariat<= /u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> __________________________________= _____________

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Lsr mailing list

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Lsr@ietf.org

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mai= lman/listinfo/lsr

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ____________________________________________= ___

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lsr mailing list

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lsr@ietf.org

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mai= lman/listinfo/lsr

=C2=A0<= u>

=C2=A0=C2=A0= =C2=A0 _______________________________________________=

=C2=A0=C2=A0= =C2=A0 Lsr mailing list

=C2=A0=C2=A0= =C2=A0 Lsr@ietf.org

=C2=A0=C2=A0= =C2=A0 https://www.ietf.org/mai= lman/listinfo/lsr

=C2=A0<= u>

=C2=A0<= u>

______________= _________________________________

Lsr mailing li= st

Lsr@ietf.org

https://www.ietf.org/mailman/listinfo/= lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--
--00000000000053d25805b16a0f3b-- From nobody Sun Oct 11 14:06:09 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8C43A08C3 for ; Sun, 11 Oct 2020 14:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YQFB9qUxq3S7 for ; Sun, 11 Oct 2020 14:06:04 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 64E213A08C1 for ; Sun, 11 Oct 2020 14:06:04 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id k8so11583933pfk.2 for ; Sun, 11 Oct 2020 14:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=+hFJRCDWb6iz8bmN0OPRNbs8OzP75Mzn8mbCRo7+48E=; b=NfcUV04eCBanuRThmg6OiCGtPsp97LlROj4wfYQjyOrwcrPvoN1igOACMBvHp2PKaS mMjShEf6NXtVK2u9Q2EQtoxTXUakaduUinRsnqGTDh27m2UOrNQ4hHJjK7RBdYVTT4Hq w/UHbaeZICWOxs5ET7MPjdhzXGvrRZWIDcnog3qHsxbkx/Yxb/E4BMsJOsL1Ma/uwzYv hlL+BCvJ+K7WEcSRQNJQSJwETZurTeSA/fG2VVf7jGuQyzq7RLV5bhHS3NJap5Vl/6wc btGyeKPEFk8HGlqUCargzzapu/Jjj0J59tBz5VqdYRS+GR9W0WVISaD5YMYuf4SPL/C7 9qUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=+hFJRCDWb6iz8bmN0OPRNbs8OzP75Mzn8mbCRo7+48E=; b=hn7B1FP73rRhid/c1UJJfKZnwU1aF448uFNCLqyM9TBrIhpdHT1hh92V/jWhyN8S41 /piIKR4Fqe01B3YQ3S/HhOiq+5GmkZTpt45qfWIJyUaioBDs8jaABKSAPggM43T8Ds/N lKWoYGgP/a4FsNmLA3OiycnVoAeAOEaHWvbRzHoy7Po4D/ftSg1Ukg/cPBBnmJ+60mGR OsZBY8qJVquOLflmQl6DGyauiCA17D7AE5fZupWd4fhptxRiR2uGGxnWKd8Fxri16Afd cLigGkw21N2HkFBYR0ZOPyg894jUEK1gCS8Wy1iAwmM9orccRrExVSqN3jNxXXoDJoPl ZuZg== X-Gm-Message-State: AOAM533R8+WNrajhLU7ihaWP/bCmVBL/jqPmC2L0R+DzSJPu6I3abXEa B22r4TgsMkTDLa0sny9am3Y= X-Google-Smtp-Source: ABdhPJykW3SkCxxS2NU49AwJLRU0ZUoFsvOv1Zw5GbPxuNo9hQmzzWF8uRhAoI0JeAaLVw97/T+Vxw== X-Received: by 2002:a62:e516:0:b029:156:3b35:9423 with SMTP id n22-20020a62e5160000b02901563b359423mr116704pff.19.1602450363328; Sun, 11 Oct 2020 14:06:03 -0700 (PDT) Received: from [192.168.1.13] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id p3sm20926980pjj.38.2020.10.11.14.06.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Oct 2020 14:06:02 -0700 (PDT) Date: Sun, 11 Oct 2020 14:05:54 -0700 From: Jeff Tantsura To: Gyan Mishra Cc: "Dongjie (Jimmy)" , Peter Psenak , Ron Bonica , Yingzhen Qu , lsr@ietf.org Message-ID: <9c1fa875-fdce-40a4-a41d-a025c102eac7@Spark> In-Reply-To: References: X-Readdle-Message-ID: 9c1fa875-fdce-40a4-a41d-a025c102eac7@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f8373b7_7a6d8d3c_cede" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 21:06:08 -0000 --5f8373b7_7a6d8d3c_cede Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Gyan, In simple terms - destination lookup would yield a SID (stack) for SR or = next-hop/adj for IP. =46or SR, no transport device in between should try = to derive/evaluate context (source based routing - once you are in the tu= nnel), in IP case - every device will evaluate (per hop routing) the dest= ination. As long as the destination lookup result is unambiguous, any com= bination of algo's could be used. In SR easy days we (large radio vendor :)) were considering using a set o= f loopbacks per virtual topology as a poor-man=E2=80=99s slicing in MBH, = where PCE would perform =E2=80=9Cslicing=E2=80=9D and =46EC2tunnel mappin= g over flat routing domain, perceived too complex ended up with some othe= r ways of mapping. =46lex algo provides an easier (because distributed + additional meta-dat= a, algo =3D context) way of light virtualization as compared to MT and/or= fully centralized solutions. Wrt SRv6 vs IPv6 (algo is irrelevant here), I=E2=80=99d assume there=E2=80= =99s no conflict, however would leave to the implementors to comment. Cheers, Jeff P.S. Acee - nothing gets me more excited than algo 201 with chocolate ove= r it ;-) On Oct 11, 2020, 11:21 AM -0700, Gyan Mishra , w= rote: > > Jeff > > So basically as SR =46lex Algo uses SR data plane (SID ,context) unique= ness for SR-MPLS label uniqueness and SRv6 Locator uniqueness as compare = to IP =46lex Algo IP Data plane is destination prefix based. > > So you could literally have both IP flex algo and SR flex also data pla= ne as mutually exclusive data plane work in parallel as two ships in the = night. > > SRv6 uses Longest prefix match and in SRv6-BE w/o SRH which would be de= stination based IP and SRv6-BE in parallel to IP =46lex algo would not wo= rk as they would collide on the IPv6 data plane. > > Kind Regards > > Gyan > > > On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura wrote: > > > Thanks Ron, indeed=21=C2=A0 Autocorrect works in mysterious ways=C2= =A0 ;-) > > > > > > Regards, > > > Jeff > > > > > > > On Oct 11, 2020, at 09:41, Ron Bonica wro= te: > > > > > > > > Jeff, > > > > > > > > I think that you mean the scope is different..... > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ron > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > -----Original Message----- > > > > =46rom: Jeff Tantsura > > > > Sent: Saturday, October 10, 2020 3:14 PM > > > > To: Ron Bonica > > > > Cc: Dongjie (Jimmy) ; Peter Psenak ; Yingzhen Qu ; Gyan Mishra ; lsr=40ietf.org > > > > Subject: Re: =5BLsr=5D =46W: New Version Notification for draft-b= onica-lsr-ip-flexalgo-00.txt > > > > > > > > =5BExternal Email. Be cautious of content=5D > > > > > > > > > > > > Jie, > > > > > > > > The scoop is different, for SR data plane entry uniqueness is in = context of SR domain (SID =3D value + context), while for IP it is global= to the routing domain, =46IB entry is a destination, nothing more. > > > > > > > > Regards, > > > > Jeff > > > > > > > >> On Oct 10, 2020, at 05:47, Ron Bonica wr= ote: > > > >> > > > >> Hi Jimmie, > > > >> > > > >> Inline..... > > > >> > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Ron > > > >> > > > >> > > > >> Juniper Business Use Only > > > >> > > > >> -----Original Message----- > > > >> =46rom: Dongjie (Jimmy) > > > >> Sent: =46riday, October 9, 2020 11:06 PM > > > >> To: Peter Psenak ; Ron Bonica > > > >> ; Yingzhen Qu ; Gyan > > > >> Mishra > > > >> Cc: lsr=40ietf.org; Jeff Tantsura > > > >> Subject: RE: =5BLsr=5D =46W: New Version Notification for > > > >> draft-bonica-lsr-ip-flexalgo-00.txt > > > >> > > > >> =5BExternal Email. Be cautious of content=5D > > > >> > > > >> > > > >> Hi Peter, > > > >> > > > >> Thanks for your reply. It aligns with my understanding of =46AD,= which is just a set of constraints for path computation. Thus one =46lex= -Algo ID could be used with multiple different data planes. Is this under= standing correct=3F > > > >> > > > >> =5BRB=5D I never thought about this. Is there a use-case=3F I th= ink that it will work, but I would have to try it before saying for sure.= > > > >> > > > >> If so, my question is about the scenario below: > > > >> > > > >> A group of nodes in a network support =46A-128, a sub-group of t= hem bind =46A-128 to SR SIDs, another sub-group of them bind =46A-128 to = IP address. When one node compute an SR path to a destination, can it com= pute the path to only pass the nodes which bind =46A-128 to SR SIDs, and = avoid the nodes which bind =46A-128 to IP address=3F > > > >> > > > >> =5BRB=5D I don't think so. However, you could achieve the same o= utcome using link colors. > > > >> > > > >> If so, how could this node know the binding of =46A to different= data planes on other nodes=3F > > > >> > > > >> Best regards, > > > >> Jie > > > >> > > > >>> -----Original Message----- > > > >>> =46rom: Lsr =5Bmailto:lsr-bounces=40ietf.org=5D On Behalf Of Pe= ter Psenak > > > >>> Sent: =46riday, October 9, 2020 11:58 PM > > > >>> To: Dongjie (Jimmy) ; Ron Bonica > > > >>> ; Yingzhen Qu > > > >>> ; Gyan Mishra > > > >>> Cc: lsr=40ietf.org; Jeff Tantsura > > > >>> Subject: Re: =5BLsr=5D =46W: New Version Notification for > > > >>> draft-bonica-lsr-ip-flexalgo-00.txt > > > >>> > > > >>> Hi Jimmy, > > > >>> > > > >>> > > > >>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > > > >>>>> Hi Ron, > > > >>>>> > > > >>>>> Thanks for explaining the difference between IP =46lex-Algo a= nd SR > > > >>>>> =46lex-algo. As > > > >>> you said, the major difference is the data plane. > > > >>>> > > > >>>> If my understanding is correct, for one =46lex-Algo to be used= > > > >>>> correctly, the set > > > >>> of nodes need to apply consistent constraints in computation, a= nd > > > >>> bind the =46AD to the same data plane. > > > >>>> > > > >>>> Is it possible that different nodes may use the same =46lex-Al= go with > > > >>>> different > > > >>> data plane, e.g. some with SR-MPLS, some with SRv6, and some wi= th > > > >>> pure IP etc., or each =46lex-Algo is always associated with onl= y one > > > >>> data plane=3F In the former case, should the flex-algo definiti= on also > > > >>> indicate the data plane(s) to be used with the flex-algo=3F > > > >>> > > > >>> let me respond to this query, as this is not specific to Ron's = draft. > > > >>> > > > >>> =46AD is data plane agnostic and is used by all of them. > > > >>> > > > >>> thanks, > > > >>> Peter > > > >>> > > > >>>> > > > >>>> Best regards, > > > >>>> Jie > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> =46rom: Lsr =5Bmailto:lsr-bounces=40ietf.org=5D On Behalf Of = Ron Bonica > > > >>>>> Sent: Sunday, October 4, 2020 4:34 AM > > > >>>>> To: Yingzhen Qu ; Peter Psenak > > > >>>>> ; Gyan Mishra > > > >>>>> Cc: lsr=40ietf.org; Jeff Tantsura = > > > >>>>> Subject: Re: =5BLsr=5D =46W: New Version Notification for > > > >>>>> draft-bonica-lsr-ip-flexalgo-00.txt > > > >>>>> > > > >>>>> Hi Yingzhen, > > > >>>>> > > > >>>>> IP =46lexible Algorithms are like SR =46lexible Algorithms in= the > > > >>>>> following > > > >>> respects: > > > >>>>> > > > >>>>> - Links have IGP metrics, TE metrics, delay metrics and > > > >>>>> administrative colors > > > >>>>> - =46ADs define =46lexible Algorithms > > > >>>>> > > > >>>>> More specifically, the =46AD: > > > >>>>> > > > >>>>> - Indicates which metric type the =46lexible Algorithm uses > > > >>>>> - Specifies constraints in terms of link colors that are incl= uded > > > >>>>> or excluded from the =46lexible Algorithm. > > > >>>>> > > > >>>>> The significant difference between IP =46lexible Algorithms a= nd SR > > > >>>>> =46lexible Algorithms is: > > > >>>>> > > > >>>>> - SR =46lexible Algorithms bind =46ADs to prefix SIDs or SRv6= locators > > > >>>>> - IP =46lexible Algorithms bind =46ADs to IPv4 or IPv6 addres= ses. > > > >>>>> > > > >>>>> So, IP =46lexible Algorithms can be deployed in any IP networ= k, even > > > >>>>> in the absence of SR. > > > >>>>> > > > >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Ron > > > >>>>> > > > >>>>> > > > >>>>> Juniper Business Use Only > > > >>>>> > > > >>>>> -----Original Message----- > > > >>>>> =46rom: Yingzhen Qu > > > >>>>> Sent: Saturday, October 3, 2020 2:08 PM > > > >>>>> To: Peter Psenak ; Gyan Mishra > > > >>>>> ; Ron Bonica = > > > >>>>> Cc: lsr=40ietf.org; Jeff Tantsura = > > > >>>>> Subject: Re: =5BLsr=5D =46W: New Version Notification for > > > >>>>> draft-bonica-lsr-ip-flexalgo-00.txt > > > >>>>> > > > >>>>> =5BExternal Email. Be cautious of content=5D > > > >>>>> > > > >>>>> > > > >>>>> Hi Peter, > > > >>>>> > > > >>>>> Using flex-algo, a SRv6 locator can be associated with a sing= le > > > >>>>> algo, which means an IPv6 or IPv4 address can also be associa= ted > > > >>>>> with a single algo. So my understanding is Ron's proposal is = making > > > >>>>> the > > > >>> configuration of flex-algo easier=3F > > > >>>>> Instead of using the exclude or include list you can configur= e a > > > >>>>> loopback address to a flex-algo directly=3F > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Yingzhen > > > >>>>> > > > >>>>> On 10/3/20, 2:47 AM, =22Peter Psenak=22 = wrote: > > > >>>>> > > > >>>>>=C2=A0 =C2=A0 Hi Yingzhen, > > > >>>>> > > > >>>>>=C2=A0 =C2=A0 On 02/10/2020 22:15, Yingzhen Qu wrote: > > > >>>>>> Hi Peter, > > > >>>>>> > > > >>>>>> My understanding of flex-algo is that for traffic destined > > > >>>>> to a prefix on a particular algo, it can only be routed on ro= uters > > > >>>>> belong to that algo, which also means only routers in that al= go > > > >>>>> calculates how to reach that prefix and install it into the r= outing > > > >>>>> table. It seems to me that using flex-algo (section 12 of the= > > > >>>>> draft) it's possible to have a loopback address associated wi= th > > > >>>>> only one algo, please correct me if I'm missing or misunderst= ood something. > > > >>>>> > > > >>>>>=C2=A0 =C2=A0 you are right. That is exactly what is being don= e for flex-algo with > > > >>>>>=C2=A0 =C2=A0 SRv6 - locator is associated with a single algo = only. The proposal uses > > > >>>>>=C2=A0 =C2=A0 the same concept. > > > >>>>> > > > >>>>>=C2=A0 =C2=A0 thanks, > > > >>>>>=C2=A0 =C2=A0 Peter > > > >>>>> > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Yingzhen > > > >>>>>> > > > >>>>>> On 10/2/20, 9:43 AM, =22Lsr on behalf of Peter Psenak=22 > > > >>>>> > > >>>>> ppsenak=3D40cisco.com=40dmarc.ietf.org> > > > >>>>> wrote: > > > >>>>>> > > > >>>>>>=C2=A0 =C2=A0 Gyan, > > > >>>>>> > > > >>>>>>=C2=A0 =C2=A0 On 02/10/2020 18:30, Gyan Mishra wrote: > > > >>>>>>> All, > > > >>>>>>> > > > >>>>>>> With SRv6 and IP based flex algo a generic question as it > > > >>> applies > > > >>>>> to > > > >>>>>>> both. Is it possible to have within a single IGP domain > > > >>> different > > > >>>>> sets > > > >>>>>>> of nodes or segments of the network running different > > > >>>>> algorithms. > > > >>>>>> > > > >>>>>>=C2=A0 =C2=A0 absolutely. > > > >>>>>> > > > >>>>>>> =46rom > > > >>>>>>> both drafts it sounds like all nodes have to agree on same > > > >>>>> algorithm > > > >>>>>>> similar to concept of metric and reference bandwidth all > > > >>> have to > > > >>>>> have > > > >>>>>>> the same style metric and play to the same sheet of music. > > > >>>>>> > > > >>>>>>=C2=A0 =C2=A0 all participating nodes need to agree on the de= finition of the > > > >>>>> flex-algo > > > >>>>>>=C2=A0 =C2=A0 and advertise the participation. That's it. > > > >>>>>> > > > >>>>>>> If there was > > > >>>>>>> a way to use multiple algorithms simultaneously based on > > > >>> S=46C > > > >>>>> or services > > > >>>>>>> and instantiation of specific algorithm based on service to= > > > >>> be > > > >>>>>>> rendered.=C2=A0 Doing so without causing a routing loop or = sub > > > >>>>> optimal > > > >>>>>>> routing. > > > >>>>>> > > > >>>>>>=C2=A0 =C2=A0 you can certainly use multiple algorithms simul= taneously and > > > >>> use > > > >>>>> algo > > > >>>>>>=C2=A0 =C2=A0 specific paths to forward specific traffic over= it. How that > > > >>>>>> is > > > >>> done > > > >>>>>>=C2=A0 =C2=A0 from the forwarding perspective depends in whic= h > > > >>> forwarding > > > >>>>> plane you > > > >>>>>>=C2=A0 =C2=A0 use. =46lex-algo control plane is independent o= f the forwarding > > > >>>>> plane. > > > >>>>>> > > > >>>>>> > > > >>>>>>> I thought with flex algo that there exists a feature that o= n each > > > >>>>>>> hop there is a way to specify which algo to use hop by > > > >>> hop > > > >>>>> similar > > > >>>>>>> to a hop by hop policy based routing. > > > >>>>>> > > > >>>>>>=C2=A0 =C2=A0 no, there is no hop-by-hop classification, that= is problematic > > > >>> and > > > >>>>> does > > > >>>>>>=C2=A0 =C2=A0 not scale for high speeds. Classification is do= ne at the > > > >>> ingress only. > > > >>>>>> > > > >>>>>>=C2=A0 =C2=A0 thanks, > > > >>>>>>=C2=A0 =C2=A0 Peter > > > >>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>>>=C2=A0 =C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F > > > >>>>>>=C2=A0 =C2=A0 Lsr mailing list > > > >>>>>>=C2=A0 =C2=A0 Lsr=40ietf.org > > > >>>>>> > > > >>>>> https://urldefense.com/v3/=5F=5Fhttps://nam11.safelinks.prote= ction.outl > > > >>>>> oo > > > >>>>> k.com/ > > > >>>>> =3Furl=3Dhttps*3A*2=46*2=46www.ietf.org*2=46mailman*2=46listi= nfo*2=46lsr&data > > > >>>>> =3D > > > >>> 0 > > > >>>>> 2 > > > >>>>> > > > >>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86= 781 > > > >>>>> > > > >>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C6373731527398= 6 > > > >>>>> > > > >>> 5126&sdata=3DWI48cEAan*2=46OkDPmVXGurEAjPItNG=469p9PDQIlD1i= p0g*3D > > > >>>>> > > > >>> &reserved=3D0=5F=5F;JSUlJSUlJSUlJSUlJSUlJQ=21=21NEt6yMaO-gk= =21X1fRln9MjimeJcR > > > >>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G=24 > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>> > > > >>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > >>>>> Lsr mailing list > > > >>>>> Lsr=40ietf.org > > > >>>>> https://urldefense.com/v3/=5F=5Fhttps://www.ietf.org/mailman/= listinfo/l > > > >>>>> sr=5F=5F;=21=21NEt6yMaO-gk=21TeHgIKM4lUZhkYnt=5Fe=46t3SshGJtl= n8PTqhCuZtODomUQWC=5FH > > > >>>>> z218CE8S8XzlIxAA=24 > > > >>>> > > > >>>> > > > >>> > > > >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > >>> Lsr mailing list > > > >>> Lsr=40ietf.org > > > >>> https://urldefense.com/v3/=5F=5Fhttps://www.ietf.org/mailman/li= stinfo/lsr > > > >>> =5F > > > >>> =5F;=21=21NEt6yMaO-gk=21TeHgIKM4lUZhkYnt=5Fe=46t3SshGJtln8PTqhC= uZtODomUQWC=5FHz218C > > > >>> E > > > >>> 8S8XzlIxAA=24 > -- > > Gyan Mishra > Network Solutions Architect > M 301 502-1347 > 13101 Columbia Pike > Silver Spring, MD > --5f8373b7_7a6d8d3c_cede Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Gyan,

In simple terms - destination lookup would yield a SID (stack) for SR or = next-hop/adj for IP. =46or SR, no transport device in between should try = to derive/evaluate context (source based routing - once you are in the tu= nnel), in IP case - every device will evaluate (per hop routing) the dest= ination. As long as the destination lookup result is unambiguous, any com= bination of algo's could be used.

In SR easy days we (large radio vendor :)) were considering using a set o= f loopbacks per virtual topology as a poor-man=E2=80=99s slicing in MBH, = where PCE would perform =E2=80=9Cslicing=E2=80=9D and =46EC2tunnel mappin= g over flat routing domain, perceived too complex ended up with some othe= r ways of mapping.
=46lex algo provides an easier (because distributed + additional meta-dat= a, algo =3D context) way of light virtualization as compared to MT and/or= fully centralized solutions.&=23160;

Wrt SRv6 vs IPv6 (algo is irrelevant here), I=E2=80=99d assume there=E2=80= =99s no conflict, however would leave to the implementors to comment.&=23= 160;

Cheers,
Jeff

P.S. Acee - nothing gets me more excited than algo = 201 with chocolate over it ;-)
 --5f8373b7_7a6d8d3c_cede-- From nobody Sun Oct 11 20:27:55 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B993A0997 for ; Sun, 11 Oct 2020 20:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 2QTe1nI_nIzl for ; Sun, 11 Oct 2020 20:27:48 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F6E3A099F for ; Sun, 11 Oct 2020 20:27:47 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 02D0547C21; Mon, 12 Oct 2020 11:27:42 +0800 (CST) From: "Aijun Wang" To: "'Gyan Mishra'" , "'Acee Lindem \(acee\)'" Cc: , "'Aijun Wang'" , "'Peter Psenak \(ppsenak\)'" References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> In-Reply-To: Date: Mon, 12 Oct 2020 11:27:42 +0800 Message-ID: <007701d6a047$a56f8640$f04e92c0$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01D6A08A.B39DE9D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIJ+mWorx9ReexromEfqpSgpX3kFwEFLd5+AaLg+ScCZ8Mz1AFBnbZFAnYY+uECbteHkQJR6V6DAmQjRUkCKRShvAHJrWG+AiX9uxGofGtyMA== Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZHUtJGU5OQkNOTRodVkpNS0lPTEhJTUhOSE1VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NU06NQw*Qz8eATpWGjoXCAJK NzhPCQtVSlVKTUtJT0xISU1PSkNIVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpJS01PSTcG X-HM-Tid: 0a751ad9805f9865kuuu02d0547c21 Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 03:27:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0078_01D6A08A.B39DE9D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Acee: =20 As Gyan=E2=80=99s explain, the information that identifies the passive = interfaces will give the operators the capabilities to accomplish TE = task across the different AS domains. And, flooding such passive/boundary information within IGP can lead to = the flexibility of BGP-LS deployment-----any router within the IGP = domain can report such information to PCE. =20 More replies are inline below. =20 =20 Best Regards =20 Aijun Wang China Telecom =20 From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Gyan Mishra Sent: Monday, October 12, 2020 3:19 AM To: Acee Lindem (acee) Cc: lsr@ietf.org; Aijun Wang ; Aijun Wang = ; Peter Psenak (ppsenak) Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 =20 Hi Acee =20 I believe what Aijun is trying to explain is that the primary purpose of = PCE for active or passive path computation is for inter-as RSVP-TE PCALC = path computation or SR-TE path computation. So PCE is solving a well = known PCALC bin packing problem due to pcalc over subscribing RSVP = tunnel bandwidth which is inherent an RSVP issue, but a bigger = problematic issue is with being able to build an inter-as TE path with a = single or multiple PCE controllers that can take the LSDB link = attributes in the TEDs dB opaque LSAs in the ospf case and ISIS TE TLVs = and rebuild the topology topology from each TE domain to be able to = build a congruent end to end RSVP TE or SR-TE traffic steered path = instantiation. =20 Without the use of PCE controllers as the LSDB link attribute = information is not known as RSVP loose ERO static lsp is built or SR = SR-TE prefix sid loose path is built, failover due to crank back is = impacted for reroute, due to not having a complete depiction of the = other AS Link state topology by the head end or SR source node. =20 So to build that entire end to end inter-as path for that end to end = RSVP TE or SR-TE path instantiation it is critical to indentify the = inter-as link eBGP tie link that may have static routes or BGP LU for = RSVP head end to tail end reachability and SR-TE reachability to build = out the end to end path instantiation. So the BGP-LS task to rebuild = the lsdb topology of each inter connected AS that the RSVP TE or SR-TE = steered path traverses, we need the accurate depiction and that includes = the Identification of the critical inter-as tie link eBGP peering link = that is passive for the PCE path computation logic for the end to end = inter-as path instantiation. =20 =20 As for other interfaces using passive in the context of a operator = service provider or enterprise core P and PE routers all links are = transit with neighbors except the inter-as tie so having this new IGP = TLV will help to that end. In the operator =E2=80=9Ccore=E2=80=9D = network if there are other interfaces that don=E2=80=99t need to be = advertised as stub, they can easily be excluded from being added into = IGP. =20 =20 Kind Regards=20 =20 Gyan =20 On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) = > = wrote: Hi Aijun,=20 =20 From: Aijun Wang > Date: Friday, October 9, 2020 at 9:58 PM To: Acee Lindem >, "Peter Psenak = (ppsenak)" >, 'Aijun Wang' = > Cc: "lsr@ietf.org " > Subject: RE: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Hi, Acee: =20 From: lsr-bounces@ietf.org = [mailto:lsr-bounces@ietf.org ] On Behalf = Of Acee Lindem (acee) Sent: Saturday, October 10, 2020 3:48 AM To: Aijun Wang >; Peter Psenak (ppsenak) = >; 'Aijun Wang' = > Cc: lsr@ietf.org =20 Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Speaking as WG member: =20 Hi Aijun,=20 =20 From: Aijun Wang > Date: Thursday, October 8, 2020 at 11:09 PM To: Acee Lindem >, "Peter Psenak = (ppsenak)" >, 'Aijun Wang' = > Cc: "lsr@ietf.org " > Subject: RE: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Hi, Acee: Sorry for the previous pruned mail. Let's reply you again along your = original question. Please see inline.[WAJ] =20 -----Original Message----- = = =20 From: lsr-bounces@ietf.org = [mailto:lsr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Wednesday, September 30, 2020 7:47 PM To: Aijun Wang >; Peter Psenak (ppsenak) = >; 'Aijun Wang' = > Cc: lsr@ietf.org =20 Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Hi Aijun,=20 Other than your ill-conceived topology discovery heuristic [WAJ] The topology discovery heuristic is not suitable for the corner = use case when the unnumbered interface is used, as explained in = https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appe= ndix-B. If you don=E2=80=99t agree, would you like to illustrate other = non-applicable scenarios? =20 Right =E2=80=93 and nobody other than yourself believes the IGPs should = be modified to expose the abstracted topology of an area outside that = area.=20 [WAJ] The modification doesn=E2=80=99t change the way and complexity of = route calculation within IGP. It just piggyback some extra information, = the bulk of the reconstruction work is done by the controller. Such = extra information can also have other usage, as described in = https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#sect= ion-1 And, the proposal described in = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-at= tribute-04 is different with the problem you concerned. It has no = relation with the abstracted topology of an area. Maybe you are = confused by these two drafts? =20 It is a similar problem. You are still trying to overload the prefix = advertisements with a link attribute (passive interface) so that it can = be conveyed outside the domain. We certainly wouldn=E2=80=99t waste a = limited prefix flag on this parochial application.=20 [WAJ] Such information is flooded within the domain, not outside the = domain. One bit flag can facilitate the calculation of inter-as path. Is = there any other exist flags has such important usages? =20 =20 You can solve the problem with BGP-LS session(s) between the router with = a BGP-LS session to the controller and a router in each area w/o a = router with a BGP-LS session to the controller.=20 [WAJ] This is possible, but not efficient. For operation, we must also = consider the configuration/administration overhead. BGP-LS is designed = mainly for the northbound protocol, not east-west protocol. =20 what other possible reason would there be for associating the passive = attribute with a prefix?=20 [WAJ] To know the boundary of the IGP domain. After knowing the = boundary, the controller can safely apply and check the network security = policy, the inbound traffic control policy etc. =20 It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How does = the presence of a prefix associated with a passive interface allow you = to make this deduction?=20 [WAJ] Passive interfaces are deployed mainly at the boundary of IGP = domain. Is there any other exception? While passive interfaces are not standardized, there is nothing that = limits their usage to an IGP boundary. They can and are deployed on any = interface where adjacencies are not to be formed (e.g., a stub subnet = containing hosts).=20 [WAJ] Isn=E2=80=99t the interface that connects =E2=80=9Ca stub subnet = containing hosts=E2=80=9D IGP boundary? =20 Thanks, Acee =20 Thanks, Acee =20 Thanks, Acee =20 On 9/29/20, 10:39 PM, "Aijun Wang" < = wangaijun@tsinghua.org.cn> wrote: =20 Hi, Acee and Peter: Passive interface is mainly used at the edge of the network, where = the unnumbered interface will not be used.=20 And the information to flag the passive interfaces is for = positioning the area boundary, not conflict with the abstract = capabilities of the area inside. =20 =20 Best Regards =20 Aijun Wang China Telecom =20 -----Original Message----- From: lsr-bounces@ietf.org [ = mailto:lsr-bounces@ietf.org] On Behalf Of = Acee Lindem (acee) Sent: Tuesday, September 29, 2020 9:16 PM To: Peter Psenak < = ppsenak=3D40cisco.com@dmarc.ietf.org>; Aijun Wang < = wangaijun@tsinghua.org.cn>; 'Aijun = Wang' < wangaj3@chinatelecom.cn> Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Speaking as WG member: =20 Hi Aijun, Peter,=20 I agree with Peter - one of the main motivations for having areas is = to abstract the topology within the area. Now you're trying to supplant = this - one topological detail at a time with ill-conceived IGP = features. Thanks, Acee =20 On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" < = lsr-bounces@ietf.org on behalf of = ppsenak=3D40cisco.com@dmarc.ietf.org> wrote: =20 Hi Aijun, =20 On 29/09/2020 11:07, Aijun Wang wrote: > Hi, Peter: >=20 > Thanks for your comments. > 1. For BGP-LS deployment, there normally only be one router = that within the > IGP domain to report the topology information, this router = should know such > passive links which exists mainly on other border routers via = the IGP > protocol. This is main reason to extension the IGP protocol. > = 2. For the solution, normally, the link within the IGP connect two=20 ends, but > passive interface is special and not fall in this space. We = have studied the > current TLVs that for link, and find no suitable container to = append this > information. This is the reason that we select the TLVs that = associated with > Prefix. =20 if the link is unnumbered, your solution does not work. As I = said, if=20 you need a knowledge about the link, you can not advertise it as = a prefix. =20 thanks, Peter =20 =20 >=20 >>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix = LSA", which > isolate the prefix information that associated with link into = this > container, contains the stub link, local interface information = etc. Put such > attribute along with the prefix is then acceptable? >=20 >=20 > Best Regards >=20 > Aijun Wang > China Telecom >=20 > -----Original Message----- > From: lsr-bounces@ietf.org [ = mailto:lsr-bounces@ietf.org] On Behalf Of = Peter > Psenak > Sent: Tuesday, September 29, 2020 4:29 PM > To: Aijun Wang < = wangaj3@chinatelecom.cn> > Cc: lsr@ietf.org > Subject: Re: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt >=20 > Hi Aijun, >=20 > here's my comments: >=20 > The purpose of this draft is to advertise passive links. >=20 > 1. I'm not sure the problem needs to be solved by IGPs. I tend = to believe > ietf-idr-bgpls-inter-as-topology-ext is sufficient. >=20 > 2. the solution that you proposed is wrong. You are trying to = derive > topological data about the passive links from the prefix = advertisement. > This is semantically incorrect and only works under very = specific condition. > If you need to advertise a link, advertise it as a "special" > link, not as a "special" prefix. >=20 > thanks, > Peter >=20 > On 29/09/2020 03:17, Aijun Wang wrote: >> Hi, Peter: >> >> Would you like to review and give comments on the updates = version of this > draft? >> We have also added the protocol extension proposal for = OSPFv3. >> >> The update version of this draft can refer to >> = = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface >> -attribute >> Thanks in advance. >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >>> -----Original Message----- >>> From: = internet-drafts@ietf.org [ = mailto:internet-drafts@ietf.org] >>> Sent: Monday, September 28, 2020 3:17 PM >>> To: Zhibo Hu < = huzhibo@huawei.com>; Gyan Mishra >>> < = gyan.s.mishra@verizon.com>; Aijun Wang < = wangaj3@chinatelecom.cn>; >>> Gyan S. Mishra < = gyan.s.mishra@verizon.com> >>> Subject: New Version Notification for >>> draft-wang-lsr-passive-interface-attribute-04.txt >>> >>> >>> A new version of I-D, >>> draft-wang-lsr-passive-interface-attribute-04.txt >>> has been successfully submitted by Aijun Wang and posted to = the IETF >>> repository. >>> >>> Name: = draft-wang-lsr-passive-interface-attribute >>> Revision: 04 >>> Title: Passive Interface Attribute >>> Document date: 2020-09-28 >>> Group: Individual Submission >>> Pages: 7 >>> URL: >>> = = https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04. >>> txt >>> Status: >>> = = https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att >>> r >>> ibute/ >>> Htmlized: >>> = = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac >>> e >>> -attribut >>> e >>> Htmlized: >>> = = https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut >>> e >>> -04 >>> Diff: >>> = = https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-interface-at >>> t >>> ribute-04 >>> >>> Abstract: >>> This document describes the mechanism that can be used = to >>> differentiate the passive interfaces from the normal = interfaces >>> within ISIS or OSPF domain. >>> >>> >>> >>> >>> 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 . >>> >>> The IETF Secretariat >>> >> >> >> >> >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > = https://www.ietf.org/mailman/listinfo/lsr >=20 >=20 >=20 =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr =20 =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org =20 https://www.ietf.org/mailman/listinfo/lsr --=20 =20 Gyan Mishra Network Solutions Architect=20 M 301 502-1347 13101 Columbia Pike=20 Silver Spring, MD =20 ------=_NextPart_000_0078_01D6A08A.B39DE9D0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

H= i, Acee:

<= o:p> 

A= s Gyan=E2=80=99s explain, the information that identifies the passive = interfaces will give the operators the capabilities to accomplish TE = task across the different AS domains.

A= nd, flooding such passive/boundary information within IGP can lead to = the flexibility of =C2=A0BGP-LS deployment-----any router within the IGP = domain can report such information to PCE.

<= o:p> 

M= ore replies are inline below.

<= o:p> 

<= o:p> 

B= est Regards

<= o:p> 

A= ijun Wang

C= hina Telecom<= o:p>

<= o:p> 

From:<= /b> = lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Gyan Mishra
Sent: Monday, October 12, 2020 3:19 = AM
To: Acee Lindem (acee) = <acee=3D40cisco.com@dmarc.ietf.org>
Cc: lsr@ietf.org; = Aijun Wang <wangaj3@chinatelecom.cn>; Aijun Wang = <wangaijun@tsinghua.org.cn>; Peter Psenak (ppsenak) = <ppsenak@cisco.com>
Subject: Re: [Lsr] FW: New Version = Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

 

Hi Acee

 

I believe what Aijun is trying to explain is that the = primary purpose of PCE for active or passive path computation is for = inter-as RSVP-TE PCALC path computation or SR-TE path computation.  = So PCE is solving a well known PCALC bin packing problem due to pcalc = over subscribing RSVP tunnel bandwidth which is inherent an RSVP issue, = but a bigger problematic issue is with being able to build an inter-as = TE path with a single or multiple PCE controllers that can take the LSDB = link attributes in the TEDs dB opaque LSAs in the ospf case and ISIS TE = TLVs and rebuild the topology topology from each TE domain to be able to = build a congruent end to end RSVP TE or SR-TE traffic steered path = instantiation.

 

Without the use of PCE controllers as the LSDB link = attribute information is not known as RSVP loose ERO static lsp is built = or SR SR-TE prefix sid loose path is built, failover due to crank back = is impacted for reroute, due to not having a complete depiction of the = other AS Link state topology by the head end or SR source = node.

 

So to build that entire end to end inter-as path for that = end to end RSVP TE or SR-TE path instantiation it is critical to = indentify the inter-as link eBGP tie link that may have static routes or = BGP LU for RSVP head end to tail end reachability and SR-TE reachability = to build out the end to end path instantiation.  So the BGP-LS task = to  rebuild the lsdb topology of each inter connected AS that the = RSVP TE or SR-TE steered path traverses, we need the accurate depiction = and that includes the Identification of the  critical inter-as tie = link eBGP peering link that is passive for the PCE path computation = logic for the end to end inter-as path instantiation. =  

 

As for other interfaces using passive in the context of a = operator service provider or enterprise core P and PE routers all links = are transit with neighbors except the inter-as tie so having this new = IGP TLV will help to that end.  In the operator = =E2=80=9Ccore=E2=80=9D network if there are other  interfaces that = don=E2=80=99t need to be advertised as stub, they can easily be excluded = from being added into IGP.  

 

Kind Regards 

 

Gyan

 

On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) = <acee=3D40cisco.com@dmarc.ietf.org= > wrote:

Hi Aijun, =

 =

From: = Aijun Wang <wangaijun@tsinghua.org.cn>
Date: = Friday, October 9, 2020 at 9:58 PM
To: Acee Lindem <acee@cisco.com>, = "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: "lsr@ietf.org" = <lsr@ietf.org>
Subject: RE: [Lsr] FW: = New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Hi, = Acee:

 

From:<= /b> lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Acee = Lindem (acee)
Sent: Saturday, October 10, 2020 3:48 = AM
To: Aijun Wang <wangaijun@tsinghua.org.cn>; Peter Psenak = (ppsenak) <ppsenak@cisco.com>; 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New = Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Speaking as = WG member:

 =

Hi Aijun, =

 =

From: = Aijun Wang <wangaijun@tsinghua.org.cn>
Date: = Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem = <acee@cisco.com>, "Peter Psenak = (ppsenak)" <ppsenak@cisco.com>, 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: "lsr@ietf.org" = <lsr@ietf.org>
Subject: RE: [Lsr] FW: = New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Hi, = Acee:

Sorry for the = previous pruned mail. Let's reply you again along your original = question.

Please see = inline.[WAJ]

 

-----Original = Message-----          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;         
From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Acee = Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: = Aijun Wang <wangaijun@tsinghua.org.cn>; Peter Psenak = (ppsenak) <ppsenak@cisco.com>; 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version = Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Hi Aijun, =

Other than your = ill-conceived topology discovery heuristic

[WAJ] The = topology discovery heuristic is not suitable for the corner use case = when the unnumbered interface is used, as explained in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-= originator-06#appendix-B.  If you don=E2=80=99t agree, would you like to = illustrate other non-applicable scenarios?

 =

Right = =E2=80=93 and nobody other than yourself believes the IGPs should be = modified to expose the abstracted topology of an area outside that area. =

[WAJ]  The modification = doesn=E2=80=99t change the way and complexity of route calculation = within IGP. It just piggyback some extra information, the bulk of the = reconstruction work is done by the controller.  Such extra = information can also have other usage, as described in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-= originator-06#section-1

And, the proposal described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-pa= ssive-interface-attribute-04 is different with the problem you = concerned.  It has no relation with the abstracted topology of an = area.  Maybe you are confused by these two = drafts?

 =

It is a = similar problem. You are still trying to overload the prefix = advertisements with a link attribute (passive interface) so that it can = be conveyed outside the domain. We certainly wouldn=E2=80=99t waste a = limited prefix flag on this parochial application. =

[= WAJ] Such information is flooded within the domain, not outside the = domain. One bit flag can facilitate the calculation of inter-as path. Is = there any other exist flags has such important = usages?<= o:p>

 

 

You can = solve the problem with BGP-LS session(s) between the router with a = BGP-LS session to the controller and a router in each area w/o  a = router with a BGP-LS session to the controller.

[WAJ] This is possible, but not = efficient. For operation, we must also consider the = configuration/administration overhead.  BGP-LS is designed mainly = for the northbound protocol, not east-west protocol.

 

what other = possible reason would there be for associating the passive attribute = with a prefix?

[WAJ] To know the = boundary of the IGP domain. After knowing the boundary, the controller = can safely apply and check the network security policy, the inbound = traffic control policy etc.

 =

It really = isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How does the = presence of a prefix associated with a passive interface allow you to = make this deduction?

[WAJ] Passive interfaces are = deployed mainly at the boundary of IGP domain.  Is there any other = exception?

While = passive interfaces are not standardized, there is nothing that limits = their usage to an IGP boundary. They can and are deployed on any = interface where adjacencies are not to be formed (e.g., a stub subnet = containing hosts).

[= WAJ] Isn=E2=80=99t the interface that connects =E2=80=9Ca stub subnet = containing hosts=E2=80=9D IGP boundary?<= o:p>

 =

Thanks,
Ac= ee

 =

Thanks,

Acee

 

Thanks,

Acee

 

On 9/29/20, = 10:39 PM, "Aijun Wang" <wangaijun@tsinghua.org.cn= > wrote:

 

    Hi, Acee = and Peter:

    Passive = interface is mainly used at the edge of the network, where the = unnumbered interface will not be used.

    And = the information to flag the passive interfaces is for positioning the = area boundary, not conflict with the abstract capabilities of the area = inside.

 

 

    Best = Regards

 

    Aijun = Wang

    China = Telecom

 

    = -----Original Message-----

    From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.o= rg] On Behalf Of Acee Lindem (acee)

    Sent: = Tuesday, September 29, 2020 9:16 PM

    To: Peter = Psenak <ppsenak=3D40cisco.com@dma= rc.ietf.org>; Aijun Wang <wangaijun@tsinghua.org.cn= >; 'Aijun Wang' <wangaj3@chinatelecom.cn>

    Cc: lsr@ietf.org

    Subject: = Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

    Speaking = as WG member:

 

    Hi Aijun, = Peter,

    I = agree with Peter - one of the main motivations for having areas is to = abstract the topology within the area. Now you're trying to supplant = this  - one topological detail at a time with ill-conceived IGP = features.

    = Thanks,

    = Acee

 

    On = 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" <lsr-bounces@ietf.org on = behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> = wrote:

 

     =    Hi Aijun,

 

     =    On 29/09/2020 11:07, Aijun Wang wrote:

     =    > Hi, Peter:

     =    >

     =    > Thanks for your comments.

     =    > 1. For BGP-LS deployment, there normally only be one = router that within the

     =    > IGP domain to report the topology information, this = router should know such

     =    > passive links which exists mainly on other border = routers via the IGP

     =    > protocol. This is main reason to extension the IGP = protocol. > 2. For the solution, normally, the link within the IGP = connect two

     =    ends, but

     =    > passive interface is special and not fall in this = space. We have studied the

     =    > current TLVs that for link, and find no suitable = container to append this

     =    > information. This is the reason that we select the = TLVs that associated with

     =    > Prefix.

 

     =    if the link is unnumbered, your solution does not work. As = I said, if

     =    you need a knowledge about the link, you can not = advertise it as a prefix.

 

     =    thanks,

     =    Peter

 

 

     =    >

     =    >>From other POV, the OSPFv3 defines now the = "Intra-Area-Prefix LSA", which

     =    > isolate the prefix information that associated with = link into this

     =    > container, contains the stub link, local interface = information etc. Put such

     =    > attribute along with the prefix is then = acceptable?

     =    >

     =    >

     =    > Best Regards

     =    >

     =    > Aijun Wang

     =    > China Telecom

     =    >

     =    > -----Original Message-----

     =    > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.o= rg] On Behalf Of Peter

     =    > Psenak

     =    > Sent: Tuesday, September 29, 2020 4:29 PM

     =    > To: Aijun Wang <wangaj3@chinatelecom.cn>

     =    > Cc: lsr@ietf.org

     =    > Subject: Re: [Lsr] FW: New Version Notification = for

     =    > = draft-wang-lsr-passive-interface-attribute-04.txt

     =    >

     =    > Hi Aijun,

     =    >

     =    > here's my comments:

     =    >

     =    > The purpose of this draft is to advertise passive = links.

     =    >

     =    > 1. I'm not sure the problem needs to be solved by = IGPs. I tend to believe

     =    > ietf-idr-bgpls-inter-as-topology-ext is = sufficient.

     =    >

     =    > 2. the solution that you proposed is wrong. You = are trying to derive

     =    > topological data about the passive links from the = prefix advertisement.

     =    > This is semantically incorrect and only works under = very specific condition.

     =    > If you need to advertise a link, advertise it as a = "special"

     =    > link, not as a "special" prefix.

     =    >

     =    > thanks,

     =    > Peter

     =    >

     =    > On 29/09/2020 03:17, Aijun Wang = wrote:

     =    >> Hi, Peter:

     =    >>

     =    >> Would you like to review and give comments on the = updates version of this

     =    > draft?

     =    >> We have also added the protocol extension proposal = for OSPFv3.

     =    >>

     =    >> The update version of this draft can refer = to

     =    >> https://datatracker.ietf.= org/doc/html/draft-wang-lsr-passive-interface

     =    >> -attribute

     =    >> Thanks in advance.

     =    >>

     =    >>

     =    >> Best Regards

     =    >>

     =    >> Aijun Wang

     =    >> China Telecom

     =    >>

     =    >>> -----Original Message-----

     =    >>> From: internet-drafts@ietf.org<= /span> [mailto:internet-drafts@ie= tf.org]

     =    >>> Sent: Monday, September 28, 2020 3:17 = PM

     =    >>> To: Zhibo Hu <huzhibo@huawei.com= >; Gyan Mishra

     =    >>> <gyan.s.mishra@verizon.com= >; Aijun Wang <wangaj3@chinatelecom.cn>;

     =    >>> Gyan S. Mishra <gyan.s.mishra@verizon.com= >

     =    >>> Subject: New Version Notification = for

     =    >>> = draft-wang-lsr-passive-interface-attribute-04.txt

     =    >>>

     =    >>>

     =    >>> A new version of I-D,

     =    >>> = draft-wang-lsr-passive-interface-attribute-04.txt

     =    >>> has been successfully submitted by Aijun Wang = and posted to the IETF

     =    >>> repository.

     =    >>>

     =    >>> = Name:           &n= bsp;   draft-wang-lsr-passive-interface-attribute

     =    >>> Revision:   04

     =    >>> = Title:         Passive Interface = Attribute

     =    >>> Document = date:       2020-09-28

     =    >>> = Group:           &= nbsp;   Individual Submission

     =    >>> = Pages:           &= nbsp;   7

     =    >>> URL:

     =    >>> https://www.ietf.org/id/d= raft-wang-lsr-passive-interface-attribute-04.

     =    >>> txt

     =    >>> Status:

     =    >>> https://datatracker.ietf.= org/doc/draft-wang-lsr-passive-interface-att

     =    >>> r

     =    >>> ibute/

     =    >>> Htmlized:

     =    >>> https://datatracker.ietf.= org/doc/html/draft-wang-lsr-passive-interfac

     =    >>> e

     =    >>> -attribut

     =    >>> e

     =    >>> Htmlized:

     =    >>> https://tools.ietf.org/ht= ml/draft-wang-lsr-passive-interface-attribut

     =    >>> e

     =    >>> -04

     =    >>> Diff:

     =    >>> https://www.ietf.org/rfcd= iff?url2=3Ddraft-wang-lsr-passive-interface-at

     =    >>> t

     =    >>> ribute-04

     =    >>>

     =    >>> Abstract:

     =    >>>      This document = describes the mechanism that can be used to

     =    >>>      differentiate = the passive interfaces from the normal interfaces

     =    >>>      within ISIS or = OSPF domain.

     =    >>>

     =    >>>

     =    >>>

     =    >>>

     =    >>> 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.

     =    >>>

     =    >>> The IETF Secretariat

     =    >>>

     =    >>

     =    >>

     =    >>

     =    >>

     =    >

     =    > = _______________________________________________

     =    > Lsr mailing list

     =    > Lsr@ietf.org

     =    > https://www.ietf.org/mail= man/listinfo/lsr

     =    >

     =    >

     =    >

 

     =    _______________________________________________

     =    Lsr mailing list

     =    Lsr@ietf.org

     =    https://www.ietf.org/mail= man/listinfo/lsr

 

    = _______________________________________________

    Lsr = mailing list

    Lsr@ietf.org

    https://www.ietf.org/mail= man/listinfo/lsr

 

 

______________________________= _________________

Lsr mailing = list

Lsr@ietf.org

https://www.ietf.org/mail= man/listinfo/lsr

_______________________________________________
Lsr = mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

-- =

=

Gyan = Mishra

Network = Solutions Architect 

M 301 = 502-1347
13101 Columbia Pike 
Silver Spring, = MD

 

------=_NextPart_000_0078_01D6A08A.B39DE9D0-- From nobody Sun Oct 11 23:53:32 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFA13A12C1 for ; Sun, 11 Oct 2020 23:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 D6iJtD8Fa4YN for ; Sun, 11 Oct 2020 23:53:28 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A0A3A12C0 for ; Sun, 11 Oct 2020 23:53:28 -0700 (PDT) Received: from lhreml720-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 55CE8933D9E65BA816B1; Mon, 12 Oct 2020 07:53:25 +0100 (IST) Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Mon, 12 Oct 2020 07:53:24 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 12 Oct 2020 14:53:22 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Mon, 12 Oct 2020 14:53:22 +0800 From: "Dongjie (Jimmy)" To: Ron Bonica , Peter Psenak , Yingzhen Qu , Gyan Mishra CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAESbICAACKHAIAA7E2AgADTYwCAAWy/gIAAAz6AgAA7sgCAAOLhAIAAi8SAgAAopgCAA1loEIAFx4OAgAExPQCAACwOgIADQL2w Date: Mon, 12 Oct 2020 06:53:22 +0000 Message-ID: References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 06:53:31 -0000 Hi Ron,=20 Please see inline: > -----Original Message----- > From: Ron Bonica [mailto:rbonica@juniper.net] > Sent: Saturday, October 10, 2020 8:48 PM > To: Dongjie (Jimmy) ; Peter Psenak > ; Yingzhen Qu ; Gyan > Mishra > Cc: lsr@ietf.org; Jeff Tantsura > Subject: RE: [Lsr] FW: New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt >=20 > Hi Jimmie, >=20 > Inline..... >=20 > Ron >=20 >=20 > Juniper Business Use Only >=20 > -----Original Message----- > From: Dongjie (Jimmy) > Sent: Friday, October 9, 2020 11:06 PM > To: Peter Psenak ; Ron Bonica ; > Yingzhen Qu ; Gyan Mishra > > Cc: lsr@ietf.org; Jeff Tantsura > Subject: RE: [Lsr] FW: New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt >=20 > [External Email. Be cautious of content] >=20 >=20 > Hi Peter, >=20 > Thanks for your reply. It aligns with my understanding of FAD, which is j= ust a set > of constraints for path computation. Thus one Flex-Algo ID could be used = with > multiple different data planes. Is this understanding correct? >=20 > [RB] I never thought about this. Is there a use-case? I think that it wil= l work, > but I would have to try it before saying for sure. One possible case is to define one Flex-Algo (say FA-128) with delay metric= and no admin-group (color) constraints. Then as Flex-Algo is data plane ag= nostic, FA-128 could be used to bind to prefix-SIDs, SRv6 locators or IP ad= dresses. >=20 > If so, my question is about the scenario below: >=20 > A group of nodes in a network support FA-128, a sub-group of them bind FA= -128 > to SR SIDs, another sub-group of them bind FA-128 to IP address. When one > node compute an SR path to a destination, can it compute the path to only= pass > the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA= -128 > to IP address? >=20 > [RB] I don't think so. However, you could achieve the same outcome using = link > colors. Do you mean to use different link colors to identify links with different d= ata plane enabled? I believe it would work, while actually this is using di= fferent Flex-Algos (with different color constraints) for different data pl= ane.=20 Best regards, Jie > If so, how could this node know the binding of FA to different data plane= s on > other nodes? >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > > Sent: Friday, October 9, 2020 11:58 PM > > To: Dongjie (Jimmy) ; Ron Bonica > > ; Yingzhen Qu > > ; Gyan Mishra > > Cc: lsr@ietf.org; Jeff Tantsura > > Subject: Re: [Lsr] FW: New Version Notification for > > draft-bonica-lsr-ip-flexalgo-00.txt > > > > Hi Jimmy, > > > > > > On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > > > Hi Ron, > > > > > > Thanks for explaining the difference between IP Flex-Algo and SR > > > Flex-algo. As > > you said, the major difference is the data plane. > > > > > > If my understanding is correct, for one Flex-Algo to be used > > > correctly, the set > > of nodes need to apply consistent constraints in computation, and bind > > the FAD to the same data plane. > > > > > > Is it possible that different nodes may use the same Flex-Algo with > > > different > > data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure > > IP etc., or each Flex-Algo is always associated with only one data > > plane? In the former case, should the flex-algo definition also > > indicate the data plane(s) to be used with the flex-algo? > > > > let me respond to this query, as this is not specific to Ron's draft. > > > > FAD is data plane agnostic and is used by all of them. > > > > thanks, > > Peter > > > > > > > > Best regards, > > > Jie > > > > > >> -----Original Message----- > > >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica > > >> Sent: Sunday, October 4, 2020 4:34 AM > > >> To: Yingzhen Qu ; Peter Psenak > > >> ; Gyan Mishra > > >> Cc: lsr@ietf.org; Jeff Tantsura > > >> Subject: Re: [Lsr] FW: New Version Notification for > > >> draft-bonica-lsr-ip-flexalgo-00.txt > > >> > > >> Hi Yingzhen, > > >> > > >> IP Flexible Algorithms are like SR Flexible Algorithms in the > > >> following > > respects: > > >> > > >> - Links have IGP metrics, TE metrics, delay metrics and > > >> administrative colors > > >> - FADs define Flexible Algorithms > > >> > > >> More specifically, the FAD: > > >> > > >> - Indicates which metric type the Flexible Algorithm uses > > >> - Specifies constraints in terms of link colors that are included > > >> or excluded from the Flexible Algorithm. > > >> > > >> The significant difference between IP Flexible Algorithms and SR > > >> Flexible Algorithms is: > > >> > > >> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators > > >> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > > >> > > >> So, IP Flexible Algorithms can be deployed in any IP network, even > > >> in the absence of SR. > > >> > > >> Ron > > >> > > >> > > >> Juniper Business Use Only > > >> > > >> -----Original Message----- > > >> From: Yingzhen Qu > > >> Sent: Saturday, October 3, 2020 2:08 PM > > >> To: Peter Psenak ; Gyan Mishra > > >> ; Ron Bonica > > >> Cc: lsr@ietf.org; Jeff Tantsura > > >> Subject: Re: [Lsr] FW: New Version Notification for > > >> draft-bonica-lsr-ip-flexalgo-00.txt > > >> > > >> [External Email. Be cautious of content] > > >> > > >> > > >> Hi Peter, > > >> > > >> Using flex-algo, a SRv6 locator can be associated with a single > > >> algo, which means an IPv6 or IPv4 address can also be associated > > >> with a single algo. So my understanding is Ron's proposal is making > > >> the > > configuration of flex-algo easier? > > >> Instead of using the exclude or include list you can configure a > > >> loopback address to a flex-algo directly? > > >> > > >> Thanks, > > >> Yingzhen > > >> > > >> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: > > >> > > >> Hi Yingzhen, > > >> > > >> On 02/10/2020 22:15, Yingzhen Qu wrote: > > >> > Hi Peter, > > >> > > > >> > My understanding of flex-algo is that for traffic destined > > >> to a prefix on a particular algo, it can only be routed on routers > > >> belong to that algo, which also means only routers in that algo > > >> calculates how to reach that prefix and install it into the routing > > >> table. It seems to me that using flex-algo (section 12 of the > > >> draft) it's possible to have a loopback address associated with > > >> only one algo, please correct me if I'm missing or misunderstood > something. > > >> > > >> you are right. That is exactly what is being done for flex-algo= with > > >> SRv6 - locator is associated with a single algo only. The propo= sal > uses > > >> the same concept. > > >> > > >> thanks, > > >> Peter > > >> > > >> > > > >> > Thanks, > > >> > Yingzhen > > >> > > > >> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > > >> > >> ppsenak=3D40cisco.com@dmarc.ietf.org> > > >> wrote: > > >> > > > >> > Gyan, > > >> > > > >> > On 02/10/2020 18:30, Gyan Mishra wrote: > > >> > > All, > > >> > > > > >> > > With SRv6 and IP based flex algo a generic question as= it > > applies > > >> to > > >> > > both. Is it possible to have within a single IGP domai= n > > different > > >> sets > > >> > > of nodes or segments of the network running different > > >> algorithms. > > >> > > > >> > absolutely. > > >> > > > >> > > From > > >> > > both drafts it sounds like all nodes have to agree on = same > > >> algorithm > > >> > > similar to concept of metric and reference bandwidth a= ll > > have to > > >> have > > >> > > the same style metric and play to the same sheet of > music. > > >> > > > >> > all participating nodes need to agree on the definition = of > the > > >> flex-algo > > >> > and advertise the participation. That's it. > > >> > > > >> > > If there was > > >> > > a way to use multiple algorithms simultaneously based > on > > SFC > > >> or services > > >> > > and instantiation of specific algorithm based on servi= ce > to > > be > > >> > > rendered. Doing so without causing a routing loop or > sub > > >> optimal > > >> > > routing. > > >> > > > >> > you can certainly use multiple algorithms simultaneously > and > > use > > >> algo > > >> > specific paths to forward specific traffic over it. How = that is > > done > > >> > from the forwarding perspective depends in which > > forwarding > > >> plane you > > >> > use. Flex-algo control plane is independent of the > forwarding > > >> plane. > > >> > > > >> > > > >> > >I thought with flex algo that there exists a feature th= at on > > >> > > each hop there is a way to specify which algo to use h= op > by > > hop > > >> similar > > >> > > to a hop by hop policy based routing. > > >> > > > >> > no, there is no hop-by-hop classification, that is > problematic > > and > > >> does > > >> > not scale for high speeds. Classification is done at the > > ingress only. > > >> > > > >> > thanks, > > >> > Peter > > >> > > > >> > > > > >> > > > >> > _______________________________________________ > > >> > Lsr mailing list > > >> > Lsr@ietf.org > > >> > > > >> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl > > >> oo > > >> k.com/ > > >> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&dat= a > > >> =3D > > 0 > > >> 2 > > >> > > > *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 > > >> > > 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > > >> > > > 5126&sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > > >> > > > &reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR > > >> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > > >> > > > >> > > > >> > > > >> > > >> _______________________________________________ > > >> Lsr mailing list > > >> Lsr@ietf.org > > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l > > >> > sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC > _H > > >> z218CE8S8XzlIxAA$ > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > > > _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H > z218CE > > 8S8XzlIxAA$ From nobody Mon Oct 12 00:12:39 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7263A12D4 for ; Mon, 12 Oct 2020 00:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 DzQFrV6OYsaF for ; Mon, 12 Oct 2020 00:12:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32EC3A0F36 for ; Mon, 12 Oct 2020 00:12:34 -0700 (PDT) Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A7FBD23621993CC7B519; Mon, 12 Oct 2020 08:12:33 +0100 (IST) Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Mon, 12 Oct 2020 08:12:32 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 12 Oct 2020 15:12:30 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Mon, 12 Oct 2020 15:12:30 +0800 From: "Dongjie (Jimmy)" To: Jeff Tantsura , Ron Bonica CC: Peter Psenak , Yingzhen Qu , Gyan Mishra , "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAESbICAACKHAIAA7E2AgADTYwCAAWy/gIAAAz6AgAA7sgCAAOLhAIAAi8SAgAAopgCAA1loEIAFx4OAgAExPQCAACwOgIAAa8sAgALb+jA= Date: Mon, 12 Oct 2020 07:12:30 +0000 Message-ID: References: <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.com> In-Reply-To: <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 07:12:38 -0000 SGkgSmVmZiwNCg0KVGhhbmtzIGZvciB5b3VyIGV4cGxhbmF0aW9uLiBJIHVuZGVyc3RhbmQgdGhh dCBmb3IgZGlmZmVyZW50IGRhdGEgcGxhbmUgdGhlIFNJRHMgb3IgSVAgYWRkcmVzc2VzIGhhdmUg ZGlmZmVyZW50IHNjb3BlLCBhbmQgd2lsbCBub3QgY29uZmxpY3QgaW4gbm9ybWFsIGNhc2VzLg0K DQpNeSBxdWVzdGlvbiBpcyBtb3JlIGFib3V0IHdoZXRoZXIgYSBjb21wdXRhdGlvbiBub2RlIG5l ZWRzIHRvIGtub3cgYW5kIGNoZWNrIHdoaWNoIGRhdGEgcGxhbmUgaXMgdXNlZCBieSB0aGUgaW50 ZXJtZWRpYXRlIG5vZGVzIHRvIGJpbmQgdG8gdGhlIEZsZXgtQWxnbz8gSW4gYW5vdGhlciB3b3Jk LCBjYW4gYW4gU1IgcGF0aCBjb21wdXRlZCB1c2luZyBGbGV4LUFsZ28gMTI4IGdvIHRocm91Z2gg YW4gaW50ZXJtZWRpYXRlIG5vZGUgd2hpY2ggYmluZCBGbGV4LUFsZ28gMTI4IHRvIElQIGRhdGEg cGxhbmU/DQoNCkJlc3QgcmVnYXJkcywNCkppZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IEplZmYgVGFudHN1cmEgW21haWx0bzpqZWZmdGFudC5pZXRmQGdtYWlsLmNv bV0NCj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDExLCAyMDIwIDM6MTQgQU0NCj4gVG86IFJvbiBC b25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+DQo+IENjOiBEb25namllIChKaW1teSkgPGppZS5k b25nQGh1YXdlaS5jb20+OyBQZXRlciBQc2VuYWsNCj4gPHBwc2VuYWtAY2lzY28uY29tPjsgWWlu Z3poZW4gUXUgPHlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5jb20+OyBHeWFuDQo+IE1pc2hyYSA8aGF5 YWJ1c2Fnc21AZ21haWwuY29tPjsgbHNyQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTHNyXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1ib25pY2EtbHNyLWlwLWZs ZXhhbGdvLTAwLnR4dA0KPiANCj4gSmllLA0KPiANCj4gVGhlIHNjb29wIGlzIGRpZmZlcmVudCwg Zm9yIFNSIGRhdGEgcGxhbmUgZW50cnkgdW5pcXVlbmVzcyBpcyBpbiBjb250ZXh0IG9mIFNSDQo+ IGRvbWFpbiAoU0lEID0gdmFsdWUgKyBjb250ZXh0KSwgd2hpbGUgZm9yIElQIGl0IGlzIGdsb2Jh bCB0byB0aGUgcm91dGluZyBkb21haW4sDQo+IEZJQiBlbnRyeSBpcyBhIGRlc3RpbmF0aW9uLCBu b3RoaW5nIG1vcmUuDQo+IA0KPiBSZWdhcmRzLA0KPiBKZWZmDQo+IA0KPiA+IE9uIE9jdCAxMCwg MjAyMCwgYXQgMDU6NDcsIFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+IHdyb3RlOg0K PiA+DQo+ID4g77u/SGkgSmltbWllLA0KPiA+DQo+ID4gSW5saW5lLi4uLi4NCj4gPg0KPiA+ICAg ICAgICAgICAgICAgICAgICBSb24NCj4gPg0KPiA+DQo+ID4gSnVuaXBlciBCdXNpbmVzcyBVc2Ug T25seQ0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBEb25n amllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb20+DQo+ID4gU2VudDogRnJpZGF5LCBPY3Rv YmVyIDksIDIwMjAgMTE6MDYgUE0NCj4gPiBUbzogUGV0ZXIgUHNlbmFrIDxwcHNlbmFrQGNpc2Nv LmNvbT47IFJvbiBCb25pY2ENCj4gPiA8cmJvbmljYUBqdW5pcGVyLm5ldD47IFlpbmd6aGVuIFF1 IDx5aW5nemhlbi5xdUBmdXR1cmV3ZWkuY29tPjsgR3lhbg0KPiA+IE1pc2hyYSA8aGF5YWJ1c2Fn c21AZ21haWwuY29tPg0KPiA+IENjOiBsc3JAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmEgPGplZmZ0 YW50LmlldGZAZ21haWwuY29tPg0KPiA+IFN1YmplY3Q6IFJFOiBbTHNyXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDAu dHh0DQo+ID4NCj4gPiBbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQo+ ID4NCj4gPg0KPiA+IEhpIFBldGVyLA0KPiA+DQo+ID4gVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBJ dCBhbGlnbnMgd2l0aCBteSB1bmRlcnN0YW5kaW5nIG9mIEZBRCwgd2hpY2ggaXMganVzdCBhDQo+ IHNldCBvZiBjb25zdHJhaW50cyBmb3IgcGF0aCBjb21wdXRhdGlvbi4gVGh1cyBvbmUgRmxleC1B bGdvIElEIGNvdWxkIGJlIHVzZWQNCj4gd2l0aCBtdWx0aXBsZSBkaWZmZXJlbnQgZGF0YSBwbGFu ZXMuIElzIHRoaXMgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0KPiA+DQo+ID4gW1JCXSBJIG5ldmVy IHRob3VnaHQgYWJvdXQgdGhpcy4gSXMgdGhlcmUgYSB1c2UtY2FzZT8gSSB0aGluayB0aGF0IGl0 IHdpbGwgd29yaywNCj4gYnV0IEkgd291bGQgaGF2ZSB0byB0cnkgaXQgYmVmb3JlIHNheWluZyBm b3Igc3VyZS4NCj4gPg0KPiA+IElmIHNvLCBteSBxdWVzdGlvbiBpcyBhYm91dCB0aGUgc2NlbmFy aW8gYmVsb3c6DQo+ID4NCj4gPiBBIGdyb3VwIG9mIG5vZGVzIGluIGEgbmV0d29yayBzdXBwb3J0 IEZBLTEyOCwgYSBzdWItZ3JvdXAgb2YgdGhlbSBiaW5kDQo+IEZBLTEyOCB0byBTUiBTSURzLCBh bm90aGVyIHN1Yi1ncm91cCBvZiB0aGVtIGJpbmQgRkEtMTI4IHRvIElQIGFkZHJlc3MuIFdoZW4N Cj4gb25lIG5vZGUgY29tcHV0ZSBhbiBTUiBwYXRoIHRvIGEgZGVzdGluYXRpb24sIGNhbiBpdCBj b21wdXRlIHRoZSBwYXRoIHRvIG9ubHkNCj4gcGFzcyB0aGUgbm9kZXMgd2hpY2ggYmluZCBGQS0x MjggdG8gU1IgU0lEcywgYW5kIGF2b2lkIHRoZSBub2RlcyB3aGljaCBiaW5kDQo+IEZBLTEyOCB0 byBJUCBhZGRyZXNzPw0KPiA+DQo+ID4gW1JCXSBJIGRvbid0IHRoaW5rIHNvLiBIb3dldmVyLCB5 b3UgY291bGQgYWNoaWV2ZSB0aGUgc2FtZSBvdXRjb21lIHVzaW5nIGxpbmsNCj4gY29sb3JzLg0K PiA+DQo+ID4gSWYgc28sIGhvdyBjb3VsZCB0aGlzIG5vZGUga25vdyB0aGUgYmluZGluZyBvZiBG QSB0byBkaWZmZXJlbnQgZGF0YSBwbGFuZXMgb24NCj4gb3RoZXIgbm9kZXM/DQo+ID4NCj4gPiBC ZXN0IHJlZ2FyZHMsDQo+ID4gSmllDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4gRnJvbTogTHNyIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBQZXRlciBQc2VuYWsNCj4gPj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDksIDIwMjAgMTE6 NTggUE0NCj4gPj4gVG86IERvbmdqaWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT47IFJv biBCb25pY2ENCj4gPj4gPHJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz47IFlp bmd6aGVuIFF1DQo+ID4+IDx5aW5nemhlbi5xdUBmdXR1cmV3ZWkuY29tPjsgR3lhbiBNaXNocmEg PGhheWFidXNhZ3NtQGdtYWlsLmNvbT4NCj4gPj4gQ2M6IGxzckBpZXRmLm9yZzsgSmVmZiBUYW50 c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+DQo+ID4+IFN1YmplY3Q6IFJlOiBbTHNyXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+PiBkcmFmdC1ib25pY2EtbHNyLWlw LWZsZXhhbGdvLTAwLnR4dA0KPiA+Pg0KPiA+PiBIaSBKaW1teSwNCj4gPj4NCj4gPj4NCj4gPj4+ ICBPbiAwOS8xMC8yMDIwIDA0OjU5LCBEb25namllIChKaW1teSkgd3JvdGU6DQo+ID4+PiBIaSBS b24sDQo+ID4+Pg0KPiA+Pj4gVGhhbmtzIGZvciBleHBsYWluaW5nIHRoZSBkaWZmZXJlbmNlIGJl dHdlZW4gSVAgRmxleC1BbGdvIGFuZCBTUg0KPiA+Pj4gRmxleC1hbGdvLiBBcw0KPiA+PiB5b3Ug c2FpZCwgdGhlIG1ham9yIGRpZmZlcmVuY2UgaXMgdGhlIGRhdGEgcGxhbmUuDQo+ID4+Pg0KPiA+ Pj4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCBmb3Igb25lIEZsZXgtQWxnbyB0byBi ZSB1c2VkDQo+ID4+PiBjb3JyZWN0bHksIHRoZSBzZXQNCj4gPj4gb2Ygbm9kZXMgbmVlZCB0byBh cHBseSBjb25zaXN0ZW50IGNvbnN0cmFpbnRzIGluIGNvbXB1dGF0aW9uLCBhbmQNCj4gPj4gYmlu ZCB0aGUgRkFEIHRvIHRoZSBzYW1lIGRhdGEgcGxhbmUuDQo+ID4+Pg0KPiA+Pj4gSXMgaXQgcG9z c2libGUgdGhhdCBkaWZmZXJlbnQgbm9kZXMgbWF5IHVzZSB0aGUgc2FtZSBGbGV4LUFsZ28gd2l0 aA0KPiA+Pj4gZGlmZmVyZW50DQo+ID4+IGRhdGEgcGxhbmUsIGUuZy4gc29tZSB3aXRoIFNSLU1Q TFMsIHNvbWUgd2l0aCBTUnY2LCBhbmQgc29tZSB3aXRoDQo+ID4+IHB1cmUgSVAgZXRjLiwgb3Ig ZWFjaCBGbGV4LUFsZ28gaXMgYWx3YXlzIGFzc29jaWF0ZWQgd2l0aCBvbmx5IG9uZQ0KPiA+PiBk YXRhIHBsYW5lPyBJbiB0aGUgZm9ybWVyIGNhc2UsIHNob3VsZCB0aGUgZmxleC1hbGdvIGRlZmlu aXRpb24gYWxzbw0KPiA+PiBpbmRpY2F0ZSB0aGUgZGF0YSBwbGFuZShzKSB0byBiZSB1c2VkIHdp dGggdGhlIGZsZXgtYWxnbz8NCj4gPj4NCj4gPj4gbGV0IG1lIHJlc3BvbmQgdG8gdGhpcyBxdWVy eSwgYXMgdGhpcyBpcyBub3Qgc3BlY2lmaWMgdG8gUm9uJ3MgZHJhZnQuDQo+ID4+DQo+ID4+IEZB RCBpcyBkYXRhIHBsYW5lIGFnbm9zdGljIGFuZCBpcyB1c2VkIGJ5IGFsbCBvZiB0aGVtLg0KPiA+ Pg0KPiA+PiB0aGFua3MsDQo+ID4+IFBldGVyDQo+ID4+DQo+ID4+Pg0KPiA+Pj4gQmVzdCByZWdh cmRzLA0KPiA+Pj4gSmllDQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+Pj4gRnJvbTogTHNyIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBSb24gQm9uaWNhDQo+ID4+Pj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDQsIDIwMjAgNDoz NCBBTQ0KPiA+Pj4+IFRvOiBZaW5nemhlbiBRdSA8eWluZ3poZW4ucXVAZnV0dXJld2VpLmNvbT47 IFBldGVyIFBzZW5haw0KPiA+Pj4+IDxwcHNlbmFrQGNpc2NvLmNvbT47IEd5YW4gTWlzaHJhIDxo YXlhYnVzYWdzbUBnbWFpbC5jb20+DQo+ID4+Pj4gQ2M6IGxzckBpZXRmLm9yZzsgSmVmZiBUYW50 c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+DQo+ID4+Pj4gU3ViamVjdDogUmU6IFtMc3Jd IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4+Pj4gZHJhZnQtYm9uaWNhLWxz ci1pcC1mbGV4YWxnby0wMC50eHQNCj4gPj4+Pg0KPiA+Pj4+IEhpIFlpbmd6aGVuLA0KPiA+Pj4+ DQo+ID4+Pj4gSVAgRmxleGlibGUgQWxnb3JpdGhtcyBhcmUgbGlrZSBTUiBGbGV4aWJsZSBBbGdv cml0aG1zIGluIHRoZQ0KPiA+Pj4+IGZvbGxvd2luZw0KPiA+PiByZXNwZWN0czoNCj4gPj4+Pg0K PiA+Pj4+IC0gTGlua3MgaGF2ZSBJR1AgbWV0cmljcywgVEUgbWV0cmljcywgZGVsYXkgbWV0cmlj cyBhbmQNCj4gPj4+PiBhZG1pbmlzdHJhdGl2ZSBjb2xvcnMNCj4gPj4+PiAtIEZBRHMgZGVmaW5l IEZsZXhpYmxlIEFsZ29yaXRobXMNCj4gPj4+Pg0KPiA+Pj4+IE1vcmUgc3BlY2lmaWNhbGx5LCB0 aGUgRkFEOg0KPiA+Pj4+DQo+ID4+Pj4gLSBJbmRpY2F0ZXMgd2hpY2ggbWV0cmljIHR5cGUgdGhl IEZsZXhpYmxlIEFsZ29yaXRobSB1c2VzDQo+ID4+Pj4gLSBTcGVjaWZpZXMgY29uc3RyYWludHMg aW4gdGVybXMgb2YgbGluayBjb2xvcnMgdGhhdCBhcmUgaW5jbHVkZWQNCj4gPj4+PiBvciBleGNs dWRlZCBmcm9tIHRoZSBGbGV4aWJsZSBBbGdvcml0aG0uDQo+ID4+Pj4NCj4gPj4+PiBUaGUgc2ln bmlmaWNhbnQgZGlmZmVyZW5jZSBiZXR3ZWVuIElQIEZsZXhpYmxlIEFsZ29yaXRobXMgYW5kIFNS DQo+ID4+Pj4gRmxleGlibGUgQWxnb3JpdGhtcyBpczoNCj4gPj4+Pg0KPiA+Pj4+IC0gU1IgRmxl eGlibGUgQWxnb3JpdGhtcyBiaW5kIEZBRHMgdG8gcHJlZml4IFNJRHMgb3IgU1J2NiBsb2NhdG9y cw0KPiA+Pj4+IC0gSVAgRmxleGlibGUgQWxnb3JpdGhtcyBiaW5kIEZBRHMgdG8gSVB2NCBvciBJ UHY2IGFkZHJlc3Nlcy4NCj4gPj4+Pg0KPiA+Pj4+IFNvLCBJUCBGbGV4aWJsZSBBbGdvcml0aG1z IGNhbiBiZSBkZXBsb3llZCBpbiBhbnkgSVAgbmV0d29yaywgZXZlbg0KPiA+Pj4+IGluIHRoZSBh YnNlbmNlIG9mIFNSLg0KPiA+Pj4+DQo+ID4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFJvbg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBKdW5pcGVyIEJ1c2luZXNz IFVzZSBPbmx5DQo+ID4+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ Pj4+IEZyb206IFlpbmd6aGVuIFF1IDx5aW5nemhlbi5xdUBmdXR1cmV3ZWkuY29tPg0KPiA+Pj4+ IFNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDMsIDIwMjAgMjowOCBQTQ0KPiA+Pj4+IFRvOiBQZXRl ciBQc2VuYWsgPHBwc2VuYWtAY2lzY28uY29tPjsgR3lhbiBNaXNocmENCj4gPj4+PiA8aGF5YWJ1 c2Fnc21AZ21haWwuY29tPjsgUm9uIEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD4NCj4gPj4+ PiBDYzogbHNyQGlldGYub3JnOyBKZWZmIFRhbnRzdXJhIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNv bT4NCj4gPj4+PiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3INCj4gPj4+PiBkcmFmdC1ib25pY2EtbHNyLWlwLWZsZXhhbGdvLTAwLnR4dA0KPiA+Pj4+ DQo+ID4+Pj4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KPiA+Pj4+ DQo+ID4+Pj4NCj4gPj4+PiBIaSBQZXRlciwNCj4gPj4+Pg0KPiA+Pj4+IFVzaW5nIGZsZXgtYWxn bywgYSBTUnY2IGxvY2F0b3IgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHNpbmdsZQ0KPiA+Pj4+ IGFsZ28sIHdoaWNoIG1lYW5zIGFuIElQdjYgb3IgSVB2NCBhZGRyZXNzIGNhbiBhbHNvIGJlIGFz c29jaWF0ZWQNCj4gPj4+PiB3aXRoIGEgc2luZ2xlIGFsZ28uIFNvIG15IHVuZGVyc3RhbmRpbmcg aXMgUm9uJ3MgcHJvcG9zYWwgaXMgbWFraW5nDQo+ID4+Pj4gdGhlDQo+ID4+IGNvbmZpZ3VyYXRp b24gb2YgZmxleC1hbGdvIGVhc2llcj8NCj4gPj4+PiBJbnN0ZWFkIG9mIHVzaW5nIHRoZSBleGNs dWRlIG9yIGluY2x1ZGUgbGlzdCB5b3UgY2FuIGNvbmZpZ3VyZSBhDQo+ID4+Pj4gbG9vcGJhY2sg YWRkcmVzcyB0byBhIGZsZXgtYWxnbyBkaXJlY3RseT8NCj4gPj4+Pg0KPiA+Pj4+IFRoYW5rcywN Cj4gPj4+PiBZaW5nemhlbg0KPiA+Pj4+DQo+ID4+Pj4gT24gMTAvMy8yMCwgMjo0NyBBTSwgIlBl dGVyIFBzZW5hayIgPHBwc2VuYWtAY2lzY28uY29tPiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+ICAg ICBIaSBZaW5nemhlbiwNCj4gPj4+Pg0KPiA+Pj4+ICAgICBPbiAwMi8xMC8yMDIwIDIyOjE1LCBZ aW5nemhlbiBRdSB3cm90ZToNCj4gPj4+Pj4gSGkgUGV0ZXIsDQo+ID4+Pj4+DQo+ID4+Pj4+IE15 IHVuZGVyc3RhbmRpbmcgb2YgZmxleC1hbGdvIGlzIHRoYXQgZm9yIHRyYWZmaWMgZGVzdGluZWQN Cj4gPj4+PiB0byBhIHByZWZpeCBvbiBhIHBhcnRpY3VsYXIgYWxnbywgaXQgY2FuIG9ubHkgYmUg cm91dGVkIG9uIHJvdXRlcnMNCj4gPj4+PiBiZWxvbmcgdG8gdGhhdCBhbGdvLCB3aGljaCBhbHNv IG1lYW5zIG9ubHkgcm91dGVycyBpbiB0aGF0IGFsZ28NCj4gPj4+PiBjYWxjdWxhdGVzIGhvdyB0 byByZWFjaCB0aGF0IHByZWZpeCBhbmQgaW5zdGFsbCBpdCBpbnRvIHRoZSByb3V0aW5nDQo+ID4+ Pj4gdGFibGUuIEl0IHNlZW1zIHRvIG1lIHRoYXQgdXNpbmcgZmxleC1hbGdvIChzZWN0aW9uIDEy IG9mIHRoZQ0KPiA+Pj4+IGRyYWZ0KSBpdCdzIHBvc3NpYmxlIHRvIGhhdmUgYSBsb29wYmFjayBh ZGRyZXNzIGFzc29jaWF0ZWQgd2l0aA0KPiA+Pj4+IG9ubHkgb25lIGFsZ28sIHBsZWFzZSBjb3Jy ZWN0IG1lIGlmIEknbSBtaXNzaW5nIG9yIG1pc3VuZGVyc3Rvb2QNCj4gc29tZXRoaW5nLg0KPiA+ Pj4+DQo+ID4+Pj4gICAgIHlvdSBhcmUgcmlnaHQuIFRoYXQgaXMgZXhhY3RseSB3aGF0IGlzIGJl aW5nIGRvbmUgZm9yIGZsZXgtYWxnbyB3aXRoDQo+ID4+Pj4gICAgIFNSdjYgLSBsb2NhdG9yIGlz IGFzc29jaWF0ZWQgd2l0aCBhIHNpbmdsZSBhbGdvIG9ubHkuIFRoZSBwcm9wb3NhbA0KPiB1c2Vz DQo+ID4+Pj4gICAgIHRoZSBzYW1lIGNvbmNlcHQuDQo+ID4+Pj4NCj4gPj4+PiAgICAgdGhhbmtz LA0KPiA+Pj4+ICAgICBQZXRlcg0KPiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IFRoYW5rcywNCj4g Pj4+Pj4gWWluZ3poZW4NCj4gPj4+Pj4NCj4gPj4+Pj4gT24gMTAvMi8yMCwgOTo0MyBBTSwgIkxz ciBvbiBiZWhhbGYgb2YgUGV0ZXIgUHNlbmFrIg0KPiA+Pj4+IDxsc3ItYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YNCj4gPj4+PiBwcHNlbmFrPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3Jn Pg0KPiA+Pj4+IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgR3lhbiwNCj4gPj4+Pj4NCj4g Pj4+Pj4gICAgIE9uIDAyLzEwLzIwMjAgMTg6MzAsIEd5YW4gTWlzaHJhIHdyb3RlOg0KPiA+Pj4+ Pj4gQWxsLA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFdpdGggU1J2NiBhbmQgSVAgYmFzZWQgZmxleCBh bGdvIGEgZ2VuZXJpYyBxdWVzdGlvbiBhcyBpdA0KPiA+PiBhcHBsaWVzDQo+ID4+Pj4gdG8NCj4g Pj4+Pj4+IGJvdGguIElzIGl0IHBvc3NpYmxlIHRvIGhhdmUgd2l0aGluIGEgc2luZ2xlIElHUCBk b21haW4NCj4gPj4gZGlmZmVyZW50DQo+ID4+Pj4gc2V0cw0KPiA+Pj4+Pj4gb2Ygbm9kZXMgb3Ig c2VnbWVudHMgb2YgdGhlIG5ldHdvcmsgcnVubmluZyBkaWZmZXJlbnQNCj4gPj4+PiBhbGdvcml0 aG1zLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgYWJzb2x1dGVseS4NCj4gPj4+Pj4NCj4gPj4+Pj4+ IEZyb20NCj4gPj4+Pj4+IGJvdGggZHJhZnRzIGl0IHNvdW5kcyBsaWtlIGFsbCBub2RlcyBoYXZl IHRvIGFncmVlIG9uIHNhbWUNCj4gPj4+PiBhbGdvcml0aG0NCj4gPj4+Pj4+IHNpbWlsYXIgdG8g Y29uY2VwdCBvZiBtZXRyaWMgYW5kIHJlZmVyZW5jZSBiYW5kd2lkdGggYWxsDQo+ID4+IGhhdmUg dG8NCj4gPj4+PiBoYXZlDQo+ID4+Pj4+PiB0aGUgc2FtZSBzdHlsZSBtZXRyaWMgYW5kIHBsYXkg dG8gdGhlIHNhbWUgc2hlZXQgb2YgbXVzaWMuDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICBhbGwgcGFy dGljaXBhdGluZyBub2RlcyBuZWVkIHRvIGFncmVlIG9uIHRoZSBkZWZpbml0aW9uIG9mIHRoZQ0K PiA+Pj4+IGZsZXgtYWxnbw0KPiA+Pj4+PiAgICAgYW5kIGFkdmVydGlzZSB0aGUgcGFydGljaXBh dGlvbi4gVGhhdCdzIGl0Lg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gSWYgdGhlcmUgd2FzDQo+ID4+Pj4+ PiBhIHdheSB0byB1c2UgbXVsdGlwbGUgYWxnb3JpdGhtcyBzaW11bHRhbmVvdXNseSBiYXNlZCBv bg0KPiA+PiBTRkMNCj4gPj4+PiBvciBzZXJ2aWNlcw0KPiA+Pj4+Pj4gYW5kIGluc3RhbnRpYXRp b24gb2Ygc3BlY2lmaWMgYWxnb3JpdGhtIGJhc2VkIG9uIHNlcnZpY2UgdG8NCj4gPj4gYmUNCj4g Pj4+Pj4+IHJlbmRlcmVkLiAgRG9pbmcgc28gd2l0aG91dCBjYXVzaW5nIGEgcm91dGluZyBsb29w IG9yIHN1Yg0KPiA+Pj4+IG9wdGltYWwNCj4gPj4+Pj4+IHJvdXRpbmcuDQo+ID4+Pj4+DQo+ID4+ Pj4+ICAgICB5b3UgY2FuIGNlcnRhaW5seSB1c2UgbXVsdGlwbGUgYWxnb3JpdGhtcyBzaW11bHRh bmVvdXNseSBhbmQNCj4gPj4gdXNlDQo+ID4+Pj4gYWxnbw0KPiA+Pj4+PiAgICAgc3BlY2lmaWMg cGF0aHMgdG8gZm9yd2FyZCBzcGVjaWZpYyB0cmFmZmljIG92ZXIgaXQuIEhvdyB0aGF0DQo+ID4+ Pj4+IGlzDQo+ID4+IGRvbmUNCj4gPj4+Pj4gICAgIGZyb20gdGhlIGZvcndhcmRpbmcgcGVyc3Bl Y3RpdmUgZGVwZW5kcyBpbiB3aGljaA0KPiA+PiBmb3J3YXJkaW5nDQo+ID4+Pj4gcGxhbmUgeW91 DQo+ID4+Pj4+ICAgICB1c2UuIEZsZXgtYWxnbyBjb250cm9sIHBsYW5lIGlzIGluZGVwZW5kZW50 IG9mIHRoZSBmb3J3YXJkaW5nDQo+ID4+Pj4gcGxhbmUuDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+ Pj4+PiBJIHRob3VnaHQgd2l0aCBmbGV4IGFsZ28gdGhhdCB0aGVyZSBleGlzdHMgYSBmZWF0dXJl IHRoYXQgb24gZWFjaA0KPiA+Pj4+Pj4gaG9wIHRoZXJlIGlzIGEgd2F5IHRvIHNwZWNpZnkgd2hp Y2ggYWxnbyB0byB1c2UgaG9wIGJ5DQo+ID4+IGhvcA0KPiA+Pj4+IHNpbWlsYXINCj4gPj4+Pj4+ IHRvIGEgaG9wIGJ5IGhvcCBwb2xpY3kgYmFzZWQgcm91dGluZy4NCj4gPj4+Pj4NCj4gPj4+Pj4g ICAgIG5vLCB0aGVyZSBpcyBubyBob3AtYnktaG9wIGNsYXNzaWZpY2F0aW9uLCB0aGF0IGlzIHBy b2JsZW1hdGljDQo+ID4+IGFuZA0KPiA+Pj4+IGRvZXMNCj4gPj4+Pj4gICAgIG5vdCBzY2FsZSBm b3IgaGlnaCBzcGVlZHMuIENsYXNzaWZpY2F0aW9uIGlzIGRvbmUgYXQgdGhlDQo+ID4+IGluZ3Jl c3Mgb25seS4NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgIHRoYW5rcywNCj4gPj4+Pj4gICAgIFBldGVy DQo+ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4gICAgIExzciBtYWlsaW5n IGxpc3QNCj4gPj4+Pj4gICAgIExzckBpZXRmLm9yZw0KPiA+Pj4+Pg0KPiA+Pj4+IGh0dHBzOi8v dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGwNCj4gPj4+PiBvbw0KPiA+Pj4+IGsuY29tLw0KPiA+Pj4+ID91cmw9aHR0cHMqM0EqMkYqMkZ3 d3cuaWV0Zi5vcmcqMkZtYWlsbWFuKjJGbGlzdGluZm8qMkZsc3ImYW1wO2RhdGENCj4gPj4+PiA9 DQo+ID4+IDANCj4gPj4+PiAyDQo+ID4+Pj4NCj4gPj4NCj4gKjdDMDEqN0N5aW5nemhlbi5xdSo0 MGZ1dHVyZXdlaS5jb20qN0NmZTAzMTI0YzZlNDE0ZTA2N2MyMDA4ZDg2NzgxDQo+ID4+Pj4NCj4g Pj4NCj4gNjU0MSo3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjKjdDMSo3QzAqN0M2 MzczNzMxNTI3Mzk4Ng0KPiA+Pj4+DQo+ID4+DQo+IDUxMjYmYW1wO3NkYXRhPVdJNDhjRUFhbioy Rk9rRFBtVlhHdXJFQWpQSXROR0Y5cDlQRFFJbEQxaXAwZyozRA0KPiA+Pj4+DQo+ID4+DQo+ICZh bXA7cmVzZXJ2ZWQ9MF9fO0pTVWxKU1VsSlNVbEpTVWxKU1VsSlEhIU5FdDZ5TWFPLWdrIVgxZlJs bjlNamltZUpjUg0KPiA+Pj4+IEVVRUl5ZHItOElJYnROb25YTXM4M2VvWHZSd3c2eGthUWZWVWRO aDBrSzQ1MkdQLUckDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+IExz ciBtYWlsaW5nIGxpc3QNCj4gPj4+PiBMc3JAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sDQo+ ID4+Pj4NCj4gc3JfXzshIU5FdDZ5TWFPLWdrIVRlSGdJS000bFVaaGtZbnRfZUZ0M1NzaEdKdGxu OFBUcWhDdVp0T0RvbVVRV0NfDQo+IEgNCj4gPj4+PiB6MjE4Q0U4UzhYemxJeEFBJA0KPiA+Pj4N Cj4gPj4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+IExzciBtYWlsaW5nIGxpc3QNCj4gPj4gTHNyQGlldGYub3JnDQo+ID4+ IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xzcg0KPiA+PiBfDQo+ID4+DQo+IF87ISFORXQ2eU1hTy1nayFUZUhnSUtNNGxV WmhrWW50X2VGdDNTc2hHSnRsbjhQVHFoQ3VadE9Eb21VUVdDX0h6Mg0KPiAxOEMNCj4gPj4gRQ0K PiA+PiA4UzhYemxJeEFBJA0K From nobody Mon Oct 12 00:25:54 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739DC3A12E5 for ; Mon, 12 Oct 2020 00:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 zTU42f5Ogpgc for ; Mon, 12 Oct 2020 00:25:48 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 AE8F13A12E1 for ; Mon, 12 Oct 2020 00:25:48 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id 67so16647357iob.8 for ; Mon, 12 Oct 2020 00:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oc0RI5Xk2pU0WmjI66/xTCtNJEFG4G+Poin80E1+MpE=; b=PQc0afYAkZmKF2PXHU9vXuoK239LCRI3U4z4OKjWyD6MXHdPUN1yPv4qRdC8YPmT5W P9FjtJ+guCkZLRPOf3LfHrU0T5VEATKs5PARA+pdPXchu/2tHmw6h1Z5BdoIygkG9XHh J4gAIfveTR9ao5/ju+e1MTpp7HGqiYJ4O2FvdZhBBB8G76W1ctlhol2y4iSN5rZXAMw/ hUWYYl5iQn0iL04icJNThBsZt9/FkKjV1Ty17WLYUv6G5JqhyrW/Kv8QLVBrdyn7/9E4 KUVBVT8kXUF1IW7mVX+b7aep/MqEDh90LDl3NfkLnGZHZylbS/9Na19hobhZkox1P+T7 H1zQ== 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=oc0RI5Xk2pU0WmjI66/xTCtNJEFG4G+Poin80E1+MpE=; b=G1AqpiiwUVDyN3C4VEmTSLO8qSHm1i8qKy7nH3EZfbM4OtevvBTfciiGa+VFVBrOAQ N09zPVC2kRKg2ThQ/2II9OA2K0hsw6ecXnUYyibMhmgBz1rhMc5PjxIbj2O7yuGbvyGY sqyHQeFFawfmN6yB7aGO8mBjtpnFxQr25L0t0oB22ALNUJlhm3aX2THlMw84V2/CebIv mmCU36+yESvW7kqoQH5q9+mRW9tMNn9GTQl9WpDQpBR8yc1up0uKg9bNxXnngoo5CO4i 55OT5p6AMqAtV84EO4moTsMhwgsLdiC84DhuElhAfyoXliQb3UOXkFVsXNj/19bvC+Hk FyXg== X-Gm-Message-State: AOAM532E4F+rxqUdUQIdYSLDYZkQJgQVxWPfd8TTQbptWjU4mpRJjanE iNTFLuQ8m9s+PPCIgaRSlaefl8Xy2tbq+r91gU4= X-Google-Smtp-Source: ABdhPJzm+cedjDWcU1HaLVsIprwAR9I5dLrwcjzJFoXIiJQx7U7S/qgx5D+EudbNKX50SzU5dm0YQG5NgUj8qPF8hYI= X-Received: by 2002:a5d:8b4a:: with SMTP id c10mr15974584iot.143.1602487547670; Mon, 12 Oct 2020 00:25:47 -0700 (PDT) MIME-Version: 1.0 References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> In-Reply-To: From: Dhruv Dhody Date: Mon, 12 Oct 2020 12:55:10 +0530 Message-ID: To: Gyan Mishra Cc: "Acee Lindem (acee)" , "lsr@ietf.org" , Aijun Wang , Aijun Wang , "Peter Psenak (ppsenak)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 07:25:53 -0000 Hi Gyan, As far as PCE is concerned, we have the inter-AS link information via RFC 5316 and RFC 5392. Both of these include a section on PCE's BRPC procedure for instance. I see you have other use cases, but it would be good to highlight why for the PCE use case the above is deficient. Thanks! Dhruv On Mon, Oct 12, 2020 at 12:49 AM Gyan Mishra wrote: > > > Hi Acee > > I believe what Aijun is trying to explain is that the primary purpose of = PCE for active or passive path computation is for inter-as RSVP-TE PCALC pa= th computation or SR-TE path computation. So PCE is solving a well known P= CALC bin packing problem due to pcalc over subscribing RSVP tunnel bandwidt= h which is inherent an RSVP issue, but a bigger problematic issue is with b= eing able to build an inter-as TE path with a single or multiple PCE contro= llers that can take the LSDB link attributes in the TEDs dB opaque LSAs in = the ospf case and ISIS TE TLVs and rebuild the topology topology from each = TE domain to be able to build a congruent end to end RSVP TE or SR-TE traff= ic steered path instantiation. > > Without the use of PCE controllers as the LSDB link attribute information= is not known as RSVP loose ERO static lsp is built or SR SR-TE prefix sid = loose path is built, failover due to crank back is impacted for reroute, du= e to not having a complete depiction of the other AS Link state topology by= the head end or SR source node. > > So to build that entire end to end inter-as path for that end to end RSVP= TE or SR-TE path instantiation it is critical to indentify the inter-as li= nk eBGP tie link that may have static routes or BGP LU for RSVP head end to= tail end reachability and SR-TE reachability to build out the end to end p= ath instantiation. So the BGP-LS task to rebuild the lsdb topology of eac= h inter connected AS that the RSVP TE or SR-TE steered path traverses, we n= eed the accurate depiction and that includes the Identification of the cri= tical inter-as tie link eBGP peering link that is passive for the PCE path = computation logic for the end to end inter-as path instantiation. > > As for other interfaces using passive in the context of a operator servic= e provider or enterprise core P and PE routers all links are transit with n= eighbors except the inter-as tie so having this new IGP TLV will help to th= at end. In the operator =E2=80=9Ccore=E2=80=9D network if there are other = interfaces that don=E2=80=99t need to be advertised as stub, they can easi= ly be excluded from being added into IGP. > > Kind Regards > > Gyan > > On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) wrote: >> >> Hi Aijun, >> >> >> >> From: Aijun Wang >> Date: Friday, October 9, 2020 at 9:58 PM >> To: Acee Lindem , "Peter Psenak (ppsenak)" , 'Aijun Wang' >> Cc: "lsr@ietf.org" >> Subject: RE: [Lsr] FW: New Version Notification for draft-wang-lsr-passi= ve-interface-attribute-04.txt >> >> >> >> Hi, Acee: >> >> >> >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Ac= ee Lindem (acee) >> Sent: Saturday, October 10, 2020 3:48 AM >> To: Aijun Wang ; Peter Psenak (ppsenak) ; 'Aijun Wang' >> Cc: lsr@ietf.org >> Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passi= ve-interface-attribute-04.txt >> >> >> >> Speaking as WG member: >> >> >> >> Hi Aijun, >> >> >> >> From: Aijun Wang >> Date: Thursday, October 8, 2020 at 11:09 PM >> To: Acee Lindem , "Peter Psenak (ppsenak)" , 'Aijun Wang' >> Cc: "lsr@ietf.org" >> Subject: RE: [Lsr] FW: New Version Notification for draft-wang-lsr-passi= ve-interface-attribute-04.txt >> >> >> >> Hi, Acee: >> >> Sorry for the previous pruned mail. Let's reply you again along your ori= ginal question. >> >> Please see inline.[WAJ] >> >> >> >> -----Original Message----- >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Ac= ee Lindem (acee) >> Sent: Wednesday, September 30, 2020 7:47 PM >> To: Aijun Wang ; Peter Psenak (ppsenak) ; 'Aijun Wang' >> Cc: lsr@ietf.org >> Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passi= ve-interface-attribute-04.txt >> >> >> >> Hi Aijun, >> >> Other than your ill-conceived topology discovery heuristic >> >> [WAJ] The topology discovery heuristic is not suitable for the corner us= e case when the unnumbered interface is used, as explained in https://tools= .ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appendix-B. If you= don=E2=80=99t agree, would you like to illustrate other non-applicable sce= narios? >> >> >> >> Right =E2=80=93 and nobody other than yourself believes the IGPs should = be modified to expose the abstracted topology of an area outside that area. >> >> [WAJ] The modification doesn=E2=80=99t change the way and complexity of= route calculation within IGP. It just piggyback some extra information, th= e bulk of the reconstruction work is done by the controller. Such extra in= formation can also have other usage, as described in https://tools.ietf.org= /html/draft-ietf-lsr-ospf-prefix-originator-06#section-1 >> >> And, the proposal described in https://datatracker.ietf.org/doc/html/dra= ft-wang-lsr-passive-interface-attribute-04 is different with the problem yo= u concerned. It has no relation with the abstracted topology of an area. = Maybe you are confused by these two drafts? >> >> >> >> It is a similar problem. You are still trying to overload the prefix adv= ertisements with a link attribute (passive interface) so that it can be con= veyed outside the domain. We certainly wouldn=E2=80=99t waste a limited pre= fix flag on this parochial application. >> >> >> >> >> >> You can solve the problem with BGP-LS session(s) between the router with= a BGP-LS session to the controller and a router in each area w/o a router= with a BGP-LS session to the controller. >> >> [WAJ] This is possible, but not efficient. For operation, we must also c= onsider the configuration/administration overhead. BGP-LS is designed main= ly for the northbound protocol, not east-west protocol. >> >> >> >> what other possible reason would there be for associating the passive at= tribute with a prefix? >> >> [WAJ] To know the boundary of the IGP domain. After knowing the boundary= , the controller can safely apply and check the network security policy, th= e inbound traffic control policy etc. >> >> >> >> It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How does t= he presence of a prefix associated with a passive interface allow you to ma= ke this deduction? >> >> [WAJ] Passive interfaces are deployed mainly at the boundary of IGP doma= in. Is there any other exception? >> >> While passive interfaces are not standardized, there is nothing that lim= its their usage to an IGP boundary. They can and are deployed on any interf= ace where adjacencies are not to be formed (e.g., a stub subnet containing = hosts). >> >> >> >> Thanks, >> Acee >> >> >> >> Thanks, >> >> Acee >> >> >> >> Thanks, >> >> Acee >> >> >> >> On 9/29/20, 10:39 PM, "Aijun Wang" wrote: >> >> >> >> Hi, Acee and Peter: >> >> Passive interface is mainly used at the edge of the network, where t= he unnumbered interface will not be used. >> >> And the information to flag the passive interfaces is for positionin= g the area boundary, not conflict with the abstract capabilities of the are= a inside. >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> -----Original Message----- >> >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf O= f Acee Lindem (acee) >> >> Sent: Tuesday, September 29, 2020 9:16 PM >> >> To: Peter Psenak ; Aijun Wang = ; 'Aijun Wang' >> >> Cc: lsr@ietf.org >> >> Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-p= assive-interface-attribute-04.txt >> >> >> >> Speaking as WG member: >> >> >> >> Hi Aijun, Peter, >> >> I agree with Peter - one of the main motivations for having areas is= to abstract the topology within the area. Now you're trying to supplant th= is - one topological detail at a time with ill-conceived IGP features. >> >> Thanks, >> >> Acee >> >> >> >> On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" wrote: >> >> >> >> Hi Aijun, >> >> >> >> On 29/09/2020 11:07, Aijun Wang wrote: >> >> > Hi, Peter: >> >> > >> >> > Thanks for your comments. >> >> > 1. For BGP-LS deployment, there normally only be one router th= at within the >> >> > IGP domain to report the topology information, this router sho= uld know such >> >> > passive links which exists mainly on other border routers via = the IGP >> >> > protocol. This is main reason to extension the IGP protocol. >= 2. For the solution, normally, the link within the IGP connect two >> >> ends, but >> >> > passive interface is special and not fall in this space. We ha= ve studied the >> >> > current TLVs that for link, and find no suitable container to = append this >> >> > information. This is the reason that we select the TLVs that a= ssociated with >> >> > Prefix. >> >> >> >> if the link is unnumbered, your solution does not work. As I sai= d, if >> >> you need a knowledge about the link, you can not advertise it as= a prefix. >> >> >> >> thanks, >> >> Peter >> >> >> >> >> >> > >> >> >>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix = LSA", which >> >> > isolate the prefix information that associated with link into = this >> >> > container, contains the stub link, local interface information= etc. Put such >> >> > attribute along with the prefix is then acceptable? >> >> > >> >> > >> >> > Best Regards >> >> > >> >> > Aijun Wang >> >> > China Telecom >> >> > >> >> > -----Original Message----- >> >> > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Be= half Of Peter >> >> > Psenak >> >> > Sent: Tuesday, September 29, 2020 4:29 PM >> >> > To: Aijun Wang >> >> > Cc: lsr@ietf.org >> >> > Subject: Re: [Lsr] FW: New Version Notification for >> >> > draft-wang-lsr-passive-interface-attribute-04.txt >> >> > >> >> > Hi Aijun, >> >> > >> >> > here's my comments: >> >> > >> >> > The purpose of this draft is to advertise passive links. >> >> > >> >> > 1. I'm not sure the problem needs to be solved by IGPs. I tend= to believe >> >> > ietf-idr-bgpls-inter-as-topology-ext is sufficient. >> >> > >> >> > 2. the solution that you proposed is wrong. You are trying to = derive >> >> > topological data about the passive links from the prefix adver= tisement. >> >> > This is semantically incorrect and only works under very speci= fic condition. >> >> > If you need to advertise a link, advertise it as a "special" >> >> > link, not as a "special" prefix. >> >> > >> >> > thanks, >> >> > Peter >> >> > >> >> > On 29/09/2020 03:17, Aijun Wang wrote: >> >> >> Hi, Peter: >> >> >> >> >> >> Would you like to review and give comments on the updates ver= sion of this >> >> > draft? >> >> >> We have also added the protocol extension proposal for OSPFv3= . >> >> >> >> >> >> The update version of this draft can refer to >> >> >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-= interface >> >> >> -attribute >> >> >> Thanks in advance. >> >> >> >> >> >> >> >> >> Best Regards >> >> >> >> >> >> Aijun Wang >> >> >> China Telecom >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.= org] >> >> >>> Sent: Monday, September 28, 2020 3:17 PM >> >> >>> To: Zhibo Hu ; Gyan Mishra >> >> >>> ; Aijun Wang ; >> >> >>> Gyan S. Mishra >> >> >>> Subject: New Version Notification for >> >> >>> draft-wang-lsr-passive-interface-attribute-04.txt >> >> >>> >> >> >>> >> >> >>> A new version of I-D, >> >> >>> draft-wang-lsr-passive-interface-attribute-04.txt >> >> >>> has been successfully submitted by Aijun Wang and posted to = the IETF >> >> >>> repository. >> >> >>> >> >> >>> Name: draft-wang-lsr-passive-interface-attribu= te >> >> >>> Revision: 04 >> >> >>> Title: Passive Interface Attribute >> >> >>> Document date: 2020-09-28 >> >> >>> Group: Individual Submission >> >> >>> Pages: 7 >> >> >>> URL: >> >> >>> https://www.ietf.org/id/draft-wang-lsr-passive-interface-att= ribute-04. >> >> >>> txt >> >> >>> Status: >> >> >>> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-inte= rface-att >> >> >>> r >> >> >>> ibute/ >> >> >>> Htmlized: >> >> >>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive= -interfac >> >> >>> e >> >> >>> -attribut >> >> >>> e >> >> >>> Htmlized: >> >> >>> https://tools.ietf.org/html/draft-wang-lsr-passive-interface= -attribut >> >> >>> e >> >> >>> -04 >> >> >>> Diff: >> >> >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-i= nterface-at >> >> >>> t >> >> >>> ribute-04 >> >> >>> >> >> >>> Abstract: >> >> >>> This document describes the mechanism that can be used = to >> >> >>> differentiate the passive interfaces from the normal in= terfaces >> >> >>> within ISIS or OSPF domain. >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> Please note that it may take a couple of minutes from the ti= me of >> >> >>> submission until the htmlized version and diff are available= at >> >> > tools.ietf.org. >> >> >>> >> >> >>> The IETF Secretariat >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > _______________________________________________ >> >> > Lsr mailing list >> >> > Lsr@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/lsr >> >> > >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> Lsr mailing list >> >> Lsr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> >> _______________________________________________ >> >> Lsr mailing list >> >> Lsr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> >> >> >> _______________________________________________ >> >> Lsr mailing list >> >> Lsr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > -- > > > Gyan Mishra > > Network Solutions Architect > > M 301 502-1347 > 13101 Columbia Pike > Silver Spring, MD > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Mon Oct 12 01:39:22 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1580A3A134D for ; Mon, 12 Oct 2020 01:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so_ZE6cYKE5a for ; Mon, 12 Oct 2020 01:39:19 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9921A3A134F for ; Mon, 12 Oct 2020 01:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9768; q=dns/txt; s=iport; t=1602491958; x=1603701558; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=EAE9EPwV9MKpE98ocMdZm2wx9NTG1kz4u891WM6n4BI=; b=FoFRN1Tur0A5iDe9dWfX8VP/8z14aloirgbsh/APoVUrRPNgiPKgmicM RM6Qf5KLoSg4LoUyLUxNvt8uBi+gpiM0anQtHR91OUvKAkWqH46V26p96 YSAm/upQlrD9giISEXA9TjQA9RcFCSmFqsAzrqDuL+tb20vZThXZnavO9 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpBAAWFYRf/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DGlUBIBIshD2JAodpLooRkCyBaQsBAQEPGAsMBAEBhEo?= =?us-ascii?q?CghcmOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgEBASEVNgkCDAQLEQQ?= =?us-ascii?q?BAQECAiMDAgIhBh8JCAYBDAYCAQGDIgGCSwMOIA+mGHaBMoVUgjgNYoE8BoE?= =?us-ascii?q?OKokkhC2BQT+BESeCaT6CGkIBAQKBKAESASGDF4JgBJAAKwmCVYkCikGQQlK?= =?us-ascii?q?CcoMVhWyMXYR/BQcDH4MVigiFGY8EkyKKcYJsknCBayNncDMaCBsVO4JpUBk?= =?us-ascii?q?NjisXg06FFIVEPwMwAgE0AgYKAQEDCY5IAQE?= X-IronPort-AV: E=Sophos;i="5.77,366,1596499200"; d="scan'208";a="30222357" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2020 08:39:14 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 09C8dDGi031936; Mon, 12 Oct 2020 08:39:14 GMT To: "Dongjie (Jimmy)" , Ron Bonica , Yingzhen Qu , Gyan Mishra Cc: "lsr@ietf.org" , Jeff Tantsura References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> From: Peter Psenak Message-ID: <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> Date: Mon, 12 Oct 2020 10:39:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 08:39:21 -0000 Hi Jimmy, On 10/10/2020 05:05, Dongjie (Jimmy) wrote: > Hi Peter, > > Thanks for your reply. It aligns with my understanding of FAD, which is just a set of constraints for path computation. Thus one Flex-Algo ID could be used with multiple different data planes. Is this understanding correct? correct. > > If so, my question is about the scenario below: > > A group of nodes in a network support FA-128, a sub-group of them bind FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. just to use the correct terminology, we should use "participate" instead of "support". >When one node compute an SR path to a destination, can it compute the path to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes >which bind FA-128 to IP address? If so, how could this node know the binding of FA to different data planes on other nodes? again, it is the participation problem. Nodes that participate in the SR Flex-algo 128 will advertise the participation using the SR-Algorithm Sub-TLV. Only these nodes will be used during the SR flex-algo computation for algo 128. Nodes that participate in IP flex-algo 128 will advertise the participation using the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP flex-algo computation for algo 128. thanks, Peter > > Best regards, > Jie > >> -----Original Message----- >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak >> Sent: Friday, October 9, 2020 11:58 PM >> To: Dongjie (Jimmy) ; Ron Bonica >> ; Yingzhen Qu >> ; Gyan Mishra >> Cc: lsr@ietf.org; Jeff Tantsura >> Subject: Re: [Lsr] FW: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> >> Hi Jimmy, >> >> >> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: >>> Hi Ron, >>> >>> Thanks for explaining the difference between IP Flex-Algo and SR Flex-algo. As >> you said, the major difference is the data plane. >>> >>> If my understanding is correct, for one Flex-Algo to be used correctly, the set >> of nodes need to apply consistent constraints in computation, and bind the FAD >> to the same data plane. >>> >>> Is it possible that different nodes may use the same Flex-Algo with different >> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure IP >> etc., or each Flex-Algo is always associated with only one data plane? In the >> former case, should the flex-algo definition also indicate the data plane(s) to be >> used with the flex-algo? >> >> let me respond to this query, as this is not specific to Ron's draft. >> >> FAD is data plane agnostic and is used by all of them. >> >> thanks, >> Peter >> >>> >>> Best regards, >>> Jie >>> >>>> -----Original Message----- >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >>>> Sent: Sunday, October 4, 2020 4:34 AM >>>> To: Yingzhen Qu ; Peter Psenak >>>> ; Gyan Mishra >>>> Cc: lsr@ietf.org; Jeff Tantsura >>>> Subject: Re: [Lsr] FW: New Version Notification for >>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>> >>>> Hi Yingzhen, >>>> >>>> IP Flexible Algorithms are like SR Flexible Algorithms in the following >> respects: >>>> >>>> - Links have IGP metrics, TE metrics, delay metrics and >>>> administrative colors >>>> - FADs define Flexible Algorithms >>>> >>>> More specifically, the FAD: >>>> >>>> - Indicates which metric type the Flexible Algorithm uses >>>> - Specifies constraints in terms of link colors that are included or >>>> excluded from the Flexible Algorithm. >>>> >>>> The significant difference between IP Flexible Algorithms and SR >>>> Flexible Algorithms is: >>>> >>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators >>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. >>>> >>>> So, IP Flexible Algorithms can be deployed in any IP network, even in >>>> the absence of SR. >>>> >>>> Ron >>>> >>>> >>>> Juniper Business Use Only >>>> >>>> -----Original Message----- >>>> From: Yingzhen Qu >>>> Sent: Saturday, October 3, 2020 2:08 PM >>>> To: Peter Psenak ; Gyan Mishra >>>> ; Ron Bonica >>>> Cc: lsr@ietf.org; Jeff Tantsura >>>> Subject: Re: [Lsr] FW: New Version Notification for >>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>> >>>> [External Email. Be cautious of content] >>>> >>>> >>>> Hi Peter, >>>> >>>> Using flex-algo, a SRv6 locator can be associated with a single algo, >>>> which means an IPv6 or IPv4 address can also be associated with a >>>> single algo. So my understanding is Ron's proposal is making the >> configuration of flex-algo easier? >>>> Instead of using the exclude or include list you can configure a >>>> loopback address to a flex-algo directly? >>>> >>>> Thanks, >>>> Yingzhen >>>> >>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: >>>> >>>> Hi Yingzhen, >>>> >>>> On 02/10/2020 22:15, Yingzhen Qu wrote: >>>> > Hi Peter, >>>> > >>>> > My understanding of flex-algo is that for traffic destined to >>>> a prefix on a particular algo, it can only be routed on routers >>>> belong to that algo, which also means only routers in that algo >>>> calculates how to reach that prefix and install it into the routing >>>> table. It seems to me that using flex-algo (section 12 of the >>>> draft) it's possible to have a loopback address associated with only >>>> one algo, please correct me if I'm missing or misunderstood something. >>>> >>>> you are right. That is exactly what is being done for flex-algo with >>>> SRv6 - locator is associated with a single algo only. The proposal uses >>>> the same concept. >>>> >>>> thanks, >>>> Peter >>>> >>>> > >>>> > Thanks, >>>> > Yingzhen >>>> > >>>> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >>>> >>> ppsenak=40cisco.com@dmarc.ietf.org> >>>> wrote: >>>> > >>>> > Gyan, >>>> > >>>> > On 02/10/2020 18:30, Gyan Mishra wrote: >>>> > > All, >>>> > > >>>> > > With SRv6 and IP based flex algo a generic question as it >> applies >>>> to >>>> > > both. Is it possible to have within a single IGP domain >> different >>>> sets >>>> > > of nodes or segments of the network running different >>>> algorithms. >>>> > >>>> > absolutely. >>>> > >>>> > > From >>>> > > both drafts it sounds like all nodes have to agree on same >>>> algorithm >>>> > > similar to concept of metric and reference bandwidth all >> have to >>>> have >>>> > > the same style metric and play to the same sheet of music. >>>> > >>>> > all participating nodes need to agree on the definition of the >>>> flex-algo >>>> > and advertise the participation. That's it. >>>> > >>>> > > If there was >>>> > > a way to use multiple algorithms simultaneously based on >> SFC >>>> or services >>>> > > and instantiation of specific algorithm based on service to >> be >>>> > > rendered. Doing so without causing a routing loop or sub >>>> optimal >>>> > > routing. >>>> > >>>> > you can certainly use multiple algorithms simultaneously and >> use >>>> algo >>>> > specific paths to forward specific traffic over it. How that is >> done >>>> > from the forwarding perspective depends in which >> forwarding >>>> plane you >>>> > use. Flex-algo control plane is independent of the forwarding >>>> plane. >>>> > >>>> > >>>> > >I thought with flex algo that there exists a feature that on >>>> > > each hop there is a way to specify which algo to use hop by >> hop >>>> similar >>>> > > to a hop by hop policy based routing. >>>> > >>>> > no, there is no hop-by-hop classification, that is problematic >> and >>>> does >>>> > not scale for high speeds. Classification is done at the >> ingress only. >>>> > >>>> > thanks, >>>> > Peter >>>> > >>>> > > >>>> > >>>> > _______________________________________________ >>>> > Lsr mailing list >>>> > Lsr@ietf.org >>>> > >>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outloo >>>> k.com/ >>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data= >> 0 >>>> 2 >>>> >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 >>>> >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >>>> >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D >>>> >> &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR >>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ >>>> > >>>> > >>>> > >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > From nobody Mon Oct 12 01:41:24 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12203A136F for ; Mon, 12 Oct 2020 01:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7fAvyQjr8YF for ; Mon, 12 Oct 2020 01:41:13 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A18B3A1357 for ; Mon, 12 Oct 2020 01:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10391; q=dns/txt; s=iport; t=1602492073; x=1603701673; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yB9siZTDkblQ9YDN5s00a2k4axHe+8c63Mjq9qhZz2A=; b=Y5pSPs5JSiBg7t1aYXaOeuz61MKes2D2Ehxn/e+rI6/VjJlGARVNLgmy 5orIKRj+Wm6tZInoVPgPfjG/TAW+hwvwyUZgbUF1q/s2QOtDSIp4g0ZP4 /uXM3A6M1km4CNZR19AOEJ2CV7/WAzZjCZ/O0qGRxsWG7mJ5iPyVNsEIz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArBQCaFYRf/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DGlUBIBIshD2JAodqCCaKEZAsgWkLAQEBDxgLDAQBAYR?= =?us-ascii?q?KAoIXJjgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQIBAQEhFTYJAgwECw4?= =?us-ascii?q?DBAEBAQICIwMCAiEGHwkIBgEMBgIBAYMiAYJLAw4gD6YTdoEyhVSCNw1igTw?= =?us-ascii?q?GgQ4qjVGBQT+BEScMgl0+ghpCAQECgSgBEgEhgxeCYASQACsJglWJApsDUoJ?= =?us-ascii?q?ygxWFbIxdhH8FBwMfgxWKCIUZjwSTIopxgmyScIFrI2dwMxoIGxU7gmlQGQ2?= =?us-ascii?q?OKxeDToUUhUQ/AzACATQCBgoBAQMJjkgBAQ?= X-IronPort-AV: E=Sophos;i="5.77,366,1596499200"; d="scan'208";a="30281606" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2020 08:41:09 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 09C8f8fg005187; Mon, 12 Oct 2020 08:41:08 GMT To: Ron Bonica , "Dongjie (Jimmy)" , Yingzhen Qu , Gyan Mishra Cc: "lsr@ietf.org" , Jeff Tantsura References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> From: Peter Psenak Message-ID: Date: Mon, 12 Oct 2020 10:41:08 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 08:41:23 -0000 Ho Ron, On 10/10/2020 14:47, Ron Bonica wrote: > Hi Jimmie, > > Inline..... > > Ron > > > Juniper Business Use Only > > -----Original Message----- > From: Dongjie (Jimmy) > Sent: Friday, October 9, 2020 11:06 PM > To: Peter Psenak ; Ron Bonica ; Yingzhen Qu ; Gyan Mishra > Cc: lsr@ietf.org; Jeff Tantsura > Subject: RE: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt > > [External Email. Be cautious of content] > > > Hi Peter, > > Thanks for your reply. It aligns with my understanding of FAD, which is just a set of constraints for path computation. Thus one Flex-Algo ID could be used with multiple different data planes. Is this understanding correct? > > [RB] I never thought about this. Is there a use-case? I think that it will work, but I would have to try it before saying for sure. yes, this works fine. > > If so, my question is about the scenario below: > > A group of nodes in a network support FA-128, a sub-group of them bind FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When one node compute an SR path to a destination, can it compute the path to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind FA-128 to IP address? > > [RB] I don't think so. However, you could achieve the same outcome using link colors. please see my response to the Jimmy. thanks, Peter > > If so, how could this node know the binding of FA to different data planes on other nodes? > > Best regards, > Jie > >> -----Original Message----- >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak >> Sent: Friday, October 9, 2020 11:58 PM >> To: Dongjie (Jimmy) ; Ron Bonica >> ; Yingzhen Qu >> ; Gyan Mishra >> Cc: lsr@ietf.org; Jeff Tantsura >> Subject: Re: [Lsr] FW: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> >> Hi Jimmy, >> >> >> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: >>> Hi Ron, >>> >>> Thanks for explaining the difference between IP Flex-Algo and SR >>> Flex-algo. As >> you said, the major difference is the data plane. >>> >>> If my understanding is correct, for one Flex-Algo to be used >>> correctly, the set >> of nodes need to apply consistent constraints in computation, and bind >> the FAD to the same data plane. >>> >>> Is it possible that different nodes may use the same Flex-Algo with >>> different >> data plane, e.g. some with SR-MPLS, some with SRv6, and some with pure >> IP etc., or each Flex-Algo is always associated with only one data >> plane? In the former case, should the flex-algo definition also >> indicate the data plane(s) to be used with the flex-algo? >> >> let me respond to this query, as this is not specific to Ron's draft. >> >> FAD is data plane agnostic and is used by all of them. >> >> thanks, >> Peter >> >>> >>> Best regards, >>> Jie >>> >>>> -----Original Message----- >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >>>> Sent: Sunday, October 4, 2020 4:34 AM >>>> To: Yingzhen Qu ; Peter Psenak >>>> ; Gyan Mishra >>>> Cc: lsr@ietf.org; Jeff Tantsura >>>> Subject: Re: [Lsr] FW: New Version Notification for >>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>> >>>> Hi Yingzhen, >>>> >>>> IP Flexible Algorithms are like SR Flexible Algorithms in the >>>> following >> respects: >>>> >>>> - Links have IGP metrics, TE metrics, delay metrics and >>>> administrative colors >>>> - FADs define Flexible Algorithms >>>> >>>> More specifically, the FAD: >>>> >>>> - Indicates which metric type the Flexible Algorithm uses >>>> - Specifies constraints in terms of link colors that are included >>>> or excluded from the Flexible Algorithm. >>>> >>>> The significant difference between IP Flexible Algorithms and SR >>>> Flexible Algorithms is: >>>> >>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators >>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. >>>> >>>> So, IP Flexible Algorithms can be deployed in any IP network, even >>>> in the absence of SR. >>>> >>>> Ron >>>> >>>> >>>> Juniper Business Use Only >>>> >>>> -----Original Message----- >>>> From: Yingzhen Qu >>>> Sent: Saturday, October 3, 2020 2:08 PM >>>> To: Peter Psenak ; Gyan Mishra >>>> ; Ron Bonica >>>> Cc: lsr@ietf.org; Jeff Tantsura >>>> Subject: Re: [Lsr] FW: New Version Notification for >>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>> >>>> [External Email. Be cautious of content] >>>> >>>> >>>> Hi Peter, >>>> >>>> Using flex-algo, a SRv6 locator can be associated with a single >>>> algo, which means an IPv6 or IPv4 address can also be associated >>>> with a single algo. So my understanding is Ron's proposal is making >>>> the >> configuration of flex-algo easier? >>>> Instead of using the exclude or include list you can configure a >>>> loopback address to a flex-algo directly? >>>> >>>> Thanks, >>>> Yingzhen >>>> >>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: >>>> >>>> Hi Yingzhen, >>>> >>>> On 02/10/2020 22:15, Yingzhen Qu wrote: >>>> > Hi Peter, >>>> > >>>> > My understanding of flex-algo is that for traffic destined >>>> to a prefix on a particular algo, it can only be routed on routers >>>> belong to that algo, which also means only routers in that algo >>>> calculates how to reach that prefix and install it into the routing >>>> table. It seems to me that using flex-algo (section 12 of the >>>> draft) it's possible to have a loopback address associated with >>>> only one algo, please correct me if I'm missing or misunderstood something. >>>> >>>> you are right. That is exactly what is being done for flex-algo with >>>> SRv6 - locator is associated with a single algo only. The proposal uses >>>> the same concept. >>>> >>>> thanks, >>>> Peter >>>> >>>> > >>>> > Thanks, >>>> > Yingzhen >>>> > >>>> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >>>> >>> ppsenak=40cisco.com@dmarc.ietf.org> >>>> wrote: >>>> > >>>> > Gyan, >>>> > >>>> > On 02/10/2020 18:30, Gyan Mishra wrote: >>>> > > All, >>>> > > >>>> > > With SRv6 and IP based flex algo a generic question as it >> applies >>>> to >>>> > > both. Is it possible to have within a single IGP domain >> different >>>> sets >>>> > > of nodes or segments of the network running different >>>> algorithms. >>>> > >>>> > absolutely. >>>> > >>>> > > From >>>> > > both drafts it sounds like all nodes have to agree on same >>>> algorithm >>>> > > similar to concept of metric and reference bandwidth all >> have to >>>> have >>>> > > the same style metric and play to the same sheet of music. >>>> > >>>> > all participating nodes need to agree on the definition of the >>>> flex-algo >>>> > and advertise the participation. That's it. >>>> > >>>> > > If there was >>>> > > a way to use multiple algorithms simultaneously based on >> SFC >>>> or services >>>> > > and instantiation of specific algorithm based on service to >> be >>>> > > rendered. Doing so without causing a routing loop or sub >>>> optimal >>>> > > routing. >>>> > >>>> > you can certainly use multiple algorithms simultaneously and >> use >>>> algo >>>> > specific paths to forward specific traffic over it. How that is >> done >>>> > from the forwarding perspective depends in which >> forwarding >>>> plane you >>>> > use. Flex-algo control plane is independent of the forwarding >>>> plane. >>>> > >>>> > >>>> > >I thought with flex algo that there exists a feature that on >>>> > > each hop there is a way to specify which algo to use hop by >> hop >>>> similar >>>> > > to a hop by hop policy based routing. >>>> > >>>> > no, there is no hop-by-hop classification, that is problematic >> and >>>> does >>>> > not scale for high speeds. Classification is done at the >> ingress only. >>>> > >>>> > thanks, >>>> > Peter >>>> > >>>> > > >>>> > >>>> > _______________________________________________ >>>> > Lsr mailing list >>>> > Lsr@ietf.org >>>> > >>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl >>>> oo >>>> k.com/ >>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data >>>> = >> 0 >>>> 2 >>>> >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 >>>> >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >>>> >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D >>>> >> &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR >>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ >>>> > >>>> > >>>> > >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_H >>>> z218CE8S8XzlIxAA$ >>> >>> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ >> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218CE >> 8S8XzlIxAA$ > > From nobody Mon Oct 12 01:47:38 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9F3A1362 for ; Mon, 12 Oct 2020 01:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20btX0pzHD6r for ; Mon, 12 Oct 2020 01:47:33 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A8233A1357 for ; Mon, 12 Oct 2020 01:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12126; q=dns/txt; s=iport; t=1602492453; x=1603702053; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ju9jQonx+RBVgzI8Bs0qVm9lQzEGHDnXorOsY9AZ71o=; b=FHqhj8s3x7NgRdZBg99sdcep7JCm1t0lwVGcoJt+MR8hTw+g1/3jqKvg HRr/meRmLmzumAv/YWm7j8gdbuREikRF3UXq+e3eGW4ePDuHayxHZciAa Vn/ibCAAdQRSoBgYUJgki8+/2l8bWwri7YrtLVzaobY/KkDJ7uJddfGY1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqBQAIF4Rf/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DGlUBIBIshD2JAodpCCaKEZAsgWkLAQEBDxgLDAQBAYR?= =?us-ascii?q?KAoIXJjgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQIBAQEhFTYJAgwECxE?= =?us-ascii?q?EAQEBAgIjAwICIQYfCQgGAQwGAgEBgyIBgksDDiAPpht2gTKFVII2DWKBPAa?= =?us-ascii?q?BDiqHZoVrgUE/gREnDIJdPoIaQgEBAoEoARIBIYMXgmAEkAArCYJViQKKQZB?= =?us-ascii?q?CUoJygxWFbIxdhH8FBwMfgxWKCIUZjwSTIopxgmyScIFrI2dwMxoIGxU7gml?= =?us-ascii?q?QGQ2OKxeDToUUhUQ/AzACATQCBgoBAQMJjkgBAQ?= X-IronPort-AV: E=Sophos;i="5.77,366,1596499200"; d="scan'208";a="30284111" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2020 08:47:28 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 09C8lS6U015880; Mon, 12 Oct 2020 08:47:28 GMT To: "Dongjie (Jimmy)" , Jeff Tantsura , Ron Bonica Cc: Yingzhen Qu , Gyan Mishra , "lsr@ietf.org" References: <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.com> From: Peter Psenak Message-ID: Date: Mon, 12 Oct 2020 10:47:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 08:47:36 -0000 Hi Jimmy. On 12/10/2020 09:12, Dongjie (Jimmy) wrote: > Hi Jeff, > > Thanks for your explanation. I understand that for different data plane the SIDs or IP addresses have different scope, and will not conflict in normal cases. > > My question is more about whether a computation node needs to know and check which data plane is used by the intermediate nodes to bind to the Flex-Algo? In another word, can an SR path computed using Flex-Algo 128 go through an intermediate node which bind Flex-Algo 128 to IP data plane? computation node MUST check the application specific participation in flex-algo and participation advertisement is application specific. SR and IP are different applications from flex-algo perspective. draft-ietf-lsr-flex-algo-12, section 10.2: Application-specific advertisement for Flex-Algorithm participation MUST be defined for each application thanks, Peter > > Best regards, > Jie > >> -----Original Message----- >> From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com] >> Sent: Sunday, October 11, 2020 3:14 AM >> To: Ron Bonica >> Cc: Dongjie (Jimmy) ; Peter Psenak >> ; Yingzhen Qu ; Gyan >> Mishra ; lsr@ietf.org >> Subject: Re: [Lsr] FW: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> >> Jie, >> >> The scoop is different, for SR data plane entry uniqueness is in context of SR >> domain (SID = value + context), while for IP it is global to the routing domain, >> FIB entry is a destination, nothing more. >> >> Regards, >> Jeff >> >>> On Oct 10, 2020, at 05:47, Ron Bonica wrote: >>> >>> Hi Jimmie, >>> >>> Inline..... >>> >>> Ron >>> >>> >>> Juniper Business Use Only >>> >>> -----Original Message----- >>> From: Dongjie (Jimmy) >>> Sent: Friday, October 9, 2020 11:06 PM >>> To: Peter Psenak ; Ron Bonica >>> ; Yingzhen Qu ; Gyan >>> Mishra >>> Cc: lsr@ietf.org; Jeff Tantsura >>> Subject: RE: [Lsr] FW: New Version Notification for >>> draft-bonica-lsr-ip-flexalgo-00.txt >>> >>> [External Email. Be cautious of content] >>> >>> >>> Hi Peter, >>> >>> Thanks for your reply. It aligns with my understanding of FAD, which is just a >> set of constraints for path computation. Thus one Flex-Algo ID could be used >> with multiple different data planes. Is this understanding correct? >>> >>> [RB] I never thought about this. Is there a use-case? I think that it will work, >> but I would have to try it before saying for sure. >>> >>> If so, my question is about the scenario below: >>> >>> A group of nodes in a network support FA-128, a sub-group of them bind >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. When >> one node compute an SR path to a destination, can it compute the path to only >> pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which bind >> FA-128 to IP address? >>> >>> [RB] I don't think so. However, you could achieve the same outcome using link >> colors. >>> >>> If so, how could this node know the binding of FA to different data planes on >> other nodes? >>> >>> Best regards, >>> Jie >>> >>>> -----Original Message----- >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak >>>> Sent: Friday, October 9, 2020 11:58 PM >>>> To: Dongjie (Jimmy) ; Ron Bonica >>>> ; Yingzhen Qu >>>> ; Gyan Mishra >>>> Cc: lsr@ietf.org; Jeff Tantsura >>>> Subject: Re: [Lsr] FW: New Version Notification for >>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>> >>>> Hi Jimmy, >>>> >>>> >>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: >>>>> Hi Ron, >>>>> >>>>> Thanks for explaining the difference between IP Flex-Algo and SR >>>>> Flex-algo. As >>>> you said, the major difference is the data plane. >>>>> >>>>> If my understanding is correct, for one Flex-Algo to be used >>>>> correctly, the set >>>> of nodes need to apply consistent constraints in computation, and >>>> bind the FAD to the same data plane. >>>>> >>>>> Is it possible that different nodes may use the same Flex-Algo with >>>>> different >>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with >>>> pure IP etc., or each Flex-Algo is always associated with only one >>>> data plane? In the former case, should the flex-algo definition also >>>> indicate the data plane(s) to be used with the flex-algo? >>>> >>>> let me respond to this query, as this is not specific to Ron's draft. >>>> >>>> FAD is data plane agnostic and is used by all of them. >>>> >>>> thanks, >>>> Peter >>>> >>>>> >>>>> Best regards, >>>>> Jie >>>>> >>>>>> -----Original Message----- >>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >>>>>> Sent: Sunday, October 4, 2020 4:34 AM >>>>>> To: Yingzhen Qu ; Peter Psenak >>>>>> ; Gyan Mishra >>>>>> Cc: lsr@ietf.org; Jeff Tantsura >>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>>> >>>>>> Hi Yingzhen, >>>>>> >>>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the >>>>>> following >>>> respects: >>>>>> >>>>>> - Links have IGP metrics, TE metrics, delay metrics and >>>>>> administrative colors >>>>>> - FADs define Flexible Algorithms >>>>>> >>>>>> More specifically, the FAD: >>>>>> >>>>>> - Indicates which metric type the Flexible Algorithm uses >>>>>> - Specifies constraints in terms of link colors that are included >>>>>> or excluded from the Flexible Algorithm. >>>>>> >>>>>> The significant difference between IP Flexible Algorithms and SR >>>>>> Flexible Algorithms is: >>>>>> >>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators >>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. >>>>>> >>>>>> So, IP Flexible Algorithms can be deployed in any IP network, even >>>>>> in the absence of SR. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> Juniper Business Use Only >>>>>> >>>>>> -----Original Message----- >>>>>> From: Yingzhen Qu >>>>>> Sent: Saturday, October 3, 2020 2:08 PM >>>>>> To: Peter Psenak ; Gyan Mishra >>>>>> ; Ron Bonica >>>>>> Cc: lsr@ietf.org; Jeff Tantsura >>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>>> >>>>>> [External Email. Be cautious of content] >>>>>> >>>>>> >>>>>> Hi Peter, >>>>>> >>>>>> Using flex-algo, a SRv6 locator can be associated with a single >>>>>> algo, which means an IPv6 or IPv4 address can also be associated >>>>>> with a single algo. So my understanding is Ron's proposal is making >>>>>> the >>>> configuration of flex-algo easier? >>>>>> Instead of using the exclude or include list you can configure a >>>>>> loopback address to a flex-algo directly? >>>>>> >>>>>> Thanks, >>>>>> Yingzhen >>>>>> >>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: >>>>>> >>>>>> Hi Yingzhen, >>>>>> >>>>>> On 02/10/2020 22:15, Yingzhen Qu wrote: >>>>>>> Hi Peter, >>>>>>> >>>>>>> My understanding of flex-algo is that for traffic destined >>>>>> to a prefix on a particular algo, it can only be routed on routers >>>>>> belong to that algo, which also means only routers in that algo >>>>>> calculates how to reach that prefix and install it into the routing >>>>>> table. It seems to me that using flex-algo (section 12 of the >>>>>> draft) it's possible to have a loopback address associated with >>>>>> only one algo, please correct me if I'm missing or misunderstood >> something. >>>>>> >>>>>> you are right. That is exactly what is being done for flex-algo with >>>>>> SRv6 - locator is associated with a single algo only. The proposal >> uses >>>>>> the same concept. >>>>>> >>>>>> thanks, >>>>>> Peter >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Yingzhen >>>>>>> >>>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >>>>>> >>>>> ppsenak=40cisco.com@dmarc.ietf.org> >>>>>> wrote: >>>>>>> >>>>>>> Gyan, >>>>>>> >>>>>>> On 02/10/2020 18:30, Gyan Mishra wrote: >>>>>>>> All, >>>>>>>> >>>>>>>> With SRv6 and IP based flex algo a generic question as it >>>> applies >>>>>> to >>>>>>>> both. Is it possible to have within a single IGP domain >>>> different >>>>>> sets >>>>>>>> of nodes or segments of the network running different >>>>>> algorithms. >>>>>>> >>>>>>> absolutely. >>>>>>> >>>>>>>> From >>>>>>>> both drafts it sounds like all nodes have to agree on same >>>>>> algorithm >>>>>>>> similar to concept of metric and reference bandwidth all >>>> have to >>>>>> have >>>>>>>> the same style metric and play to the same sheet of music. >>>>>>> >>>>>>> all participating nodes need to agree on the definition of the >>>>>> flex-algo >>>>>>> and advertise the participation. That's it. >>>>>>> >>>>>>>> If there was >>>>>>>> a way to use multiple algorithms simultaneously based on >>>> SFC >>>>>> or services >>>>>>>> and instantiation of specific algorithm based on service to >>>> be >>>>>>>> rendered. Doing so without causing a routing loop or sub >>>>>> optimal >>>>>>>> routing. >>>>>>> >>>>>>> you can certainly use multiple algorithms simultaneously and >>>> use >>>>>> algo >>>>>>> specific paths to forward specific traffic over it. How that >>>>>>> is >>>> done >>>>>>> from the forwarding perspective depends in which >>>> forwarding >>>>>> plane you >>>>>>> use. Flex-algo control plane is independent of the forwarding >>>>>> plane. >>>>>>> >>>>>>> >>>>>>>> I thought with flex algo that there exists a feature that on each >>>>>>>> hop there is a way to specify which algo to use hop by >>>> hop >>>>>> similar >>>>>>>> to a hop by hop policy based routing. >>>>>>> >>>>>>> no, there is no hop-by-hop classification, that is problematic >>>> and >>>>>> does >>>>>>> not scale for high speeds. Classification is done at the >>>> ingress only. >>>>>>> >>>>>>> thanks, >>>>>>> Peter >>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Lsr mailing list >>>>>>> Lsr@ietf.org >>>>>>> >>>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl >>>>>> oo >>>>>> k.com/ >>>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data >>>>>> = >>>> 0 >>>>>> 2 >>>>>> >>>> >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 >>>>>> >>>> >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >>>>>> >>>> >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D >>>>>> >>>> >> &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR >>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>>>> >> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_ >> H >>>>>> z218CE8S8XzlIxAA$ >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >>>> _ >>>> >> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz2 >> 18C >>>> E >>>> 8S8XzlIxAA$ > > From nobody Mon Oct 12 04:50:22 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6154F3A0E7D for ; Mon, 12 Oct 2020 04:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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 (2048-bit key) header.d=raszuk.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 kab7Un-wUm32 for ; Mon, 12 Oct 2020 04:50:18 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 2BC8A3A0E79 for ; Mon, 12 Oct 2020 04:50:17 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id i5so16610213edr.5 for ; Mon, 12 Oct 2020 04:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kbXvWznQC8c5BT0mE5b9XbafiL99VXVzelB7mJga4uM=; b=G81iRMJbHkdtVEJajjgEoLpklouoxoJ2mKumi7wC7A5+Kf2Tf1vJ5bd/ATk4K1z+Db o7Q0QHml7NX+XYVvy0sgfTScvcB2JB5snaaQ5kB+WCPRN+iMRPmtvAJBDULZTgkoznKf dPo8RNrucwH5DQC+fb/s+DPvtKIScu7LbJAMdehKoYF/7gk1SGmEq7GMoeamTfC4cuzC lCN7LnoArS8rskKgoAKndmdkuFXWpZY6nSGJDcL7smatDI7PhMOj2RNLOulmTb/8+tpI Ob7FSimIGexBerL/eA4tXwJnKFiLCwjSjdjBpoo9hYLRbIBw8y61L8mklt0adScLRjoA l5jQ== 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=kbXvWznQC8c5BT0mE5b9XbafiL99VXVzelB7mJga4uM=; b=LS5gg3kX/fOoTEomthXT2TnopoaeFq/qDt6OE+Gtxf0hHVRJLMdKZLaRe9Qds8U2uL 1c3qElrELU1n29K7mJerIIZH9/p/TqCvj8tK5n68ubnH3IxjmYzK1eZ4wsj0AAiTWMtx yi6Xmz0xO6XfUXC4K8zoirSANIVwbpQ0FzwmEO9v5vV2b00HUxZm0mCI2ItkM9Wta5fY jamDCEfKrsgPm9qh2FaUfndOcYlf2ccvEfwpvSc476Plt7f/Ev6i2+CebhBiRxq+45sG xSVNMGVDNkBIFcF4EX4sxKTxq84Jfaz1trOSgkijFjGsKb96dsa4/vIHWa5HjfiNaGVt HtGw== X-Gm-Message-State: AOAM533DIes4p1xKZvYWX8TiDOXlDvr+QBlyf5kQEwTGoMMw32zREbzp y1vPBwcIJBqyMMBx3wjlLR/f090vNZ6ccHakFltfJZxGbxI= X-Google-Smtp-Source: ABdhPJxqEMd7bO3y7aKmI0KL8Ka6EtEsdoncP6M4yozvKHCcUL6MAY0OjEEWNon5nX59RiUQc8Kxqv1j1QptodJyd+o= X-Received: by 2002:a05:6402:b8f:: with SMTP id cf15mr13951012edb.369.1602503416146; Mon, 12 Oct 2020 04:50:16 -0700 (PDT) MIME-Version: 1.0 References: <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.com> In-Reply-To: From: Robert Raszuk Date: Mon, 12 Oct 2020 13:50:10 +0200 Message-ID: To: Peter Psenak Cc: "Dongjie (Jimmy)" , Jeff Tantsura , Ron Bonica , "lsr@ietf.org" , Gyan Mishra , Yingzhen Qu Content-Type: multipart/alternative; boundary="000000000000df09e905b177e63a" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 11:50:21 -0000 --000000000000df09e905b177e63a Content-Type: text/plain; charset="UTF-8" Hey Peter, To me the application here is "avoid red links" regardless of choice of encap in the data plane. Does it really make sense to separate advertisements of SR flex-algo vs IP flex-algo into separate TLVs ? Along the same linkes even for SR data plane can be SR-MPLS or SRv6. So in the network running all three data planes you will need to compute SPT for each flex-algo three times which may or may not be desired especially if each algorithm would be as simple as to avoid certain link color. That goes to the point can dataplanes interwork in flex algo and it seems that currently they can not if section 10.2 is interpreted as application to be a tuple of data plane + topological constraints (instead of only topological constraints). Thx, R. On Mon, Oct 12, 2020 at 10:47 AM Peter Psenak wrote: > Hi Jimmy. > > On 12/10/2020 09:12, Dongjie (Jimmy) wrote: > > Hi Jeff, > > > > Thanks for your explanation. I understand that for different data plane > the SIDs or IP addresses have different scope, and will not conflict in > normal cases. > > > > My question is more about whether a computation node needs to know and > check which data plane is used by the intermediate nodes to bind to the > Flex-Algo? In another word, can an SR path computed using Flex-Algo 128 go > through an intermediate node which bind Flex-Algo 128 to IP data plane? > > computation node MUST check the application specific participation in > flex-algo and participation advertisement is application specific. SR > and IP are different applications from flex-algo perspective. > > > draft-ietf-lsr-flex-algo-12, section 10.2: > > > Application-specific advertisement for Flex-Algorithm participation > MUST be defined for each application > > thanks, > Peter > > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com] > >> Sent: Sunday, October 11, 2020 3:14 AM > >> To: Ron Bonica > >> Cc: Dongjie (Jimmy) ; Peter Psenak > >> ; Yingzhen Qu ; Gyan > >> Mishra ; lsr@ietf.org > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> Jie, > >> > >> The scoop is different, for SR data plane entry uniqueness is in > context of SR > >> domain (SID = value + context), while for IP it is global to the > routing domain, > >> FIB entry is a destination, nothing more. > >> > >> Regards, > >> Jeff > >> > >>> On Oct 10, 2020, at 05:47, Ron Bonica wrote: > >>> > >>> Hi Jimmie, > >>> > >>> Inline..... > >>> > >>> Ron > >>> > >>> > >>> Juniper Business Use Only > >>> > >>> -----Original Message----- > >>> From: Dongjie (Jimmy) > >>> Sent: Friday, October 9, 2020 11:06 PM > >>> To: Peter Psenak ; Ron Bonica > >>> ; Yingzhen Qu ; Gyan > >>> Mishra > >>> Cc: lsr@ietf.org; Jeff Tantsura > >>> Subject: RE: [Lsr] FW: New Version Notification for > >>> draft-bonica-lsr-ip-flexalgo-00.txt > >>> > >>> [External Email. Be cautious of content] > >>> > >>> > >>> Hi Peter, > >>> > >>> Thanks for your reply. It aligns with my understanding of FAD, which > is just a > >> set of constraints for path computation. Thus one Flex-Algo ID could be > used > >> with multiple different data planes. Is this understanding correct? > >>> > >>> [RB] I never thought about this. Is there a use-case? I think that it > will work, > >> but I would have to try it before saying for sure. > >>> > >>> If so, my question is about the scenario below: > >>> > >>> A group of nodes in a network support FA-128, a sub-group of them bind > >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. > When > >> one node compute an SR path to a destination, can it compute the path > to only > >> pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes which > bind > >> FA-128 to IP address? > >>> > >>> [RB] I don't think so. However, you could achieve the same outcome > using link > >> colors. > >>> > >>> If so, how could this node know the binding of FA to different data > planes on > >> other nodes? > >>> > >>> Best regards, > >>> Jie > >>> > >>>> -----Original Message----- > >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > >>>> Sent: Friday, October 9, 2020 11:58 PM > >>>> To: Dongjie (Jimmy) ; Ron Bonica > >>>> ; Yingzhen Qu > >>>> ; Gyan Mishra > >>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>> > >>>> Hi Jimmy, > >>>> > >>>> > >>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > >>>>> Hi Ron, > >>>>> > >>>>> Thanks for explaining the difference between IP Flex-Algo and SR > >>>>> Flex-algo. As > >>>> you said, the major difference is the data plane. > >>>>> > >>>>> If my understanding is correct, for one Flex-Algo to be used > >>>>> correctly, the set > >>>> of nodes need to apply consistent constraints in computation, and > >>>> bind the FAD to the same data plane. > >>>>> > >>>>> Is it possible that different nodes may use the same Flex-Algo with > >>>>> different > >>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with > >>>> pure IP etc., or each Flex-Algo is always associated with only one > >>>> data plane? In the former case, should the flex-algo definition also > >>>> indicate the data plane(s) to be used with the flex-algo? > >>>> > >>>> let me respond to this query, as this is not specific to Ron's draft. > >>>> > >>>> FAD is data plane agnostic and is used by all of them. > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>>> > >>>>> Best regards, > >>>>> Jie > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica > >>>>>> Sent: Sunday, October 4, 2020 4:34 AM > >>>>>> To: Yingzhen Qu ; Peter Psenak > >>>>>> ; Gyan Mishra > >>>>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> Hi Yingzhen, > >>>>>> > >>>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the > >>>>>> following > >>>> respects: > >>>>>> > >>>>>> - Links have IGP metrics, TE metrics, delay metrics and > >>>>>> administrative colors > >>>>>> - FADs define Flexible Algorithms > >>>>>> > >>>>>> More specifically, the FAD: > >>>>>> > >>>>>> - Indicates which metric type the Flexible Algorithm uses > >>>>>> - Specifies constraints in terms of link colors that are included > >>>>>> or excluded from the Flexible Algorithm. > >>>>>> > >>>>>> The significant difference between IP Flexible Algorithms and SR > >>>>>> Flexible Algorithms is: > >>>>>> > >>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators > >>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > >>>>>> > >>>>>> So, IP Flexible Algorithms can be deployed in any IP network, even > >>>>>> in the absence of SR. > >>>>>> > >>>>>> Ron > >>>>>> > >>>>>> > >>>>>> Juniper Business Use Only > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Yingzhen Qu > >>>>>> Sent: Saturday, October 3, 2020 2:08 PM > >>>>>> To: Peter Psenak ; Gyan Mishra > >>>>>> ; Ron Bonica > >>>>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> [External Email. Be cautious of content] > >>>>>> > >>>>>> > >>>>>> Hi Peter, > >>>>>> > >>>>>> Using flex-algo, a SRv6 locator can be associated with a single > >>>>>> algo, which means an IPv6 or IPv4 address can also be associated > >>>>>> with a single algo. So my understanding is Ron's proposal is making > >>>>>> the > >>>> configuration of flex-algo easier? > >>>>>> Instead of using the exclude or include list you can configure a > >>>>>> loopback address to a flex-algo directly? > >>>>>> > >>>>>> Thanks, > >>>>>> Yingzhen > >>>>>> > >>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: > >>>>>> > >>>>>> Hi Yingzhen, > >>>>>> > >>>>>> On 02/10/2020 22:15, Yingzhen Qu wrote: > >>>>>>> Hi Peter, > >>>>>>> > >>>>>>> My understanding of flex-algo is that for traffic destined > >>>>>> to a prefix on a particular algo, it can only be routed on routers > >>>>>> belong to that algo, which also means only routers in that algo > >>>>>> calculates how to reach that prefix and install it into the routing > >>>>>> table. It seems to me that using flex-algo (section 12 of the > >>>>>> draft) it's possible to have a loopback address associated with > >>>>>> only one algo, please correct me if I'm missing or misunderstood > >> something. > >>>>>> > >>>>>> you are right. That is exactly what is being done for > flex-algo with > >>>>>> SRv6 - locator is associated with a single algo only. The > proposal > >> uses > >>>>>> the same concept. > >>>>>> > >>>>>> thanks, > >>>>>> Peter > >>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Yingzhen > >>>>>>> > >>>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > >>>>>> >>>>>> ppsenak=40cisco.com@dmarc.ietf.org> > >>>>>> wrote: > >>>>>>> > >>>>>>> Gyan, > >>>>>>> > >>>>>>> On 02/10/2020 18:30, Gyan Mishra wrote: > >>>>>>>> All, > >>>>>>>> > >>>>>>>> With SRv6 and IP based flex algo a generic question as it > >>>> applies > >>>>>> to > >>>>>>>> both. Is it possible to have within a single IGP domain > >>>> different > >>>>>> sets > >>>>>>>> of nodes or segments of the network running different > >>>>>> algorithms. > >>>>>>> > >>>>>>> absolutely. > >>>>>>> > >>>>>>>> From > >>>>>>>> both drafts it sounds like all nodes have to agree on same > >>>>>> algorithm > >>>>>>>> similar to concept of metric and reference bandwidth all > >>>> have to > >>>>>> have > >>>>>>>> the same style metric and play to the same sheet of music. > >>>>>>> > >>>>>>> all participating nodes need to agree on the definition of the > >>>>>> flex-algo > >>>>>>> and advertise the participation. That's it. > >>>>>>> > >>>>>>>> If there was > >>>>>>>> a way to use multiple algorithms simultaneously based on > >>>> SFC > >>>>>> or services > >>>>>>>> and instantiation of specific algorithm based on service to > >>>> be > >>>>>>>> rendered. Doing so without causing a routing loop or sub > >>>>>> optimal > >>>>>>>> routing. > >>>>>>> > >>>>>>> you can certainly use multiple algorithms simultaneously and > >>>> use > >>>>>> algo > >>>>>>> specific paths to forward specific traffic over it. How that > >>>>>>> is > >>>> done > >>>>>>> from the forwarding perspective depends in which > >>>> forwarding > >>>>>> plane you > >>>>>>> use. Flex-algo control plane is independent of the forwarding > >>>>>> plane. > >>>>>>> > >>>>>>> > >>>>>>>> I thought with flex algo that there exists a feature that on each > >>>>>>>> hop there is a way to specify which algo to use hop by > >>>> hop > >>>>>> similar > >>>>>>>> to a hop by hop policy based routing. > >>>>>>> > >>>>>>> no, there is no hop-by-hop classification, that is problematic > >>>> and > >>>>>> does > >>>>>>> not scale for high speeds. Classification is done at the > >>>> ingress only. > >>>>>>> > >>>>>>> thanks, > >>>>>>> Peter > >>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Lsr mailing list > >>>>>>> Lsr@ietf.org > >>>>>>> > >>>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl > >>>>>> oo > >>>>>> k.com/ > >>>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data > >>>>>> = > >>>> 0 > >>>>>> 2 > >>>>>> > >>>> > >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 > >>>>>> > >>>> > >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >>>>>> > >>>> > >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >>>>>> > >>>> > >> &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR > >>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Lsr mailing list > >>>>>> Lsr@ietf.org > >>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l > >>>>>> > >> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_ > >> H > >>>>>> z218CE8S8XzlIxAA$ > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > >>>> _ > >>>> > >> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz2 > >> 18C > >>>> E > >>>> 8S8XzlIxAA$ > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --000000000000df09e905b177e63a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Peter,

To me the application here i= s "avoid red links" regardless of choice of encap in the data pla= ne.=C2=A0

Does it really make=C2=A0sense to separa= te advertisements of SR flex-algo vs IP flex-algo into separate=C2=A0TLVs ?= =C2=A0

Along the same linkes even for SR data plan= e can be SR-MPLS or SRv6. So in the network running all three data planes= =C2=A0you will need to compute SPT for each flex-algo three times which may= or may not be desired especially if each algorithm would be as simple as t= o avoid certain link color.=C2=A0

That goes to the= point can dataplanes interwork in flex algo and=C2=A0it seems that current= ly=C2=A0they can not if section 10.2 is interpreted as application to be a = tuple of data plane + topological constraints (instead of only topological = constraints).=C2=A0=C2=A0

Thx,
R.
<= div>




<= div>
On Oct 11, 2020, 11:21 AM -0700, Gy= an Mishra <hayabusagsm=40gmail.com>, wrote:

Jeff

So basically as SR =46lex Algo uses SR data plane (= SID ,context) uniqueness for SR-MPLS label uniqueness and SRv6 Locator un= iqueness as compare to IP =46lex Algo IP Data plane is destination prefix= based. &=23160;

So you could literally have both IP flex algo and S= R flex also data plane as mutually exclusive data plane work in parallel = as two ships in the night. &=23160;

SRv6 uses Longest prefix match and in SRv6-BE w/o S= RH which would be destination based IP and SRv6-BE in parallel to IP =46l= ex algo would not work as they would collide on the IPv6 data plane.

Kind Regards&=23160;

Gyan

On Sun, Oct 11, 2020 at 1= :38 PM Jeff Tantsura <jefftant.ietf=40gmail.com> wrote:
Thanks Ron, indeed=21&=23160= ; Autocorrect works in mysterious ways&=23160; ;-)

Regards,
Jeff

> On Oct 11, 2020, at 09:41, Ron Bonica <rbonica=40juniper.net> = wrote:
>
> =EF=BB=BFJeff,
>
> I think that you mean the scope is different.....
>
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160= ; &=23160; &=23160; &=23160;Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> =46rom: Jeff Tantsura <jefftant.ietf=40gmail.com>
> Sent: Saturday, October 10, 2020 3:14 PM
> To: Ron Bonica <rbonica=40juniper.net>
> Cc: Dongjie (Jimmy) <jie.dong=40huawei.com>; Peter Psenak <= ppsena= k=40cisco.com>; Yingzhen Qu <yingzhen.qu=40futurewei.com&= gt;; Gyan Mishra <hayabusagsm=40gmail.com>; lsr=40ietf.org
> Subject: Re: =5BLsr=5D =46W: New Version Notification for draft-boni= ca-lsr-ip-flexalgo-00.txt
>
> =5BExternal Email. Be cautious of content=5D
>
>
> Jie,
>
> The scoop is different, for SR data plane entry uniqueness is in con= text of SR domain (SID =3D value + context), while for IP it is global to= the routing domain, =46IB entry is a destination, nothing more.
>
> Regards,
> Jeff
>
>> On Oct 10, 2020, at 05:47, Ron Bonica <rbonica=40juniper.net&= gt; wrote:
>>
>> =EF=BB=BFHi Jimmie,
>>
>> Inline.....
>>
>>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23= 160; &=23160; &=23160;Ron
>>
>>
>> Juniper Business Use Only
>>
>> -----Original Message-----
>> =46rom: Dongjie (Jimmy) <jie.dong=40huawei.com>
>> Sent: =46riday, October 9, 2020 11:06 PM
>> To: Peter Psenak <ppsenak=40cisco.com>; Ron Bonica
>> <rbonica=40juniper.net>; Yingzhen Qu <yingzhen.qu=40f= uturewei.com>; Gyan
>> Mishra <hayabusagsm=40gmail.com>
>> Cc: lsr=40ietf.org; Jeff Tantsura <jefftant.ietf=40gmail.com> >> Subject: RE: =5BLsr=5D =46W: New Version Notification for
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> =5BExternal Email. Be cautious of content=5D
>>
>>
>> Hi Peter,
>>
>> Thanks for your reply. It aligns with my understanding of =46AD,= which is just a set of constraints for path computation. Thus one =46lex= -Algo ID could be used with multiple different data planes. Is this under= standing correct=3F
>>
>> =5BRB=5D I never thought about this. Is there a use-case=3F I th= ink that it will work, but I would have to try it before saying for sure.=
>>
>> If so, my question is about the scenario below:
>>
>> A group of nodes in a network support =46A-128, a sub-group of t= hem bind =46A-128 to SR SIDs, another sub-group of them bind =46A-128 to = IP address. When one node compute an SR path to a destination, can it com= pute the path to only pass the nodes which bind =46A-128 to SR SIDs, and = avoid the nodes which bind =46A-128 to IP address=3F
>>
>> =5BRB=5D I don't think so. However, you could achieve the same o= utcome using link colors.
>>
>> If so, how could this node know the binding of =46A to different= data planes on other nodes=3F
>>
>> Best regards,
>> Jie
>>
>>> -----Original Message-----
>>> =46rom: Lsr =5Bmailto:lsr-bounces=40ietf.org=5D On Behalf O= f Peter Psenak
>>> Sent: =46riday, October 9, 2020 11:58 PM
>>> To: Dongjie (Jimmy) <jie.dong=40huawei.com>; Ron Bonic= a
>>> <rbonica=3D40juniper.net=40dmarc.ietf.org>; Y= ingzhen Qu
>>> <yingzhen.qu=40futurewei.com>; Gyan Mishra <<= a href=3D=22mailto:hayabusagsm=40gmail.com=22 target=3D=22=5Fblank=22>hay= abusagsm=40gmail.com>
>>> Cc: lsr=40ietf.org; Jeff Tantsura <jefftant.ietf=40gmail.com= >
>>> Subject: Re: =5BLsr=5D =46W: New Version Notification for >>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>
>>> Hi Jimmy,
>>>
>>>
>>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
>>>>> Hi Ron,
>>>>>
>>>>> Thanks for explaining the difference between IP =46l= ex-Algo and SR
>>>>> =46lex-algo. As
>>> you said, the major difference is the data plane.
>>>>
>>>> If my understanding is correct, for one =46lex-Algo to b= e used
>>>> correctly, the set
>>> of nodes need to apply consistent constraints in computation= , and
>>> bind the =46AD to the same data plane.
>>>>
>>>> Is it possible that different nodes may use the same =46= lex-Algo with
>>>> different
>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some= with
>>> pure IP etc., or each =46lex-Algo is always associated with = only one
>>> data plane=3F In the former case, should the flex-algo defin= ition also
>>> indicate the data plane(s) to be used with the flex-algo=3F<= br /> >>>
>>> let me respond to this query, as this is not specific to Ron= 's draft.
>>>
>>> =46AD is data plane agnostic and is used by all of them.
>>>
>>> thanks,
>>> Peter
>>>
>>>>
>>>> Best regards,
>>>> Jie
>>>>
>>>>> -----Original Message-----
>>>>> =46rom: Lsr =5Bmailto:lsr-bounces=40ietf.org=5D On = Behalf Of Ron Bonica
>>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>>> To: Yingzhen Qu <yingzhen.qu=40futurewei.com&= gt;; Peter Psenak
>>>>> <ppsenak=40cisco.com>; Gyan Mishra <hayabusagsm=40= gmail.com>
>>>>> Cc: lsr=40ietf.org; Jeff Tantsura <jefftant.ietf=40gmail.c= om>
>>>>> Subject: Re: =5BLsr=5D =46W: New Version Notificatio= n for
>>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>
>>>>> Hi Yingzhen,
>>>>>
>>>>> IP =46lexible Algorithms are like SR =46lexible Algo= rithms in the
>>>>> following
>>> respects:
>>>>>
>>>>> - Links have IGP metrics, TE metrics, delay metrics = and
>>>>> administrative colors
>>>>> - =46ADs define =46lexible Algorithms
>>>>>
>>>>> More specifically, the =46AD:
>>>>>
>>>>> - Indicates which metric type the =46lexible Algorit= hm uses
>>>>> - Specifies constraints in terms of link colors that= are included
>>>>> or excluded from the =46lexible Algorithm.
>>>>>
>>>>> The significant difference between IP =46lexible Alg= orithms and SR
>>>>> =46lexible Algorithms is:
>>>>>
>>>>> - SR =46lexible Algorithms bind =46ADs to prefix SID= s or SRv6 locators
>>>>> - IP =46lexible Algorithms bind =46ADs to IPv4 or IP= v6 addresses.
>>>>>
>>>>> So, IP =46lexible Algorithms can be deployed in any = IP network, even
>>>>> in the absence of SR.
>>>>>
>>>>>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160;= &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; = &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; Ron
>>>>>
>>>>>
>>>>> Juniper Business Use Only
>>>>>
>>>>> -----Original Message-----
>>>>> =46rom: Yingzhen Qu <yingzhen.qu=40futurewei.co= m>
>>>>> Sent: Saturday, October 3, 2020 2:08 PM
>>>>> To: Peter Psenak <ppsenak=40cisco.com>; Gyan Mis= hra
>>>>> <hayabusagsm=40gmail.com>; Ron Bonica <rbonic= a=40juniper.net>
>>>>> Cc: lsr=40ietf.org; Jeff Tantsura <jefftant.ietf=40gmail.c= om>
>>>>> Subject: Re: =5BLsr=5D =46W: New Version Notificatio= n for
>>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>
>>>>> =5BExternal Email. Be cautious of content=5D
>>>>>
>>>>>
>>>>> Hi Peter,
>>>>>
>>>>> Using flex-algo, a SRv6 locator can be associated wi= th a single
>>>>> algo, which means an IPv6 or IPv4 address can also b= e associated
>>>>> with a single algo. So my understanding is Ron's pro= posal is making
>>>>> the
>>> configuration of flex-algo easier=3F
>>>>> Instead of using the exclude or include list you can= configure a
>>>>> loopback address to a flex-algo directly=3F
>>>>>
>>>>> Thanks,
>>>>> Yingzhen
>>>>>
>>>>> On 10/3/20, 2:47 AM, =22Peter Psenak=22 <ppsenak=40cisco.= com> wrote:
>>>>>
>>>>>&=23160; &=23160; Hi Yingzhen,
>>>>>
>>>>>&=23160; &=23160; On 02/10/2020 22:15, Yingzhen Qu wr= ote:
>>>>>> Hi Peter,
>>>>>>
>>>>>> My understanding of flex-algo is that for traffi= c destined
>>>>> to a prefix on a particular algo, it can only be rou= ted on routers
>>>>> belong to that algo, which also means only routers i= n that algo
>>>>> calculates how to reach that prefix and install it i= nto the routing
>>>>> table. It seems to me that using flex-algo (section = 12 of the
>>>>> draft) it's possible to have a loopback address asso= ciated with
>>>>> only one algo, please correct me if I'm missing or m= isunderstood something.
>>>>>
>>>>>&=23160; &=23160; you are right. That is exactly what= is being done for flex-algo with
>>>>>&=23160; &=23160; SRv6 - locator is associated with a= single algo only. The proposal uses
>>>>>&=23160; &=23160; the same concept.
>>>>>
>>>>>&=23160; &=23160; thanks,
>>>>>&=23160; &=23160; Peter
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Yingzhen
>>>>>>
>>>>>> On 10/2/20, 9:43 AM, =22Lsr on behalf of Peter P= senak=22
>>>>> <lsr-bounces=40ietf.org on behalf of
>>>>> ppsenak=3D40cisco.com=40dmarc.ietf.org> >>>>> wrote:
>>>>>>
>>>>>>&=23160; &=23160; Gyan,
>>>>>>
>>>>>>&=23160; &=23160; On 02/10/2020 18:30, Gyan Mishr= a wrote:
>>>>>>> All,
>>>>>>>
>>>>>>> With SRv6 and IP based flex algo a generic q= uestion as it
>>> applies
>>>>> to
>>>>>>> both. Is it possible to have within a single= IGP domain
>>> different
>>>>> sets
>>>>>>> of nodes or segments of the network running = different
>>>>> algorithms.
>>>>>>
>>>>>>&=23160; &=23160; absolutely.
>>>>>>
>>>>>>> =46rom
>>>>>>> both drafts it sounds like all nodes have to= agree on same
>>>>> algorithm
>>>>>>> similar to concept of metric and reference b= andwidth all
>>> have to
>>>>> have
>>>>>>> the same style metric and play to the same s= heet of music.
>>>>>>
>>>>>>&=23160; &=23160; all participating nodes need to= agree on the definition of the
>>>>> flex-algo
>>>>>>&=23160; &=23160; and advertise the participation= . That's it.
>>>>>>
>>>>>>> If there was
>>>>>>> a way to use multiple algorithms simultaneou= sly based on
>>> S=46C
>>>>> or services
>>>>>>> and instantiation of specific algorithm base= d on service to
>>> be
>>>>>>> rendered.&=23160; Doing so without causing a= routing loop or sub
>>>>> optimal
>>>>>>> routing.
>>>>>>
>>>>>>&=23160; &=23160; you can certainly use multiple = algorithms simultaneously and
>>> use
>>>>> algo
>>>>>>&=23160; &=23160; specific paths to forward speci= fic traffic over it. How that
>>>>>> is
>>> done
>>>>>>&=23160; &=23160; from the forwarding perspective= depends in which
>>> forwarding
>>>>> plane you
>>>>>>&=23160; &=23160; use. =46lex-algo control plane = is independent of the forwarding
>>>>> plane.
>>>>>>
>>>>>>
>>>>>>> I thought with flex algo that there exists a= feature that on each
>>>>>>> hop there is a way to specify which algo to = use hop by
>>> hop
>>>>> similar
>>>>>>> to a hop by hop policy based routing.
>>>>>>
>>>>>>&=23160; &=23160; no, there is no hop-by-hop clas= sification, that is problematic
>>> and
>>>>> does
>>>>>>&=23160; &=23160; not scale for high speeds. Clas= sification is done at the
>>> ingress only.
>>>>>>
>>>>>>&=23160; &=23160; thanks,
>>>>>>&=23160; &=23160; Peter
>>>>>>
>>>>>>>
>>>>>>
>>>>>>&=23160; &=23160; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>>>>>>&=23160; &=23160; Lsr mailing list
>>>>>>&=23160; &=23160; Lsr=40ietf.org
>>>>>>
>>>>> https://urldefense.com/v3/=5F=5Fhttps://nam11.safelinks.protecti= on.outl
>>>>> oo
>>>>> k.com/
>>>>> =3Furl=3Dhttps*3A*2=46*2=46www.ietf.or= g*2=46mailman*2=46listinfo*2=46lsr&amp;data
>>>>> =3D
>>> 0
>>>>> 2
>>>>>
>>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe031= 24c6e414e067c2008d86781
>>>>>
>>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C6373731527= 3986
>>>>>
>>> 5126&amp;sdata=3DWI48cEAan*2=46OkDPmVXGurEAjPItNG=469p9P= DQIlD1ip0g*3D
>>>>>
>>> &amp;reserved=3D0=5F=5F;JSUlJSUlJSUlJSUlJSUlJQ=21=21NEt6= yMaO-gk=21X1fRln9MjimeJcR
>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G=24=
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F
>>>>> Lsr mailing list
>>>>> Lsr=40ietf.org
>>>>> https://urldefense.com/v3/=5F=5Fhttps://www.ietf.org/mailman/lis= tinfo/l
>>>>> sr=5F=5F;=21=21NEt6yMaO-gk=21TeHgIKM4lUZhkYnt=5Fe=46= t3SshGJtln8PTqhCuZtODomUQWC=5FH
>>>>> z218CE8S8XzlIxAA=24
>>>>
>>>>
>>>
>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
>>> Lsr mailing list
>>> Lsr=40ietf.org
>>> https://urldefense.com/v3/=5F=5Fhttps://www.ietf.org/mailman/listinfo= /lsr
>>> =5F
>>> =5F;=21=21NEt6yMaO-gk=21TeHgIKM4lUZhkYnt=5Fe=46t3SshGJtln8PT= qhCuZtODomUQWC=5FHz218C
>>> E
>>> 8S8XzlIxAA=24
--


Gyan Mishra<= /p>

Netw= ork Solutions Architect&=23160;

M 301 502-1347
13101 Columbia Pike&=23160;
Silver Spring, MD



On Mon, Oct 12, 2020 at 10:47 AM Peter Psenak <ppsenak= =3D40cisco.com@dmarc.ietf.org= > wrote:
= Hi Jimmy.

On 12/10/2020 09:12, Dongjie (Jimmy) wrote:
> Hi Jeff,
>
> Thanks for your explanation. I understand that for different data plan= e the SIDs or IP addresses have different scope, and will not conflict in n= ormal cases.
>
> My question is more about whether a computation node needs to know and= check which data plane is used by the intermediate nodes to bind to the Fl= ex-Algo? In another word, can an SR path computed using Flex-Algo 128 go th= rough an intermediate node which bind Flex-Algo 128 to IP data plane?

computation node MUST check the application specific participation in
flex-algo and participation advertisement is application specific. SR
and IP are different applications from flex-algo perspective.


draft-ietf-lsr-flex-algo-12, section 10.2:


=C2=A0 =C2=A0 Application-specific advertisement for Flex-Algorithm partici= pation
=C2=A0 =C2=A0 MUST be defined for each application

thanks,
Peter

>
> Best regards,
> Jie
>
>> -----Original Message-----
>> From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com]
>> Sent: Sunday, October 11, 2020 3:14 AM
>> To: Ron Bonica <rbonica@juniper.net>
>> Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Peter Psenak
>> <ppsenak= @cisco.com>; Yingzhen Qu <yingzhen.qu@futurewei.com>; Gyan
>> Mishra <hayabusagsm@gmail.com>; lsr@ietf.org
>> Subject: Re: [Lsr] FW: New Version Notification for
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> Jie,
>>
>> The scoop is different, for SR data plane entry uniqueness is in c= ontext of SR
>> domain (SID =3D value + context), while for IP it is global to the= routing domain,
>> FIB entry is a destination, nothing more.
>>
>> Regards,
>> Jeff
>>
>>> On Oct 10, 2020, at 05:47, Ron Bonica <rbonica@juniper.net> wrote:
>>>
>>> Hi Jimmie,
>>>
>>> Inline.....
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Ron
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> -----Original Message-----
>>> From: Dongjie (Jimmy) <jie.dong@huawei.com>
>>> Sent: Friday, October 9, 2020 11:06 PM
>>> To: Peter Psenak <ppsenak@cisco.com>; Ron Bonica
>>> <r= bonica@juniper.net>; Yingzhen Qu <yingzhen.qu@futurewei.com>; Gyan
>>> Mishra <hayabusagsm@gmail.com>
>>> Cc: lsr@ietf= .org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>> Subject: RE: [Lsr] FW: New Version Notification for
>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>
>>> [External Email. Be cautious of content]
>>>
>>>
>>> Hi Peter,
>>>
>>> Thanks for your reply. It aligns with my understanding of FAD,= which is just a
>> set of constraints for path computation. Thus one Flex-Algo ID cou= ld be used
>> with multiple different data planes. Is this understanding correct= ?
>>>
>>> [RB] I never thought about this. Is there a use-case? I think = that it will work,
>> but I would have to try it before saying for sure.
>>>
>>> If so, my question is about the scenario below:
>>>
>>> A group of nodes in a network support FA-128, a sub-group of t= hem bind
>> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP add= ress. When
>> one node compute an SR path to a destination, can it compute the p= ath to only
>> pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes w= hich bind
>> FA-128 to IP address?
>>>
>>> [RB] I don't think so. However, you could achieve the same= outcome using link
>> colors.
>>>
>>> If so, how could this node know the binding of FA to different= data planes on
>> other nodes?
>>>
>>> Best regards,
>>> Jie
>>>
>>>> -----Original Message-----
>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
>>>> Sent: Friday, October 9, 2020 11:58 PM
>>>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Ron Bonica
>>>> <rbonica=3D40juniper.net@dmarc.ietf.org>; Yingzhen Qu
>>>> <yingzhen.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com> >>>> Cc: lsr@= ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>> Subject: Re: [Lsr] FW: New Version Notification for
>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>
>>>> Hi Jimmy,
>>>>
>>>>
>>>>>=C2=A0 =C2=A0On 09/10/2020 04:59, Dongjie (Jimmy) wrote= :
>>>>> Hi Ron,
>>>>>
>>>>> Thanks for explaining the difference between IP Flex-A= lgo and SR
>>>>> Flex-algo. As
>>>> you said, the major difference is the data plane.
>>>>>
>>>>> If my understanding is correct, for one Flex-Algo to b= e used
>>>>> correctly, the set
>>>> of nodes need to apply consistent constraints in computati= on, and
>>>> bind the FAD to the same data plane.
>>>>>
>>>>> Is it possible that different nodes may use the same F= lex-Algo with
>>>>> different
>>>> data plane, e.g. some with SR-MPLS, some with SRv6, and so= me with
>>>> pure IP etc., or each Flex-Algo is always associated with = only one
>>>> data plane? In the former case, should the flex-algo defin= ition also
>>>> indicate the data plane(s) to be used with the flex-algo?<= br> >>>>
>>>> let me respond to this query, as this is not specific to R= on's draft.
>>>>
>>>> FAD is data plane agnostic and is used by all of them.
>>>>
>>>> thanks,
>>>> Peter
>>>>
>>>>>
>>>>> Best regards,
>>>>> Jie
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica=
>>>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>>>> To: Yingzhen Qu <yingzhen.qu@futurewei.com>; Peter P= senak
>>>>>> <ppsenak@cisco.com>; Gyan Mishra <hayabusagsm@gmail.com>
>>>>>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>>>> Subject: Re: [Lsr] FW: New Version Notification fo= r
>>>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>>
>>>>>> Hi Yingzhen,
>>>>>>
>>>>>> IP Flexible Algorithms are like SR Flexible Algori= thms in the
>>>>>> following
>>>> respects:
>>>>>>
>>>>>> - Links have IGP metrics, TE metrics, delay metric= s and
>>>>>> administrative colors
>>>>>> - FADs define Flexible Algorithms
>>>>>>
>>>>>> More specifically, the FAD:
>>>>>>
>>>>>> - Indicates which metric type the Flexible Algorit= hm uses
>>>>>> - Specifies constraints in terms of link colors th= at are included
>>>>>> or excluded from the Flexible Algorithm.
>>>>>>
>>>>>> The significant difference between IP Flexible Alg= orithms and SR
>>>>>> Flexible Algorithms is:
>>>>>>
>>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs = or SRv6 locators
>>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6= addresses.
>>>>>>
>>>>>> So, IP Flexible Algorithms can be deployed in any = IP network, even
>>>>>> in the absence of SR.
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Ron
>>>>>>
>>>>>>
>>>>>> Juniper Business Use Only
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Yingzhen Qu <yingzhen.qu@futurewei.com>
>>>>>> Sent: Saturday, October 3, 2020 2:08 PM
>>>>>> To: Peter Psenak <ppsenak@cisco.com>; Gyan Mishra
>>>>>> <hayabusagsm@gmail.com>; Ron Bonica <rbonica@juniper.net>
>>>>>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>>>> Subject: Re: [Lsr] FW: New Version Notification fo= r
>>>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>>
>>>>>> [External Email. Be cautious of content]
>>>>>>
>>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> Using flex-algo, a SRv6 locator can be associated = with a single
>>>>>> algo, which means an IPv6 or IPv4 address can also= be associated
>>>>>> with a single algo. So my understanding is Ron'= ;s proposal is making
>>>>>> the
>>>> configuration of flex-algo easier?
>>>>>> Instead of using the exclude or include list you c= an configure a
>>>>>> loopback address to a flex-algo directly?
>>>>>>
>>>>>> Thanks,
>>>>>> Yingzhen
>>>>>>
>>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" <= ppsenak@cisco.com> wrote:
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 Hi Yingzhen,
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 On 02/10/2020 22:15, Yingzhen = Qu wrote:
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> My understanding of flex-algo is that for traf= fic destined
>>>>>> to a prefix on a particular algo, it can only be r= outed on routers
>>>>>> belong to that algo, which also means only routers= in that algo
>>>>>> calculates how to reach that prefix and install it= into the routing
>>>>>> table. It seems to me that using flex-algo (sectio= n 12 of the
>>>>>> draft) it's possible to have a loopback addres= s associated with
>>>>>> only one algo, please correct me if I'm missin= g or misunderstood
>> something.
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 you are right. That is exactly= what is being done for flex-algo with
>>>>>>=C2=A0 =C2=A0 =C2=A0 SRv6 - locator is associated w= ith a single algo only. The proposal
>> uses
>>>>>>=C2=A0 =C2=A0 =C2=A0 the same concept.
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 thanks,
>>>>>>=C2=A0 =C2=A0 =C2=A0 Peter
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Yingzhen
>>>>>>>
>>>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Pe= ter Psenak"
>>>>>> <lsr-bounces@ietf.org on behalf of
>>>>>> ppsenak=3D40cisco.com@dmarc.ietf.org>
>>>>>> wrote:
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 Gyan,
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 On 02/10/2020 18:30, Gyan = Mishra wrote:
>>>>>>>> All,
>>>>>>>>
>>>>>>>> With SRv6 and IP based flex algo a generic= question as it
>>>> applies
>>>>>> to
>>>>>>>> both. Is it possible to have within a sing= le IGP domain
>>>> different
>>>>>> sets
>>>>>>>> of nodes or segments of the network runnin= g different
>>>>>> algorithms.
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 absolutely.
>>>>>>>
>>>>>>>> From
>>>>>>>> both drafts it sounds like all nodes have = to agree on same
>>>>>> algorithm
>>>>>>>> similar to concept of metric and reference= bandwidth all
>>>> have to
>>>>>> have
>>>>>>>> the same style metric and play to the same= sheet of music.
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 all participating nodes ne= ed to agree on the definition of the
>>>>>> flex-algo
>>>>>>>=C2=A0 =C2=A0 =C2=A0 and advertise the particip= ation. That's it.
>>>>>>>
>>>>>>>> If there was
>>>>>>>> a way to use multiple algorithms simultane= ously based on
>>>> SFC
>>>>>> or services
>>>>>>>> and instantiation of specific algorithm ba= sed on service to
>>>> be
>>>>>>>> rendered.=C2=A0 Doing so without causing a= routing loop or sub
>>>>>> optimal
>>>>>>>> routing.
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 you can certainly use mult= iple algorithms simultaneously and
>>>> use
>>>>>> algo
>>>>>>>=C2=A0 =C2=A0 =C2=A0 specific paths to forward = specific traffic over it. How that
>>>>>>> is
>>>> done
>>>>>>>=C2=A0 =C2=A0 =C2=A0 from the forwarding perspe= ctive depends in which
>>>> forwarding
>>>>>> plane you
>>>>>>>=C2=A0 =C2=A0 =C2=A0 use. Flex-algo control pla= ne is independent of the forwarding
>>>>>> plane.
>>>>>>>
>>>>>>>
>>>>>>>> I thought with flex algo that there exists= a feature that on each
>>>>>>>> hop there is a way to specify which algo t= o use hop by
>>>> hop
>>>>>> similar
>>>>>>>> to a hop by hop policy based routing.
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 no, there is no hop-by-hop= classification, that is problematic
>>>> and
>>>>>> does
>>>>>>>=C2=A0 =C2=A0 =C2=A0 not scale for high speeds.= Classification is done at the
>>>> ingress only.
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 thanks,
>>>>>>>=C2=A0 =C2=A0 =C2=A0 Peter
>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 __________________________= _____________________
>>>>>>>=C2=A0 =C2=A0 =C2=A0 Lsr mailing list
>>>>>>>=C2=A0 =C2=A0 =C2=A0 Lsr@ietf.org
>>>>>>>
>>>>>> https://= urldefense.com/v3/__https://nam11.safelinks.protection.outl
>>>>>> oo
>>>>>> k.com/
>>>>>> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flist= info*2Flsr&amp;data
>>>>>> =3D
>>>> 0
>>>>>> 2
>>>>>>
>>>>
>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d8678= 1
>>>>>>
>>>>
>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >>>>>>
>>>>
>> 5126&amp;sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g= *3D
>>>>>>
>>>>
>> &amp;reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln= 9MjimeJcR
>>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$=
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________ >>>>>> Lsr mailing list
>>>>>> = Lsr@ietf.org
>>>>>> https://= urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>>>>
>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_=
>> H
>>>>>> z218CE8S8XzlIxAA$
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> Lsr@ietf= .org
>>>> https://urldef= ense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>>>> _
>>>>
>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz2=
>> 18C
>>>> E
>>>> 8S8XzlIxAA$
>
>

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--000000000000df09e905b177e63a-- From nobody Mon Oct 12 05:02:33 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6C83A1417 for ; Mon, 12 Oct 2020 05:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oxf2QuCUR7yQ for ; Mon, 12 Oct 2020 05:02:29 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960283A140C for ; Mon, 12 Oct 2020 05:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18117; q=dns/txt; s=iport; t=1602504148; x=1603713748; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=COvTSYirW2LXc3GDMEOIvanPMZ3QKR+OjJOqF5N9ZRY=; b=bWJaYR6ab/pnmjI368tSKbue4s5TtUtik1v1uYcn44t/uRvV8eJzD1VM yTVX6zkmvKbnz6hoTLV7HF8wcvXFFJzqFZKvH8Kwvz7ThOX+pO0/VrH4w F146AyMGgjV7T2FLAiEs44EiXy67syCJ01poB+lgJSoh2f52Kxul4ikiO s=; X-IPAS-Result: =?us-ascii?q?A0CIBQBBRYRf/xbLJq1gHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DGlUBIBIshD2JAodoLooRkCyBaQsBAQEPGAsMBAEBhEoCghcmOBMCAwEBA?= =?us-ascii?q?QMCAwEBAQEFAQEBAgEGBG2FXAyFcgEBAQECAQEBIQ8BBTYJAgwECQIRBAEBA?= =?us-ascii?q?QICIwMCAiEGHwkIBg0GAgEBgyIBgksDDiAPiyWbBXaBMoQ7AYEYgjUNYoFCg?= =?us-ascii?q?Q4qh2aFa4FBP4ERJ4JpPoIaQgEBAoEoARIBIYMXgmAEkAArCYJVAaQEUoJyg?= =?us-ascii?q?xWFbIxdhH8FBwMfgxWBKohehRmPBJ4TgmyEHo5SgWsjZ3AzGggbFTuCaQlHG?= =?us-ascii?q?Q2OKxeDToUUhUQ/AzACATQCBgEJAQEDCY5IAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,366,1596499200"; d="scan'208";a="27851207" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2020 12:02:24 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 09CC2LZX026056; Mon, 12 Oct 2020 12:02:21 GMT To: Robert Raszuk Cc: "Dongjie (Jimmy)" , Jeff Tantsura , Ron Bonica , "lsr@ietf.org" , Gyan Mishra , Yingzhen Qu References: <7FC87D5B-0DA9-434C-905C-E5DD4F4EE4D8@gmail.com> From: Peter Psenak Message-ID: <054011ca-439b-a548-7d08-4fe968a02e10@cisco.com> Date: Mon, 12 Oct 2020 14:02:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 12:02:32 -0000 Robert, On 12/10/2020 13:50, Robert Raszuk wrote: > Hey Peter, > > To me the application here is "avoid red links" regardless of choice of > encap in the data plane. > > Does it really make sense to separate advertisements of SR flex-algo vs > IP flex-algo into separate TLVs ? yes, please look at the base flex-algo spec. Each app must signal participation independently, as it may use a completely different data plane and one can not assume that all data planes are supported on any particular node. Think of BIER, etc. They may want to use flex-algo. I can not assume that a node running SR is capable of forwarding BIER packets. > > Along the same linkes even for SR data plane can be SR-MPLS or SRv6. So > in the network running all three data planes you will need to compute > SPT for each flex-algo three times which may or may not be desired > especially if each algorithm would be as simple as to avoid certain link > color. > > That goes to the point can dataplanes interwork in flex algo and it > seems that currently they can not if section 10.2 is interpreted as > application to be a tuple of data plane + topological constraints > (instead of only topological constraints). application is orthogonal to constraints, constraints (e.g. FAD) is app independent. Participation in flex-algo is app specific. thanks, Peter > > Thx, > R. > > > > > > > > On Mon, Oct 12, 2020 at 10:47 AM Peter Psenak > > > wrote: > > Hi Jimmy. > > On 12/10/2020 09:12, Dongjie (Jimmy) wrote: > > Hi Jeff, > > > > Thanks for your explanation. I understand that for different data > plane the SIDs or IP addresses have different scope, and will not > conflict in normal cases. > > > > My question is more about whether a computation node needs to > know and check which data plane is used by the intermediate nodes to > bind to the Flex-Algo? In another word, can an SR path computed > using Flex-Algo 128 go through an intermediate node which bind > Flex-Algo 128 to IP data plane? > > computation node MUST check the application specific participation in > flex-algo and participation advertisement is application specific. SR > and IP are different applications from flex-algo perspective. > > > draft-ietf-lsr-flex-algo-12, section 10.2: > > >     Application-specific advertisement for Flex-Algorithm participation >     MUST be defined for each application > > thanks, > Peter > > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com > ] > >> Sent: Sunday, October 11, 2020 3:14 AM > >> To: Ron Bonica > > >> Cc: Dongjie (Jimmy) >; Peter Psenak > >> >; Yingzhen Qu > >; Gyan > >> Mishra >; > lsr@ietf.org > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> Jie, > >> > >> The scoop is different, for SR data plane entry uniqueness is in > context of SR > >> domain (SID = value + context), while for IP it is global to the > routing domain, > >> FIB entry is a destination, nothing more. > >> > >> Regards, > >> Jeff > >> > >>> On Oct 10, 2020, at 05:47, Ron Bonica > wrote: > >>> > >>> Hi Jimmie, > >>> > >>> Inline..... > >>> > >>>                     Ron > >>> > >>> > >>> Juniper Business Use Only > >>> > >>> -----Original Message----- > >>> From: Dongjie (Jimmy) > > >>> Sent: Friday, October 9, 2020 11:06 PM > >>> To: Peter Psenak >; Ron Bonica > >>> >; Yingzhen Qu > >; Gyan > >>> Mishra > > >>> Cc: lsr@ietf.org ; Jeff Tantsura > > > >>> Subject: RE: [Lsr] FW: New Version Notification for > >>> draft-bonica-lsr-ip-flexalgo-00.txt > >>> > >>> [External Email. Be cautious of content] > >>> > >>> > >>> Hi Peter, > >>> > >>> Thanks for your reply. It aligns with my understanding of FAD, > which is just a > >> set of constraints for path computation. Thus one Flex-Algo ID > could be used > >> with multiple different data planes. Is this understanding correct? > >>> > >>> [RB] I never thought about this. Is there a use-case? I think > that it will work, > >> but I would have to try it before saying for sure. > >>> > >>> If so, my question is about the scenario below: > >>> > >>> A group of nodes in a network support FA-128, a sub-group of > them bind > >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP > address. When > >> one node compute an SR path to a destination, can it compute the > path to only > >> pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes > which bind > >> FA-128 to IP address? > >>> > >>> [RB] I don't think so. However, you could achieve the same > outcome using link > >> colors. > >>> > >>> If so, how could this node know the binding of FA to different > data planes on > >> other nodes? > >>> > >>> Best regards, > >>> Jie > >>> > >>>> -----Original Message----- > >>>> From: Lsr [mailto:lsr-bounces@ietf.org > ] On Behalf Of Peter Psenak > >>>> Sent: Friday, October 9, 2020 11:58 PM > >>>> To: Dongjie (Jimmy) >; Ron Bonica > >>>> >; Yingzhen Qu > >>>> >; Gyan Mishra > > > >>>> Cc: lsr@ietf.org ; Jeff Tantsura > > > >>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>> > >>>> Hi Jimmy, > >>>> > >>>> > >>>>>   On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > >>>>> Hi Ron, > >>>>> > >>>>> Thanks for explaining the difference between IP Flex-Algo and SR > >>>>> Flex-algo. As > >>>> you said, the major difference is the data plane. > >>>>> > >>>>> If my understanding is correct, for one Flex-Algo to be used > >>>>> correctly, the set > >>>> of nodes need to apply consistent constraints in computation, and > >>>> bind the FAD to the same data plane. > >>>>> > >>>>> Is it possible that different nodes may use the same > Flex-Algo with > >>>>> different > >>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with > >>>> pure IP etc., or each Flex-Algo is always associated with only one > >>>> data plane? In the former case, should the flex-algo > definition also > >>>> indicate the data plane(s) to be used with the flex-algo? > >>>> > >>>> let me respond to this query, as this is not specific to Ron's > draft. > >>>> > >>>> FAD is data plane agnostic and is used by all of them. > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>>> > >>>>> Best regards, > >>>>> Jie > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lsr [mailto:lsr-bounces@ietf.org > ] On Behalf Of Ron Bonica > >>>>>> Sent: Sunday, October 4, 2020 4:34 AM > >>>>>> To: Yingzhen Qu >; Peter Psenak > >>>>>> >; Gyan Mishra > > > >>>>>> Cc: lsr@ietf.org ; Jeff Tantsura > > > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> Hi Yingzhen, > >>>>>> > >>>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the > >>>>>> following > >>>> respects: > >>>>>> > >>>>>> - Links have IGP metrics, TE metrics, delay metrics and > >>>>>> administrative colors > >>>>>> - FADs define Flexible Algorithms > >>>>>> > >>>>>> More specifically, the FAD: > >>>>>> > >>>>>> - Indicates which metric type the Flexible Algorithm uses > >>>>>> - Specifies constraints in terms of link colors that are > included > >>>>>> or excluded from the Flexible Algorithm. > >>>>>> > >>>>>> The significant difference between IP Flexible Algorithms and SR > >>>>>> Flexible Algorithms is: > >>>>>> > >>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 > locators > >>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > >>>>>> > >>>>>> So, IP Flexible Algorithms can be deployed in any IP > network, even > >>>>>> in the absence of SR. > >>>>>> > >>>>>>                                          Ron > >>>>>> > >>>>>> > >>>>>> Juniper Business Use Only > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Yingzhen Qu > > >>>>>> Sent: Saturday, October 3, 2020 2:08 PM > >>>>>> To: Peter Psenak >; Gyan Mishra > >>>>>> >; Ron > Bonica > > >>>>>> Cc: lsr@ietf.org ; Jeff Tantsura > > > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> [External Email. Be cautious of content] > >>>>>> > >>>>>> > >>>>>> Hi Peter, > >>>>>> > >>>>>> Using flex-algo, a SRv6 locator can be associated with a single > >>>>>> algo, which means an IPv6 or IPv4 address can also be associated > >>>>>> with a single algo. So my understanding is Ron's proposal is > making > >>>>>> the > >>>> configuration of flex-algo easier? > >>>>>> Instead of using the exclude or include list you can configure a > >>>>>> loopback address to a flex-algo directly? > >>>>>> > >>>>>> Thanks, > >>>>>> Yingzhen > >>>>>> > >>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" > wrote: > >>>>>> > >>>>>>      Hi Yingzhen, > >>>>>> > >>>>>>      On 02/10/2020 22:15, Yingzhen Qu wrote: > >>>>>>> Hi Peter, > >>>>>>> > >>>>>>> My understanding of flex-algo is that for traffic destined > >>>>>> to a prefix on a particular algo, it can only be routed on > routers > >>>>>> belong to that algo, which also means only routers in that algo > >>>>>> calculates how to reach that prefix and install it into the > routing > >>>>>> table. It seems to me that using flex-algo (section 12 of the > >>>>>> draft) it's possible to have a loopback address associated with > >>>>>> only one algo, please correct me if I'm missing or misunderstood > >> something. > >>>>>> > >>>>>>      you are right. That is exactly what is being done for > flex-algo with > >>>>>>      SRv6 - locator is associated with a single algo only. > The proposal > >> uses > >>>>>>      the same concept. > >>>>>> > >>>>>>      thanks, > >>>>>>      Peter > >>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Yingzhen > >>>>>>> > >>>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > >>>>>> on behalf of > >>>>>> ppsenak=40cisco.com@dmarc.ietf.org > > > >>>>>> wrote: > >>>>>>> > >>>>>>>      Gyan, > >>>>>>> > >>>>>>>      On 02/10/2020 18:30, Gyan Mishra wrote: > >>>>>>>> All, > >>>>>>>> > >>>>>>>> With SRv6 and IP based flex algo a generic question as it > >>>> applies > >>>>>> to > >>>>>>>> both. Is it possible to have within a single IGP domain > >>>> different > >>>>>> sets > >>>>>>>> of nodes or segments of the network running different > >>>>>> algorithms. > >>>>>>> > >>>>>>>      absolutely. > >>>>>>> > >>>>>>>> From > >>>>>>>> both drafts it sounds like all nodes have to agree on same > >>>>>> algorithm > >>>>>>>> similar to concept of metric and reference bandwidth all > >>>> have to > >>>>>> have > >>>>>>>> the same style metric and play to the same sheet of music. > >>>>>>> > >>>>>>>      all participating nodes need to agree on the > definition of the > >>>>>> flex-algo > >>>>>>>      and advertise the participation. That's it. > >>>>>>> > >>>>>>>> If there was > >>>>>>>> a way to use multiple algorithms simultaneously based on > >>>> SFC > >>>>>> or services > >>>>>>>> and instantiation of specific algorithm based on service to > >>>> be > >>>>>>>> rendered.  Doing so without causing a routing loop or sub > >>>>>> optimal > >>>>>>>> routing. > >>>>>>> > >>>>>>>      you can certainly use multiple algorithms > simultaneously and > >>>> use > >>>>>> algo > >>>>>>>      specific paths to forward specific traffic over it. > How that > >>>>>>> is > >>>> done > >>>>>>>      from the forwarding perspective depends in which > >>>> forwarding > >>>>>> plane you > >>>>>>>      use. Flex-algo control plane is independent of the > forwarding > >>>>>> plane. > >>>>>>> > >>>>>>> > >>>>>>>> I thought with flex algo that there exists a feature that > on each > >>>>>>>> hop there is a way to specify which algo to use hop by > >>>> hop > >>>>>> similar > >>>>>>>> to a hop by hop policy based routing. > >>>>>>> > >>>>>>>      no, there is no hop-by-hop classification, that is > problematic > >>>> and > >>>>>> does > >>>>>>>      not scale for high speeds. Classification is done at the > >>>> ingress only. > >>>>>>> > >>>>>>>      thanks, > >>>>>>>      Peter > >>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>>      _______________________________________________ > >>>>>>>      Lsr mailing list > >>>>>>> Lsr@ietf.org > >>>>>>> > >>>>>> > https://urldefense.com/v3/__https://nam11.safelinks.protection.outl > >>>>>> oo > >>>>>> k.com/ > >>>>>> ?url=https*3A*2F*2Fwww.ietf.org > *2Fmailman*2Flistinfo*2Flsr&data > >>>>>> = > >>>> 0 > >>>>>> 2 > >>>>>> > >>>> > >> *7C01*7Cyingzhen.qu*40futurewei.com > *7Cfe03124c6e414e067c2008d86781 > >>>>>> > >>>> > >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >>>>>> > >>>> > >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >>>>>> > >>>> > >> > &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR > >>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Lsr mailing list > >>>>>> Lsr@ietf.org > >>>>>> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l > >>>>>> > >> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_ > >> H > >>>>>> z218CE8S8XzlIxAA$ > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > >>>> _ > >>>> > >> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz2 > >> 18C > >>>> E > >>>> 8S8XzlIxAA$ > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > From nobody Mon Oct 12 11:06:05 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06F53A15EF for ; Mon, 12 Oct 2020 11:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.587 X-Spam-Level: X-Spam-Status: No, score=-9.587 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=fdzGBJ6t; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YX9ZqXP3 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 SSG6iXonzQyr for ; Mon, 12 Oct 2020 11:06:01 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D4C3A15ED for ; Mon, 12 Oct 2020 11:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=102767; q=dns/txt; s=iport; t=1602525960; x=1603735560; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R8teOfdKumllfSsNbZPvHVVnqQA15y3C8FF7DuAUN/I=; b=fdzGBJ6t4EJrX2uoUaA4tBRtfSYMMS6E74Yt6zwH1+Qzc4C1+vkBqQhc C0141UBiI3lqMPxIIftVnmiiRgE+WMOwaXmNVyk2QAtrfy1SHfk3M5Ver Tz1mmIpboPeUtcKCGmYwcN7d+kp/CDOeEwrXp0deeU7mn5CPCKRmysDvt o=; X-IPAS-Result: =?us-ascii?q?A0DUBQCrmYRf/51dJa1dAxYGAQEBAQEBBwEBEgEBBAQBA?= =?us-ascii?q?YIPgSMvIy4HcFkvLAqEM4NGA41RihGOaoFCgREDUAULAQEBDQEBGAEMCAIEA?= =?us-ascii?q?QGESgIXgX8CJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgRthVwMhXIBAQEDAQEBE?= =?us-ascii?q?AgJChMBASwEBQIBBAcEAgEIBwcDAwEBAQkYAQYDAgICHwUBCxQJCAIEDgQBG?= =?us-ascii?q?weDBAGBfk0DDiABDpxeAoE5iGF2gTKDAQEBBYE3Ag5Bgn8NC4IQCYE4gnKDb?= =?us-ascii?q?oZWG4IAgRABJxyCTT6CGkIBAQEBAQEVgR0HAQEGMQkBBQcJCAmCUDOCLZAIJ?= =?us-ascii?q?4MbhwYmnBxSCoJoiQGHG4VCgiGCagMfgxWBKohelB2RPYNgiHaCbJJIAgQCB?= =?us-ascii?q?AUCDgEBBYFBKiOBV3AVGiEqAYI+CUcXAg2OHwwXFIM6hRSFQnQCATQCBgEJA?= =?us-ascii?q?QEDCXyLBoE1AYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AgsYcIRT1jv7FJrG8gZKwl/+uwdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNmJ5PdNiu6QuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLXq3y2qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,367,1596499200"; d="scan'208,217";a="553386745" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2020 18:05:59 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 09CI5xto015523 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Oct 2020 18:05:59 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 12 Oct 2020 13:05:58 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 12 Oct 2020 13:05:58 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 12 Oct 2020 13:05:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GYhgbMRTf3by72uGBeQcnPgG70NR3qaz9pQazKFnk98KPPeo14JNAneAqIw4/1qhupmTUyxca32zShICJYfN9q2mBTYFab8RIWDvHVOwl/1grJY2W8P4SJ0xil83P5E11/rZVTZE2j9aJfhn4aSbcGcMbRtWQDgT4fOn20ML9CXpfZmB/B2nMX+QzejHDje0isYo65zBOUuJLnQjA287ibJ+RdXcSfD9R9v8T1cZH0uH0o5G/2vh7CDuQawM6efXmevB5R6DcYexvdZg+1fmQhfweWB8S7hZBx9VVZov4prjjEHcAHN3sUTatcnEyvosj+6t63cLfCfkPQEFs2LJrA== 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=R8teOfdKumllfSsNbZPvHVVnqQA15y3C8FF7DuAUN/I=; b=H+NMMZ4C+bdUtr0Z1hL1thfFql3TvQYRIPQuTeD3jAcMRVFGWAdGBKROf2JsWr0hdKHTaaRd592qgFS78TQY7p0KlD+gOwzZYlhA2tnY78Zy55sbvbrDGDTG9oDyoOUgQLXeE4yG456e7ebjAOMF3ot9G6xXpBeV7oUsEg28eC7jzjhTNF4BU/uE7Ckqn8RjQttK0yW6+EyRjdLkrRGktmDIG0JxcwOva3RLR86Z7Lk5IDmxmcWk1D6sG3q3IWIZ9SbOrrFUolSV6RuZnCSH30F9X+klP42uJgVff0CUvUu+F+aiXNtZ3simZqvRmDNUf9Tsc01a0DarNCuCWv0o1g== 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=R8teOfdKumllfSsNbZPvHVVnqQA15y3C8FF7DuAUN/I=; b=YX9ZqXP3a3aDMwqZhv4KukwdcLqFvuR0njcMxxh7V+Imi+t3FKnWP+zE5CAO54KGf+2jS380EyVqicw7pVwXbreENjRX06gBTvJ8S4CYUVrCXJIgXGF2kGhiD7Z8etmUctBTfUd5hGDnTlrl3wd8rxxjs59sltK2AwVOgUEFNhM= Received: from BL0PR11MB2884.namprd11.prod.outlook.com (2603:10b6:208:72::25) by BL0PR11MB2947.namprd11.prod.outlook.com (2603:10b6:208:33::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Mon, 12 Oct 2020 18:05:56 +0000 Received: from BL0PR11MB2884.namprd11.prod.outlook.com ([fe80::fc53:b753:4d1a:4293]) by BL0PR11MB2884.namprd11.prod.outlook.com ([fe80::fc53:b753:4d1a:4293%6]) with mapi id 15.20.3455.029; Mon, 12 Oct 2020 18:05:56 +0000 From: "Acee Lindem (acee)" To: Gyan Mishra CC: Aijun Wang , Aijun Wang , "Peter Psenak (ppsenak)" , "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt Thread-Index: AQHWljqhPwTJc6J3hEmS7XUA0fh0y6l/U3AAgAACPQCAAABHAIABIzwAgABWLoCADdcbgIAA1DUAgACqfwCAAEu2gIACaXcAgAE6xwA= Date: Mon, 12 Oct 2020 18:05:56 +0000 Message-ID: References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa0be56d-cfe3-4aea-e3dd-08d86ed9778e x-ms-traffictypediagnostic: BL0PR11MB2947: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2276; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vcK35uRZCdehE6YUNlighDV3ybRIAJSD9LwBXDacF59K060EIyG8fvOPPJ3h+mWVPSCzuasKLm8NHrhG6q6uPQxVZk6orueqd5Vi2LZHsiw54n9QUEvIwdsZybKt8e+Oeh84z5ijyMZG0EztS1cbcliLxEhW4VV9S1Sy47x+qpxyNzWzt8LwaZOUyOvrrQb4E6XFQzmEy86JWo4zz5j7FDnIq6Ll9/HvWVYMTUuLARhfUfzS9YVgdTSb4YBpRJfSfQXcl8Z/kAP07yUgbmewufzOBVRMk4sxYpbQC8kxlJKcpilTHsmeiqj9yP1ht8f6YwH+5IsBKzA0dRSQUgZWymhRICHBYqapFU0fEgz4e34= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB2884.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(346002)(376002)(396003)(39860400002)(5660300002)(966005)(8676002)(6512007)(8936002)(4326008)(6486002)(86362001)(2616005)(66946007)(478600001)(166002)(2906002)(66446008)(15650500001)(54906003)(91956017)(316002)(64756008)(66556008)(66574015)(76116006)(66476007)(186003)(6916009)(30864003)(71200400001)(33656002)(83380400001)(36756003)(53546011)(6506007)(26005)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ZibQrFG0gjcE1+pKZPEcOIVhHokmcgB5twwZdv9h7fT1LbtNBqL2C6FO6KsjVUvsM8B6eTWcvC8omLP2IcDOSNCCalbViS4twJFJLIcEf3FOciO4+nh/zFSjUMPWkHJh7UJ2dWCQcNYNrtgyYtapL9BSYmwwUjb6Sr7o9aIhBccUQgSdkVOJ4QV/bsDDrdQvukXXWcQv+qLHLqstfcKP1Ukh+s7nQ7MJLyV+18w1tTDtAhixqYhSuUHj7YgUAXS8JCzPQphQPrhC9n4jCaUPiuoBHA10IC1omDN1Ro1+ZN5gPy1g5CbJFHHAFWK/bTXm8FjrEABtUxyEVCNkEaBenTprvDnskvo2zOWz6jFiUBlCHn/JW82hUbpNekcvvD3Ln9MbXxjaesxAnXJ8mZnz6390VUXzNbZ/RUM4U9ogBZNxXOPsOOTMHFvBkl8gzVzhlqVk+7K8WiAVmvR1KRo07vN4QJL5sA1wwJX5w8UMaJ0FUE/AZw1JJfvEH/1TEF4xzOPCU6TlOiD9OxbN97KtjcH3/yXPMx40UcChMn/h60x7ZEHi/7IwZcXLB4viyiFnpM3n/LOZM+jFMR7VRo3Unh89Q3JMvjTOu8/siAtgSECjLjRTuQHcvodXJNMN7lWqki/uW83ApqiBgW7f8crWRw== Content-Type: multipart/alternative; boundary="_000_F50BDB444E474B02BE69EAA05433DE1Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB2884.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa0be56d-cfe3-4aea-e3dd-08d86ed9778e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2020 18:05:56.3758 (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: tmEmLl5k0YwEUIVPAKJXYcCMxjO+8fwcd8TLVX1ndwA5yFmNeVwa6KI9J/g8s2SI X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2947 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 18:06:05 -0000 --_000_F50BDB444E474B02BE69EAA05433DE1Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlYWtpbmcgV0cgbWVtYmVyOg0KDQpIaSBHeWFuLCBBaWp1biwNCg0KRXZlbiBpZiBJIGFncmVl ZCB3aXRoIHlvdXIgdXNlIGNhc2UgYXNzdW1pbmcgYSBwYXNzaXZlIGludGVyZmFjZSBkZW5vdGVz IHRoZSBib3VuZGFyeSBiZXR3ZWVuIHR3byBkb21haW5zIGFzIHNob3duIGluIGZpZ3VyZSAxIGlu IHlvdXIgZHJhZnQgKHdoaWNoIEkgZG9u4oCZdCksIHlvdSBzdGlsbCBzaG91bGQgbm90IGJlIHRy eWluZyB0byBoYWNrIHRoZSBwcmVmaXhlcyB3aXRoIHdoYXQgaXMgaW5oZXJlbnRseSBsaW5rIGF0 dHJpYnV0ZS4gQ2FuIEkgc3RhdGUgdGhpcyBhbnltb3JlIHNpbXBseSBvciBhcmUgeW91IGFyZSBq dXN0IGdvaW5nIHRvIHJlc3RhdGUgeW91ciByZXF1aXJlbWVudHMgYWdhaW4/Pz8NCg0KQWNlZQ0K DQpGcm9tOiBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPg0KRGF0ZTogU3VuZGF5 LCBPY3RvYmVyIDExLCAyMDIwIGF0IDM6MTkgUE0NClRvOiBBY2VlIExpbmRlbSA8YWNlZUBjaXNj by5jb20+DQpDYzogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4sIEFpanVu IFdhbmcgPHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuPiwgIlBldGVyIFBzZW5hayAocHBzZW5hayki IDxwcHNlbmFrQGNpc2NvLmNvbT4sICJsc3JAaWV0Zi5vcmciIDxsc3JAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2Fu Zy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dA0KDQoNCkhpIEFjZWUNCg0K SSBiZWxpZXZlIHdoYXQgQWlqdW4gaXMgdHJ5aW5nIHRvIGV4cGxhaW4gaXMgdGhhdCB0aGUgcHJp bWFyeSBwdXJwb3NlIG9mIFBDRSBmb3IgYWN0aXZlIG9yIHBhc3NpdmUgcGF0aCBjb21wdXRhdGlv biBpcyBmb3IgaW50ZXItYXMgUlNWUC1URSBQQ0FMQyBwYXRoIGNvbXB1dGF0aW9uIG9yIFNSLVRF IHBhdGggY29tcHV0YXRpb24uICBTbyBQQ0UgaXMgc29sdmluZyBhIHdlbGwga25vd24gUENBTEMg YmluIHBhY2tpbmcgcHJvYmxlbSBkdWUgdG8gcGNhbGMgb3ZlciBzdWJzY3JpYmluZyBSU1ZQIHR1 bm5lbCBiYW5kd2lkdGggd2hpY2ggaXMgaW5oZXJlbnQgYW4gUlNWUCBpc3N1ZSwgYnV0IGEgYmln Z2VyIHByb2JsZW1hdGljIGlzc3VlIGlzIHdpdGggYmVpbmcgYWJsZSB0byBidWlsZCBhbiBpbnRl ci1hcyBURSBwYXRoIHdpdGggYSBzaW5nbGUgb3IgbXVsdGlwbGUgUENFIGNvbnRyb2xsZXJzIHRo YXQgY2FuIHRha2UgdGhlIExTREIgbGluayBhdHRyaWJ1dGVzIGluIHRoZSBURURzIGRCIG9wYXF1 ZSBMU0FzIGluIHRoZSBvc3BmIGNhc2UgYW5kIElTSVMgVEUgVExWcyBhbmQgcmVidWlsZCB0aGUg dG9wb2xvZ3kgdG9wb2xvZ3kgZnJvbSBlYWNoIFRFIGRvbWFpbiB0byBiZSBhYmxlIHRvIGJ1aWxk IGEgY29uZ3J1ZW50IGVuZCB0byBlbmQgUlNWUCBURSBvciBTUi1URSB0cmFmZmljIHN0ZWVyZWQg cGF0aCBpbnN0YW50aWF0aW9uLg0KDQpXaXRob3V0IHRoZSB1c2Ugb2YgUENFIGNvbnRyb2xsZXJz IGFzIHRoZSBMU0RCIGxpbmsgYXR0cmlidXRlIGluZm9ybWF0aW9uIGlzIG5vdCBrbm93biBhcyBS U1ZQIGxvb3NlIEVSTyBzdGF0aWMgbHNwIGlzIGJ1aWx0IG9yIFNSIFNSLVRFIHByZWZpeCBzaWQg bG9vc2UgcGF0aCBpcyBidWlsdCwgZmFpbG92ZXIgZHVlIHRvIGNyYW5rIGJhY2sgaXMgaW1wYWN0 ZWQgZm9yIHJlcm91dGUsIGR1ZSB0byBub3QgaGF2aW5nIGEgY29tcGxldGUgZGVwaWN0aW9uIG9m IHRoZSBvdGhlciBBUyBMaW5rIHN0YXRlIHRvcG9sb2d5IGJ5IHRoZSBoZWFkIGVuZCBvciBTUiBz b3VyY2Ugbm9kZS4NCg0KU28gdG8gYnVpbGQgdGhhdCBlbnRpcmUgZW5kIHRvIGVuZCBpbnRlci1h cyBwYXRoIGZvciB0aGF0IGVuZCB0byBlbmQgUlNWUCBURSBvciBTUi1URSBwYXRoIGluc3RhbnRp YXRpb24gaXQgaXMgY3JpdGljYWwgdG8gaW5kZW50aWZ5IHRoZSBpbnRlci1hcyBsaW5rIGVCR1Ag dGllIGxpbmsgdGhhdCBtYXkgaGF2ZSBzdGF0aWMgcm91dGVzIG9yIEJHUCBMVSBmb3IgUlNWUCBo ZWFkIGVuZCB0byB0YWlsIGVuZCByZWFjaGFiaWxpdHkgYW5kIFNSLVRFIHJlYWNoYWJpbGl0eSB0 byBidWlsZCBvdXQgdGhlIGVuZCB0byBlbmQgcGF0aCBpbnN0YW50aWF0aW9uLiAgU28gdGhlIEJH UC1MUyB0YXNrIHRvICByZWJ1aWxkIHRoZSBsc2RiIHRvcG9sb2d5IG9mIGVhY2ggaW50ZXIgY29u bmVjdGVkIEFTIHRoYXQgdGhlIFJTVlAgVEUgb3IgU1ItVEUgc3RlZXJlZCBwYXRoIHRyYXZlcnNl cywgd2UgbmVlZCB0aGUgYWNjdXJhdGUgZGVwaWN0aW9uIGFuZCB0aGF0IGluY2x1ZGVzIHRoZSBJ ZGVudGlmaWNhdGlvbiBvZiB0aGUgIGNyaXRpY2FsIGludGVyLWFzIHRpZSBsaW5rIGVCR1AgcGVl cmluZyBsaW5rIHRoYXQgaXMgcGFzc2l2ZSBmb3IgdGhlIFBDRSBwYXRoIGNvbXB1dGF0aW9uIGxv Z2ljIGZvciB0aGUgZW5kIHRvIGVuZCBpbnRlci1hcyBwYXRoIGluc3RhbnRpYXRpb24uDQoNCkFz IGZvciBvdGhlciBpbnRlcmZhY2VzIHVzaW5nIHBhc3NpdmUgaW4gdGhlIGNvbnRleHQgb2YgYSBv cGVyYXRvciBzZXJ2aWNlIHByb3ZpZGVyIG9yIGVudGVycHJpc2UgY29yZSBQIGFuZCBQRSByb3V0 ZXJzIGFsbCBsaW5rcyBhcmUgdHJhbnNpdCB3aXRoIG5laWdoYm9ycyBleGNlcHQgdGhlIGludGVy LWFzIHRpZSBzbyBoYXZpbmcgdGhpcyBuZXcgSUdQIFRMViB3aWxsIGhlbHAgdG8gdGhhdCBlbmQu ICBJbiB0aGUgb3BlcmF0b3Ig4oCcY29yZeKAnSBuZXR3b3JrIGlmIHRoZXJlIGFyZSBvdGhlciAg aW50ZXJmYWNlcyB0aGF0IGRvbuKAmXQgbmVlZCB0byBiZSBhZHZlcnRpc2VkIGFzIHN0dWIsIHRo ZXkgY2FuIGVhc2lseSBiZSBleGNsdWRlZCBmcm9tIGJlaW5nIGFkZGVkIGludG8gSUdQLg0KDQpL aW5kIFJlZ2FyZHMNCg0KR3lhbg0KDQpPbiBTYXQsIE9jdCAxMCwgMjAyMCBhdCA2OjI5IEFNIEFj ZWUgTGluZGVtIChhY2VlKSA8YWNlZT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkhpIEFpanVuLA0KDQpGcm9tOiBB aWp1biBXYW5nIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPG1haWx0bzp3YW5nYWlqdW5AdHNp bmdodWEub3JnLmNuPj4NCkRhdGU6IEZyaWRheSwgT2N0b2JlciA5LCAyMDIwIGF0IDk6NTggUE0N ClRvOiBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4s ICJQZXRlciBQc2VuYWsgKHBwc2VuYWspIiA8cHBzZW5ha0BjaXNjby5jb208bWFpbHRvOnBwc2Vu YWtAY2lzY28uY29tPj4sICdBaWp1biBXYW5nJyA8d2FuZ2FqM0BjaGluYXRlbGVjb20uY248bWFp bHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPj4NCkNjOiAibHNyQGlldGYub3JnPG1haWx0bzps c3JAaWV0Zi5vcmc+IiA8bHNyQGlldGYub3JnPG1haWx0bzpsc3JAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUkU6IFtMc3JdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmct bHNyLXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQNCg0KSGksIEFjZWU6DQoNCkZy b206IGxzci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZz4gW21h aWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgQWNlZSBMaW5kZW0gKGFjZWUpDQpTZW50OiBTYXR1cmRheSwgT2N0b2JlciAx MCwgMjAyMCAzOjQ4IEFNDQpUbzogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5j bjxtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4+OyBQZXRlciBQc2VuYWsgKHBwc2Vu YWspIDxwcHNlbmFrQGNpc2NvLmNvbTxtYWlsdG86cHBzZW5ha0BjaXNjby5jb20+PjsgJ0FpanVu IFdhbmcnIDx3YW5nYWozQGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86d2FuZ2FqM0BjaGluYXRlbGVj b20uY24+Pg0KQ2M6IGxzckBpZXRmLm9yZzxtYWlsdG86bHNyQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtMc3JdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctbHNy LXBhc3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQNCg0KU3BlYWtpbmcgYXMgV0cgbWVt YmVyOg0KDQpIaSBBaWp1biwNCg0KRnJvbTogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVh Lm9yZy5jbjxtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4+DQpEYXRlOiBUaHVyc2Rh eSwgT2N0b2JlciA4LCAyMDIwIGF0IDExOjA5IFBNDQpUbzogQWNlZSBMaW5kZW0gPGFjZWVAY2lz Y28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+LCAiUGV0ZXIgUHNlbmFrIChwcHNlbmFrKSIg PHBwc2VuYWtAY2lzY28uY29tPG1haWx0bzpwcHNlbmFrQGNpc2NvLmNvbT4+LCAnQWlqdW4gV2Fu ZycgPHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuPG1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5j bj4+DQpDYzogImxzckBpZXRmLm9yZzxtYWlsdG86bHNyQGlldGYub3JnPiIgPGxzckBpZXRmLm9y ZzxtYWlsdG86bHNyQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbTHNyXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRy aWJ1dGUtMDQudHh0DQoNCg0KSGksIEFjZWU6DQoNClNvcnJ5IGZvciB0aGUgcHJldmlvdXMgcHJ1 bmVkIG1haWwuIExldCdzIHJlcGx5IHlvdSBhZ2FpbiBhbG9uZyB5b3VyIG9yaWdpbmFsIHF1ZXN0 aW9uLg0KDQpQbGVhc2Ugc2VlIGlubGluZS5bV0FKXQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IGxzci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsc3ItYm91bmNlc0Bp ZXRmLm9yZz4gW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFjZWUg TGluZGVtIChhY2VlKQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMjAgNzo0NyBQ TQ0KVG86IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY248bWFpbHRvOndhbmdh aWp1bkB0c2luZ2h1YS5vcmcuY24+PjsgUGV0ZXIgUHNlbmFrIChwcHNlbmFrKSA8cHBzZW5ha0Bj aXNjby5jb208bWFpbHRvOnBwc2VuYWtAY2lzY28uY29tPj47ICdBaWp1biBXYW5nJyA8d2FuZ2Fq M0BjaGluYXRlbGVjb20uY248bWFpbHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPj4NCkNjOiBs c3JAaWV0Zi5vcmc8bWFpbHRvOmxzckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTHNyXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVy ZmFjZS1hdHRyaWJ1dGUtMDQudHh0DQoNCg0KDQpIaSBBaWp1biwNCg0KT3RoZXIgdGhhbiB5b3Vy IGlsbC1jb25jZWl2ZWQgdG9wb2xvZ3kgZGlzY292ZXJ5IGhldXJpc3RpYw0KDQpbV0FKXSBUaGUg dG9wb2xvZ3kgZGlzY292ZXJ5IGhldXJpc3RpYyBpcyBub3Qgc3VpdGFibGUgZm9yIHRoZSBjb3Ju ZXIgdXNlIGNhc2Ugd2hlbiB0aGUgdW5udW1iZXJlZCBpbnRlcmZhY2UgaXMgdXNlZCwgYXMgZXhw bGFpbmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWxzci1vc3Bm LXByZWZpeC1vcmlnaW5hdG9yLTA2I2FwcGVuZGl4LUIuICBJZiB5b3UgZG9u4oCZdCBhZ3JlZSwg d291bGQgeW91IGxpa2UgdG8gaWxsdXN0cmF0ZSBvdGhlciBub24tYXBwbGljYWJsZSBzY2VuYXJp b3M/DQoNCg0KDQpSaWdodCDigJMgYW5kIG5vYm9keSBvdGhlciB0aGFuIHlvdXJzZWxmIGJlbGll dmVzIHRoZSBJR1BzIHNob3VsZCBiZSBtb2RpZmllZCB0byBleHBvc2UgdGhlIGFic3RyYWN0ZWQg dG9wb2xvZ3kgb2YgYW4gYXJlYSBvdXRzaWRlIHRoYXQgYXJlYS4NCg0KW1dBSl0gIFRoZSBtb2Rp ZmljYXRpb24gZG9lc27igJl0IGNoYW5nZSB0aGUgd2F5IGFuZCBjb21wbGV4aXR5IG9mIHJvdXRl IGNhbGN1bGF0aW9uIHdpdGhpbiBJR1AuIEl0IGp1c3QgcGlnZ3liYWNrIHNvbWUgZXh0cmEgaW5m b3JtYXRpb24sIHRoZSBidWxrIG9mIHRoZSByZWNvbnN0cnVjdGlvbiB3b3JrIGlzIGRvbmUgYnkg dGhlIGNvbnRyb2xsZXIuICBTdWNoIGV4dHJhIGluZm9ybWF0aW9uIGNhbiBhbHNvIGhhdmUgb3Ro ZXIgdXNhZ2UsIGFzIGRlc2NyaWJlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNiNzZWN0aW9uLTENCg0KQW5kLCB0 aGUgcHJvcG9zYWwgZGVzY3JpYmVkIGluIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0IGlzIGRp ZmZlcmVudCB3aXRoIHRoZSBwcm9ibGVtIHlvdSBjb25jZXJuZWQuICBJdCBoYXMgbm8gcmVsYXRp b24gd2l0aCB0aGUgYWJzdHJhY3RlZCB0b3BvbG9neSBvZiBhbiBhcmVhLiAgTWF5YmUgeW91IGFy ZSBjb25mdXNlZCBieSB0aGVzZSB0d28gZHJhZnRzPw0KDQoNCg0KSXQgaXMgYSBzaW1pbGFyIHBy b2JsZW0uIFlvdSBhcmUgc3RpbGwgdHJ5aW5nIHRvIG92ZXJsb2FkIHRoZSBwcmVmaXggYWR2ZXJ0 aXNlbWVudHMgd2l0aCBhIGxpbmsgYXR0cmlidXRlIChwYXNzaXZlIGludGVyZmFjZSkgc28gdGhh dCBpdCBjYW4gYmUgY29udmV5ZWQgb3V0c2lkZSB0aGUgZG9tYWluLiBXZSBjZXJ0YWlubHkgd291 bGRu4oCZdCB3YXN0ZSBhIGxpbWl0ZWQgcHJlZml4IGZsYWcgb24gdGhpcyBwYXJvY2hpYWwgYXBw bGljYXRpb24uDQoNCg0KDQoNCg0KWW91IGNhbiBzb2x2ZSB0aGUgcHJvYmxlbSB3aXRoIEJHUC1M UyBzZXNzaW9uKHMpIGJldHdlZW4gdGhlIHJvdXRlciB3aXRoIGEgQkdQLUxTIHNlc3Npb24gdG8g dGhlIGNvbnRyb2xsZXIgYW5kIGEgcm91dGVyIGluIGVhY2ggYXJlYSB3L28gIGEgcm91dGVyIHdp dGggYSBCR1AtTFMgc2Vzc2lvbiB0byB0aGUgY29udHJvbGxlci4NCg0KW1dBSl0gVGhpcyBpcyBw b3NzaWJsZSwgYnV0IG5vdCBlZmZpY2llbnQuIEZvciBvcGVyYXRpb24sIHdlIG11c3QgYWxzbyBj b25zaWRlciB0aGUgY29uZmlndXJhdGlvbi9hZG1pbmlzdHJhdGlvbiBvdmVyaGVhZC4gIEJHUC1M UyBpcyBkZXNpZ25lZCBtYWlubHkgZm9yIHRoZSBub3J0aGJvdW5kIHByb3RvY29sLCBub3QgZWFz dC13ZXN0IHByb3RvY29sLg0KDQoNCg0Kd2hhdCBvdGhlciBwb3NzaWJsZSByZWFzb24gd291bGQg dGhlcmUgYmUgZm9yIGFzc29jaWF0aW5nIHRoZSBwYXNzaXZlIGF0dHJpYnV0ZSB3aXRoIGEgcHJl Zml4Pw0KDQpbV0FKXSBUbyBrbm93IHRoZSBib3VuZGFyeSBvZiB0aGUgSUdQIGRvbWFpbi4gQWZ0 ZXIga25vd2luZyB0aGUgYm91bmRhcnksIHRoZSBjb250cm9sbGVyIGNhbiBzYWZlbHkgYXBwbHkg YW5kIGNoZWNrIHRoZSBuZXR3b3JrIHNlY3VyaXR5IHBvbGljeSwgdGhlIGluYm91bmQgdHJhZmZp YyBjb250cm9sIHBvbGljeSBldGMuDQoNCg0KDQpJdCByZWFsbHkgaXNu4oCZdCByZWxldmFudCwg YnV0IEkgaGF2ZSB0byBhc2vigKYuIEhvdyBkb2VzIHRoZSBwcmVzZW5jZSBvZiBhIHByZWZpeCBh c3NvY2lhdGVkIHdpdGggYSBwYXNzaXZlIGludGVyZmFjZSBhbGxvdyB5b3UgdG8gbWFrZSB0aGlz IGRlZHVjdGlvbj8NCg0KW1dBSl0gUGFzc2l2ZSBpbnRlcmZhY2VzIGFyZSBkZXBsb3llZCBtYWlu bHkgYXQgdGhlIGJvdW5kYXJ5IG9mIElHUCBkb21haW4uICBJcyB0aGVyZSBhbnkgb3RoZXIgZXhj ZXB0aW9uPw0KDQpXaGlsZSBwYXNzaXZlIGludGVyZmFjZXMgYXJlIG5vdCBzdGFuZGFyZGl6ZWQs IHRoZXJlIGlzIG5vdGhpbmcgdGhhdCBsaW1pdHMgdGhlaXIgdXNhZ2UgdG8gYW4gSUdQIGJvdW5k YXJ5LiBUaGV5IGNhbiBhbmQgYXJlIGRlcGxveWVkIG9uIGFueSBpbnRlcmZhY2Ugd2hlcmUgYWRq YWNlbmNpZXMgYXJlIG5vdCB0byBiZSBmb3JtZWQgKGUuZy4sIGEgc3R1YiBzdWJuZXQgY29udGFp bmluZyBob3N0cykuDQoNCg0KDQpUaGFua3MsDQpBY2VlDQoNCg0KDQpUaGFua3MsDQoNCkFjZWUN Cg0KDQoNClRoYW5rcywNCg0KQWNlZQ0KDQoNCg0KT24gOS8yOS8yMCwgMTA6MzkgUE0sICJBaWp1 biBXYW5nIiA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbjxtYWlsdG86d2FuZ2FpanVuQHRzaW5n aHVhLm9yZy5jbj4+IHdyb3RlOg0KDQoNCg0KICAgIEhpLCBBY2VlIGFuZCBQZXRlcjoNCg0KICAg IFBhc3NpdmUgaW50ZXJmYWNlIGlzIG1haW5seSB1c2VkIGF0IHRoZSBlZGdlIG9mIHRoZSBuZXR3 b3JrLCB3aGVyZSB0aGUgdW5udW1iZXJlZCBpbnRlcmZhY2Ugd2lsbCBub3QgYmUgdXNlZC4NCg0K ICAgIEFuZCB0aGUgaW5mb3JtYXRpb24gdG8gZmxhZyB0aGUgcGFzc2l2ZSBpbnRlcmZhY2VzIGlz IGZvciBwb3NpdGlvbmluZyB0aGUgYXJlYSBib3VuZGFyeSwgbm90IGNvbmZsaWN0IHdpdGggdGhl IGFic3RyYWN0IGNhcGFiaWxpdGllcyBvZiB0aGUgYXJlYSBpbnNpZGUuDQoNCg0KDQoNCg0KICAg IEJlc3QgUmVnYXJkcw0KDQoNCg0KICAgIEFpanVuIFdhbmcNCg0KICAgIENoaW5hIFRlbGVjb20N Cg0KDQoNCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQogICAgRnJvbTogbHNyLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmxzci1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0gKGFjZWUpDQoNCiAgICBT ZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMjAgOToxNiBQTQ0KDQogICAgVG86IFBldGVy IFBzZW5hayA8cHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cHBzZW5h az00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBBaWp1biBXYW5nIDx3YW5nYWlqdW5AdHNp bmdodWEub3JnLmNuPG1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPj47ICdBaWp1biBX YW5nJyA8d2FuZ2FqM0BjaGluYXRlbGVjb20uY248bWFpbHRvOndhbmdhajNAY2hpbmF0ZWxlY29t LmNuPj4NCg0KICAgIENjOiBsc3JAaWV0Zi5vcmc8bWFpbHRvOmxzckBpZXRmLm9yZz4NCg0KICAg IFN1YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUtMDQudHh0DQoNCg0KDQogICAg U3BlYWtpbmcgYXMgV0cgbWVtYmVyOg0KDQoNCg0KICAgIEhpIEFpanVuLCBQZXRlciwNCg0KICAg IEkgYWdyZWUgd2l0aCBQZXRlciAtIG9uZSBvZiB0aGUgbWFpbiBtb3RpdmF0aW9ucyBmb3IgaGF2 aW5nIGFyZWFzIGlzIHRvIGFic3RyYWN0IHRoZSB0b3BvbG9neSB3aXRoaW4gdGhlIGFyZWEuIE5v dyB5b3UncmUgdHJ5aW5nIHRvIHN1cHBsYW50IHRoaXMgIC0gb25lIHRvcG9sb2dpY2FsIGRldGFp bCBhdCBhIHRpbWUgd2l0aCBpbGwtY29uY2VpdmVkIElHUCBmZWF0dXJlcy4NCg0KICAgIFRoYW5r cywNCg0KICAgIEFjZWUNCg0KDQoNCiAgICBPbiA5LzI5LzIwLCA1OjE1IEFNLCAiTHNyIG9uIGJl aGFsZiBvZiBQZXRlciBQc2VuYWsiIDxsc3ItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg cHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86bHNyLWJvdW5jZXNAaWV0 Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIwcHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRm Lm9yZz4+IHdyb3RlOg0KDQoNCg0KICAgICAgICBIaSBBaWp1biwNCg0KDQoNCiAgICAgICAgT24g MjkvMDkvMjAyMCAxMTowNywgQWlqdW4gV2FuZyB3cm90ZToNCg0KICAgICAgICA+IEhpLCBQZXRl cjoNCg0KICAgICAgICA+DQoNCiAgICAgICAgPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQoN CiAgICAgICAgPiAxLiBGb3IgQkdQLUxTIGRlcGxveW1lbnQsIHRoZXJlIG5vcm1hbGx5IG9ubHkg YmUgb25lIHJvdXRlciB0aGF0IHdpdGhpbiB0aGUNCg0KICAgICAgICA+IElHUCBkb21haW4gdG8g cmVwb3J0IHRoZSB0b3BvbG9neSBpbmZvcm1hdGlvbiwgdGhpcyByb3V0ZXIgc2hvdWxkIGtub3cg c3VjaA0KDQogICAgICAgID4gcGFzc2l2ZSBsaW5rcyB3aGljaCBleGlzdHMgbWFpbmx5IG9uIG90 aGVyIGJvcmRlciByb3V0ZXJzIHZpYSB0aGUgSUdQDQoNCiAgICAgICAgPiBwcm90b2NvbC4gVGhp cyBpcyBtYWluIHJlYXNvbiB0byBleHRlbnNpb24gdGhlIElHUCBwcm90b2NvbC4gPiAyLiBGb3Ig dGhlIHNvbHV0aW9uLCBub3JtYWxseSwgdGhlIGxpbmsgd2l0aGluIHRoZSBJR1AgY29ubmVjdCB0 d28NCg0KICAgICAgICBlbmRzLCBidXQNCg0KICAgICAgICA+IHBhc3NpdmUgaW50ZXJmYWNlIGlz IHNwZWNpYWwgYW5kIG5vdCBmYWxsIGluIHRoaXMgc3BhY2UuIFdlIGhhdmUgc3R1ZGllZCB0aGUN Cg0KICAgICAgICA+IGN1cnJlbnQgVExWcyB0aGF0IGZvciBsaW5rLCBhbmQgZmluZCBubyBzdWl0 YWJsZSBjb250YWluZXIgdG8gYXBwZW5kIHRoaXMNCg0KICAgICAgICA+IGluZm9ybWF0aW9uLiBU aGlzIGlzIHRoZSByZWFzb24gdGhhdCB3ZSBzZWxlY3QgdGhlIFRMVnMgdGhhdCBhc3NvY2lhdGVk IHdpdGgNCg0KICAgICAgICA+IFByZWZpeC4NCg0KDQoNCiAgICAgICAgaWYgdGhlIGxpbmsgaXMg dW5udW1iZXJlZCwgeW91ciBzb2x1dGlvbiBkb2VzIG5vdCB3b3JrLiBBcyBJIHNhaWQsIGlmDQoN CiAgICAgICAgeW91IG5lZWQgYSBrbm93bGVkZ2UgYWJvdXQgdGhlIGxpbmssIHlvdSBjYW4gbm90 IGFkdmVydGlzZSBpdCBhcyBhIHByZWZpeC4NCg0KDQoNCiAgICAgICAgdGhhbmtzLA0KDQogICAg ICAgIFBldGVyDQoNCg0KDQoNCg0KICAgICAgICA+DQoNCiAgICAgICAgPj5Gcm9tIG90aGVyIFBP ViwgdGhlIE9TUEZ2MyBkZWZpbmVzIG5vdyB0aGUgIkludHJhLUFyZWEtUHJlZml4IExTQSIsIHdo aWNoDQoNCiAgICAgICAgPiBpc29sYXRlIHRoZSBwcmVmaXggaW5mb3JtYXRpb24gdGhhdCBhc3Nv Y2lhdGVkIHdpdGggbGluayBpbnRvIHRoaXMNCg0KICAgICAgICA+IGNvbnRhaW5lciwgY29udGFp bnMgdGhlIHN0dWIgbGluaywgbG9jYWwgaW50ZXJmYWNlIGluZm9ybWF0aW9uIGV0Yy4gUHV0IHN1 Y2gNCg0KICAgICAgICA+IGF0dHJpYnV0ZSBhbG9uZyB3aXRoIHRoZSBwcmVmaXggaXMgdGhlbiBh Y2NlcHRhYmxlPw0KDQogICAgICAgID4NCg0KICAgICAgICA+DQoNCiAgICAgICAgPiBCZXN0IFJl Z2FyZHMNCg0KICAgICAgICA+DQoNCiAgICAgICAgPiBBaWp1biBXYW5nDQoNCiAgICAgICAgPiBD aGluYSBUZWxlY29tDQoNCiAgICAgICAgPg0KDQogICAgICAgID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCg0KICAgICAgICA+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzps c3ItYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFBldGVyDQoNCiAgICAgICAgPiBQc2VuYWsNCg0KICAgICAgICA+IFNlbnQ6IFR1ZXNk YXksIFNlcHRlbWJlciAyOSwgMjAyMCA0OjI5IFBNDQoNCiAgICAgICAgPiBUbzogQWlqdW4gV2Fu ZyA8d2FuZ2FqM0BjaGluYXRlbGVjb20uY248bWFpbHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNu Pj4NCg0KICAgICAgICA+IENjOiBsc3JAaWV0Zi5vcmc8bWFpbHRvOmxzckBpZXRmLm9yZz4NCg0K ICAgICAgICA+IFN1YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvcg0KDQogICAgICAgID4gZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmli dXRlLTA0LnR4dA0KDQogICAgICAgID4NCg0KICAgICAgICA+IEhpIEFpanVuLA0KDQogICAgICAg ID4NCg0KICAgICAgICA+IGhlcmUncyBteSBjb21tZW50czoNCg0KICAgICAgICA+DQoNCiAgICAg ICAgPiBUaGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0IGlzIHRvIGFkdmVydGlzZSBwYXNzaXZlIGxp bmtzLg0KDQogICAgICAgID4NCg0KICAgICAgICA+IDEuIEknbSBub3Qgc3VyZSB0aGUgcHJvYmxl bSBuZWVkcyB0byBiZSBzb2x2ZWQgYnkgSUdQcy4gSSB0ZW5kIHRvIGJlbGlldmUNCg0KICAgICAg ICA+IGlldGYtaWRyLWJncGxzLWludGVyLWFzLXRvcG9sb2d5LWV4dCBpcyBzdWZmaWNpZW50Lg0K DQogICAgICAgID4NCg0KICAgICAgICA+IDIuIHRoZSBzb2x1dGlvbiB0aGF0IHlvdSBwcm9wb3Nl ZCBpcyB3cm9uZy4gWW91IGFyZSB0cnlpbmcgdG8gZGVyaXZlDQoNCiAgICAgICAgPiB0b3BvbG9n aWNhbCBkYXRhIGFib3V0IHRoZSBwYXNzaXZlIGxpbmtzIGZyb20gdGhlIHByZWZpeCBhZHZlcnRp c2VtZW50Lg0KDQogICAgICAgID4gVGhpcyBpcyBzZW1hbnRpY2FsbHkgaW5jb3JyZWN0IGFuZCBv bmx5IHdvcmtzIHVuZGVyIHZlcnkgc3BlY2lmaWMgY29uZGl0aW9uLg0KDQogICAgICAgID4gSWYg eW91IG5lZWQgdG8gYWR2ZXJ0aXNlIGEgbGluaywgYWR2ZXJ0aXNlIGl0IGFzIGEgInNwZWNpYWwi DQoNCiAgICAgICAgPiBsaW5rLCBub3QgYXMgYSAic3BlY2lhbCIgcHJlZml4Lg0KDQogICAgICAg ID4NCg0KICAgICAgICA+IHRoYW5rcywNCg0KICAgICAgICA+IFBldGVyDQoNCiAgICAgICAgPg0K DQogICAgICAgID4gT24gMjkvMDkvMjAyMCAwMzoxNywgQWlqdW4gV2FuZyB3cm90ZToNCg0KICAg ICAgICA+PiBIaSwgUGV0ZXI6DQoNCiAgICAgICAgPj4NCg0KICAgICAgICA+PiBXb3VsZCB5b3Ug bGlrZSB0byByZXZpZXcgYW5kIGdpdmUgY29tbWVudHMgb24gdGhlIHVwZGF0ZXMgdmVyc2lvbiBv ZiB0aGlzDQoNCiAgICAgICAgPiBkcmFmdD8NCg0KICAgICAgICA+PiBXZSBoYXZlIGFsc28gYWRk ZWQgdGhlIHByb3RvY29sIGV4dGVuc2lvbiBwcm9wb3NhbCBmb3IgT1NQRnYzLg0KDQogICAgICAg ID4+DQoNCiAgICAgICAgPj4gVGhlIHVwZGF0ZSB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQgY2FuIHJl ZmVyIHRvDQoNCiAgICAgICAgPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZQ0KDQogICAgICAgID4+IC1hdHRyaWJ1 dGUNCg0KICAgICAgICA+PiBUaGFua3MgaW4gYWR2YW5jZS4NCg0KICAgICAgICA+Pg0KDQogICAg ICAgID4+DQoNCiAgICAgICAgPj4gQmVzdCBSZWdhcmRzDQoNCiAgICAgICAgPj4NCg0KICAgICAg ICA+PiBBaWp1biBXYW5nDQoNCiAgICAgICAgPj4gQ2hpbmEgVGVsZWNvbQ0KDQogICAgICAgID4+ DQoNCiAgICAgICAgPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCiAgICAgICAgPj4+ IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCg0KICAgICAgICA+Pj4g U2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjgsIDIwMjAgMzoxNyBQTQ0KDQogICAgICAgID4+PiBU bzogWmhpYm8gSHUgPGh1emhpYm9AaHVhd2VpLmNvbTxtYWlsdG86aHV6aGlib0BodWF3ZWkuY29t Pj47IEd5YW4gTWlzaHJhDQoNCiAgICAgICAgPj4+IDxneWFuLnMubWlzaHJhQHZlcml6b24uY29t PG1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tPj47IEFpanVuIFdhbmcgPHdhbmdhajNA Y2hpbmF0ZWxlY29tLmNuPG1haWx0bzp3YW5nYWozQGNoaW5hdGVsZWNvbS5jbj4+Ow0KDQogICAg ICAgID4+PiBHeWFuIFMuIE1pc2hyYSA8Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTxtYWlsdG86 Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbT4+DQoNCiAgICAgICAgPj4+IFN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCg0KICAgICAgICA+Pj4gZHJhZnQtd2FuZy1sc3ItcGFz c2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dA0KDQogICAgICAgID4+Pg0KDQogICAgICAg ID4+Pg0KDQogICAgICAgID4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwNCg0KICAgICAgICA+Pj4g ZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dA0KDQogICAg ICAgID4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFpanVuIFdhbmcgYW5k IHBvc3RlZCB0byB0aGUgSUVURg0KDQogICAgICAgID4+PiByZXBvc2l0b3J5Lg0KDQogICAgICAg ID4+Pg0KDQogICAgICAgID4+PiBOYW1lOiAgICAgICAgICAgICAgIGRyYWZ0LXdhbmctbHNyLXBh c3NpdmUtaW50ZXJmYWNlLWF0dHJpYnV0ZQ0KDQogICAgICAgID4+PiBSZXZpc2lvbjogICAwNA0K DQogICAgICAgID4+PiBUaXRsZTogICAgICAgICBQYXNzaXZlIEludGVyZmFjZSBBdHRyaWJ1dGUN Cg0KICAgICAgICA+Pj4gRG9jdW1lbnQgZGF0ZTogICAgICAgMjAyMC0wOS0yOA0KDQogICAgICAg ID4+PiBHcm91cDogICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KICAgICAg ICA+Pj4gUGFnZXM6ICAgICAgICAgICAgICAgNw0KDQogICAgICAgID4+PiBVUkw6DQoNCiAgICAg ICAgPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50 ZXJmYWNlLWF0dHJpYnV0ZS0wNC4NCg0KICAgICAgICA+Pj4gdHh0DQoNCiAgICAgICAgPj4+IFN0 YXR1czoNCg0KICAgICAgICA+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0DQoNCiAgICAgICAgPj4+IHINCg0KICAg ICAgICA+Pj4gaWJ1dGUvDQoNCiAgICAgICAgPj4+IEh0bWxpemVkOg0KDQogICAgICAgID4+PiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdhbmctbHNyLXBhc3Np dmUtaW50ZXJmYWMNCg0KICAgICAgICA+Pj4gZQ0KDQogICAgICAgID4+PiAtYXR0cmlidXQNCg0K ICAgICAgICA+Pj4gZQ0KDQogICAgICAgID4+PiBIdG1saXplZDoNCg0KICAgICAgICA+Pj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWNl LWF0dHJpYnV0DQoNCiAgICAgICAgPj4+IGUNCg0KICAgICAgICA+Pj4gLTA0DQoNCiAgICAgICAg Pj4+IERpZmY6DQoNCiAgICAgICAgPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdA0KDQogICAgICAgID4+PiB0DQoN CiAgICAgICAgPj4+IHJpYnV0ZS0wNA0KDQogICAgICAgID4+Pg0KDQogICAgICAgID4+PiBBYnN0 cmFjdDoNCg0KICAgICAgICA+Pj4gICAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgbWVj aGFuaXNtIHRoYXQgY2FuIGJlIHVzZWQgdG8NCg0KICAgICAgICA+Pj4gICAgICBkaWZmZXJlbnRp YXRlIHRoZSBwYXNzaXZlIGludGVyZmFjZXMgZnJvbSB0aGUgbm9ybWFsIGludGVyZmFjZXMNCg0K ICAgICAgICA+Pj4gICAgICB3aXRoaW4gSVNJUyBvciBPU1BGIGRvbWFpbi4NCg0KICAgICAgICA+ Pj4NCg0KICAgICAgICA+Pj4NCg0KICAgICAgICA+Pj4NCg0KICAgICAgICA+Pj4NCg0KICAgICAg ICA+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YNCg0KICAgICAgICA+Pj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQoNCiAgICAgICAgPiB0b29scy5p ZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQogICAgICAgID4+Pg0KDQogICAgICAg ID4+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQogICAgICAgID4+Pg0KDQogICAgICAgID4+DQoN CiAgICAgICAgPj4NCg0KICAgICAgICA+Pg0KDQogICAgICAgID4+DQoNCiAgICAgICAgPg0KDQog ICAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KICAgICAgICA+IExzciBtYWlsaW5nIGxpc3QNCg0KICAgICAgICA+IExzckBpZXRmLm9yZzxt YWlsdG86THNyQGlldGYub3JnPg0KDQogICAgICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sc3INCg0KICAgICAgICA+DQoNCiAgICAgICAgPg0KDQogICAgICAgID4N Cg0KDQoNCiAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KICAgICAgICBMc3IgbWFpbGluZyBsaXN0DQoNCiAgICAgICAgTHNyQGlldGYub3Jn PG1haWx0bzpMc3JAaWV0Zi5vcmc+DQoNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sc3INCg0KDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQogICAgTHNyIG1haWxpbmcgbGlzdA0KDQogICAgTHNyQGll dGYub3JnPG1haWx0bzpMc3JAaWV0Zi5vcmc+DQoNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xzcg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkxzciBtYWlsaW5nIGxpc3QNCg0KTHNyQGlldGYub3Jn PG1haWx0bzpMc3JAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbHNyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KTHNyIG1haWxpbmcgbGlzdA0KTHNyQGlldGYub3JnPG1haWx0bzpMc3JAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0KLS0NCg0KW0ltYWdlIHJl bW92ZWQgYnkgc2VuZGVyLl08aHR0cDovL3d3dy52ZXJpem9uLmNvbS8+DQoNCkd5YW4gTWlzaHJh DQoNCk5ldHdvcmsgU29sdXRpb25zIEFyY2hpdGVjdA0KDQpNIDMwMSA1MDItMTM0Nw0KMTMxMDEg Q29sdW1iaWEgUGlrZQ0KU2lsdmVyIFNwcmluZywgTUQNCg0K --_000_F50BDB444E474B02BE69EAA05433DE1Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2VvcmdpYTsN CglwYW5vc2UtMToyIDQgNSAyIDUgNCA1IDIgMyAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tLTg4MzUxNjgxMjUw NjI0NTA3Mzltc29wbGFpbnRleHQsIGxpLm0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4 dCwgZGl2Lm0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dA0KCXttc28tc3R5bGUtbmFt ZTptXy04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13 b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T cGVha2luZyBXRyBtZW1iZXI6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEd5YW4sIEFpanVu LCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlbiBpZiBJIGFncmVlZCB3aXRoIHlvdXIgdXNl IGNhc2UgYXNzdW1pbmcgYSBwYXNzaXZlIGludGVyZmFjZSBkZW5vdGVzIHRoZSBib3VuZGFyeSBi ZXR3ZWVuIHR3byBkb21haW5zIGFzIHNob3duIGluIGZpZ3VyZSAxIGluIHlvdXIgZHJhZnQgKHdo aWNoIEkgZG9u4oCZdCksIHlvdSBzdGlsbCBzaG91bGQgbm90IGJlIHRyeWluZyB0byBoYWNrIHRo ZSBwcmVmaXhlcyB3aXRoIHdoYXQgaXMgaW5oZXJlbnRseSBsaW5rDQogYXR0cmlidXRlLiBDYW4g SSBzdGF0ZSB0aGlzIGFueW1vcmUgc2ltcGx5IG9yIGFyZSB5b3UgYXJlIGp1c3QgZ29pbmcgdG8g cmVzdGF0ZSB5b3VyIHJlcXVpcmVtZW50cyBhZ2Fpbj8/PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BY2VlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkd5YW4gTWlzaHJhICZsdDtoYXlhYnVzYWdzbUBnbWFpbC5jb20m Z3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlN1bmRheSwgT2N0b2JlciAxMSwgMjAyMCBhdCAzOjE5IFBN PGJyPg0KPGI+VG86IDwvYj5BY2VlIExpbmRlbSAmbHQ7YWNlZUBjaXNjby5jb20mZ3Q7PGJyPg0K PGI+Q2M6IDwvYj5BaWp1biBXYW5nICZsdDt3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuJmd0Oywg QWlqdW4gV2FuZyAmbHQ7d2FuZ2FqM0BjaGluYXRlbGVjb20uY24mZ3Q7LCAmcXVvdDtQZXRlciBQ c2VuYWsgKHBwc2VuYWspJnF1b3Q7ICZsdDtwcHNlbmFrQGNpc2NvLmNvbSZndDssICZxdW90O2xz ckBpZXRmLm9yZyZxdW90OyAmbHQ7bHNyQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1s c3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5IaSBBY2VlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+SSBiZWxpZXZlIHdoYXQgQWlqdW4gaXMgdHJ5aW5nIHRvIGV4cGxhaW4gaXMgdGhhdCB0aGUg cHJpbWFyeSBwdXJwb3NlIG9mIFBDRSBmb3IgYWN0aXZlIG9yIHBhc3NpdmUgcGF0aCBjb21wdXRh dGlvbiBpcyBmb3IgaW50ZXItYXMgUlNWUC1URSBQQ0FMQyBwYXRoIGNvbXB1dGF0aW9uIG9yIFNS LVRFIHBhdGggY29tcHV0YXRpb24uJm5ic3A7IFNvIFBDRSBpcyBzb2x2aW5nIGENCiB3ZWxsIGtu b3duIFBDQUxDIGJpbiBwYWNraW5nIHByb2JsZW0gZHVlIHRvIHBjYWxjIG92ZXIgc3Vic2NyaWJp bmcgUlNWUCB0dW5uZWwgYmFuZHdpZHRoIHdoaWNoIGlzIGluaGVyZW50IGFuIFJTVlAgaXNzdWUs IGJ1dCBhIGJpZ2dlciBwcm9ibGVtYXRpYyBpc3N1ZSBpcyB3aXRoIGJlaW5nIGFibGUgdG8gYnVp bGQgYW4gaW50ZXItYXMgVEUgcGF0aCB3aXRoIGEgc2luZ2xlIG9yIG11bHRpcGxlIFBDRSBjb250 cm9sbGVycyB0aGF0IGNhbiB0YWtlDQogdGhlIExTREIgbGluayBhdHRyaWJ1dGVzIGluIHRoZSBU RURzIGRCIG9wYXF1ZSBMU0FzIGluIHRoZSBvc3BmIGNhc2UgYW5kIElTSVMgVEUgVExWcyBhbmQg cmVidWlsZCB0aGUgdG9wb2xvZ3kgdG9wb2xvZ3kgZnJvbSBlYWNoIFRFIGRvbWFpbiB0byBiZSBh YmxlIHRvIGJ1aWxkIGEgY29uZ3J1ZW50IGVuZCB0byBlbmQgUlNWUCBURSBvciBTUi1URSB0cmFm ZmljIHN0ZWVyZWQgcGF0aCBpbnN0YW50aWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPldpdGhvdXQgdGhlIHVzZSBvZiBQQ0UgY29udHJvbGxlcnMg YXMgdGhlIExTREIgbGluayBhdHRyaWJ1dGUgaW5mb3JtYXRpb24gaXMgbm90IGtub3duIGFzIFJT VlAgbG9vc2UgRVJPIHN0YXRpYyBsc3AgaXMgYnVpbHQgb3IgU1IgU1ItVEUgcHJlZml4IHNpZCBs b29zZSBwYXRoIGlzIGJ1aWx0LCBmYWlsb3ZlciBkdWUgdG8gY3JhbmsgYmFjayBpcyBpbXBhY3Rl ZCBmb3INCiByZXJvdXRlLCBkdWUgdG8gbm90IGhhdmluZyBhIGNvbXBsZXRlIGRlcGljdGlvbiBv ZiB0aGUgb3RoZXIgQVMgTGluayBzdGF0ZSB0b3BvbG9neSBieSB0aGUgaGVhZCBlbmQgb3IgU1Ig c291cmNlIG5vZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+U28gdG8gYnVpbGQgdGhhdCBlbnRpcmUgZW5kIHRvIGVuZCBpbnRlci1hcyBwYXRoIGZvciB0 aGF0IGVuZCB0byBlbmQgUlNWUCBURSBvciBTUi1URSBwYXRoIGluc3RhbnRpYXRpb24gaXQgaXMg Y3JpdGljYWwgdG8gaW5kZW50aWZ5IHRoZSBpbnRlci1hcyBsaW5rIGVCR1AgdGllIGxpbmsgdGhh dCBtYXkgaGF2ZSBzdGF0aWMgcm91dGVzIG9yIEJHUCBMVSBmb3IgUlNWUA0KIGhlYWQgZW5kIHRv IHRhaWwgZW5kIHJlYWNoYWJpbGl0eSBhbmQgU1ItVEUgcmVhY2hhYmlsaXR5IHRvIGJ1aWxkIG91 dCB0aGUgZW5kIHRvIGVuZCBwYXRoIGluc3RhbnRpYXRpb24uJm5ic3A7IFNvIHRoZSBCR1AtTFMg dGFzayB0byAmbmJzcDtyZWJ1aWxkIHRoZSBsc2RiIHRvcG9sb2d5IG9mIGVhY2ggaW50ZXIgY29u bmVjdGVkIEFTIHRoYXQgdGhlIFJTVlAgVEUgb3IgU1ItVEUgc3RlZXJlZCBwYXRoIHRyYXZlcnNl cywgd2UgbmVlZCB0aGUgYWNjdXJhdGUgZGVwaWN0aW9uDQogYW5kIHRoYXQgaW5jbHVkZXMgdGhl IElkZW50aWZpY2F0aW9uIG9mIHRoZSAmbmJzcDtjcml0aWNhbCBpbnRlci1hcyB0aWUgbGluayBl QkdQIHBlZXJpbmcgbGluayB0aGF0IGlzIHBhc3NpdmUgZm9yIHRoZSBQQ0UgcGF0aCBjb21wdXRh dGlvbiBsb2dpYyBmb3IgdGhlIGVuZCB0byBlbmQgaW50ZXItYXMgcGF0aCBpbnN0YW50aWF0aW9u LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5B cyBmb3Igb3RoZXIgaW50ZXJmYWNlcyB1c2luZyBwYXNzaXZlIGluIHRoZSBjb250ZXh0IG9mIGEg b3BlcmF0b3Igc2VydmljZSBwcm92aWRlciBvciBlbnRlcnByaXNlIGNvcmUgUCBhbmQgUEUgcm91 dGVycyBhbGwgbGlua3MgYXJlIHRyYW5zaXQgd2l0aCBuZWlnaGJvcnMgZXhjZXB0IHRoZSBpbnRl ci1hcyB0aWUgc28gaGF2aW5nIHRoaXMgbmV3IElHUCBUTFYgd2lsbA0KIGhlbHAgdG8gdGhhdCBl bmQuJm5ic3A7IEluIHRoZSBvcGVyYXRvciDigJxjb3Jl4oCdIG5ldHdvcmsgaWYgdGhlcmUgYXJl IG90aGVyICZuYnNwO2ludGVyZmFjZXMgdGhhdCBkb27igJl0IG5lZWQgdG8gYmUgYWR2ZXJ0aXNl ZCBhcyBzdHViLCB0aGV5IGNhbiBlYXNpbHkgYmUgZXhjbHVkZWQgZnJvbSBiZWluZyBhZGRlZCBp bnRvIElHUC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+S2luZCBSZWdhcmRzJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+R3lhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+T24gU2F0LCBPY3QgMTAsIDIwMjAgYXQgNjoyOSBBTSBBY2VlIExpbmRlbSAoYWNl ZSkgJmx0O2FjZWU9PGEgaHJlZj0ibWFpbHRvOjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnIj40 MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6LjVpbiI+DQpIaSBBaWp1biwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+QWlqdW4gV2FuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhaWp1bkB0c2luZ2h1YS5vcmcu Y24iIHRhcmdldD0iX2JsYW5rIj53YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPC9hPiZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBPY3RvYmVyIDksIDIwMjAgYXQgOTo1OCBQTTxicj4NCjxi PlRvOiA8L2I+QWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmFjZWVAY2lzY28uY29tPC9hPiZndDssICZxdW90O1BldGVyIFBzZW5h ayAocHBzZW5haykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwcHNlbmFrQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnBwc2VuYWtAY2lzY28uY29tPC9hPiZndDssICdBaWp1biBXYW5nJyAm bHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNuIiB0YXJnZXQ9Il9ibGFu ayI+d2FuZ2FqM0BjaGluYXRlbGVjb20uY248L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7 PGEgaHJlZj0ibWFpbHRvOmxzckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxzckBpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsc3JAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5sc3JAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogW0xzcl0g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1p bnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjEuMGluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSwgQWNlZTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6OTMuMHB0Ij4NCjxiPkZyb206PC9iPiA8YSBocmVmPSJtYWlsdG86bHNyLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sc3ItYm91bmNlc0BpZXRmLm9yZzwvYT4g W21haWx0bzo8YSBocmVmPSJtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5sc3ItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFjZWUg TGluZGVtIChhY2VlKTxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2JlciAxMCwgMjAy MCAzOjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBBaWp1biBXYW5nICZsdDs8YSBocmVmPSJtYWlsdG86 d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbiIgdGFyZ2V0PSJfYmxhbmsiPndhbmdhaWp1bkB0c2lu Z2h1YS5vcmcuY248L2E+Jmd0OzsgUGV0ZXIgUHNlbmFrIChwcHNlbmFrKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBwc2VuYWtAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cHBzZW5ha0BjaXNjby5j b208L2E+Jmd0OzsgJ0FpanVuIFdhbmcnICZsdDs8YSBocmVmPSJtYWlsdG86d2FuZ2FqM0BjaGlu YXRlbGVjb20uY24iIHRhcmdldD0iX2JsYW5rIj53YW5nYWozQGNoaW5hdGVsZWNvbS5jbjwvYT4m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bHNyQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bHNyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0xzcl0g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1p bnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo5My4wcHQiPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6OTMuMHB0Ij4NClNw ZWFraW5nIGFzIFdHIG1lbWJlcjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDo5My4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6OTMuMHB0Ij4NCkhpIEFpanVuLCA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo5My4wcHQiPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MTI5LjBwdCI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+QWlqdW4gV2FuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdh aWp1bkB0c2luZ2h1YS5vcmcuY24iIHRhcmdldD0iX2JsYW5rIj53YW5nYWlqdW5AdHNpbmdodWEu b3JnLmNuPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIE9jdG9iZXIgOCwgMjAy MCBhdCAxMTowOSBQTTxicj4NCjxiPlRvOiA8L2I+QWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1h aWx0bzphY2VlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFjZWVAY2lzY28uY29tPC9hPiZn dDssICZxdW90O1BldGVyIFBzZW5hayAocHBzZW5haykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpwcHNlbmFrQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBwc2VuYWtAY2lzY28uY29tPC9h PiZndDssICdBaWp1biBXYW5nJyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhajNAY2hpbmF0ZWxl Y29tLmNuIiB0YXJnZXQ9Il9ibGFuayI+d2FuZ2FqM0BjaGluYXRlbGVjb20uY248L2E+Jmd0Ozxi cj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmxzckBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmxzckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsc3JA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sc3JAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SRTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDoxMjkuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i bS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5 LjBwdCI+SGksIEFjZWU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYy NDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+U29ycnkgZm9y IHRoZSBwcmV2aW91cyBwcnVuZWQgbWFpbC4gTGV0J3MgcmVwbHkgeW91IGFnYWluIGFsb25nIHlv dXIgb3JpZ2luYWwgcXVlc3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+UGxl YXNlIHNlZSBpbmxpbmUuW1dBSl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgx MjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFp bnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPGJy Pg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bHNyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86bHNyLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0gKGFjZWUpPGJyPg0KU2VudDogV2VkbmVzZGF5 LCBTZXB0ZW1iZXIgMzAsIDIwMjAgNzo0NyBQTTxicj4NClRvOiBBaWp1biBXYW5nICZsdDs8YSBo cmVmPSJtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbiIgdGFyZ2V0PSJfYmxhbmsiPndh bmdhaWp1bkB0c2luZ2h1YS5vcmcuY248L2E+Jmd0OzsgUGV0ZXIgUHNlbmFrIChwcHNlbmFrKSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnBwc2VuYWtAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cHBz ZW5ha0BjaXNjby5jb208L2E+Jmd0OzsgJ0FpanVuIFdhbmcnICZsdDs8YSBocmVmPSJtYWlsdG86 d2FuZ2FqM0BjaGluYXRlbGVjb20uY24iIHRhcmdldD0iX2JsYW5rIj53YW5nYWozQGNoaW5hdGVs ZWNvbS5jbjwvYT4mZ3Q7PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpsc3JAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5sc3JAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtMc3JdIEZX OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50 ZXJmYWNlLWF0dHJpYnV0ZS0wNC50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUx NjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29w bGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij5IaSBBaWp1biwNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPk90aGVyIHRoYW4geW91ciBpbGwtY29uY2VpdmVkIHRv cG9sb2d5IGRpc2NvdmVyeSBoZXVyaXN0aWM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4 MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0 Ij5bV0FKXSBUaGUgdG9wb2xvZ3kgZGlzY292ZXJ5IGhldXJpc3RpYyBpcyBub3Qgc3VpdGFibGUg Zm9yIHRoZSBjb3JuZXIgdXNlIGNhc2Ugd2hlbiB0aGUgdW5udW1iZXJlZCBpbnRlcmZhY2UgaXMg dXNlZCwgYXMgZXhwbGFpbmVkIGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNiNhcHBlbmRpeC1CIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1s c3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNiNhcHBlbmRpeC1CPC9hPi4mbmJzcDsgSWYgeW91 IGRvbjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCZ PC9zcGFuPnQgYWdyZWUsIHdvdWxkIHlvdSBsaWtlIHRvIGlsbHVzdHJhdGUgb3RoZXIgbm9uLWFw cGxpY2FibGUgc2NlbmFyaW9zPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEy NTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50 ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij5SaWdodCDigJMgYW5kIG5vYm9keSBvdGhl ciB0aGFuIHlvdXJzZWxmIGJlbGlldmVzIHRoZSBJR1BzIHNob3VsZCBiZSBtb2RpZmllZCB0byBl eHBvc2UgdGhlIGFic3RyYWN0ZWQgdG9wb2xvZ3kgb2YgYW4gYXJlYSBvdXRzaWRlIHRoYXQgYXJl YS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3Bs YWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPltXQUpdICZuYnNwO1RoZSBtb2RpZmljYXRpb24gZG9lc27igJl0IGNoYW5n ZSB0aGUgd2F5IGFuZCBjb21wbGV4aXR5IG9mIHJvdXRlIGNhbGN1bGF0aW9uIHdpdGhpbiBJR1Au IEl0IGp1c3QgcGlnZ3liYWNrIHNvbWUgZXh0cmEgaW5mb3JtYXRpb24sIHRoZSBidWxrIG9mIHRo ZQ0KIHJlY29uc3RydWN0aW9uIHdvcmsgaXMgZG9uZSBieSB0aGUgY29udHJvbGxlci4mbmJzcDsg U3VjaCBleHRyYSBpbmZvcm1hdGlvbiBjYW4gYWxzbyBoYXZlIG90aGVyIHVzYWdlLCBhcyBkZXNj cmliZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2I3NlY3Rpb24tMSIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4 LW9yaWdpbmF0b3ItMDYjc2VjdGlvbi0xPC9hPjwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjkzLjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFuZCwg dGhlIHByb3Bvc2FsIGRlc2NyaWJlZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1 dGUtMDQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0PC9hPiBp cyBkaWZmZXJlbnQgd2l0aCB0aGUgcHJvYmxlbSB5b3UgY29uY2VybmVkLiZuYnNwOyBJdCBoYXMg bm8gcmVsYXRpb24gd2l0aCB0aGUgYWJzdHJhY3RlZCB0b3BvbG9neSBvZiBhbiBhcmVhLiZuYnNw OyBNYXliZSB5b3UgYXJlIGNvbmZ1c2VkIGJ5IHRoZXNlIHR3byBkcmFmdHM/PC9zcGFuPjwvaT48 L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxh aW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUw NzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SXQgaXMgYSBzaW1pbGFy IHByb2JsZW0uIFlvdSBhcmUgc3RpbGwgdHJ5aW5nIHRvIG92ZXJsb2FkIHRoZSBwcmVmaXggYWR2 ZXJ0aXNlbWVudHMgd2l0aCBhIGxpbmsgYXR0cmlidXRlIChwYXNzaXZlIGludGVyZmFjZSkgc28g dGhhdCBpdCBjYW4gYmUgY29udmV5ZWQgb3V0c2lkZSB0aGUgZG9tYWluLiBXZSBjZXJ0YWlubHkg d291bGRu4oCZdA0KIHdhc3RlIGEgbGltaXRlZCBwcmVmaXggZmxhZyBvbiB0aGlzIHBhcm9jaGlh bCBhcHBsaWNhdGlvbi4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYy NDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojkz LjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3Bs YWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+WW91IGNhbiBzb2x2ZSB0aGUgcHJv YmxlbSB3aXRoIEJHUC1MUyBzZXNzaW9uKHMpIGJldHdlZW4gdGhlIHJvdXRlciB3aXRoIGEgQkdQ LUxTIHNlc3Npb24gdG8gdGhlIGNvbnRyb2xsZXIgYW5kIGEgcm91dGVyIGluIGVhY2ggYXJlYSB3 L28gJm5ic3A7YSByb3V0ZXIgd2l0aCBhIEJHUC1MUyBzZXNzaW9uIHRvIHRoZSBjb250cm9sbGVy Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxh aW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTMuMHB0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+W1dBSl0gVGhpcyBpcyBwb3NzaWJsZSwgYnV0IG5vdCBlZmZpY2llbnQuIEZv ciBvcGVyYXRpb24sIHdlIG11c3QgYWxzbyBjb25zaWRlciB0aGUgY29uZmlndXJhdGlvbi9hZG1p bmlzdHJhdGlvbiBvdmVyaGVhZC4mbmJzcDsgQkdQLUxTIGlzIGRlc2lnbmVkIG1haW5seSBmb3IN CiB0aGUgbm9ydGhib3VuZCBwcm90b2NvbCwgbm90IGVhc3Qtd2VzdCBwcm90b2NvbC48L3NwYW4+ PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzlt c29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij53aGF0IG90aGVyIHBvc3NpYmxlIHJlYXNvbiB3b3VsZCB0 aGVyZSBiZSBmb3IgYXNzb2NpYXRpbmcgdGhlIHBhc3NpdmUgYXR0cmlidXRlIHdpdGggYSBwcmVm aXg/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29w bGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPltXQUpdIFRvIGtub3cgdGhlIGJvdW5kYXJ5IG9mIHRoZSBJR1AgZG9tYWluLiBBZnRl ciBrbm93aW5nIHRoZSBib3VuZGFyeSwgdGhlIGNvbnRyb2xsZXIgY2FuIHNhZmVseSBhcHBseSBh bmQgY2hlY2sgdGhlIG5ldHdvcmsgc2VjdXJpdHkgcG9saWN5LCB0aGUgaW5ib3VuZCB0cmFmZmlj DQogY29udHJvbCBwb2xpY3kgZXRjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt LTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDcz OW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+SXQgcmVhbGx5IGlzbuKA mXQgcmVsZXZhbnQsIGJ1dCBJIGhhdmUgdG8gYXNr4oCmLiBIb3cgZG9lcyB0aGUgcHJlc2VuY2Ug b2YgYSBwcmVmaXggYXNzb2NpYXRlZCB3aXRoIGEgcGFzc2l2ZSBpbnRlcmZhY2UgYWxsb3cgeW91 IHRvIG1ha2UgdGhpcyBkZWR1Y3Rpb24/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4 MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQi PjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bV0FKXSBQYXNzaXZlIGludGVyZmFj ZXMgYXJlIGRlcGxveWVkIG1haW5seSBhdCB0aGUgYm91bmRhcnkgb2YgSUdQIGRvbWFpbi4mbmJz cDsgSXMgdGhlcmUgYW55IG90aGVyIGV4Y2VwdGlvbj88L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5XaGlsZSBwYXNzaXZlIGludGVyZmFjZXMgYXJlIG5vdCBzdGFu ZGFyZGl6ZWQsIHRoZXJlIGlzIG5vdGhpbmcgdGhhdCBsaW1pdHMgdGhlaXIgdXNhZ2UgdG8gYW4g SUdQIGJvdW5kYXJ5LiBUaGV5IGNhbiBhbmQgYXJlIGRlcGxveWVkIG9uIGFueSBpbnRlcmZhY2Ug d2hlcmUgYWRqYWNlbmNpZXMgYXJlIG5vdCB0byBiZSBmb3JtZWQNCiAoZS5nLiwgYSBzdHViIHN1 Ym5ldCBjb250YWluaW5nIGhvc3RzKS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1 MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxh aW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhbmtzLDxicj4NCkFjZWU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtLTg4MzUx NjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo5My4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3Bs YWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjkzLjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjkzLjBwdCI+QWNlZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2 ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEyOS4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgx MjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij5BY2Vl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50 ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTI5LjBwdCI+T24gOS8yOS8yMCwgMTA6MzkgUE0sICZxdW90O0FpanVuIFdhbmcmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPndhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY248L3NwYW4+PC9hPiZndDsNCiB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgSGksIEFjZWUgYW5kIFBldGVyOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBQYXNzaXZlIGludGVy ZmFjZSBpcyBtYWlubHkgdXNlZCBhdCB0aGUgZWRnZSBvZiB0aGUgbmV0d29yaywgd2hlcmUgdGhl IHVubnVtYmVyZWQgaW50ZXJmYWNlIHdpbGwgbm90IGJlIHVzZWQuDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBbmQgdGhlIGluZm9ybWF0 aW9uIHRvIGZsYWcgdGhlIHBhc3NpdmUgaW50ZXJmYWNlcyBpcyBmb3IgcG9zaXRpb25pbmcgdGhl IGFyZWEgYm91bmRhcnksIG5vdCBjb25mbGljdCB3aXRoIHRoZSBhYnN0cmFjdCBjYXBhYmlsaXRp ZXMgb2YgdGhlIGFyZWEgaW5zaWRlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2 ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3Bs YWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBCZXN0IFJlZ2FyZHM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDox MjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQWlqdW4gV2FuZzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBDaGluYSBUZWxlY29tPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04 ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb206DQo8YSBocmVm PSJtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bHNyLWJvdW5jZXNAaWV0 Zi5vcmc8L3NwYW4+PC9hPiBbPGEgaHJlZj0ibWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPm1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XQ0KIE9uIEJl aGFsZiBPZiBBY2VlIExpbmRlbSAoYWNlZSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4 MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDI5LCAyMDIwIDk6 MTYgUE08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29w bGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg VG86IFBldGVyIFBzZW5hayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBwc2VuYWs9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+cHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRm Lm9yZzwvc3Bhbj48L2E+Jmd0OzsNCiBBaWp1biBXYW5nICZsdDs8YSBocmVmPSJtYWlsdG86d2Fu Z2FpanVuQHRzaW5naHVhLm9yZy5jbiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj53YW5nYWlqdW5AdHNpbmdodWEub3Jn LmNuPC9zcGFuPjwvYT4mZ3Q7OyAnQWlqdW4gV2FuZycgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5n YWozQGNoaW5hdGVsZWNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj53YW5nYWozQGNoaW5hdGVsZWNvbS5jbjwv c3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1 MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBDYzogPGEgaHJlZj0ibWFpbHRvOmxzckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmxz ckBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IFN1YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHRyaWJ1dGUtMDQu dHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxh aW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNwZWFraW5nIGFzIFdHIG1lbWJl cjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFp bnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgSGkgQWlqdW4sIFBldGVyLA0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SSBh Z3JlZSB3aXRoIFBldGVyIC0gb25lIG9mIHRoZSBtYWluIG1vdGl2YXRpb25zIGZvciBoYXZpbmcg YXJlYXMgaXMgdG8gYWJzdHJhY3QgdGhlIHRvcG9sb2d5IHdpdGhpbiB0aGUgYXJlYS4gTm93IHlv dSdyZSB0cnlpbmcgdG8gc3VwcGxhbnQgdGhpcyAmbmJzcDstIG9uZSB0b3BvbG9naWNhbCBkZXRh aWwgYXQgYSB0aW1lDQogd2l0aCBpbGwtY29uY2VpdmVkIElHUCBmZWF0dXJlcy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBBY2VlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIDkvMjkvMjAsIDU6MTUgQU0sICZxdW90O0xzciBv biBiZWhhbGYgb2YgUGV0ZXIgUHNlbmFrJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bHNyLWJv dW5jZXNAaWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIwcHBzZW5haz00MGNpc2NvLmNvbUBk bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5sc3ItYm91bmNlc0BpZXRmLm9yZw0KIG9uIGJlaGFs ZiBvZiBwcHNlbmFrPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3Bs YWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBIaSBBaWp1biw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0 NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgT24gMjkvMDkvMjAyMCAxMTowNywgQWlqdW4gV2FuZyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBIaSwgUGV0ZXI6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsgVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7IDEuIEZvciBCR1AtTFMgZGVwbG95bWVudCwgdGhlcmUgbm9ybWFs bHkgb25seSBiZSBvbmUgcm91dGVyIHRoYXQgd2l0aGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IElHUCBkb21haW4gdG8gcmVwb3J0IHRoZSB0b3BvbG9neSBpbmZvcm1hdGlvbiwgdGhpcyBy b3V0ZXIgc2hvdWxkIGtub3cgc3VjaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2 ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHBhc3NpdmUgbGlu a3Mgd2hpY2ggZXhpc3RzIG1haW5seSBvbiBvdGhlciBib3JkZXIgcm91dGVycyB2aWEgdGhlIElH UDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWlu dGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHByb3RvY29sLiBUaGlzIGlzIG1haW4gcmVhc29uIHRv IGV4dGVuc2lvbiB0aGUgSUdQIHByb3RvY29sLiAmZ3Q7IDIuIEZvciB0aGUgc29sdXRpb24sIG5v cm1hbGx5LCB0aGUgbGluayB3aXRoaW4gdGhlIElHUCBjb25uZWN0IHR3bw0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ZW5kcywgYnV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgcGFzc2l2ZSBpbnRl cmZhY2UgaXMgc3BlY2lhbCBhbmQgbm90IGZhbGwgaW4gdGhpcyBzcGFjZS4gV2UgaGF2ZSBzdHVk aWVkIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1z b3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGN1cnJlbnQgVExWcyB0aGF0IGZvciBsaW5r LCBhbmQgZmluZCBubyBzdWl0YWJsZSBjb250YWluZXIgdG8gYXBwZW5kIHRoaXM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBpbmZvcm1hdGlvbi4gVGhpcyBpcyB0aGUgcmVhc29uIHRoYXQgd2Ugc2Vs ZWN0IHRoZSBUTFZzIHRoYXQgYXNzb2NpYXRlZCB3aXRoPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg UHJlZml4LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1z b3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpZiB0aGUgbGluayBpcyB1bm51bWJlcmVkLCB5b3VyIHNvbHV0aW9uIGRvZXMgbm90 IHdvcmsuIEFzIEkgc2FpZCwgaWYNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2 ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3lvdSBuZWVkIGEg a25vd2xlZGdlIGFib3V0IHRoZSBsaW5rLCB5b3UgY2FuIG5vdCBhZHZlcnRpc2UgaXQgYXMgYSBw cmVmaXguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNv cGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0 NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGV0ZXI8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDoxMjkuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgx MjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFp bnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04 ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyZn dDtGcm9tIG90aGVyIFBPViwgdGhlIE9TUEZ2MyBkZWZpbmVzIG5vdyB0aGUgJnF1b3Q7SW50cmEt QXJlYS1QcmVmaXggTFNBJnF1b3Q7LCB3aGljaDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0t ODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGlzb2xh dGUgdGhlIHByZWZpeCBpbmZvcm1hdGlvbiB0aGF0IGFzc29jaWF0ZWQgd2l0aCBsaW5rIGludG8g dGhpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3Bs YWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGNvbnRhaW5lciwgY29udGFpbnMgdGhlIHN0dWIg bGluaywgbG9jYWwgaW50ZXJmYWNlIGluZm9ybWF0aW9uIGV0Yy4gUHV0IHN1Y2g8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBhdHRyaWJ1dGUgYWxvbmcgd2l0aCB0aGUgcHJlZml4IGlzIHRoZW4gYWNj ZXB0YWJsZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzlt c29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jmd0Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNv cGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBCZXN0IFJlZ2FyZHM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYy NDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBBaWp1biBXYW5nPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgQ2hpbmEgVGVsZWNvbTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFp bnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50 ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgRnJvbToNCjxhIGhyZWY9Im1haWx0bzpsc3ItYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lIj5sc3ItYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+IFs8 YSBocmVmPSJtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmxz ci1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dDQogT24gQmVoYWxmIE9mIFBldGVyPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgUHNlbmFrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1 MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgU2VudDogVHVl c2RheSwgU2VwdGVtYmVyIDI5LCAyMDIwIDQ6MjkgUE08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDox MjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBU bzogQWlqdW4gV2FuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndhbmdhajNAY2hpbmF0ZWxlY29tLmNu IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPndhbmdhajNAY2hpbmF0ZWxlY29tLmNuPC9zcGFuPjwvYT4mZ3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgQ2M6DQo8YSBocmVmPSJtYWlsdG86bHNyQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmxzckBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgU3Vi amVjdDogUmU6IFtMc3JdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRl LTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1z b3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDox MjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm Z3Q7IEhpIEFpanVuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1 MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7DQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmZ3Q7IGhlcmUncyBteSBjb21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt LTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjku MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBUaGUgcHVycG9zZSBvZiB0aGlzIGRyYWZ0IGlzIHRv IGFkdmVydGlzZSBwYXNzaXZlIGxpbmtzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgz NTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmZ3Q7IDEuIEknbSBub3Qgc3VyZSB0aGUgcHJvYmxlbSBuZWVkcyB0 byBiZSBzb2x2ZWQgYnkgSUdQcy4gSSB0ZW5kIHRvIGJlbGlldmU8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyBpZXRmLWlkci1iZ3Bscy1pbnRlci1hcy10b3BvbG9neS1leHQgaXMgc3VmZmljaWVudC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1 MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyAyLiB0 aGUgc29sdXRpb24gdGhhdCB5b3UgcHJvcG9zZWQgaXMgd3JvbmcuIFlvdSBhcmUgdHJ5aW5nIHRv IGRlcml2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1z b3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHRvcG9sb2dpY2FsIGRhdGEgYWJvdXQgdGhl IHBhc3NpdmUgbGlua3MgZnJvbSB0aGUgcHJlZml4IGFkdmVydGlzZW1lbnQuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgVGhpcyBpcyBzZW1hbnRpY2FsbHkgaW5jb3JyZWN0IGFuZCBvbmx5IHdvcmtz IHVuZGVyIHZlcnkgc3BlY2lmaWMgY29uZGl0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEy OS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IElm IHlvdSBuZWVkIHRvIGFkdmVydGlzZSBhIGxpbmssIGFkdmVydGlzZSBpdCBhcyBhICZxdW90O3Nw ZWNpYWwmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3 Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBsaW5rLCBub3QgYXMgYSAmcXVvdDtz cGVjaWFsJnF1b3Q7IHByZWZpeC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgx MjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jmd0OyB0aGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1 MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgUGV0ZXI8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBPbiAyOS8w OS8yMDIwIDAzOjE3LCBBaWp1biBXYW5nIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEy OS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyBIaSwgUGV0ZXI6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUw NzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsmZ3Q7IFdvdWxkIHlvdSBsaWtlIHRvIHJldmlldyBhbmQgZ2l2ZSBjb21tZW50cyBvbiB0 aGUgdXBkYXRlcyB2ZXJzaW9uIG9mIHRoaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4 MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBkcmFmdD88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgV2UgaGF2ZSBhbHNvIGFkZGVkIHRoZSBwcm90b2Nv bCBleHRlbnNpb24gcHJvcG9zYWwgZm9yIE9TUEZ2My48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDox MjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFp bnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsgVGhlIHVwZGF0ZSB2ZXJzaW9uIG9mIHRoaXMg ZHJhZnQgY2FuIHJlZmVyIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1 MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7DQo8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdhbmctbHNyLXBhc3Np dmUtaW50ZXJmYWNlIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZTwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IC1hdHRyaWJ1dGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDox MjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsgVGhhbmtzIGluIGFkdmFuY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1 MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IEJlc3QgUmVnYXJk czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWlu dGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0t ODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBB aWp1biBXYW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5 bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IENoaW5hIFRlbGVjb208bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgx MjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBGcm9t Og0KPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5p bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PC9hPiBbPGEgaHJlZj0ibWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPC9zcGFuPjwvYT5dPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1 MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZndDsmZ3Q7Jmd0OyBTZW50OiBN b25kYXksIFNlcHRlbWJlciAyOCwgMjAyMCAzOjE3IFBNPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyBUbzogWmhpYm8gSHUgJmx0OzxhIGhyZWY9Im1haWx0bzpodXpoaWJvQGh1YXdlaS5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+aHV6aGlib0BodWF3ZWkuY29tPC9zcGFuPjwvYT4mZ3Q7OyBHeWFuIE1p c2hyYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3Bs YWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpn eWFuLnMubWlzaHJhQHZlcml6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmd5YW4ucy5taXNocmFAdmVyaXpv bi5jb208L3NwYW4+PC9hPiZndDs7IEFpanVuIFdhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp3YW5n YWozQGNoaW5hdGVsZWNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj53YW5nYWozQGNoaW5hdGVsZWNvbS5jbjwv c3Bhbj48L2E+Jmd0Ozs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0 NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IEd5YW4gUy4gTWlz aHJhICZsdDs8YSBocmVmPSJtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5neWFuLnMubWlzaHJhQHZlcml6b24uY29tPC9zcGFuPjwvYT4mZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50 ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBkcmFmdC13YW5nLWxzci1wYXNzaXZlLWlu dGVyZmFjZS1hdHRyaWJ1dGUtMDQudHh0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1 MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt LTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjku MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgz NTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsg ZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0LnR4dDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBBaWp1biBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEY8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVm dDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7IHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgTmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBSZXZpc2lvbjombmJzcDsmbmJzcDsgMDQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7IFRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBQYXNzaXZlIEludGVyZmFjZSBBdHRyaWJ1dGU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJt YXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7IERvY3VtZW50IGRhdGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDIwMjAtMDktMjg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUx NjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IEdy b3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IFBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNv cGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBVUkw6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0Ow0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt d2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXRlLTA0IiB0YXJnZXQ9Il9ibGFuayI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0 cmlidXRlLTA0PC9zcGFuPjwvYT4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyB0eHQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IFN0YXR1czo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4t bGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmZ3Q7DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdHQiIHRhcmdldD0iX2JsYW5rIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFj ZS1hdHQ8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2 MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgcjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgaWJ1dGUvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyBIdG1saXplZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0 NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7DQo8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdhbmctbHNyLXBhc3Np dmUtaW50ZXJmYWMiIHRhcmdldD0iX2JsYW5rIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LXdhbmctbHNyLXBhc3NpdmUtaW50ZXJmYWM8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgz NTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsg LWF0dHJpYnV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5 bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyBIdG1saXplZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4 MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1sc3ItcGFz c2l2ZS1pbnRlcmZhY2UtYXR0cmlidXQiIHRhcmdldD0iX2JsYW5rIj4NCjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtd2FuZy1sc3ItcGFzc2l2ZS1pbnRlcmZhY2UtYXR0cmlidXQ8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3Bs YWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsgLTA0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYy NDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBEaWZmOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC13YW5nLWxzci1wYXNzaXZlLWludGVyZmFjZS1hdCIgdGFyZ2V0 PSJfYmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13YW5nLWxzci1w YXNzaXZlLWludGVyZmFjZS1hdDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i bS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyB0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNv cGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyByaWJ1dGUtMDQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBBYnN0 cmFjdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29w bGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBtZWNoYW5pc20gdGhhdCBjYW4g YmUgdXNlZCB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDcz OW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZGlmZmVyZW50aWF0ZSB0aGUgcGFzc2l2ZSBpbnRlcmZhY2VzIGZyb20g dGhlIG5vcm1hbCBpbnRlcmZhY2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4 MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRoaW4gSVNJUyBvciBPU1BGIGRvbWFpbi48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04 ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWlu dGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDox MjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNv cGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsgc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04 ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsNCjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3Jn PC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29w bGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTI5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEy OS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29w bGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDox MjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFp bnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt LTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjku MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1 MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IExzciBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4 MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ow0KPGEgaHJl Zj0ibWFpbHRvOkxzckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5Mc3JAaWV0Zi5vcmc8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWlu dGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xzciIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2xzcjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04 ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZndDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgz NTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZndDsNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBMc3IgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1 MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1haWx0 bzpMc3JAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5Mc3JAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2xzciIgdGFyZ2V0PSJfYmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHNyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUw NjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgTHNyIG1haWxpbmcgbGlzdDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2MjQ1MDczOW1zb3BsYWludGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJt YWlsdG86THNyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+THNyQGlldGYub3JnPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRl eHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3IiIHRhcmdldD0iX2Js YW5rIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcjwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTI5LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS04ODM1MTY4MTI1 MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTI5LjBwdCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtLTg4MzUxNjgxMjUwNjI0NTA3Mzltc29wbGFpbnRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDoxMjkuMHB0Ij5Mc3IgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibS04ODM1MTY4MTI1MDYyNDUwNzM5bXNvcGxhaW50ZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTI5LjBwdCI+PGEgaHJlZj0ibWFpbHRvOkxzckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5Mc3JAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tODgzNTE2ODEyNTA2 MjQ1MDczOW1zb3BsYWludGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEyOS4wcHQiPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpMc3IgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkxzckBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkxzckBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzciIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+PGEgaHJlZj0i aHR0cDovL3d3dy52ZXJpem9uLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6IzIyMjIyMjt0ZXh0LWRlY29yYXRpb246bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1 Q0M7Ym9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPjxpbWcgYm9yZGVy PSIwIiB3aWR0aD0iODEiIGhlaWdodD0iMTgiIHN0eWxlPSJ3aWR0aDouODQzN2luO2hlaWdodDou MTg3NWluIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9ImNpZDp+V1JEMDAwNC5qcGciIGFsdD0iSW1h Z2UgcmVtb3ZlZCBieSBzZW5kZXIuIj48L3NwYW4+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bXNvLWxpbmUtaGVpZ2h0LWFsdDo5 Ljc1cHQiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkd5YW4gTWlzaHJhPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21zby1saW5l LWhlaWdodC1hbHQ6OS43NXB0Ij4NCjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtH ZW9yZ2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5OZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRl Y3QmbmJzcDs8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bXNvLWxpbmUtaGVpZ2h0 LWFsdDo5Ljc1cHQiPg0KPGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEm cXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPk0gMzAxIDUwMi0xMzQ3PGJyPg0KMTMxMDEgQ29sdW1i aWEgUGlrZSZuYnNwOzxicj4NCjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5T aWx2ZXIgU3ByaW5nLCBNRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F50BDB444E474B02BE69EAA05433DE1Dciscocom_-- From nobody Mon Oct 12 14:22:46 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C813A09E4 for ; Mon, 12 Oct 2020 14:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=0.01, 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 cKX9A01L6wsH for ; Mon, 12 Oct 2020 14:22:39 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 CD45B3A0953 for ; Mon, 12 Oct 2020 14:22:39 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id d6so9370915plo.13 for ; Mon, 12 Oct 2020 14:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=e0iLfZPAt0wH1D+JwAZF/aPBVXPuuwbyxDYKb0EhhhM=; b=ufEr/jes63s17LKLbnPtYDPACQDf+DjOoN/KJDBVcD/BEdAfM5FWCX5ZgNru6/JowO gCb23A7vxD30kZ40D3NhtFlZnvKuatzyFNcgbakXcwB8fAGi6RKDe1T8iQENbgyyZSHn wionzrKGdjMiZ7Zfk8BoCDTc0BnlMioq/4tdsCoU+WPcQa/jmSuNBzaOjncDt8TKVBUl kh9fANzALjW27RTCcJBghbvGrRRbo02tBKdIS37D/C+WDY2+iBrqZh0IoesE9aC+Io2u 2aj55l8OvSiQFrlYZLJuQZXKqJQMbpAVFDilvRWk+KMTlf+1jWfI1Pq1wQ4wsixOKsGA Q6Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=e0iLfZPAt0wH1D+JwAZF/aPBVXPuuwbyxDYKb0EhhhM=; b=qCkk+Lrim87WfeYx3wD7aP4kMRaG5od0Wc0WqNsk+CRZmy1QXnRy24ZMYnbHGaCk0M Fa7XFAunT38uUycdoz4EKXnPE4FDl3eJY4b3pP1htpDSD47FRh8c2SyFk3BCozOgzp+J RwyMqfWhjfcBqVfReY7lruRMhtaNrm6j3ljLvBkEnr6CS9hUm2/vyc8hxk+710mQhAl4 Y7vGrtAqGlsqaJgAUKKFg3TUr14DJv1OKn/igIVHYw26vcOhTfChdM6X03LGujdCzagu sWAOFCQXrlpYmsdu/6+S5ICG1eShVJ53Ne4xYyqL+eWtL+oZwLZy7V1QYGZqMTfVmnWg raNw== X-Gm-Message-State: AOAM5333335xMvyQ05UbdRC5BMF0GFgpslniS7jyOOwW2tu+BC/37PXg ZndrpEJaVo5s3m+k92L9hZI= X-Google-Smtp-Source: ABdhPJyB9GevGegeKL+O/qeae/Rd4HsAza4VKTZXsSgVM52a+Dhq3+Vxl2B1vvzhYsUt8Y6/UhjuZQ== X-Received: by 2002:a17:902:eacc:b029:d3:b362:72c0 with SMTP id p12-20020a170902eaccb02900d3b36272c0mr24654074pld.23.1602537759282; Mon, 12 Oct 2020 14:22:39 -0700 (PDT) Received: from [192.168.1.13] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id lb13sm1186724pjb.5.2020.10.12.14.22.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Oct 2020 14:22:38 -0700 (PDT) Date: Mon, 12 Oct 2020 14:22:26 -0700 From: Jeff Tantsura To: Gyan Mishra , "Acee Lindem (acee)" Cc: "=?utf-8?Q?lsr=40ietf.org?=" , Aijun Wang , Aijun Wang , "Peter Psenak (ppsenak)" Message-ID: <30d11575-2e24-4add-8bf6-454fdbf07ceb@Spark> In-Reply-To: References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> X-Readdle-Message-ID: 30d11575-2e24-4add-8bf6-454fdbf07ceb@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5f84c918_5fb8370b_cede" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 21:22:45 -0000 --5f84c918_5fb8370b_cede Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I=E2=80=99m with Acee here, the presence of a passive interface in a topo= logy is in no way unambiguously signaling domain boundaries. You could =E2= =80=9Chack around=E2=80=9D though, but that would defeat the purpose of a= n IET=46 document. Keeping it to OSP=46v2 (other protocols have similar ways of doing that),= I=E2=80=99d say, using a technique similar to that, defined for Inter-AS= -TE-v2 LSA provides you exactly that. Cheers, Jeff On Oct 12, 2020, 11:06 AM -0700, Acee Lindem (acee) , wrote: > Speaking WG member: > > Hi Gyan, Aijun, > > Even if I agreed with your use case assuming a passive interface denote= s the boundary between two domains as shown in figure 1 in your draft (wh= ich I don=E2=80=99t), you still should not be trying to hack the prefixes= with what is inherently link attribute. Can I state this anymore simply = or are you are just going to restate your requirements again=3F=3F=3F > > Acee > > =46rom: Gyan Mishra > Date: Sunday, October 11, 2020 at 3:19 PM > To: Acee Lindem > Cc: Aijun Wang , Aijun Wang , =22Peter Psenak (ppsenak)=22 , =22lsr= =40ietf.org=22 > Subject: Re: =5BLsr=5D =46W: New Version Notification for draft-wang-ls= r-passive-interface-attribute-04.txt > > > Hi Acee > > I believe what Aijun is trying to explain is that the primary purpose o= f PCE for active or passive path computation is for inter-as RSVP-TE PCAL= C path computation or SR-TE path computation.=C2=A0 So PCE is solving a w= ell known PCALC bin packing problem due to pcalc over subscribing RSVP tu= nnel bandwidth which is inherent an RSVP issue, but a bigger problematic = issue is with being able to build an inter-as TE path with a single or mu= ltiple PCE controllers that can take the LSDB link attributes in the TEDs= dB opaque LSAs in the ospf case and ISIS TE TLVs and rebuild the topolog= y topology from each TE domain to be able to build a congruent end to end= RSVP TE or SR-TE traffic steered path instantiation. > > Without the use of PCE controllers as the LSDB link attribute informati= on is not known as RSVP loose ERO static lsp is built or SR SR-TE prefix = sid loose path is built, failover due to crank back is impacted for rerou= te, due to not having a complete depiction of the other AS Link state top= ology by the head end or SR source node. > > So to build that entire end to end inter-as path for that end to end RS= VP TE or SR-TE path instantiation it is critical to indentify the inter-a= s link eBGP tie link that may have static routes or BGP LU for RSVP head = end to tail end reachability and SR-TE reachability to build out the end = to end path instantiation.=C2=A0 So the BGP-LS task to =C2=A0rebuild the = lsdb topology of each inter connected AS that the RSVP TE or SR-TE steere= d path traverses, we need the accurate depiction and that includes the Id= entification of the =C2=A0critical inter-as tie link eBGP peering link th= at is passive for the PCE path computation logic for the end to end inter= -as path instantiation. > > As for other interfaces using passive in the context of a operator serv= ice provider or enterprise core P and PE routers all links are transit wi= th neighbors except the inter-as tie so having this new IGP TLV will help= to that end.=C2=A0 In the operator =E2=80=9Ccore=E2=80=9D network if the= re are other =C2=A0interfaces that don=E2=80=99t need to be advertised as= stub, they can easily be excluded from being added into IGP. > > Kind Regards > > Gyan > > On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) wrote: > > quote=5Ftype > > Hi Aijun, > > > > =46rom: Aijun Wang > > Date: =46riday, October 9, 2020 at 9:58 PM > > To: Acee Lindem , =22Peter Psenak (ppsenak)=22 , 'Aijun Wang' > > Cc: =22lsr=40ietf.org=22 > > Subject: RE: =5BLsr=5D =46W: New Version Notification for draft-wang-= lsr-passive-interface-attribute-04.txt > > > > Hi, Acee: > > > > =46rom: lsr-bounces=40ietf.org =5Bmailto:lsr-bounces=40ietf.org=5D On= Behalf Of Acee Lindem (acee) > > Sent: Saturday, October 10, 2020 3:48 AM > > To: Aijun Wang ; Peter Psenak (ppsenak) = ; 'Aijun Wang' > > Cc: lsr=40ietf.org > > Subject: Re: =5BLsr=5D =46W: New Version Notification for draft-wang-= lsr-passive-interface-attribute-04.txt > > > > Speaking as WG member: > > > > Hi Aijun, > > > > =46rom: Aijun Wang > > Date: Thursday, October 8, 2020 at 11:09 PM > > To: Acee Lindem , =22Peter Psenak (ppsenak)=22 , 'Aijun Wang' > > Cc: =22lsr=40ietf.org=22 > > Subject: RE: =5BLsr=5D =46W: New Version Notification for draft-wang-= lsr-passive-interface-attribute-04.txt > > > > Hi, Acee: > > Sorry for the previous pruned mail. Let's reply you again along your = original question. > > Please see inline.=5BWAJ=5D > > > > -----Original Message----- > > =46rom: lsr-bounces=40ietf.org =5Bmailto:lsr-bounces=40ietf.org=5D On= Behalf Of Acee Lindem (acee) > > Sent: Wednesday, September 30, 2020 7:47 PM > > To: Aijun Wang ; Peter Psenak (ppsenak) = ; 'Aijun Wang' > > Cc: lsr=40ietf.org > > Subject: Re: =5BLsr=5D =46W: New Version Notification for draft-wang-= lsr-passive-interface-attribute-04.txt > > > > Hi Aijun, > > Other than your ill-conceived topology discovery heuristic > > =5BWAJ=5D The topology discovery heuristic is not suitable for the co= rner use case when the unnumbered interface is used, as explained in http= s://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06=23append= ix-B.=C2=A0 If you don=E2=80=99t agree, would you like to illustrate othe= r non-applicable scenarios=3F > > > > Right =E2=80=93 and nobody other than yourself believes the IGPs shou= ld be modified to expose the abstracted topology of an area outside that = area. > > =5BWAJ=5D =C2=A0The modification doesn=E2=80=99t change the way and c= omplexity of route calculation within IGP. It just piggyback some extra i= nformation, the bulk of the reconstruction work is done by the controller= .=C2=A0 Such extra information can also have other usage, as described in= https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06=23s= ection-1 > > And, the proposal described in https://datatracker.ietf.org/doc/html/= draft-wang-lsr-passive-interface-attribute-04 is different with the probl= em you concerned.=C2=A0 It has no relation with the abstracted topology o= f an area.=C2=A0 Maybe you are confused by these two drafts=3F > > > > It is a similar problem. You are still trying to overload the prefix = advertisements with a link attribute (passive interface) so that it can b= e conveyed outside the domain. We certainly wouldn=E2=80=99t waste a limi= ted prefix flag on this parochial application. > > > > > > You can solve the problem with BGP-LS session(s) between the router w= ith a BGP-LS session to the controller and a router in each area w/o =C2=A0= a router with a BGP-LS session to the controller. > > =5BWAJ=5D This is possible, but not efficient. =46or operation, we mu= st also consider the configuration/administration overhead.=C2=A0 BGP-LS = is designed mainly for the northbound protocol, not east-west protocol. > > > > what other possible reason would there be for associating the passive= attribute with a prefix=3F > > =5BWAJ=5D To know the boundary of the IGP domain. After knowing the b= oundary, the controller can safely apply and check the network security p= olicy, the inbound traffic control policy etc. > > > > It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How doe= s the presence of a prefix associated with a passive interface allow you = to make this deduction=3F > > =5BWAJ=5D Passive interfaces are deployed mainly at the boundary of I= GP domain.=C2=A0 Is there any other exception=3F > > While passive interfaces are not standardized, there is nothing that = limits their usage to an IGP boundary. They can and are deployed on any i= nterface where adjacencies are not to be formed (e.g., a stub subnet cont= aining hosts). > > > > Thanks, > > Acee > > > > Thanks, > > Acee > > > > Thanks, > > Acee > > > > On 9/29/20, 10:39 PM, =22Aijun Wang=22 = wrote: > > > > =C2=A0=C2=A0=C2=A0 Hi, Acee and Peter: > > =C2=A0=C2=A0=C2=A0 Passive interface is mainly used at the edge of th= e network, where the unnumbered interface will not be used. > > =C2=A0=C2=A0=C2=A0=C2=A0And the information to flag the passive inter= faces is for positioning the area boundary, not conflict with the abstrac= t capabilities of the area inside. > > > > > > =C2=A0=C2=A0=C2=A0 Best Regards > > > > =C2=A0=C2=A0=C2=A0 Aijun Wang > > =C2=A0=C2=A0=C2=A0 China Telecom > > > > =C2=A0=C2=A0=C2=A0 -----Original Message----- > > =C2=A0=C2=A0=C2=A0 =46rom: lsr-bounces=40ietf.org =5Bmailto:lsr-bounc= es=40ietf.org=5D On Behalf Of Acee Lindem (acee) > > =C2=A0=C2=A0=C2=A0 Sent: Tuesday, September 29, 2020 9:16 PM > > =C2=A0=C2=A0=C2=A0 To: Peter Psenak ; Aijun Wang ; 'Aijun Wang' > > =C2=A0=C2=A0=C2=A0 Cc: lsr=40ietf.org > > =C2=A0=C2=A0=C2=A0 Subject: Re: =5BLsr=5D =46W: New Version Notificat= ion for draft-wang-lsr-passive-interface-attribute-04.txt > > > > =C2=A0=C2=A0=C2=A0 Speaking as WG member: > > > > =C2=A0=C2=A0=C2=A0 Hi Aijun, Peter, > > =C2=A0=C2=A0=C2=A0=C2=A0I agree with Peter - one of the main motivati= ons for having areas is to abstract the topology within the area. Now you= 're trying to supplant this =C2=A0- one topological detail at a time with= ill-conceived IGP features. > > =C2=A0=C2=A0=C2=A0 Thanks, > > =C2=A0=C2=A0=C2=A0 Acee > > > > =C2=A0=C2=A0=C2=A0 On 9/29/20, 5:15 AM, =22Lsr on behalf of Peter Pse= nak=22 wrote: > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi Aijun, > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On 29/09/2020 11:07, Aijun= Wang wrote: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Hi, Peter: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Thanks for your com= ments. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > 1. =46or BGP-LS deployme= nt, there normally only be one router that within the > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > IGP domain to report the= topology information, this router should know such > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > passive links which exis= ts mainly on other border routers via the IGP > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > protocol. This is main r= eason to extension the IGP protocol. > 2. =46or the solution, normally, t= he link within the IGP connect two > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ends, but > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > passive interface is spe= cial and not fall in this space. We have studied the > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > current TLVs that for li= nk, and find no suitable container to append this > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > information. This is the= reason that we select the TLVs that associated with > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Prefix. > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if the link is unnumbered,= your solution does not work. As I said, if > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0you need a knowledge = about the link, you can not advertise it as a prefix. > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 thanks, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Peter > > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>=46rom other POV, t= he OSP=46v3 defines now the =22Intra-Area-Prefix LSA=22, which > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > isolate the prefix infor= mation that associated with link into this > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > container, contains the = stub link, local interface information etc. Put such > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > attribute along with the= prefix is then acceptable=3F > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Best Regards > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Aijun Wang > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > China Telecom > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> -----Original Messa= ge----- > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > =46rom: lsr-bounces=40ie= tf.org =5Bmailto:lsr-bounces=40ietf.org=5D On Behalf Of Peter > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Psenak > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Sent: Tuesday, September= 29, 2020 4:29 PM > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > To: Aijun Wang > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Cc: lsr=40ietf.org > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Subject: Re: =5BLsr=5D =46= W: New Version Notification for > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > draft-wang-lsr-passive-i= nterface-attribute-04.txt > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Hi Aijun, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> here's my comments:= > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> The purpose of this= draft is to advertise passive links. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> 1. I'm not sure the= problem needs to be solved by IGPs. I tend to believe > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > ietf-idr-bgpls-inter-as-= topology-ext is sufficient. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> 2. the solution tha= t you proposed is wrong. You are trying to derive > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > topological data about t= he passive links from the prefix advertisement. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > This is semantically inc= orrect and only works under very specific condition. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > If you need to advertise= a link, advertise it as a =22special=22 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > link, not as a =22specia= l=22 prefix. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> thanks, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Peter > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> On 29/09/2020 03:17= , Aijun Wang wrote: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Hi, Peter: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Would you like to revie= w and give comments on the updates version of this > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > draft=3F > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> We have also added the = protocol extension proposal for OSP=46v3. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> The update version of t= his draft can refer to > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> https://datatracker.iet= f.org/doc/html/draft-wang-lsr-passive-interface > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> -attribute > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Thanks in advance. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Best Regards > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> Aijun Wang > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> China Telecom > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> -----Original Message-= ---- > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> =46rom: internet-draft= s=40ietf.org =5Bmailto:internet-drafts=40ietf.org=5D > > =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0>>> Sent: Monday, Septembe= r 28, 2020 3:17 PM > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> To: Zhibo Hu ; Gyan Mishra > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> ; Aijun Wang ; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Gyan S. Mishra > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Subject: New Version N= otification for > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> draft-wang-lsr-passive= -interface-attribute-04.txt > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> A new version of I-D, > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> draft-wang-lsr-passive= -interface-attribute-04.txt > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> has been successfully = submitted by Aijun Wang and posted to the IET=46 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> repository. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Name:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-= wang-lsr-passive-interface-attribute > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Revision:=C2=A0=C2=A0 = 04 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Title:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Passive Interface Attribute > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Document date:=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 2020-09-28 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Group:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Indivi= dual Submission > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Pages:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 7 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> URL: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://www.ietf.org/i= d/draft-wang-lsr-passive-interface-attribute-04. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> txt > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Status: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://datatracker.ie= tf.org/doc/draft-wang-lsr-passive-interface-att > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> r > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> ibute/ > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Htmlized: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://datatracker.ie= tf.org/doc/html/draft-wang-lsr-passive-interfac > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> e > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> -attribut > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> e > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Htmlized: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://tools.ietf.org= /html/draft-wang-lsr-passive-interface-attribut > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> e > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> -04 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Diff: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> https://www.ietf.org/r= fcdiff=3Furl2=3Ddraft-wang-lsr-passive-interface-at > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> t > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> ribute-04 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Abstract: > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 This document describes the mechanism that can be used to > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 differentiate the passive interfaces from the normal interfaces > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>>=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 within ISIS or OSP=46 domain. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> Please note that it ma= y take a couple of minutes from the time of > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> submission until the h= tmlized version and diff are available at > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > tools.ietf.org. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> The IET=46 Secretariat= > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >>> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> =5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Lsr mailing list > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Lsr=40ietf.org > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mai= lman/listinfo/lsr > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lsr mailing list > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Lsr=40ietf.org > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailm= an/listinfo/lsr > > > > =C2=A0=C2=A0=C2=A0 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F > > =C2=A0=C2=A0=C2=A0 Lsr mailing list > > =C2=A0=C2=A0=C2=A0 Lsr=40ietf.org > > =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/lsr > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Lsr mailing list > > Lsr=40ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Lsr mailing list > > Lsr=40ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > -- > <> > Gyan Mishra > Network Solutions Architect > M 301 502-1347 > 13101 Columbia Pike > Silver Spring, MD > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Lsr mailing list > Lsr=40ietf.org > https://www.ietf.org/mailman/listinfo/lsr --5f84c918_5fb8370b_cede Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I=E2=80=99m with Acee here, the presence of a passi= ve interface in a topology is in no way unambiguously signaling domain bo= undaries. You could =E2=80=9Chack around=E2=80=9D though, but that would = defeat the purpose of an IET=46 document.
Keeping it to OSP=46v2 (other protocols have similar ways of doing that),= I=E2=80=99d say, using a technique similar to that, defined for Inter-AS= -TE-v2 LSA provides you exactly that.

Cheers,
Jeff
On Oct 12, 2020, 11:06 AM -0700, Ac= ee Lindem (acee) <acee=3D40cisco.com=40dmarc.ietf.org>, wrote:

Speaking WG member:

&=23160;

Hi Gyan, Aijun,

&=23160;

Even if I agreed with your use case assuming a= passive interface denotes the boundary between two domains as shown in f= igure 1 in your draft (which I don=E2=80=99t), you still should not be tr= ying to hack the prefixes with what is inherently link attribute. Can I s= tate this anymore simply or are you are just going to restate your requir= ements again=3F=3F=3F

&=23160;

Acee

&=23160;

=46rom: Gyan Mishra <hayabusagsm=40gmail.com>=
Date: Sunday, October 11, 2020 at 3:19 PM
To: Acee Lindem <acee=40cisco.com>
Cc: Aijun Wang <wangaijun=40tsinghua.org.cn>, Aijun Wang <= ;wangaj3=40chinatelecom.cn>, =22Peter Psenak (ppsenak)=22 <ppsenak=40= cisco.com>, =22lsr=40ietf.org=22 <lsr=40ietf.org>
Subject: Re: =5BLsr=5D =46W: New Version Notification for draft-wa= ng-lsr-passive-interface-attribute-04.txt

&=23160;

&=23160;

Hi Acee

&=23160;

I believe what = Aijun is trying to explain is that the primary purpose of PCE for active = or passive path computation is for inter-as RSVP-TE PCALC path computatio= n or SR-TE path computation.&=23160; So PCE is solving a well known PCALC= bin packing problem due to pcalc over subscribing RSVP tunnel bandwidth = which is inherent an RSVP issue, but a bigger problematic issue is with b= eing able to build an inter-as TE path with a single or multiple PCE cont= rollers that can take the LSDB link attributes in the TEDs dB opaque LSAs= in the ospf case and ISIS TE TLVs and rebuild the topology topology from= each TE domain to be able to build a congruent end to end RSVP TE or SR-= TE traffic steered path instantiation.

&=23160;

Without the use= of PCE controllers as the LSDB link attribute information is not known a= s RSVP loose ERO static lsp is built or SR SR-TE prefix sid loose path is= built, failover due to crank back is impacted for reroute, due to not ha= ving a complete depiction of the other AS Link state topology by the head= end or SR source node.

&=23160;

So to build tha= t entire end to end inter-as path for that end to end RSVP TE or SR-TE pa= th instantiation it is critical to indentify the inter-as link eBGP tie l= ink that may have static routes or BGP LU for RSVP head end to tail end r= eachability and SR-TE reachability to build out the end to end path insta= ntiation.&=23160; So the BGP-LS task to &=23160;rebuild the lsdb topology= of each inter connected AS that the RSVP TE or SR-TE steered path traver= ses, we need the accurate depiction and that includes the Identification = of the &=23160;critical inter-as tie link eBGP peering link that is passi= ve for the PCE path computation logic for the end to end inter-as path in= stantiation. &=23160;

&=23160;

As for other in= terfaces using passive in the context of a operator service provider or e= nterprise core P and PE routers all links are transit with neighbors exce= pt the inter-as tie so having this new IGP TLV will help to that end.&=23= 160; In the operator =E2=80=9Ccore=E2=80=9D network if there are other &=23= 160;interfaces that don=E2=80=99t need to be advertised as stub, they can= easily be excluded from being added into IGP. &=23160;

&=23160;

Kind Regards&=23= 160;

&=23160;

Gyan

&=23160;

On Sat, Oct 10,= 2020 at 6:29 AM Acee Lindem (acee) <acee=3D40cisco.com=40dmarc.ietf.org> wrote:

=

Hi Aijun,

&=23160;

=46rom: Aijun Wang <wangaijun=40tsinghua.org.cn>
Date: =46riday, October 9, 2020 at 9:58 PM
To: Acee Lindem <acee=40cisco.com>, =22Peter Psenak (ppsenak)=22 = <pp= senak=40cisco.com>, 'Aijun Wang' <wangaj3=40chinatelecom.cn&= gt;
Cc: =22lsr=40ietf.org=22 <lsr=40ietf.org>
Subject: RE: =5BLsr=5D =46W: New Version Notification for draft-wa= ng-lsr-passive-interface-attribute-04.txt

&=23160;

Hi, Acee:

&=23160;

=46rom: lsr-bounces=40ietf.org<= /a> =5Bmailto:lsr-bounces=40ietf.org=5D On Behalf Of Acee Lindem (a= cee)
Sent: Saturday, October 10, 2020 3:48 AM
To: Aijun Wang <wangaijun=40tsinghua.org.cn>; Peter Ps= enak (ppsenak) <ppsenak=40cisco.com>; 'Aijun Wang' <wangaj3=40china= telecom.cn>
Cc: = lsr=40ietf.org
Subject: Re: =5BLsr=5D =46W: New Version Notification for draft-wa= ng-lsr-passive-interface-attribute-04.txt

&=23160;

Speaking as WG member:

&=23160;

Hi Aijun,

&=23160;

=46rom: Aijun Wang <wangaijun=40tsinghua.org.cn>
Date: Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem <acee=40cisco.com>, =22Peter Psenak (ppsenak)=22 = <pp= senak=40cisco.com>, 'Aijun Wang' <wangaj3=40chinatelecom.cn&= gt;
Cc: =22lsr=40ietf.org=22 <lsr=40ietf.org>
Subject: RE: =5BLsr=5D =46W: New Version Notification for draft-wa= ng-lsr-passive-interface-attribute-04.txt

&=23160;

Hi, Acee:

Sorry for the previous pruned mail. Let's reply you again alo= ng your original question.

Please see inline.=5BWAJ=5D

&=23160;

-----Original Message-----&=23160;&=23160;&=23160;&=23160;&=23= 160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=2316= 0;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160= ;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;= &=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&= =23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23= 160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=2316= 0;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160= ;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;= &=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&= =23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23= 160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=2316= 0;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;
=46rom: lsr-bounces=40ietf.org =5Bmailto:lsr-bounces=40ietf.org=5D On B= ehalf Of Acee Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: Aijun Wang <wangaijun=40tsinghua.org.cn>; Peter Psenak (p= psenak) <ppsenak=40cisco.com>; 'Aijun Wang' <wangaj3=40chinateleco= m.cn>
Cc: lsr=40i= etf.org
Subject: Re: =5BLsr=5D =46W: New Version Notification for draft-wang-lsr-= passive-interface-attribute-04.txt

&=23160;

Hi Aijun,

Other than your ill-conceived topology discovery heuristic

=5BWAJ=5D The topology discovery heuristic is not suitable fo= r the corner use case when the unnumbered interface is used, as explained= in https://tools.ietf.o= rg/html/draft-ietf-lsr-ospf-prefix-originator-06=23appendix-B.&=23160= ; If you don=E2=80= =99t agree, would you like to illustrate other non-applicable scen= arios=3F

&=23160;

Right =E2=80=93 and nobody other than yourself believes the IG= Ps should be modified to expose the abstracted topology of an area outsid= e that area.

=5BWAJ=5D &=23160;= The modification doesn=E2=80=99t change the way and complexity of route c= alculation within IGP. It just piggyback some extra information, the bulk= of the reconstruction work is done by the controller.&=23160; Such extra= information can also have other usage, as described in https://tools.ietf.org/html/draft-ietf-lsr= -ospf-prefix-originator-06=23section-1

And, the proposal = described in https://d= atatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-attribute-0= 4 is different with the problem you concerned.&=23160; It has no rela= tion with the abstracted topology of an area.&=23160; Maybe you are confu= sed by these two drafts=3F

&=23160;

It is a similar problem. You are still trying to overload the pr= efix advertisements with a link attribute (passive interface) so that it = can be conveyed outside the domain. We certainly wouldn=E2=80=99t waste a= limited prefix flag on this parochial application.

&=23160;

&=23160;

You can solve the problem with BGP-LS session(s) between the r= outer with a BGP-LS session to the controller and a router in each area w= /o &=23160;a router with a BGP-LS session to the controller.

=5BWAJ=5D This is = possible, but not efficient. =46or operation, we must also consider the c= onfiguration/administration overhead.&=23160; BGP-LS is designed mainly f= or the northbound protocol, not east-west protocol.

&=23160;

what other possible reason would there be for associating the= passive attribute with a prefix=3F

=5BWAJ=5D To know the boundar= y of the IGP domain. After knowing the boundary, the controller can safel= y apply and check the network security policy, the inbound traffic contro= l policy etc.

&=23160;

It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. = How does the presence of a prefix associated with a passive interface all= ow you to make this deduction=3F

=5BWAJ=5D Passive = interfaces are deployed mainly at the boundary of IGP domain.&=23160; Is = there any other exception=3F

While passive interfaces are not standardized, there is nothing = that limits their usage to an IGP boundary. They can and are deployed on = any interface where adjacencies are not to be formed (e.g., a stub subnet= containing hosts).

&=23160;

Thanks,
Acee

&=23160;

Thanks,

Acee

&=23160;

Thanks,

Acee

&=23160;

On 9/29/20, 10:39 PM, =22Aijun Wang=22 <wangaijun=40tsinghua.org.cn> wrote:

&=23160;

&=23160;&=23160;&=23160; Hi, Acee and Peter:

&=23160;&=23160;&=23160; Passive interface is mainly used at = the edge of the network, where the unnumbered interface will not be used.=

&=23160;&=23160;&=23160;&=23160;And the information to flag t= he passive interfaces is for positioning the area boundary, not conflict = with the abstract capabilities of the area inside.

&=23160;

&=23160;

&=23160;&=23160;&=23160; Best Regards

&=23160;

&=23160;&=23160;&=23160; Aijun Wang

&=23160;&=23160;&=23160; China Telecom

&=23160;

&=23160;&=23160;&=23160; -----Original Message-----

&=23160;&=23160;&=23160; =46rom: lsr-bounces=40ietf.org =5Bmailto:lsr-bounces=40ietf.org= =5D On Behalf Of Acee Lindem (acee)

&=23160;&=23160;&=23160; Sent: Tuesday, September 29, 2020 9:= 16 PM

&=23160;&=23160;&=23160; To: Peter Psenak <ppsenak=3D40cisco= .com=40dmarc.ietf.org>; Aijun Wang <wangaijun=40tsinghua.org.cn>; 'Aijun Wang' <wangaj3=40chinatelecom.cn>

&=23160;&=23160;&=23160; Cc: lsr=40ietf.org

&=23160;&=23160;&=23160; Subject: Re: =5BLsr=5D =46W: New Ver= sion Notification for draft-wang-lsr-passive-interface-attribute-04.txt

&=23160;

&=23160;&=23160;&=23160; Speaking as WG member:

&=23160;

&=23160;&=23160;&=23160; Hi Aijun, Peter,

&=23160;&=23160;&=23160;&=23160;I agree with Peter - one of t= he main motivations for having areas is to abstract the topology within t= he area. Now you're trying to supplant this &=23160;- one topological det= ail at a time with ill-conceived IGP features.

&=23160;&=23160;&=23160; Thanks,

&=23160;&=23160;&=23160; Acee

&=23160;

&=23160;&=23160;&=23160; On 9/29/20, 5:15 AM, =22Lsr on behal= f of Peter Psenak=22 <lsr-bo= unces=40ietf.org on behalf of ppsenak=3D40cisco.com=40dmarc.ietf.org> wrote:

&=23160;

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; Hi A= ijun,

&=23160;

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; On 2= 9/09/2020 11:07, Aijun Wang wrote:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= Hi, Peter:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> Thanks for your comments.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= 1. =46or BGP-LS deployment, there normally only be one router that withi= n the

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= IGP domain to report the topology information, this router should know s= uch

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= passive links which exists mainly on other border routers via the IGP

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= protocol. This is main reason to extension the IGP protocol. > 2. =46= or the solution, normally, the link within the IGP connect two

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;ends, but

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= passive interface is special and not fall in this space. We have studied= the

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= current TLVs that for link, and find no suitable container to append thi= s

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= information. This is the reason that we select the TLVs that associated = with

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= Prefix.

&=23160;

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; if t= he link is unnumbered, your solution does not work. As I said, if

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;you need a knowledge about the link, you can not advertise it as a pre= fix.

&=23160;

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; than= ks,

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; Pete= r

&=23160;

&=23160;

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;>>=46rom other POV, the OSP=46v3 defines now the =22Intra-Area-P= refix LSA=22, which

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= isolate the prefix information that associated with link into this

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= container, contains the stub link, local interface information etc. Put = such

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= attribute along with the prefix is then acceptable=3F

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> Best Regards

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> Aijun Wang

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= China Telecom

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> -----Original Message-----

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= =46rom: lsr-bounc= es=40ietf.org =5Bmailto:lsr-bounces=40ietf.org=5D On Behalf Of Peter<= /p>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= Psenak

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= Sent: Tuesday, September 29, 2020 4:29 PM

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= To: Aijun Wang <wangaj3=40chinatelecom.cn>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= Cc: lsr=40ietf.org=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= Subject: Re: =5BLsr=5D =46W: New Version Notification for

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= draft-wang-lsr-passive-interface-attribute-04.txt

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> Hi Aijun,

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> here's my comments:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> The purpose of this draft is to advertise passive links.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> 1. I'm not sure the problem needs to be solved by IGPs. I tend to= believe

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= ietf-idr-bgpls-inter-as-topology-ext is sufficient.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> 2. the solution that you proposed is wrong. You are trying to der= ive

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= topological data about the passive links from the prefix advertisement.<= /p>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= This is semantically incorrect and only works under very specific condit= ion.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= If you need to advertise a link, advertise it as a =22special=22

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= link, not as a =22special=22 prefix.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> thanks,

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= Peter

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> On 29/09/2020 03:17, Aijun Wang wrote:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > Hi, Peter:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > Would you like to review and give comments on the updates version of= this

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= draft=3F

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > We have also added the protocol extension proposal for OSP=46v3.

=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > The update version of this draft can refer to

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > https://datatracker.ietf.org/doc/html/draft-w= ang-lsr-passive-interface

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > -attribute

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > Thanks in advance.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > Best Regards

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > Aijun Wang

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= > China Telecom

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> -----Original Message-----

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> =46rom: internet-drafts=40ietf.org =5Bmailto:internet-drafts=40ietf.org=5D=

&=23160;&=23160;&=23160;&=23160; &=23160;&=23160;&=23160;>= >> Sent: Monday, September 28, 2020 3:17 PM

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> To: Zhibo Hu <huzhibo=40huawei.com>; Gyan Mishra

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> <= gyan.s.mishra=40verizon.com>; Aijun Wang <wangaj3=40chinatelecom.cn>;

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Gyan S. Mishra <gyan.s.mishra=40verizon.com>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Subject: New Version Notification for

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> draft-wang-lsr-passive-interface-attribute-04.txt

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> A new version of I-D,

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> draft-wang-lsr-passive-interface-attribute-04.txt

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> has been successfully submitted by Aijun Wang and posted to the = IET=46

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> repository.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Name:&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23= 160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; draft-wang-lsr-passi= ve-interface-attribute

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Revision:&=23160;&=23160; 04

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Title:&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23= 160; Passive Interface Attribute

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Document date:&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; 2= 020-09-28

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Group:&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23= 160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; Individual Submissio= n

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Pages:&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23= 160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; 7

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> URL:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> https://www.ietf.org/id/draft-wang-lsr-pas= sive-interface-attribute-04.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> txt

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Status:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> https://datatracker.ietf.org/doc/draft-wan= g-lsr-passive-interface-att

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> r

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> ibute/

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Htmlized:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> https://datatracker.ietf.org/doc/html/draf= t-wang-lsr-passive-interfac

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> e

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> -attribut

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> e

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Htmlized:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> https://tools.ietf.org/html/draft-wang-lsr= -passive-interface-attribut

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> e

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> -04

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Diff:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> https://www.ietf.org/rfcdiff=3Furl2=3D= draft-wang-lsr-passive-interface-at

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> t

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> ribute-04

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Abstract:

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>&=23160;&=23160;&=23160;&=23160;&=23160; This document describes = the mechanism that can be used to

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>&=23160;&=23160;&=23160;&=23160;&=23160; differentiate the passiv= e interfaces from the normal interfaces

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>&=23160;&=23160;&=23160;&=23160;&=23160; within ISIS or OSP=46 do= main.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> Please note that it may take a couple of minutes from the time o= f

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> submission until the htmlized version and diff are available at<= /p>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= tools.ietf= .org.

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >> The IET=46 Secretariat

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= >

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= Lsr mailing list

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= Lsr=40ietf.org=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >= https:= //www.ietf.org/mailman/listinfo/lsr

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; >=

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;>

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=231= 60;>

&=23160;

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; =5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; Lsr = mailing list

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; Lsr=40ietf.org

&=23160;&=23160;&=23160;&=23160;&=23160;&=23160;&=23160; https://ww= w.ietf.org/mailman/listinfo/lsr

&=23160;

&=23160;&=23160;&=23160; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F

&=23160;&=23160;&=23160; Lsr mailing list

&=23160;&=23160;&=23160; Lsr=40ietf.org

&=23160;&=23160;&=23160; https://www.ietf.org/mailman/listinfo/lsr<= /span>

&=23160;

&=23160;

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F

Lsr mailing list

Lsr=40ietf.org=

https://www.ietf.org/mailman/listinfo/lsr

=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Lsr mailing list
Lsr=40ietf.= org
https://www.ietf.org/mailman/listinfo/lsr

--

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Lsr mailing list
Lsr=40ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--5f84c918_5fb8370b_cede-- From nobody Mon Oct 12 19:24:53 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF003A02BD for ; Mon, 12 Oct 2020 19:24:52 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 3QqAiiGf1X2P for ; Mon, 12 Oct 2020 19:24:47 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328573A0DA1 for ; Mon, 12 Oct 2020 19:24:45 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 3AA694602F; Tue, 13 Oct 2020 10:24:41 +0800 (CST) From: "Aijun Wang" To: "'Jeff Tantsura'" , "'Gyan Mishra'" , "'Acee Lindem \(acee\)'" Cc: , "'Aijun Wang'" , "'Peter Psenak \(ppsenak\)'" References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> <30d11575-2e24-4add-8bf6-454fdbf07ceb@Spark> In-Reply-To: <30d11575-2e24-4add-8bf6-454fdbf07ceb@Spark> Date: Tue, 13 Oct 2020 10:24:39 +0800 Message-ID: <009b01d6a108$00e92ce0$02bb86a0$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01D6A14B.0F126050" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIJ+mWorx9ReexromEfqpSgpX3kFwEFLd5+AaLg+ScCZ8Mz1AFBnbZFAnYY+uECbteHkQJR6V6DAmQjRUkCKRShvAHJrWG+AiX9uxECprbmHQE/dJ3TqF6svIA= Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQhhNGh0dHUsZGEtOVkpNS0lOTk5DQ0pNTkhVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Kxw6Shw*PD8eLzk9GCMXMkg# Hx8wCiFVSlVKTUtJTk5OQ0NJT05KVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpKQkNISDcG X-HM-Tid: 0a751fc627d69865kuuu3aa694602f Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 02:24:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009C_01D6A14B.0F126050 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Jeff: =20 Using the solution that similar with Inter-AS-TE-v2 = LSA(https://tools.ietf.org/html/rfc5392#section-3.1.1) is = straightforward but has the following constraints: 1. It requires the configuration of the remote-as/remote ASBR ID on = border router, and requires the advertisement of the redundant = information on every Link TLV that included in such LSA. 2. It requires the configuration of the remote interface address on = every inter-as link, which is tedious work. 3. It requires the proxy of remote neighbor information on every = inter-as link, as that described in = https://tools.ietf.org/html/rfc5392#section-4.1 =20 Such solution is obvious not as concise as deducting the IGP domain = boundary from the passive interface attribute and interconnect them by = the PCE.=20 And the PCE doesn=E2=80=99t depend solely on such information to = reconstruct the boundary, it has some algorithm to exclude the = extraordinary scenario=E3=80=90for example, when the prefix length is = 32(IPv4) or 128(IPv6)bit length=E3=80=91=20 =20 The ASBR just needs to flag the prefix is coming from the passive = interface, nothing more. Such flag mechanism is not defeat the purpose = of IETF document. =20 And Acee: Please see inline for your concerns. =20 =20 Best Regards =20 Aijun Wang China Telecom =20 From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com]=20 Sent: Tuesday, October 13, 2020 5:22 AM To: Gyan Mishra ; Acee Lindem (acee) = Cc: lsr@ietf.org; Aijun Wang ; Aijun Wang = ; Peter Psenak (ppsenak) Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 I=E2=80=99m with Acee here, the presence of a passive interface in a = topology is in no way unambiguously signaling domain boundaries. You = could =E2=80=9Chack around=E2=80=9D though, but that would defeat the = purpose of an IETF document. Keeping it to OSPFv2 (other protocols have similar ways of doing that), = I=E2=80=99d say, using a technique similar to that, defined for = Inter-AS-TE-v2 LSA provides you exactly that. =20 Cheers,=20 Jeff On Oct 12, 2020, 11:06 AM -0700, Acee Lindem (acee) = >, wrote: Speaking WG member: =20 Hi Gyan, Aijun, =20 Even if I agreed with your use case assuming a passive interface denotes = the boundary between two domains as shown in figure 1 in your draft = (which I don=E2=80=99t), you still should not be trying to hack the = prefixes with what is inherently link attribute. [WAJ] There is no space now within the IGP protocol to describe the = stub/passive link attribute. When we talk link, we often refer to the = link that connects two IGP neighbors. And, using the prefix passive flag to position the IGP boundary, is the = reasonable deduction, not hack.=20 Can I state this anymore simply or are you are just going to restate = your requirements again??? [WAJ] Just want to emphasize the potential usage of such information, = and be clear also for other experts. =20 Acee =20 From: Gyan Mishra = > Date: Sunday, October 11, 2020 at 3:19 PM To: Acee Lindem > Cc: Aijun Wang >, Aijun Wang = >, "Peter = Psenak (ppsenak)" >, = "lsr@ietf.org " > Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 =20 Hi Acee =20 I believe what Aijun is trying to explain is that the primary purpose of = PCE for active or passive path computation is for inter-as RSVP-TE PCALC = path computation or SR-TE path computation. So PCE is solving a well = known PCALC bin packing problem due to pcalc over subscribing RSVP = tunnel bandwidth which is inherent an RSVP issue, but a bigger = problematic issue is with being able to build an inter-as TE path with a = single or multiple PCE controllers that can take the LSDB link = attributes in the TEDs dB opaque LSAs in the ospf case and ISIS TE TLVs = and rebuild the topology topology from each TE domain to be able to = build a congruent end to end RSVP TE or SR-TE traffic steered path = instantiation. =20 Without the use of PCE controllers as the LSDB link attribute = information is not known as RSVP loose ERO static lsp is built or SR = SR-TE prefix sid loose path is built, failover due to crank back is = impacted for reroute, due to not having a complete depiction of the = other AS Link state topology by the head end or SR source node. =20 So to build that entire end to end inter-as path for that end to end = RSVP TE or SR-TE path instantiation it is critical to indentify the = inter-as link eBGP tie link that may have static routes or BGP LU for = RSVP head end to tail end reachability and SR-TE reachability to build = out the end to end path instantiation. So the BGP-LS task to rebuild = the lsdb topology of each inter connected AS that the RSVP TE or SR-TE = steered path traverses, we need the accurate depiction and that includes = the Identification of the critical inter-as tie link eBGP peering link = that is passive for the PCE path computation logic for the end to end = inter-as path instantiation. =20 =20 As for other interfaces using passive in the context of a operator = service provider or enterprise core P and PE routers all links are = transit with neighbors except the inter-as tie so having this new IGP = TLV will help to that end. In the operator =E2=80=9Ccore=E2=80=9D = network if there are other interfaces that don=E2=80=99t need to be = advertised as stub, they can easily be excluded from being added into = IGP. =20 =20 Kind Regards=20 =20 Gyan =20 On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) = > = wrote: Hi Aijun, =20 From: Aijun Wang > Date: Friday, October 9, 2020 at 9:58 PM To: Acee Lindem >, "Peter Psenak = (ppsenak)" >, 'Aijun Wang' = > Cc: "lsr@ietf.org " > Subject: RE: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Hi, Acee: =20 From: lsr-bounces@ietf.org = [mailto:lsr-bounces@ietf.org ] On Behalf = Of Acee Lindem (acee) Sent: Saturday, October 10, 2020 3:48 AM To: Aijun Wang >; Peter Psenak (ppsenak) = >; 'Aijun Wang' = > Cc: lsr@ietf.org =20 Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Speaking as WG member: =20 Hi Aijun, =20 From: Aijun Wang > Date: Thursday, October 8, 2020 at 11:09 PM To: Acee Lindem >, "Peter Psenak = (ppsenak)" >, 'Aijun Wang' = > Cc: "lsr@ietf.org " > Subject: RE: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Hi, Acee: Sorry for the previous pruned mail. Let's reply you again along your = original question. Please see inline.[WAJ] =20 -----Original Message----- = = =20 From: lsr-bounces@ietf.org = [mailto:lsr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Wednesday, September 30, 2020 7:47 PM To: Aijun Wang >; Peter Psenak (ppsenak) = >; 'Aijun Wang' = > Cc: lsr@ietf.org =20 Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Hi Aijun, Other than your ill-conceived topology discovery heuristic [WAJ] The topology discovery heuristic is not suitable for the corner = use case when the unnumbered interface is used, as explained in = https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appe= ndix-B. If you don=E2=80=99t agree, would you like to illustrate other = non-applicable scenarios? =20 Right =E2=80=93 and nobody other than yourself believes the IGPs should = be modified to expose the abstracted topology of an area outside that = area. [WAJ] The modification doesn=E2=80=99t change the way and complexity of = route calculation within IGP. It just piggyback some extra information, = the bulk of the reconstruction work is done by the controller. Such = extra information can also have other usage, as described in = https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#sect= ion-1 And, the proposal described in = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-at= tribute-04 is different with the problem you concerned. It has no = relation with the abstracted topology of an area. Maybe you are = confused by these two drafts? =20 It is a similar problem. You are still trying to overload the prefix = advertisements with a link attribute (passive interface) so that it can = be conveyed outside the domain. We certainly wouldn=E2=80=99t waste a = limited prefix flag on this parochial application. =20 =20 You can solve the problem with BGP-LS session(s) between the router with = a BGP-LS session to the controller and a router in each area w/o a = router with a BGP-LS session to the controller. [WAJ] This is possible, but not efficient. For operation, we must also = consider the configuration/administration overhead. BGP-LS is designed = mainly for the northbound protocol, not east-west protocol. =20 what other possible reason would there be for associating the passive = attribute with a prefix? [WAJ] To know the boundary of the IGP domain. After knowing the = boundary, the controller can safely apply and check the network security = policy, the inbound traffic control policy etc. =20 It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How does = the presence of a prefix associated with a passive interface allow you = to make this deduction? [WAJ] Passive interfaces are deployed mainly at the boundary of IGP = domain. Is there any other exception? While passive interfaces are not standardized, there is nothing that = limits their usage to an IGP boundary. They can and are deployed on any = interface where adjacencies are not to be formed (e.g., a stub subnet = containing hosts). =20 Thanks, Acee =20 Thanks, Acee =20 Thanks, Acee =20 On 9/29/20, 10:39 PM, "Aijun Wang" < = wangaijun@tsinghua.org.cn> wrote: =20 Hi, Acee and Peter: Passive interface is mainly used at the edge of the network, where = the unnumbered interface will not be used. And the information to flag the passive interfaces is for = positioning the area boundary, not conflict with the abstract = capabilities of the area inside. =20 =20 Best Regards =20 Aijun Wang China Telecom =20 -----Original Message----- From: lsr-bounces@ietf.org [ = mailto:lsr-bounces@ietf.org] On Behalf Of = Acee Lindem (acee) Sent: Tuesday, September 29, 2020 9:16 PM To: Peter Psenak < = ppsenak=3D40cisco.com@dmarc.ietf.org>; Aijun Wang < = wangaijun@tsinghua.org.cn>; 'Aijun = Wang' < wangaj3@chinatelecom.cn> Cc: lsr@ietf.org Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt =20 Speaking as WG member: =20 Hi Aijun, Peter, I agree with Peter - one of the main motivations for having areas is = to abstract the topology within the area. Now you're trying to supplant = this - one topological detail at a time with ill-conceived IGP = features. Thanks, Acee =20 On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" < = lsr-bounces@ietf.org on behalf of = ppsenak=3D40cisco.com@dmarc.ietf.org> wrote: =20 Hi Aijun, =20 On 29/09/2020 11:07, Aijun Wang wrote: > Hi, Peter: > > Thanks for your comments. > 1. For BGP-LS deployment, there normally only be one router = that within the > IGP domain to report the topology information, this router = should know such > passive links which exists mainly on other border routers via = the IGP > protocol. This is main reason to extension the IGP protocol. > = 2. For the solution, normally, the link within the IGP connect two ends, but > passive interface is special and not fall in this space. We = have studied the > current TLVs that for link, and find no suitable container to = append this > information. This is the reason that we select the TLVs that = associated with > Prefix. =20 if the link is unnumbered, your solution does not work. As I = said, if you need a knowledge about the link, you can not advertise it as = a prefix. =20 thanks, Peter =20 =20 > >>From other POV, the OSPFv3 defines now the "Intra-Area-Prefix = LSA", which > isolate the prefix information that associated with link into = this > container, contains the stub link, local interface information = etc. Put such > attribute along with the prefix is then acceptable? > > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: lsr-bounces@ietf.org [ = mailto:lsr-bounces@ietf.org] On Behalf Of = Peter > Psenak > Sent: Tuesday, September 29, 2020 4:29 PM > To: Aijun Wang < = wangaj3@chinatelecom.cn> > Cc: lsr@ietf.org > Subject: Re: [Lsr] FW: New Version Notification for > draft-wang-lsr-passive-interface-attribute-04.txt > > Hi Aijun, > > here's my comments: > > The purpose of this draft is to advertise passive links. > > 1. I'm not sure the problem needs to be solved by IGPs. I tend = to believe > ietf-idr-bgpls-inter-as-topology-ext is sufficient. > > 2. the solution that you proposed is wrong. You are trying to = derive > topological data about the passive links from the prefix = advertisement. > This is semantically incorrect and only works under very = specific condition. > If you need to advertise a link, advertise it as a "special" > link, not as a "special" prefix. > > thanks, > Peter > > On 29/09/2020 03:17, Aijun Wang wrote: >> Hi, Peter: >> >> Would you like to review and give comments on the updates = version of this > draft? >> We have also added the protocol extension proposal for = OSPFv3. >> >> The update version of this draft can refer to >> = = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface >> -attribute >> Thanks in advance. >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >>> -----Original Message----- >>> From: = internet-drafts@ietf.org [ = mailto:internet-drafts@ietf.org] >>> Sent: Monday, September 28, 2020 3:17 PM >>> To: Zhibo Hu < = huzhibo@huawei.com>; Gyan Mishra >>> < = gyan.s.mishra@verizon.com>; Aijun Wang < = wangaj3@chinatelecom.cn>; >>> Gyan S. Mishra < = gyan.s.mishra@verizon.com> >>> Subject: New Version Notification for >>> draft-wang-lsr-passive-interface-attribute-04.txt >>> >>> >>> A new version of I-D, >>> draft-wang-lsr-passive-interface-attribute-04.txt >>> has been successfully submitted by Aijun Wang and posted to = the IETF >>> repository. >>> >>> Name: = draft-wang-lsr-passive-interface-attribute >>> Revision: 04 >>> Title: Passive Interface Attribute >>> Document date: 2020-09-28 >>> Group: Individual Submission >>> Pages: 7 >>> URL: >>> = = https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04. >>> txt >>> Status: >>> = = https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att >>> r >>> ibute/ >>> Htmlized: >>> = = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac >>> e >>> -attribut >>> e >>> Htmlized: >>> = = https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut >>> e >>> -04 >>> Diff: >>> = = https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-interface-at >>> t >>> ribute-04 >>> >>> Abstract: >>> This document describes the mechanism that can be used = to >>> differentiate the passive interfaces from the normal = interfaces >>> within ISIS or OSPF domain. >>> >>> >>> >>> >>> 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 . >>> >>> The IETF Secretariat >>> >> >> >> >> > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > = https://www.ietf.org/mailman/listinfo/lsr > > > =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr =20 =20 _______________________________________________ Lsr mailing list Lsr@ietf.org = https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org =20 https://www.ietf.org/mailman/listinfo/lsr -- <> Gyan Mishra Network Solutions Architect=20 M 301 502-1347 13101 Columbia Pike=20 Silver Spring, MD =20 _______________________________________________ Lsr mailing list Lsr@ietf.org =20 https://www.ietf.org/mailman/listinfo/lsr ------=_NextPart_000_009C_01D6A14B.0F126050 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

H= i, Jeff:

<= o:p> 

U= sing the solution that similar with Inter-AS-TE-v2 LSA(https://tools.= ietf.org/html/rfc5392#section-3.1.1) is straightforward but has the = following constraints:

<= span style=3D'mso-list:Ignore'>1.     I= t requires the configuration of the remote-as/remote ASBR ID on border = router, and requires the advertisement of the redundant information on = every Link TLV that included in such LSA.

<= span style=3D'mso-list:Ignore'>2.     I= t requires the configuration of the remote interface address on every = inter-as link, which is tedious work.

<= span style=3D'mso-list:Ignore'>3.     I= t requires the proxy of remote neighbor information on every inter-as = link, as that described in https://tools.ie= tf.org/html/rfc5392#section-4.1

<= o:p> 

S= uch solution is obvious not as concise as deducting the IGP domain = boundary from the passive interface attribute and interconnect them by = the PCE.

A= nd the PCE doesn=E2=80=99t depend solely on such information to = reconstruct the boundary, it has some algorithm to exclude the = extraordinary scenario=E3= =80=90for example, when the prefix length is 32(IPv4) = or 128(IPv6)bit length=E3=80=91

<= o:p> 

T= he ASBR just needs to flag the prefix is coming from the passive = interface, nothing more. Such flag mechanism is not defeat the purpose = of IETF document.

<= o:p> 

A= nd Acee:

P= lease see inline for your concerns.

<= o:p> 

<= o:p> 

B= est Regards

<= o:p> 

A= ijun Wang

C= hina Telecom<= o:p>

<= o:p> 

From:<= /b> Jeff = Tantsura [mailto:jefftant.ietf@gmail.com]
Sent: Tuesday, = October 13, 2020 5:22 AM
To: Gyan Mishra = <hayabusagsm@gmail.com>; Acee Lindem (acee) = <acee=3D40cisco.com@dmarc.ietf.org>
Cc: lsr@ietf.org; = Aijun Wang <wangaj3@chinatelecom.cn>; Aijun Wang = <wangaijun@tsinghua.org.cn>; Peter Psenak (ppsenak) = <ppsenak@cisco.com>
Subject: Re: [Lsr] FW: New Version = Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

I=E2=80=99m with Acee here, the presence of a passive = interface in a topology is in no way unambiguously signaling domain = boundaries. You could =E2=80=9Chack around=E2=80=9D though, but that = would defeat the purpose of an IETF document.


Keeping it to OSPFv2 (other protocols have similar ways = of doing that), I=E2=80=99d say, using a technique similar to that, = defined for Inter-AS-TE-v2 LSA provides you exactly = that.

 

Cheers,

Jeff

On Oct 12, 2020, 11:06 AM -0700, Acee Lindem (acee) <acee=3D40cisco.com@dmar= c.ietf.org>, wrote:

Speaking WG = member:

 

Hi Gyan, Aijun,

 

Even if I agreed with your use case = assuming a passive interface denotes the boundary between two domains as = shown in figure 1 in your draft (which I don=E2=80=99t), you still = should not be trying to hack the prefixes with what is inherently link = attribute.

[= WAJ] There is no space now within the IGP protocol to describe the = stub/passive link attribute. When we talk link, we often refer to the = link that connects two IGP neighbors.

A= nd, using the prefix passive flag to position the IGP boundary, is the = reasonable deduction, not hack.

=C2=A0Can I state this anymore simply or = are you are just going to restate your requirements = again???

[= WAJ] Just want to emphasize the potential usage of such information, and = be clear also for other experts.<= o:p>

 

Acee

 

From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sunday, October 11, 2020 at 3:19 PM
To: Acee Lindem = <acee@cisco.com>
Cc: = Aijun Wang <wangaijun@tsinghua.org.cn&g= t;, Aijun Wang <wangaj3@chinatelecom.cn>, = "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Subject: Re: = [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

 

Hi = Acee

 

I believe what Aijun is trying to = explain is that the primary purpose of PCE for active or passive path = computation is for inter-as RSVP-TE PCALC path computation or SR-TE path = computation.  So PCE is solving a well known PCALC bin packing = problem due to pcalc over subscribing RSVP tunnel bandwidth which is = inherent an RSVP issue, but a bigger problematic issue is with being = able to build an inter-as TE path with a single or multiple PCE = controllers that can take the LSDB link attributes in the TEDs dB opaque = LSAs in the ospf case and ISIS TE TLVs and rebuild the topology topology = from each TE domain to be able to build a congruent end to end RSVP TE = or SR-TE traffic steered path = instantiation.

 

Without the use of PCE controllers as = the LSDB link attribute information is not known as RSVP loose ERO = static lsp is built or SR SR-TE prefix sid loose path is built, failover = due to crank back is impacted for reroute, due to not having a complete = depiction of the other AS Link state topology by the head end or SR = source node.

 

So to build that entire end to end = inter-as path for that end to end RSVP TE or SR-TE path instantiation it = is critical to indentify the inter-as link eBGP tie link that may have = static routes or BGP LU for RSVP head end to tail end reachability and = SR-TE reachability to build out the end to end path instantiation.  = So the BGP-LS task to  rebuild the lsdb topology of each inter = connected AS that the RSVP TE or SR-TE steered path traverses, we need = the accurate depiction and that includes the Identification of the =  critical inter-as tie link eBGP peering link that is passive for = the PCE path computation logic for the end to end inter-as path = instantiation.  

 

As for other interfaces using passive in = the context of a operator service provider or enterprise core P and PE = routers all links are transit with neighbors except the inter-as tie so = having this new IGP TLV will help to that end.  In the operator = =E2=80=9Ccore=E2=80=9D network if there are other  interfaces that = don=E2=80=99t need to be advertised as stub, they can easily be excluded = from being added into IGP.  

 

Kind = Regards 

 

Gyan

 

On Sat, Oct 10, 2020 at 6:29 AM Acee = Lindem (acee) <acee=3D40cisco.com@dmarc.ietf.org= > wrote:

Hi Aijun,

 

From: Aijun Wang <wangaijun@tsinghua.org.cn>
Date: = Friday, October 9, 2020 at 9:58 PM
To: Acee Lindem <acee@cisco.com>, = "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: "lsr@ietf.org" = <lsr@ietf.org>
Subject: RE: [Lsr] FW: = New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Hi, = Acee:

 

From: = lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Acee = Lindem (acee)
Sent: Saturday, October 10, 2020 3:48 = AM
To: Aijun Wang <wangaijun@tsinghua.org.cn>; Peter Psenak = (ppsenak) <ppsenak@cisco.com>; 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New = Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Speaking as WG = member:

 

Hi Aijun,

 

From: Aijun Wang <wangaijun@tsinghua.org.cn>
Date: = Thursday, October 8, 2020 at 11:09 PM
To: Acee Lindem <acee@cisco.com>, = "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: "lsr@ietf.org" = <lsr@ietf.org>
Subject: RE: [Lsr] FW: = New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Hi, Acee:

Sorry for the previous pruned mail. Let's reply you again = along your original question.

Please see inline.[WAJ]

 

-----Original = Message-----          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;         
From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Acee = Lindem (acee)
Sent: Wednesday, September 30, 2020 7:47 PM
To: = Aijun Wang <wangaijun@tsinghua.org.cn>; Peter Psenak = (ppsenak) <ppsenak@cisco.com>; 'Aijun Wang' <wangaj3@chinatelecom.cn>
Cc: lsr@ietf.org
Subject: Re: [Lsr] FW: New Version = Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

Hi Aijun,

Other than your ill-conceived topology discovery = heuristic

[WAJ] The topology discovery heuristic is not suitable for = the corner use case when the unnumbered interface is used, as explained = in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-= originator-06#appendix-B.  If you don=E2=80=99t = agree, would you like to illustrate other non-applicable = scenarios?

 

Right =E2=80=93 and nobody other than yourself believes the = IGPs should be modified to expose the abstracted topology of an area = outside that area.

[WAJ]  The modification = doesn=E2=80=99t change the way and complexity of route calculation = within IGP. It just piggyback some extra information, the bulk of the = reconstruction work is done by the controller.  Such extra = information can also have other usage, as described in https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-= originator-06#section-1

And, the proposal described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-pa= ssive-interface-attribute-04 is different with the problem you = concerned.  It has no relation with the abstracted topology of an = area.  Maybe you are confused by these two = drafts?

 

It is a similar problem. You are still trying to overload = the prefix advertisements with a link attribute (passive interface) so = that it can be conveyed outside the domain. We certainly = wouldn=E2=80=99t waste a limited prefix flag on this parochial = application.

 

 

You can solve the problem with BGP-LS session(s) between = the router with a BGP-LS session to the controller and a router in each = area w/o  a router with a BGP-LS session to the = controller.

[WAJ] This is possible, but not = efficient. For operation, we must also consider the = configuration/administration overhead.  BGP-LS is designed mainly = for the northbound protocol, not east-west protocol.

 

what other possible reason would there be for associating = the passive attribute with a prefix?

[WAJ] To know the boundary of the IGP = domain. After knowing the boundary, the controller can safely apply and = check the network security policy, the inbound traffic control policy = etc.

 

It really isn=E2=80=99t relevant, but I have to = ask=E2=80=A6. How does the presence of a prefix associated with a = passive interface allow you to make this = deduction?

[WAJ] Passive interfaces are = deployed mainly at the boundary of IGP domain.  Is there any other = exception?

While passive interfaces are not standardized, there is = nothing that limits their usage to an IGP boundary. They can and are = deployed on any interface where adjacencies are not to be formed (e.g., = a stub subnet containing hosts).

 

Thanks,
Acee

<= p class=3Dm-8835168125062450739msoplaintext = style=3D'margin-left:114.0pt;mso-para-margin-left:9.5gd'> 

Thanks,

Acee

 

Thanks,

Acee

 

On 9/29/20, 10:39 PM, "Aijun Wang" <wangaijun@tsinghua.org.cn= > wrote:

 

    Hi, Acee and = Peter:

    Passive interface is mainly used at the = edge of the network, where the unnumbered interface will not be = used.

    And the information to flag the = passive interfaces is for positioning the area boundary, not conflict = with the abstract capabilities of the area = inside.

 

 

    Best Regards

 

    Aijun Wang

    China Telecom

 

    -----Original = Message-----

    From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.o= rg] On Behalf Of Acee Lindem (acee)

    Sent: Tuesday, September 29, 2020 9:16 = PM

    To: Peter Psenak <ppsenak=3D40cisco.com@dma= rc.ietf.org>; Aijun Wang <wangaijun@tsinghua.org.cn= >; 'Aijun Wang' <wangaj3@chinatelecom.cn>

    Cc: lsr@ietf.org

    Subject: Re: [Lsr] FW: New Version = Notification for = draft-wang-lsr-passive-interface-attribute-04.txt

 

    Speaking as WG = member:

 

    Hi Aijun, Peter,

    I agree with Peter - one of the = main motivations for having areas is to abstract the topology within the = area. Now you're trying to supplant this  - one topological detail = at a time with ill-conceived IGP features.

    Thanks,

    Acee

 

    On 9/29/20, 5:15 AM, "Lsr on behalf = of Peter Psenak" <lsr-bounces@ietf.org on = behalf of ppsenak=3D40cisco.com@dmarc.ietf.org> = wrote:

 

        Hi = Aijun,

 

        On 29/09/2020 = 11:07, Aijun Wang wrote:

        > Hi, = Peter:

        = >

        > Thanks = for your comments.

        > 1. For = BGP-LS deployment, there normally only be one router that within = the

        > IGP domain = to report the topology information, this router should know = such

        > passive = links which exists mainly on other border routers via the = IGP

        > protocol. = This is main reason to extension the IGP protocol. > 2. For the = solution, normally, the link within the IGP connect = two

        ends, = but

        > passive = interface is special and not fall in this space. We have studied = the

        > current = TLVs that for link, and find no suitable container to append = this

        > = information. This is the reason that we select the TLVs that associated = with

        > = Prefix.

 

        if the link is = unnumbered, your solution does not work. As I said, = if

        you need a = knowledge about the link, you can not advertise it as a = prefix.

 

        = thanks,

        = Peter

 

 

        = >

        >>From= other POV, the OSPFv3 defines now the "Intra-Area-Prefix = LSA", which

        > isolate the = prefix information that associated with link into = this

        > container, = contains the stub link, local interface information etc. Put = such

        > attribute = along with the prefix is then acceptable?

        = >

        >

        > Best = Regards

        = >

        > Aijun = Wang

        > China = Telecom

        = >

        > = -----Original Message-----

        > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.o= rg] On Behalf Of Peter

        > = Psenak

        > Sent: = Tuesday, September 29, 2020 4:29 PM

        > To: Aijun = Wang <wangaj3@chinatelecom.cn>

        > Cc: lsr@ietf.org

        > Subject: = Re: [Lsr] FW: New Version Notification for

        > = draft-wang-lsr-passive-interface-attribute-04.txt

        = >

        > Hi = Aijun,

        = >

        > here's = my comments:

        = >

        > The = purpose of this draft is to advertise passive = links.

        = >

        > 1. I'm = not sure the problem needs to be solved by IGPs. I tend to = believe

        > = ietf-idr-bgpls-inter-as-topology-ext is = sufficient.

        = >

        > 2. the = solution that you proposed is wrong. You are trying to = derive

        > topological = data about the passive links from the prefix = advertisement.

        > This is = semantically incorrect and only works under very specific = condition.

        > If you need = to advertise a link, advertise it as a = "special"

        > link, not = as a "special" prefix.

        = >

        > = thanks,

        > = Peter

        = >

        > On = 29/09/2020 03:17, Aijun Wang wrote:

        >> Hi, = Peter:

        = >>

        >> Would = you like to review and give comments on the updates version of = this

        > = draft?

        >> We have = also added the protocol extension proposal for = OSPFv3.

        = >>

        >> The = update version of this draft can refer to

        >> https://datatracker.ietf.= org/doc/html/draft-wang-lsr-passive-interface

        >> = -attribute

        >> Thanks = in advance.

        = >>

        = >>

        >> Best = Regards

        = >>

        >> Aijun = Wang

        >> China = Telecom

        = >>

        >>> = -----Original Message-----

        >>> = From: internet-drafts@ietf.org<= /span> [mailto:internet-drafts@ie= tf.org]

        >>> = Sent: Monday, September 28, 2020 3:17 PM

        >>> To: = Zhibo Hu <huzhibo@huawei.com= >; Gyan Mishra

        >>> = <gyan.s.mishra@verizon.com= >; Aijun Wang <wangaj3@chinatelecom.cn>;

        >>> = Gyan S. Mishra <gyan.s.mishra@verizon.com= >

        >>> = Subject: New Version Notification for

        >>> = draft-wang-lsr-passive-interface-attribute-04.txt

        = >>>

        = >>>

        >>> A = new version of I-D,

        >>> = draft-wang-lsr-passive-interface-attribute-04.txt

        >>> has = been successfully submitted by Aijun Wang and posted to the = IETF

        >>> = repository.

        = >>>

        >>> = Name:           &n= bsp;   = draft-wang-lsr-passive-interface-attribute

        >>> = Revision:   04

        >>> = Title:         Passive Interface = Attribute

        >>> = Document date:       = 2020-09-28

        >>> = Group:           &= nbsp;   Individual Submission

        >>> = Pages:           &= nbsp;   7

        >>> = URL:

        >>> https://www.ietf.org/id/d= raft-wang-lsr-passive-interface-attribute-04.

        >>> = txt

        >>> = Status:

        >>> https://datatracker.ietf.= org/doc/draft-wang-lsr-passive-interface-att=

        >>> = r

        >>> = ibute/

        >>> = Htmlized:

        >>> https://datatracker.ietf.= org/doc/html/draft-wang-lsr-passive-interfac=

        >>> = e

        >>> = -attribut

        >>> = e

        >>> = Htmlized:

        >>> https://tools.ietf.org/ht= ml/draft-wang-lsr-passive-interface-attribut=

        >>> = e

        >>> = -04

        >>> = Diff:

        >>> https://www.ietf.org/rfcd= iff?url2=3Ddraft-wang-lsr-passive-interface-at

        >>> = t

        >>> = ribute-04

        = >>>

        >>> = Abstract:

        = >>>      This document describes the = mechanism that can be used to

        = >>>      differentiate the passive = interfaces from the normal interfaces

        = >>>      within ISIS or OSPF = domain.

        = >>>

        = >>>

        = >>>

        = >>>

        >>> = 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.

        = >>>

        >>> The = IETF Secretariat

        = >>>

        = >>

        = >>

        = >>

        = >>

        = >

        > = _______________________________________________

        > Lsr mailing = list

        > Lsr@ietf.org

        > https://www.ietf.org/mail= man/listinfo/lsr

        = >

        >

        >

 

        = _______________________________________________

        Lsr mailing = list

        Lsr@ietf.org

        https://www.ietf.org/mail= man/listinfo/lsr

 

    = _______________________________________________

    Lsr mailing list

    Lsr@ietf.org

    https://www.ietf.org/mail= man/listinfo/lsr

 

 

_______________________________________________

Lsr mailing list

Lsr@ietf.org

https://www.ietf.org/mail= man/listinfo/lsr

_______________________________________________
Lsr = mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

--

<= div>

<>

Gyan = Mishra

Network = Solutions Architect 

M 301 = 502-1347
13101 Columbia Pike 
Silver Spring, MD

 

_______________________________________________
Lsr = mailing list
Lsr@ietf.org
https://www.ietf.org/m= ailman/listinfo/lsr

------=_NextPart_000_009C_01D6A14B.0F126050-- From nobody Mon Oct 12 19:33:50 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78D3A0858 for ; Mon, 12 Oct 2020 19:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 25Fku6P_P_Xn for ; Mon, 12 Oct 2020 19:33:45 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id 822C73A0DCC for ; Mon, 12 Oct 2020 19:33:44 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.92:64708.507102867 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.75?logid-d7765e5ab6ee42caafb07943e8a02c69 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 975EE2800DC; Tue, 13 Oct 2020 10:33:36 +0800 (CST) X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn Received: from ([172.18.0.92]) by App0021 with ESMTP id d7765e5ab6ee42caafb07943e8a02c69 for acee=40cisco.com@dmarc.ietf.org; Tue Oct 13 10:33:40 2020 X-Transaction-ID: d7765e5ab6ee42caafb07943e8a02c69 X-filter-score: filter<0> X-Real-From: wangaj3@chinatelecom.cn X-Receive-IP: 172.18.0.92 X-MEDUSA-Status: 0 Sender: wangaj3@chinatelecom.cn From: "Aijun Wang" To: , "'Gyan Mishra'" Cc: "'Acee Lindem \(acee\)'" , , "'Aijun Wang'" , "'Peter Psenak \(ppsenak\)'" References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> In-Reply-To: Date: Tue, 13 Oct 2020 10:33:33 +0800 Message-ID: <00a701d6a109$423b2bc0$c6b18340$@chinatelecom.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIJ+mWorx9ReexromEfqpSgpX3kFwEFLd5+AaLg+ScCZ8Mz1AFBnbZFAnYY+uECbteHkQJR6V6DAmQjRUkCKRShvAHJrWG+AiX9uxEBjzJAq6hxeYmA Content-Language: zh-cn Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 02:33:48 -0000 Hi, Dhruv: Please see my explain to Jeff. = https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/ The solutions described in RFC 5316 and RFC 5392 are possible and = straightforward, but they have some constraints, especially for the = operation/configuration of the network. Best Regards Aijun Wang China Telecom -----Original Message----- From: dhruv.ietf@gmail.com [mailto:dhruv.ietf@gmail.com]=20 Sent: Monday, October 12, 2020 3:25 PM To: Gyan Mishra Cc: Acee Lindem (acee) ; = lsr@ietf.org; Aijun Wang ; Aijun Wang = ; Peter Psenak (ppsenak) Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt Hi Gyan, As far as PCE is concerned, we have the inter-AS link information via = RFC 5316 and RFC 5392. Both of these include a section on PCE's BRPC = procedure for instance. I see you have other use cases, but it would be good to highlight why = for the PCE use case the above is deficient. Thanks! Dhruv On Mon, Oct 12, 2020 at 12:49 AM Gyan Mishra = wrote: > > > Hi Acee > > I believe what Aijun is trying to explain is that the primary purpose = of PCE for active or passive path computation is for inter-as RSVP-TE = PCALC path computation or SR-TE path computation. So PCE is solving a = well known PCALC bin packing problem due to pcalc over subscribing RSVP = tunnel bandwidth which is inherent an RSVP issue, but a bigger = problematic issue is with being able to build an inter-as TE path with a = single or multiple PCE controllers that can take the LSDB link = attributes in the TEDs dB opaque LSAs in the ospf case and ISIS TE TLVs = and rebuild the topology topology from each TE domain to be able to = build a congruent end to end RSVP TE or SR-TE traffic steered path = instantiation. > > Without the use of PCE controllers as the LSDB link attribute = information is not known as RSVP loose ERO static lsp is built or SR = SR-TE prefix sid loose path is built, failover due to crank back is = impacted for reroute, due to not having a complete depiction of the = other AS Link state topology by the head end or SR source node. > > So to build that entire end to end inter-as path for that end to end = RSVP TE or SR-TE path instantiation it is critical to indentify the = inter-as link eBGP tie link that may have static routes or BGP LU for = RSVP head end to tail end reachability and SR-TE reachability to build = out the end to end path instantiation. So the BGP-LS task to rebuild = the lsdb topology of each inter connected AS that the RSVP TE or SR-TE = steered path traverses, we need the accurate depiction and that includes = the Identification of the critical inter-as tie link eBGP peering link = that is passive for the PCE path computation logic for the end to end = inter-as path instantiation. > > As for other interfaces using passive in the context of a operator = service provider or enterprise core P and PE routers all links are = transit with neighbors except the inter-as tie so having this new IGP = TLV will help to that end. In the operator =E2=80=9Ccore=E2=80=9D = network if there are other interfaces that don=E2=80=99t need to be = advertised as stub, they can easily be excluded from being added into = IGP. > > Kind Regards > > Gyan > > On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) = wrote: >> >> Hi Aijun, >> >> >> >> From: Aijun Wang >> Date: Friday, October 9, 2020 at 9:58 PM >> To: Acee Lindem , "Peter Psenak (ppsenak)"=20 >> , 'Aijun Wang' >> Cc: "lsr@ietf.org" >> Subject: RE: [Lsr] FW: New Version Notification for=20 >> draft-wang-lsr-passive-interface-attribute-04.txt >> >> >> >> Hi, Acee: >> >> >> >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = >> Acee Lindem (acee) >> Sent: Saturday, October 10, 2020 3:48 AM >> To: Aijun Wang ; Peter Psenak (ppsenak)=20 >> ; 'Aijun Wang' >> Cc: lsr@ietf.org >> Subject: Re: [Lsr] FW: New Version Notification for=20 >> draft-wang-lsr-passive-interface-attribute-04.txt >> >> >> >> Speaking as WG member: >> >> >> >> Hi Aijun, >> >> >> >> From: Aijun Wang >> Date: Thursday, October 8, 2020 at 11:09 PM >> To: Acee Lindem , "Peter Psenak (ppsenak)"=20 >> , 'Aijun Wang' >> Cc: "lsr@ietf.org" >> Subject: RE: [Lsr] FW: New Version Notification for=20 >> draft-wang-lsr-passive-interface-attribute-04.txt >> >> >> >> Hi, Acee: >> >> Sorry for the previous pruned mail. Let's reply you again along your = original question. >> >> Please see inline.[WAJ] >> >> >> >> -----Original Message----- >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = >> Acee Lindem (acee) >> Sent: Wednesday, September 30, 2020 7:47 PM >> To: Aijun Wang ; Peter Psenak (ppsenak)=20 >> ; 'Aijun Wang' >> Cc: lsr@ietf.org >> Subject: Re: [Lsr] FW: New Version Notification for=20 >> draft-wang-lsr-passive-interface-attribute-04.txt >> >> >> >> Hi Aijun, >> >> Other than your ill-conceived topology discovery heuristic >> >> [WAJ] The topology discovery heuristic is not suitable for the corner = use case when the unnumbered interface is used, as explained in = https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appe= ndix-B. If you don=E2=80=99t agree, would you like to illustrate other = non-applicable scenarios? >> >> >> >> Right =E2=80=93 and nobody other than yourself believes the IGPs = should be modified to expose the abstracted topology of an area outside = that area. >> >> [WAJ] The modification doesn=E2=80=99t change the way and complexity = of=20 >> route calculation within IGP. It just piggyback some extra=20 >> information, the bulk of the reconstruction work is done by the=20 >> controller. Such extra information can also have other usage, as=20 >> described in=20 >> https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06# >> section-1 >> >> And, the proposal described in = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-at= tribute-04 is different with the problem you concerned. It has no = relation with the abstracted topology of an area. Maybe you are = confused by these two drafts? >> >> >> >> It is a similar problem. You are still trying to overload the prefix = advertisements with a link attribute (passive interface) so that it can = be conveyed outside the domain. We certainly wouldn=E2=80=99t waste a = limited prefix flag on this parochial application. >> >> >> >> >> >> You can solve the problem with BGP-LS session(s) between the router = with a BGP-LS session to the controller and a router in each area w/o a = router with a BGP-LS session to the controller. >> >> [WAJ] This is possible, but not efficient. For operation, we must = also consider the configuration/administration overhead. BGP-LS is = designed mainly for the northbound protocol, not east-west protocol. >> >> >> >> what other possible reason would there be for associating the passive = attribute with a prefix? >> >> [WAJ] To know the boundary of the IGP domain. After knowing the = boundary, the controller can safely apply and check the network security = policy, the inbound traffic control policy etc. >> >> >> >> It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How = does the presence of a prefix associated with a passive interface allow = you to make this deduction? >> >> [WAJ] Passive interfaces are deployed mainly at the boundary of IGP = domain. Is there any other exception? >> >> While passive interfaces are not standardized, there is nothing that = limits their usage to an IGP boundary. They can and are deployed on any = interface where adjacencies are not to be formed (e.g., a stub subnet = containing hosts). >> >> >> >> Thanks, >> Acee >> >> >> >> Thanks, >> >> Acee >> >> >> >> Thanks, >> >> Acee >> >> >> >> On 9/29/20, 10:39 PM, "Aijun Wang" wrote: >> >> >> >> Hi, Acee and Peter: >> >> Passive interface is mainly used at the edge of the network, = where the unnumbered interface will not be used. >> >> And the information to flag the passive interfaces is for = positioning the area boundary, not conflict with the abstract = capabilities of the area inside. >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> -----Original Message----- >> >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On=20 >> Behalf Of Acee Lindem (acee) >> >> Sent: Tuesday, September 29, 2020 9:16 PM >> >> To: Peter Psenak ; Aijun = Wang=20 >> ; 'Aijun Wang' >> >> Cc: lsr@ietf.org >> >> Subject: Re: [Lsr] FW: New Version Notification for=20 >> draft-wang-lsr-passive-interface-attribute-04.txt >> >> >> >> Speaking as WG member: >> >> >> >> Hi Aijun, Peter, >> >> I agree with Peter - one of the main motivations for having areas = is to abstract the topology within the area. Now you're trying to = supplant this - one topological detail at a time with ill-conceived IGP = features. >> >> Thanks, >> >> Acee >> >> >> >> On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" = = wrote: >> >> >> >> Hi Aijun, >> >> >> >> On 29/09/2020 11:07, Aijun Wang wrote: >> >> > Hi, Peter: >> >> > >> >> > Thanks for your comments. >> >> > 1. For BGP-LS deployment, there normally only be one router = >> that within the >> >> > IGP domain to report the topology information, this router=20 >> should know such >> >> > passive links which exists mainly on other border routers=20 >> via the IGP >> >> > protocol. This is main reason to extension the IGP=20 >> protocol. > 2. For the solution, normally, the link within the IGP=20 >> connect two >> >> ends, but >> >> > passive interface is special and not fall in this space. We = >> have studied the >> >> > current TLVs that for link, and find no suitable container=20 >> to append this >> >> > information. This is the reason that we select the TLVs=20 >> that associated with >> >> > Prefix. >> >> >> >> if the link is unnumbered, your solution does not work. As I=20 >> said, if >> >> you need a knowledge about the link, you can not advertise it = as a prefix. >> >> >> >> thanks, >> >> Peter >> >> >> >> >> >> > >> >> >>From other POV, the OSPFv3 defines now the=20 >> "Intra-Area-Prefix LSA", which >> >> > isolate the prefix information that associated with link=20 >> into this >> >> > container, contains the stub link, local interface=20 >> information etc. Put such >> >> > attribute along with the prefix is then acceptable? >> >> > >> >> > >> >> > Best Regards >> >> > >> >> > Aijun Wang >> >> > China Telecom >> >> > >> >> > -----Original Message----- >> >> > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On = >> Behalf Of Peter >> >> > Psenak >> >> > Sent: Tuesday, September 29, 2020 4:29 PM >> >> > To: Aijun Wang >> >> > Cc: lsr@ietf.org >> >> > Subject: Re: [Lsr] FW: New Version Notification for >> >> > draft-wang-lsr-passive-interface-attribute-04.txt >> >> > >> >> > Hi Aijun, >> >> > >> >> > here's my comments: >> >> > >> >> > The purpose of this draft is to advertise passive links. >> >> > >> >> > 1. I'm not sure the problem needs to be solved by IGPs. I=20 >> tend to believe >> >> > ietf-idr-bgpls-inter-as-topology-ext is sufficient. >> >> > >> >> > 2. the solution that you proposed is wrong. You are trying=20 >> to derive >> >> > topological data about the passive links from the prefix = advertisement. >> >> > This is semantically incorrect and only works under very = specific condition. >> >> > If you need to advertise a link, advertise it as a = "special" >> >> > link, not as a "special" prefix. >> >> > >> >> > thanks, >> >> > Peter >> >> > >> >> > On 29/09/2020 03:17, Aijun Wang wrote: >> >> >> Hi, Peter: >> >> >> >> >> >> Would you like to review and give comments on the updates=20 >> version of this >> >> > draft? >> >> >> We have also added the protocol extension proposal for = OSPFv3. >> >> >> >> >> >> The update version of this draft can refer to >> >> >>=20 >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac >> e >> >> >> -attribute >> >> >> Thanks in advance. >> >> >> >> >> >> >> >> >> Best Regards >> >> >> >> >> >> Aijun Wang >> >> >> China Telecom >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: internet-drafts@ietf.org=20 >> [mailto:internet-drafts@ietf.org] >> >> >>> Sent: Monday, September 28, 2020 3:17 PM >> >> >>> To: Zhibo Hu ; Gyan Mishra >> >> >>> ; Aijun Wang=20 >> ; >> >> >>> Gyan S. Mishra >> >> >>> Subject: New Version Notification for >> >> >>> draft-wang-lsr-passive-interface-attribute-04.txt >> >> >>> >> >> >>> >> >> >>> A new version of I-D, >> >> >>> draft-wang-lsr-passive-interface-attribute-04.txt >> >> >>> has been successfully submitted by Aijun Wang and posted=20 >> to the IETF >> >> >>> repository. >> >> >>> >> >> >>> Name: = draft-wang-lsr-passive-interface-attribute >> >> >>> Revision: 04 >> >> >>> Title: Passive Interface Attribute >> >> >>> Document date: 2020-09-28 >> >> >>> Group: Individual Submission >> >> >>> Pages: 7 >> >> >>> URL: >> >> >>> = https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04. >> >> >>> txt >> >> >>> Status: >> >> >>>=20 >> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att >> >> >>> r >> >> >>> ibute/ >> >> >>> Htmlized: >> >> >>>=20 >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac >> >> >>> e >> >> >>> -attribut >> >> >>> e >> >> >>> Htmlized: >> >> >>>=20 >> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut >> >> >>> e >> >> >>> -04 >> >> >>> Diff: >> >> >>>=20 >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-interface-at >> >> >>> t >> >> >>> ribute-04 >> >> >>> >> >> >>> Abstract: >> >> >>> This document describes the mechanism that can be = used to >> >> >>> differentiate the passive interfaces from the normal = interfaces >> >> >>> within ISIS or OSPF domain. >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> Please note that it may take a couple of minutes from the = >> time of >> >> >>> submission until the htmlized version and diff are=20 >> available at >> >> > tools.ietf.org. >> >> >>> >> >> >>> The IETF Secretariat >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > _______________________________________________ >> >> > Lsr mailing list >> >> > Lsr@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/lsr >> >> > >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> Lsr mailing list >> >> Lsr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> >> _______________________________________________ >> >> Lsr mailing list >> >> Lsr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> >> >> >> _______________________________________________ >> >> Lsr mailing list >> >> Lsr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > -- > > > Gyan Mishra > > Network Solutions Architect > > M 301 502-1347 > 13101 Columbia Pike > Silver Spring, MD > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Mon Oct 12 20:38:46 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571BB3A08C7 for ; Mon, 12 Oct 2020 20:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 p2Po9TZEEKmJ for ; Mon, 12 Oct 2020 20:38:42 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 0F36B3A0880 for ; Mon, 12 Oct 2020 20:38:42 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id r17so1526677uaf.2 for ; Mon, 12 Oct 2020 20:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5GZ+NkLOnB/xFnXSPqWj6ynPGmIIpdOm/deE/RPe7+0=; b=Otx6sjVJA+L2ywfkrAwwLIp7u71b5NJI4F8gg/oMEBiSGw51RzhERBb2Hr9ZwGJVve gB45xqmUFp789wEGmb+rDHbTErlSZ3ridOSYiqIiHXbdtowBwdqlDGTlXGmf/EyobWQl PW+0Dbum0n49BCGIwkvLQ7Jke3VTeCvjJKQo1vW0AxvcXUJBDjvaT5pjkYSQ+XoxEVVh KSxed6Vx+CDodHdmUOyX9JGJQ0RacSPIzdbP23WCOaXPKky+UvdkeGYFjkIqmU/Cbiah BTSuNWWATxOKwTeT2sni6S02Hbj5ovez8pSykRtlRoOD7nTXC96OrxoFQQfAs1zvd4HV 3BPA== 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=5GZ+NkLOnB/xFnXSPqWj6ynPGmIIpdOm/deE/RPe7+0=; b=P+ATPH0cCGctl8UpO2qvghgKlw16UE+TdcVczAIlNqOBByLcVxgeD5R1QVyZUtBVvs YnITxU5tjhaaW7MZGiz550YB9Kiv+e+jVPDyNUvqoYo5mLZ3rDlqeAvsok1yy06VwUQs wjubQvVt9LcCilJC4et/79AMTecrZMd6ktRg5aIVGnNfj+FUgJJgTQoStHDwmLqFz38k zLwFx1NBddv8FBvw557vrwYJiQjxhNoFhl4yFHnHal66+PNtDT+3bZSt47xL1618rrUZ rqYNZGtvxqV8Pte0KU5yx+F8ih7W1eaimlpnlPsaM0QAUHP8rU/APAzPMi4uOpen1hPk S9Dw== X-Gm-Message-State: AOAM531f9vOCgKAwhfVDbQ0J+G6Xf8i6lmEAvqEeVzQzUAAbtjikHtiu iAP02PcxDV6igs1ISLeK+2hykYd0TknxzR8NYeE= X-Google-Smtp-Source: ABdhPJx7LwOzhzOatbRTsgeuaKAJBjdTzm1gb7ESjJgej+Xr6zUFZpvmZ7RC+P/oWh5Gq+4qSOnlK0KrYj99YklGgdo= X-Received: by 2002:ab0:608c:: with SMTP id i12mr15079184ual.106.1602560320820; Mon, 12 Oct 2020 20:38:40 -0700 (PDT) MIME-Version: 1.0 References: <9c1fa875-fdce-40a4-a41d-a025c102eac7@Spark> In-Reply-To: <9c1fa875-fdce-40a4-a41d-a025c102eac7@Spark> From: Gyan Mishra Date: Mon, 12 Oct 2020 23:38:29 -0400 Message-ID: To: Jeff Tantsura Cc: "Dongjie (Jimmy)" , Peter Psenak , Ron Bonica , Yingzhen Qu , lsr@ietf.org Content-Type: multipart/alternative; boundary="000000000000a75a4b05b185263e" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 03:38:45 -0000 --000000000000a75a4b05b185263e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeff Thanks for the detailed analysis and explanation comparison of SR & IP Flex Algo. Please see in-line Me like Flex Algo covered in Chocolate. =F0=9F=98=82 On Sun, Oct 11, 2020 at 5:06 PM Jeff Tantsura wrote: > Gyan, > > In simple terms - destination lookup would yield a SID (stack) for SR or > next-hop/adj for IP. For SR, no transport device in between should try to > derive/evaluate context (source based routing - once you are in the > tunnel), in IP case - every device will evaluate (per hop routing) the > destination. As long as the destination lookup result is unambiguous, any > combination of algo's could be used. > Gyan> So with SR-MPLS as long as there is a SR-TE binding sid policy and you are in the tunnel the middle transport routers will evaluate flex algo context, Unless flex algo is called out on a candidate path. IP based can really fully take advantage hop by hop as compared to SR-MPLS. > > > In SR easy days we (large radio vendor :)) were considering using a set o= f > loopbacks per virtual topology as a poor-man=E2=80=99s slicing in MBH, wh= ere PCE > would perform =E2=80=9Cslicing=E2=80=9D and FEC2tunnel mapping over flat = routing domain, > perceived too complex ended up with some other ways of mapping. > Flex algo provides an easier (because distributed + additional meta-data, > algo =3D context) way of light virtualization as compared to MT and/or fu= lly > centralized solutions. > Gyan> I think the poor mans slicing pre advent of SR paradigm was complex with the FEC2Tunnel mapping =E2=80=9CPer VRF TE=E2=80=9Dcoloring wh= ich required a discrete FEC loopback for next hop rewrite with static route with tunnel next hop crude rudimentary way of transport slicing. Good point that the issues with the complexity and painful FEC to tunnel mapping lead to development of both SR stateless intent based FEC to tunnel coloring along with as you mentioned how gap was as well filled with Flex Algo. I really like the light weight simple aspects of flex algo, however has the requirement of SR data plane until Ron=E2=80=99s much needed draft came out= . Did MT ever really take off in providing a means of network slicing? Kind Regards Gyan > > > Wrt SRv6 vs IPv6 (algo is irrelevant here), I=E2=80=99d assume there=E2= =80=99s no > conflict, however would leave to the implementors to comment. > > Cheers, > Jeff > > P.S. Acee - nothing gets me more excited than algo 201 with chocolate ove= r > it ;-) > On Oct 11, 2020, 11:21 AM -0700, Gyan Mishra , > wrote: > > > Jeff > > So basically as SR Flex Algo uses SR data plane (SID ,context) uniqueness > for SR-MPLS label uniqueness and SRv6 Locator uniqueness as compare to IP > Flex Algo IP Data plane is destination prefix based. > > So you could literally have both IP flex algo and SR flex also data plane > as mutually exclusive data plane work in parallel as two ships in the > night. > > SRv6 uses Longest prefix match and in SRv6-BE w/o SRH which would be > destination based IP and SRv6-BE in parallel to IP Flex algo would not wo= rk > as they would collide on the IPv6 data plane. > > Kind Regards > > Gyan > > On Sun, Oct 11, 2020 at 1:38 PM Jeff Tantsura > wrote: > >> Thanks Ron, indeed! Autocorrect works in mysterious ways ;-) >> >> Regards, >> Jeff >> >> > On Oct 11, 2020, at 09:41, Ron Bonica wrote: >> > >> > =EF=BB=BFJeff, >> > >> > I think that you mean the scope is different..... >> > >> > Ron >> > >> > >> > >> > Juniper Business Use Only >> > >> > -----Original Message----- >> > From: Jeff Tantsura >> > Sent: Saturday, October 10, 2020 3:14 PM >> > To: Ron Bonica >> > Cc: Dongjie (Jimmy) ; Peter Psenak < >> ppsenak@cisco.com>; Yingzhen Qu ; Gyan Mishra >> ; lsr@ietf.org >> > Subject: Re: [Lsr] FW: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> > >> > [External Email. Be cautious of content] >> > >> > >> > Jie, >> > >> > The scoop is different, for SR data plane entry uniqueness is in >> context of SR domain (SID =3D value + context), while for IP it is globa= l to >> the routing domain, FIB entry is a destination, nothing more. >> > >> > Regards, >> > Jeff >> > >> >> On Oct 10, 2020, at 05:47, Ron Bonica wrote: >> >> >> >> =EF=BB=BFHi Jimmie, >> >> >> >> Inline..... >> >> >> >> Ron >> >> >> >> >> >> Juniper Business Use Only >> >> >> >> -----Original Message----- >> >> From: Dongjie (Jimmy) >> >> Sent: Friday, October 9, 2020 11:06 PM >> >> To: Peter Psenak ; Ron Bonica >> >> ; Yingzhen Qu ; Gyan >> >> Mishra >> >> Cc: lsr@ietf.org; Jeff Tantsura >> >> Subject: RE: [Lsr] FW: New Version Notification for >> >> draft-bonica-lsr-ip-flexalgo-00.txt >> >> >> >> [External Email. Be cautious of content] >> >> >> >> >> >> Hi Peter, >> >> >> >> Thanks for your reply. It aligns with my understanding of FAD, which >> is just a set of constraints for path computation. Thus one Flex-Algo ID >> could be used with multiple different data planes. Is this understanding >> correct? >> >> >> >> [RB] I never thought about this. Is there a use-case? I think that it >> will work, but I would have to try it before saying for sure. >> >> >> >> If so, my question is about the scenario below: >> >> >> >> A group of nodes in a network support FA-128, a sub-group of them bin= d >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. >> When one node compute an SR path to a destination, can it compute the pa= th >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes >> which bind FA-128 to IP address? >> >> >> >> [RB] I don't think so. However, you could achieve the same outcome >> using link colors. >> >> >> >> If so, how could this node know the binding of FA to different data >> planes on other nodes? >> >> >> >> Best regards, >> >> Jie >> >> >> >>> -----Original Message----- >> >>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak >> >>> Sent: Friday, October 9, 2020 11:58 PM >> >>> To: Dongjie (Jimmy) ; Ron Bonica >> >>> ; Yingzhen Qu >> >>> ; Gyan Mishra >> >>> Cc: lsr@ietf.org; Jeff Tantsura >> >>> Subject: Re: [Lsr] FW: New Version Notification for >> >>> draft-bonica-lsr-ip-flexalgo-00.txt >> >>> >> >>> Hi Jimmy, >> >>> >> >>> >> >>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: >> >>>>> Hi Ron, >> >>>>> >> >>>>> Thanks for explaining the difference between IP Flex-Algo and SR >> >>>>> Flex-algo. As >> >>> you said, the major difference is the data plane. >> >>>> >> >>>> If my understanding is correct, for one Flex-Algo to be used >> >>>> correctly, the set >> >>> of nodes need to apply consistent constraints in computation, and >> >>> bind the FAD to the same data plane. >> >>>> >> >>>> Is it possible that different nodes may use the same Flex-Algo with >> >>>> different >> >>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with >> >>> pure IP etc., or each Flex-Algo is always associated with only one >> >>> data plane? In the former case, should the flex-algo definition also >> >>> indicate the data plane(s) to be used with the flex-algo? >> >>> >> >>> let me respond to this query, as this is not specific to Ron's draft= . >> >>> >> >>> FAD is data plane agnostic and is used by all of them. >> >>> >> >>> thanks, >> >>> Peter >> >>> >> >>>> >> >>>> Best regards, >> >>>> Jie >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >> >>>>> Sent: Sunday, October 4, 2020 4:34 AM >> >>>>> To: Yingzhen Qu ; Peter Psenak >> >>>>> ; Gyan Mishra >> >>>>> Cc: lsr@ietf.org; Jeff Tantsura >> >>>>> Subject: Re: [Lsr] FW: New Version Notification for >> >>>>> draft-bonica-lsr-ip-flexalgo-00.txt >> >>>>> >> >>>>> Hi Yingzhen, >> >>>>> >> >>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the >> >>>>> following >> >>> respects: >> >>>>> >> >>>>> - Links have IGP metrics, TE metrics, delay metrics and >> >>>>> administrative colors >> >>>>> - FADs define Flexible Algorithms >> >>>>> >> >>>>> More specifically, the FAD: >> >>>>> >> >>>>> - Indicates which metric type the Flexible Algorithm uses >> >>>>> - Specifies constraints in terms of link colors that are included >> >>>>> or excluded from the Flexible Algorithm. >> >>>>> >> >>>>> The significant difference between IP Flexible Algorithms and SR >> >>>>> Flexible Algorithms is: >> >>>>> >> >>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators >> >>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. >> >>>>> >> >>>>> So, IP Flexible Algorithms can be deployed in any IP network, even >> >>>>> in the absence of SR. >> >>>>> >> >>>>> Ron >> >>>>> >> >>>>> >> >>>>> Juniper Business Use Only >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Yingzhen Qu >> >>>>> Sent: Saturday, October 3, 2020 2:08 PM >> >>>>> To: Peter Psenak ; Gyan Mishra >> >>>>> ; Ron Bonica >> >>>>> Cc: lsr@ietf.org; Jeff Tantsura >> >>>>> Subject: Re: [Lsr] FW: New Version Notification for >> >>>>> draft-bonica-lsr-ip-flexalgo-00.txt >> >>>>> >> >>>>> [External Email. Be cautious of content] >> >>>>> >> >>>>> >> >>>>> Hi Peter, >> >>>>> >> >>>>> Using flex-algo, a SRv6 locator can be associated with a single >> >>>>> algo, which means an IPv6 or IPv4 address can also be associated >> >>>>> with a single algo. So my understanding is Ron's proposal is makin= g >> >>>>> the >> >>> configuration of flex-algo easier? >> >>>>> Instead of using the exclude or include list you can configure a >> >>>>> loopback address to a flex-algo directly? >> >>>>> >> >>>>> Thanks, >> >>>>> Yingzhen >> >>>>> >> >>>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: >> >>>>> >> >>>>> Hi Yingzhen, >> >>>>> >> >>>>> On 02/10/2020 22:15, Yingzhen Qu wrote: >> >>>>>> Hi Peter, >> >>>>>> >> >>>>>> My understanding of flex-algo is that for traffic destined >> >>>>> to a prefix on a particular algo, it can only be routed on routers >> >>>>> belong to that algo, which also means only routers in that algo >> >>>>> calculates how to reach that prefix and install it into the routin= g >> >>>>> table. It seems to me that using flex-algo (section 12 of the >> >>>>> draft) it's possible to have a loopback address associated with >> >>>>> only one algo, please correct me if I'm missing or misunderstood >> something. >> >>>>> >> >>>>> you are right. That is exactly what is being done for flex-algo >> with >> >>>>> SRv6 - locator is associated with a single algo only. The >> proposal uses >> >>>>> the same concept. >> >>>>> >> >>>>> thanks, >> >>>>> Peter >> >>>>> >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Yingzhen >> >>>>>> >> >>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >> >>>>> > >>>>> ppsenak=3D40cisco.com@dmarc.ietf.org> >> >>>>> wrote: >> >>>>>> >> >>>>>> Gyan, >> >>>>>> >> >>>>>> On 02/10/2020 18:30, Gyan Mishra wrote: >> >>>>>>> All, >> >>>>>>> >> >>>>>>> With SRv6 and IP based flex algo a generic question as it >> >>> applies >> >>>>> to >> >>>>>>> both. Is it possible to have within a single IGP domain >> >>> different >> >>>>> sets >> >>>>>>> of nodes or segments of the network running different >> >>>>> algorithms. >> >>>>>> >> >>>>>> absolutely. >> >>>>>> >> >>>>>>> From >> >>>>>>> both drafts it sounds like all nodes have to agree on same >> >>>>> algorithm >> >>>>>>> similar to concept of metric and reference bandwidth all >> >>> have to >> >>>>> have >> >>>>>>> the same style metric and play to the same sheet of music. >> >>>>>> >> >>>>>> all participating nodes need to agree on the definition of the >> >>>>> flex-algo >> >>>>>> and advertise the participation. That's it. >> >>>>>> >> >>>>>>> If there was >> >>>>>>> a way to use multiple algorithms simultaneously based on >> >>> SFC >> >>>>> or services >> >>>>>>> and instantiation of specific algorithm based on service to >> >>> be >> >>>>>>> rendered. Doing so without causing a routing loop or sub >> >>>>> optimal >> >>>>>>> routing. >> >>>>>> >> >>>>>> you can certainly use multiple algorithms simultaneously and >> >>> use >> >>>>> algo >> >>>>>> specific paths to forward specific traffic over it. How that >> >>>>>> is >> >>> done >> >>>>>> from the forwarding perspective depends in which >> >>> forwarding >> >>>>> plane you >> >>>>>> use. Flex-algo control plane is independent of the forwarding >> >>>>> plane. >> >>>>>> >> >>>>>> >> >>>>>>> I thought with flex algo that there exists a feature that on eac= h >> >>>>>>> hop there is a way to specify which algo to use hop by >> >>> hop >> >>>>> similar >> >>>>>>> to a hop by hop policy based routing. >> >>>>>> >> >>>>>> no, there is no hop-by-hop classification, that is problematic >> >>> and >> >>>>> does >> >>>>>> not scale for high speeds. Classification is done at the >> >>> ingress only. >> >>>>>> >> >>>>>> thanks, >> >>>>>> Peter >> >>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Lsr mailing list >> >>>>>> Lsr@ietf.org >> >>>>>> >> >>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.out= l >> >>>>> oo >> >>>>> k.com/ >> >>>>> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&d= ata >> >>>>> =3D >> >>> 0 >> >>>>> 2 >> >>>>> >> >>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 >> >>>>> >> >>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >> >>>>> >> >>> 5126&sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D >> >>>>> >> >>> &reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9Mjime= JcR >> >>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Lsr mailing list >> >>>>> Lsr@ietf.org >> >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/= l >> >>>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_= H >> >>>>> z218CE8S8XzlIxAA$ >> >>>> >> >>>> >> >>> >> >>> _______________________________________________ >> >>> Lsr mailing list >> >>> Lsr@ietf.org >> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls= r >> >>> _ >> >>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC_Hz218= C >> >>> E >> >>> 8S8XzlIxAA$ >> > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-1347 13101 Columbia Pike > *Silver > Spring, MD > > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000a75a4b05b185263e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Jeff=C2=A0

<= /div>
Thanks for the detailed analysis and explanation com= parison of SR & IP Flex Algo.

Please see in-line=C2=A0


Me like Flex Algo covered in Chocola= te. =F0=9F=98=82
On Sun, Oct 11, 2020 at 5:06 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
Gyan,

In simple terms - destination lookup would yield a SID (stack) for SR or ne= xt-hop/adj for IP. For SR, no transport device in between should try to der= ive/evaluate context (source based routing - once you are in the tunnel), i= n IP case - every device will evaluate (per hop routing) the destination. A= s long as the destination lookup result is unambiguous, any combination of = algo's could be used.
<= br>
=C2=A0 =C2=A0Gyan> So with SR-MPLS as long as= there is a=C2=A0
SR-TE binding sid policy and you a= re in the tunnel the middle transport routers will evaluate flex algo conte= xt, Unless flex algo is called out on a candidate path.=C2=A0 IP based can = really fully take advantage hop by hop as compared to SR-MPLS.


In SR easy days we (large radio vendor :)) were considering using a set of = loopbacks per virtual topology as a poor-man=E2=80=99s slicing in MBH, wher= e PCE would perform =E2=80=9Cslicing=E2=80=9D and FEC2tunnel mapping over f= lat routing domain, perceived too complex ended up with some other ways of = mapping.
Flex algo provides an easier (because distributed + additional meta-data, a= lgo =3D context) way of light virtualization as compared to MT and/or fully= centralized solutions.=C2=A0

=C2=A0 =C2=A0 Gyan> I think the poor mans= slicing pre advent of SR paradigm was complex with the FEC2Tunnel mapping = =E2=80=9CPer VRF TE=E2=80=9Dcoloring which required a discrete FEC loopback= for next hop rewrite with static route with tunnel next hop crude rudiment= ary way of transport slicing. =C2=A0

Good point that the issues with the complexity and painful FEC= to tunnel mapping lead to development of both SR stateless intent based FE= C to tunnel coloring along with as you mentioned how gap was as well filled= with Flex Algo. =C2=A0

= I really like the light weight simple aspects of flex algo, however has the= requirement of SR data plane until Ron=E2=80=99s much needed draft came ou= t.

Did MT ever really ta= ke off in providing a means of network slicing?

=

Kind Regards=C2=A0

Gyan


Wrt SRv6 vs IPv6 (algo is irrelevant here), I=E2=80=99d assume there=E2=80= =99s no conflict, however would leave to the implementors to comment.=C2=A0=

Cheers,
Jeff

P.S. Acee - nothing gets me more excited than algo 201 wi= th chocolate over it ;-)
On Oct 11, 2020, 11:21 AM -0700, Gyan Mis= hra <hayabusa= gsm@gmail.com>, wrote:

Jeff

So basically as SR Flex Algo uses SR data plane (SID ,con= text) uniqueness for SR-MPLS label uniqueness and SRv6 Locator uniqueness a= s compare to IP Flex Algo IP Data plane is destination prefix based. =C2=A0=

So you could literally have both IP flex algo and SR flex= also data plane as mutually exclusive data plane work in parallel as two s= hips in the night. =C2=A0

SRv6 uses Longest prefix match and in SRv6-BE w/o SRH whi= ch would be destination based IP and SRv6-BE in parallel to IP Flex algo wo= uld not work as they would collide on the IPv6 data plane.

Kind Regards=C2=A0

Gyan

On Sun, Oct 11, 2020 at 1:38 PM Jeff = Tantsura <j= efftant.ietf@gmail.com> wrote:
Thanks Ron, indeed!=C2=A0 Autocorrect works = in mysterious ways=C2=A0 ;-)

Regards,
Jeff

> On Oct 11, 2020, at 09:41, Ron Bonica <rbonica@juniper.net> wrote:
>
> =EF=BB=BFJeff,
>
> I think that you mean the scope is different.....
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Jeff Tantsura <jefftant.ietf@gmail.com>
> Sent: Saturday, October 10, 2020 3:14 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Peter Psenak <ppsenak@cisco.com>; Yingzhen Q= u <yingzh= en.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com>; lsr@ietf.org
> Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-i= p-flexalgo-00.txt
>
> [External Email. Be cautious of content]
>
>
> Jie,
>
> The scoop is different, for SR data plane entry uniqueness is in conte= xt of SR domain (SID =3D value + context), while for IP it is global to the= routing domain, FIB entry is a destination, nothing more.
>
> Regards,
> Jeff
>
>> On Oct 10, 2020, at 05:47, Ron Bonica <rbonica@juniper.net> wrote:
>>
>> =EF=BB=BFHi Jimmie,
>>
>> Inline.....
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Ron
>>
>>
>> Juniper Business Use Only
>>
>> -----Original Message-----
>> From: Dongjie (Jimmy) <jie.dong@huawei.com>
>> Sent: Friday, October 9, 2020 11:06 PM
>> To: Peter Psenak <ppsenak@cisco.com>; Ron Bonica
>> <rboni= ca@juniper.net>; Yingzhen Qu <yingzhen.qu@futurewei.com>; Gyan
>> Mishra <hayabusagsm@gmail.com>
>> Cc: lsr@ietf.org= ; Jeff Tantsura <jefftant.ietf@gmail.com>
>> Subject: RE: [Lsr] FW: New Version Notification for
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> Hi Peter,
>>
>> Thanks for your reply. It aligns with my understanding of FAD, whi= ch is just a set of constraints for path computation. Thus one Flex-Algo ID= could be used with multiple different data planes. Is this understanding c= orrect?
>>
>> [RB] I never thought about this. Is there a use-case? I think that= it will work, but I would have to try it before saying for sure.
>>
>> If so, my question is about the scenario below:
>>
>> A group of nodes in a network support FA-128, a sub-group of them = bind FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address= . When one node compute an SR path to a destination, can it compute the pat= h to only pass the nodes which bind FA-128 to SR SIDs, and avoid the nodes = which bind FA-128 to IP address?
>>
>> [RB] I don't think so. However, you could achieve the same out= come using link colors.
>>
>> If so, how could this node know the binding of FA to different dat= a planes on other nodes?
>>
>> Best regards,
>> Jie
>>
>>> -----Original Message-----
>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
>>> Sent: Friday, October 9, 2020 11:58 PM
>>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Ron Bonica
>>> <rbonica=3D40juniper.net@dmarc.ietf.org>; Yingzhen Qu
>>> <yingzhen.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com>
>>> Cc: lsr@ietf= .org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>> Subject: Re: [Lsr] FW: New Version Notification for
>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>
>>> Hi Jimmy,
>>>
>>>
>>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote:
>>>>> Hi Ron,
>>>>>
>>>>> Thanks for explaining the difference between IP Flex-A= lgo and SR
>>>>> Flex-algo. As
>>> you said, the major difference is the data plane.
>>>>
>>>> If my understanding is correct, for one Flex-Algo to be us= ed
>>>> correctly, the set
>>> of nodes need to apply consistent constraints in computation, = and
>>> bind the FAD to the same data plane.
>>>>
>>>> Is it possible that different nodes may use the same Flex-= Algo with
>>>> different
>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some w= ith
>>> pure IP etc., or each Flex-Algo is always associated with only= one
>>> data plane? In the former case, should the flex-algo definitio= n also
>>> indicate the data plane(s) to be used with the flex-algo?
>>>
>>> let me respond to this query, as this is not specific to Ron&#= 39;s draft.
>>>
>>> FAD is data plane agnostic and is used by all of them.
>>>
>>> thanks,
>>> Peter
>>>
>>>>
>>>> Best regards,
>>>> Jie
>>>>
>>>>> -----Original Message-----
>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica
>>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>>> To: Yingzhen Qu <yingzhen.qu@futurewei.com>; Peter Psena= k
>>>>> <ppsenak@cisco.com>; Gyan Mishra <hayabusagsm@gmail.com>
>>>>> Cc: = lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>
>>>>> Hi Yingzhen,
>>>>>
>>>>> IP Flexible Algorithms are like SR Flexible Algorithms= in the
>>>>> following
>>> respects:
>>>>>
>>>>> - Links have IGP metrics, TE metrics, delay metrics an= d
>>>>> administrative colors
>>>>> - FADs define Flexible Algorithms
>>>>>
>>>>> More specifically, the FAD:
>>>>>
>>>>> - Indicates which metric type the Flexible Algorithm u= ses
>>>>> - Specifies constraints in terms of link colors that a= re included
>>>>> or excluded from the Flexible Algorithm.
>>>>>
>>>>> The significant difference between IP Flexible Algorit= hms and SR
>>>>> Flexible Algorithms is:
>>>>>
>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or S= Rv6 locators
>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 add= resses.
>>>>>
>>>>> So, IP Flexible Algorithms can be deployed in any IP n= etwork, even
>>>>> in the absence of SR.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Ron
>>>>>
>>>>>
>>>>> Juniper Business Use Only
>>>>>
>>>>> -----Original Message-----
>>>>> From: Yingzhen Qu <yingzhen.qu@futurewei.com>
>>>>> Sent: Saturday, October 3, 2020 2:08 PM
>>>>> To: Peter Psenak <ppsenak@cisco.com>; Gyan Mishra
>>>>> <hayabusagsm@gmail.com>; Ron Bonica <rbonica@juniper.net>
>>>>> Cc: = lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>
>>>>> [External Email. Be cautious of content]
>>>>>
>>>>>
>>>>> Hi Peter,
>>>>>
>>>>> Using flex-algo, a SRv6 locator can be associated with= a single
>>>>> algo, which means an IPv6 or IPv4 address can also be = associated
>>>>> with a single algo. So my understanding is Ron's p= roposal is making
>>>>> the
>>> configuration of flex-algo easier?
>>>>> Instead of using the exclude or include list you can c= onfigure a
>>>>> loopback address to a flex-algo directly?
>>>>>
>>>>> Thanks,
>>>>> Yingzhen
>>>>>
>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" <ppsenak@cisco.com>= ; wrote:
>>>>>
>>>>>=C2=A0 =C2=A0 Hi Yingzhen,
>>>>>
>>>>>=C2=A0 =C2=A0 On 02/10/2020 22:15, Yingzhen Qu wrote: >>>>>> Hi Peter,
>>>>>>
>>>>>> My understanding of flex-algo is that for traffic = destined
>>>>> to a prefix on a particular algo, it can only be route= d on routers
>>>>> belong to that algo, which also means only routers in = that algo
>>>>> calculates how to reach that prefix and install it int= o the routing
>>>>> table. It seems to me that using flex-algo (section 12= of the
>>>>> draft) it's possible to have a loopback address as= sociated with
>>>>> only one algo, please correct me if I'm missing or= misunderstood something.
>>>>>
>>>>>=C2=A0 =C2=A0 you are right. That is exactly what is be= ing done for flex-algo with
>>>>>=C2=A0 =C2=A0 SRv6 - locator is associated with a singl= e algo only. The proposal uses
>>>>>=C2=A0 =C2=A0 the same concept.
>>>>>
>>>>>=C2=A0 =C2=A0 thanks,
>>>>>=C2=A0 =C2=A0 Peter
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Yingzhen
>>>>>>
>>>>>> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter = Psenak"
>>>>> <lsr-bounces@ietf.org on behalf of
>>>>> ppsenak=3D40cisco.com@dmarc.ietf.org>
>>>>> wrote:
>>>>>>
>>>>>>=C2=A0 =C2=A0 Gyan,
>>>>>>
>>>>>>=C2=A0 =C2=A0 On 02/10/2020 18:30, Gyan Mishra wrot= e:
>>>>>>> All,
>>>>>>>
>>>>>>> With SRv6 and IP based flex algo a generic que= stion as it
>>> applies
>>>>> to
>>>>>>> both. Is it possible to have within a single I= GP domain
>>> different
>>>>> sets
>>>>>>> of nodes or segments of the network running di= fferent
>>>>> algorithms.
>>>>>>
>>>>>>=C2=A0 =C2=A0 absolutely.
>>>>>>
>>>>>>> From
>>>>>>> both drafts it sounds like all nodes have to a= gree on same
>>>>> algorithm
>>>>>>> similar to concept of metric and reference ban= dwidth all
>>> have to
>>>>> have
>>>>>>> the same style metric and play to the same she= et of music.
>>>>>>
>>>>>>=C2=A0 =C2=A0 all participating nodes need to agree= on the definition of the
>>>>> flex-algo
>>>>>>=C2=A0 =C2=A0 and advertise the participation. That= 's it.
>>>>>>
>>>>>>> If there was
>>>>>>> a way to use multiple algorithms simultaneousl= y based on
>>> SFC
>>>>> or services
>>>>>>> and instantiation of specific algorithm based = on service to
>>> be
>>>>>>> rendered.=C2=A0 Doing so without causing a rou= ting loop or sub
>>>>> optimal
>>>>>>> routing.
>>>>>>
>>>>>>=C2=A0 =C2=A0 you can certainly use multiple algori= thms simultaneously and
>>> use
>>>>> algo
>>>>>>=C2=A0 =C2=A0 specific paths to forward specific tr= affic over it. How that
>>>>>> is
>>> done
>>>>>>=C2=A0 =C2=A0 from the forwarding perspective depen= ds in which
>>> forwarding
>>>>> plane you
>>>>>>=C2=A0 =C2=A0 use. Flex-algo control plane is indep= endent of the forwarding
>>>>> plane.
>>>>>>
>>>>>>
>>>>>>> I thought with flex algo that there exists a f= eature that on each
>>>>>>> hop there is a way to specify which algo to us= e hop by
>>> hop
>>>>> similar
>>>>>>> to a hop by hop policy based routing.
>>>>>>
>>>>>>=C2=A0 =C2=A0 no, there is no hop-by-hop classifica= tion, that is problematic
>>> and
>>>>> does
>>>>>>=C2=A0 =C2=A0 not scale for high speeds. Classifica= tion is done at the
>>> ingress only.
>>>>>>
>>>>>>=C2=A0 =C2=A0 thanks,
>>>>>>=C2=A0 =C2=A0 Peter
>>>>>>
>>>>>>>
>>>>>>
>>>>>>=C2=A0 =C2=A0 _____________________________________= __________
>>>>>>=C2=A0 =C2=A0 Lsr mailing list
>>>>>>=C2=A0 =C2=A0 Lsr@ietf.org
>>>>>>
>>>>> https://urld= efense.com/v3/__https://nam11.safelinks.protection.outl
>>>>> oo
>>>>> k.com/
>>>>> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo= *2Flsr&amp;data
>>>>> =3D
>>> 0
>>>>> 2
>>>>>
>>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d= 86781
>>>>>
>>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637373152739= 86
>>>>>
>>> 5126&amp;sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1= ip0g*3D
>>>>>
>>> &amp;reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1= fRln9MjimeJcR
>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lsr mailing list
>>>>> Lsr@= ietf.org
>>>>> https://urld= efense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>>> sr__;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhC= uZtODomUQWC_H
>>>>> z218CE8S8XzlIxAA$
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org=
>>> https://urldefense= .com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>>> _
>>> _;!!NEt6yMaO-gk!TeHgIKM4lUZhkYnt_eFt3SshGJtln8PTqhCuZtODomUQWC= _Hz218C
>>> E
>>> 8S8XzlIxAA$
--


Gyan Mishra

Network Solutions A<= /i>rchitect=C2=A0=

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD


--
--000000000000a75a4b05b185263e-- From nobody Mon Oct 12 21:39:51 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD313A0DFE; Mon, 12 Oct 2020 21:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 yroNN4thhABL; Mon, 12 Oct 2020 21:39:37 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 315103A09F7; Mon, 12 Oct 2020 21:39:34 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id f15so6086215uaq.9; Mon, 12 Oct 2020 21:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IDVmzwul4ofqd5waloRN0uQpcMgvLZ9ZAv4gENR6/vk=; b=F0Rbf0927PXPCY8P+LUqSssUIphXiGlgH7Mpj5zcMadlgjnOSFWzeixVoRkjqFV0rh ySP0nnJcEyrsXoBFPrHe9AgwSDnT44IkK/aiM+MTOgXYPqAxxgF+XEM8D9dXfew1IvGk mzhT9j6YGewOMKt9JzOEFs+H1+1iEDoAxVUt7H5zUQME3rsp8l3y/FoiSc9wOqJnclEK 7z3yy/oYtTu7hHPyvLMNpyaoo3T8XEQQToAw2V+KSL4jmiT8E73cgSHP3eiw0SkogC5N 9m+NG7J2xUM9fQj1ld3U4bjtZDh+xjpGO1XXlrrGR5uhJHk5OvctparlVzcS9ea7ulwm fOcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IDVmzwul4ofqd5waloRN0uQpcMgvLZ9ZAv4gENR6/vk=; b=Ukcg6f+KxcXsQkge3Y6XW112RCeu7sdSrFWc3KeQPZ2GbdDAfERIBwGs9i2IgRU+hu mEQGkIHQZ50lLb02K+4vIfCJmHadQm4JvqrchE5OPDIerzeUNjVUFsNOWHYdOXnf1uWq 20Stl0cnVcHWI0OmlNTlyjuAq80y/O7wjOQcv5zHtcB/6Y2xdAeH9SVHfPSHs+bPiuXv ORgEF3yjYITttAjNA0Bb/MOJuAXtzsUOR7Ax1//W6WN/IMoj2tr2r1C+epBHeiEX6KBl +DkKJgDcN737P6KzaUtRaKG3Cu8WbNi0GCZqgUMA4tMAE9/KV+K7BCam9Gs4kN14Igdu iOWA== X-Gm-Message-State: AOAM532khP51HYqyDDXnl6TqMz2U5MLQtL/+DpDGNyLIyDzMfiXzEDwh Fiw19kbfMonAIXW21gwYxn34CM7awAUuS6CfmXibuTGzWVT6Mzwc X-Google-Smtp-Source: ABdhPJwivjK3H4T4XTF7JrFFfYTkZE+PXcHfazL1EzpNUJ1VDSmY2OT+6w6pEa/fwhHH19RCTN3IoRrMn4WnlpA3iZg= X-Received: by 2002:ab0:4d62:: with SMTP id k34mr2800567uag.141.1602563972692; Mon, 12 Oct 2020 21:39:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Tue, 13 Oct 2020 00:33:50 -0400 Message-ID: To: TEAS WG , pce@ietf.org, IDR List , lsr , BESS , BIER WG , SPRING WG Content-Type: multipart/alternative; boundary="00000000000052820105b18600e0" Archived-At: Subject: Re: [Lsr] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 04:39:40 -0000 --00000000000052820105b18600e0 Content-Type: text/plain; charset="UTF-8" All Another way of looking at BGP-LS is that it is an extremely powerful tool for centralized controller based architectures or hybrid architectures, and it does not bog down or impact the agility and lightweight aspects of BGP, as BGP has its overall ability to stack & pile on SAFI's and codepoint's as necessary to meet the desired design objectives. So BGP can still remain as light weight or as heavy weight as desired based on the design objective. ! BGP LS IAIA codepoints https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml So its safe to say that the use cases are pretty limitless for BGP-LS from PCE path instantiation to ZTP & Day X provisioning & configuration. I think "dump drunk" depiction of BGP-LS is really a negative perception, as BGP-LS has the native data structures primitives to build customizable TLV's to meet almost any design objective. Comments welcome. Kind Regards Gyan On Sat, Oct 10, 2020 at 3:26 PM Gyan Mishra wrote: > > Dear TEAS, PCE, IDR, LSR, BESS, BIER Spring Working Groups, > > I have noticed that after reviewing many drafts across many WGs it seems > in the industry that the lines seem to be blurred between a PCE controller, > ODL or Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day > X provisioning. > > As this is a software sitting on a server you can have a swiss army knife > server that does everything from PCE path computation to Netconf/Yang ZTP > & Day N provisioning as well as any SDN Controller ODL or Openflow > controller type functions as well. > > How this comes into play and realization of the lines being blurred is the > use of BGP-LS in building the IGP topological graph of the network which > was designed for PCEP and PCE & PCC active & passive off line path > computation for both RSVP-TE or SR-TE path instantiation. > > However now BGP-LS can also be used for other functions now such as usage > as I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use > BGP-LS to gather the elements internals within BIER using the same BGP-LS > data structures to populate with BIER specific information to graph the > BIER topology. So here we are not doing any path computations as we are > using in this use case for NMS type function to gather data for ZTP & Day > N provisioning. > > Similarly other use cases such as with TEAS TS-Transport slice and being > able to provision TS and capturing the TS Enhanced VPN RT & resource > information and leveraging BGP-LS to do the same data gathering & ZTP like > controller style provisioning. > > It does seem as though BGP-LS as its a means of "data gathering" "dump > truck" of anything with the kitchen sink included to build any type of > topological graph of literally anything under the sun. I see that is a > nice to leverage but it does in fact blur the lines of NMS Netconf/Yang > Controller based functionality and PCE path computation functionality and > SDN controller based ZTP functionality into a single ubiquitous server that > can do all of the above and use BGP-LS to accomplish the "kitchen sink" > tasks. It does however transform BGP to be an NMS tool but a "tool" and > not just the original function which it was intended NLRI network > reachability. > > Am I off base and please let me know as its BGP-LS is being way over > leveraged. There are pros & cons to everything but I thought I would bring > up to the WG as an important discussion point. > > Lots of food for thought. Welcome all comments as well as concerns > related to this topic. > > Kind Regards, > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000052820105b18600e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

So its safe to say that the use= cases are pretty limitless for BGP-LS from PCE path instantiation to ZTP &= amp; Day X provisioning & configuration.=C2=A0 I think "dump drunk= " depiction of BGP-LS is really a negative perception, as BGP-LS has t= he native data structures primitives to build customizable TLV's to mee= t almost any design objective.=C2=A0

Comments welc= ome.

Kind Regards

Gyan



On Sat, Oct 10, 2020 at 3:26 PM Gyan Mishra <= hayabusagsm@gmail.com> wrot= e:

Dear TEAS, PCE, IDR, LSR, BESS, BIER=C2=A0 Spring Workin= g Groups,

I have noticed that after reviewing many draft= s across many WGs it seems in the industry that the lines seem to be blurre= d between a PCE controller, ODL or Openflow SDN Controller and a Netconf/Ya= ng NMS Controller ZTP & Day X provisioning.

As= this is a software sitting on a server you can have a swiss army knife ser= ver that does everything from PCE path computation to=C2=A0 Netconf/Yang ZT= P & Day N provisioning as well as any SDN Controller ODL or Openflow co= ntroller type functions as well.

How this comes in= to play and realization of the lines being blurred is the use of BGP-LS in = building the IGP topological graph of the network which was designed for PC= EP and PCE & PCC active & passive off line path computation for bot= h RSVP-TE or SR-TE path instantiation.=C2=A0=C2=A0

However now BGP-LS can also be used for other functions now such as usage = as I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use BGP-L= S to gather the elements internals within BIER using the same BGP-LS data s= tructures to populate with BIER specific information to graph the BIER topo= logy.=C2=A0 So here we are not doing any path computations as we are using = in this use case=C2=A0 for NMS type function to gather data for ZTP & D= ay N provisioning.

Similarly other use cases such = as with TEAS TS-Transport slice and being able to provision TS and capturin= g the TS Enhanced VPN RT & resource information and leveraging BGP-LS t= o do the same data gathering & ZTP like controller style provisioning.= =C2=A0

It does seem as though BGP-LS as its a mean= s of "data gathering" "dump truck" of anything with the= kitchen sink included to build any type of topological graph of literally = anything under the sun.=C2=A0 I see that is a nice to leverage but it does = in fact blur the lines of NMS Netconf/Yang Controller based functionality a= nd=C2=A0 PCE path computation functionality and SDN controller based ZTP fu= nctionality into a single ubiquitous server that can do all of the above an= d use BGP-LS to accomplish the "kitchen sink" tasks.=C2=A0 It doe= s however transform BGP to be an NMS tool but a "tool" and not ju= st the original function which it was intended NLRI network reachability.

Am I off base and please let me know as its BG= P-LS is being way over leveraged.=C2=A0 There are pros & cons to everyt= hing but I thought I would bring up to the WG as an important discussion po= int.

Lots of food for thought.=C2=A0 Welcome all c= omments as well as concerns related to this topic.

Kind= Regards,


--
--00000000000052820105b18600e0-- From nobody Mon Oct 12 22:48:25 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDAB3A0E61 for ; Mon, 12 Oct 2020 22:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 6gUJqvaSZ9PT for ; Mon, 12 Oct 2020 22:48:20 -0700 (PDT) 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 355153A0D0E for ; Mon, 12 Oct 2020 22:48:20 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id y16so14970243ila.7 for ; Mon, 12 Oct 2020 22:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=696ou6rsD+ELcjX9nxK5rl6fh4zt8B5CRry0TpQ5cPY=; b=Tk8PrfYiv42A2n5d8qHwke4TWfTYNZ3srUJNITy/PGjhr389bXIh9IzwYifx/DNTeS OHWUV4JNUbfidO7sYN9kiPW2l1QZ4gAUY01CnQT4JzBMyamwFn/YWVSBJ0VjNP62nEAe zrqcXg5jpOK6qgoGmgRxZ4WUtWYkovc+1tRbgJVbsLtWwUvp1aa9pKXgi3cYumjQiKk9 PdvPreGXBXiueLh+fMRgI0OJOglkXL7sV8b09tS/Bv03QBit2gbeVWIL1SPs0RaI4ZA8 W4vCle+SsMH96YHAB/Va/HsmeQNzAg2JK9KOnJChu24QknXkE+YHQT3PuSCecb+MVXOU lghQ== 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=696ou6rsD+ELcjX9nxK5rl6fh4zt8B5CRry0TpQ5cPY=; b=g8kxUiGcsnNtCrv0w0oQ+2qEUez3+mFnDVRMaIQdJzrW7dQ73vIAonqzNy6tSbi//p WRdRuksqT1R0UU/SQuGY761UKACXRyMmpUmXUcr4JdTUanFd73CevP7DTMwSMDgAepcR 9p2aJg4i9d/NSzbgLldqNJjK19y46VHugABwyYBmzuYd26pygoAWn7Aa3X7usmC/sy1x U46v7pm6okLGY0+Hc7MXNsyC6d7Z8lliOhian5X4z/zjQocV7b13Hi3HlSSCgV62oJtE zsNmQE5wVyj2MkDOPaKIDOZL3n+vqFBYGHMbVF+qDXLifnVbZH0h2IBqwc/v6YJGC/2O sOmA== X-Gm-Message-State: AOAM532QFbrh9MDfZTMoNib6k/IHEXd1OSOxobhwQduexqjj9GPyQ9H6 Em/o1Hn6Lla376N5wDfUyIEMO8KXld2gvHaNIpo= X-Google-Smtp-Source: ABdhPJwO5hp22vLTJk7cSXnN47LGCpAnlnilv5R/5nNOqXxAgIn8NVaxTKaRdOiRLTF07PhBcO1mT4yfLx3LReGDZh0= X-Received: by 2002:a92:907:: with SMTP id y7mr1821829ilg.276.1602568099207; Mon, 12 Oct 2020 22:48:19 -0700 (PDT) MIME-Version: 1.0 References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> <00a701d6a109$423b2bc0$c6b18340$@chinatelecom.cn> In-Reply-To: <00a701d6a109$423b2bc0$c6b18340$@chinatelecom.cn> From: Dhruv Dhody Date: Tue, 13 Oct 2020 11:17:42 +0530 Message-ID: To: Aijun Wang Cc: Gyan Mishra , "Acee Lindem (acee)" , lsr@ietf.org, Aijun Wang , "Peter Psenak (ppsenak)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 05:48:23 -0000 Hi Aijun, I am not particularly sold on the argument that the configuration requirements of RFC 5316/RFC 5392 are especially burdensome. A PCE relies on the TEDB which comprises nodes & links, and it makes sense to have an inter-AS link represented as a "Link". Moreover, these links are TE-enabled and thus carry the TE properties of the link. You cannot avoid using this mechanism if Inter-AS Link's TE-properties need to be advertised. That is why I consider your proposal to be more applicable for non-TE use cases perhaps(?)! Thanks! Dhruv On Tue, Oct 13, 2020 at 8:03 AM Aijun Wang wrote: > > Hi, Dhruv: > > Please see my explain to Jeff. https://mailarchive.ietf.org/arch/msg/lsr/= VLufuaGDiRgaflcu58FY_SHnJ7A/ > > The solutions described in RFC 5316 and RFC 5392 are possible and straigh= tforward, but they have some constraints, especially for the operation/conf= iguration of the network. > > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: dhruv.ietf@gmail.com [mailto:dhruv.ietf@gmail.com] > Sent: Monday, October 12, 2020 3:25 PM > To: Gyan Mishra > Cc: Acee Lindem (acee) ; lsr@ietf.org;= Aijun Wang ; Aijun Wang ; Peter Psenak (ppsenak) > Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passiv= e-interface-attribute-04.txt > > Hi Gyan, > > As far as PCE is concerned, we have the inter-AS link information via RFC= 5316 and RFC 5392. Both of these include a section on PCE's BRPC procedure= for instance. > > I see you have other use cases, but it would be good to highlight why for= the PCE use case the above is deficient. > > Thanks! > Dhruv > > > On Mon, Oct 12, 2020 at 12:49 AM Gyan Mishra wrot= e: > > > > > > Hi Acee > > > > I believe what Aijun is trying to explain is that the primary purpose o= f PCE for active or passive path computation is for inter-as RSVP-TE PCALC = path computation or SR-TE path computation. So PCE is solving a well known= PCALC bin packing problem due to pcalc over subscribing RSVP tunnel bandwi= dth which is inherent an RSVP issue, but a bigger problematic issue is with= being able to build an inter-as TE path with a single or multiple PCE cont= rollers that can take the LSDB link attributes in the TEDs dB opaque LSAs i= n the ospf case and ISIS TE TLVs and rebuild the topology topology from eac= h TE domain to be able to build a congruent end to end RSVP TE or SR-TE tra= ffic steered path instantiation. > > > > Without the use of PCE controllers as the LSDB link attribute informati= on is not known as RSVP loose ERO static lsp is built or SR SR-TE prefix si= d loose path is built, failover due to crank back is impacted for reroute, = due to not having a complete depiction of the other AS Link state topology = by the head end or SR source node. > > > > So to build that entire end to end inter-as path for that end to end RS= VP TE or SR-TE path instantiation it is critical to indentify the inter-as = link eBGP tie link that may have static routes or BGP LU for RSVP head end = to tail end reachability and SR-TE reachability to build out the end to end= path instantiation. So the BGP-LS task to rebuild the lsdb topology of e= ach inter connected AS that the RSVP TE or SR-TE steered path traverses, we= need the accurate depiction and that includes the Identification of the c= ritical inter-as tie link eBGP peering link that is passive for the PCE pat= h computation logic for the end to end inter-as path instantiation. > > > > As for other interfaces using passive in the context of a operator serv= ice provider or enterprise core P and PE routers all links are transit with= neighbors except the inter-as tie so having this new IGP TLV will help to = that end. In the operator =E2=80=9Ccore=E2=80=9D network if there are othe= r interfaces that don=E2=80=99t need to be advertised as stub, they can ea= sily be excluded from being added into IGP. > > > > Kind Regards > > > > Gyan > > > > On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) wrote: > >> > >> Hi Aijun, > >> > >> > >> > >> From: Aijun Wang > >> Date: Friday, October 9, 2020 at 9:58 PM > >> To: Acee Lindem , "Peter Psenak (ppsenak)" > >> , 'Aijun Wang' > >> Cc: "lsr@ietf.org" > >> Subject: RE: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Hi, Acee: > >> > >> > >> > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of > >> Acee Lindem (acee) > >> Sent: Saturday, October 10, 2020 3:48 AM > >> To: Aijun Wang ; Peter Psenak (ppsenak) > >> ; 'Aijun Wang' > >> Cc: lsr@ietf.org > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Speaking as WG member: > >> > >> > >> > >> Hi Aijun, > >> > >> > >> > >> From: Aijun Wang > >> Date: Thursday, October 8, 2020 at 11:09 PM > >> To: Acee Lindem , "Peter Psenak (ppsenak)" > >> , 'Aijun Wang' > >> Cc: "lsr@ietf.org" > >> Subject: RE: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Hi, Acee: > >> > >> Sorry for the previous pruned mail. Let's reply you again along your o= riginal question. > >> > >> Please see inline.[WAJ] > >> > >> > >> > >> -----Original Message----- > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of > >> Acee Lindem (acee) > >> Sent: Wednesday, September 30, 2020 7:47 PM > >> To: Aijun Wang ; Peter Psenak (ppsenak) > >> ; 'Aijun Wang' > >> Cc: lsr@ietf.org > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Hi Aijun, > >> > >> Other than your ill-conceived topology discovery heuristic > >> > >> [WAJ] The topology discovery heuristic is not suitable for the corner = use case when the unnumbered interface is used, as explained in https://too= ls.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appendix-B. If y= ou don=E2=80=99t agree, would you like to illustrate other non-applicable s= cenarios? > >> > >> > >> > >> Right =E2=80=93 and nobody other than yourself believes the IGPs shoul= d be modified to expose the abstracted topology of an area outside that are= a. > >> > >> [WAJ] The modification doesn=E2=80=99t change the way and complexity = of > >> route calculation within IGP. It just piggyback some extra > >> information, the bulk of the reconstruction work is done by the > >> controller. Such extra information can also have other usage, as > >> described in > >> https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06# > >> section-1 > >> > >> And, the proposal described in https://datatracker.ietf.org/doc/html/d= raft-wang-lsr-passive-interface-attribute-04 is different with the problem = you concerned. It has no relation with the abstracted topology of an area.= Maybe you are confused by these two drafts? > >> > >> > >> > >> It is a similar problem. You are still trying to overload the prefix a= dvertisements with a link attribute (passive interface) so that it can be c= onveyed outside the domain. We certainly wouldn=E2=80=99t waste a limited p= refix flag on this parochial application. > >> > >> > >> > >> > >> > >> You can solve the problem with BGP-LS session(s) between the router wi= th a BGP-LS session to the controller and a router in each area w/o a rout= er with a BGP-LS session to the controller. > >> > >> [WAJ] This is possible, but not efficient. For operation, we must also= consider the configuration/administration overhead. BGP-LS is designed ma= inly for the northbound protocol, not east-west protocol. > >> > >> > >> > >> what other possible reason would there be for associating the passive = attribute with a prefix? > >> > >> [WAJ] To know the boundary of the IGP domain. After knowing the bounda= ry, the controller can safely apply and check the network security policy, = the inbound traffic control policy etc. > >> > >> > >> > >> It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How does= the presence of a prefix associated with a passive interface allow you to = make this deduction? > >> > >> [WAJ] Passive interfaces are deployed mainly at the boundary of IGP do= main. Is there any other exception? > >> > >> While passive interfaces are not standardized, there is nothing that l= imits their usage to an IGP boundary. They can and are deployed on any inte= rface where adjacencies are not to be formed (e.g., a stub subnet containin= g hosts). > >> > >> > >> > >> Thanks, > >> Acee > >> > >> > >> > >> Thanks, > >> > >> Acee > >> > >> > >> > >> Thanks, > >> > >> Acee > >> > >> > >> > >> On 9/29/20, 10:39 PM, "Aijun Wang" wrote: > >> > >> > >> > >> Hi, Acee and Peter: > >> > >> Passive interface is mainly used at the edge of the network, where= the unnumbered interface will not be used. > >> > >> And the information to flag the passive interfaces is for position= ing the area boundary, not conflict with the abstract capabilities of the a= rea inside. > >> > >> > >> > >> > >> > >> Best Regards > >> > >> > >> > >> Aijun Wang > >> > >> China Telecom > >> > >> > >> > >> -----Original Message----- > >> > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On > >> Behalf Of Acee Lindem (acee) > >> > >> Sent: Tuesday, September 29, 2020 9:16 PM > >> > >> To: Peter Psenak ; Aijun Wan= g > >> ; 'Aijun Wang' > >> > >> Cc: lsr@ietf.org > >> > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Speaking as WG member: > >> > >> > >> > >> Hi Aijun, Peter, > >> > >> I agree with Peter - one of the main motivations for having areas = is to abstract the topology within the area. Now you're trying to supplant = this - one topological detail at a time with ill-conceived IGP features. > >> > >> Thanks, > >> > >> Acee > >> > >> > >> > >> On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" wrote: > >> > >> > >> > >> Hi Aijun, > >> > >> > >> > >> On 29/09/2020 11:07, Aijun Wang wrote: > >> > >> > Hi, Peter: > >> > >> > > >> > >> > Thanks for your comments. > >> > >> > 1. For BGP-LS deployment, there normally only be one router > >> that within the > >> > >> > IGP domain to report the topology information, this router > >> should know such > >> > >> > passive links which exists mainly on other border routers > >> via the IGP > >> > >> > protocol. This is main reason to extension the IGP > >> protocol. > 2. For the solution, normally, the link within the IGP > >> connect two > >> > >> ends, but > >> > >> > passive interface is special and not fall in this space. We > >> have studied the > >> > >> > current TLVs that for link, and find no suitable container > >> to append this > >> > >> > information. This is the reason that we select the TLVs > >> that associated with > >> > >> > Prefix. > >> > >> > >> > >> if the link is unnumbered, your solution does not work. As I > >> said, if > >> > >> you need a knowledge about the link, you can not advertise it = as a prefix. > >> > >> > >> > >> thanks, > >> > >> Peter > >> > >> > >> > >> > >> > >> > > >> > >> >>From other POV, the OSPFv3 defines now the > >> "Intra-Area-Prefix LSA", which > >> > >> > isolate the prefix information that associated with link > >> into this > >> > >> > container, contains the stub link, local interface > >> information etc. Put such > >> > >> > attribute along with the prefix is then acceptable? > >> > >> > > >> > >> > > >> > >> > Best Regards > >> > >> > > >> > >> > Aijun Wang > >> > >> > China Telecom > >> > >> > > >> > >> > -----Original Message----- > >> > >> > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On > >> Behalf Of Peter > >> > >> > Psenak > >> > >> > Sent: Tuesday, September 29, 2020 4:29 PM > >> > >> > To: Aijun Wang > >> > >> > Cc: lsr@ietf.org > >> > >> > Subject: Re: [Lsr] FW: New Version Notification for > >> > >> > draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > > >> > >> > Hi Aijun, > >> > >> > > >> > >> > here's my comments: > >> > >> > > >> > >> > The purpose of this draft is to advertise passive links. > >> > >> > > >> > >> > 1. I'm not sure the problem needs to be solved by IGPs. I > >> tend to believe > >> > >> > ietf-idr-bgpls-inter-as-topology-ext is sufficient. > >> > >> > > >> > >> > 2. the solution that you proposed is wrong. You are trying > >> to derive > >> > >> > topological data about the passive links from the prefix adv= ertisement. > >> > >> > This is semantically incorrect and only works under very spe= cific condition. > >> > >> > If you need to advertise a link, advertise it as a "special" > >> > >> > link, not as a "special" prefix. > >> > >> > > >> > >> > thanks, > >> > >> > Peter > >> > >> > > >> > >> > On 29/09/2020 03:17, Aijun Wang wrote: > >> > >> >> Hi, Peter: > >> > >> >> > >> > >> >> Would you like to review and give comments on the updates > >> version of this > >> > >> > draft? > >> > >> >> We have also added the protocol extension proposal for OSPF= v3. > >> > >> >> > >> > >> >> The update version of this draft can refer to > >> > >> >> > >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac > >> e > >> > >> >> -attribute > >> > >> >> Thanks in advance. > >> > >> >> > >> > >> >> > >> > >> >> Best Regards > >> > >> >> > >> > >> >> Aijun Wang > >> > >> >> China Telecom > >> > >> >> > >> > >> >>> -----Original Message----- > >> > >> >>> From: internet-drafts@ietf.org > >> [mailto:internet-drafts@ietf.org] > >> > >> >>> Sent: Monday, September 28, 2020 3:17 PM > >> > >> >>> To: Zhibo Hu ; Gyan Mishra > >> > >> >>> ; Aijun Wang > >> ; > >> > >> >>> Gyan S. Mishra > >> > >> >>> Subject: New Version Notification for > >> > >> >>> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> >>> > >> > >> >>> > >> > >> >>> A new version of I-D, > >> > >> >>> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> >>> has been successfully submitted by Aijun Wang and posted > >> to the IETF > >> > >> >>> repository. > >> > >> >>> > >> > >> >>> Name: draft-wang-lsr-passive-interface-attri= bute > >> > >> >>> Revision: 04 > >> > >> >>> Title: Passive Interface Attribute > >> > >> >>> Document date: 2020-09-28 > >> > >> >>> Group: Individual Submission > >> > >> >>> Pages: 7 > >> > >> >>> URL: > >> > >> >>> https://www.ietf.org/id/draft-wang-lsr-passive-interface-a= ttribute-04. > >> > >> >>> txt > >> > >> >>> Status: > >> > >> >>> > >> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-att > >> > >> >>> r > >> > >> >>> ibute/ > >> > >> >>> Htmlized: > >> > >> >>> > >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interfac > >> > >> >>> e > >> > >> >>> -attribut > >> > >> >>> e > >> > >> >>> Htmlized: > >> > >> >>> > >> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribut > >> > >> >>> e > >> > >> >>> -04 > >> > >> >>> Diff: > >> > >> >>> > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-interface-a= t > >> > >> >>> t > >> > >> >>> ribute-04 > >> > >> >>> > >> > >> >>> Abstract: > >> > >> >>> This document describes the mechanism that can be use= d to > >> > >> >>> differentiate the passive interfaces from the normal = interfaces > >> > >> >>> within ISIS or OSPF domain. > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> 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. > >> > >> >>> > >> > >> >>> The IETF Secretariat > >> > >> >>> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> > > >> > >> > _______________________________________________ > >> > >> > Lsr mailing list > >> > >> > Lsr@ietf.org > >> > >> > https://www.ietf.org/mailman/listinfo/lsr > >> > >> > > >> > >> > > >> > >> > > >> > >> > >> > >> _______________________________________________ > >> > >> Lsr mailing list > >> > >> Lsr@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/lsr > >> > >> > >> > >> _______________________________________________ > >> > >> Lsr mailing list > >> > >> Lsr@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/lsr > >> > >> > >> > >> > >> > >> _______________________________________________ > >> > >> Lsr mailing list > >> > >> Lsr@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/lsr > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > -- > > > > > > Gyan Mishra > > > > Network Solutions Architect > > > > M 301 502-1347 > > 13101 Columbia Pike > > Silver Spring, MD > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > From nobody Tue Oct 13 01:02:50 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B01F3A0EC4 for ; Tue, 13 Oct 2020 01:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 D-evNVcSOgoB for ; Tue, 13 Oct 2020 01:02:46 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47523A0944 for ; Tue, 13 Oct 2020 01:02:45 -0700 (PDT) Received: from lhreml749-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E87EACCC019D1DA8CC64; Tue, 13 Oct 2020 09:02:43 +0100 (IST) Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by lhreml749-chm.china.huawei.com (10.201.108.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Tue, 13 Oct 2020 09:02:43 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 13 Oct 2020 16:02:40 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Tue, 13 Oct 2020 16:02:40 +0800 From: "Dongjie (Jimmy)" To: Peter Psenak , Ron Bonica , Yingzhen Qu , Gyan Mishra CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAESbICAACKHAIAA7E2AgADTYwCAAWy/gIAAAz6AgAA7sgCAAOLhAIAAi8SAgAAopgCAA1loEIAFx4OAgAExPQCAAwtCgIACAvgg Date: Tue, 13 Oct 2020 08:02:40 +0000 Message-ID: <34c223a132f748e0a802d538ccd073b0@huawei.com> References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> In-Reply-To: <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 08:02:48 -0000 Hi Peter,=20 Thanks for your reply. Please see further inline: > -----Original Message----- > From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > Sent: Monday, October 12, 2020 4:39 PM > To: Dongjie (Jimmy) ; Ron Bonica > ; Yingzhen Qu ; Gyan > Mishra > Cc: lsr@ietf.org; Jeff Tantsura > Subject: Re: [Lsr] FW: New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt >=20 > Hi Jimmy, >=20 > On 10/10/2020 05:05, Dongjie (Jimmy) wrote: > > Hi Peter, > > > > Thanks for your reply. It aligns with my understanding of FAD, which is= just a > set of constraints for path computation. Thus one Flex-Algo ID could be u= sed > with multiple different data planes. Is this understanding correct? >=20 > correct. >=20 > > > > If so, my question is about the scenario below: > > > > A group of nodes in a network support FA-128, a sub-group of them bind > FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. >=20 > just to use the correct terminology, we should use "participate" instead = of > "support". Agree. >=20 > >When one node compute an SR path to a destination, can it compute the pa= th > to only pass the nodes which bind FA-128 to SR SIDs, and avoid the > nodes >which bind FA-128 to IP address? If so, how could this node know t= he > binding of FA to different data planes on other nodes? >=20 > again, it is the participation problem. >=20 > Nodes that participate in the SR Flex-algo 128 will advertise the partici= pation > using the SR-Algorithm Sub-TLV. Only these nodes will be used during the = SR > flex-algo computation for algo 128. >=20 > Nodes that participate in IP flex-algo 128 will advertise the participati= on using > the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP fl= ex-algo > computation for algo 128. Agree that if participation to Flex-Algo is advertised in a data plane spec= ific manner, then path computation with Flex-Algo constraints could be done= only using nodes which bind the Flex-Algo to the same data plane.=20 As Robert asked and you confirmed, this implies each data plane needs to be= treated as an independent application of Flex-Algo. We have SR-Algorithm s= ub-TLV and IP Algorithm sub-TLV, while there are actually more data planes = to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that Flex= -Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4, IPv6, e= tc. separately? Best regards, Jie >=20 > thanks, > Peter >=20 > > > > Best regards, > > Jie > > > >> -----Original Message----- > >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > >> Sent: Friday, October 9, 2020 11:58 PM > >> To: Dongjie (Jimmy) ; Ron Bonica > >> ; Yingzhen Qu > >> ; Gyan Mishra > >> Cc: lsr@ietf.org; Jeff Tantsura > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> Hi Jimmy, > >> > >> > >> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > >>> Hi Ron, > >>> > >>> Thanks for explaining the difference between IP Flex-Algo and SR > >>> Flex-algo. As > >> you said, the major difference is the data plane. > >>> > >>> If my understanding is correct, for one Flex-Algo to be used > >>> correctly, the set > >> of nodes need to apply consistent constraints in computation, and > >> bind the FAD to the same data plane. > >>> > >>> Is it possible that different nodes may use the same Flex-Algo with > >>> different > >> data plane, e.g. some with SR-MPLS, some with SRv6, and some with > >> pure IP etc., or each Flex-Algo is always associated with only one > >> data plane? In the former case, should the flex-algo definition also > >> indicate the data plane(s) to be used with the flex-algo? > >> > >> let me respond to this query, as this is not specific to Ron's draft. > >> > >> FAD is data plane agnostic and is used by all of them. > >> > >> thanks, > >> Peter > >> > >>> > >>> Best regards, > >>> Jie > >>> > >>>> -----Original Message----- > >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica > >>>> Sent: Sunday, October 4, 2020 4:34 AM > >>>> To: Yingzhen Qu ; Peter Psenak > >>>> ; Gyan Mishra > >>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>> > >>>> Hi Yingzhen, > >>>> > >>>> IP Flexible Algorithms are like SR Flexible Algorithms in the > >>>> following > >> respects: > >>>> > >>>> - Links have IGP metrics, TE metrics, delay metrics and > >>>> administrative colors > >>>> - FADs define Flexible Algorithms > >>>> > >>>> More specifically, the FAD: > >>>> > >>>> - Indicates which metric type the Flexible Algorithm uses > >>>> - Specifies constraints in terms of link colors that are included > >>>> or excluded from the Flexible Algorithm. > >>>> > >>>> The significant difference between IP Flexible Algorithms and SR > >>>> Flexible Algorithms is: > >>>> > >>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators > >>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > >>>> > >>>> So, IP Flexible Algorithms can be deployed in any IP network, even > >>>> in the absence of SR. > >>>> > >>>> Ron > >>>> > >>>> > >>>> Juniper Business Use Only > >>>> > >>>> -----Original Message----- > >>>> From: Yingzhen Qu > >>>> Sent: Saturday, October 3, 2020 2:08 PM > >>>> To: Peter Psenak ; Gyan Mishra > >>>> ; Ron Bonica > >>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>> > >>>> [External Email. Be cautious of content] > >>>> > >>>> > >>>> Hi Peter, > >>>> > >>>> Using flex-algo, a SRv6 locator can be associated with a single > >>>> algo, which means an IPv6 or IPv4 address can also be associated > >>>> with a single algo. So my understanding is Ron's proposal is making > >>>> the > >> configuration of flex-algo easier? > >>>> Instead of using the exclude or include list you can configure a > >>>> loopback address to a flex-algo directly? > >>>> > >>>> Thanks, > >>>> Yingzhen > >>>> > >>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: > >>>> > >>>> Hi Yingzhen, > >>>> > >>>> On 02/10/2020 22:15, Yingzhen Qu wrote: > >>>> > Hi Peter, > >>>> > > >>>> > My understanding of flex-algo is that for traffic destined > >>>> to a prefix on a particular algo, it can only be routed on routers > >>>> belong to that algo, which also means only routers in that algo > >>>> calculates how to reach that prefix and install it into the routing > >>>> table. It seems to me that using flex-algo (section 12 of the > >>>> draft) it's possible to have a loopback address associated with > >>>> only one algo, please correct me if I'm missing or misunderstood > something. > >>>> > >>>> you are right. That is exactly what is being done for flex-alg= o with > >>>> SRv6 - locator is associated with a single algo only. The prop= osal > uses > >>>> the same concept. > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>> > > >>>> > Thanks, > >>>> > Yingzhen > >>>> > > >>>> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > >>>> >>>> ppsenak=3D40cisco.com@dmarc.ietf.org> > >>>> wrote: > >>>> > > >>>> > Gyan, > >>>> > > >>>> > On 02/10/2020 18:30, Gyan Mishra wrote: > >>>> > > All, > >>>> > > > >>>> > > With SRv6 and IP based flex algo a generic question a= s it > >> applies > >>>> to > >>>> > > both. Is it possible to have within a single IGP doma= in > >> different > >>>> sets > >>>> > > of nodes or segments of the network running different > >>>> algorithms. > >>>> > > >>>> > absolutely. > >>>> > > >>>> > > From > >>>> > > both drafts it sounds like all nodes have to agree on > same > >>>> algorithm > >>>> > > similar to concept of metric and reference bandwidth > all > >> have to > >>>> have > >>>> > > the same style metric and play to the same sheet of > music. > >>>> > > >>>> > all participating nodes need to agree on the definition= of > the > >>>> flex-algo > >>>> > and advertise the participation. That's it. > >>>> > > >>>> > > If there was > >>>> > > a way to use multiple algorithms simultaneously based > on > >> SFC > >>>> or services > >>>> > > and instantiation of specific algorithm based on serv= ice > to > >> be > >>>> > > rendered. Doing so without causing a routing loop or > sub > >>>> optimal > >>>> > > routing. > >>>> > > >>>> > you can certainly use multiple algorithms simultaneousl= y > and > >> use > >>>> algo > >>>> > specific paths to forward specific traffic over it. How= that > is > >> done > >>>> > from the forwarding perspective depends in which > >> forwarding > >>>> plane you > >>>> > use. Flex-algo control plane is independent of the > forwarding > >>>> plane. > >>>> > > >>>> > > >>>> > >I thought with flex algo that there exists a feature t= hat > on > >>>> > > each hop there is a way to specify which algo to use > hop by > >> hop > >>>> similar > >>>> > > to a hop by hop policy based routing. > >>>> > > >>>> > no, there is no hop-by-hop classification, that is > problematic > >> and > >>>> does > >>>> > not scale for high speeds. Classification is done at th= e > >> ingress only. > >>>> > > >>>> > thanks, > >>>> > Peter > >>>> > > >>>> > > > >>>> > > >>>> > > _______________________________________________ > >>>> > Lsr mailing list > >>>> > Lsr@ietf.org > >>>> > > >>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl > >>>> oo > >>>> k.com/ > >>>> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&dat= a > >>>> =3D > >> 0 > >>>> 2 > >>>> > >> > *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 > >>>> > >> > 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >>>> > >> > 5126&sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >>>> > >> > &reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR > >>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > >>>> > > >>>> > > >>>> > > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lsr > >>> > >>> > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Tue Oct 13 01:05:18 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16033A0EE0 for ; Tue, 13 Oct 2020 01:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YCNm-Bkg0d9q for ; Tue, 13 Oct 2020 01:05:13 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9163A0944 for ; Tue, 13 Oct 2020 01:05:12 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id C90CA472AB; Tue, 13 Oct 2020 16:05:05 +0800 (CST) From: "Aijun Wang" To: "'Dhruv Dhody'" , "'Aijun Wang'" Cc: , "'Peter Psenak \(ppsenak\)'" , "'Gyan Mishra'" , "'Acee Lindem \(acee\)'" References: <007a01d695fe$4c4b3f80$e4e1be80$@chinatelecom.cn> <009a01d6963f$f37d9cd0$da78d670$@tsinghua.org.cn> <8d04ccea-1810-421b-84cc-75934200b3f0@cisco.com> <6A10EA24-2A50-439F-8189-FDDDCEF6BB46@cisco.com> <00cb01d696d2$d3abf990$7b03ecb0$@tsinghua.org.cn> <7236B930-5950-4E32-8AB0-416DB5278E1F@cisco.com> <001c01d69de9$783924c0$68ab6e40$@tsinghua.org.cn> <4C885AD1-3E04-476B-B779-C83023B9B7D5@cisco.com> <008901d69ea8$d210f7b0$7632e710$@tsinghua.org.cn> <92C4AB95-5CE6-4BFF-BDFB-5F6322952994@cisco.com> <00a701d6a109$423b2bc0$c6b18340$@chinatelecom.cn> In-Reply-To: Date: Tue, 13 Oct 2020 16:05:05 +0800 Message-ID: <00de01d6a137$8fb89440$af29bcc0$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIJ+mWorx9ReexromEfqpSgpX3kFwEFLd5+AaLg+ScCZ8Mz1AFBnbZFAnYY+uECbteHkQJR6V6DAmQjRUkCKRShvAHJrWG+AiX9uxEBjzJAqwKe9tjlAhSWKruoTDZG0A== Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZHxhISRkeHk9KQh0fVkpNS0lOTE1IS01KSE1VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OhA6ODo6LD8vATgyLQNJOSoB A0kaFANVSlVKTUtJTkxNSEtNTUNLVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUlPSUhNNwY+ X-HM-Tid: 0a7520fdcf779865kuuuc90ca472ab Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-wang-lsr-passive-interface-attribute-04.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 08:05:17 -0000 Hi, Dhruv: -----Original Message----- From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Dhruv Dhody Sent: Tuesday, October 13, 2020 1:48 PM To: Aijun Wang Cc: lsr@ietf.org; Peter Psenak (ppsenak) ; Aijun Wang = ; Gyan Mishra ; Acee = Lindem (acee) Subject: Re: [Lsr] FW: New Version Notification for = draft-wang-lsr-passive-interface-attribute-04.txt Hi Aijun, I am not particularly sold on the argument that the configuration = requirements of RFC 5316/RFC 5392 are especially burdensome. A PCE relies on the TEDB which comprises nodes & links, and it makes = sense to have an inter-AS link represented as a "Link". Moreover, these = links are TE-enabled and thus carry the TE properties of the link. You = cannot avoid using this mechanism if Inter-AS Link's TE-properties need = to be advertised. [WAJ] Yes. For deploying the inter-as TE based on RFC5316/RFC539, we = must configure the properties parameters on every inter-AS link = manually. Interface address/Remote Router ID/Remote AS are just part of = these configuration.=20 That is why I consider your proposal to be more applicable for non-TE = use cases perhaps(?)! [WAJ] To be exact, the proposal is more applicable for non-MPLS TE use = case. But it can also relieve the configuration overhead for MPLS TE use = case. Thanks! Dhruv On Tue, Oct 13, 2020 at 8:03 AM Aijun Wang = wrote: > > Hi, Dhruv: > > Please see my explain to Jeff.=20 > https://mailarchive.ietf.org/arch/msg/lsr/VLufuaGDiRgaflcu58FY_SHnJ7A/ > > The solutions described in RFC 5316 and RFC 5392 are possible and = straightforward, but they have some constraints, especially for the = operation/configuration of the network. > > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: dhruv.ietf@gmail.com [mailto:dhruv.ietf@gmail.com] > Sent: Monday, October 12, 2020 3:25 PM > To: Gyan Mishra > Cc: Acee Lindem (acee) ;=20 > lsr@ietf.org; Aijun Wang ; Aijun Wang=20 > ; Peter Psenak (ppsenak)=20 > > Subject: Re: [Lsr] FW: New Version Notification for=20 > draft-wang-lsr-passive-interface-attribute-04.txt > > Hi Gyan, > > As far as PCE is concerned, we have the inter-AS link information via = RFC 5316 and RFC 5392. Both of these include a section on PCE's BRPC = procedure for instance. > > I see you have other use cases, but it would be good to highlight why = for the PCE use case the above is deficient. > > Thanks! > Dhruv > > > On Mon, Oct 12, 2020 at 12:49 AM Gyan Mishra = wrote: > > > > > > Hi Acee > > > > I believe what Aijun is trying to explain is that the primary = purpose of PCE for active or passive path computation is for inter-as = RSVP-TE PCALC path computation or SR-TE path computation. So PCE is = solving a well known PCALC bin packing problem due to pcalc over = subscribing RSVP tunnel bandwidth which is inherent an RSVP issue, but a = bigger problematic issue is with being able to build an inter-as TE path = with a single or multiple PCE controllers that can take the LSDB link = attributes in the TEDs dB opaque LSAs in the ospf case and ISIS TE TLVs = and rebuild the topology topology from each TE domain to be able to = build a congruent end to end RSVP TE or SR-TE traffic steered path = instantiation. > > > > Without the use of PCE controllers as the LSDB link attribute = information is not known as RSVP loose ERO static lsp is built or SR = SR-TE prefix sid loose path is built, failover due to crank back is = impacted for reroute, due to not having a complete depiction of the = other AS Link state topology by the head end or SR source node. > > > > So to build that entire end to end inter-as path for that end to end = RSVP TE or SR-TE path instantiation it is critical to indentify the = inter-as link eBGP tie link that may have static routes or BGP LU for = RSVP head end to tail end reachability and SR-TE reachability to build = out the end to end path instantiation. So the BGP-LS task to rebuild = the lsdb topology of each inter connected AS that the RSVP TE or SR-TE = steered path traverses, we need the accurate depiction and that includes = the Identification of the critical inter-as tie link eBGP peering link = that is passive for the PCE path computation logic for the end to end = inter-as path instantiation. > > > > As for other interfaces using passive in the context of a operator = service provider or enterprise core P and PE routers all links are = transit with neighbors except the inter-as tie so having this new IGP = TLV will help to that end. In the operator =E2=80=9Ccore=E2=80=9D = network if there are other interfaces that don=E2=80=99t need to be = advertised as stub, they can easily be excluded from being added into = IGP. > > > > Kind Regards > > > > Gyan > > > > On Sat, Oct 10, 2020 at 6:29 AM Acee Lindem (acee) = wrote: > >> > >> Hi Aijun, > >> > >> > >> > >> From: Aijun Wang > >> Date: Friday, October 9, 2020 at 9:58 PM > >> To: Acee Lindem , "Peter Psenak (ppsenak)" > >> , 'Aijun Wang' > >> Cc: "lsr@ietf.org" > >> Subject: RE: [Lsr] FW: New Version Notification for=20 > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Hi, Acee: > >> > >> > >> > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf=20 > >> Of Acee Lindem (acee) > >> Sent: Saturday, October 10, 2020 3:48 AM > >> To: Aijun Wang ; Peter Psenak (ppsenak)=20 > >> ; 'Aijun Wang' > >> Cc: lsr@ietf.org > >> Subject: Re: [Lsr] FW: New Version Notification for=20 > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Speaking as WG member: > >> > >> > >> > >> Hi Aijun, > >> > >> > >> > >> From: Aijun Wang > >> Date: Thursday, October 8, 2020 at 11:09 PM > >> To: Acee Lindem , "Peter Psenak (ppsenak)" > >> , 'Aijun Wang' > >> Cc: "lsr@ietf.org" > >> Subject: RE: [Lsr] FW: New Version Notification for=20 > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Hi, Acee: > >> > >> Sorry for the previous pruned mail. Let's reply you again along = your original question. > >> > >> Please see inline.[WAJ] > >> > >> > >> > >> -----Original Message----- > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf=20 > >> Of Acee Lindem (acee) > >> Sent: Wednesday, September 30, 2020 7:47 PM > >> To: Aijun Wang ; Peter Psenak (ppsenak)=20 > >> ; 'Aijun Wang' > >> Cc: lsr@ietf.org > >> Subject: Re: [Lsr] FW: New Version Notification for=20 > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Hi Aijun, > >> > >> Other than your ill-conceived topology discovery heuristic > >> > >> [WAJ] The topology discovery heuristic is not suitable for the = corner use case when the unnumbered interface is used, as explained in = https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-06#appe= ndix-B. If you don=E2=80=99t agree, would you like to illustrate other = non-applicable scenarios? > >> > >> > >> > >> Right =E2=80=93 and nobody other than yourself believes the IGPs = should be modified to expose the abstracted topology of an area outside = that area. > >> > >> [WAJ] The modification doesn=E2=80=99t change the way and = complexity of=20 > >> route calculation within IGP. It just piggyback some extra=20 > >> information, the bulk of the reconstruction work is done by the=20 > >> controller. Such extra information can also have other usage, as=20 > >> described in=20 > >> https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-0 > >> 6# > >> section-1 > >> > >> And, the proposal described in = https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interface-at= tribute-04 is different with the problem you concerned. It has no = relation with the abstracted topology of an area. Maybe you are = confused by these two drafts? > >> > >> > >> > >> It is a similar problem. You are still trying to overload the = prefix advertisements with a link attribute (passive interface) so that = it can be conveyed outside the domain. We certainly wouldn=E2=80=99t = waste a limited prefix flag on this parochial application. > >> > >> > >> > >> > >> > >> You can solve the problem with BGP-LS session(s) between the router = with a BGP-LS session to the controller and a router in each area w/o a = router with a BGP-LS session to the controller. > >> > >> [WAJ] This is possible, but not efficient. For operation, we must = also consider the configuration/administration overhead. BGP-LS is = designed mainly for the northbound protocol, not east-west protocol. > >> > >> > >> > >> what other possible reason would there be for associating the = passive attribute with a prefix? > >> > >> [WAJ] To know the boundary of the IGP domain. After knowing the = boundary, the controller can safely apply and check the network security = policy, the inbound traffic control policy etc. > >> > >> > >> > >> It really isn=E2=80=99t relevant, but I have to ask=E2=80=A6. How = does the presence of a prefix associated with a passive interface allow = you to make this deduction? > >> > >> [WAJ] Passive interfaces are deployed mainly at the boundary of IGP = domain. Is there any other exception? > >> > >> While passive interfaces are not standardized, there is nothing = that limits their usage to an IGP boundary. They can and are deployed on = any interface where adjacencies are not to be formed (e.g., a stub = subnet containing hosts). > >> > >> > >> > >> Thanks, > >> Acee > >> > >> > >> > >> Thanks, > >> > >> Acee > >> > >> > >> > >> Thanks, > >> > >> Acee > >> > >> > >> > >> On 9/29/20, 10:39 PM, "Aijun Wang" = wrote: > >> > >> > >> > >> Hi, Acee and Peter: > >> > >> Passive interface is mainly used at the edge of the network, = where the unnumbered interface will not be used. > >> > >> And the information to flag the passive interfaces is for = positioning the area boundary, not conflict with the abstract = capabilities of the area inside. > >> > >> > >> > >> > >> > >> Best Regards > >> > >> > >> > >> Aijun Wang > >> > >> China Telecom > >> > >> > >> > >> -----Original Message----- > >> > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On=20 > >> Behalf Of Acee Lindem (acee) > >> > >> Sent: Tuesday, September 29, 2020 9:16 PM > >> > >> To: Peter Psenak ; Aijun=20 > >> Wang ; 'Aijun Wang'=20 > >> > >> > >> Cc: lsr@ietf.org > >> > >> Subject: Re: [Lsr] FW: New Version Notification for=20 > >> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > >> > >> Speaking as WG member: > >> > >> > >> > >> Hi Aijun, Peter, > >> > >> I agree with Peter - one of the main motivations for having = areas is to abstract the topology within the area. Now you're trying to = supplant this - one topological detail at a time with ill-conceived IGP = features. > >> > >> Thanks, > >> > >> Acee > >> > >> > >> > >> On 9/29/20, 5:15 AM, "Lsr on behalf of Peter Psenak" = = wrote: > >> > >> > >> > >> Hi Aijun, > >> > >> > >> > >> On 29/09/2020 11:07, Aijun Wang wrote: > >> > >> > Hi, Peter: > >> > >> > > >> > >> > Thanks for your comments. > >> > >> > 1. For BGP-LS deployment, there normally only be one=20 > >> router that within the > >> > >> > IGP domain to report the topology information, this=20 > >> router should know such > >> > >> > passive links which exists mainly on other border routers = > >> via the IGP > >> > >> > protocol. This is main reason to extension the IGP=20 > >> protocol. > 2. For the solution, normally, the link within the IGP=20 > >> connect two > >> > >> ends, but > >> > >> > passive interface is special and not fall in this space.=20 > >> We have studied the > >> > >> > current TLVs that for link, and find no suitable=20 > >> container to append this > >> > >> > information. This is the reason that we select the TLVs=20 > >> that associated with > >> > >> > Prefix. > >> > >> > >> > >> if the link is unnumbered, your solution does not work. As=20 > >> I said, if > >> > >> you need a knowledge about the link, you can not advertise = it as a prefix. > >> > >> > >> > >> thanks, > >> > >> Peter > >> > >> > >> > >> > >> > >> > > >> > >> >>From other POV, the OSPFv3 defines now the=20 > >> "Intra-Area-Prefix LSA", which > >> > >> > isolate the prefix information that associated with link=20 > >> into this > >> > >> > container, contains the stub link, local interface=20 > >> information etc. Put such > >> > >> > attribute along with the prefix is then acceptable? > >> > >> > > >> > >> > > >> > >> > Best Regards > >> > >> > > >> > >> > Aijun Wang > >> > >> > China Telecom > >> > >> > > >> > >> > -----Original Message----- > >> > >> > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org]=20 > >> On Behalf Of Peter > >> > >> > Psenak > >> > >> > Sent: Tuesday, September 29, 2020 4:29 PM > >> > >> > To: Aijun Wang > >> > >> > Cc: lsr@ietf.org > >> > >> > Subject: Re: [Lsr] FW: New Version Notification for > >> > >> > draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> > > >> > >> > Hi Aijun, > >> > >> > > >> > >> > here's my comments: > >> > >> > > >> > >> > The purpose of this draft is to advertise passive links. > >> > >> > > >> > >> > 1. I'm not sure the problem needs to be solved by IGPs. I = > >> tend to believe > >> > >> > ietf-idr-bgpls-inter-as-topology-ext is sufficient. > >> > >> > > >> > >> > 2. the solution that you proposed is wrong. You are=20 > >> trying to derive > >> > >> > topological data about the passive links from the prefix = advertisement. > >> > >> > This is semantically incorrect and only works under very = specific condition. > >> > >> > If you need to advertise a link, advertise it as a = "special" > >> > >> > link, not as a "special" prefix. > >> > >> > > >> > >> > thanks, > >> > >> > Peter > >> > >> > > >> > >> > On 29/09/2020 03:17, Aijun Wang wrote: > >> > >> >> Hi, Peter: > >> > >> >> > >> > >> >> Would you like to review and give comments on the=20 > >> updates version of this > >> > >> > draft? > >> > >> >> We have also added the protocol extension proposal for = OSPFv3. > >> > >> >> > >> > >> >> The update version of this draft can refer to > >> > >> >> > >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interf > >> ac > >> e > >> > >> >> -attribute > >> > >> >> Thanks in advance. > >> > >> >> > >> > >> >> > >> > >> >> Best Regards > >> > >> >> > >> > >> >> Aijun Wang > >> > >> >> China Telecom > >> > >> >> > >> > >> >>> -----Original Message----- > >> > >> >>> From: internet-drafts@ietf.org=20 > >> [mailto:internet-drafts@ietf.org] > >> > >> >>> Sent: Monday, September 28, 2020 3:17 PM > >> > >> >>> To: Zhibo Hu ; Gyan Mishra > >> > >> >>> ; Aijun Wang=20 > >> ; > >> > >> >>> Gyan S. Mishra > >> > >> >>> Subject: New Version Notification for > >> > >> >>> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> >>> > >> > >> >>> > >> > >> >>> A new version of I-D, > >> > >> >>> draft-wang-lsr-passive-interface-attribute-04.txt > >> > >> >>> has been successfully submitted by Aijun Wang and=20 > >> posted to the IETF > >> > >> >>> repository. > >> > >> >>> > >> > >> >>> Name: = draft-wang-lsr-passive-interface-attribute > >> > >> >>> Revision: 04 > >> > >> >>> Title: Passive Interface Attribute > >> > >> >>> Document date: 2020-09-28 > >> > >> >>> Group: Individual Submission > >> > >> >>> Pages: 7 > >> > >> >>> URL: > >> > >> >>> = https://www.ietf.org/id/draft-wang-lsr-passive-interface-attribute-04. > >> > >> >>> txt > >> > >> >>> Status: > >> > >> >>> > >> https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-a > >> tt > >> > >> >>> r > >> > >> >>> ibute/ > >> > >> >>> Htmlized: > >> > >> >>> > >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-passive-interf > >> ac > >> > >> >>> e > >> > >> >>> -attribut > >> > >> >>> e > >> > >> >>> Htmlized: > >> > >> >>> > >> https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attrib > >> ut > >> > >> >>> e > >> > >> >>> -04 > >> > >> >>> Diff: > >> > >> >>> > >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-wang-lsr-passive-interface- > >> at > >> > >> >>> t > >> > >> >>> ribute-04 > >> > >> >>> > >> > >> >>> Abstract: > >> > >> >>> This document describes the mechanism that can be = used to > >> > >> >>> differentiate the passive interfaces from the = normal interfaces > >> > >> >>> within ISIS or OSPF domain. > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> Please note that it may take a couple of minutes from=20 > >> the time of > >> > >> >>> submission until the htmlized version and diff are=20 > >> available at > >> > >> > tools.ietf.org. > >> > >> >>> > >> > >> >>> The IETF Secretariat > >> > >> >>> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> > > >> > >> > _______________________________________________ > >> > >> > Lsr mailing list > >> > >> > Lsr@ietf.org > >> > >> > https://www.ietf.org/mailman/listinfo/lsr > >> > >> > > >> > >> > > >> > >> > > >> > >> > >> > >> _______________________________________________ > >> > >> Lsr mailing list > >> > >> Lsr@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/lsr > >> > >> > >> > >> _______________________________________________ > >> > >> Lsr mailing list > >> > >> Lsr@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/lsr > >> > >> > >> > >> > >> > >> _______________________________________________ > >> > >> Lsr mailing list > >> > >> Lsr@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/lsr > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > -- > > > > > > Gyan Mishra > > > > Network Solutions Architect > > > > M 301 502-1347 > > 13101 Columbia Pike > > Silver Spring, MD > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr From nobody Tue Oct 13 01:52:52 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4CE3A0DE1 for ; Tue, 13 Oct 2020 01:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3OR2XWUqQTv for ; Tue, 13 Oct 2020 01:52:49 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A363A0D05 for ; Tue, 13 Oct 2020 01:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13002; q=dns/txt; s=iport; t=1602579169; x=1603788769; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=M8E8kEcuhI0NRzgh6n8Kl3NedMgop9bDV1S+nCL/w60=; b=QtObfEhduRfHpdRfmNhdqNyDqJ4exfTM78k+qIvjTGpMyhIHziaP3jkf vD8aVZUebPKvibZwCTLZw3Bj4q6HcIxbAuWb4gQD/isG0g1q8KW+mOxtK 8bfeFdzChQsjiP6RuU07BRZvalZ+R2ArAOYbFSzkP3My4tQeQ3nUHVP0t M=; X-IPAS-Result: =?us-ascii?q?A0BZAwAwV4Vf/xbLJq1gHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DGlUBIBIshD2JAodpLooRkCyBaQsBAQEPGAsMBAEBhEoCghgmOBMCAwEBA?= =?us-ascii?q?QMCAwEBAQEFAQEBAgEGBG2FXAyFcgEBAQECAQEBIRU2CQIMBAsRBAEBAQICI?= =?us-ascii?q?wMCAiEGHwkIBgEMBgIBAYMiAYJLAw4gD6dIdoEyhVSCPg1igTwGgQ4qiSSEL?= =?us-ascii?q?YFBP4ERJ4JpPoIaQgEBAoEoARIBIYMXgmAEkAErCYJViQKbA1KCc4MVhWyMX?= =?us-ascii?q?YR/BQcDH4MVigiFGY8FkySKcYJsknCBayNncDMaCBsVO4JpUBkNjisXg06FF?= =?us-ascii?q?IVEPwMwAgE0AgYKAQEDCY5IAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,369,1596499200"; d="scan'208";a="27875997" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Oct 2020 08:52:44 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 09D8qh46015657; Tue, 13 Oct 2020 08:52:44 GMT To: "Dongjie (Jimmy)" , Ron Bonica , Yingzhen Qu , Gyan Mishra Cc: "lsr@ietf.org" , Jeff Tantsura References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> <34c223a132f748e0a802d538ccd073b0@huawei.com> From: Peter Psenak Message-ID: Date: Tue, 13 Oct 2020 10:52:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <34c223a132f748e0a802d538ccd073b0@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 08:52:51 -0000 Hi Jimmy, On 13/10/2020 10:02, Dongjie (Jimmy) wrote: > Hi Peter, > > Thanks for your reply. Please see further inline: > >> -----Original Message----- >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak >> Sent: Monday, October 12, 2020 4:39 PM >> To: Dongjie (Jimmy) ; Ron Bonica >> ; Yingzhen Qu ; Gyan >> Mishra >> Cc: lsr@ietf.org; Jeff Tantsura >> Subject: Re: [Lsr] FW: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> >> Hi Jimmy, >> >> On 10/10/2020 05:05, Dongjie (Jimmy) wrote: >>> Hi Peter, >>> >>> Thanks for your reply. It aligns with my understanding of FAD, which is just a >> set of constraints for path computation. Thus one Flex-Algo ID could be used >> with multiple different data planes. Is this understanding correct? >> >> correct. >> >>> >>> If so, my question is about the scenario below: >>> >>> A group of nodes in a network support FA-128, a sub-group of them bind >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. >> >> just to use the correct terminology, we should use "participate" instead of >> "support". > > Agree. > >> >>> When one node compute an SR path to a destination, can it compute the path >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the >> nodes >which bind FA-128 to IP address? If so, how could this node know the >> binding of FA to different data planes on other nodes? >> >> again, it is the participation problem. >> >> Nodes that participate in the SR Flex-algo 128 will advertise the participation >> using the SR-Algorithm Sub-TLV. Only these nodes will be used during the SR >> flex-algo computation for algo 128. >> >> Nodes that participate in IP flex-algo 128 will advertise the participation using >> the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP flex-algo >> computation for algo 128. > > Agree that if participation to Flex-Algo is advertised in a data plane specific manner, then path computation with Flex-Algo constraints could be done only using nodes which bind the Flex-Algo to the same data plane. it's per app, not per data plane, but yes, that is what the base flex-algo spec mandates. > > As Robert asked and you confirmed, this implies each data plane needs to be treated as an independent application of Flex-Algo. We have SR-Algorithm sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that Flex-Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. separately? yes, it needs to be advertised per app. We have SR specific algo participation, we need one for IP as proposed in Ron's draft. Regarding IPv4 vs IPv6, it's up to the authors whether they want to make the participation for IP flex-algo topology specific or topology independent, both could work. Here's the text from the base flerx-algo draft: 10.2. Advertisement of Node Participation for Other Applications This section describes considerations related to how other applications can advertise their participation in a specific Flex- Algorithm. Application-specific Flex-Algorithm participation advertisements MAY be topology specific or MAY be topology independent, depending on the application itself. Application-specific advertisement for Flex-Algorithm participation MUST be defined for each application and is outside of the scope of this document. thanks, Peter > > Best regards, > Jie > >> >> thanks, >> Peter >> >>> >>> Best regards, >>> Jie >>> >>>> -----Original Message----- >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak >>>> Sent: Friday, October 9, 2020 11:58 PM >>>> To: Dongjie (Jimmy) ; Ron Bonica >>>> ; Yingzhen Qu >>>> ; Gyan Mishra >>>> Cc: lsr@ietf.org; Jeff Tantsura >>>> Subject: Re: [Lsr] FW: New Version Notification for >>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>> >>>> Hi Jimmy, >>>> >>>> >>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: >>>>> Hi Ron, >>>>> >>>>> Thanks for explaining the difference between IP Flex-Algo and SR >>>>> Flex-algo. As >>>> you said, the major difference is the data plane. >>>>> >>>>> If my understanding is correct, for one Flex-Algo to be used >>>>> correctly, the set >>>> of nodes need to apply consistent constraints in computation, and >>>> bind the FAD to the same data plane. >>>>> >>>>> Is it possible that different nodes may use the same Flex-Algo with >>>>> different >>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with >>>> pure IP etc., or each Flex-Algo is always associated with only one >>>> data plane? In the former case, should the flex-algo definition also >>>> indicate the data plane(s) to be used with the flex-algo? >>>> >>>> let me respond to this query, as this is not specific to Ron's draft. >>>> >>>> FAD is data plane agnostic and is used by all of them. >>>> >>>> thanks, >>>> Peter >>>> >>>>> >>>>> Best regards, >>>>> Jie >>>>> >>>>>> -----Original Message----- >>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >>>>>> Sent: Sunday, October 4, 2020 4:34 AM >>>>>> To: Yingzhen Qu ; Peter Psenak >>>>>> ; Gyan Mishra >>>>>> Cc: lsr@ietf.org; Jeff Tantsura >>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>>> >>>>>> Hi Yingzhen, >>>>>> >>>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the >>>>>> following >>>> respects: >>>>>> >>>>>> - Links have IGP metrics, TE metrics, delay metrics and >>>>>> administrative colors >>>>>> - FADs define Flexible Algorithms >>>>>> >>>>>> More specifically, the FAD: >>>>>> >>>>>> - Indicates which metric type the Flexible Algorithm uses >>>>>> - Specifies constraints in terms of link colors that are included >>>>>> or excluded from the Flexible Algorithm. >>>>>> >>>>>> The significant difference between IP Flexible Algorithms and SR >>>>>> Flexible Algorithms is: >>>>>> >>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators >>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. >>>>>> >>>>>> So, IP Flexible Algorithms can be deployed in any IP network, even >>>>>> in the absence of SR. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> Juniper Business Use Only >>>>>> >>>>>> -----Original Message----- >>>>>> From: Yingzhen Qu >>>>>> Sent: Saturday, October 3, 2020 2:08 PM >>>>>> To: Peter Psenak ; Gyan Mishra >>>>>> ; Ron Bonica >>>>>> Cc: lsr@ietf.org; Jeff Tantsura >>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>>> >>>>>> [External Email. Be cautious of content] >>>>>> >>>>>> >>>>>> Hi Peter, >>>>>> >>>>>> Using flex-algo, a SRv6 locator can be associated with a single >>>>>> algo, which means an IPv6 or IPv4 address can also be associated >>>>>> with a single algo. So my understanding is Ron's proposal is making >>>>>> the >>>> configuration of flex-algo easier? >>>>>> Instead of using the exclude or include list you can configure a >>>>>> loopback address to a flex-algo directly? >>>>>> >>>>>> Thanks, >>>>>> Yingzhen >>>>>> >>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: >>>>>> >>>>>> Hi Yingzhen, >>>>>> >>>>>> On 02/10/2020 22:15, Yingzhen Qu wrote: >>>>>> > Hi Peter, >>>>>> > >>>>>> > My understanding of flex-algo is that for traffic destined >>>>>> to a prefix on a particular algo, it can only be routed on routers >>>>>> belong to that algo, which also means only routers in that algo >>>>>> calculates how to reach that prefix and install it into the routing >>>>>> table. It seems to me that using flex-algo (section 12 of the >>>>>> draft) it's possible to have a loopback address associated with >>>>>> only one algo, please correct me if I'm missing or misunderstood >> something. >>>>>> >>>>>> you are right. That is exactly what is being done for flex-algo with >>>>>> SRv6 - locator is associated with a single algo only. The proposal >> uses >>>>>> the same concept. >>>>>> >>>>>> thanks, >>>>>> Peter >>>>>> >>>>>> > >>>>>> > Thanks, >>>>>> > Yingzhen >>>>>> > >>>>>> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >>>>>> >>>>> ppsenak=40cisco.com@dmarc.ietf.org> >>>>>> wrote: >>>>>> > >>>>>> > Gyan, >>>>>> > >>>>>> > On 02/10/2020 18:30, Gyan Mishra wrote: >>>>>> > > All, >>>>>> > > >>>>>> > > With SRv6 and IP based flex algo a generic question as it >>>> applies >>>>>> to >>>>>> > > both. Is it possible to have within a single IGP domain >>>> different >>>>>> sets >>>>>> > > of nodes or segments of the network running different >>>>>> algorithms. >>>>>> > >>>>>> > absolutely. >>>>>> > >>>>>> > > From >>>>>> > > both drafts it sounds like all nodes have to agree on >> same >>>>>> algorithm >>>>>> > > similar to concept of metric and reference bandwidth >> all >>>> have to >>>>>> have >>>>>> > > the same style metric and play to the same sheet of >> music. >>>>>> > >>>>>> > all participating nodes need to agree on the definition of >> the >>>>>> flex-algo >>>>>> > and advertise the participation. That's it. >>>>>> > >>>>>> > > If there was >>>>>> > > a way to use multiple algorithms simultaneously based >> on >>>> SFC >>>>>> or services >>>>>> > > and instantiation of specific algorithm based on service >> to >>>> be >>>>>> > > rendered. Doing so without causing a routing loop or >> sub >>>>>> optimal >>>>>> > > routing. >>>>>> > >>>>>> > you can certainly use multiple algorithms simultaneously >> and >>>> use >>>>>> algo >>>>>> > specific paths to forward specific traffic over it. How that >> is >>>> done >>>>>> > from the forwarding perspective depends in which >>>> forwarding >>>>>> plane you >>>>>> > use. Flex-algo control plane is independent of the >> forwarding >>>>>> plane. >>>>>> > >>>>>> > >>>>>> > >I thought with flex algo that there exists a feature that >> on >>>>>> > > each hop there is a way to specify which algo to use >> hop by >>>> hop >>>>>> similar >>>>>> > > to a hop by hop policy based routing. >>>>>> > >>>>>> > no, there is no hop-by-hop classification, that is >> problematic >>>> and >>>>>> does >>>>>> > not scale for high speeds. Classification is done at the >>>> ingress only. >>>>>> > >>>>>> > thanks, >>>>>> > Peter >>>>>> > >>>>>> > > >>>>>> > >>>>>> > >> _______________________________________________ >>>>>> > Lsr mailing list >>>>>> > Lsr@ietf.org >>>>>> > >>>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl >>>>>> oo >>>>>> k.com/ >>>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data >>>>>> = >>>> 0 >>>>>> 2 >>>>>> >>>> >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 >>>>>> >>>> >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >>>>>> >>>> >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D >>>>>> >>>> >> &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR >>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ >>>>>> > >>>>>> > >>>>>> > >>>>>> >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > From nobody Tue Oct 13 04:34:59 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781073A0DEC for ; Tue, 13 Oct 2020 04:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 SZukighp7rrD for ; Tue, 13 Oct 2020 04:34:54 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80104.outbound.protection.outlook.com [40.107.8.104]) (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 6538B3A0F61 for ; Tue, 13 Oct 2020 04:34:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TBHYE7IQaYnCH/tT1P1MKiXGro1UZarvWeOtFMAGZkET2fEXZ1jQLaRHDVCBoOYnZWJpSR4ZWrk1OvZVZjNwysAK3tH6BG8fzvRshQI32zsQ2enuLfDJhNYSYcDIisgNXFf/dT6TS5utSbmh+5YHge4y/xllOg5F1f7qXogNaCvaa7/XplmLf27bmg/Z7Qm1gDCX44SEVgUdXPhWxrDrjw73yuFiw5fiMtHuVJq4hi+OKPvE/uPWc43P0vSu6nBtaF8zJgxa75DOhRVHB3UPsQrW/ZRI3+57YR94YB8qpmUEBzvJbvr59UNiQKuuUZm0VfhXR11egEFaNhhSdJWnBw== 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=GUIFqlZUCcnvEsH3iqUCRRA1//Xf24LSOVr/s0e/cZM=; b=l72oZYnf7MjvxY+WtE70uAQsfcz1k6hVhB/mjmw3LV9nOijZBUB0yNelIb75khLBDKWrB+TbfTGmhAPAJifPuZToWXG/xyPOYWucmpw0SaOC/rJ0Jg1CfG6r2IABxE089xZs3iN7qe1g9v6ylE7AW4uDjBp+3RZWDgsyxkjFi8tlNPwcgnR7Bf8IekM3tdrijvREkX4nGo9dVOJ6ZX3iWsfvc1zFk1OJ8KvZAxwbNLroDsUIyGN1PlhaVZDewaSKKXDeu5Hmn95OVPxXFjBQP5i/4kLr9NJLIROCafdmzn3lCCszrfnoQZ3HAfDME2JLagY9WkJa2QKOyW59HI05VA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GUIFqlZUCcnvEsH3iqUCRRA1//Xf24LSOVr/s0e/cZM=; b=NjvB9wdbGiAfvvZ2L9wDNWnmpy8SCZDJePuHXjUD0HaRRUVpSvK21EFaxgtgDAdoiskhDSs626Kwx7N2A2zUockOzNEBvKvOGZB3X/N0fiPkzgp9ajEh98wMV5+hT8+rCoOS6vsJP8VRTWZgqUt5RVfje5nhcwLISPxvC/eDfQE= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB5720.eurprd07.prod.outlook.com (2603:10a6:20b:93::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Tue, 13 Oct 2020 11:34:49 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804%7]) with mapi id 15.20.3477.018; Tue, 13 Oct 2020 11:34:49 +0000 From: tom petch To: "tony.li@tony.li" , "Acee Lindem (acee)" CC: "lsr@ietf.org" Thread-Topic: [Lsr] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt Thread-Index: AQHWi3nsjeBx0nOhLk6id8R9+t4XAalqNEYAgCtXKYI= Date: Tue, 13 Oct 2020 11:34:49 +0000 Message-ID: References: <83C65E45-521B-4AD4-A735-E3925A6B2ED9@cisco.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tony.li; dkim=none (message not signed) header.d=none;tony.li; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 689bb0d6-0b75-4ce2-ff16-08d86f6bfe6f x-ms-traffictypediagnostic: AM6PR07MB5720: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JUCf+fvQcGffHBlLrBAMr/vZ7XpgqTtkDlQUaonsD7HWEsQUirfZnU9X6zRnKUBSHjEzhfUXzj91kS864AEOhVVBraVPswvEqgir6Fqr6LpjyIc8D7lIXZ8o71b7FkY2SRGQ1guhRfcef3baon+OElQzI2bu2gCXcMT9V2K71pl7dIT35zq6dueGYr8KfCDbDDJAy4AXKL9YACWLyoKec+07jDLf2/92kpCe/GquxubRUi+aDJ7ZTwKIqfZXIrbNd7FoHG2SZChz51i+KBRxw9yXWRh/dQXmWrXqAzKAvnEvV/qufgbTFV4b+qvRikerVbA7xmO8q48Unw8bG0y6URNNQovwcVenWy+vppn/X03XkRhiJBCkUTcRiBYh3+lGZUcZopEyXcbafWzx6bGnNQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(396003)(366004)(376002)(39860400002)(8676002)(4326008)(91956017)(76116006)(64756008)(66476007)(66446008)(66556008)(66946007)(2906002)(52536014)(8936002)(83380400001)(110136005)(5660300002)(66574015)(316002)(33656002)(186003)(966005)(478600001)(55016002)(7696005)(26005)(9686003)(86362001)(83080400001)(71200400001)(6506007)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: N7o6FUJxherpFnZu0SHFxtlqfQpr119okerl+DSSUfR4UCu1WkFEe6pyPO986R2OjDHRRF0cw5SIclabVlECqmQQY/xBgC5Q66X7FDlyBy1nhhnmivqT1zkJLUI6D+JbxAYFu47zYhbUzU59cyvDAaU4cTuoO8KmlvbzK7MJrK+nKFO+q+bMXcqtnHjviqJ/ndBdPUKM/8b2R/ys2U0Ka33159VaYUWqTFFv3l79rbuPXaFPef97cg7BlxbGWJbufQvfmGlSm225veYWc4qiI7wdf1jvFWtVJFgGsVP9gVODHPzuIoqw90pIuj7pEieY58e518CaQ+OCMTBBtKzxxb6lorcR8Y4J51n+a7hGXbzcdZe0eWIu+Mt5Vh6BWBMtoH0oASa8FMS1rSHaIzEOXa/AdVzFHNCy8XjoFKr3NS3EesRBgfjsHJMxk9bhp2lUmA0xh5s8r3tZ7AcJeioF2BrlIUpmvEcK+z+vTEvoMIlEA2xCUPYO5lAOEHvExaj5cGwHNd+DnMKe6kT0fzO31gAhGbEd/44nmUK7V4ppmXRuf1ni6gc7h2Sj+W/swYT4uiqdiZI+IH2dCmL5dxbiok/0V5XjmPlJ9eyXFwz630YBHKyRRwfJE7pY4eWij11VH83hdw+2g7q7njJuWIX57w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 689bb0d6-0b75-4ce2-ff16-08d86f6bfe6f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2020 11:34:49.3095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aHwaIqj3SXyG9wHJO4qJ59ugUfOu5gTC0OVEL1YCEsq9SO8XEv3fp4H3SEnf9hN+wc8TXEyfHxxs7Dvn27ktFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5720 Archived-At: Subject: Re: [Lsr] I-D Action: draft-dontula-lsr-yang-dynamic-flooding-03.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 11:34:58 -0000 RnJvbTogVG9ueSBMaSA8dG9ueTFhdGhvbWVAZ21haWwuY29tPiBvbiBiZWhhbGYgb2YgdG9ueS5s aUB0b255LmxpIDx0b255LmxpQHRvbnkubGk+ClNlbnQ6IDE1IFNlcHRlbWJlciAyMDIwIDIyOjE3 CgpPdXIgYXBvbG9naWVzLiAgV2XigJlyZSBvbiBpdC4KCjx0cD4KVGhhbmsgeW91LCAtMDQgaXMg bXVjaCBlYXNpZXIgdG8gZGlnZXN0IGFsdGhvdWdoIHBlcmhhcHMgbm90IGVhc3k6LSgKCkkgdGhp bmsgdGhhdCB0aGUgSS1EIG5lZWRzIHRvIGRlY2lkZSB3aGF0IHRvIGRvIHdpdGggT3BlbkNvbmZp ZyB3aGljaCBhcHBlYXJzIGEgbG90IGluIG9uZSBtb2R1bGUgYW5kIG1ha2VzIGl0IGhhcmQgdG8g cmVhZC4gIElmIHRoaXMgaXMgZ29pbmcgdG8gYmUgYW4gSUVURiBtb2R1bGUsIHRoZW4gSSB0aGlu ayB0aGF0IGl0IGFsbCBoYXMgdG8gZ28sIHBlcmhhcHMgdmlhIGFuIGFwcGVuZGl4IHdoaWxlIHRo ZSBJLUQgaXMgdW5kZXIgZGV2ZWxvcG1lbnQuCgpUaGUgbGFjayBvZiB0ZXh0IG1ha2VzIGl0IGhh cmQgdG8ga25vdyB3aGF0IGlzIGludGVuZGVkLiAgSSByZXZlcnNlIGVuZ2luZWVyIHRoZSBZQU5H IHRvIGZpbmQgb3V0IHdoYXQgaXQgaXMgbWVhbnQgdG8gZG8gYW5kIGxvIGFuZCBiZWhvbGQgdGhl IFlBTkcgZG9lcyBqdXN0IHRoYXQuICBJIHRoaW5rIHRoYXQgdGhlIGJhc2UgT1NQRiBZQU5HIG1v ZHVsZSBnZXRzIGl0IGp1c3QgcmlnaHQgd2l0aCBpdHMgbWl4IG9mIHRleHQgYW5kIHRyZWUgZGlh Z3JhbSwgc28gSSBjYW4gc2VlIHdoYXQgaXQgaXMgdHJ5aW5nIHRvIGRvLCBzZWUgYXQgYSBoaWdo IGxldmVsIGFuZCB0aGVuIGdvIHRvIHRoZSBkZXRhaWwgb2YgdGhlIFlBTkcuICBTZXZlcmFsIG90 aGVyIHJvdXRpbmcgYXJlYSBJLUQgYXJlIHNpbWlsYXIgYWx0aG91Z2ggYnkgbm8gbWVhbnMgYWxs LgoKQWxzbyB0aGUgbGFjayBvZiByZWZlcmVuY2VzLCBvciB0aGUgbWluaW1hbCBkZXNjcmlwdGlv bnMsIG9yIGJvdGggbWFrZSBpdCBoYXJkIHRvIGZvbGxvdy4gc28gYWxnb3JpdGhtIGlzIHVpbnQ4 LCBjb25uZWN0aW9uIHR5cGUgaXMgdWludDgsIHdoYXQgaXMgYW4gSUQgaW4gbnVtYmVyIG9mIElE cz8sIGluZGV4IGlzIHVpbnQxNiwgcHJpb3JpdHkgaXMgdWludDggYnV0IHdoYXQgaXMgaGlnaCB3 aGF0IGxvdz8gYW5kIHNvIG9uLiAgSSBzaG91bGQgbm90IG5lZWQgdG8ga25vdyBsc3ItZHluYW1p Yy1mbG9vZGluZyBvZmYgYnkgaGVhcnQgaW4gb3JkZXIgdG8gbWFrZSBzZW5zZSBvZiB0aGlzLgoK QW5kCi0gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgaXMgcGxhaW4gd3Jvbmc7IGdvIHJlYWQgWUFO RyBHdWlkZWxpbmVzOi0pCi0gSUFOQSBDb25zaWRlcmF0aW9ucyBkaXR0bwotIFhYWFggaXMgdXNl ZCBhcyBhIHBsYWNlaG9sZGVyIGZvciB0d28gZGlmZmVyZW50IEktRAotICBpZXRmLW9zcGYtZHlu Zmxvb2Qgd291bGQgYmUgY29uc2lzdGVudCBhbmQgbGVzcyBlcnJvciBwcm9uZSBJTUhPCi0gUkZD Njk5MSwgUkZDODM0OSBuZWVkIHRvIGJlIE5vcm1hdGl2ZSByZWZlcmVuY2VzCi0gSW50cm9kdWN0 aW9uIHNob3VsZCByZWZlcmVuY2UgT1NQRnYzCi0gb2JqZWN0cyBhbmQgaWRlbnRpdGllcyByZWxh dGluZyB0byBUTFYgbmVlZCByZWZlcmVuY2VzIC0gdGhleSBhcmUgZXZlciBoYXJkZXIgdG8gZmlu ZCBpbiB0aGUgSUVURiBsaXRlcmF0dXJlCi0gb3NwZiBzaG91bGQgYmUgY2FwaXRhbGlzZWQsIExF RUYgcHJvYmFibHkgbm90Ci0gc2V2ZXJhbCBhYmJyZXZpYXRpb25zIG5lZWQgZXhwYW5kaW5nIG9u IGZpcnN0IHVzZSBwZXJoYXBzIGluIGEgdGVybWlub2xvZ3kgc2VjdGlvbjsgdXN1YWxseSB0aGVy ZSBpcyBvbmUgc3VjaCBmb3IgWUFORyB0ZXJtaW5vbG9neQotIEkgd29uZGVyIGlmIG9zcGYtZHlu YW1pYy1mbG9vZGluZyB3b3VsZCBiZSBhIGJldHRlciBmZWF0dXJlIG5hbWUgZ2l2ZW4gdGhlcmUg YXJlIHRoZSB0d28gb2YgdGhlbSBzaWRlLWJ5LXNpZGUKClRvbSBQZXRjaAoKCgpUb255CgoKPiBP biBTZXAgMTUsIDIwMjAsIGF0IDk6MDQgQU0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZT00MGNp c2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6Cj4KPiBJdCBsb29rcyBsaWtlIHNvbWUgdW5m b3J0dW5hdGUgdGFiIHNldHRpbmdzIGF0IGxlYXN0IGZvciB0aGUgT1NQRiBtb2RlbC4uLiAgTm90 ZSB0aGF0IHB5YW5nIGNhbiBiZSB1c2VkIGZvciBmb3JtYXR0aW5nLgo+Cj4gcHlhbmcgLWYgeWFu ZyA8bW9kZWwtZmlsZT4gLS15YW5nLWxpbmUtbGVuZ3RoIDY4Cj4KPiDvu79PbiA5LzE1LzIwLCAx MTo0NyBBTSwgIkxzciBvbiBiZWhhbGYgb2YgdG9tIHBldGNoIiA8bHNyLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGlldGZjQGJ0Y29ubmVjdC5jb20+IHdyb3RlOgo+Cj4gICAgVGhlIGZv cm1hdHRpbmcgb2YgdGhpcyBJLUQgc2VlbXMgdG8gaGF2ZSBnb25lIHdyb25nIG1ha2luZyBpdCBo YXJkIHRvIHJlYWQgYW5kIHJldmlldy4gIFRoZSBpbmRlbnRhdGlvbiBvZiBzdWNjZXNzaXZlIGxp bmVzIG9mIHRoZSBZQU5HIG1vZHVsZSBpcyBtb3JlIHRoYW4gaXQgdXN1YWxseSBpcy4gIFRoaXMg d2FzIGEgcHJvYmxlbSB3aXRoIC0wMSB0aGF0IHdhcyBub3QgcHJlc2VudCBpbiAtMDIgYnV0IGhh cyBub3cgcmV0dXJuZWQgaW4gLTAzCj4KPiAgICBUb20gUGV0Y2gKPgo+ICAgIEZyb206IEktRC1B bm5vdW5jZSA8aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4KPiAgICBTZW50 OiAxNCBTZXB0ZW1iZXIgMjAyMCAyMjoxNQo+ICAgIFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcK PiAgICBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1kb250dWxhLWxzci15YW5nLWR5bmFtaWMt Zmxvb2RpbmctMDMudHh0Cj4KPgo+ICAgIEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4KPgo+Cj4gICAg ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBZQU5HIERhdGEgTW9kZWwgZm9yIER5bmFtaWMgRmxv b2RpbmcKPiAgICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFNyaW5hdGggRG9udHVsYQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVG9ueSBMaQo+ICAgICAgICAgICAgRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtZG9udHVsYS1sc3IteWFuZy1keW5hbWljLWZsb29kaW5nLTAzLnR4dAo+ ICAgICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMjYKPiAgICAgICAgICAgIERhdGUgICAgICAg ICAgICA6IDIwMjAtMDktMTQKPgo+ICAgIEFic3RyYWN0Ogo+ICAgICAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5zIFlBTkcgZGF0YSBtb2RlbHMgdGhhdCBjYW4gYmUgdXNlZCB0byBjb25maWd1cmUKPiAg ICAgICBhbmQgbWFuYWdlIER5bmFtaWMgRmxvb2RpbmcgZm9yIElTLUlTIGFuZCBPU1BGLgo+Cj4K PiAgICBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoK PiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kb250dWxhLWxzci15 YW5nLWR5bmFtaWMtZmxvb2RpbmcvCj4KPiAgICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJz aW9ucyBhdmFpbGFibGUgYXQ6Cj4gICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWRvbnR1bGEtbHNyLXlhbmctZHluYW1pYy1mbG9vZGluZy0wMwo+ICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZG9udHVsYS1sc3IteWFuZy1keW5hbWljLWZs b29kaW5nLTAzCj4KPiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6Cj4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWRv bnR1bGEtbHNyLXlhbmctZHluYW1pYy1mbG9vZGluZy0wMwo+Cj4KPiAgICBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uCj4gICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4KPgo+ICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoKPiAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLwo+Cj4KPiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+ICAgIEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QKPiAgICBJLUQtQW5u b3VuY2VAaWV0Zi5vcmcKPiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ktZC1hbm5vdW5jZQo+ICAgIEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sCj4gICAgb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNo YWRvdy1zaXRlcy50eHQKPgo+ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gICAgTHNyIG1haWxpbmcgbGlzdAo+ICAgIExzckBpZXRmLm9yZwo+ICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyCj4KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IExzciBtYWlsaW5nIGxpc3QK PiBMc3JAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xz cgoK From nobody Tue Oct 13 04:38:22 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77FA3A0F61 for ; Tue, 13 Oct 2020 04:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=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 (2048-bit key) header.d=raszuk.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 azRUD-QJ67XF for ; Tue, 13 Oct 2020 04:38:18 -0700 (PDT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 85EEC3A0B2E for ; Tue, 13 Oct 2020 04:38:17 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id md26so27750433ejb.10 for ; Tue, 13 Oct 2020 04:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hd4foOdD1riBttrO2huN3+3WVS8Xd/cVXssIm9/Brd8=; b=NjaIFyaNbpE7wi8CympDHBWQhKx2iEu7LwNXq4wb/cQUaPR+DTfNnhSSKnR+c4nvkS GU0I4CRffyPl5nkMxPF17QIAEYtf0zkOuDAZ/8OVGjNuhPdadBbIsOIni5p2c0WertNR 8qzvaK+/rZjUnjGTpzJ8AxqwshoqKGjLZOsLmqxWcqLFflJjxpe9idd0nJi6wnwxYaqH EEUb4ZCwXlYq5wwwgRS2A/hpvdLZu4hyE4eav3NUw0FmgNEimy7liQMxIMucp3CuzzDD 9uPXDnEsG5lidGJUSLAPOtj/UTeZfFNq0Ygkmff2f8s6It8hqb4eiiogZW4IFBDiLVrl +NMw== 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=hd4foOdD1riBttrO2huN3+3WVS8Xd/cVXssIm9/Brd8=; b=cIHDjEXHmPtgvpj/rjn/iY2Eu2ukC5oZkVIQYQ99C2E14Vfryf92oSiFGs2ffbf+Ym RwsEFG4oA8+nwd44uOW82C42ZW8Qo7nwQSjUZwgJ29EDbMsaWZkr7uGWXs3Nn3BRPMUV khOi06OmP+iISBp97ZgN5zfA8QFfukHhzxSJY8TwAFcQC2DQOq8fZ2JIpJDNRrJ3cMdX kyAGQz8O51AjaSPhzwNqt0Qxf++YqoiQkVBhJkGZrqBty21TclZJxvXPC3Kx26k1lQJG cxb4R0CBu2dJULY407ktUIvmjpVZewyY/NQpEMY55xKXIvOPEK5t2FVJ1c0iaZPSp4KJ c/5A== X-Gm-Message-State: AOAM533gWUs7MkAAoWb3ujzOR0YGVwuxawoiwNfnKWpYbvNmAf+9i3AQ BD97HP1gQpq7a+Oz1vAwgI2DWVr02YfAFt1VEnuI0Q== X-Google-Smtp-Source: ABdhPJzbiIzTlITNixAF5+WPVv8Kc0Stv0rwvWJlFwHmJhQNc3FcZiV2OafYkh+yA99xdv3wuARK/z37+yIITeHoouI= X-Received: by 2002:a17:906:d964:: with SMTP id rp4mr5589291ejb.110.1602589095687; Tue, 13 Oct 2020 04:38:15 -0700 (PDT) MIME-Version: 1.0 References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> <34c223a132f748e0a802d538ccd073b0@huawei.com> In-Reply-To: From: Robert Raszuk Date: Tue, 13 Oct 2020 13:38:05 +0200 Message-ID: To: Peter Psenak Cc: "Dongjie (Jimmy)" , Ron Bonica , Yingzhen Qu , Gyan Mishra , "lsr@ietf.org" , Jeff Tantsura Content-Type: multipart/alternative; boundary="000000000000c51a8905b18bd91b" Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 11:38:21 -0000 --000000000000c51a8905b18bd91b Content-Type: text/plain; charset="UTF-8" Peter, If this is per app how are the constraints shared across apps ? See we have single physical resources (for example links) and single interface outbound queues. If I use per app flex-algo and do not have central controller how is this going to work in practice for any network which attempts to use more then one forwarding schema with dynamic constraints ? Many thx, R. On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak wrote: > Hi Jimmy, > > On 13/10/2020 10:02, Dongjie (Jimmy) wrote: > > Hi Peter, > > > > Thanks for your reply. Please see further inline: > > > >> -----Original Message----- > >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > >> Sent: Monday, October 12, 2020 4:39 PM > >> To: Dongjie (Jimmy) ; Ron Bonica > >> ; Yingzhen Qu ; Gyan > >> Mishra > >> Cc: lsr@ietf.org; Jeff Tantsura > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> Hi Jimmy, > >> > >> On 10/10/2020 05:05, Dongjie (Jimmy) wrote: > >>> Hi Peter, > >>> > >>> Thanks for your reply. It aligns with my understanding of FAD, which > is just a > >> set of constraints for path computation. Thus one Flex-Algo ID could be > used > >> with multiple different data planes. Is this understanding correct? > >> > >> correct. > >> > >>> > >>> If so, my question is about the scenario below: > >>> > >>> A group of nodes in a network support FA-128, a sub-group of them bind > >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP address. > >> > >> just to use the correct terminology, we should use "participate" > instead of > >> "support". > > > > Agree. > > > >> > >>> When one node compute an SR path to a destination, can it compute the > path > >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the > >> nodes >which bind FA-128 to IP address? If so, how could this node know > the > >> binding of FA to different data planes on other nodes? > >> > >> again, it is the participation problem. > >> > >> Nodes that participate in the SR Flex-algo 128 will advertise the > participation > >> using the SR-Algorithm Sub-TLV. Only these nodes will be used during > the SR > >> flex-algo computation for algo 128. > >> > >> Nodes that participate in IP flex-algo 128 will advertise the > participation using > >> the IGP Algorithm Sub-TLV. Only these nodes will be used during the IP > flex-algo > >> computation for algo 128. > > > > Agree that if participation to Flex-Algo is advertised in a data plane > specific manner, then path computation with Flex-Algo constraints could be > done only using nodes which bind the Flex-Algo to the same data plane. > > it's per app, not per data plane, but yes, that is what the base > flex-algo spec mandates. > > > > > As Robert asked and you confirmed, this implies each data plane needs to > be treated as an independent application of Flex-Algo. We have SR-Algorithm > sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes > to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that > Flex-Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4, > IPv6, etc. separately? > > yes, it needs to be advertised per app. We have SR specific algo > participation, we need one for IP as proposed in Ron's draft. > > Regarding IPv4 vs IPv6, it's up to the authors whether they want to make > the participation for IP flex-algo topology specific or topology > independent, both could work. > > Here's the text from the base flerx-algo draft: > > 10.2. Advertisement of Node Participation for Other Applications > > This section describes considerations related to how other > applications can advertise their participation in a specific Flex- > Algorithm. > > Application-specific Flex-Algorithm participation advertisements MAY > be topology specific or MAY be topology independent, depending on the > application itself. > > Application-specific advertisement for Flex-Algorithm participation > MUST be defined for each application and is outside of the scope of > this document. > > thanks, > Peter > > > > > > Best regards, > > Jie > > > >> > >> thanks, > >> Peter > >> > >>> > >>> Best regards, > >>> Jie > >>> > >>>> -----Original Message----- > >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak > >>>> Sent: Friday, October 9, 2020 11:58 PM > >>>> To: Dongjie (Jimmy) ; Ron Bonica > >>>> ; Yingzhen Qu > >>>> ; Gyan Mishra > >>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>> > >>>> Hi Jimmy, > >>>> > >>>> > >>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > >>>>> Hi Ron, > >>>>> > >>>>> Thanks for explaining the difference between IP Flex-Algo and SR > >>>>> Flex-algo. As > >>>> you said, the major difference is the data plane. > >>>>> > >>>>> If my understanding is correct, for one Flex-Algo to be used > >>>>> correctly, the set > >>>> of nodes need to apply consistent constraints in computation, and > >>>> bind the FAD to the same data plane. > >>>>> > >>>>> Is it possible that different nodes may use the same Flex-Algo with > >>>>> different > >>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with > >>>> pure IP etc., or each Flex-Algo is always associated with only one > >>>> data plane? In the former case, should the flex-algo definition also > >>>> indicate the data plane(s) to be used with the flex-algo? > >>>> > >>>> let me respond to this query, as this is not specific to Ron's draft. > >>>> > >>>> FAD is data plane agnostic and is used by all of them. > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>>> > >>>>> Best regards, > >>>>> Jie > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica > >>>>>> Sent: Sunday, October 4, 2020 4:34 AM > >>>>>> To: Yingzhen Qu ; Peter Psenak > >>>>>> ; Gyan Mishra > >>>>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> Hi Yingzhen, > >>>>>> > >>>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the > >>>>>> following > >>>> respects: > >>>>>> > >>>>>> - Links have IGP metrics, TE metrics, delay metrics and > >>>>>> administrative colors > >>>>>> - FADs define Flexible Algorithms > >>>>>> > >>>>>> More specifically, the FAD: > >>>>>> > >>>>>> - Indicates which metric type the Flexible Algorithm uses > >>>>>> - Specifies constraints in terms of link colors that are included > >>>>>> or excluded from the Flexible Algorithm. > >>>>>> > >>>>>> The significant difference between IP Flexible Algorithms and SR > >>>>>> Flexible Algorithms is: > >>>>>> > >>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 locators > >>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > >>>>>> > >>>>>> So, IP Flexible Algorithms can be deployed in any IP network, even > >>>>>> in the absence of SR. > >>>>>> > >>>>>> Ron > >>>>>> > >>>>>> > >>>>>> Juniper Business Use Only > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Yingzhen Qu > >>>>>> Sent: Saturday, October 3, 2020 2:08 PM > >>>>>> To: Peter Psenak ; Gyan Mishra > >>>>>> ; Ron Bonica > >>>>>> Cc: lsr@ietf.org; Jeff Tantsura > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> [External Email. Be cautious of content] > >>>>>> > >>>>>> > >>>>>> Hi Peter, > >>>>>> > >>>>>> Using flex-algo, a SRv6 locator can be associated with a single > >>>>>> algo, which means an IPv6 or IPv4 address can also be associated > >>>>>> with a single algo. So my understanding is Ron's proposal is making > >>>>>> the > >>>> configuration of flex-algo easier? > >>>>>> Instead of using the exclude or include list you can configure a > >>>>>> loopback address to a flex-algo directly? > >>>>>> > >>>>>> Thanks, > >>>>>> Yingzhen > >>>>>> > >>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: > >>>>>> > >>>>>> Hi Yingzhen, > >>>>>> > >>>>>> On 02/10/2020 22:15, Yingzhen Qu wrote: > >>>>>> > Hi Peter, > >>>>>> > > >>>>>> > My understanding of flex-algo is that for traffic destined > >>>>>> to a prefix on a particular algo, it can only be routed on routers > >>>>>> belong to that algo, which also means only routers in that algo > >>>>>> calculates how to reach that prefix and install it into the routing > >>>>>> table. It seems to me that using flex-algo (section 12 of the > >>>>>> draft) it's possible to have a loopback address associated with > >>>>>> only one algo, please correct me if I'm missing or misunderstood > >> something. > >>>>>> > >>>>>> you are right. That is exactly what is being done for > flex-algo with > >>>>>> SRv6 - locator is associated with a single algo only. The > proposal > >> uses > >>>>>> the same concept. > >>>>>> > >>>>>> thanks, > >>>>>> Peter > >>>>>> > >>>>>> > > >>>>>> > Thanks, > >>>>>> > Yingzhen > >>>>>> > > >>>>>> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > >>>>>> >>>>>> ppsenak=40cisco.com@dmarc.ietf.org> > >>>>>> wrote: > >>>>>> > > >>>>>> > Gyan, > >>>>>> > > >>>>>> > On 02/10/2020 18:30, Gyan Mishra wrote: > >>>>>> > > All, > >>>>>> > > > >>>>>> > > With SRv6 and IP based flex algo a generic question > as it > >>>> applies > >>>>>> to > >>>>>> > > both. Is it possible to have within a single IGP > domain > >>>> different > >>>>>> sets > >>>>>> > > of nodes or segments of the network running > different > >>>>>> algorithms. > >>>>>> > > >>>>>> > absolutely. > >>>>>> > > >>>>>> > > From > >>>>>> > > both drafts it sounds like all nodes have to agree > on > >> same > >>>>>> algorithm > >>>>>> > > similar to concept of metric and reference bandwidth > >> all > >>>> have to > >>>>>> have > >>>>>> > > the same style metric and play to the same sheet of > >> music. > >>>>>> > > >>>>>> > all participating nodes need to agree on the > definition of > >> the > >>>>>> flex-algo > >>>>>> > and advertise the participation. That's it. > >>>>>> > > >>>>>> > > If there was > >>>>>> > > a way to use multiple algorithms simultaneously > based > >> on > >>>> SFC > >>>>>> or services > >>>>>> > > and instantiation of specific algorithm based on > service > >> to > >>>> be > >>>>>> > > rendered. Doing so without causing a routing loop > or > >> sub > >>>>>> optimal > >>>>>> > > routing. > >>>>>> > > >>>>>> > you can certainly use multiple algorithms > simultaneously > >> and > >>>> use > >>>>>> algo > >>>>>> > specific paths to forward specific traffic over it. > How that > >> is > >>>> done > >>>>>> > from the forwarding perspective depends in which > >>>> forwarding > >>>>>> plane you > >>>>>> > use. Flex-algo control plane is independent of the > >> forwarding > >>>>>> plane. > >>>>>> > > >>>>>> > > >>>>>> > >I thought with flex algo that there exists a feature > that > >> on > >>>>>> > > each hop there is a way to specify which algo to use > >> hop by > >>>> hop > >>>>>> similar > >>>>>> > > to a hop by hop policy based routing. > >>>>>> > > >>>>>> > no, there is no hop-by-hop classification, that is > >> problematic > >>>> and > >>>>>> does > >>>>>> > not scale for high speeds. Classification is done at > the > >>>> ingress only. > >>>>>> > > >>>>>> > thanks, > >>>>>> > Peter > >>>>>> > > >>>>>> > > > >>>>>> > > >>>>>> > > >> _______________________________________________ > >>>>>> > Lsr mailing list > >>>>>> > Lsr@ietf.org > >>>>>> > > >>>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.outl > >>>>>> oo > >>>>>> k.com/ > >>>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&data > >>>>>> = > >>>> 0 > >>>>>> 2 > >>>>>> > >>>> > >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 > >>>>>> > >>>> > >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >>>>>> > >>>> > >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >>>>>> > >>>> > >> &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR > >>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Lsr mailing list > >>>>>> Lsr@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lsr > >>> > >>> > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --000000000000c51a8905b18bd91b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peter,

If this is per app how are the c= onstraints=C2=A0shared across apps ?=C2=A0

See we = have single physical resources (for example links) and single interface out= bound queues. If I use per app flex-algo and=C2=A0do not have central contr= oller how is this going to work in practice for any network which attempts = to use more then one forwarding schema with dynamic constraints ?=C2=A0

Many thx,
R.


<= /div>

On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak <ppsenak=3D40cisco.com@dmarc.ietf.org> wrot= e:
Hi Jimmy,

On 13/10/2020 10:02, Dongjie (Jimmy) wrote:
> Hi Peter,
>
> Thanks for your reply. Please see further inline:
>
>> -----Original Message-----
>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
>> Sent: Monday, October 12, 2020 4:39 PM
>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Ron Bonica
>> <rboni= ca@juniper.net>; Yingzhen Qu <yingzhen.qu@futurewei.com>; Gyan
>> Mishra <hayabusagsm@gmail.com>
>> Cc: lsr@ietf.org= ; Jeff Tantsura <jefftant.ietf@gmail.com>
>> Subject: Re: [Lsr] FW: New Version Notification for
>> draft-bonica-lsr-ip-flexalgo-00.txt
>>
>> Hi Jimmy,
>>
>> On 10/10/2020 05:05, Dongjie (Jimmy) wrote:
>>> Hi Peter,
>>>
>>> Thanks for your reply. It aligns with my understanding of FAD,= which is just a
>> set of constraints for path computation. Thus one Flex-Algo ID cou= ld be used
>> with multiple different data planes. Is this understanding correct= ?
>>
>> correct.
>>
>>>
>>> If so, my question is about the scenario below:
>>>
>>> A group of nodes in a network support FA-128, a sub-group of t= hem bind
>> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP add= ress.
>>
>> just to use the correct terminology, we should use "participa= te" instead of
>> "support".
>
> Agree.
>
>>
>>> When one node compute an SR path to a destination, can it comp= ute the path
>> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the=
>> nodes >which bind FA-128 to IP address? If so, how could this n= ode know the
>> binding of FA to different data planes on other nodes?
>>
>> again, it is the participation problem.
>>
>> Nodes that participate in the SR Flex-algo 128 will advertise the = participation
>> using the SR-Algorithm Sub-TLV. Only these nodes will be used duri= ng the SR
>> flex-algo computation for algo 128.
>>
>> Nodes that participate in IP flex-algo 128 will advertise the part= icipation using
>> the IGP Algorithm Sub-TLV. Only these nodes will be used during th= e IP flex-algo
>> computation for algo 128.
>
> Agree that if participation to Flex-Algo is advertised in a data plane= specific manner, then path computation with Flex-Algo constraints could be= done only using nodes which bind the Flex-Algo to the same data plane.

it's per app, not per data plane, but yes, that is what the base
flex-algo spec mandates.

>
> As Robert asked and you confirmed, this implies each data plane needs = to be treated as an independent application of Flex-Algo. We have SR-Algori= thm sub-TLV and IP Algorithm sub-TLV, while there are actually more data pl= anes to be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that= Flex-Algo participation needs to be advertised for SR-MPLS, SRv6, IPv4, IP= v6, etc. separately?

yes, it needs to be advertised per app. We have SR specific algo
participation, we need one for IP as proposed in Ron's draft.

Regarding IPv4 vs IPv6, it's up to the authors whether they want to mak= e
the participation for IP flex-algo topology specific or topology
independent, both could work.

Here's the text from the base flerx-algo draft:

10.2.=C2=A0 Advertisement of Node Participation for Other Applications

=C2=A0 =C2=A0 This section describes considerations related to how other =C2=A0 =C2=A0 applications can advertise their participation in a specific = Flex-
=C2=A0 =C2=A0 Algorithm.

=C2=A0 =C2=A0 Application-specific Flex-Algorithm participation advertiseme= nts MAY
=C2=A0 =C2=A0 be topology specific or MAY be topology independent, dependin= g on the
=C2=A0 =C2=A0 application itself.

=C2=A0 =C2=A0 Application-specific advertisement for Flex-Algorithm partici= pation
=C2=A0 =C2=A0 MUST be defined for each application and is outside of the sc= ope of
=C2=A0 =C2=A0 this document.

thanks,
Peter


>
> Best regards,
> Jie
>
>>
>> thanks,
>> Peter
>>
>>>
>>> Best regards,
>>> Jie
>>>
>>>> -----Original Message-----
>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak
>>>> Sent: Friday, October 9, 2020 11:58 PM
>>>> To: Dongjie (Jimmy) <jie.dong@huawei.com>; Ron Bonica
>>>> <rbonica=3D40juniper.net@dmarc.ietf.org>; Yingzhen Qu
>>>> <yingzhen.qu@futurewei.com>; Gyan Mishra <hayabusagsm@gmail.com> >>>> Cc: lsr@= ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>> Subject: Re: [Lsr] FW: New Version Notification for
>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>
>>>> Hi Jimmy,
>>>>
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0On 09/10/2020 04:59, Dongjie (Jimmy) wr= ote:
>>>>> Hi Ron,
>>>>>
>>>>> Thanks for explaining the difference between IP Flex-A= lgo and SR
>>>>> Flex-algo. As
>>>> you said, the major difference is the data plane.
>>>>>
>>>>> If my understanding is correct, for one Flex-Algo to b= e used
>>>>> correctly, the set
>>>> of nodes need to apply consistent constraints in computati= on, and
>>>> bind the FAD to the same data plane.
>>>>>
>>>>> Is it possible that different nodes may use the same F= lex-Algo with
>>>>> different
>>>> data plane, e.g. some with SR-MPLS, some with SRv6, and so= me with
>>>> pure IP etc., or each Flex-Algo is always associated with = only one
>>>> data plane? In the former case, should the flex-algo defin= ition also
>>>> indicate the data plane(s) to be used with the flex-algo?<= br> >>>>
>>>> let me respond to this query, as this is not specific to R= on's draft.
>>>>
>>>> FAD is data plane agnostic and is used by all of them.
>>>>
>>>> thanks,
>>>> Peter
>>>>
>>>>>
>>>>> Best regards,
>>>>> Jie
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica=
>>>>>> Sent: Sunday, October 4, 2020 4:34 AM
>>>>>> To: Yingzhen Qu <yingzhen.qu@futurewei.com>; Peter P= senak
>>>>>> <ppsenak@cisco.com>; Gyan Mishra <hayabusagsm@gmail.com>
>>>>>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>>>> Subject: Re: [Lsr] FW: New Version Notification fo= r
>>>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>>
>>>>>> Hi Yingzhen,
>>>>>>
>>>>>> IP Flexible Algorithms are like SR Flexible Algori= thms in the
>>>>>> following
>>>> respects:
>>>>>>
>>>>>> - Links have IGP metrics, TE metrics, delay metric= s and
>>>>>> administrative colors
>>>>>> - FADs define Flexible Algorithms
>>>>>>
>>>>>> More specifically, the FAD:
>>>>>>
>>>>>> - Indicates which metric type the Flexible Algorit= hm uses
>>>>>> - Specifies constraints in terms of link colors th= at are included
>>>>>> or excluded from the Flexible Algorithm.
>>>>>>
>>>>>> The significant difference between IP Flexible Alg= orithms and SR
>>>>>> Flexible Algorithms is:
>>>>>>
>>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs = or SRv6 locators
>>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6= addresses.
>>>>>>
>>>>>> So, IP Flexible Algorithms can be deployed in any = IP network, even
>>>>>> in the absence of SR.
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ron
>>>>>>
>>>>>>
>>>>>> Juniper Business Use Only
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Yingzhen Qu <yingzhen.qu@futurewei.com>
>>>>>> Sent: Saturday, October 3, 2020 2:08 PM
>>>>>> To: Peter Psenak <ppsenak@cisco.com>; Gyan Mishra
>>>>>> <hayabusagsm@gmail.com>; Ron Bonica <rbonica@juniper.net>
>>>>>> Cc: lsr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>
>>>>>> Subject: Re: [Lsr] FW: New Version Notification fo= r
>>>>>> draft-bonica-lsr-ip-flexalgo-00.txt
>>>>>>
>>>>>> [External Email. Be cautious of content]
>>>>>>
>>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> Using flex-algo, a SRv6 locator can be associated = with a single
>>>>>> algo, which means an IPv6 or IPv4 address can also= be associated
>>>>>> with a single algo. So my understanding is Ron'= ;s proposal is making
>>>>>> the
>>>> configuration of flex-algo easier?
>>>>>> Instead of using the exclude or include list you c= an configure a
>>>>>> loopback address to a flex-algo directly?
>>>>>>
>>>>>> Thanks,
>>>>>> Yingzhen
>>>>>>
>>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" <= ppsenak@cisco.com> wrote:
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Yingzhen,
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 02/10/2020 22:15, Yi= ngzhen Qu wrote:
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Hi Peter,
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 > My understanding o= f flex-algo is that for traffic destined
>>>>>> to a prefix on a particular algo, it can only be r= outed on routers
>>>>>> belong to that algo, which also means only routers= in that algo
>>>>>> calculates how to reach that prefix and install it= into the routing
>>>>>> table. It seems to me that using flex-algo (sectio= n 12 of the
>>>>>> draft) it's possible to have a loopback addres= s associated with
>>>>>> only one algo, please correct me if I'm missin= g or misunderstood
>> something.
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 you are right. That is = exactly what is being done for flex-algo with
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 SRv6 - locator is assoc= iated with a single algo only. The proposal
>> uses
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the same concept.
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 thanks,
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Peter
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Thanks,
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Yingzhen
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 > On 10/2/20, 9:43 A= M, "Lsr on behalf of Peter Psenak"
>>>>>> <lsr-bounces@ietf.org on behalf of
>>>>>> ppsenak=3D40cisco.com@dmarc.ietf.org>
>>>>>> wrote:
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 Gyan,
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 On 02/10/2020 18:30, Gyan Mishra wrote:
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > All,
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > With SRv6 and IP based flex algo a generic question as it
>>>> applies
>>>>>> to
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > both. Is it possible to have within a single IGP domain
>>>> different
>>>>>> sets
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > of nodes or segments of the network running different
>>>>>> algorithms.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 absolutely.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > From
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > both drafts it sounds like all nodes have to agree on
>> same
>>>>>> algorithm
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > similar to concept of metric and reference bandwidth
>> all
>>>> have to
>>>>>> have
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > the same style metric and play to the same sheet of
>> music.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 all participating nodes need to agree on the definition of
>> the
>>>>>> flex-algo
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 and advertise the participation. That's it.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > If there was
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > a way to use multiple algorithms simultaneously based
>> on
>>>> SFC
>>>>>> or services
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > and instantiation of specific algorithm based on service
>> to
>>>> be
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > rendered.=C2=A0 Doing so without causing a routing loop or
>> sub
>>>>>> optimal
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > routing.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 you can certainly use multiple algorithms simultaneously
>> and
>>>> use
>>>>>> algo
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 specific paths to forward specific traffic over it. How that
>> is
>>>> done
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 from the forwarding perspective depends in which
>>>> forwarding
>>>>>> plane you
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 use. Flex-algo control plane is independent of the
>> forwarding
>>>>>> plane.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >I thought with flex algo that there exists a feature that
>> on
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > each hop there is a way to specify which algo to use
>> hop by
>>>> hop
>>>>>> similar
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 > to a hop by hop policy based routing.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 no, there is no hop-by-hop classification, that is
>> problematic
>>>> and
>>>>>> does
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 not scale for high speeds. Classification is done at the
>>>> ingress only.
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 thanks,
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 Peter
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>> _______________________________________________
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 Lsr mailing list
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0 Lsr@ietf.org
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>> https://= urldefense.com/v3/__https://nam11.safelinks.protection.outl
>>>>>> oo
>>>>>> k.com/
>>>>>> ?url=3Dhttps*3A*2F*2Fwww.ietf.org*2Fmailman*2Flist= info*2Flsr&amp;data
>>>>>> =3D
>>>> 0
>>>>>> 2
>>>>>>
>>>>
>> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d8678= 1
>>>>>>
>>>>
>> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >>>>>>
>>>>
>> 5126&amp;sdata=3DWI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g= *3D
>>>>>>
>>>>
>> &amp;reserved=3D0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln= 9MjimeJcR
>>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$=
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
>>>>>>
>>>>>> _______________________________________________ >>>>>> Lsr mailing list
>>>>>> = Lsr@ietf.org
>>>>>> https://www.ietf.org/mailman/listi= nfo/lsr
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> Lsr@ietf= .org
>>>> https://www.ietf.org/mailman/listinfo/lsr=
>>>
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org=
>> https://www.ietf.org/mailman/listinfo/lsr
>
>

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--000000000000c51a8905b18bd91b-- From nobody Tue Oct 13 04:55:03 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D24D3A0F73 for ; Tue, 13 Oct 2020 04:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH9LsOwDNPYm for ; Tue, 13 Oct 2020 04:55:00 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5D63A0F70 for ; Tue, 13 Oct 2020 04:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18740; q=dns/txt; s=iport; t=1602590099; x=1603799699; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wbqTaMGsPEqXLYMBnP8a8SJozgYNmPJi+6sMqjgiSYc=; b=h8+bL6+LCaoe/XarSkzem202KqtLe7ubfPA1LCVcPnv4VN7ZcxZiQOMc grZOB8BdF9jREoPJTCquL+Ao0XjPbaO4xhBD7NwOoYIZdhou4WepsBmUG tLhe2x6qZFUCK9tzwnj9fxG3XOWBlHLCYeGdlUZ73+0c6XoY4vg0ccLD1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSBQABlYVf/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DGlUBIBIshD2JAodpCCaKEZAsgWkLAQEBDxgLDAQBAYR?= =?us-ascii?q?KAoIDJjgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQIBAQEhDwEFNgkCDAQ?= =?us-ascii?q?JAhEEAQEBAgIjAwICIQYfCQgGDQYCAQGDIgGCSwMOIA+MXZsFdoEyhDsBgRi?= =?us-ascii?q?CRA1igUKBDiqHZoVrgUE/gREnDIJdPoIaQgEBAoEoARIBIYMXgmAEkAMrCYJ?= =?us-ascii?q?VAaNMOFKCc4MVhW2MXYR/BQcDH4MVgSqIXoUZjweeF4JshB6OU4FrI2dwMxo?= =?us-ascii?q?IGxU7gmkJRxkNgzqKcReDToUUhUQ/AzACATQCBgEJAQEDCY5IAQE?= X-IronPort-AV: E=Sophos;i="5.77,370,1596499200"; d="scan'208";a="30315489" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Oct 2020 11:54:55 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 09DBssIv024427; Tue, 13 Oct 2020 11:54:54 GMT To: Robert Raszuk Cc: "Dongjie (Jimmy)" , Ron Bonica , Yingzhen Qu , Gyan Mishra , "lsr@ietf.org" , Jeff Tantsura References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> <34c223a132f748e0a802d538ccd073b0@huawei.com> From: Peter Psenak Message-ID: <7c75f1bf-5255-bd37-895b-e07b803ace6e@cisco.com> Date: Tue, 13 Oct 2020 13:54:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 11:55:03 -0000 Robert, On 13/10/2020 13:38, Robert Raszuk wrote: > Peter, > > If this is per app how are the constraints shared across apps ? FAD constraints are only used for calculating the flex-algo path. > > See we have single physical resources (for example links) and single > interface outbound queues. If I use per app flex-algo and do not have > central controller how is this going to work in practice for any network > which attempts to use more then one forwarding schema with dynamic > constraints ? flex-algo defines the way to calculate constraint based paths in a distributed manner and guarantees the loop free forwarding over such path. Possible per app and/or per algo resource allocation at each hop is not something that flex-algo spec attempts to solve. That does not mean it is not possible. I don't see anything in the flex-algo spec that would prevent one to do that. thanks, Peter > > Many thx, > R. > > > > On Tue, Oct 13, 2020 at 10:52 AM Peter Psenak > > > wrote: > > Hi Jimmy, > > On 13/10/2020 10:02, Dongjie (Jimmy) wrote: > > Hi Peter, > > > > Thanks for your reply. Please see further inline: > > > >> -----Original Message----- > >> From: Lsr [mailto:lsr-bounces@ietf.org > ] On Behalf Of Peter Psenak > >> Sent: Monday, October 12, 2020 4:39 PM > >> To: Dongjie (Jimmy) >; Ron Bonica > >> >; Yingzhen Qu > >; Gyan > >> Mishra > > >> Cc: lsr@ietf.org ; Jeff Tantsura > > > >> Subject: Re: [Lsr] FW: New Version Notification for > >> draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> Hi Jimmy, > >> > >> On 10/10/2020 05:05, Dongjie (Jimmy) wrote: > >>> Hi Peter, > >>> > >>> Thanks for your reply. It aligns with my understanding of FAD, > which is just a > >> set of constraints for path computation. Thus one Flex-Algo ID > could be used > >> with multiple different data planes. Is this understanding correct? > >> > >> correct. > >> > >>> > >>> If so, my question is about the scenario below: > >>> > >>> A group of nodes in a network support FA-128, a sub-group of > them bind > >> FA-128 to SR SIDs, another sub-group of them bind FA-128 to IP > address. > >> > >> just to use the correct terminology, we should use "participate" > instead of > >> "support". > > > > Agree. > > > >> > >>> When one node compute an SR path to a destination, can it > compute the path > >> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the > >> nodes >which bind FA-128 to IP address? If so, how could this > node know the > >> binding of FA to different data planes on other nodes? > >> > >> again, it is the participation problem. > >> > >> Nodes that participate in the SR Flex-algo 128 will advertise > the participation > >> using the SR-Algorithm Sub-TLV. Only these nodes will be used > during the SR > >> flex-algo computation for algo 128. > >> > >> Nodes that participate in IP flex-algo 128 will advertise the > participation using > >> the IGP Algorithm Sub-TLV. Only these nodes will be used during > the IP flex-algo > >> computation for algo 128. > > > > Agree that if participation to Flex-Algo is advertised in a data > plane specific manner, then path computation with Flex-Algo > constraints could be done only using nodes which bind the Flex-Algo > to the same data plane. > > it's per app, not per data plane, but yes, that is what the base > flex-algo spec mandates. > > > > > As Robert asked and you confirmed, this implies each data plane > needs to be treated as an independent application of Flex-Algo. We > have SR-Algorithm sub-TLV and IP Algorithm sub-TLV, while there are > actually more data planes to be considered: SR-MPLS, SRv6, IPv4, > IPv6, etc., does this mean that Flex-Algo participation needs to be > advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. separately? > > yes, it needs to be advertised per app. We have SR specific algo > participation, we need one for IP as proposed in Ron's draft. > > Regarding IPv4 vs IPv6, it's up to the authors whether they want to > make > the participation for IP flex-algo topology specific or topology > independent, both could work. > > Here's the text from the base flerx-algo draft: > > 10.2.  Advertisement of Node Participation for Other Applications > >     This section describes considerations related to how other >     applications can advertise their participation in a specific Flex- >     Algorithm. > >     Application-specific Flex-Algorithm participation > advertisements MAY >     be topology specific or MAY be topology independent, depending > on the >     application itself. > >     Application-specific advertisement for Flex-Algorithm participation >     MUST be defined for each application and is outside of the scope of >     this document. > > thanks, > Peter > > > > > > Best regards, > > Jie > > > >> > >> thanks, > >> Peter > >> > >>> > >>> Best regards, > >>> Jie > >>> > >>>> -----Original Message----- > >>>> From: Lsr [mailto:lsr-bounces@ietf.org > ] On Behalf Of Peter Psenak > >>>> Sent: Friday, October 9, 2020 11:58 PM > >>>> To: Dongjie (Jimmy) >; Ron Bonica > >>>> >; Yingzhen Qu > >>>> >; Gyan Mishra > > > >>>> Cc: lsr@ietf.org ; Jeff Tantsura > > > >>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>> > >>>> Hi Jimmy, > >>>> > >>>> > >>>>     On 09/10/2020 04:59, Dongjie (Jimmy) wrote: > >>>>> Hi Ron, > >>>>> > >>>>> Thanks for explaining the difference between IP Flex-Algo and SR > >>>>> Flex-algo. As > >>>> you said, the major difference is the data plane. > >>>>> > >>>>> If my understanding is correct, for one Flex-Algo to be used > >>>>> correctly, the set > >>>> of nodes need to apply consistent constraints in computation, and > >>>> bind the FAD to the same data plane. > >>>>> > >>>>> Is it possible that different nodes may use the same > Flex-Algo with > >>>>> different > >>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with > >>>> pure IP etc., or each Flex-Algo is always associated with only one > >>>> data plane? In the former case, should the flex-algo > definition also > >>>> indicate the data plane(s) to be used with the flex-algo? > >>>> > >>>> let me respond to this query, as this is not specific to Ron's > draft. > >>>> > >>>> FAD is data plane agnostic and is used by all of them. > >>>> > >>>> thanks, > >>>> Peter > >>>> > >>>>> > >>>>> Best regards, > >>>>> Jie > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Lsr [mailto:lsr-bounces@ietf.org > ] On Behalf Of Ron Bonica > >>>>>> Sent: Sunday, October 4, 2020 4:34 AM > >>>>>> To: Yingzhen Qu >; Peter Psenak > >>>>>> >; Gyan Mishra > > > >>>>>> Cc: lsr@ietf.org ; Jeff Tantsura > > > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> Hi Yingzhen, > >>>>>> > >>>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the > >>>>>> following > >>>> respects: > >>>>>> > >>>>>> - Links have IGP metrics, TE metrics, delay metrics and > >>>>>> administrative colors > >>>>>> - FADs define Flexible Algorithms > >>>>>> > >>>>>> More specifically, the FAD: > >>>>>> > >>>>>> - Indicates which metric type the Flexible Algorithm uses > >>>>>> - Specifies constraints in terms of link colors that are > included > >>>>>> or excluded from the Flexible Algorithm. > >>>>>> > >>>>>> The significant difference between IP Flexible Algorithms and SR > >>>>>> Flexible Algorithms is: > >>>>>> > >>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 > locators > >>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. > >>>>>> > >>>>>> So, IP Flexible Algorithms can be deployed in any IP > network, even > >>>>>> in the absence of SR. > >>>>>> > >>>>>>                                            Ron > >>>>>> > >>>>>> > >>>>>> Juniper Business Use Only > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Yingzhen Qu > > >>>>>> Sent: Saturday, October 3, 2020 2:08 PM > >>>>>> To: Peter Psenak >; Gyan Mishra > >>>>>> >; Ron > Bonica > > >>>>>> Cc: lsr@ietf.org ; Jeff Tantsura > > > >>>>>> Subject: Re: [Lsr] FW: New Version Notification for > >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt > >>>>>> > >>>>>> [External Email. Be cautious of content] > >>>>>> > >>>>>> > >>>>>> Hi Peter, > >>>>>> > >>>>>> Using flex-algo, a SRv6 locator can be associated with a single > >>>>>> algo, which means an IPv6 or IPv4 address can also be associated > >>>>>> with a single algo. So my understanding is Ron's proposal is > making > >>>>>> the > >>>> configuration of flex-algo easier? > >>>>>> Instead of using the exclude or include list you can configure a > >>>>>> loopback address to a flex-algo directly? > >>>>>> > >>>>>> Thanks, > >>>>>> Yingzhen > >>>>>> > >>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" > wrote: > >>>>>> > >>>>>>        Hi Yingzhen, > >>>>>> > >>>>>>        On 02/10/2020 22:15, Yingzhen Qu wrote: > >>>>>>        > Hi Peter, > >>>>>>        > > >>>>>>        > My understanding of flex-algo is that for traffic > destined > >>>>>> to a prefix on a particular algo, it can only be routed on > routers > >>>>>> belong to that algo, which also means only routers in that algo > >>>>>> calculates how to reach that prefix and install it into the > routing > >>>>>> table. It seems to me that using flex-algo (section 12 of the > >>>>>> draft) it's possible to have a loopback address associated with > >>>>>> only one algo, please correct me if I'm missing or misunderstood > >> something. > >>>>>> > >>>>>>        you are right. That is exactly what is being done for > flex-algo with > >>>>>>        SRv6 - locator is associated with a single algo only. > The proposal > >> uses > >>>>>>        the same concept. > >>>>>> > >>>>>>        thanks, > >>>>>>        Peter > >>>>>> > >>>>>>        > > >>>>>>        > Thanks, > >>>>>>        > Yingzhen > >>>>>>        > > >>>>>>        > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" > >>>>>> on behalf of > >>>>>> ppsenak=40cisco.com@dmarc.ietf.org > > > >>>>>> wrote: > >>>>>>        > > >>>>>>        >      Gyan, > >>>>>>        > > >>>>>>        >      On 02/10/2020 18:30, Gyan Mishra wrote: > >>>>>>        >      > All, > >>>>>>        >      > > >>>>>>        >      > With SRv6 and IP based flex algo a generic > question as it > >>>> applies > >>>>>> to > >>>>>>        >      > both. Is it possible to have within a single > IGP domain > >>>> different > >>>>>> sets > >>>>>>        >      > of nodes or segments of the network running > different > >>>>>> algorithms. > >>>>>>        > > >>>>>>        >      absolutely. > >>>>>>        > > >>>>>>        >      > From > >>>>>>        >      > both drafts it sounds like all nodes have to > agree on > >> same > >>>>>> algorithm > >>>>>>        >      > similar to concept of metric and reference > bandwidth > >> all > >>>> have to > >>>>>> have > >>>>>>        >      > the same style metric and play to the same > sheet of > >> music. > >>>>>>        > > >>>>>>        >      all participating nodes need to agree on the > definition of > >> the > >>>>>> flex-algo > >>>>>>        >      and advertise the participation. That's it. > >>>>>>        > > >>>>>>        >      > If there was > >>>>>>        >      > a way to use multiple algorithms > simultaneously based > >> on > >>>> SFC > >>>>>> or services > >>>>>>        >      > and instantiation of specific algorithm > based on service > >> to > >>>> be > >>>>>>        >      > rendered.  Doing so without causing a > routing loop or > >> sub > >>>>>> optimal > >>>>>>        >      > routing. > >>>>>>        > > >>>>>>        >      you can certainly use multiple algorithms > simultaneously > >> and > >>>> use > >>>>>> algo > >>>>>>        >      specific paths to forward specific traffic > over it. How that > >> is > >>>> done > >>>>>>        >      from the forwarding perspective depends in which > >>>> forwarding > >>>>>> plane you > >>>>>>        >      use. Flex-algo control plane is independent of the > >> forwarding > >>>>>> plane. > >>>>>>        > > >>>>>>        > > >>>>>>        >      >I thought with flex algo that there exists a > feature that > >> on > >>>>>>        >      > each hop there is a way to specify which > algo to use > >> hop by > >>>> hop > >>>>>> similar > >>>>>>        >      > to a hop by hop policy based routing. > >>>>>>        > > >>>>>>        >      no, there is no hop-by-hop classification, that is > >> problematic > >>>> and > >>>>>> does > >>>>>>        >      not scale for high speeds. Classification is > done at the > >>>> ingress only. > >>>>>>        > > >>>>>>        >      thanks, > >>>>>>        >      Peter > >>>>>>        > > >>>>>>        >      > > >>>>>>        > > >>>>>>        > > >> _______________________________________________ > >>>>>>        >      Lsr mailing list > >>>>>>        > Lsr@ietf.org > >>>>>>        > > >>>>>> > https://urldefense.com/v3/__https://nam11.safelinks.protection.outl > >>>>>> oo > >>>>>> k.com/ > >>>>>> ?url=https*3A*2F*2Fwww.ietf.org > *2Fmailman*2Flistinfo*2Flsr&data > >>>>>> = > >>>> 0 > >>>>>> 2 > >>>>>> > >>>> > >> *7C01*7Cyingzhen.qu*40futurewei.com > *7Cfe03124c6e414e067c2008d86781 > >>>>>> > >>>> > >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 > >>>>>> > >>>> > >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D > >>>>>> > >>>> > >> > &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR > >>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ > >>>>>>        > > >>>>>>        > > >>>>>>        > > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Lsr mailing list > >>>>>> Lsr@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lsr > >>> > >>> > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > From nobody Wed Oct 14 01:39:08 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347323A145A for ; Wed, 14 Oct 2020 01:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 mbPF-rZylH29 for ; Wed, 14 Oct 2020 01:38:57 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6634A3A141B for ; Wed, 14 Oct 2020 01:38:57 -0700 (PDT) Received: from lhreml705-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 59DBAD3577F284931D0C; Wed, 14 Oct 2020 09:38:51 +0100 (IST) Received: from dggeme704-chm.china.huawei.com (10.1.199.100) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 14 Oct 2020 09:38:50 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme704-chm.china.huawei.com (10.1.199.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 14 Oct 2020 16:38:48 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Wed, 14 Oct 2020 16:38:47 +0800 From: "Dongjie (Jimmy)" To: Peter Psenak , Ron Bonica , Yingzhen Qu , Gyan Mishra CC: "lsr@ietf.org" , Jeff Tantsura Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAESbICAACKHAIAA7E2AgADTYwCAAWy/gIAAAz6AgAA7sgCAAOLhAIAAi8SAgAAopgCAA1loEIAFx4OAgAExPQCAAwtCgIACAvgg//+TI4CAAfmEMA== Date: Wed, 14 Oct 2020 08:38:47 +0000 Message-ID: <5d9887519bbc429fb0bf9886b35ccefd@huawei.com> References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> <34c223a132f748e0a802d538ccd073b0@huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 08:39:07 -0000 SGkgUGV0ZXIsIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBldGVy IFBzZW5hayBbbWFpbHRvOnBwc2VuYWtAY2lzY28uY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBPY3Rv YmVyIDEzLCAyMDIwIDQ6NTMgUE0NCj4gVG86IERvbmdqaWUgKEppbW15KSA8amllLmRvbmdAaHVh d2VpLmNvbT47IFJvbiBCb25pY2ENCj4gPHJib25pY2FAanVuaXBlci5uZXQ+OyBZaW5nemhlbiBR dSA8eWluZ3poZW4ucXVAZnV0dXJld2VpLmNvbT47IEd5YW4NCj4gTWlzaHJhIDxoYXlhYnVzYWdz bUBnbWFpbC5jb20+DQo+IENjOiBsc3JAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmEgPGplZmZ0YW50 LmlldGZAZ21haWwuY29tPg0KPiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtYm9uaWNhLWxzci1pcC1mbGV4YWxnby0wMC50eHQNCj4g DQo+ID4+PiBXaGVuIG9uZSBub2RlIGNvbXB1dGUgYW4gU1IgcGF0aCB0byBhIGRlc3RpbmF0aW9u LCBjYW4gaXQgY29tcHV0ZQ0KPiA+Pj4gdGhlIHBhdGgNCj4gPj4gdG8gb25seSBwYXNzIHRoZSBu b2RlcyB3aGljaCBiaW5kIEZBLTEyOCB0byBTUiBTSURzLCBhbmQgYXZvaWQgdGhlDQo+ID4+IG5v ZGVzID53aGljaCBiaW5kIEZBLTEyOCB0byBJUCBhZGRyZXNzPyBJZiBzbywgaG93IGNvdWxkIHRo aXMgbm9kZQ0KPiA+PiBrbm93IHRoZSBiaW5kaW5nIG9mIEZBIHRvIGRpZmZlcmVudCBkYXRhIHBs YW5lcyBvbiBvdGhlciBub2Rlcz8NCj4gPj4NCj4gPj4gYWdhaW4sIGl0IGlzIHRoZSBwYXJ0aWNp cGF0aW9uIHByb2JsZW0uDQo+ID4+DQo+ID4+IE5vZGVzIHRoYXQgcGFydGljaXBhdGUgaW4gdGhl IFNSIEZsZXgtYWxnbyAxMjggd2lsbCBhZHZlcnRpc2UgdGhlDQo+ID4+IHBhcnRpY2lwYXRpb24g dXNpbmcgdGhlIFNSLUFsZ29yaXRobSBTdWItVExWLiBPbmx5IHRoZXNlIG5vZGVzIHdpbGwNCj4g Pj4gYmUgdXNlZCBkdXJpbmcgdGhlIFNSIGZsZXgtYWxnbyBjb21wdXRhdGlvbiBmb3IgYWxnbyAx MjguDQo+ID4+DQo+ID4+IE5vZGVzIHRoYXQgcGFydGljaXBhdGUgaW4gSVAgZmxleC1hbGdvIDEy OCB3aWxsIGFkdmVydGlzZSB0aGUNCj4gPj4gcGFydGljaXBhdGlvbiB1c2luZyB0aGUgSUdQIEFs Z29yaXRobSBTdWItVExWLiBPbmx5IHRoZXNlIG5vZGVzIHdpbGwNCj4gPj4gYmUgdXNlZCBkdXJp bmcgdGhlIElQIGZsZXgtYWxnbyBjb21wdXRhdGlvbiBmb3IgYWxnbyAxMjguDQo+ID4NCj4gPiBB Z3JlZSB0aGF0IGlmIHBhcnRpY2lwYXRpb24gdG8gRmxleC1BbGdvIGlzIGFkdmVydGlzZWQgaW4g YSBkYXRhIHBsYW5lIHNwZWNpZmljDQo+IG1hbm5lciwgdGhlbiBwYXRoIGNvbXB1dGF0aW9uIHdp dGggRmxleC1BbGdvIGNvbnN0cmFpbnRzIGNvdWxkIGJlIGRvbmUgb25seQ0KPiB1c2luZyBub2Rl cyB3aGljaCBiaW5kIHRoZSBGbGV4LUFsZ28gdG8gdGhlIHNhbWUgZGF0YSBwbGFuZS4NCj4gDQo+ IGl0J3MgcGVyIGFwcCwgbm90IHBlciBkYXRhIHBsYW5lLCBidXQgeWVzLCB0aGF0IGlzIHdoYXQg dGhlIGJhc2UgZmxleC1hbGdvIHNwZWMNCj4gbWFuZGF0ZXMuDQo+DQo+ID4gQXMgUm9iZXJ0IGFz a2VkIGFuZCB5b3UgY29uZmlybWVkLCB0aGlzIGltcGxpZXMgZWFjaCBkYXRhIHBsYW5lIG5lZWRz IHRvIGJlDQo+IHRyZWF0ZWQgYXMgYW4gaW5kZXBlbmRlbnQgYXBwbGljYXRpb24gb2YgRmxleC1B bGdvLiBXZSBoYXZlIFNSLUFsZ29yaXRobQ0KPiBzdWItVExWIGFuZCBJUCBBbGdvcml0aG0gc3Vi LVRMViwgd2hpbGUgdGhlcmUgYXJlIGFjdHVhbGx5IG1vcmUgZGF0YSBwbGFuZXMgdG8NCj4gYmUg Y29uc2lkZXJlZDogU1ItTVBMUywgU1J2NiwgSVB2NCwgSVB2NiwgZXRjLiwgZG9lcyB0aGlzIG1l YW4gdGhhdCBGbGV4LUFsZ28NCj4gcGFydGljaXBhdGlvbiBuZWVkcyB0byBiZSBhZHZlcnRpc2Vk IGZvciBTUi1NUExTLCBTUnY2LCBJUHY0LCBJUHY2LCBldGMuDQo+IHNlcGFyYXRlbHk/DQo+IA0K PiB5ZXMsIGl0IG5lZWRzIHRvIGJlIGFkdmVydGlzZWQgcGVyIGFwcC4gV2UgaGF2ZSBTUiBzcGVj aWZpYyBhbGdvIHBhcnRpY2lwYXRpb24sDQo+IHdlIG5lZWQgb25lIGZvciBJUCBhcyBwcm9wb3Nl ZCBpbiBSb24ncyBkcmFmdC4NCg0KT0suIFdoaWxlIHRoZSBtZWFuaW5nIG9mICJhcHAiIGhlcmUg bWF5YmUgYSBsaXR0bGUgdmFndWUsIGFyZSBTUi1NUExTIGFuZCBTUnY2IGNvbnNpZGVyZWQgdGhl IHNhbWUgb3IgZGlmZmVyZW50IGFwcHM/IA0KDQo+IFJlZ2FyZGluZyBJUHY0IHZzIElQdjYsIGl0 J3MgdXAgdG8gdGhlIGF1dGhvcnMgd2hldGhlciB0aGV5IHdhbnQgdG8gbWFrZSB0aGUNCj4gcGFy dGljaXBhdGlvbiBmb3IgSVAgZmxleC1hbGdvIHRvcG9sb2d5IHNwZWNpZmljIG9yIHRvcG9sb2d5 IGluZGVwZW5kZW50LCBib3RoDQo+IGNvdWxkIHdvcmsuDQoNCklmIHRoZSBwYXJ0aWNpcGF0aW9u IGlzIHRvcG9sb2d5IHNwZWNpZmljLCBkbyB5b3UgbWVhbiBJUHY0IGFuZCBJUHY2IGNvdWxkIGJl IGRpc3Rpbmd1aXNoZWQgYnkgYWR2ZXJ0aXNpbmcgRmxleC1BbGdvIHBhcnRpY2lwYXRpb24gd2l0 aCBkaWZmZXJlbnQgVG9wb2xvZ3kgSURzIChNVC1JRCk/IFRoaXMgd2F5LCBpcyB0aGUgdG9wb2xv Z3kgSUQgYWN0dWFsbHkgdXNlZCBhcyB0aGUgYWRkcmVzcyBmYW1pbHkgZGlzdGluZ3Vpc2hlcj8N Cg0KQmVzdCByZWdhcmRzLA0KSmllDQoNCj4gSGVyZSdzIHRoZSB0ZXh0IGZyb20gdGhlIGJhc2Ug ZmxlcngtYWxnbyBkcmFmdDoNCj4gDQo+IDEwLjIuICBBZHZlcnRpc2VtZW50IG9mIE5vZGUgUGFy dGljaXBhdGlvbiBmb3IgT3RoZXIgQXBwbGljYXRpb25zDQo+IA0KPiAgICAgVGhpcyBzZWN0aW9u IGRlc2NyaWJlcyBjb25zaWRlcmF0aW9ucyByZWxhdGVkIHRvIGhvdyBvdGhlcg0KPiAgICAgYXBw bGljYXRpb25zIGNhbiBhZHZlcnRpc2UgdGhlaXIgcGFydGljaXBhdGlvbiBpbiBhIHNwZWNpZmlj IEZsZXgtDQo+ICAgICBBbGdvcml0aG0uDQo+IA0KPiAgICAgQXBwbGljYXRpb24tc3BlY2lmaWMg RmxleC1BbGdvcml0aG0gcGFydGljaXBhdGlvbiBhZHZlcnRpc2VtZW50cyBNQVkNCj4gICAgIGJl IHRvcG9sb2d5IHNwZWNpZmljIG9yIE1BWSBiZSB0b3BvbG9neSBpbmRlcGVuZGVudCwgZGVwZW5k aW5nIG9uIHRoZQ0KPiAgICAgYXBwbGljYXRpb24gaXRzZWxmLg0KPiANCj4gICAgIEFwcGxpY2F0 aW9uLXNwZWNpZmljIGFkdmVydGlzZW1lbnQgZm9yIEZsZXgtQWxnb3JpdGhtIHBhcnRpY2lwYXRp b24NCj4gICAgIE1VU1QgYmUgZGVmaW5lZCBmb3IgZWFjaCBhcHBsaWNhdGlvbiBhbmQgaXMgb3V0 c2lkZSBvZiB0aGUgc2NvcGUgb2YNCj4gICAgIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiB0aGFua3Ms DQo+IFBldGVyDQo+IA0KPiANCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBKaWUNCj4gPg0K PiA+Pg0KPiA+PiB0aGFua3MsDQo+ID4+IFBldGVyDQo+ID4+DQo+ID4+Pg0KPiA+Pj4gQmVzdCBy ZWdhcmRzLA0KPiA+Pj4gSmllDQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+Pj4gRnJvbTogTHNyIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBQZXRlciBQc2VuYWsNCj4gPj4+PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgOSwgMjAy MCAxMTo1OCBQTQ0KPiA+Pj4+IFRvOiBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5j b20+OyBSb24gQm9uaWNhDQo+ID4+Pj4gPHJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRm Lm9yZz47IFlpbmd6aGVuIFF1DQo+ID4+Pj4gPHlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5jb20+OyBH eWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPg0KPiA+Pj4+IENjOiBsc3JAaWV0Zi5v cmc7IEplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPg0KPiA+Pj4+IFN1Ympl Y3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+Pj4+IGRy YWZ0LWJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDAudHh0DQo+ID4+Pj4NCj4gPj4+PiBIaSBKaW1t eSwNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gICAgIE9uIDA5LzEwLzIwMjAgMDQ6NTksIERvbmdq aWUgKEppbW15KSB3cm90ZToNCj4gPj4+Pj4gSGkgUm9uLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFu a3MgZm9yIGV4cGxhaW5pbmcgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBJUCBGbGV4LUFsZ28gYW5k IFNSDQo+ID4+Pj4+IEZsZXgtYWxnby4gQXMNCj4gPj4+PiB5b3Ugc2FpZCwgdGhlIG1ham9yIGRp ZmZlcmVuY2UgaXMgdGhlIGRhdGEgcGxhbmUuDQo+ID4+Pj4+DQo+ID4+Pj4+IElmIG15IHVuZGVy c3RhbmRpbmcgaXMgY29ycmVjdCwgZm9yIG9uZSBGbGV4LUFsZ28gdG8gYmUgdXNlZA0KPiA+Pj4+ PiBjb3JyZWN0bHksIHRoZSBzZXQNCj4gPj4+PiBvZiBub2RlcyBuZWVkIHRvIGFwcGx5IGNvbnNp c3RlbnQgY29uc3RyYWludHMgaW4gY29tcHV0YXRpb24sIGFuZA0KPiA+Pj4+IGJpbmQgdGhlIEZB RCB0byB0aGUgc2FtZSBkYXRhIHBsYW5lLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJcyBpdCBwb3NzaWJs ZSB0aGF0IGRpZmZlcmVudCBub2RlcyBtYXkgdXNlIHRoZSBzYW1lIEZsZXgtQWxnbw0KPiA+Pj4+ PiB3aXRoIGRpZmZlcmVudA0KPiA+Pj4+IGRhdGEgcGxhbmUsIGUuZy4gc29tZSB3aXRoIFNSLU1Q TFMsIHNvbWUgd2l0aCBTUnY2LCBhbmQgc29tZSB3aXRoDQo+ID4+Pj4gcHVyZSBJUCBldGMuLCBv ciBlYWNoIEZsZXgtQWxnbyBpcyBhbHdheXMgYXNzb2NpYXRlZCB3aXRoIG9ubHkgb25lDQo+ID4+ Pj4gZGF0YSBwbGFuZT8gSW4gdGhlIGZvcm1lciBjYXNlLCBzaG91bGQgdGhlIGZsZXgtYWxnbyBk ZWZpbml0aW9uDQo+ID4+Pj4gYWxzbyBpbmRpY2F0ZSB0aGUgZGF0YSBwbGFuZShzKSB0byBiZSB1 c2VkIHdpdGggdGhlIGZsZXgtYWxnbz8NCj4gPj4+Pg0KPiA+Pj4+IGxldCBtZSByZXNwb25kIHRv IHRoaXMgcXVlcnksIGFzIHRoaXMgaXMgbm90IHNwZWNpZmljIHRvIFJvbidzIGRyYWZ0Lg0KPiA+ Pj4+DQo+ID4+Pj4gRkFEIGlzIGRhdGEgcGxhbmUgYWdub3N0aWMgYW5kIGlzIHVzZWQgYnkgYWxs IG9mIHRoZW0uDQo+ID4+Pj4NCj4gPj4+PiB0aGFua3MsDQo+ID4+Pj4gUGV0ZXINCj4gPj4+Pg0K PiA+Pj4+Pg0KPiA+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+Pj4+IEppZQ0KPiA+Pj4+Pg0KPiA+ Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+IEZyb206IExzciBbbWFp bHRvOmxzci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uIEJvbmljYQ0KPiA+Pj4+ Pj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDQsIDIwMjAgNDozNCBBTQ0KPiA+Pj4+Pj4gVG86IFlp bmd6aGVuIFF1IDx5aW5nemhlbi5xdUBmdXR1cmV3ZWkuY29tPjsgUGV0ZXIgUHNlbmFrDQo+ID4+ Pj4+PiA8cHBzZW5ha0BjaXNjby5jb20+OyBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwu Y29tPg0KPiA+Pj4+Pj4gQ2M6IGxzckBpZXRmLm9yZzsgSmVmZiBUYW50c3VyYSA8amVmZnRhbnQu aWV0ZkBnbWFpbC5jb20+DQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPj4+Pj4+IGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxleGFs Z28tMDAudHh0DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSGkgWWluZ3poZW4sDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gSVAgRmxleGlibGUgQWxnb3JpdGhtcyBhcmUgbGlrZSBTUiBGbGV4aWJsZSBBbGdvcml0 aG1zIGluIHRoZQ0KPiA+Pj4+Pj4gZm9sbG93aW5nDQo+ID4+Pj4gcmVzcGVjdHM6DQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gLSBMaW5rcyBoYXZlIElHUCBtZXRyaWNzLCBURSBtZXRyaWNzLCBkZWxheSBt ZXRyaWNzIGFuZA0KPiA+Pj4+Pj4gYWRtaW5pc3RyYXRpdmUgY29sb3JzDQo+ID4+Pj4+PiAtIEZB RHMgZGVmaW5lIEZsZXhpYmxlIEFsZ29yaXRobXMNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBNb3JlIHNw ZWNpZmljYWxseSwgdGhlIEZBRDoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtIEluZGljYXRlcyB3aGlj aCBtZXRyaWMgdHlwZSB0aGUgRmxleGlibGUgQWxnb3JpdGhtIHVzZXMNCj4gPj4+Pj4+IC0gU3Bl Y2lmaWVzIGNvbnN0cmFpbnRzIGluIHRlcm1zIG9mIGxpbmsgY29sb3JzIHRoYXQgYXJlIGluY2x1 ZGVkDQo+ID4+Pj4+PiBvciBleGNsdWRlZCBmcm9tIHRoZSBGbGV4aWJsZSBBbGdvcml0aG0uDQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIHNpZ25pZmljYW50IGRpZmZlcmVuY2UgYmV0d2VlbiBJUCBG bGV4aWJsZSBBbGdvcml0aG1zIGFuZCBTUg0KPiA+Pj4+Pj4gRmxleGlibGUgQWxnb3JpdGhtcyBp czoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtIFNSIEZsZXhpYmxlIEFsZ29yaXRobXMgYmluZCBGQURz IHRvIHByZWZpeCBTSURzIG9yIFNSdjYNCj4gPj4+Pj4+IGxvY2F0b3JzDQo+ID4+Pj4+PiAtIElQ IEZsZXhpYmxlIEFsZ29yaXRobXMgYmluZCBGQURzIHRvIElQdjQgb3IgSVB2NiBhZGRyZXNzZXMu DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gU28sIElQIEZsZXhpYmxlIEFsZ29yaXRobXMgY2FuIGJlIGRl cGxveWVkIGluIGFueSBJUCBuZXR3b3JrLA0KPiA+Pj4+Pj4gZXZlbiBpbiB0aGUgYWJzZW5jZSBv ZiBTUi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEp1bmlwZXIgQnVz aW5lc3MgVXNlIE9ubHkNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+Pj4+Pj4gRnJvbTogWWluZ3poZW4gUXUgPHlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5j b20+DQo+ID4+Pj4+PiBTZW50OiBTYXR1cmRheSwgT2N0b2JlciAzLCAyMDIwIDI6MDggUE0NCj4g Pj4+Pj4+IFRvOiBQZXRlciBQc2VuYWsgPHBwc2VuYWtAY2lzY28uY29tPjsgR3lhbiBNaXNocmEN Cj4gPj4+Pj4+IDxoYXlhYnVzYWdzbUBnbWFpbC5jb20+OyBSb24gQm9uaWNhIDxyYm9uaWNhQGp1 bmlwZXIubmV0Pg0KPiA+Pj4+Pj4gQ2M6IGxzckBpZXRmLm9yZzsgSmVmZiBUYW50c3VyYSA8amVm ZnRhbnQuaWV0ZkBnbWFpbC5jb20+DQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPj4+Pj4+IGRyYWZ0LWJvbmljYS1sc3ItaXAt ZmxleGFsZ28tMDAudHh0DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gW0V4dGVybmFsIEVtYWlsLiBCZSBj YXV0aW91cyBvZiBjb250ZW50XQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBIaSBQZXRl ciwNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBVc2luZyBmbGV4LWFsZ28sIGEgU1J2NiBsb2NhdG9yIGNh biBiZSBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUNCj4gPj4+Pj4+IGFsZ28sIHdoaWNoIG1lYW5z IGFuIElQdjYgb3IgSVB2NCBhZGRyZXNzIGNhbiBhbHNvIGJlIGFzc29jaWF0ZWQNCj4gPj4+Pj4+ IHdpdGggYSBzaW5nbGUgYWxnby4gU28gbXkgdW5kZXJzdGFuZGluZyBpcyBSb24ncyBwcm9wb3Nh bCBpcw0KPiA+Pj4+Pj4gbWFraW5nIHRoZQ0KPiA+Pj4+IGNvbmZpZ3VyYXRpb24gb2YgZmxleC1h bGdvIGVhc2llcj8NCj4gPj4+Pj4+IEluc3RlYWQgb2YgdXNpbmcgdGhlIGV4Y2x1ZGUgb3IgaW5j bHVkZSBsaXN0IHlvdSBjYW4gY29uZmlndXJlIGENCj4gPj4+Pj4+IGxvb3BiYWNrIGFkZHJlc3Mg dG8gYSBmbGV4LWFsZ28gZGlyZWN0bHk/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhhbmtzLA0KPiA+ Pj4+Pj4gWWluZ3poZW4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBPbiAxMC8zLzIwLCAyOjQ3IEFNLCAi UGV0ZXIgUHNlbmFrIiA8cHBzZW5ha0BjaXNjby5jb20+IHdyb3RlOg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+ICAgICAgICBIaSBZaW5nemhlbiwNCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgICAgT24gMDIv MTAvMjAyMCAyMjoxNSwgWWluZ3poZW4gUXUgd3JvdGU6DQo+ID4+Pj4+PiAgICAgICAgPiBIaSBQ ZXRlciwNCj4gPj4+Pj4+ICAgICAgICA+DQo+ID4+Pj4+PiAgICAgICAgPiBNeSB1bmRlcnN0YW5k aW5nIG9mIGZsZXgtYWxnbyBpcyB0aGF0IGZvciB0cmFmZmljDQo+ID4+Pj4+PiBkZXN0aW5lZCB0 byBhIHByZWZpeCBvbiBhIHBhcnRpY3VsYXIgYWxnbywgaXQgY2FuIG9ubHkgYmUgcm91dGVkDQo+ ID4+Pj4+PiBvbiByb3V0ZXJzIGJlbG9uZyB0byB0aGF0IGFsZ28sIHdoaWNoIGFsc28gbWVhbnMg b25seSByb3V0ZXJzIGluDQo+ID4+Pj4+PiB0aGF0IGFsZ28gY2FsY3VsYXRlcyBob3cgdG8gcmVh Y2ggdGhhdCBwcmVmaXggYW5kIGluc3RhbGwgaXQgaW50bw0KPiA+Pj4+Pj4gdGhlIHJvdXRpbmcg dGFibGUuIEl0IHNlZW1zIHRvIG1lIHRoYXQgdXNpbmcgZmxleC1hbGdvIChzZWN0aW9uDQo+ID4+ Pj4+PiAxMiBvZiB0aGUNCj4gPj4+Pj4+IGRyYWZ0KSBpdCdzIHBvc3NpYmxlIHRvIGhhdmUgYSBs b29wYmFjayBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aA0KPiA+Pj4+Pj4gb25seSBvbmUgYWxnbywg cGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdtIG1pc3Npbmcgb3IgbWlzdW5kZXJzdG9vZA0KPiA+PiBz b21ldGhpbmcuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICAgIHlvdSBhcmUgcmlnaHQuIFRoYXQg aXMgZXhhY3RseSB3aGF0IGlzIGJlaW5nIGRvbmUgZm9yIGZsZXgtYWxnbw0KPiB3aXRoDQo+ID4+ Pj4+PiAgICAgICAgU1J2NiAtIGxvY2F0b3IgaXMgYXNzb2NpYXRlZCB3aXRoIGEgc2luZ2xlIGFs Z28gb25seS4gVGhlDQo+ID4+Pj4+PiBwcm9wb3NhbA0KPiA+PiB1c2VzDQo+ID4+Pj4+PiAgICAg ICAgdGhlIHNhbWUgY29uY2VwdC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICAgICAgdGhhbmtzLA0K PiA+Pj4+Pj4gICAgICAgIFBldGVyDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICAgID4NCj4gPj4+ Pj4+ICAgICAgICA+IFRoYW5rcywNCj4gPj4+Pj4+ICAgICAgICA+IFlpbmd6aGVuDQo+ID4+Pj4+ PiAgICAgICAgPg0KPiA+Pj4+Pj4gICAgICAgID4gT24gMTAvMi8yMCwgOTo0MyBBTSwgIkxzciBv biBiZWhhbGYgb2YgUGV0ZXIgUHNlbmFrIg0KPiA+Pj4+Pj4gPGxzci1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZg0KPiA+Pj4+Pj4gcHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9y Zz4NCj4gPj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4gICAgICAgID4NCj4gPj4+Pj4+ICAgICAgICA+ ICAgICAgR3lhbiwNCj4gPj4+Pj4+ICAgICAgICA+DQo+ID4+Pj4+PiAgICAgICAgPiAgICAgIE9u IDAyLzEwLzIwMjAgMTg6MzAsIEd5YW4gTWlzaHJhIHdyb3RlOg0KPiA+Pj4+Pj4gICAgICAgID4g ICAgICA+IEFsbCwNCj4gPj4+Pj4+ICAgICAgICA+ICAgICAgPg0KPiA+Pj4+Pj4gICAgICAgID4g ICAgICA+IFdpdGggU1J2NiBhbmQgSVAgYmFzZWQgZmxleCBhbGdvIGEgZ2VuZXJpYyBxdWVzdGlv bg0KPiBhcyBpdA0KPiA+Pj4+IGFwcGxpZXMNCj4gPj4+Pj4+IHRvDQo+ID4+Pj4+PiAgICAgICAg PiAgICAgID4gYm90aC4gSXMgaXQgcG9zc2libGUgdG8gaGF2ZSB3aXRoaW4gYSBzaW5nbGUgSUdQ DQo+IGRvbWFpbg0KPiA+Pj4+IGRpZmZlcmVudA0KPiA+Pj4+Pj4gc2V0cw0KPiA+Pj4+Pj4gICAg ICAgID4gICAgICA+IG9mIG5vZGVzIG9yIHNlZ21lbnRzIG9mIHRoZSBuZXR3b3JrIHJ1bm5pbmcN Cj4gZGlmZmVyZW50DQo+ID4+Pj4+PiBhbGdvcml0aG1zLg0KPiA+Pj4+Pj4gICAgICAgID4NCj4g Pj4+Pj4+ICAgICAgICA+ICAgICAgYWJzb2x1dGVseS4NCj4gPj4+Pj4+ICAgICAgICA+DQo+ID4+ Pj4+PiAgICAgICAgPiAgICAgID4gRnJvbQ0KPiA+Pj4+Pj4gICAgICAgID4gICAgICA+IGJvdGgg ZHJhZnRzIGl0IHNvdW5kcyBsaWtlIGFsbCBub2RlcyBoYXZlIHRvIGFncmVlIG9uDQo+ID4+IHNh bWUNCj4gPj4+Pj4+IGFsZ29yaXRobQ0KPiA+Pj4+Pj4gICAgICAgID4gICAgICA+IHNpbWlsYXIg dG8gY29uY2VwdCBvZiBtZXRyaWMgYW5kIHJlZmVyZW5jZQ0KPiBiYW5kd2lkdGgNCj4gPj4gYWxs DQo+ID4+Pj4gaGF2ZSB0bw0KPiA+Pj4+Pj4gaGF2ZQ0KPiA+Pj4+Pj4gICAgICAgID4gICAgICA+ IHRoZSBzYW1lIHN0eWxlIG1ldHJpYyBhbmQgcGxheSB0byB0aGUgc2FtZSBzaGVldCBvZg0KPiA+ PiBtdXNpYy4NCj4gPj4+Pj4+ICAgICAgICA+DQo+ID4+Pj4+PiAgICAgICAgPiAgICAgIGFsbCBw YXJ0aWNpcGF0aW5nIG5vZGVzIG5lZWQgdG8gYWdyZWUgb24gdGhlIGRlZmluaXRpb24NCj4gb2YN Cj4gPj4gdGhlDQo+ID4+Pj4+PiBmbGV4LWFsZ28NCj4gPj4+Pj4+ICAgICAgICA+ICAgICAgYW5k IGFkdmVydGlzZSB0aGUgcGFydGljaXBhdGlvbi4gVGhhdCdzIGl0Lg0KPiA+Pj4+Pj4gICAgICAg ID4NCj4gPj4+Pj4+ICAgICAgICA+ICAgICAgPiBJZiB0aGVyZSB3YXMNCj4gPj4+Pj4+ICAgICAg ICA+ICAgICAgPiBhIHdheSB0byB1c2UgbXVsdGlwbGUgYWxnb3JpdGhtcyBzaW11bHRhbmVvdXNs eQ0KPiBiYXNlZA0KPiA+PiBvbg0KPiA+Pj4+IFNGQw0KPiA+Pj4+Pj4gb3Igc2VydmljZXMNCj4g Pj4+Pj4+ICAgICAgICA+ICAgICAgPiBhbmQgaW5zdGFudGlhdGlvbiBvZiBzcGVjaWZpYyBhbGdv cml0aG0gYmFzZWQgb24NCj4gc2VydmljZQ0KPiA+PiB0bw0KPiA+Pj4+IGJlDQo+ID4+Pj4+PiAg ICAgICAgPiAgICAgID4gcmVuZGVyZWQuICBEb2luZyBzbyB3aXRob3V0IGNhdXNpbmcgYSByb3V0 aW5nIGxvb3ANCj4gb3INCj4gPj4gc3ViDQo+ID4+Pj4+PiBvcHRpbWFsDQo+ID4+Pj4+PiAgICAg ICAgPiAgICAgID4gcm91dGluZy4NCj4gPj4+Pj4+ICAgICAgICA+DQo+ID4+Pj4+PiAgICAgICAg PiAgICAgIHlvdSBjYW4gY2VydGFpbmx5IHVzZSBtdWx0aXBsZSBhbGdvcml0aG1zDQo+IHNpbXVs dGFuZW91c2x5DQo+ID4+IGFuZA0KPiA+Pj4+IHVzZQ0KPiA+Pj4+Pj4gYWxnbw0KPiA+Pj4+Pj4g ICAgICAgID4gICAgICBzcGVjaWZpYyBwYXRocyB0byBmb3J3YXJkIHNwZWNpZmljIHRyYWZmaWMg b3ZlciBpdC4gSG93DQo+IHRoYXQNCj4gPj4gaXMNCj4gPj4+PiBkb25lDQo+ID4+Pj4+PiAgICAg ICAgPiAgICAgIGZyb20gdGhlIGZvcndhcmRpbmcgcGVyc3BlY3RpdmUgZGVwZW5kcyBpbiB3aGlj aA0KPiA+Pj4+IGZvcndhcmRpbmcNCj4gPj4+Pj4+IHBsYW5lIHlvdQ0KPiA+Pj4+Pj4gICAgICAg ID4gICAgICB1c2UuIEZsZXgtYWxnbyBjb250cm9sIHBsYW5lIGlzIGluZGVwZW5kZW50IG9mIHRo ZQ0KPiA+PiBmb3J3YXJkaW5nDQo+ID4+Pj4+PiBwbGFuZS4NCj4gPj4+Pj4+ICAgICAgICA+DQo+ ID4+Pj4+PiAgICAgICAgPg0KPiA+Pj4+Pj4gICAgICAgID4gICAgICA+SSB0aG91Z2h0IHdpdGgg ZmxleCBhbGdvIHRoYXQgdGhlcmUgZXhpc3RzIGEgZmVhdHVyZQ0KPiB0aGF0DQo+ID4+IG9uDQo+ ID4+Pj4+PiAgICAgICAgPiAgICAgID4gZWFjaCBob3AgdGhlcmUgaXMgYSB3YXkgdG8gc3BlY2lm eSB3aGljaCBhbGdvIHRvIHVzZQ0KPiA+PiBob3AgYnkNCj4gPj4+PiBob3ANCj4gPj4+Pj4+IHNp bWlsYXINCj4gPj4+Pj4+ICAgICAgICA+ICAgICAgPiB0byBhIGhvcCBieSBob3AgcG9saWN5IGJh c2VkIHJvdXRpbmcuDQo+ID4+Pj4+PiAgICAgICAgPg0KPiA+Pj4+Pj4gICAgICAgID4gICAgICBu bywgdGhlcmUgaXMgbm8gaG9wLWJ5LWhvcCBjbGFzc2lmaWNhdGlvbiwgdGhhdCBpcw0KPiA+PiBw cm9ibGVtYXRpYw0KPiA+Pj4+IGFuZA0KPiA+Pj4+Pj4gZG9lcw0KPiA+Pj4+Pj4gICAgICAgID4g ICAgICBub3Qgc2NhbGUgZm9yIGhpZ2ggc3BlZWRzLiBDbGFzc2lmaWNhdGlvbiBpcyBkb25lIGF0 IHRoZQ0KPiA+Pj4+IGluZ3Jlc3Mgb25seS4NCj4gPj4+Pj4+ICAgICAgICA+DQo+ID4+Pj4+PiAg ICAgICAgPiAgICAgIHRoYW5rcywNCj4gPj4+Pj4+ICAgICAgICA+ICAgICAgUGV0ZXINCj4gPj4+ Pj4+ICAgICAgICA+DQo+ID4+Pj4+PiAgICAgICAgPiAgICAgID4NCj4gPj4+Pj4+ICAgICAgICA+ DQo+ID4+Pj4+PiAgICAgICAgPg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4gICAgICAgID4gICAgICBMc3IgbWFpbGluZyBsaXN0 DQo+ID4+Pj4+PiAgICAgICAgPiAgICAgIExzckBpZXRmLm9yZw0KPiA+Pj4+Pj4gICAgICAgID4N Cj4gPj4+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL25hbTExLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91DQo+ID4+Pj4+PiB0bA0KPiA+Pj4+Pj4gb28NCj4gPj4+Pj4+IGsu Y29tLw0KPiA+Pj4+Pj4gP3VybD1odHRwcyozQSoyRioyRnd3dy5pZXRmLm9yZyoyRm1haWxtYW4q MkZsaXN0aW5mbyoyRmxzciZhbXA7ZGENCj4gPj4+Pj4+IHRhDQo+ID4+Pj4+PiA9DQo+ID4+Pj4g MA0KPiA+Pj4+Pj4gMg0KPiA+Pj4+Pj4NCj4gPj4+Pg0KPiA+Pg0KPiAqN0MwMSo3Q3lpbmd6aGVu LnF1KjQwZnV0dXJld2VpLmNvbSo3Q2ZlMDMxMjRjNmU0MTRlMDY3YzIwMDhkODY3ODENCj4gPj4+ Pj4+DQo+ID4+Pj4NCj4gPj4NCj4gNjU0MSo3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFm ZWRjKjdDMSo3QzAqN0M2MzczNzMxNTI3Mzk4Ng0KPiA+Pj4+Pj4NCj4gPj4+Pg0KPiA+Pg0KPiA1 MTI2JmFtcDtzZGF0YT1XSTQ4Y0VBYW4qMkZPa0RQbVZYR3VyRUFqUEl0TkdGOXA5UERRSWxEMWlw MGcqM0QNCj4gPj4+Pj4+DQo+ID4+Pj4NCj4gPj4NCj4gJmFtcDtyZXNlcnZlZD0wX187SlNVbEpT VWxKU1VsSlNVbEpTVWxKUSEhTkV0NnlNYU8tZ2shWDFmUmxuOU1qaW1lSmNSDQo+ID4+Pj4+PiBF VUVJeWRyLThJSWJ0Tm9uWE1zODNlb1h2Und3NnhrYVFmVlVkTmgwa0s0NTJHUC1HJA0KPiA+Pj4+ Pj4gICAgICAgID4NCj4gPj4+Pj4+ICAgICAgICA+DQo+ID4+Pj4+PiAgICAgICAgPg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+Pj4+PiBMc3IgbWFpbGluZyBsaXN0DQo+ID4+Pj4+PiBMc3JAaWV0Zi5vcmcNCj4g Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo+ID4+Pj4+ DQo+ID4+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+Pj4+IExzciBtYWlsaW5nIGxpc3QNCj4gPj4+PiBMc3JAaWV0 Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0K PiA+Pj4NCj4gPj4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+IExzciBtYWlsaW5nIGxpc3QNCj4gPj4gTHNyQGlldGYub3Jn DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo+ID4NCj4g Pg0KDQo= From nobody Wed Oct 14 01:57:36 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FFD3A1400 for ; Wed, 14 Oct 2020 01:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 hMZeoQvsjizv for ; Wed, 14 Oct 2020 01:57:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3A43A1413 for ; Wed, 14 Oct 2020 01:57:32 -0700 (PDT) Received: from lhreml733-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E74EEE14AA6A18B448C1; Wed, 14 Oct 2020 09:57:30 +0100 (IST) Received: from dggeme701-chm.china.huawei.com (10.1.199.97) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Wed, 14 Oct 2020 09:57:29 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme701-chm.china.huawei.com (10.1.199.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 14 Oct 2020 16:57:27 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Wed, 14 Oct 2020 16:57:27 +0800 From: "Dongjie (Jimmy)" To: Peter Psenak , Robert Raszuk CC: Gyan Mishra , Ron Bonica , "lsr@ietf.org" , Jeff Tantsura , Yingzhen Qu Thread-Topic: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgAESbICAACKHAIAA7E2AgADTYwCAAWy/gIAAAz6AgAA7sgCAAOLhAIAAi8SAgAAopgCAA1loEIAFx4OAgAExPQCAAwtCgIACAvgg//+TI4CAAC4zgIAABLMAgAHRpEA= Date: Wed, 14 Oct 2020 08:57:27 +0000 Message-ID: <99e047acd56a47c593b6826bfcad952f@huawei.com> References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> <34c223a132f748e0a802d538ccd073b0@huawei.com> <7c75f1bf-5255-bd37-895b-e07b803ace6e@cisco.com> In-Reply-To: <7c75f1bf-5255-bd37-895b-e07b803ace6e@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 08:57:35 -0000 SGkgUm9iZXJ0IGFuZCBQZXRlciwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBMc3IgW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBldGVy IFBzZW5haw0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDEzLCAyMDIwIDc6NTUgUE0NCj4gVG86 IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0Pg0KPiBDYzogRG9uZ2ppZSAoSmltbXkp IDxqaWUuZG9uZ0BodWF3ZWkuY29tPjsgR3lhbiBNaXNocmENCj4gPGhheWFidXNhZ3NtQGdtYWls LmNvbT47IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+OyBsc3JAaWV0Zi5vcmc7DQo+ IEplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsgWWluZ3poZW4gUXUNCj4g PHlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5jb20+DQo+IFN1YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1ib25pY2EtbHNyLWlwLWZsZXhhbGdv LTAwLnR4dA0KPiANCj4gUm9iZXJ0LA0KPiANCj4gDQo+IE9uIDEzLzEwLzIwMjAgMTM6MzgsIFJv YmVydCBSYXN6dWsgd3JvdGU6DQo+ID4gUGV0ZXIsDQo+ID4NCj4gPiBJZiB0aGlzIGlzIHBlciBh cHAgaG93IGFyZSB0aGUgY29uc3RyYWludHPCoHNoYXJlZCBhY3Jvc3MgYXBwcyA/DQo+IA0KPiBG QUQgY29uc3RyYWludHMgYXJlIG9ubHkgdXNlZCBmb3IgY2FsY3VsYXRpbmcgdGhlIGZsZXgtYWxn byBwYXRoLg0KDQpBZ3JlZSB0aGF0IEZBRCBqdXN0IGRlZmluZXMgdGhlIGNvbnN0cmFpbnRzIGZv ciBwYXRoIGNvbXB1dGF0aW9uLCBhbmQgYXMgZGlzY3Vzc2VkIGNvbXB1dGF0aW9uIHdpdGggRmxl eC1BbGdvIGNvbnN0cmFpbnRzIG5lZWRzIHRvIGJlIGRvbmUgdXNpbmcgbm9kZXMgd2hpY2ggYmlu ZCB0aGUgRmxleC1BbGdvIHRvIHRoZSBzYW1lIGFwcC9kYXRhIHBsYW5lLg0KDQo+ID4NCj4gPiBT ZWUgd2UgaGF2ZSBzaW5nbGUgcGh5c2ljYWwgcmVzb3VyY2VzIChmb3IgZXhhbXBsZSBsaW5rcykg YW5kIHNpbmdsZQ0KPiA+IGludGVyZmFjZSBvdXRib3VuZCBxdWV1ZXMuIElmIEkgdXNlIHBlciBh cHAgZmxleC1hbGdvIGFuZMKgZG8gbm90IGhhdmUNCj4gPiBjZW50cmFsIGNvbnRyb2xsZXIgaG93 IGlzIHRoaXMgZ29pbmcgdG8gd29yayBpbiBwcmFjdGljZSBmb3IgYW55DQo+ID4gbmV0d29yayB3 aGljaCBhdHRlbXB0cyB0byB1c2UgbW9yZSB0aGVuIG9uZSBmb3J3YXJkaW5nIHNjaGVtYSB3aXRo DQo+ID4gZHluYW1pYyBjb25zdHJhaW50cyA/DQo+IA0KPiBmbGV4LWFsZ28gZGVmaW5lcyB0aGUg d2F5IHRvIGNhbGN1bGF0ZSBjb25zdHJhaW50IGJhc2VkIHBhdGhzIGluIGEgZGlzdHJpYnV0ZWQN Cj4gbWFubmVyIGFuZCBndWFyYW50ZWVzIHRoZSBsb29wIGZyZWUgZm9yd2FyZGluZyBvdmVyIHN1 Y2ggcGF0aC4NCj4gDQo+IFBvc3NpYmxlIHBlciBhcHAgYW5kL29yIHBlciBhbGdvIHJlc291cmNl IGFsbG9jYXRpb24gYXQgZWFjaCBob3AgaXMgbm90DQo+IHNvbWV0aGluZyB0aGF0IGZsZXgtYWxn byBzcGVjIGF0dGVtcHRzIHRvIHNvbHZlLiBUaGF0IGRvZXMgbm90IG1lYW4gaXQgaXMgbm90DQo+ IHBvc3NpYmxlLiBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGUgZmxleC1hbGdvIHNwZWMgdGhh dCB3b3VsZCBwcmV2ZW50IG9uZSB0byBkbw0KPiB0aGF0Lg0KDQpZZXMgZm9yIHRoYXQgcHVycG9z ZSBzb21lIGV4dGVuc2lvbnMgYmFzZWQgb24gRmxleC1BbGdvIHdvdWxkIGJlIG5lZWRlZC4NCg0K Rm9yIHBlci1BbGdvIHJlc291cmNlIGFsbG9jYXRpb24sIHBsZWFzZSByZWZlciB0byBkcmFmdC16 aHUtbHNyLWlzaXMtc3ItdnRuLWZsZXhhbGdvLTAxLiBGb3IgcGVyIGFwcCByZXNvdXJjZSBhbGxv Y2F0aW9uIGFuZCBpZGVudGlmaWNhdGlvbiAsIHlvdSBtYXkgcmVmZXIgdG8gZHJhZnQtZG9uZy1s c3Itc3ItZW5oYW5jZWQtdnBuLTA0LiANCg0KQmVzdCByZWdhcmRzLA0KSmllDQoNCj4gDQo+IHRo YW5rcywNCj4gUGV0ZXINCj4gDQo+ID4NCj4gPiBNYW55IHRoeCwNCj4gPiBSLg0KPiA+DQo+ID4N Cj4gPg0KPiA+IE9uIFR1ZSwgT2N0IDEzLCAyMDIwIGF0IDEwOjUyIEFNIFBldGVyIFBzZW5haw0K PiA+IDxwcHNlbmFrPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnDQo+ID4gPG1haWx0bzo0MGNp c2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQo+ID4gd3JvdGU6DQo+ID4NCj4gPiAgICAgSGkgSmlt bXksDQo+ID4NCj4gPiAgICAgT24gMTMvMTAvMjAyMCAxMDowMiwgRG9uZ2ppZSAoSmltbXkpIHdy b3RlOg0KPiA+ICAgICAgPiBIaSBQZXRlciwNCj4gPiAgICAgID4NCj4gPiAgICAgID4gVGhhbmtz IGZvciB5b3VyIHJlcGx5LiBQbGVhc2Ugc2VlIGZ1cnRoZXIgaW5saW5lOg0KPiA+ICAgICAgPg0K PiA+ICAgICAgPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiAgICAgID4+IEZyb206 IExzciBbbWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnDQo+ID4gICAgIDxtYWlsdG86bHNyLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUGV0ZXIgUHNlbmFrDQo+ID4gICAgICA+PiBT ZW50OiBNb25kYXksIE9jdG9iZXIgMTIsIDIwMjAgNDozOSBQTQ0KPiA+ICAgICAgPj4gVG86IERv bmdqaWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbQ0KPiA+ICAgICA8bWFpbHRvOmppZS5k b25nQGh1YXdlaS5jb20+PjsgUm9uIEJvbmljYQ0KPiA+ICAgICAgPj4gPHJib25pY2FAanVuaXBl ci5uZXQgPG1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0Pj47IFlpbmd6aGVuIFF1DQo+ID4gICAg IDx5aW5nemhlbi5xdUBmdXR1cmV3ZWkuY29tIDxtYWlsdG86eWluZ3poZW4ucXVAZnV0dXJld2Vp LmNvbT4+Ow0KPiBHeWFuDQo+ID4gICAgICA+PiBNaXNocmEgPGhheWFidXNhZ3NtQGdtYWlsLmNv bQ0KPiA8bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4+DQo+ID4gICAgICA+PiBDYzogbHNy QGlldGYub3JnIDxtYWlsdG86bHNyQGlldGYub3JnPjsgSmVmZiBUYW50c3VyYQ0KPiA+ICAgICA8 amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20gPG1haWx0bzpqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4+ DQo+ID4gICAgICA+PiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3INCj4gPiAgICAgID4+IGRyYWZ0LWJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDAudHh0 DQo+ID4gICAgICA+Pg0KPiA+ICAgICAgPj4gSGkgSmltbXksDQo+ID4gICAgICA+Pg0KPiA+ICAg ICAgPj4gT24gMTAvMTAvMjAyMCAwNTowNSwgRG9uZ2ppZSAoSmltbXkpIHdyb3RlOg0KPiA+ICAg ICAgPj4+IEhpIFBldGVyLA0KPiA+ICAgICAgPj4+DQo+ID4gICAgICA+Pj4gVGhhbmtzIGZvciB5 b3VyIHJlcGx5LiBJdCBhbGlnbnMgd2l0aCBteSB1bmRlcnN0YW5kaW5nIG9mIEZBRCwNCj4gPiAg ICAgd2hpY2ggaXMganVzdCBhDQo+ID4gICAgICA+PiBzZXQgb2YgY29uc3RyYWludHMgZm9yIHBh dGggY29tcHV0YXRpb24uIFRodXMgb25lIEZsZXgtQWxnbyBJRA0KPiA+ICAgICBjb3VsZCBiZSB1 c2VkDQo+ID4gICAgICA+PiB3aXRoIG11bHRpcGxlIGRpZmZlcmVudCBkYXRhIHBsYW5lcy4gSXMg dGhpcyB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQo+ID4gICAgICA+Pg0KPiA+ICAgICAgPj4gY29y cmVjdC4NCj4gPiAgICAgID4+DQo+ID4gICAgICA+Pj4NCj4gPiAgICAgID4+PiBJZiBzbywgbXkg cXVlc3Rpb24gaXMgYWJvdXQgdGhlIHNjZW5hcmlvIGJlbG93Og0KPiA+ICAgICAgPj4+DQo+ID4g ICAgICA+Pj4gQSBncm91cCBvZiBub2RlcyBpbiBhIG5ldHdvcmsgc3VwcG9ydCBGQS0xMjgsIGEg c3ViLWdyb3VwIG9mDQo+ID4gICAgIHRoZW0gYmluZA0KPiA+ICAgICAgPj4gRkEtMTI4IHRvIFNS IFNJRHMsIGFub3RoZXIgc3ViLWdyb3VwIG9mIHRoZW0gYmluZCBGQS0xMjggdG8gSVANCj4gPiAg ICAgYWRkcmVzcy4NCj4gPiAgICAgID4+DQo+ID4gICAgICA+PiBqdXN0IHRvIHVzZSB0aGUgY29y cmVjdCB0ZXJtaW5vbG9neSwgd2Ugc2hvdWxkIHVzZSAicGFydGljaXBhdGUiDQo+ID4gICAgIGlu c3RlYWQgb2YNCj4gPiAgICAgID4+ICJzdXBwb3J0Ii4NCj4gPiAgICAgID4NCj4gPiAgICAgID4g QWdyZWUuDQo+ID4gICAgICA+DQo+ID4gICAgICA+Pg0KPiA+ICAgICAgPj4+IFdoZW4gb25lIG5v ZGUgY29tcHV0ZSBhbiBTUiBwYXRoIHRvIGEgZGVzdGluYXRpb24sIGNhbiBpdA0KPiA+ICAgICBj b21wdXRlIHRoZSBwYXRoDQo+ID4gICAgICA+PiB0byBvbmx5IHBhc3MgdGhlIG5vZGVzIHdoaWNo IGJpbmQgRkEtMTI4IHRvIFNSIFNJRHMsIGFuZCBhdm9pZCB0aGUNCj4gPiAgICAgID4+IG5vZGVz ID53aGljaCBiaW5kIEZBLTEyOCB0byBJUCBhZGRyZXNzPyBJZiBzbywgaG93IGNvdWxkIHRoaXMN Cj4gPiAgICAgbm9kZSBrbm93IHRoZQ0KPiA+ICAgICAgPj4gYmluZGluZyBvZiBGQSB0byBkaWZm ZXJlbnQgZGF0YSBwbGFuZXMgb24gb3RoZXIgbm9kZXM/DQo+ID4gICAgICA+Pg0KPiA+ICAgICAg Pj4gYWdhaW4sIGl0IGlzIHRoZSBwYXJ0aWNpcGF0aW9uIHByb2JsZW0uDQo+ID4gICAgICA+Pg0K PiA+ICAgICAgPj4gTm9kZXMgdGhhdCBwYXJ0aWNpcGF0ZSBpbiB0aGUgU1IgRmxleC1hbGdvIDEy OCB3aWxsIGFkdmVydGlzZQ0KPiA+ICAgICB0aGUgcGFydGljaXBhdGlvbg0KPiA+ICAgICAgPj4g dXNpbmcgdGhlIFNSLUFsZ29yaXRobSBTdWItVExWLiBPbmx5IHRoZXNlIG5vZGVzIHdpbGwgYmUg dXNlZA0KPiA+ICAgICBkdXJpbmcgdGhlIFNSDQo+ID4gICAgICA+PiBmbGV4LWFsZ28gY29tcHV0 YXRpb24gZm9yIGFsZ28gMTI4Lg0KPiA+ICAgICAgPj4NCj4gPiAgICAgID4+IE5vZGVzIHRoYXQg cGFydGljaXBhdGUgaW4gSVAgZmxleC1hbGdvIDEyOCB3aWxsIGFkdmVydGlzZSB0aGUNCj4gPiAg ICAgcGFydGljaXBhdGlvbiB1c2luZw0KPiA+ICAgICAgPj4gdGhlIElHUCBBbGdvcml0aG0gU3Vi LVRMVi4gT25seSB0aGVzZSBub2RlcyB3aWxsIGJlIHVzZWQgZHVyaW5nDQo+ID4gICAgIHRoZSBJ UCBmbGV4LWFsZ28NCj4gPiAgICAgID4+IGNvbXB1dGF0aW9uIGZvciBhbGdvIDEyOC4NCj4gPiAg ICAgID4NCj4gPiAgICAgID4gQWdyZWUgdGhhdCBpZiBwYXJ0aWNpcGF0aW9uIHRvIEZsZXgtQWxn byBpcyBhZHZlcnRpc2VkIGluIGEgZGF0YQ0KPiA+ICAgICBwbGFuZSBzcGVjaWZpYyBtYW5uZXIs IHRoZW4gcGF0aCBjb21wdXRhdGlvbiB3aXRoIEZsZXgtQWxnbw0KPiA+ICAgICBjb25zdHJhaW50 cyBjb3VsZCBiZSBkb25lIG9ubHkgdXNpbmcgbm9kZXMgd2hpY2ggYmluZCB0aGUgRmxleC1BbGdv DQo+ID4gICAgIHRvIHRoZSBzYW1lIGRhdGEgcGxhbmUuDQo+ID4NCj4gPiAgICAgaXQncyBwZXIg YXBwLCBub3QgcGVyIGRhdGEgcGxhbmUsIGJ1dCB5ZXMsIHRoYXQgaXMgd2hhdCB0aGUgYmFzZQ0K PiA+ICAgICBmbGV4LWFsZ28gc3BlYyBtYW5kYXRlcy4NCj4gPg0KPiA+ICAgICAgPg0KPiA+ICAg ICAgPiBBcyBSb2JlcnQgYXNrZWQgYW5kIHlvdSBjb25maXJtZWQsIHRoaXMgaW1wbGllcyBlYWNo IGRhdGEgcGxhbmUNCj4gPiAgICAgbmVlZHMgdG8gYmUgdHJlYXRlZCBhcyBhbiBpbmRlcGVuZGVu dCBhcHBsaWNhdGlvbiBvZiBGbGV4LUFsZ28uIFdlDQo+ID4gICAgIGhhdmUgU1ItQWxnb3JpdGht IHN1Yi1UTFYgYW5kIElQIEFsZ29yaXRobSBzdWItVExWLCB3aGlsZSB0aGVyZSBhcmUNCj4gPiAg ICAgYWN0dWFsbHkgbW9yZSBkYXRhIHBsYW5lcyB0byBiZSBjb25zaWRlcmVkOiBTUi1NUExTLCBT UnY2LCBJUHY0LA0KPiA+ICAgICBJUHY2LCBldGMuLCBkb2VzIHRoaXMgbWVhbiB0aGF0IEZsZXgt QWxnbyBwYXJ0aWNpcGF0aW9uIG5lZWRzIHRvIGJlDQo+ID4gICAgIGFkdmVydGlzZWQgZm9yIFNS LU1QTFMsIFNSdjYsIElQdjQsIElQdjYsIGV0Yy4gc2VwYXJhdGVseT8NCj4gPg0KPiA+ICAgICB5 ZXMsIGl0IG5lZWRzIHRvIGJlIGFkdmVydGlzZWQgcGVyIGFwcC4gV2UgaGF2ZSBTUiBzcGVjaWZp YyBhbGdvDQo+ID4gICAgIHBhcnRpY2lwYXRpb24sIHdlIG5lZWQgb25lIGZvciBJUCBhcyBwcm9w b3NlZCBpbiBSb24ncyBkcmFmdC4NCj4gPg0KPiA+ICAgICBSZWdhcmRpbmcgSVB2NCB2cyBJUHY2 LCBpdCdzIHVwIHRvIHRoZSBhdXRob3JzIHdoZXRoZXIgdGhleSB3YW50IHRvDQo+ID4gICAgIG1h a2UNCj4gPiAgICAgdGhlIHBhcnRpY2lwYXRpb24gZm9yIElQIGZsZXgtYWxnbyB0b3BvbG9neSBz cGVjaWZpYyBvciB0b3BvbG9neQ0KPiA+ICAgICBpbmRlcGVuZGVudCwgYm90aCBjb3VsZCB3b3Jr Lg0KPiA+DQo+ID4gICAgIEhlcmUncyB0aGUgdGV4dCBmcm9tIHRoZSBiYXNlIGZsZXJ4LWFsZ28g ZHJhZnQ6DQo+ID4NCj4gPiAgICAgMTAuMi7CoCBBZHZlcnRpc2VtZW50IG9mIE5vZGUgUGFydGlj aXBhdGlvbiBmb3IgT3RoZXIgQXBwbGljYXRpb25zDQo+ID4NCj4gPiAgICAgIMKgIMKgIFRoaXMg c2VjdGlvbiBkZXNjcmliZXMgY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byBob3cgb3RoZXINCj4g PiAgICAgIMKgIMKgIGFwcGxpY2F0aW9ucyBjYW4gYWR2ZXJ0aXNlIHRoZWlyIHBhcnRpY2lwYXRp b24gaW4gYSBzcGVjaWZpYyBGbGV4LQ0KPiA+ICAgICAgwqAgwqAgQWxnb3JpdGhtLg0KPiA+DQo+ ID4gICAgICDCoCDCoCBBcHBsaWNhdGlvbi1zcGVjaWZpYyBGbGV4LUFsZ29yaXRobSBwYXJ0aWNp cGF0aW9uDQo+ID4gICAgIGFkdmVydGlzZW1lbnRzIE1BWQ0KPiA+ICAgICAgwqAgwqAgYmUgdG9w b2xvZ3kgc3BlY2lmaWMgb3IgTUFZIGJlIHRvcG9sb2d5IGluZGVwZW5kZW50LCBkZXBlbmRpbmcN Cj4gPiAgICAgb24gdGhlDQo+ID4gICAgICDCoCDCoCBhcHBsaWNhdGlvbiBpdHNlbGYuDQo+ID4N Cj4gPiAgICAgIMKgIMKgIEFwcGxpY2F0aW9uLXNwZWNpZmljIGFkdmVydGlzZW1lbnQgZm9yIEZs ZXgtQWxnb3JpdGhtDQo+IHBhcnRpY2lwYXRpb24NCj4gPiAgICAgIMKgIMKgIE1VU1QgYmUgZGVm aW5lZCBmb3IgZWFjaCBhcHBsaWNhdGlvbiBhbmQgaXMgb3V0c2lkZSBvZiB0aGUgc2NvcGUNCj4g b2YNCj4gPiAgICAgIMKgIMKgIHRoaXMgZG9jdW1lbnQuDQo+ID4NCj4gPiAgICAgdGhhbmtzLA0K PiA+ICAgICBQZXRlcg0KPiA+DQo+ID4NCj4gPiAgICAgID4NCj4gPiAgICAgID4gQmVzdCByZWdh cmRzLA0KPiA+ICAgICAgPiBKaWUNCj4gPiAgICAgID4NCj4gPiAgICAgID4+DQo+ID4gICAgICA+ PiB0aGFua3MsDQo+ID4gICAgICA+PiBQZXRlcg0KPiA+ICAgICAgPj4NCj4gPiAgICAgID4+Pg0K PiA+ICAgICAgPj4+IEJlc3QgcmVnYXJkcywNCj4gPiAgICAgID4+PiBKaWUNCj4gPiAgICAgID4+ Pg0KPiA+ICAgICAgPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ICAgICAgPj4+ PiBGcm9tOiBMc3IgW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZw0KPiA+ICAgICA8bWFpbHRv Omxzci1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFBldGVyIFBzZW5haw0KPiA+ICAg ICAgPj4+PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgOSwgMjAyMCAxMTo1OCBQTQ0KPiA+ICAgICAg Pj4+PiBUbzogRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29tDQo+ID4gICAgIDxt YWlsdG86amllLmRvbmdAaHVhd2VpLmNvbT4+OyBSb24gQm9uaWNhDQo+ID4gICAgICA+Pj4+IDxy Ym9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmcNCj4gPiAgICAgPG1haWx0bzo0MGp1 bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPj47IFlpbmd6aGVuIFF1DQo+ID4gICAgICA+Pj4+IDx5 aW5nemhlbi5xdUBmdXR1cmV3ZWkuY29tDQo+ID4gICAgIDxtYWlsdG86eWluZ3poZW4ucXVAZnV0 dXJld2VpLmNvbT4+OyBHeWFuIE1pc2hyYQ0KPiA+ICAgICA8aGF5YWJ1c2Fnc21AZ21haWwuY29t IDxtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tPj4NCj4gPiAgICAgID4+Pj4gQ2M6IGxzckBp ZXRmLm9yZyA8bWFpbHRvOmxzckBpZXRmLm9yZz47IEplZmYgVGFudHN1cmENCj4gPiAgICAgPGpl ZmZ0YW50LmlldGZAZ21haWwuY29tIDxtYWlsdG86amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+Pg0K PiA+ICAgICAgPj4+PiBTdWJqZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3INCj4gPiAgICAgID4+Pj4gZHJhZnQtYm9uaWNhLWxzci1pcC1mbGV4YWxnby0wMC50 eHQNCj4gPiAgICAgID4+Pj4NCj4gPiAgICAgID4+Pj4gSGkgSmltbXksDQo+ID4gICAgICA+Pj4+ DQo+ID4gICAgICA+Pj4+DQo+ID4gICAgICA+Pj4+wqAgwqAgwqBPbiAwOS8xMC8yMDIwIDA0OjU5 LCBEb25namllIChKaW1teSkgd3JvdGU6DQo+ID4gICAgICA+Pj4+PiBIaSBSb24sDQo+ID4gICAg ICA+Pj4+Pg0KPiA+ICAgICAgPj4+Pj4gVGhhbmtzIGZvciBleHBsYWluaW5nIHRoZSBkaWZmZXJl bmNlIGJldHdlZW4gSVAgRmxleC1BbGdvIGFuZA0KPiBTUg0KPiA+ICAgICAgPj4+Pj4gRmxleC1h bGdvLiBBcw0KPiA+ICAgICAgPj4+PiB5b3Ugc2FpZCwgdGhlIG1ham9yIGRpZmZlcmVuY2UgaXMg dGhlIGRhdGEgcGxhbmUuDQo+ID4gICAgICA+Pj4+Pg0KPiA+ICAgICAgPj4+Pj4gSWYgbXkgdW5k ZXJzdGFuZGluZyBpcyBjb3JyZWN0LCBmb3Igb25lIEZsZXgtQWxnbyB0byBiZSB1c2VkDQo+ID4g ICAgICA+Pj4+PiBjb3JyZWN0bHksIHRoZSBzZXQNCj4gPiAgICAgID4+Pj4gb2Ygbm9kZXMgbmVl ZCB0byBhcHBseSBjb25zaXN0ZW50IGNvbnN0cmFpbnRzIGluIGNvbXB1dGF0aW9uLA0KPiBhbmQN Cj4gPiAgICAgID4+Pj4gYmluZCB0aGUgRkFEIHRvIHRoZSBzYW1lIGRhdGEgcGxhbmUuDQo+ID4g ICAgICA+Pj4+Pg0KPiA+ICAgICAgPj4+Pj4gSXMgaXQgcG9zc2libGUgdGhhdCBkaWZmZXJlbnQg bm9kZXMgbWF5IHVzZSB0aGUgc2FtZQ0KPiA+ICAgICBGbGV4LUFsZ28gd2l0aA0KPiA+ICAgICAg Pj4+Pj4gZGlmZmVyZW50DQo+ID4gICAgICA+Pj4+IGRhdGEgcGxhbmUsIGUuZy4gc29tZSB3aXRo IFNSLU1QTFMsIHNvbWUgd2l0aCBTUnY2LCBhbmQgc29tZQ0KPiB3aXRoDQo+ID4gICAgICA+Pj4+ IHB1cmUgSVAgZXRjLiwgb3IgZWFjaCBGbGV4LUFsZ28gaXMgYWx3YXlzIGFzc29jaWF0ZWQgd2l0 aCBvbmx5IG9uZQ0KPiA+ICAgICAgPj4+PiBkYXRhIHBsYW5lPyBJbiB0aGUgZm9ybWVyIGNhc2Us IHNob3VsZCB0aGUgZmxleC1hbGdvDQo+ID4gICAgIGRlZmluaXRpb24gYWxzbw0KPiA+ICAgICAg Pj4+PiBpbmRpY2F0ZSB0aGUgZGF0YSBwbGFuZShzKSB0byBiZSB1c2VkIHdpdGggdGhlIGZsZXgt YWxnbz8NCj4gPiAgICAgID4+Pj4NCj4gPiAgICAgID4+Pj4gbGV0IG1lIHJlc3BvbmQgdG8gdGhp cyBxdWVyeSwgYXMgdGhpcyBpcyBub3Qgc3BlY2lmaWMgdG8gUm9uJ3MNCj4gPiAgICAgZHJhZnQu DQo+ID4gICAgICA+Pj4+DQo+ID4gICAgICA+Pj4+IEZBRCBpcyBkYXRhIHBsYW5lIGFnbm9zdGlj IGFuZCBpcyB1c2VkIGJ5IGFsbCBvZiB0aGVtLg0KPiA+ICAgICAgPj4+Pg0KPiA+ICAgICAgPj4+ PiB0aGFua3MsDQo+ID4gICAgICA+Pj4+IFBldGVyDQo+ID4gICAgICA+Pj4+DQo+ID4gICAgICA+ Pj4+Pg0KPiA+ICAgICAgPj4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+ICAgICAgPj4+Pj4gSmllDQo+ ID4gICAgICA+Pj4+Pg0KPiA+ICAgICAgPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gICAgICA+Pj4+Pj4gRnJvbTogTHNyIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmcN Cj4gPiAgICAgPG1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBSb24g Qm9uaWNhDQo+ID4gICAgICA+Pj4+Pj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDQsIDIwMjAgNDoz NCBBTQ0KPiA+ICAgICAgPj4+Pj4+IFRvOiBZaW5nemhlbiBRdSA8eWluZ3poZW4ucXVAZnV0dXJl d2VpLmNvbQ0KPiA+ICAgICA8bWFpbHRvOnlpbmd6aGVuLnF1QGZ1dHVyZXdlaS5jb20+PjsgUGV0 ZXIgUHNlbmFrDQo+ID4gICAgICA+Pj4+Pj4gPHBwc2VuYWtAY2lzY28uY29tIDxtYWlsdG86cHBz ZW5ha0BjaXNjby5jb20+PjsgR3lhbg0KPiBNaXNocmENCj4gPiAgICAgPGhheWFidXNhZ3NtQGdt YWlsLmNvbSA8bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4+DQo+ID4gICAgICA+Pj4+Pj4g Q2M6IGxzckBpZXRmLm9yZyA8bWFpbHRvOmxzckBpZXRmLm9yZz47IEplZmYgVGFudHN1cmENCj4g PiAgICAgPGplZmZ0YW50LmlldGZAZ21haWwuY29tIDxtYWlsdG86amVmZnRhbnQuaWV0ZkBnbWFp bC5jb20+Pg0KPiA+ICAgICAgPj4+Pj4+IFN1YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcg0KPiA+ICAgICAgPj4+Pj4+IGRyYWZ0LWJvbmljYS1sc3ItaXAt ZmxleGFsZ28tMDAudHh0DQo+ID4gICAgICA+Pj4+Pj4NCj4gPiAgICAgID4+Pj4+PiBIaSBZaW5n emhlbiwNCj4gPiAgICAgID4+Pj4+Pg0KPiA+ICAgICAgPj4+Pj4+IElQIEZsZXhpYmxlIEFsZ29y aXRobXMgYXJlIGxpa2UgU1IgRmxleGlibGUgQWxnb3JpdGhtcyBpbiB0aGUNCj4gPiAgICAgID4+ Pj4+PiBmb2xsb3dpbmcNCj4gPiAgICAgID4+Pj4gcmVzcGVjdHM6DQo+ID4gICAgICA+Pj4+Pj4N Cj4gPiAgICAgID4+Pj4+PiAtIExpbmtzIGhhdmUgSUdQIG1ldHJpY3MsIFRFIG1ldHJpY3MsIGRl bGF5IG1ldHJpY3MgYW5kDQo+ID4gICAgICA+Pj4+Pj4gYWRtaW5pc3RyYXRpdmUgY29sb3JzDQo+ ID4gICAgICA+Pj4+Pj4gLSBGQURzIGRlZmluZSBGbGV4aWJsZSBBbGdvcml0aG1zDQo+ID4gICAg ICA+Pj4+Pj4NCj4gPiAgICAgID4+Pj4+PiBNb3JlIHNwZWNpZmljYWxseSwgdGhlIEZBRDoNCj4g PiAgICAgID4+Pj4+Pg0KPiA+ICAgICAgPj4+Pj4+IC0gSW5kaWNhdGVzIHdoaWNoIG1ldHJpYyB0 eXBlIHRoZSBGbGV4aWJsZSBBbGdvcml0aG0gdXNlcw0KPiA+ICAgICAgPj4+Pj4+IC0gU3BlY2lm aWVzIGNvbnN0cmFpbnRzIGluIHRlcm1zIG9mIGxpbmsgY29sb3JzIHRoYXQgYXJlDQo+ID4gICAg IGluY2x1ZGVkDQo+ID4gICAgICA+Pj4+Pj4gb3IgZXhjbHVkZWQgZnJvbSB0aGUgRmxleGlibGUg QWxnb3JpdGhtLg0KPiA+ICAgICAgPj4+Pj4+DQo+ID4gICAgICA+Pj4+Pj4gVGhlIHNpZ25pZmlj YW50IGRpZmZlcmVuY2UgYmV0d2VlbiBJUCBGbGV4aWJsZSBBbGdvcml0aG1zIGFuZA0KPiBTUg0K PiA+ICAgICAgPj4+Pj4+IEZsZXhpYmxlIEFsZ29yaXRobXMgaXM6DQo+ID4gICAgICA+Pj4+Pj4N Cj4gPiAgICAgID4+Pj4+PiAtIFNSIEZsZXhpYmxlIEFsZ29yaXRobXMgYmluZCBGQURzIHRvIHBy ZWZpeCBTSURzIG9yIFNSdjYNCj4gPiAgICAgbG9jYXRvcnMNCj4gPiAgICAgID4+Pj4+PiAtIElQ IEZsZXhpYmxlIEFsZ29yaXRobXMgYmluZCBGQURzIHRvIElQdjQgb3IgSVB2NiBhZGRyZXNzZXMu DQo+ID4gICAgICA+Pj4+Pj4NCj4gPiAgICAgID4+Pj4+PiBTbywgSVAgRmxleGlibGUgQWxnb3Jp dGhtcyBjYW4gYmUgZGVwbG95ZWQgaW4gYW55IElQDQo+ID4gICAgIG5ldHdvcmssIGV2ZW4NCj4g PiAgICAgID4+Pj4+PiBpbiB0aGUgYWJzZW5jZSBvZiBTUi4NCj4gPiAgICAgID4+Pj4+Pg0KPiA+ ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgUm8NCj4gbg0KPiA+ICAgICAgPj4+Pj4+DQo+ID4gICAgICA+ Pj4+Pj4NCj4gPiAgICAgID4+Pj4+PiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+ID4gICAg ICA+Pj4+Pj4NCj4gPiAgICAgID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ICAgICAgPj4+Pj4+IEZyb206IFlpbmd6aGVuIFF1IDx5aW5nemhlbi5xdUBmdXR1cmV3ZWkuY29t DQo+ID4gICAgIDxtYWlsdG86eWluZ3poZW4ucXVAZnV0dXJld2VpLmNvbT4+DQo+ID4gICAgICA+ Pj4+Pj4gU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMywgMjAyMCAyOjA4IFBNDQo+ID4gICAgICA+ Pj4+Pj4gVG86IFBldGVyIFBzZW5hayA8cHBzZW5ha0BjaXNjby5jb20NCj4gPiAgICAgPG1haWx0 bzpwcHNlbmFrQGNpc2NvLmNvbT4+OyBHeWFuIE1pc2hyYQ0KPiA+ICAgICAgPj4+Pj4+IDxoYXlh YnVzYWdzbUBnbWFpbC5jb20NCj4gPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+PjsgUm9u DQo+ID4gICAgIEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldCA8bWFpbHRvOnJib25pY2FAanVu aXBlci5uZXQ+Pg0KPiA+ICAgICAgPj4+Pj4+IENjOiBsc3JAaWV0Zi5vcmcgPG1haWx0bzpsc3JA aWV0Zi5vcmc+OyBKZWZmIFRhbnRzdXJhDQo+ID4gICAgIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNv bSA8bWFpbHRvOmplZmZ0YW50LmlldGZAZ21haWwuY29tPj4NCj4gPiAgICAgID4+Pj4+PiBTdWJq ZWN0OiBSZTogW0xzcl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gPiAgICAg ID4+Pj4+PiBkcmFmdC1ib25pY2EtbHNyLWlwLWZsZXhhbGdvLTAwLnR4dA0KPiA+ICAgICAgPj4+ Pj4+DQo+ID4gICAgICA+Pj4+Pj4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250 ZW50XQ0KPiA+ICAgICAgPj4+Pj4+DQo+ID4gICAgICA+Pj4+Pj4NCj4gPiAgICAgID4+Pj4+PiBI aSBQZXRlciwNCj4gPiAgICAgID4+Pj4+Pg0KPiA+ICAgICAgPj4+Pj4+IFVzaW5nIGZsZXgtYWxn bywgYSBTUnY2IGxvY2F0b3IgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHNpbmdsZQ0KPiA+ICAg ICAgPj4+Pj4+IGFsZ28sIHdoaWNoIG1lYW5zIGFuIElQdjYgb3IgSVB2NCBhZGRyZXNzIGNhbiBh bHNvIGJlDQo+IGFzc29jaWF0ZWQNCj4gPiAgICAgID4+Pj4+PiB3aXRoIGEgc2luZ2xlIGFsZ28u IFNvIG15IHVuZGVyc3RhbmRpbmcgaXMgUm9uJ3MgcHJvcG9zYWwgaXMNCj4gPiAgICAgbWFraW5n DQo+ID4gICAgICA+Pj4+Pj4gdGhlDQo+ID4gICAgICA+Pj4+IGNvbmZpZ3VyYXRpb24gb2YgZmxl eC1hbGdvIGVhc2llcj8NCj4gPiAgICAgID4+Pj4+PiBJbnN0ZWFkIG9mIHVzaW5nIHRoZSBleGNs dWRlIG9yIGluY2x1ZGUgbGlzdCB5b3UgY2FuIGNvbmZpZ3VyZSBhDQo+ID4gICAgICA+Pj4+Pj4g bG9vcGJhY2sgYWRkcmVzcyB0byBhIGZsZXgtYWxnbyBkaXJlY3RseT8NCj4gPiAgICAgID4+Pj4+ Pg0KPiA+ICAgICAgPj4+Pj4+IFRoYW5rcywNCj4gPiAgICAgID4+Pj4+PiBZaW5nemhlbg0KPiA+ ICAgICAgPj4+Pj4+DQo+ID4gICAgICA+Pj4+Pj4gT24gMTAvMy8yMCwgMjo0NyBBTSwgIlBldGVy IFBzZW5hayIgPHBwc2VuYWtAY2lzY28uY29tDQo+ID4gICAgIDxtYWlsdG86cHBzZW5ha0BjaXNj by5jb20+PiB3cm90ZToNCj4gPiAgICAgID4+Pj4+Pg0KPiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAg wqAgSGkgWWluZ3poZW4sDQo+ID4gICAgICA+Pj4+Pj4NCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKg IMKgIE9uIDAyLzEwLzIwMjAgMjI6MTUsIFlpbmd6aGVuIFF1IHdyb3RlOg0KPiA+ICAgICAgPj4+ Pj4+wqAgwqAgwqAgwqAgPiBIaSBQZXRlciwNCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4N Cj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4gTXkgdW5kZXJzdGFuZGluZyBvZiBmbGV4LWFs Z28gaXMgdGhhdCBmb3IgdHJhZmZpYw0KPiA+ICAgICBkZXN0aW5lZA0KPiA+ICAgICAgPj4+Pj4+ IHRvIGEgcHJlZml4IG9uIGEgcGFydGljdWxhciBhbGdvLCBpdCBjYW4gb25seSBiZSByb3V0ZWQg b24NCj4gPiAgICAgcm91dGVycw0KPiA+ICAgICAgPj4+Pj4+IGJlbG9uZyB0byB0aGF0IGFsZ28s IHdoaWNoIGFsc28gbWVhbnMgb25seSByb3V0ZXJzIGluIHRoYXQgYWxnbw0KPiA+ICAgICAgPj4+ Pj4+IGNhbGN1bGF0ZXMgaG93IHRvIHJlYWNoIHRoYXQgcHJlZml4IGFuZCBpbnN0YWxsIGl0IGlu dG8gdGhlDQo+ID4gICAgIHJvdXRpbmcNCj4gPiAgICAgID4+Pj4+PiB0YWJsZS4gSXQgc2VlbXMg dG8gbWUgdGhhdCB1c2luZyBmbGV4LWFsZ28gKHNlY3Rpb24gMTIgb2YgdGhlDQo+ID4gICAgICA+ Pj4+Pj4gZHJhZnQpIGl0J3MgcG9zc2libGUgdG8gaGF2ZSBhIGxvb3BiYWNrIGFkZHJlc3MgYXNz b2NpYXRlZCB3aXRoDQo+ID4gICAgICA+Pj4+Pj4gb25seSBvbmUgYWxnbywgcGxlYXNlIGNvcnJl Y3QgbWUgaWYgSSdtIG1pc3Npbmcgb3INCj4gbWlzdW5kZXJzdG9vZA0KPiA+ICAgICAgPj4gc29t ZXRoaW5nLg0KPiA+ICAgICAgPj4+Pj4+DQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCB5b3Ug YXJlIHJpZ2h0LiBUaGF0IGlzIGV4YWN0bHkgd2hhdCBpcyBiZWluZyBkb25lIGZvcg0KPiA+ICAg ICBmbGV4LWFsZ28gd2l0aA0KPiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgU1J2NiAtIGxvY2F0 b3IgaXMgYXNzb2NpYXRlZCB3aXRoIGEgc2luZ2xlIGFsZ28gb25seS4NCj4gPiAgICAgVGhlIHBy b3Bvc2FsDQo+ID4gICAgICA+PiB1c2VzDQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCB0aGUg c2FtZSBjb25jZXB0Lg0KPiA+ICAgICAgPj4+Pj4+DQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDC oCB0aGFua3MsDQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCBQZXRlcg0KPiA+ICAgICAgPj4+ Pj4+DQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCA+DQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDC oCDCoCA+IFRoYW5rcywNCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4gWWluZ3poZW4NCj4g PiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4NCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4g T24gMTAvMi8yMCwgOTo0MyBBTSwgIkxzciBvbiBiZWhhbGYgb2YgUGV0ZXINCj4gUHNlbmFrIg0K PiA+ICAgICAgPj4+Pj4+IDxsc3ItYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOmxzci1ib3VuY2Vz QGlldGYub3JnPiBvbg0KPiBiZWhhbGYgb2YNCj4gPiAgICAgID4+Pj4+PiBwcHNlbmFrPTQwY2lz Y28uY29tQGRtYXJjLmlldGYub3JnDQo+ID4gICAgIDxtYWlsdG86NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmc+Pg0KPiA+ICAgICAgPj4+Pj4+IHdyb3RlOg0KPiA+ICAgICAgPj4+Pj4+wqAgwqAg wqAgwqAgPg0KPiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgPsKgIMKgIMKgIEd5YW4sDQo+ID4g ICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCA+DQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCA+wqAg wqAgwqAgT24gMDIvMTAvMjAyMCAxODozMCwgR3lhbiBNaXNocmEgd3JvdGU6DQo+ID4gICAgICA+ Pj4+Pj7CoCDCoCDCoCDCoCA+wqAgwqAgwqAgPiBBbGwsDQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDC oCDCoCA+wqAgwqAgwqAgPg0KPiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgPsKgIMKgIMKgID4g V2l0aCBTUnY2IGFuZCBJUCBiYXNlZCBmbGV4IGFsZ28gYQ0KPiBnZW5lcmljDQo+ID4gICAgIHF1 ZXN0aW9uIGFzIGl0DQo+ID4gICAgICA+Pj4+IGFwcGxpZXMNCj4gPiAgICAgID4+Pj4+PiB0bw0K PiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgPsKgIMKgIMKgID4gYm90aC4gSXMgaXQgcG9zc2li bGUgdG8gaGF2ZSB3aXRoaW4gYSBzaW5nbGUNCj4gPiAgICAgSUdQIGRvbWFpbg0KPiA+ICAgICAg Pj4+PiBkaWZmZXJlbnQNCj4gPiAgICAgID4+Pj4+PiBzZXRzDQo+ID4gICAgICA+Pj4+Pj7CoCDC oCDCoCDCoCA+wqAgwqAgwqAgPiBvZiBub2RlcyBvciBzZWdtZW50cyBvZiB0aGUgbmV0d29yaw0K PiBydW5uaW5nDQo+ID4gICAgIGRpZmZlcmVudA0KPiA+ICAgICAgPj4+Pj4+IGFsZ29yaXRobXMu DQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCA+DQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDC oCA+wqAgwqAgwqAgYWJzb2x1dGVseS4NCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4NCj4g PiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID7CoCDCoCDCoCA+IEZyb20NCj4gPiAgICAgID4+Pj4+ PsKgIMKgIMKgIMKgID7CoCDCoCDCoCA+IGJvdGggZHJhZnRzIGl0IHNvdW5kcyBsaWtlIGFsbCBu b2RlcyBoYXZlDQo+IHRvDQo+ID4gICAgIGFncmVlIG9uDQo+ID4gICAgICA+PiBzYW1lDQo+ID4g ICAgICA+Pj4+Pj4gYWxnb3JpdGhtDQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCA+wqAgwqAg wqAgPiBzaW1pbGFyIHRvIGNvbmNlcHQgb2YgbWV0cmljIGFuZA0KPiByZWZlcmVuY2UNCj4gPiAg ICAgYmFuZHdpZHRoDQo+ID4gICAgICA+PiBhbGwNCj4gPiAgICAgID4+Pj4gaGF2ZSB0bw0KPiA+ ICAgICAgPj4+Pj4+IGhhdmUNCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID7CoCDCoCDCoCA+ IHRoZSBzYW1lIHN0eWxlIG1ldHJpYyBhbmQgcGxheSB0byB0aGUNCj4gc2FtZQ0KPiA+ICAgICBz aGVldCBvZg0KPiA+ICAgICAgPj4gbXVzaWMuDQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCA+ DQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCA+wqAgwqAgwqAgYWxsIHBhcnRpY2lwYXRpbmcg bm9kZXMgbmVlZCB0byBhZ3JlZSBvbiB0aGUNCj4gPiAgICAgZGVmaW5pdGlvbiBvZg0KPiA+ICAg ICAgPj4gdGhlDQo+ID4gICAgICA+Pj4+Pj4gZmxleC1hbGdvDQo+ID4gICAgICA+Pj4+Pj7CoCDC oCDCoCDCoCA+wqAgwqAgwqAgYW5kIGFkdmVydGlzZSB0aGUgcGFydGljaXBhdGlvbi4gVGhhdCdz IGl0Lg0KPiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgPg0KPiA+ICAgICAgPj4+Pj4+wqAgwqAg wqAgwqAgPsKgIMKgIMKgID4gSWYgdGhlcmUgd2FzDQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDC oCA+wqAgwqAgwqAgPiBhIHdheSB0byB1c2UgbXVsdGlwbGUgYWxnb3JpdGhtcw0KPiA+ICAgICBz aW11bHRhbmVvdXNseSBiYXNlZA0KPiA+ICAgICAgPj4gb24NCj4gPiAgICAgID4+Pj4gU0ZDDQo+ ID4gICAgICA+Pj4+Pj4gb3Igc2VydmljZXMNCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID7C oCDCoCDCoCA+IGFuZCBpbnN0YW50aWF0aW9uIG9mIHNwZWNpZmljIGFsZ29yaXRobQ0KPiA+ICAg ICBiYXNlZCBvbiBzZXJ2aWNlDQo+ID4gICAgICA+PiB0bw0KPiA+ICAgICAgPj4+PiBiZQ0KPiA+ ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgPsKgIMKgIMKgID4gcmVuZGVyZWQuwqAgRG9pbmcgc28g d2l0aG91dCBjYXVzaW5nIGENCj4gPiAgICAgcm91dGluZyBsb29wIG9yDQo+ID4gICAgICA+PiBz dWINCj4gPiAgICAgID4+Pj4+PiBvcHRpbWFsDQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCA+ wqAgwqAgwqAgPiByb3V0aW5nLg0KPiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgPg0KPiA+ICAg ICAgPj4+Pj4+wqAgwqAgwqAgwqAgPsKgIMKgIMKgIHlvdSBjYW4gY2VydGFpbmx5IHVzZSBtdWx0 aXBsZSBhbGdvcml0aG1zDQo+ID4gICAgIHNpbXVsdGFuZW91c2x5DQo+ID4gICAgICA+PiBhbmQN Cj4gPiAgICAgID4+Pj4gdXNlDQo+ID4gICAgICA+Pj4+Pj4gYWxnbw0KPiA+ICAgICAgPj4+Pj4+ wqAgwqAgwqAgwqAgPsKgIMKgIMKgIHNwZWNpZmljIHBhdGhzIHRvIGZvcndhcmQgc3BlY2lmaWMg dHJhZmZpYw0KPiA+ICAgICBvdmVyIGl0LiBIb3cgdGhhdA0KPiA+ICAgICAgPj4gaXMNCj4gPiAg ICAgID4+Pj4gZG9uZQ0KPiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgPsKgIMKgIMKgIGZyb20g dGhlIGZvcndhcmRpbmcgcGVyc3BlY3RpdmUgZGVwZW5kcw0KPiBpbiB3aGljaA0KPiA+ICAgICAg Pj4+PiBmb3J3YXJkaW5nDQo+ID4gICAgICA+Pj4+Pj4gcGxhbmUgeW91DQo+ID4gICAgICA+Pj4+ Pj7CoCDCoCDCoCDCoCA+wqAgwqAgwqAgdXNlLiBGbGV4LWFsZ28gY29udHJvbCBwbGFuZSBpcyBp bmRlcGVuZGVudA0KPiBvZiB0aGUNCj4gPiAgICAgID4+IGZvcndhcmRpbmcNCj4gPiAgICAgID4+ Pj4+PiBwbGFuZS4NCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4NCj4gPiAgICAgID4+Pj4+ PsKgIMKgIMKgIMKgID4NCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID7CoCDCoCDCoCA+SSB0 aG91Z2h0IHdpdGggZmxleCBhbGdvIHRoYXQgdGhlcmUgZXhpc3RzIGENCj4gPiAgICAgZmVhdHVy ZSB0aGF0DQo+ID4gICAgICA+PiBvbg0KPiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgPsKgIMKg IMKgID4gZWFjaCBob3AgdGhlcmUgaXMgYSB3YXkgdG8gc3BlY2lmeSB3aGljaA0KPiA+ICAgICBh bGdvIHRvIHVzZQ0KPiA+ICAgICAgPj4gaG9wIGJ5DQo+ID4gICAgICA+Pj4+IGhvcA0KPiA+ICAg ICAgPj4+Pj4+IHNpbWlsYXINCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID7CoCDCoCDCoCA+ IHRvIGEgaG9wIGJ5IGhvcCBwb2xpY3kgYmFzZWQgcm91dGluZy4NCj4gPiAgICAgID4+Pj4+PsKg IMKgIMKgIMKgID4NCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID7CoCDCoCDCoCBubywgdGhl cmUgaXMgbm8gaG9wLWJ5LWhvcCBjbGFzc2lmaWNhdGlvbiwNCj4gdGhhdCBpcw0KPiA+ICAgICAg Pj4gcHJvYmxlbWF0aWMNCj4gPiAgICAgID4+Pj4gYW5kDQo+ID4gICAgICA+Pj4+Pj4gZG9lcw0K PiA+ICAgICAgPj4+Pj4+wqAgwqAgwqAgwqAgPsKgIMKgIMKgIG5vdCBzY2FsZSBmb3IgaGlnaCBz cGVlZHMuIENsYXNzaWZpY2F0aW9uIGlzDQo+ID4gICAgIGRvbmUgYXQgdGhlDQo+ID4gICAgICA+ Pj4+IGluZ3Jlc3Mgb25seS4NCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4NCj4gPiAgICAg ID4+Pj4+PsKgIMKgIMKgIMKgID7CoCDCoCDCoCB0aGFua3MsDQo+ID4gICAgICA+Pj4+Pj7CoCDC oCDCoCDCoCA+wqAgwqAgwqAgUGV0ZXINCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4NCj4g PiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID7CoCDCoCDCoCA+DQo+ID4gICAgICA+Pj4+Pj7CoCDC oCDCoCDCoCA+DQo+ID4gICAgICA+Pj4+Pj7CoCDCoCDCoCDCoCA+DQo+ID4gICAgICA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICAgICAgPj4+ Pj4+wqAgwqAgwqAgwqAgPsKgIMKgIMKgIExzciBtYWlsaW5nIGxpc3QNCj4gPiAgICAgID4+Pj4+ PsKgIMKgIMKgIMKgID4gTHNyQGlldGYub3JnIDxtYWlsdG86THNyQGlldGYub3JnPg0KPiA+ICAg ICAgPj4+Pj4+wqAgwqAgwqAgwqAgPg0KPiA+ICAgICAgPj4+Pj4+DQo+ID4gICAgIGh0dHBzOi8v dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGwNCj4gPiAgICAgID4+Pj4+PiBvbw0KPiA+ICAgICAgPj4+Pj4+IGsuY29tLyA8aHR0cDovL2su Y29tLz4NCj4gPiAgICAgID4+Pj4+PiA/dXJsPWh0dHBzKjNBKjJGKjJGd3d3LmlldGYub3JnDQo+ ID4gICAgIDxodHRwOi8vMkZ3d3cuaWV0Zi5vcmc+KjJGbWFpbG1hbioyRmxpc3RpbmZvKjJGbHNy JmFtcDtkYXRhDQo+ID4gICAgICA+Pj4+Pj4gPQ0KPiA+ICAgICAgPj4+PiAwDQo+ID4gICAgICA+ Pj4+Pj4gMg0KPiA+ICAgICAgPj4+Pj4+DQo+ID4gICAgICA+Pj4+DQo+ID4gICAgICA+PiAqN0Mw MSo3Q3lpbmd6aGVuLnF1KjQwZnV0dXJld2VpLmNvbQ0KPiA+ICAgICA8aHR0cDovLzQwZnV0dXJl d2VpLmNvbT4qN0NmZTAzMTI0YzZlNDE0ZTA2N2MyMDA4ZDg2NzgxDQo+ID4gICAgICA+Pj4+Pj4N Cj4gPiAgICAgID4+Pj4NCj4gPiAgICAgID4+DQo+IDY1NDEqN0MwZmVlOGZmMmEzYjI0MDE4OWM3 NTNhMWQ1NTkxZmVkYyo3QzEqN0MwKjdDNjM3MzczMTUyNzM5ODYNCj4gPiAgICAgID4+Pj4+Pg0K PiA+ICAgICAgPj4+Pg0KPiA+ICAgICAgPj4NCj4gNTEyNiZhbXA7c2RhdGE9V0k0OGNFQWFuKjJG T2tEUG1WWEd1ckVBalBJdE5HRjlwOVBEUUlsRDFpcDBnKjNEDQo+ID4gICAgICA+Pj4+Pj4NCj4g PiAgICAgID4+Pj4NCj4gPiAgICAgID4+DQo+ID4NCj4gJmFtcDtyZXNlcnZlZD0wX187SlNVbEpT VWxKU1VsSlNVbEpTVWxKUSEhTkV0NnlNYU8tZ2shWDFmUmxuOU1qaW1lSmNSDQo+ID4gICAgICA+ Pj4+Pj4gRVVFSXlkci04SUlidE5vblhNczgzZW9YdlJ3dzZ4a2FRZlZVZE5oMGtLNDUyR1AtRyQN Cj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4NCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKg ID4NCj4gPiAgICAgID4+Pj4+PsKgIMKgIMKgIMKgID4NCj4gPiAgICAgID4+Pj4+Pg0KPiA+ICAg ICAgPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gICAgICA+Pj4+Pj4gTHNyIG1haWxpbmcgbGlzdA0KPiA+ICAgICAgPj4+Pj4+IExzckBp ZXRmLm9yZyA8bWFpbHRvOkxzckBpZXRmLm9yZz4NCj4gPiAgICAgID4+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0KPiA+ICAgICAgPj4+Pj4NCj4gPiAgICAg ID4+Pj4+DQo+ID4gICAgICA+Pj4+DQo+ID4gICAgICA+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gICAgICA+Pj4+IExzciBtYWlsaW5nIGxp c3QNCj4gPiAgICAgID4+Pj4gTHNyQGlldGYub3JnIDxtYWlsdG86THNyQGlldGYub3JnPg0KPiA+ ICAgICAgPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0KPiA+ ICAgICAgPj4+DQo+ID4gICAgICA+Pj4NCj4gPiAgICAgID4+DQo+ID4gICAgICA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICAgICAgPj4gTHNy IG1haWxpbmcgbGlzdA0KPiA+ICAgICAgPj4gTHNyQGlldGYub3JnIDxtYWlsdG86THNyQGlldGYu b3JnPg0KPiA+ICAgICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s c3INCj4gPiAgICAgID4NCj4gPiAgICAgID4NCj4gPg0KPiA+ICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICAgICBMc3IgbWFpbGluZyBsaXN0 DQo+ID4gICAgIExzckBpZXRmLm9yZyA8bWFpbHRvOkxzckBpZXRmLm9yZz4NCj4gPiAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3INCj4gPg0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHNyIG1haWxpbmcg bGlzdA0KPiBMc3JAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sc3INCg== From nobody Wed Oct 14 02:06:56 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE7F3A1424 for ; Wed, 14 Oct 2020 02:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eEqzPoo3QKE for ; Wed, 14 Oct 2020 02:06:52 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6C63A1422 for ; Wed, 14 Oct 2020 02:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13910; q=dns/txt; s=iport; t=1602666412; x=1603876012; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LKacHajUWhoQmiwprUC6qyepHHma7Wwd4n2lAPXZTeU=; b=XU70e7wiijEgo6fUN9Q23DlzUPeqX84A5obATagGcQPbJtmPDe9xn8Vw Il3zhb6MUjxtfDuycU1xUB9PSEElLB/DGy3fsvsKzL8N0lXVNNYH69uzc 56drgSC2N3rDU1R93iKUIz+ppofYyHwCEwAOo10hWDOCMEHBA1mE8yshV 8=; X-IPAS-Result: =?us-ascii?q?A0CPBQCvvoZf/xbLJq1gHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DGlUBIBIshD2JAodpCCaKEZAsgWkLAQEBDxgLDAQBAYRKAoIDJjgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgRthVwMhXIBAQEBAgEBASEVNgkCDAQLEQQBAQECA?= =?us-ascii?q?iMDAgIhBh8JCAYBDAYCAQGDIgGCSwMOIA+nV3aBMoVUgkkNYoE8BoEOKokkh?= =?us-ascii?q?C2BQT+BEAEnDIJdPoIaQgEBAoEoARIBISaCcYJgBJAFK4JeiQabBFKCdIMVh?= =?us-ascii?q?W6MX4R/BQcDH4MVigiFGY8MkymKcYJsjheEXYFrI2dwMxoIGxU7gmlQGQ2DO?= =?us-ascii?q?opxF4NOhRSFRD8DMAIBNQIGCgEBAwmOSAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,374,1596499200"; d="scan'208";a="27907464" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Oct 2020 09:06:47 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 09E96kaP002117; Wed, 14 Oct 2020 09:06:47 GMT To: "Dongjie (Jimmy)" , Ron Bonica , Yingzhen Qu , Gyan Mishra Cc: "lsr@ietf.org" , Jeff Tantsura References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <00158dee-bb0d-6f5e-f740-b7bac61a1c74@cisco.com> <7F26707A-8137-4114-9236-D80B060E2528@futurewei.com> <4896cf59c3314f1c92cdb491d1d8a5a3@huawei.com> <9c7628a9-d089-1de9-932b-83bb3f875ba3@cisco.com> <34c223a132f748e0a802d538ccd073b0@huawei.com> <5d9887519bbc429fb0bf9886b35ccefd@huawei.com> From: Peter Psenak Message-ID: <1c4372ed-5f40-6452-0d34-d8f132bb301f@cisco.com> Date: Wed, 14 Oct 2020 11:06:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5d9887519bbc429fb0bf9886b35ccefd@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 09:06:55 -0000 Hi Jimmy, On 14/10/2020 10:38, Dongjie (Jimmy) wrote: > Hi Peter, > >> -----Original Message----- >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> Sent: Tuesday, October 13, 2020 4:53 PM >> To: Dongjie (Jimmy) ; Ron Bonica >> ; Yingzhen Qu ; Gyan >> Mishra >> Cc: lsr@ietf.org; Jeff Tantsura >> Subject: Re: [Lsr] FW: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> >>>>> When one node compute an SR path to a destination, can it compute >>>>> the path >>>> to only pass the nodes which bind FA-128 to SR SIDs, and avoid the >>>> nodes >which bind FA-128 to IP address? If so, how could this node >>>> know the binding of FA to different data planes on other nodes? >>>> >>>> again, it is the participation problem. >>>> >>>> Nodes that participate in the SR Flex-algo 128 will advertise the >>>> participation using the SR-Algorithm Sub-TLV. Only these nodes will >>>> be used during the SR flex-algo computation for algo 128. >>>> >>>> Nodes that participate in IP flex-algo 128 will advertise the >>>> participation using the IGP Algorithm Sub-TLV. Only these nodes will >>>> be used during the IP flex-algo computation for algo 128. >>> >>> Agree that if participation to Flex-Algo is advertised in a data plane specific >> manner, then path computation with Flex-Algo constraints could be done only >> using nodes which bind the Flex-Algo to the same data plane. >> >> it's per app, not per data plane, but yes, that is what the base flex-algo spec >> mandates. >> >>> As Robert asked and you confirmed, this implies each data plane needs to be >> treated as an independent application of Flex-Algo. We have SR-Algorithm >> sub-TLV and IP Algorithm sub-TLV, while there are actually more data planes to >> be considered: SR-MPLS, SRv6, IPv4, IPv6, etc., does this mean that Flex-Algo >> participation needs to be advertised for SR-MPLS, SRv6, IPv4, IPv6, etc. >> separately? >> >> yes, it needs to be advertised per app. We have SR specific algo participation, >> we need one for IP as proposed in Ron's draft. > > OK. While the meaning of "app" here maybe a little vague, are SR-MPLS and SRv6 considered the same or different apps? these are considered as single app, and share the same participation signaling. Please note that SRv6 support is signaled independently of FA participation. > >> Regarding IPv4 vs IPv6, it's up to the authors whether they want to make the >> participation for IP flex-algo topology specific or topology independent, both >> could work. > > If the participation is topology specific, do you mean IPv4 and IPv6 could be distinguished by advertising Flex-Algo participation with different Topology IDs (MT-ID)? This way, is the topology ID actually used as the address family distinguisher? Yes, one can signal participation for each topology and each MT topology is associated with one or AF. But let not speculate here and let authors decide. thanks, Peter > > Best regards, > Jie > >> Here's the text from the base flerx-algo draft: >> >> 10.2. Advertisement of Node Participation for Other Applications >> >> This section describes considerations related to how other >> applications can advertise their participation in a specific Flex- >> Algorithm. >> >> Application-specific Flex-Algorithm participation advertisements MAY >> be topology specific or MAY be topology independent, depending on the >> application itself. >> >> Application-specific advertisement for Flex-Algorithm participation >> MUST be defined for each application and is outside of the scope of >> this document. >> >> thanks, >> Peter >> >> >>> >>> Best regards, >>> Jie >>> >>>> >>>> thanks, >>>> Peter >>>> >>>>> >>>>> Best regards, >>>>> Jie >>>>> >>>>>> -----Original Message----- >>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Peter Psenak >>>>>> Sent: Friday, October 9, 2020 11:58 PM >>>>>> To: Dongjie (Jimmy) ; Ron Bonica >>>>>> ; Yingzhen Qu >>>>>> ; Gyan Mishra >>>>>> Cc: lsr@ietf.org; Jeff Tantsura >>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>>> >>>>>> Hi Jimmy, >>>>>> >>>>>> >>>>>> On 09/10/2020 04:59, Dongjie (Jimmy) wrote: >>>>>>> Hi Ron, >>>>>>> >>>>>>> Thanks for explaining the difference between IP Flex-Algo and SR >>>>>>> Flex-algo. As >>>>>> you said, the major difference is the data plane. >>>>>>> >>>>>>> If my understanding is correct, for one Flex-Algo to be used >>>>>>> correctly, the set >>>>>> of nodes need to apply consistent constraints in computation, and >>>>>> bind the FAD to the same data plane. >>>>>>> >>>>>>> Is it possible that different nodes may use the same Flex-Algo >>>>>>> with different >>>>>> data plane, e.g. some with SR-MPLS, some with SRv6, and some with >>>>>> pure IP etc., or each Flex-Algo is always associated with only one >>>>>> data plane? In the former case, should the flex-algo definition >>>>>> also indicate the data plane(s) to be used with the flex-algo? >>>>>> >>>>>> let me respond to this query, as this is not specific to Ron's draft. >>>>>> >>>>>> FAD is data plane agnostic and is used by all of them. >>>>>> >>>>>> thanks, >>>>>> Peter >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Jie >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >>>>>>>> Sent: Sunday, October 4, 2020 4:34 AM >>>>>>>> To: Yingzhen Qu ; Peter Psenak >>>>>>>> ; Gyan Mishra >>>>>>>> Cc: lsr@ietf.org; Jeff Tantsura >>>>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>>>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>>>>> >>>>>>>> Hi Yingzhen, >>>>>>>> >>>>>>>> IP Flexible Algorithms are like SR Flexible Algorithms in the >>>>>>>> following >>>>>> respects: >>>>>>>> >>>>>>>> - Links have IGP metrics, TE metrics, delay metrics and >>>>>>>> administrative colors >>>>>>>> - FADs define Flexible Algorithms >>>>>>>> >>>>>>>> More specifically, the FAD: >>>>>>>> >>>>>>>> - Indicates which metric type the Flexible Algorithm uses >>>>>>>> - Specifies constraints in terms of link colors that are included >>>>>>>> or excluded from the Flexible Algorithm. >>>>>>>> >>>>>>>> The significant difference between IP Flexible Algorithms and SR >>>>>>>> Flexible Algorithms is: >>>>>>>> >>>>>>>> - SR Flexible Algorithms bind FADs to prefix SIDs or SRv6 >>>>>>>> locators >>>>>>>> - IP Flexible Algorithms bind FADs to IPv4 or IPv6 addresses. >>>>>>>> >>>>>>>> So, IP Flexible Algorithms can be deployed in any IP network, >>>>>>>> even in the absence of SR. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> Juniper Business Use Only >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Yingzhen Qu >>>>>>>> Sent: Saturday, October 3, 2020 2:08 PM >>>>>>>> To: Peter Psenak ; Gyan Mishra >>>>>>>> ; Ron Bonica >>>>>>>> Cc: lsr@ietf.org; Jeff Tantsura >>>>>>>> Subject: Re: [Lsr] FW: New Version Notification for >>>>>>>> draft-bonica-lsr-ip-flexalgo-00.txt >>>>>>>> >>>>>>>> [External Email. Be cautious of content] >>>>>>>> >>>>>>>> >>>>>>>> Hi Peter, >>>>>>>> >>>>>>>> Using flex-algo, a SRv6 locator can be associated with a single >>>>>>>> algo, which means an IPv6 or IPv4 address can also be associated >>>>>>>> with a single algo. So my understanding is Ron's proposal is >>>>>>>> making the >>>>>> configuration of flex-algo easier? >>>>>>>> Instead of using the exclude or include list you can configure a >>>>>>>> loopback address to a flex-algo directly? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yingzhen >>>>>>>> >>>>>>>> On 10/3/20, 2:47 AM, "Peter Psenak" wrote: >>>>>>>> >>>>>>>> Hi Yingzhen, >>>>>>>> >>>>>>>> On 02/10/2020 22:15, Yingzhen Qu wrote: >>>>>>>> > Hi Peter, >>>>>>>> > >>>>>>>> > My understanding of flex-algo is that for traffic >>>>>>>> destined to a prefix on a particular algo, it can only be routed >>>>>>>> on routers belong to that algo, which also means only routers in >>>>>>>> that algo calculates how to reach that prefix and install it into >>>>>>>> the routing table. It seems to me that using flex-algo (section >>>>>>>> 12 of the >>>>>>>> draft) it's possible to have a loopback address associated with >>>>>>>> only one algo, please correct me if I'm missing or misunderstood >>>> something. >>>>>>>> >>>>>>>> you are right. That is exactly what is being done for flex-algo >> with >>>>>>>> SRv6 - locator is associated with a single algo only. The >>>>>>>> proposal >>>> uses >>>>>>>> the same concept. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Peter >>>>>>>> >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > Yingzhen >>>>>>>> > >>>>>>>> > On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" >>>>>>>> >>>>>>> ppsenak=40cisco.com@dmarc.ietf.org> >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > Gyan, >>>>>>>> > >>>>>>>> > On 02/10/2020 18:30, Gyan Mishra wrote: >>>>>>>> > > All, >>>>>>>> > > >>>>>>>> > > With SRv6 and IP based flex algo a generic question >> as it >>>>>> applies >>>>>>>> to >>>>>>>> > > both. Is it possible to have within a single IGP >> domain >>>>>> different >>>>>>>> sets >>>>>>>> > > of nodes or segments of the network running >> different >>>>>>>> algorithms. >>>>>>>> > >>>>>>>> > absolutely. >>>>>>>> > >>>>>>>> > > From >>>>>>>> > > both drafts it sounds like all nodes have to agree on >>>> same >>>>>>>> algorithm >>>>>>>> > > similar to concept of metric and reference >> bandwidth >>>> all >>>>>> have to >>>>>>>> have >>>>>>>> > > the same style metric and play to the same sheet of >>>> music. >>>>>>>> > >>>>>>>> > all participating nodes need to agree on the definition >> of >>>> the >>>>>>>> flex-algo >>>>>>>> > and advertise the participation. That's it. >>>>>>>> > >>>>>>>> > > If there was >>>>>>>> > > a way to use multiple algorithms simultaneously >> based >>>> on >>>>>> SFC >>>>>>>> or services >>>>>>>> > > and instantiation of specific algorithm based on >> service >>>> to >>>>>> be >>>>>>>> > > rendered. Doing so without causing a routing loop >> or >>>> sub >>>>>>>> optimal >>>>>>>> > > routing. >>>>>>>> > >>>>>>>> > you can certainly use multiple algorithms >> simultaneously >>>> and >>>>>> use >>>>>>>> algo >>>>>>>> > specific paths to forward specific traffic over it. How >> that >>>> is >>>>>> done >>>>>>>> > from the forwarding perspective depends in which >>>>>> forwarding >>>>>>>> plane you >>>>>>>> > use. Flex-algo control plane is independent of the >>>> forwarding >>>>>>>> plane. >>>>>>>> > >>>>>>>> > >>>>>>>> > >I thought with flex algo that there exists a feature >> that >>>> on >>>>>>>> > > each hop there is a way to specify which algo to use >>>> hop by >>>>>> hop >>>>>>>> similar >>>>>>>> > > to a hop by hop policy based routing. >>>>>>>> > >>>>>>>> > no, there is no hop-by-hop classification, that is >>>> problematic >>>>>> and >>>>>>>> does >>>>>>>> > not scale for high speeds. Classification is done at the >>>>>> ingress only. >>>>>>>> > >>>>>>>> > thanks, >>>>>>>> > Peter >>>>>>>> > >>>>>>>> > > >>>>>>>> > >>>>>>>> > >>>> _______________________________________________ >>>>>>>> > Lsr mailing list >>>>>>>> > Lsr@ietf.org >>>>>>>> > >>>>>>>> https://urldefense.com/v3/__https://nam11.safelinks.protection.ou >>>>>>>> tl >>>>>>>> oo >>>>>>>> k.com/ >>>>>>>> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Flsr&da >>>>>>>> ta >>>>>>>> = >>>>>> 0 >>>>>>>> 2 >>>>>>>> >>>>>> >>>> >> *7C01*7Cyingzhen.qu*40futurewei.com*7Cfe03124c6e414e067c2008d86781 >>>>>>>> >>>>>> >>>> >> 6541*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63737315273986 >>>>>>>> >>>>>> >>>> >> 5126&sdata=WI48cEAan*2FOkDPmVXGurEAjPItNGF9p9PDQIlD1ip0g*3D >>>>>>>> >>>>>> >>>> >> &reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!X1fRln9MjimeJcR >>>>>>>> EUEIydr-8IIbtNonXMs83eoXvRww6xkaQfVUdNh0kK452GP-G$ >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Lsr mailing list >>>>>>>> Lsr@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> > > > From nobody Wed Oct 14 02:32:17 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81A73A142C for ; Wed, 14 Oct 2020 02:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 W3j06bCjOtPU for ; Wed, 14 Oct 2020 02:32:12 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA123A1428 for ; Wed, 14 Oct 2020 02:32:09 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:57349.258879856 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-114.250.152.55?logid-c7d41313d0634e54a82ccfa5dd3a607f (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id CA7512800B9 for ; Wed, 14 Oct 2020 17:32:07 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id c7d41313d0634e54a82ccfa5dd3a607f for lsr@ietf.org; Wed Oct 14 17:32:07 2020 X-Transaction-ID: c7d41313d0634e54a82ccfa5dd3a607f X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Sender: xiechf@chinatelecom.cn Date: Wed, 14 Oct 2020 17:32:13 +0800 From: "Xie Chongfeng" To: lsr X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 166[cn] Mime-Version: 1.0 Message-ID: <2020101417321319345959@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart462415317206_=----" Archived-At: Subject: [Lsr] Fw: New Version Notification for draft-xie-lsr-isis-sr-vtn-mt-02.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2020 09:32:16 -0000 This is a multi-part message in MIME format. ------=_001_NextPart462415317206_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIFdHLA0KIA0KV2UganVzdCBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC14aWUt bHNyLWlzaXMtc3ItdnRuLW10IHRvIHJlc29sdmUgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGR1cmlu ZyBhbmQgYWZ0ZXIgbGFzdCBJRVRGIG1lZXRpbmcuIFRoZSBjaGFuZ2VzIGFyZToNCiANCjEuIEJh c2VkIG9uIHRoZSBzdWdnZXN0aW9ucyBvbiBJRVRGIG1lZXRpbmcsIHRoZSBkb2N1bWVudCB0eXBl IGlzIGNoYW5nZWQgdG8gaW5mb3JtYXRpb25hbC4NCiAyLiBBZGQgc29tZSBkZXNjcmlwdGlvbnMg YWJvdXQgdGhlIG9wZXJhdGlvbnMgaW4gZm9yd2FyZGluZyBwbGFuZS4NCiAzLiBBZGQgcmVmZXJl bmNlIHRvIGRyYWZ0LWlldGYtc3ByaW5nLXJlc291cmNlLWF3YXJlLXNlZ21lbnRzLCB3aGljaCBp bnRyb2R1Y2VzIHRoZSBtZWNoYW5pc20gdG8gYXNzb2NpYXRlIFNSIFNJRHMgd2l0aCBkaWZmZXJl bnQgc3Vic2V0IG9mIHJlc291cmNlcy4NCiA0LiBTb21lIGVkaXRvcmlhbCBjaGFuZ2VzLg0KIA0K RHVyaW5nIHRoZSBwcmVzZW50YXRpb24gb24gbGFzdCBJRVRGIG1lZXRpbmcsIGF1dGhvcnMgYXNr ZWQgV0cgdG8gY29uc2lkZXIgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFNpbmNlIHRo aXMgdmVyc2lvbiByZXNvbHZlcyBhbGwgdGhlIGNvbW1lbnRzIHNvIGZhciBhbmQgdGhlIGNvbnRl bnQgaXMgZ2V0dGluZyBzdGFibGUsIGF1dGhvcnMgd291bGQgbGlrZSB0byBzb2xpY2l0IFdHIGFk b3B0aW9uIHBvbGwgb24gdGhpcyBkb2N1bWVudC4NCiANClJldmlldyBhbmQgY29tbWVudHMgYXJl IGFsd2F5cyB3ZWxjb21lLg0KIA0KQmVzdCByZWdhcmRzLA0KDQpDaG9uZ2ZlbmcgDQogDQogDQpG cm9tOiBpbnRlcm5ldC1kcmFmdHMNCkRhdGU6IDIwMjAtMTAtMTMgMTQ6NTkNClRvOiBKaWUgRG9u ZzsgQ2hlbmhhbyBNYTsgWmhlbmJpbiBMaTsgQ2hvbmdmZW5nIFhpZQ0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAyLnR4 dA0KIA0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXhpZS1sc3ItaXNpcy1zci12dG4tbXQt MDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppZSBEb25nIGFuZCBw b3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQogDQpOYW1lOiBkcmFmdC14aWUtbHNyLWlz aXMtc3ItdnRuLW10DQpSZXZpc2lvbjogMDINClRpdGxlOiBVc2luZyBJUy1JUyBNdWx0aS1Ub3Bv bG9neSAoTVQpIGZvciBTZWdtZW50IFJvdXRpbmcgYmFzZWQgVmlydHVhbCBUcmFuc3BvcnQgTmV0 d29yaw0KRG9jdW1lbnQgZGF0ZTogMjAyMC0xMC0xMw0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlz c2lvbg0KUGFnZXM6IDgNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNo aXZlL2lkL2RyYWZ0LXhpZS1sc3ItaXNpcy1zci12dG4tbXQtMDIudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteGllLWxzci1pc2lzLXNy LXZ0bi1tdC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LXhpZS1sc3ItaXNpcy1zci12dG4tbXQNCkh0bWxpemVkOiAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteGllLWxzci1pc2lzLXNyLXZ0bi1tdC0wMg0K RGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC14 aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAyDQogDQpBYnN0cmFjdDoNCiAgIEVuaGFuY2VkIFZQTiAo VlBOKykgYXMgZGVmaW5lZCBpbiBJLUQuaWV0Zi10ZWFzLWVuaGFuY2VkLXZwbiBhaW1zIHRvDQog ICBwcm92aWRlIGVuaGFuY2VkIFZQTiBzZXJ2aWNlIHRvIHN1cHBvcnQgc29tZSBhcHBsaWNhdGlv bidzIG5lZWRzIG9mDQogICBlbmhhbmNlZCBpc29sYXRpb24gYW5kIHN0cmluZ2VudCBwZXJmb3Jt YW5jZSByZXF1aXJlbWVudHMuICBWUE4rDQogICByZXF1aXJlcyBpbnRlZ3JhdGlvbiBiZXR3ZWVu IHRoZSBvdmVybGF5IFZQTiBhbmQgdGhlIHVuZGVybGF5DQogICBuZXR3b3JrLiAgQSBWaXJ0dWFs IFRyYW5zcG9ydCBOZXR3b3JrIChWVE4pIGlzIGEgdmlydHVhbCBuZXR3b3JrDQogICB3aGljaCBj b25zaXN0cyBvZiBhIHN1YnNldCBvZiB0aGUgbmV0d29yayB0b3BvbG9neSBhbmQgbmV0d29yaw0K ICAgcmVzb3VyY2VzIGFsbG9jYXRlZCBmcm9tIHRoZSB1bmRlcmxheSBuZXR3b3JrLiAgQSBWVE4g Y291bGQgYmUgdXNlZA0KICAgYXMgdGhlIHVuZGVybGF5IGZvciBvbmUgb3IgYSBncm91cCBvZiBW UE4rIHNlcnZpY2VzLg0KIA0KICAgSS1ELmRvbmctbHNyLXNyLWVuaGFuY2VkLXZwbiBkZWZpbmVz IHRoZSBJR1AgZXh0ZW5zaW9ucyB0byBidWlsZCBhDQogICBzZXQgb2YgU2VnbWVudCBSb3V0aW5n IChTUikgYmFzZWQgVlROcy4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGENCiAgIHNpbXBsaWZp ZWQgbWVjaGFuaXNtIHRvIGJ1aWxkIHRoZSBTUiBiYXNlZCBWVE5zIHVzaW5nIElTLUlTIE11bHRp LQ0KICAgVG9wb2xvZ3kgdG9nZXRoZXIgd2l0aCBvdGhlciB3ZWxsLWRlZmluZWQgSVMtSVMgZXh0 ZW5zaW9ucy4NCiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiANCiANClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KIA0KIA0KIA0K ------=_001_NextPart462415317206_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A

Hi, WG,

 

= We just submitted a ne= w version of draft-xie-lsr-isis-sr-vtn-mt to resolve the comments received= during and after last IETF meeting. The changes are:

 

1. Based on the suggestions on IETF = meeting, the document type is changed to informational.

 2. Add some descriptions about the operations in forwarding p= lane.

&= nbsp;3. Add reference to draft-ietf-spring= -resource-aware-segments, which introduces the mechanism to associate SR S= IDs with different subset of resources.

 4. = Some editorial changes.

 

During the presentation on last IETF meeting, au= thors asked WG to consider the adoption of this document. Since this versi= on resolves all the comments so far and the content is getting stable, aut= hors would like to solicit WG adoption poll on this document.

&= nbsp;

Review and comments are always welcome.

=

 

Best regar= ds,


Chongfeng 

 

=0A
 
Date= : 2020-10-13 14:59
<= b>Subject: New Version Notification for draft-xie-lsr-isis-sr-vtn= -mt-02.txt
 
=0A
A new version of= I-D, draft-xie-lsr-isis-sr-vtn-mt-02.txt
=0A
has been successful= ly submitted by Jie Dong and posted to the
=0A
IETF repository.=0A
 
=0A
Name: draft-xie-lsr-isis-sr-vtn-mt
= =0A
Revision: 02
=0A
Title: Using IS-IS Multi-Topology (MT) = for Segment Routing based Virtual Transport Network
=0A
Document = date: 2020-10-13
=0A
Group: Individual Submission
=0A
P= ages: 8
=0A
URL:        =     https://www.ietf.org/archive/id/draft-xie-lsr-isis-sr-v= tn-mt-02.txt
=0A
Status:       = ;  https://datatracker.ietf.org/doc/draft-xie-lsr-isis-sr-vtn-mt/=0A
Htmlized:       https://datatracke= r.ietf.org/doc/html/draft-xie-lsr-isis-sr-vtn-mt
=0A
Htmlized:&nb= sp;      https://tools.ietf.org/html/draft-xie-ls= r-isis-sr-vtn-mt-02
=0A
Diff:      =      https://www.ietf.org/rfcdiff?url2=3Ddraft-xie-lsr= -isis-sr-vtn-mt-02
=0A
 
=0A
Abstract:
=0A   Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-vpn= aims to
=0A
   provide enhanced VPN service to support= some application's needs of
=0A
   enhanced isolation = and stringent performance requirements.  VPN+
=0A
 &nbs= p; requires integration between the overlay VPN and the underlay
=0A<= div>   network.  A Virtual Transport Network (VTN) is a vir= tual network
=0A
   which consists of a subset of the n= etwork topology and network
=0A
   resources allocated = from the underlay network.  A VTN could be used
=0A
 &n= bsp; as the underlay for one or a group of VPN+ services.
=0A
&nb= sp;
=0A
   I-D.dong-lsr-sr-enhanced-vpn defines the IGP= extensions to build a
=0A
   set of Segment Routing (S= R) based VTNs.  This document describes a
=0A
   s= implified mechanism to build the SR based VTNs using IS-IS Multi-
=0A=
   Topology together with other well-defined IS-IS extensio= ns.
=0A
 
=0A
      &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;
=0A
 
=0A
 
=0A
Please note th= at it may take a couple of minutes from the time of submission
=0Auntil the htmlized version and diff are available at tools.ietf.org.=0A
 
=0A
The IETF Secretariat
=0A
 =0A
 
=0A
 
=0A
=0A= ------=_001_NextPart462415317206_=------ From nobody Wed Oct 14 23:15:28 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616AC3A12DE; Wed, 14 Oct 2020 23:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PvletiHGTnUx; Wed, 14 Oct 2020 23:15:26 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6953A12DC; Wed, 14 Oct 2020 23:15:23 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8C2266166F; Thu, 15 Oct 2020 06:15:22 +0000 (UTC) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_76545936-EC19-490E-A5E8-05556FE1F750"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Thu, 15 Oct 2020 02:15:21 -0400 Cc: Christian Hopps , lsr-chairs@ietf.org, lsr-ads@ietf.org, draft-ietf-lsr-ospf-prefix-originator@ietf.org To: lsr@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 06:15:27 -0000 --Apple-Mail=_76545936-EC19-490E-A5E8-05556FE1F750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: = https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ The following IPR has been filed https://datatracker.ietf.org/ipr/3448/ Authors, Please indicate to the list, your knowledge of any other IPR related = to this work. Thanks, Chris. --Apple-Mail=_76545936-EC19-490E-A5E8-05556FE1F750 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+H6PkACgkQLh2DDte4 MCU1Lw/+NyDnHcEljWBI67JCA7X9Enkxi6l90ybjIu3x2oMR/rj8uABUxr0ROkkd hefevEbVwbehLiggjWYawis0iJGcyD+RIiXtAdoyo4+KySW3ztWG/QjC/TNjQxnM rcKewOvnu2rWXfhb/GKsBKXVQzMjaB0cCd6vN3BR/3RQaAMUsv8LgzVEo9sm9G0G kglO6RjShpTVxLLJoddA3xNJYhhzlCMKgpuhk9CHoWYDRPeUF+cN7VZ8kSX5/kfj EaFTh1v51JeZC+w4KweBuFxgI4fURSTZQqIsAeB+lNutjKML34vPnxXKGAOk9GE9 KBf+PWZ25OsLzkvP5hrZTCMyQU3tiHGk+PNazhqtCBIwTutXl+ZYfG8vF/u970ao OeapTPvy+iWUS8NIH3sFHdbbbPw3XFsIHNjF9eaVJ4eXzl1zwNf5NDl7bkuI7zKV 8Auyibicpv7E/qIg0ksNTidsnl41QVLtAszP0aPEnK8UMvQScm9GvMzDlFJSP+59 1r+M2vkswZmWV2MKC63A1+bw1j+kjk141c5qCkSkiNI8z2yljLeY1bwEgPWRhhHZ b1n/6xPEsn2PFmq7F87/G0k6vh5DiR3qd871wG09Y8UoDZrnHyZiRy1vA/0KDif/ 4qdxAI2+XmieG/44NdYtAN/br/rWiiK69eZLlKYkkGf2U31qTz8= =wU2m -----END PGP SIGNATURE----- --Apple-Mail=_76545936-EC19-490E-A5E8-05556FE1F750-- From nobody Wed Oct 14 23:17:51 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5483A1318; Wed, 14 Oct 2020 23:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 8qOFDYKO9EPo; Wed, 14 Oct 2020 23:17:41 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 B651B3A1301; Wed, 14 Oct 2020 23:17:41 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id a1so1314757pjd.1; Wed, 14 Oct 2020 23:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=MO/vmdnTmCOQ1noOj62ItHta0/1y7oP3Ozx6OPYoM7s=; b=QjhsGZU0K4YVOz3y2rdt6Eq3+Z0LgdiQxWNjxCgWb6skUpWu9e3FdRtdpkybbolvDB tHqSE3XQ/xuyDzXS3nKEdg/+cs+f1/3l7k21aWPQJ6D6UIpwy2AAvdmyfYGG0vkqVliD UZko9Gyx3ovkA+qwubEo1AehOgc6Pq6FWfQ79uGzYqWU0SLF0wiCodtSJ9jczBl7aZvH +wOAdocUON4FhgCBVzJ1DUwGAUa5TyN+OGZxhvmQaiJZAA30Lxc+4CqbtcvThBXsJLnC J7bbBIwbJf8pL6a3Ag2YBmlyrgQRGLoLFn83zuO//gx4FPTWc4p8SHSFs2MXBT7vEKyd 5Wkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=MO/vmdnTmCOQ1noOj62ItHta0/1y7oP3Ozx6OPYoM7s=; b=DUBlno0ufQJr5xQttjt0ObON39Q+WSwnXJJJUm7dHTLuofzxKdKlaLnNbREPG77gjZ 3abEtmT12RNRdEaMGvwWFhSkD5Tdrg/PTW5Z9WkyNopby9ReA9m8fsZyZkmoeeKA6EPR 5CbcS3/Tx4b0Cr6pjhBeysIA5eOs39kRK0Ld3hLcDrBbVise59x0k6ysM+HIM24BLBEn oLGCD+T3fDz0B0z/1yCqxl+XhNfp7XO2x1z/c1CorRjfiCzXuacfwAuDbXiTxhJcNSoG SbSxS80ONjhAIDgEQKtuTtgHRmOPjghD1dcfNw5Zm3GbLekEZIHMSNjpcQh6ebFvl70Z /cDg== X-Gm-Message-State: AOAM533HZlMsmClcP9WF8tmdjsEE+Ij4F3JHDx12Fyb47YNyTfDJdhYc mMVE3upXsUSDEReMlW/aLR1UcTht+y8= X-Google-Smtp-Source: ABdhPJzL4BOz/psHmjaZO9KPSQxANKK8eD6vUnlwVQ4esy1DYfkDPtTI7Sb47ho6SgbsaIFD6WMLKQ== X-Received: by 2002:a17:90b:717:: with SMTP id s23mr2951624pjz.122.1602742660837; Wed, 14 Oct 2020 23:17:40 -0700 (PDT) Received: from ?IPv6:2601:647:5c00:e83:c0b1:b5ed:16c6:2dfa? ([2601:647:5c00:e83:c0b1:b5ed:16c6:2dfa]) by smtp.gmail.com with ESMTPSA id w205sm1747633pfc.78.2020.10.14.23.17.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2020 23:17:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jeff Tantsura Mime-Version: 1.0 (1.0) Date: Wed, 14 Oct 2020 23:17:39 -0700 Message-Id: <1A4DCE24-50F9-4010-80B1-EED08CBDBEC9@gmail.com> References: Cc: lsr@ietf.org, draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-chairs@ietf.org, lsr-ads@ietf.org In-Reply-To: To: Christian Hopps X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 06:17:50 -0000 Yes/support Regards, Jeff > On Oct 14, 2020, at 23:16, Christian Hopps wrote: >=20 > =EF=BB=BFThis begins a 2 week WG Last Call, ending after Oct 29th, 2020, f= or: >=20 > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ >=20 > The following IPR has been filed https://datatracker.ietf.org/ipr/3448/ >=20 > Authors, >=20 > Please indicate to the list, your knowledge of any other IPR related to t= his work. >=20 > Thanks, > Chris. > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Thu Oct 15 01:39:16 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6F03A1370; Thu, 15 Oct 2020 01:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=E4k1NCgI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=urOyYS1S 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 koTXMem4GNFO; Thu, 15 Oct 2020 01:39:12 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9350B3A136E; Thu, 15 Oct 2020 01:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=794; q=dns/txt; s=iport; t=1602751152; x=1603960752; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ylaCqIA2MTbjj7lkSc+j1/qMArW5PkDeCRWLPACXXck=; b=E4k1NCgIKWaKoI9x43oykS4CaUgLZXYK/Dj4/QCwrYQUqvBzwDS2xNEs OLwjVESPZ0EvZbG75IZywdHDpMFIyXeErsoh5XgDjohYK463Yva10DUrJ TnLDchsf4s9o61HYX3dTlhx2RVCLKYrmW4BtBCh/ve/60+jb3Fd/Ud2XY M=; IronPort-PHdr: =?us-ascii?q?9a23=3AwOSOJhKIZmkmEhELRNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKs/h1/ORZ3ArfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBteGMHmf0aUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+CABkCYhf/4QNJK1gHgE8DAILFYF?= =?us-ascii?q?PgVJRB3BZLywKh3kDjVCYe4JTA1ULAQEBDQEBIwoCBAEBhEoCgggCJTcGDgI?= =?us-ascii?q?DAQELAQEFAQEBAgEGBG2FXAyFcgEBAQQSKAYBATcBCwQCAQgOAwQBAR8QMh0?= =?us-ascii?q?IAgQBDQUIGoMFgksDLgEOoFQCgTmIYXSBNIMBAQEFgTMBE0GDFxiCEAMGgTi?= =?us-ascii?q?CcoJgEjqHGBuBQT+BVIJNPoJcAgMBgV2DSIItkDinPQqCaogCgQKSDIMVigi?= =?us-ascii?q?UKZMqinKRCIQwAgQCBAUCDgEBBYFqJIFXcBU7gmlQFwINkhCFFIVCdDgCBgo?= =?us-ascii?q?BAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,378,1596499200"; d="scan'208";a="563242899" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2020 08:39:10 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 09F8d9V3029958 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2020 08:39:09 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 03:39:09 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 03:39:08 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 03:39:09 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nP2DoWqKoKVV8LhBw+mMY30JUJnHEUTdX9RHz4rQkBfH5+Ep0QV1+Mp84wokypyOmnpJz26a7wIFpvgbOyDirdjTNEGoY/LKOttYiGV2gmPU6AwmeQbGlYXyOJ9qpEewv9+ZLtR0oRWELZ9gGlk1SS5Z+dSuf/OmSHQgjzFsjq6g9QjX8+yLH2LNU82CCUMBELe7UOea+dBT9SXXZ+5M502JDzJW++qzvOxudaLZyyDq510r4RJdPgZSsQDhcZ9ysYWJzmGQxSxSbY0ZVUUfrFkmcKlRmSvvvsxZ7fO0ueGcRI7RVgEOBizQnQO7AdIl+72WemoMg3vXtYSlP0RMyw== 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=jhtB1iDBqDSTgeQBGj1IIso5aXh8hP7B8IAuyf1beXs=; b=D6ZYqQhdtuOZ09IZIBui4KbHcuvhxi0KKxRXn6FJd0fKMJ3LbNta7E1XvzkGt8+BZPXxLizNFl6oCH567M4Z3HyrtSvVroMIhXC30TAF7A1ecIyVu6ldFWed3geISJazaPApPqw1D/1J/3ztIgo+JoDY5gkWSKltU+q+yDQJGqC9TpxYT4V6DB+DA+Lfm98hzUR1Ydc6BrA5dVC4m5Bd1pANMoalj9ZbPxqOpyOpWYDS3SLsutHTQHXAxCPHxB5G1lLft5iX4DwXXSAjF4zgfvgT1tG8Jblssw1juKQnxjhemuZbqTFB9ebiAEHSC//+ScCjz+CNBYX3sv4aaCqabg== 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=jhtB1iDBqDSTgeQBGj1IIso5aXh8hP7B8IAuyf1beXs=; b=urOyYS1SMCtPHV7ip1SXyY+NhknS3wfVlqoUgAGNX9bSMreGOF8/ib9VHhghJt3LFw8jn6rCOk8lPTRNf9+2Jy0VXl+apsp+jZeC44x7KBtydF53Up7jrtA3ArNG1O9vwBhgrZcE6XPf93HVciXa59c5w1LHjjNRtZRyJ0ORXZE= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR1101MB2078.namprd11.prod.outlook.com (2603:10b6:301:4e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Thu, 15 Oct 2020 08:39:08 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3477.021; Thu, 15 Oct 2020 08:39:08 +0000 From: "Ketan Talaulikar (ketant)" To: Christian Hopps , "lsr@ietf.org" CC: "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" Thread-Topic: WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorqoC1KYinwtxka4W6+KBPi+NqmYWIHg Date: Thu, 15 Oct 2020 08:39:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4e01be45-e793-41a6-f52e-08d870e5c855 x-ms-traffictypediagnostic: MWHPR1101MB2078: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2gFCIsNJd5y/LF22wQAfyfB13egPDpGRySXh2NVSSEHN+0hcwXGjD0TxphZcs4MchyGz6kRTEWkztpSUNwHSRM9SwBZw0gbkIy5KdHIkYw2+F0Mili9wNWp0nPC7hm/fFAns9WVN7hURD25ZLZZHc5wNZ4d5maBZnVW+BUw7yv8q8HsMHMnBcdX7Hf9FtZvKmAmwo89evqoNYVHmcYU8CsRA4Pl6Q/IN5PpftALMRJUcq3GZTYFOEoWVCmT0zOrm3CQEZraUMcuOGym2SiM2JkZlyBUAhIcSYMOwrqUk00r2/PtNUuJA96oVujOa0G3DvT/QDW29GEBG2GI1tK73/sKe6PwTUV4kwj/C8Pjo5EXvAi2Plaonj9PXr5Riqdode6tl8kLxnW8ZhvN1hkLqjA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(136003)(39860400002)(376002)(346002)(9686003)(8676002)(53546011)(76116006)(66446008)(6506007)(186003)(66556008)(5660300002)(26005)(66946007)(33656002)(66476007)(2906002)(64756008)(8936002)(83380400001)(966005)(83080400001)(4744005)(316002)(4326008)(55016002)(478600001)(86362001)(54906003)(110136005)(7696005)(71200400001)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: XGTZyGO9oa4kMDq2VRAI92aUytRUpmFGwBwL6G+pt1Re8Neg/DQNCvWy8x0TYnmxpx6bZzz0nbencmDxMWnHKsPUQxdYsR+Z4XiJY1Tl/KyjbTgOIV2GNmaTUR4PhooiLelmNn4XPhWh7cl5qcgYMejbnSQhHS9Peo4TFEg6cQCt+UOCscixoBtFDZUDvDrW/WDfDD5NvduBurgx7kZ4phZnS1C5PcHjrcC1o84usBHkKA+OB8IMr/xVyMilC8GVBbF+b5Ei4yJR4useCAKjXSbmnXbPEqetHbHbsetT17tlwbKJ3hX6W7ie4Sh5VqD2GVrN/I+KjNBaykaVmPi8H0v1ZoqjsrsJdd89pps0LQxuWaUrPEXADjqUt4/Hjs8jvF3ExMeA87zDbAXPzaQa6qA8EvtAan5/QALIjET1mgn8I0u0u4KL3nMg6fTSHJ8nFhjwXy8PZwmXFiYo0q5Ezo6dUf7hUsS39oaSONZuZwgsRTsgG7SW5cMWSl9uOm516gbdMu236cCCDhDV3eqiKwQNxr9DI/hEoTlvituoIn6YotB92M+r5htTEc3R7O94gAHHpwoicsI5rojIxROX8ZK1nyaoDESmEn2e5mPjVelmoeaHU4AcI5we/ra77I5sNYbcFn5J11zMLhnTw9JYOQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e01be45-e793-41a6-f52e-08d870e5c855 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 08:39:08.2837 (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: qKS+qLwfUY0cTaQQcLXcjTNrmyM5NXudn+lneiu0aCtnFnGTVin0wU/0Wcus31hAsRJcooyJa8ONsbGBYjxyAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2078 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 08:39:15 -0000 Hello, I support the progression to publication and as co-author, I am not aware o= f any undisclosed IPR. Thanks, Ketan -----Original Message----- From: Christian Hopps =20 Sent: 15 October 2020 11:45 To: lsr@ietf.org Cc: Christian Hopps ; lsr-chairs@ietf.org; lsr-ads@ietf.= org; draft-ietf-lsr-ospf-prefix-originator@ietf.org Subject: WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ The following IPR has been filed https://datatracker.ietf.org/ipr/3448/ Authors, Please indicate to the list, your knowledge of any other IPR related to t= his work. Thanks, Chris. From nobody Thu Oct 15 02:09:34 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF22A3A1387; Thu, 15 Oct 2020 02:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-VFvVcEeRwz; Thu, 15 Oct 2020 02:09:31 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA743A1386; Thu, 15 Oct 2020 02:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=527; q=dns/txt; s=iport; t=1602752971; x=1603962571; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=h6aZyT5193ia9/JW8gNMRoyvIaxwE0H41kH+RJSuXSc=; b=PVWv9KTgNau7k18jzCw3fT+/LY4ro/4Ds/hcBNlvN0i9ZbmwvPrU4I9v n9MmrQamHL8eBrNo/Hyf6FepMTUg7YU82eRdMUK9ZyLX7ojqJmcA5/MNm wyvtfs6pL8bK/SlAPwtdvwwA1Bsf5FG/dJFWwmBVsaTeOz8VKalPig7zg Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlBABREYhf/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DGlUBIBKEaYkCh2kunCYLAQEBDyMMBAEBhEoCggkmOBM?= =?us-ascii?q?CAwEBCwEBBQEBAQIBBgRthVwMhXMBBSMVQRALGAICJgICVwcMCAEBgyIBgnw?= =?us-ascii?q?Pqm12gTKEOwETQUSDOoE8BoEOKokkhC2BQT+BOIJpPoJcAgMBhHKCYAScF5t?= =?us-ascii?q?agnSDFoVukV4FBwMfgwMSigiFHY8MkyqKcpVggWsjgVczGggbFTuCak8ZDZc?= =?us-ascii?q?khUQ/A2gCBgoBAQMJjkgBAQ?= X-IronPort-AV: E=Sophos;i="5.77,378,1596499200"; d="scan'208";a="30375256" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2020 09:09:26 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 09F99QYj013052; Thu, 15 Oct 2020 09:09:26 GMT To: chopps@chopps.org, lsr@ietf.org Cc: lsr-chairs@ietf.org, lsr-ads@ietf.org, draft-ietf-lsr-ospf-prefix-originator@ietf.org References: From: Peter Psenak Message-ID: Date: Thu, 15 Oct 2020 11:09:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 09:09:33 -0000 Hi Chris, I am not aware of any undisclosed IPRs. thanks, Peter On 15/10/2020 08:15, Christian Hoppsprotocol= application/pgp-signature wrote: > This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ > > The following IPR has been filed https://datatracker.ietf.org/ipr/3448/ > > Authors, > > Please indicate to the list, your knowledge of any other IPR related to this work. > > Thanks, > Chris. > From nobody Thu Oct 15 02:51:09 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E993A13B5; Thu, 15 Oct 2020 02:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 4fneCWjl5U9e; Thu, 15 Oct 2020 02:51:03 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD283A13B4; Thu, 15 Oct 2020 02:51:03 -0700 (PDT) Received: from lhreml735-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0221DB198C0A0BF772E2; Thu, 15 Oct 2020 10:51:00 +0100 (IST) Received: from dggeme753-chm.china.huawei.com (10.3.19.99) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 10:50:59 +0100 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme753-chm.china.huawei.com (10.3.19.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 15 Oct 2020 17:50:57 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Thu, 15 Oct 2020 17:50:57 +0800 From: "Dongjie (Jimmy)" To: Christian Hopps , "lsr@ietf.org" CC: "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorrd6LPPhXen00C59XVecrmqHqmYaqCw Date: Thu, 15 Oct 2020 09:50:57 +0000 Message-ID: <81f71f96d4344d31b423dc03ae9dd372@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 09:51:08 -0000 Hi Chris,=20 I support the publication of this document, and as co-author I am not aware= of any undisclosed IPR. Best regards, Jie > -----Original Message----- > From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Christian Hopps > Sent: Thursday, October 15, 2020 2:15 PM > To: lsr@ietf.org > Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr-chairs@ietf.org; > lsr-ads@ietf.org; Christian Hopps > Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >=20 > This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: >=20 > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ >=20 > The following IPR has been filed https://datatracker.ietf.org/ipr/3448/ >=20 > Authors, >=20 > Please indicate to the list, your knowledge of any other IPR related to= this > work. >=20 > Thanks, > Chris. From nobody Thu Oct 15 03:12:32 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CA03A0DCD; Thu, 15 Oct 2020 03:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.898 X-Spam-Level: X-Spam-Status: No, score=-11.898 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=HpoeoRAs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GhSWnLMg 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 fiv4rChKBYYD; Thu, 15 Oct 2020 03:12:29 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925A33A0917; Thu, 15 Oct 2020 03:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=674; q=dns/txt; s=iport; t=1602756749; x=1603966349; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Gty59HjRWpuXSrdN633U7G8oUXdO35zNWKzFZMRBPIU=; b=HpoeoRAs7YgLvZ+/Ih7hxXM+9DQhNQbsremqYs+0dUT8cX5FAWVcevWC 7h7yR4VpMyP0+8Qh13ukG7F54BE/r8wrFEYj7rH+2gSxHsZbP8YOoW+qN lZVHAH0/ns1ooY5UZDtymvJAKMpxxHI9gem0Nwadu1ErTs4QGR6TBxEvF Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AYNy6hBFgLJV8f+lkVLchTJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QGbVoXc8+pfze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX1Z1rKumb06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRCADUH4hf/5FdJa1gHgE8DAILFYF?= =?us-ascii?q?PgVJRB3BZLywKhDODRgOeDog+glMDVQsBAQENAQEjCgIEAQGESgIXgXECJTc?= =?us-ascii?q?GDgIDAQELAQEFAQEBAgEGBG2FXAyFcwIEEhERDAEBNwEPAgEIDgwCJgICAjA?= =?us-ascii?q?VEAIEAQ0FIoMEAYJLAy4BDqBZAoE5iGF2gTKDAQEBBYEzARNBgxYYghADBoE?= =?us-ascii?q?OKoJyg26GVhuCAIE4HIJNPoJcAgMBgVuDFzOCLZNPpCYKgmqJBJFqAx+DAwE?= =?us-ascii?q?RigiUKZMqinKVOAIEAgQFAg4BAQWBaiSBV3AVOyoBgj5QFwINkhCFFIVCdDg?= =?us-ascii?q?CBgEJAQEDCXyMOwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,378,1596499200"; d="scan'208";a="563315801" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2020 10:12:28 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 09FACRD3002243 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2020 10:12:28 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 05:12:27 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 06:12:25 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 05:12:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KXwN7wnQrMOGoEKKyiqTqucMDJN8S9a4aad5K+Mm50q6cwJ65a9SxQDZpW2fUplzR4df+SlcdBjzyI+YY7RH0ZAh1x0g7trIgEPbWCMeYwHymeUeFa6q7l3M2xhwiUn7ZQXKZ160IgxCbLIjIFf91GjEhr8rK7HIBRqn+zkyYZKinKnsog+TJDRjoIH4ld8t52HwNtZFM26ITkD1U7ecCtz6iHUEPqEnOpI0CHyzr/5nnSeiRuuI9qCdywPt+fWSR7EZXj28D+cL1nT+4wk8pnceoV7L6y3DoNo6gjtZCO/MurqS5rUWzyUgD2mQf/DmZObqrWnzaZzMSNHt7Emp6A== 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=Gty59HjRWpuXSrdN633U7G8oUXdO35zNWKzFZMRBPIU=; b=dLDboPgz/dWnOBlg4J1/S1327moWHRLm64AYT9oJeVChpvF9Jh6OqgMQfJWtM4kdId49PX6QFs/6I0wMEPHFy88bitViNe5JU+WR7PzsiAkYNtZ36VPoOqj/6ov/3f/gO7reByAzumH1qaa+WPicSkW7Uh3Z7i3Amrxv5LMFSsObmHgX1k6TtxtKLkOd4ATRQd+uRZc5LQXRaYZW0iDAY7Y67+eNdbQmuZHQwgnmp8RNgvCc9ELYOaq5L3be1ztwBy9yaTvl00noYQmwy0ABuEW8LlasmfBHaxwwhCxZLPKqe6Tbop8J3M51meQA+BnPM/hTIpGldAlT1dsQLhd2qg== 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=Gty59HjRWpuXSrdN633U7G8oUXdO35zNWKzFZMRBPIU=; b=GhSWnLMgZLDYJRYLFQz/4pDk23bEK1lTkdxGm1IArxsA+GyOxh1Z+QHCCG5l4vHRgy9RrgDBQxzL++Re4nCb8ZhJdkDtsXJRTXXM3bKzBzr6PSOIzhyGSyhSHEQp121tEUY2i/LaCzu+OtE14DXVHDEB/SHtqsjC7TWzj7DS4gE= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BY5PR11MB4209.namprd11.prod.outlook.com (2603:10b6:a03:1cc::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.28; Thu, 15 Oct 2020 10:12:23 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3477.020; Thu, 15 Oct 2020 10:12:23 +0000 From: "Acee Lindem (acee)" To: Christian Hopps , "lsr@ietf.org" CC: "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" Thread-Topic: WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorqiw9pv6soWMUKVhaUBbeDrx6mYLtWA Date: Thu, 15 Oct 2020 10:12:23 +0000 Message-ID: <0FF06AD3-D393-401E-A847-5140EBB0B350@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35444a87-2387-4559-4e31-08d870f2cf64 x-ms-traffictypediagnostic: BY5PR11MB4209: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uN0CGTz0Jam+RwCIX5CzIo4/46+xrIYvqE/h/zL730JI7kOU9a/nrNpOU4qkct25cRLCQcXPpfniGoNlGT9FDtfYVsLuminvx8pm3Do58v7tVkGl8AWS8ZsQ4yLO/o0+nvXHXmMZNNBpCC/fHzqzSt0FKnX4293+YrTV9YivCAeHqYG8CQuFVON9Ym1rN2m7TMbRdv3hNV572TQ+WPgiHOhixqy/hOD0n5owf0tPpeoG+WCZspTz3INZb4aiSnf3Y9qh/9e/AVNHkBHZRoUHgMsTemaZJCGgp2OemXpLOsQPFM2I1KV0aXjckS7jDARkjvsBhSxrFKd0WsBUMnZeSQ9zLRnkBz3EZGpndyNAnQqYqTVKVGCzdUAfFO29JvlJ3qbwv+bK8BU1joS/yu4CmA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(366004)(136003)(346002)(376002)(8676002)(478600001)(66446008)(66476007)(5660300002)(33656002)(4744005)(966005)(66946007)(64756008)(76116006)(66556008)(71200400001)(316002)(54906003)(6486002)(8936002)(83080400001)(86362001)(6506007)(26005)(110136005)(186003)(6512007)(36756003)(2906002)(4326008)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: /2XbfVq96O3xWbukJ5ejMXBUIFLmSA9DbHqNqUBIH7CMxUS1otsgDeOpvEwHNIlGcCNzfeEFfRlndXU8a6rI8wJF9pRrbPUHvPKsX+VKYblVPBATQTLgG8Ad3wRNVwVibRrd7zFZcQ8NsOtiDpNbpPH6t9koZp4Xf6r8Er4R37al7PP+SPY3Pb6suGbI06d21kAN+IuAOHAumjaSVK5OWMKSnbdC4g8W9Vh0EnHIGmRAoF8nk5+V4oKA5MdnrXVYxeXJ+IQdxO1VTewltKXAYCW0qgh7FOY90jBMKByLKo5dSDG7lS1dzz40GcyhZkEfUmauIYfo4fQFXrBXYCDpb6+2p3ONTVNHH0wKuU2kMQZkHO6flzdtPf/2Ppr1S9mvBuxjgJYXbJ+OLLVFI66PR5+kLB+1Gm7UKQyx4nIZWixdjfCtQoWBkxeZ3qIRTHzUFTWaVYbz3TgeEXWNq4Vhn82m2+ytA1mPPZQ0zt7tl1Y2px/97dVmWbTGfJRF35vhVykTaF75vhTJz9P3mnFRgGUariesNYis8daz/vgFXDP32gzEuqv0Y+DHOrXeIlPfnb29+/KbSbTyjNULQvGLd2496wcuV7wuJtLLC7DOmTFLg+bGMGHwRnaBVAQtNsuYDFBcKwA0mflEIocvT5GOqg== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35444a87-2387-4559-4e31-08d870f2cf64 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 10:12:23.5439 (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: DVENNPpX+oROWdMKWGBQlJESZaoIJt8TS+BBvl02n0XliOhTTkXLkXc36mjBMKS6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4209 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 10:12:31 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUi4gDQpUaGFua3MsDQpBY2VlDQoNCu+7v09uIDEwLzE1 LzIwLCAyOjE1IEFNLCAiQ2hyaXN0aWFuIEhvcHBzIiA8Y2hvcHBzQGNob3Bwcy5vcmc+IHdyb3Rl Og0KDQogICAgVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTGFzdCBDYWxsLCBlbmRpbmcgYWZ0ZXIg T2N0IDI5dGgsIDIwMjAsIGZvcjoNCg0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci8NCg0KICAgIFRoZSBm b2xsb3dpbmcgSVBSIGhhcyBiZWVuIGZpbGVkIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv aXByLzM0NDgvDQoNCiAgICBBdXRob3JzLA0KDQogICAgICBQbGVhc2UgaW5kaWNhdGUgdG8gdGhl IGxpc3QsIHlvdXIga25vd2xlZGdlIG9mIGFueSBvdGhlciBJUFIgcmVsYXRlZCB0byB0aGlzIHdv cmsuDQoNCiAgICBUaGFua3MsDQogICAgQ2hyaXMuDQoNCg== From nobody Thu Oct 15 03:32:59 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922573A10EB; Thu, 15 Oct 2020 03:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=J5EFzL6S; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EX3piSuu 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 J6Y0y-lGSckO; Thu, 15 Oct 2020 03:32:57 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9B83A113E; Thu, 15 Oct 2020 03:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=950; q=dns/txt; s=iport; t=1602757977; x=1603967577; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=39Fs+0MKB8fLcjOhwG2ubsk4AslAGU+1tcsGzHS4zVQ=; b=J5EFzL6SoFT5GasHVor32TJRq0weyF1XmsL5N35rDOzsUA32rZDu/zqp b0qZtwDI5wF7ziGq+rPGILqNozEVSJZjmWSZT6xwuX9DM3WQa5Z1uTzua hpCvPOL6aVVaW0zqgoMp1eaC4Y+q5hcw20tCB89B//vPwfJTCD0SPyiy0 w=; IronPort-PHdr: =?us-ascii?q?9a23=3AQZQLwRQHZynIOAZv/tkcaJow29psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNuJ4PJDk/LN9af6Vj9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Zonqq9SVUHQ?= =?us-ascii?q?/wZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmEAD3JIhf/4oNJK1gHQEBPAEFBQE?= =?us-ascii?q?CAQkBFYFPAoFQUQdwWS8sCoQzg0YDjSuZIYJTA1ULAQEBDQEBIwoCBAEBhEo?= =?us-ascii?q?CF4FxAiU3Bg4CAwEBCwEBBQEBAQIBBgRthVwMhXMCBBIREQwBATcBDwIBCA4?= =?us-ascii?q?MAiYCAgIwFRACBAENBSKDBAGCSwMuAQ6gXwKBOYhhdoEygwEBAQWBMwETQYM?= =?us-ascii?q?SGIIQAwaBDioBgnGDboZWG4IAgTgMEIJNPoJcAgMBgVuDFzOCLZNPpCYKgmq?= =?us-ascii?q?JBJFqAx+DAxKKCJQpkyqKcpU4AgQCBAUCDgEBBYFqJIFXcBU7KgGCPlAXAg2?= =?us-ascii?q?SEIUUhUJ0OAIGAQkBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,378,1596499200"; d="scan'208";a="583329308" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2020 10:32:56 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 09FAWuAa030667 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2020 10:32:56 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 05:32:55 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 06:32:55 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 05:32:54 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nHvs3w3cNIMRHZWlkysbnP+TGbNetdVZGLoPZcB6OXrmsQeKKSc57r4yq8B5hXyHybfrkWNmC01X1eR/vYOG3zWk3bagzf0zgQIdlUVrGiXnB+2AmSWfhu+GHIkpazJebBJljR/u+C6J32rbDyBGGzRAvO2oH7cJD7U7cWMY4TQnV/uS1j4d56g2YfMbJemuXDGd6H4zNAS7Ate6mWpPZYKNVjdPhWH3y/+7QjoMn97bY5TpTwzMNpOq0OWJPbwzn+24LiUBevtxyhwbORETseD2ZA86V+dorGVPAYitondKWyo/UiZ5iHwQsmXOvJM3zaj7haUO7reM6xRuTz4NBg== 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=39Fs+0MKB8fLcjOhwG2ubsk4AslAGU+1tcsGzHS4zVQ=; b=F0JDasgG2Cusr+h+chxBB6zmT30YEKAZhJooCOAL/fEtds6TU57j/A8P8CUXVTG5uHoPr5OVOM+HxqSS2p58LaGqzh/ooF4KbbHM7CbWivDx6cG/0vfjexm8/VmJ5Wd7q5tpKO1MOHJPzJrdexieYmR2nyXrjTLrAI9010ADI+BmPfOzjTmiDswZVguF1MDInUgk2QQjBrOmiKk/9zS4IrVNm812+ZUnyx9S7xPFHM5KTQYMQ6sj6Tj24hTdBYXA5nH0hx8BEPJcLAJwzLzXpbawA5kdhjA1svO3uJ5YNEZEh55YyZn/cCGoMGnk0vifNXwTCU65H56v6Ocvu2sVeg== 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=39Fs+0MKB8fLcjOhwG2ubsk4AslAGU+1tcsGzHS4zVQ=; b=EX3piSuumTjCwR/lpDHufaPKmKFh8DRYyslDT3WdKVRWoBBWiYKctldpjNDTIYRoyaq9SfMuucyFHbbhvGDbEfCIDy+HJzxNOvFjMU9Id0KjQ8rqnmmzy+vyfRlTVeVottSyZL2Y3Vvrx/sXGnZLHxYqRIlr89g6ffvyOFrgmxk= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3078.namprd11.prod.outlook.com (2603:10b6:a03:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Thu, 15 Oct 2020 10:32:52 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3477.020; Thu, 15 Oct 2020 10:32:52 +0000 From: "Acee Lindem (acee)" To: Christian Hopps , "lsr@ietf.org" CC: "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" Thread-Topic: WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorqiw9pv6soWMUKVhaUBbeDrx6mYLtWAgAAFsYA= Date: Thu, 15 Oct 2020 10:32:52 +0000 Message-ID: <5BD96843-3484-432A-93D2-FCB3D92C1DB3@cisco.com> References: <0FF06AD3-D393-401E-A847-5140EBB0B350@cisco.com> In-Reply-To: <0FF06AD3-D393-401E-A847-5140EBB0B350@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a34684e9-e7e2-41a3-50a7-08d870f5abf4 x-ms-traffictypediagnostic: BYAPR11MB3078: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FyUxp4IKyGleM20evTXgy+nm+xBAk+8hrw+iUERdcN6/JUcaQgHzKsq4kFRtAE9yW6Ut3Zcz9xUwZo8ld5T8drsBjrMku3zwmb/kAHcWwgn80a8y/X4HZTmg0dawocf64Bs/ZJg37QAkgXSuqfOQOnICI8pVj1Gtr8+eMnTdfijAwKNL8Ydm29UCvzOOhFx04O//NT5NdWDYBveXgAJTyP/8Wj9H3zUJwzwKG+Tq6kCl8hNIyKWm4QLDUbuQ13vZ87452cLF3ueo+gSt3rWqIw69Y3S9sey8YZrwvl54q9KZ15EgnN1/uKk/r2u5sVnfjBJ25kybhtC/o1v82ebTALMgPBHFv4I5mPTkRX921380Iu+QvYj8pIJCk6tp9JsCxbNdxh8Ruf2h+ib2PZ19Jg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(39860400002)(346002)(376002)(136003)(66476007)(6512007)(36756003)(478600001)(110136005)(54906003)(71200400001)(316002)(4326008)(33656002)(83080400001)(8676002)(966005)(6506007)(26005)(66556008)(86362001)(76116006)(8936002)(64756008)(66946007)(66446008)(4744005)(6486002)(2906002)(5660300002)(186003)(2616005)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: W2bP1RglGDbCTrMtbYcPWDSCSmkyMjG1uMSEq9B0imwcKmj8hzL0MfUN9OK+1fRDcEUVZZeZCjMdpoCRqQXJVnxHRitgC+Nb6X6gSSPP+m0O7iGUC9339oLQlzMbdxGwuE/vfckHTgaJRSdASy1e7k6OzBF+63j5rPojF6TIR6MMAybv8ovWnNDUOW3zzJEVG0vmN20vDE3FUCraBKaqywwKeFjWPclMQCnIAAZn969A3Q90JTqA79pxxOpxQyh2/AxS44yn9142MQJ7Vhzs9nQXJQZ0jp+GhE3bzOcnKHkMkaVm/abTrte0oWUdftbdlqhtXms3dhhIK8VzVyVYDQK2vY8SK68STyhfsU6sW9xHHcJRs8lhwmTAIzUbBuB1qMbl7X8fbEQGM+PAnC7hc5uQ3I5PMwlRTLRAkMMHkGo9QpmtqjlxNX1+xBkXg0ZqnXC8CDMACDD4tX+Sk6n1GAgHE+RPUTl3WmY5VVS8F/2toOqJA7J7d81mO/HHKZrxhcPZh9l4RRqZgAfLp8UhsceLduUp116CZ9e4eH1Stjz48JLiF/Ro/adYBvjz7+5qIhSOZoilMGErkymtvGpUwQmyBKFBI2a8xL6fQG/cJTSSZVKND5CZ9kYoN7+VlkC2bpcn7Px8JVU+kUPorCvrIA== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a34684e9-e7e2-41a3-50a7-08d870f5abf4 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 10:32:52.5859 (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: evlzYk+tth2RSInkXL6GZZNUZfKE2VpuyZ4gfog6wtq6ci/qv5AbSRoLMF2q1LBi X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3078 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 10:32:59 -0000 QWxzbywgc3BlYWtpbmcgYXMgV0cgbWVtYmVyIGFuZCBjby1hdXRob3IsIEkgc3VwcG9ydCBwdWJs aWNhdGlvbi4gDQpUaGFua3MsDQpBY2VlDQoNCu+7v09uIDEwLzE1LzIwLCA2OjEyIEFNLCAiQWNl ZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KDQogICAgSSBhbSBub3Qg YXdhcmUgb2YgYW55IElQUi4gDQogICAgVGhhbmtzLA0KICAgIEFjZWUNCg0KICAgIE9uIDEwLzE1 LzIwLCAyOjE1IEFNLCAiQ2hyaXN0aWFuIEhvcHBzIiA8Y2hvcHBzQGNob3Bwcy5vcmc+IHdyb3Rl Og0KDQogICAgICAgIFRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExhc3QgQ2FsbCwgZW5kaW5nIGFm dGVyIE9jdCAyOXRoLCAyMDIwLCBmb3I6DQoNCiAgICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLw0KDQog ICAgICAgIFRoZSBmb2xsb3dpbmcgSVBSIGhhcyBiZWVuIGZpbGVkIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvaXByLzM0NDgvDQoNCiAgICAgICAgQXV0aG9ycywNCg0KICAgICAgICAgIFBs ZWFzZSBpbmRpY2F0ZSB0byB0aGUgbGlzdCwgeW91ciBrbm93bGVkZ2Ugb2YgYW55IG90aGVyIElQ UiByZWxhdGVkIHRvIHRoaXMgd29yay4NCg0KICAgICAgICBUaGFua3MsDQogICAgICAgIENocmlz Lg0KDQoNCg== From nobody Thu Oct 15 09:33:35 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38763A08E3; Thu, 15 Oct 2020 09:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, RCVD_IN_MSPIKE_H2=-0.001, 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=h7cg5cIz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LiGynOOe 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 dRb09HjJTL1q; Thu, 15 Oct 2020 09:33:32 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B133A08C7; Thu, 15 Oct 2020 09:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1610; q=dns/txt; s=iport; t=1602779612; x=1603989212; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4iIgOQFQZLscgno4yDhN8xnOiZ/54fSxqg/m2Wp7tIA=; b=h7cg5cIzaE0WRjFl0gFP8mc/SmMv/XkKGQ2oNpN+yTEkaITZR+frpnUI kdY5Gp0TDcjwaZuM53G9GTzY70EStQnA0spIy3szHYSs39YYx38OxqN+K mqUjU5H/51uL9lHMHJHgvYz7M7t5jW3uUsz/dBtP9Ob4Hxjx6aC1sSp3r Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AsMAEBBVUptFwRkrYEFV0QdOSMkzV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyFuflEjPLOqObnQ2NTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBqX219SYJXB?= =?us-ascii?q?LlOlk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGEAC8eIhf/4kNJK1gHQEBPAEFBQE?= =?us-ascii?q?CAQkBFYFRgVBRB3BZLyyIAwONUZh7gUKBEQNVCwEBAQ0BASMKAgQBAYRKAoI?= =?us-ascii?q?IAiU4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDEigGAQE3AQsEAgEIDgM?= =?us-ascii?q?EAQEfEDIdCAIEAQ0FCBqDBYJLAy4BDqFoAoE5iGF0gTSDAQEBBYEzARNBgxM?= =?us-ascii?q?YghADBoE4AYJxikQbgUE/gRABQ4JNPoJcAgMBgUEcJIMkgi23fAqCaokEkgy?= =?us-ascii?q?DFooIlCyTLIpzlToCBAIEBQIOAQEFgWsjgVdwFTuCaVAXAg2SEIUUhUJ0OAI?= =?us-ascii?q?GCgEBAwl8jUwBAQ?= X-IronPort-AV: E=Sophos;i="5.77,379,1596499200"; d="scan'208";a="580989447" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2020 16:33:30 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 09FGXUsN023398 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2020 16:33:31 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 11:33:30 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 11:33:30 -0500 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 11:33:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZDhOOVxQwltU6l3bt0ATXY4VrS0UQAI6VnlkEpSXectH4BcWy0K1AdBKIGps9hWKsuzMLXyRyMvin0ElDz+Kt5/FrS4qLvv6L/46aKA4Nm2PYCcLjPRHZu6xhveoqo4bzNNmdKTGOBWW+rCyNk7WORsrPEyn6Y+oYW2Ms5v65wEqywlQ/1KajGycRvPx27GXu4qCpDCSEe5u/BGayIbMZNBTel+Tx8ZXH+5QvyoFsB3KJwR6UD+r20at937KKUU6huUQ2mlLPZtd8gLHhj5HVwbknAQmyrwDly3xc0oghRgFizWRR8PiQDMkh3EDfab8bmuts0AKUHTbcx87qwaztw== 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=+bwoQo6U6ZtZ2rf9YSapfJdqtrzaB6IShBLGc7dTDRI=; b=mFAMkX57nijnqe2Dhi5TRwH0vri1DRuaaxV/Dg6Y+8HJ1KgbYjeodIJJxL/LztSr/5NGJ9rztVVAFOafs94aJCrefG1Om3tQeK4v/xd2P3D82eHYZz1d7P06uuRMEyll1BnTjRkdjt4WQJ9o91HGNSlJpkpjLpjfGzAj8hfJlV+TQj2nxapfOW/tW86ivOtoZu2LAQ4qtjTNB3oCdjc0y7BBLTo4LfXVJuaWoaxgcshJ0zT1DoW73Ue8yDexZEGopBQxT2G31tYHcHYZWtM212JDhwawosPFxfkcpGIP6n7lvL5lc4KpRT4ryhgV2/42Af9GTlsmHSgDlJXy20Izhg== 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=+bwoQo6U6ZtZ2rf9YSapfJdqtrzaB6IShBLGc7dTDRI=; b=LiGynOOe0KV5woUKUEiOR89BJ+LAdFhYYelwt22Ruf5VXuZjSzgYw0u86ydfWaBvN8bKbPjWqcEKbPqacOYrREcNYl/R/T8QXjKQxI8RD3U7qH3RmD5vOwElFSvTvOXVVnkow+uuEoyOfS9TLYbAX7n6gXSiuu8LCjpkvTF0rkA= Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BY5PR11MB4292.namprd11.prod.outlook.com (2603:10b6:a03:1cb::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Thu, 15 Oct 2020 16:33:28 +0000 Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf%3]) with mapi id 15.20.3455.030; Thu, 15 Oct 2020 16:33:28 +0000 From: "Les Ginsberg (ginsberg)" To: Christian Hopps , "lsr@ietf.org" CC: "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorrKRY+9H8pM3U+ItYWSF6YHFamY2IdA Date: Thu, 15 Oct 2020 16:33:28 +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: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2602:306:36ca:6640:2d9a:f9b6:44f7:40a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dfd7550b-9137-47a0-2297-08d871280c1e x-ms-traffictypediagnostic: BY5PR11MB4292: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9TyUhTiQdK9orQCex77DthHjMj22IMpkhNO1ZHNL1upbGoKP2//qY+NEYsADoa9cuYcLe0bZlVaSVTyL785I5BzuNYEDCS09ogyPrkQWTAIMxHVYYdWp0c21HedwvXXhdM/o4LA169Lchb0V/3ZGNRkKUc429UBeJLFw85LjoHA3L2h7MIlwzR50O4IbP8GNnoOdtoRQ3WR8c2ShhIHcZxYPvk3m6bTgjFWYGgx5e5MCcRpVWWya9MhROpEX2MWPqmur4Ewh60xZ+Pz7LWccbU5LasbRWXUd0eR76LAu1Yn7+ORymY9HTK/yIMoUeCvWHm8+efiwweireueQVLD3fzeYpKg0zrAIl15GMkGbFoCd/yeP/byIhRNA5nctVXOX6w7K4I4815lHAush+89fHQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(39860400002)(346002)(376002)(5660300002)(55016002)(8936002)(4326008)(9686003)(8676002)(966005)(110136005)(86362001)(6506007)(66446008)(66946007)(66476007)(76116006)(64756008)(66556008)(54906003)(316002)(478600001)(33656002)(7696005)(186003)(53546011)(52536014)(71200400001)(2906002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: mWfI4pYwDO274hem1HHH85P6vTo555tNUJyY0uqScG4PnI/xnx/mKK10+x6cn3JzXZLgYDky/vqYsT5+Av4UeHIEB3NnvsFnc8ff4L/2Pe/xHXebT6QcdOG8EjC3PFxUVzTMMHC+9a2xKTQgbfINyhqkO5vYtEqShW1ecdZaTkG3S5CdZ4mGaohA0EFJsDqb+2c0egu516abZD1jDJJzUiONh7mEtz6h7IpGSCgBMDW84R96lj/5Wg1QX3g83hct6vV3cW3meM9tPLQTF0WlzWKe52QAxvuofQjY1FEkkRvtKgQwB5P+98Eb8boobthZFD3OSsTlBLYyIelBTc2AKan7tshwfK6eJTHrVP4jcWok6MIm6oNu1B/dvBo7wGwZMsIHF12K1jPx+Rt5gVm2HmzdpAudmbftEuuJSaHEQBMSje1Fj1+wtkvo7N3TSSUe6ukur1/CUW4KwX9Z7WByPdg/zpUtvoCV5zPMbpT2GjjPKzgHZz02d8071uNJSLrzNLB3LLT0ZOWPbD4bIEYiBahgvt2fbSmrhYkuLv3ES2B0ialOf1yBehxf8+W1QtBBpzwRxwP1xjEPIN4w0JhyeaFbOWg/Q0qkVTtGUjsLXH+jFwbyTrB6mdeS/VJaBlLKkwcBIML+CGPi65yE7FMuOr7y3XqUtpVSDFHF5VaHQIP7jd+HvR1S7xlSusMVzwHV3T5e8Z0jNDqaDkpTLP8Prw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfd7550b-9137-47a0-2297-08d871280c1e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 16:33:28.6788 (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: 695aIFWA6QtIxcoGEreJZD8b2tF2nAhsTsYCNBFizB6j5O/15wU9n6hsN8AX+oD3Ib53zWhf6rqMpIwXZs22sg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4292 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 16:33:35 -0000 I support moving this document forward. Similar functionality in IS-IS has proved useful. I would however like to repeat comments I made earlier in the review of thi= s document. The content of the Appendices should be removed. The Appendices define and discuss deriving topology information from prefix= advertisements - which is flawed and should not be done. Perhaps more relevant, the purpose of the document is to define protocol e= xtensions supporting advertisement of the originators of a prefix advertise= ment. There is no need to discuss how this mechanism might be used to build= topology information. This document should confine itself to defining the protocol extensions - s= imilar the RFC 7794. If the authors do not agree to do this, I would encourage this point to be = discussed during IESG review. Les > -----Original Message----- > From: Lsr On Behalf Of Christian Hopps > Sent: Wednesday, October 14, 2020 11:15 PM > To: lsr@ietf.org > Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr-chairs@ietf.org; = lsr- > ads@ietf.org; Christian Hopps > Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >=20 > This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: >=20 > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ >=20 > The following IPR has been filed https://datatracker.ietf.org/ipr/3448/ >=20 > Authors, >=20 > Please indicate to the list, your knowledge of any other IPR related to= this > work. >=20 > Thanks, > Chris. From nobody Thu Oct 15 11:33:09 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CA23A11E6; Thu, 15 Oct 2020 11:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.997 X-Spam-Level: X-Spam-Status: No, score=-3.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=OECjL37y; dkim=pass (1024-bit key) header.d=juniper.net header.b=aNY42uYr 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 suWvNJvbRAbj; Thu, 15 Oct 2020 11:33:05 -0700 (PDT) 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 548793A11E2; Thu, 15 Oct 2020 11:33:05 -0700 (PDT) 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 09FIHOkZ016455; Thu, 15 Oct 2020 11:33:04 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=kcvFzLm+vXp1CMETl6L+hH0TArGVC6yjB4Li+VEJ8Zo=; b=OECjL37y6vsSwdGrpm9uIC69fbkX2jQiQMXzIOgCifJVrCMqBzB+GacBA4GNz87x8vkT UZiLpSRz+sAS4jUHfw7q6CwJFmSKo99dMChnbB5vOz0MYYOA9lYLUyodXKlme8qoSAPq 7V+h/ksHTX4hGz6utnQAdfyMVamfMzeorbvHOlJ6LmViHBp5S8D6jW9Iyvu0OZ8lekVk JLabFfgAZruNTzc1SksHAAnGmNjz3DlI/4E3ucxyVPVE83uIa3AkVMCLCk8OuJbtu4ju OviMX0ZZcqVtNGpsXjX9i4lDOg64EVvVhd3T+knbPR59Hlc0kR8uUEjWlzE4cQeSEXdy 0A== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2172.outbound.protection.outlook.com [104.47.57.172]) by mx0b-00273201.pphosted.com with ESMTP id 3468t51s8t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Oct 2020 11:33:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Clw0aGZkXLXRkzCZb9eX1sZNxnjpRPImwj8/Y1svQUs6wnaxRplk7crI48cQMVbxOyWfA1ivridJHUY4nFdM7Ik/g/PLWJrll1bGBYl78p6M4UmjLQgKeBAcjrWfzJhRRdlFo6uRWvxeMpLreJUR9cjdePs7GDZrS8aJCOaz9eAcxzLcsRJnOqI6LaTsjIXFpTN0iZdr/TayTAY4wI7lOIbMvY+mMdGrxkNYay+Sl8phf4r1G8GyHSP+1zS7biCQHAOAMj+kS/af7t7YXXD9nlXWsw31xr51Y3/QSKLIfiAsx6CHl6qi5Jtn8FvbtdYdcV/MKufHXo9T2egja7d+tw== 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=kcvFzLm+vXp1CMETl6L+hH0TArGVC6yjB4Li+VEJ8Zo=; b=ONjaBcTuWdzhiT67HVKk1hPJEVEf5ocv3stOd19Zvax6sU0e9oZgwIrF57IYt/pJddTKa4m4jxL/bHOZCKT0CTk7o5tS5JR9F3bL6g8eIj2XLo3ILuTYUolondtKdSV82CAoFuG5PaZ89Y81uBiB/Ok8NVEFRZwQkDqX49Au1UcpEiWRU+lGQXnfpzq90prn70zvfX6Vg/pKbeelb6631ur9x5zlKG54OkT8v1tHy/6PZazZhA1qE00kF0hD5LJdtdWxxrVDlBu5AgdbO9nNlIYFCmKWQ2t2nRLJLWM+qIkzf+7YBaHxc8n2IiRNL1u0CoVLJdYNSRWLXWu5VdtMZA== 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=kcvFzLm+vXp1CMETl6L+hH0TArGVC6yjB4Li+VEJ8Zo=; b=aNY42uYrCPsWipdB/eWrVgmV8vIoD0DpHs9B6/YaPLta2ntD9xTriSosHSC7VB6+JD+Kla5yv7BOuCBLvHOHm4wqXhfF8bfKUBtM0f3QiTU87b6KtvD2HK1Nz0RPE9f3AEO5OEg/Ywb+O8hamyvW+mJcGgRdHsVuv/QNsElSq84= Received: from DM5PR05MB3388.namprd05.prod.outlook.com (2603:10b6:4:40::18) by DM6PR05MB6986.namprd05.prod.outlook.com (2603:10b6:5:202::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Thu, 15 Oct 2020 18:33:01 +0000 Received: from DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865]) by DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865%7]) with mapi id 15.20.3477.011; Thu, 15 Oct 2020 18:33:00 +0000 From: John E Drake To: "Les Ginsberg (ginsberg)" , Christian Hopps , "lsr@ietf.org" CC: "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorqau3U4dgerCEqgRHM3T2BK7qmY3F0AgAAgktA= Date: Thu, 15 Oct 2020 18:33:00 +0000 Message-ID: References: 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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-15T18:33:01Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=8f400981-d79b-42a4-aa17-a819e54ed10e; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [100.6.43.167] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1a3fb83a-df69-4f37-920f-08d87138bf09 x-ms-traffictypediagnostic: DM6PR05MB6986: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y8CUL+nk4NAWon0K+uyTDxP2Us1tv+4YPvYkkm5V30pICw0oEa5++luWfTQMnWvpm4P7Jor8pXrtah8jvQdw113SGG4F5FD9aHiWG5tBwreWBgshiy+VKhTPaB7Q3tZiVelRZntSO2D8KYUysE8EC0RC5eCXV+IRF0JnfOPfsHXs75ltTf+Ln1VQeq4QUcSQP/14gyECyAf/HiL0W5uxPdEo1epuNYeuMo8GHQmq5+A5n0JNGCNDDGk460RXjzd26B2W3jCk+kgQF1lKTwu+Onz204VbLdfE1C4PNqD+bB3f4U3Sl56n0zvRbRcl4J++QH79CHpD5srHEF+KFm9zt4qcDJ/XkDZd6JusjWb5B8jOb4sqbUmZMT+bfkW8Eam3BaZjtMY1wm2zf1ZeclDWXQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3388.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(396003)(366004)(39860400002)(136003)(966005)(478600001)(76116006)(83380400001)(66556008)(6506007)(64756008)(66446008)(8936002)(8676002)(66946007)(66476007)(71200400001)(86362001)(53546011)(55016002)(33656002)(5660300002)(52536014)(54906003)(26005)(316002)(2906002)(7696005)(186003)(4326008)(9686003)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: kBpOEdi9iI7V5YC836cOiXLpZascFNSPLUyhqEOPf9L1N+1AqCCjvhfne/w78qTG2FPQyCgE1Ue+hsPpgerbGKH53zQaeRTZdYswRRIBLKyxFG9rS+m6TUUcozgj68sIJJz+Wto3Ju8tsaEsYJBc7yTApPDQIq/OYMP+OxZy/nUHJTcQM60q697xCMgmkH4+quau13yNqd1yYsuQW7gP2DgDAnKkc0bObHNKMNyKfG7yzB7msIANOmjqDI1ks9+8kQCGldqxTYeTFoiSrED+PCxlbjp/bvD/oW8bIZ42K7vMyiT6MCRcf/bD7PlYJYUnDtUkLFe/9P0S3I44cJ44hCPx6USAdvUI60fhha8EAgkyq6BK9foozRj90QAh8MSXB4PNrLcJHoPknvoyLX4BhoGW4Gl7vLv9hG9bqTPytLtdK2XVFPGk2eznGWOnzB5/eDhwo2+vLvVm9LCmxxJkNiAIJ7RSw+1eg1VXvfRpR7poGeF6AIQRVA2uF0usDoz7o1p69APF+2FbKMTafu+DNXeNwWWXF9SIS29T3BiAjCPDEEMM8FkkBZEHe2NPq3XHmCGCJRmf4E254ic1oU7St1xfx1n1exxFBdwVCiz1/Vfgk4ygXrqYLiILJhQ9bDYCQrOYJsqb94RQJ4N+j4k1JA== 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR05MB3388.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1a3fb83a-df69-4f37-920f-08d87138bf09 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 18:33:00.8199 (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: yyJ6fS8NOLrJ6yEIYJGi8kipNfNtojLJzwYn0pn8wk+eMChlxTAV6qz7C8oX5PikFwXfZZxpPR2yPeyHmg9jmA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6986 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-15_14:2020-10-14, 2020-10-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 spamscore=0 priorityscore=1501 clxscore=1011 impostorscore=0 mlxlogscore=691 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010150122 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 18:33:07 -0000 Hi, I agree with Les. This is a simple protocol extension for a specific purpo= se and there is no reason to include speculation about its use for other pu= rposes, particularly when it is inherently not suited for them. Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Lsr On Behalf Of Les Ginsberg (ginsberg) > Sent: Thursday, October 15, 2020 12:33 PM > To: Christian Hopps ; lsr@ietf.org > Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; draft-ietf-lsr-ospf-prefix- > originator@ietf.org > Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >=20 > [External Email. Be cautious of content] >=20 >=20 > I support moving this document forward. > Similar functionality in IS-IS has proved useful. >=20 > I would however like to repeat comments I made earlier in the review of t= his > document. > The content of the Appendices should be removed. > The Appendices define and discuss deriving topology information from pref= ix > advertisements - which is flawed and should not be done. > Perhaps more relevant, the purpose of the document is to define protocol > extensions supporting advertisement of the originators of a prefix > advertisement. There is no need to discuss how this mechanism might be us= ed to > build topology information. > This document should confine itself to defining the protocol extensions -= similar > the RFC 7794. >=20 > If the authors do not agree to do this, I would encourage this point to b= e > discussed during IESG review. >=20 > Les >=20 > > -----Original Message----- > > From: Lsr On Behalf Of Christian Hopps > > Sent: Wednesday, October 14, 2020 11:15 PM > > To: lsr@ietf.org > > Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; > > lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps > > > > Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > > > > This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: > > > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet > > f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLqhK > > 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ > > > > The following IPR has been filed > > https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! > > !NEt6yMaO- > gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz > > 5KtUHQ$ > > > > Authors, > > > > Please indicate to the list, your knowledge of any other IPR related > > to this work. > > > > Thanks, > > Chris. >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!= !NEt > 6yMaO- > gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8 > Lc$ From nobody Thu Oct 15 14:28:26 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7C3A0838; Thu, 15 Oct 2020 14:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 YBpY7mL7wvpa; Thu, 15 Oct 2020 14:28:23 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 1CEAC3A07CE; Thu, 15 Oct 2020 14:28:23 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id ds1so153877pjb.5; Thu, 15 Oct 2020 14:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=jzfu75G0quloxYPEA/X4Eq2d2bw5mrnN1Nf8C85tDxA=; b=VijdiLvC5ZIbvNZaQdvuDCA0ufSxInDgBU9Lmof8axFVqxc577XAmzLWiE3Ep9deEU bb44bG4c5GUDz4GufeU78/XSmOao7hqggGzEsnojQGCkGVLIesdUC0t1pg1qtWUCkFe3 y0rSruzzhEffTFcDrkswAVco7wrfw6waBGCpghY2DdCLxyb5rROgkBIMpUADuBXPyrcS X9VRg1zbO8rNwj0fW1k3sdrr+ifPrPRqYFYkKDHYS12lraJpqOJWW4xK15gV9WdaPykK q8gqjJL6sC09XXAfuFSfucaw8xbzNRCFwuHyoYI6qUmQLacfK3LUsfwtqQsd0DxkN5gV vivg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=jzfu75G0quloxYPEA/X4Eq2d2bw5mrnN1Nf8C85tDxA=; b=Fkv2Ou5y71QmQDaAV0FH5PxJ4H9i/iJHvxIDCigXCPbJYhlvpmKQW+2CLGMfcyKLll 33WPPi2iT9dt1rW1stWvbOqmm/8ETIzeSxAVhliGfztqGKKmhMA0Kv/oRD3YvWafxbNv yyT/rOml6GazfwTC003n05RKZep8dE/qZ69IrPYgIY3TOTLcNuEhhEjbcxB04zyfJUGF tUrpqayGFYIShqmW/0ULKKVsv1HmR0L1ewcrNQ4D1RaJUFqzeViM/OiYBLu8ieeEBPWG yAmJ8y33EavnI+A3xkYcv8sj0bbMiamMwv3wiLXoRy5WhD0QIc7j5V/qysnTbOmJdOKK j6kg== X-Gm-Message-State: AOAM532i8Sn3OuIH50xGSccF5CBKn3r4HkYSda7hHhc75xwKVwmOPvx4 6vh8Lu6NgbkeBam4VOFOwIaV4D3QZIQ= X-Google-Smtp-Source: ABdhPJxPxASdKCNPHCT8S5q5pGasfaSFf2DyfUmxlxbqnobHxRg7RYxehfrwxN4Hcjgy8cikVCgtlA== X-Received: by 2002:a17:90a:f001:: with SMTP id bt1mr633212pjb.116.1602797302637; Thu, 15 Oct 2020 14:28:22 -0700 (PDT) Received: from ?IPv6:2601:647:5c00:e83:85f8:9bc5:37dc:33f0? ([2601:647:5c00:e83:85f8:9bc5:37dc:33f0]) by smtp.gmail.com with ESMTPSA id o15sm224546pfp.91.2020.10.15.14.28.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2020 14:28:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jeff Tantsura Mime-Version: 1.0 (1.0) Date: Thu, 15 Oct 2020 14:28:20 -0700 Message-Id: References: Cc: "Les Ginsberg (ginsberg)" , Christian Hopps , lsr@ietf.org, lsr-chairs@ietf.org, lsr-ads@ietf.org, draft-ietf-lsr-ospf-prefix-originator@ietf.org In-Reply-To: To: John E Drake X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 21:28:25 -0000 +1 Regards, Jeff > On Oct 15, 2020, at 11:33, John E Drake wrote: >=20 > =EF=BB=BFHi, >=20 > I agree with Les. This is a simple protocol extension for a specific purp= ose and there is no reason to include speculation about its use for other pu= rposes, particularly when it is inherently not suited for them. >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > Juniper Business Use Only >=20 >> -----Original Message----- >> From: Lsr On Behalf Of Les Ginsberg (ginsberg) >> Sent: Thursday, October 15, 2020 12:33 PM >> To: Christian Hopps ; lsr@ietf.org >> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; draft-ietf-lsr-ospf-prefix- >> originator@ietf.org >> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>=20 >> [External Email. Be cautious of content] >>=20 >>=20 >> I support moving this document forward. >> Similar functionality in IS-IS has proved useful. >>=20 >> I would however like to repeat comments I made earlier in the review of t= his >> document. >> The content of the Appendices should be removed. >> The Appendices define and discuss deriving topology information from pref= ix >> advertisements - which is flawed and should not be done. >> Perhaps more relevant, the purpose of the document is to define protocol= >> extensions supporting advertisement of the originators of a prefix >> advertisement. There is no need to discuss how this mechanism might be us= ed to >> build topology information. >> This document should confine itself to defining the protocol extensions -= similar >> the RFC 7794. >>=20 >> If the authors do not agree to do this, I would encourage this point to b= e >> discussed during IESG review. >>=20 >> Les >>=20 >>> -----Original Message----- >>> From: Lsr On Behalf Of Christian Hopps >>> Sent: Wednesday, October 14, 2020 11:15 PM >>> To: lsr@ietf.org >>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >>> >>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>>=20 >>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: >>>=20 >>>=20 >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet >>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLqhK >>> 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>=20 >>> The following IPR has been filed >>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! >>> !NEt6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>> 5KtUHQ$ >>>=20 >>> Authors, >>>=20 >>> Please indicate to the list, your knowledge of any other IPR related >>> to this work. >>>=20 >>> Thanks, >>> Chris. >>=20 >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!= !NEt >> 6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8 >> Lc$ >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Thu Oct 15 18:21:15 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954D43A0DD4; Thu, 15 Oct 2020 18:21:13 -0700 (PDT) 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=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 XgyJz0f6E76M; Thu, 15 Oct 2020 18:21:11 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9623A0DCB; Thu, 15 Oct 2020 18:21:10 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 324ED46C40; Fri, 16 Oct 2020 09:21:06 +0800 (CST) From: "Aijun Wang" To: "'Christian Hopps'" , Cc: , , References: In-Reply-To: Date: Fri, 16 Oct 2020 09:21:04 +0800 Message-ID: <005d01d6a35a$9e33d730$da9b8590$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: zh-cn Thread-Index: AQKwdjX9pGLVkcrp6WHrBGYvmJBL86flxuxA X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGBpISxpKGUhIHkhCVkpNS0lDSkpJTU1PTEtVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hKTFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PCI6FCo*MD8dET0dDk8ZCBVL SjUKFA1VSlVKTUtJQ0pKSU1NQklMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUlKTko3Bg++ X-HM-Tid: 0a752eff05539865kuuu324ed46c40 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 01:21:14 -0000 Hi, Chris: I support the forwarding of this document and as author, I am not aware of other IPR except the disclosed one. Best Regards Aijun Wang China Telecom -----Original Message----- From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Christian Hopps Sent: Thursday, October 15, 2020 2:15 PM To: lsr@ietf.org Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr-chairs@ietf.org; lsr-ads@ietf.org; Christian Hopps Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ The following IPR has been filed https://datatracker.ietf.org/ipr/3448/ Authors, Please indicate to the list, your knowledge of any other IPR related to this work. Thanks, Chris. From nobody Thu Oct 15 18:51:33 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709783A0E46; Thu, 15 Oct 2020 18:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YXXWHVhW6ay9; Thu, 15 Oct 2020 18:51:29 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F4F3A0E45; Thu, 15 Oct 2020 18:51:27 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id D426C46C8C; Fri, 16 Oct 2020 09:51:21 +0800 (CST) From: "Aijun Wang" To: "'Jeff Tantsura'" , "'John E Drake'" Cc: "'Christian Hopps'" , , "'Les Ginsberg \(ginsberg\)'" , , , References: In-Reply-To: Date: Fri, 16 Oct 2020 09:51:20 +0800 Message-ID: <006001d6a35e$d9136ab0$8b3a4010$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: zh-cn Thread-Index: AQKxZ4cxGLGkLReI9SxNqo7tLyH7tQFQI5z6p9llMYA= X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZQkxPGE4ZGUwaTkgfVkpNS0lDSkhLQ0hJSUxVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NC46Hio*Hj8hET0fNE8aAQ8v IgkwCU1VSlVKTUtJQ0pIS0NIQ0lDVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUxLTEM3Bg++ X-HM-Tid: 0a752f1abe089865kuuud426c46c8c Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 01:51:32 -0000 Hi, Les, John and Jeff: Let's reply you all together. In my POV, The standard document should not define solely the protocol = extension, but their usages in the network deployment. As I known, = almost all the IETF documents following this style.=20 And, before adopting one work, we have often intense discussion for = what's their usages.=20 Such discussion in the mail list and statements in the document can = certainly assist the reader/user of the document get the essence of the = standard, and follow them unambiguously. Regarding the contents of appendices, as stated in the section, "The = Appendix A heuristic to rebuild the topology can normally be used if all = links are numbered." I think this can apply almost most of the = operator's network, and facilitate the inter-area TE path calculation = for central controller, or even for the head-end router that located in = one area that different from the tail-end router. Keeping the contents of appendices does not have the negative impact of = the protocol extension, it is just one reference for the usage of this = extension.=20 One can select not refer to it, if their networks are deployed with = large amount of unnumbered links. But for others, the heuristic applies. Best Regards Aijun Wang China Telecom -----Original Message----- From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Jeff Tantsura Sent: Friday, October 16, 2020 5:28 AM To: John E Drake Cc: Christian Hopps ; lsr-chairs@ietf.org; Les = Ginsberg (ginsberg) ; = lsr@ietf.org; lsr-ads@ietf.org; = draft-ietf-lsr-ospf-prefix-originator@ietf.org Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 +1 Regards, Jeff > On Oct 15, 2020, at 11:33, John E Drake = wrote: >=20 > =EF=BB=BFHi, >=20 > I agree with Les. This is a simple protocol extension for a specific = purpose and there is no reason to include speculation about its use for = other purposes, particularly when it is inherently not suited for them. >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > Juniper Business Use Only >=20 >> -----Original Message----- >> From: Lsr On Behalf Of Les Ginsberg (ginsberg) >> Sent: Thursday, October 15, 2020 12:33 PM >> To: Christian Hopps ; lsr@ietf.org >> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org;=20 >> draft-ietf-lsr-ospf-prefix- originator@ietf.org >> Subject: Re: [Lsr] WG Last Call=20 >> draft-ietf-lsr-ospf-prefix-originator-06 >>=20 >> [External Email. Be cautious of content] >>=20 >>=20 >> I support moving this document forward. >> Similar functionality in IS-IS has proved useful. >>=20 >> I would however like to repeat comments I made earlier in the review=20 >> of this document. >> The content of the Appendices should be removed. >> The Appendices define and discuss deriving topology information from=20 >> prefix advertisements - which is flawed and should not be done. >> Perhaps more relevant, the purpose of the document is to define =20 >> protocol extensions supporting advertisement of the originators of a=20 >> prefix advertisement. There is no need to discuss how this mechanism=20 >> might be used to build topology information. >> This document should confine itself to defining the protocol=20 >> extensions - similar the RFC 7794. >>=20 >> If the authors do not agree to do this, I would encourage this point=20 >> to be discussed during IESG review. >>=20 >> Les >>=20 >>> -----Original Message----- >>> From: Lsr On Behalf Of Christian Hopps >>> Sent: Wednesday, October 14, 2020 11:15 PM >>> To: lsr@ietf.org >>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps=20 >>> >>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>>=20 >>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: >>>=20 >>>=20 >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i >>> et=20 >>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLq >>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>=20 >>> The following IPR has been filed >>> = https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! >>> !NEt6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>> 5KtUHQ$ >>>=20 >>> Authors, >>>=20 >>> Please indicate to the list, your knowledge of any other IPR=20 >>> related to this work. >>>=20 >>> Thanks, >>> Chris. >>=20 >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >> __;!!NEt >> 6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8 >> Lc$ >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr From nobody Thu Oct 15 21:41:41 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD8E3A09C5; Thu, 15 Oct 2020 21:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, 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 g4qeJq6l-YyF; Thu, 15 Oct 2020 21:41:36 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 38CE83A09C4; Thu, 15 Oct 2020 21:41:36 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id x11so283021uav.1; Thu, 15 Oct 2020 21:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6gKmjfa4H5r+5zdFxyyRvFHZ9vV2VXdjVYxOUFoMlKc=; b=YlRLo6/JCpub5jdxntWUlGnDWvQ12NSO7cMWXvl/CzbyyCtUPx0ZEtaX5En3ZkUMe0 g9CBrboiRb3lIVZ8F9vOLmyIf4G868ydAtzSLU+m/8fkh6VEL3XhejR7MtMHCfs9hH5W 3cmP+CkBxeMB9Y78zfd235s386uZkNaXOU4dus47lzVnwqmSAkfDGYGfRiVuf92WBBxZ 5syganysCpJ+kf6LQ4r44Wt82Q7YYpJ3F9QMnTiFJDQgP6r/mgWpSBlLbd9l+RMJR+tH pP0KSsk85PSpvumgxnZ1qYwX2zcDacHOKJehxysDrQb9IGPcqYCJj4ETNjqScfJb8o4N lK3w== 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=6gKmjfa4H5r+5zdFxyyRvFHZ9vV2VXdjVYxOUFoMlKc=; b=GZaI1Txqs8MbJrqhcTIyCy3J9VrTVpHxYoStolZuTz0YoJ8VV89/TQeDV8DwYZQAHT 76FLuiUmBqG+k+Ns0FMsWbujCxHPoj+zj16DrfIr4m5Wf4wmPlmZhjRVEJ1IhjiU9D5J u0CeWq1yd91IOgplKN9PIyaQ1eT8vbsf+kUIDR05qHpkydaPlPkyHzukQnQzHtFKKxlA 3Rt9RK6IH2BLEQtNXVKBhS5QKEoL5vN+f/sf6JelWsra86hJv69HnG/rCtRlN6sqVByM w6hPcSeVjXpnmzBECB1V5nSv0efoEwHaSxwczbta/6ft+Il7YxFbZEPpcz5/24wW4R5A B2iQ== X-Gm-Message-State: AOAM531RNvttAVu5VS3kDlwQyH0nvXZ3yfJGf40GkmZyaz2D8JvUnFCb VPBX0FX/PzBj2Y/LPcbeVqL+TCXDTw2q3ch2KuI= X-Google-Smtp-Source: ABdhPJwOBmxpRQq5RHW5cJ62YLKzO2RamMc2gKr5R8PCG9+JJ+LdAlzbBlwtZ1dKbMqFvyleo9GPC5HZtHuXjrA5YTk= X-Received: by 2002:a9f:301e:: with SMTP id h30mr965130uab.114.1602823295009; Thu, 15 Oct 2020 21:41:35 -0700 (PDT) MIME-Version: 1.0 References: <006001d6a35e$d9136ab0$8b3a4010$@tsinghua.org.cn> In-Reply-To: <006001d6a35e$d9136ab0$8b3a4010$@tsinghua.org.cn> From: Gyan Mishra Date: Fri, 16 Oct 2020 00:41:24 -0400 Message-ID: To: Aijun Wang Cc: Christian Hopps , Jeff Tantsura , John E Drake , "Les Ginsberg (ginsberg)" , draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr@ietf.org, lsr-ads@ietf.org, lsr-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000002306db05b1c261d6" Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 04:41:39 -0000 --0000000000002306db05b1c261d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support advancement of the draft. This draft follows along the lines of ISIS RFC 7794 to provide an extension to identify the prefix originator attribute using an originating router TLV and a reachable prefix. A node in ospf is represented by a router-id which technically can be a random 4 octet prefix that does not have to be reachable entry in the IGP RIB. The reachability prefix is important in cases where the originator router-id is not in the RIB or in traffic engineering inter as path instantiation use case where the router-id originator node is advertised, however since the TEDs database link attributes are not known inter-as,having the reachability address is important as defined in the draft. This feature can also be used identifying the prefix originator in a normal user case other then the traffic engineering scenario such as for troubleshooting which is common to view all the prefixes advertised by a node by Prefix type. There maybe cases where you need to create a database filter or policy and if you can use this feature as a means of controlling prefix advertisements based on source node that can be powerful and could have ubiquitous use cases. With regards to the appendix it does appear to be pertinent, as the use case appears to be the primary focal point and reason for the draft by the authors. I don=E2=80=99t think that having the appendix precluding other = use cases by any means. Kind Regards Gyan On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang wrote: > Hi, Les, John and Jeff: > > Let's reply you all together. > In my POV, The standard document should not define solely the protocol > extension, but their usages in the network deployment. As I known, almost > all the IETF documents following this style. > And, before adopting one work, we have often intense discussion for what'= s > their usages. > Such discussion in the mail list and statements in the document can > certainly assist the reader/user of the document get the essence of the > standard, and follow them unambiguously. > > Regarding the contents of appendices, as stated in the section, "The > Appendix A heuristic to rebuild the topology can normally be used if all > links are numbered." I think this can apply almost most of the operator's > network, and facilitate the inter-area TE path calculation for central > controller, or even for the head-end router that located in one area that > different from the tail-end router. > > Keeping the contents of appendices does not have the negative impact of > the protocol extension, it is just one reference for the usage of this > extension. > One can select not refer to it, if their networks are deployed with large > amount of unnumbered links. But for others, the heuristic applies. > > Best Regards > > Aijun Wang > China Telecom > > > > -----Original Message----- > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of > Jeff Tantsura > Sent: Friday, October 16, 2020 5:28 AM > To: John E Drake > Cc: Christian Hopps ; lsr-chairs@ietf.org; Les > Ginsberg (ginsberg) ; lsr@ietf.org= ; > lsr-ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org > Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > > +1 > > Regards, > Jeff > > > On Oct 15, 2020, at 11:33, John E Drake 40juniper.net@dmarc.ietf.org> wrote: > > > > =EF=BB=BFHi, > > > > I agree with Les. This is a simple protocol extension for a specific > purpose and there is no reason to include speculation about its use for > other purposes, particularly when it is inherently not suited for them. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > > >> -----Original Message----- > >> From: Lsr On Behalf Of Les Ginsberg (ginsberg) > >> Sent: Thursday, October 15, 2020 12:33 PM > >> To: Christian Hopps ; lsr@ietf.org > >> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; > >> draft-ietf-lsr-ospf-prefix- originator@ietf.org > >> Subject: Re: [Lsr] WG Last Call > >> draft-ietf-lsr-ospf-prefix-originator-06 > >> > >> [External Email. Be cautious of content] > >> > >> > >> I support moving this document forward. > >> Similar functionality in IS-IS has proved useful. > >> > >> I would however like to repeat comments I made earlier in the review > >> of this document. > >> The content of the Appendices should be removed. > >> The Appendices define and discuss deriving topology information from > >> prefix advertisements - which is flawed and should not be done. > >> Perhaps more relevant, the purpose of the document is to define > >> protocol extensions supporting advertisement of the originators of a > >> prefix advertisement. There is no need to discuss how this mechanism > >> might be used to build topology information. > >> This document should confine itself to defining the protocol > >> extensions - similar the RFC 7794. > >> > >> If the authors do not agree to do this, I would encourage this point > >> to be discussed during IESG review. > >> > >> Les > >> > >>> -----Original Message----- > >>> From: Lsr On Behalf Of Christian Hopps > >>> Sent: Wednesday, October 14, 2020 11:15 PM > >>> To: lsr@ietf.org > >>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; > >>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps > >>> > >>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > >>> > >>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: > >>> > >>> > >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i > >>> et > >>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLq > >>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ > >>> > >>> The following IPR has been filed > >>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;= ! > >>> !NEt6yMaO- > >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz > >>> 5KtUHQ$ > >>> > >>> Authors, > >>> > >>> Please indicate to the list, your knowledge of any other IPR > >>> related to this work. > >>> > >>> Thanks, > >>> Chris. > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > >> __;!!NEt > >> 6yMaO- > >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8 > >> Lc$ > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000002306db05b1c261d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support advancement of the draft. =C2=A0

This draft follows along the line= s of ISIS RFC 7794 to provide an extension to identify the prefix originato= r attribute using an originating router TLV and a reachable prefix.=C2=A0 A= node in ospf is represented by a router-id which technically can be a rand= om 4 octet prefix that does not have to be reachable entry in the IGP RIB. = =C2=A0

The reachability = prefix is important in cases where the originator router-id is not =C2=A0in= the RIB or in traffic engineering inter as path instantiation use case whe= re the router-id originator node is advertised, however since the TEDs data= base link attributes are not known inter-as,having the reachability address= is important as defined in the draft.=C2=A0 This feature can also be used = =C2=A0identifying the prefix originator in a normal user case other then th= e traffic engineering scenario such as for troubleshooting which is common = to view all the prefixes advertised by a node by Prefix type.=C2=A0

There maybe cases where you nee= d to create =C2=A0a database filter or policy and if you can use this featu= re as a means of controlling prefix advertisements based on source node tha= t can be powerful and could have ubiquitous use cases.

With regards to the appendix it does appear = to be pertinent, as the use case appears to be the primary focal point and = reason for the draft by the authors.=C2=A0 I don=E2=80=99t think that havin= g the appendix =C2=A0precluding other use cases by any means.=C2=A0


Kin= d Regards=C2=A0

Gyan

On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
Hi, Les, John and Jeff:

Let's reply you all together.
In my POV, The standard document should not define solely the protocol exte= nsion, but their usages in the network deployment. As I known, almost all t= he IETF documents following this style.
And, before adopting one work, we have often intense discussion for what= 9;s their usages.
Such discussion in the mail list and statements in the document can certain= ly assist the reader/user of the document get the essence of the standard, = and follow them unambiguously.

Regarding the contents of appendices, as stated in the section, "The A= ppendix A heuristic to rebuild the topology can normally be used if all lin= ks are numbered." I think this can apply almost most of the operator&#= 39;s network, and facilitate the inter-area TE path calculation for central= controller, or even for the head-end router that located in one area that = different from the tail-end router.

Keeping the contents of appendices does not have the negative impact of the= protocol extension, it is just one reference for the usage of this extensi= on.
One can select not refer to it, if their networks are deployed with large a= mount of unnumbered links. But for others, the heuristic applies.

Best Regards

Aijun Wang
China Telecom



-----Original Message-----
From: lsr-bounces= @ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake <jdrake=3D40juniper.net@dmarc.ietf.org>
Cc: Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) <ginsberg= =3D40cisco.= com@dmarc.ietf.org>; lsr@ietf.org; = lsr-ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.o= rg
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
+1

Regards,
Jeff

> On Oct 15, 2020, at 11:33, John E Drake <jdrake=3D40juniper.net@dmarc.ietf.o= rg> wrote:
>
> =EF=BB=BFHi,
>
> I agree with Les.=C2=A0 This is a simple protocol extension for a spec= ific purpose and there is no reason to include speculation about its use fo= r other purposes, particularly when it is inherently not suited for them. >
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
>
>> -----Original Message-----
>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Thursday, October 15, 2020 12:33 PM
>> To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org
>> Cc: lsr-c= hairs@ietf.org; l= sr-ads@ietf.org;
>> draft-ietf-lsr-ospf-prefix- originator@ietf.org
>> Subject: Re: [Lsr] WG Last Call
>> draft-ietf-lsr-ospf-prefix-originator-06
>>
>> [External Email. Be cautious of content]
>>
>>
>> I support moving this document forward.
>> Similar functionality in IS-IS has proved useful.
>>
>> I would however like to repeat comments I made earlier in the revi= ew
>> of this document.
>> The content of the Appendices should be removed.
>> The Appendices define and discuss deriving topology information fr= om
>> prefix advertisements - which is flawed and should not be done. >> Perhaps more relevant, the purpose of the document is to define=C2= =A0
>> protocol extensions supporting advertisement of the originators of= a
>> prefix advertisement. There is no need to discuss how this mechani= sm
>> might be used to build topology information.
>> This document should confine itself to defining the protocol
>> extensions - similar the RFC 7794.
>>
>> If the authors do not agree to do this, I would encourage this poi= nt
>> to be discussed during IESG review.
>>
>>=C2=A0 =C2=A0Les
>>
>>> -----Original Message-----
>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Christian Hopps
>>> Sent: Wednesday, October 14, 2020 11:15 PM
>>> To: lsr@ietf= .org
>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org;
>>> lsr-c= hairs@ietf.org; lsr- = ads@ietf.org; Christian Hopps
>>> <cho= pps@chopps.org>
>>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-origina= tor-06
>>>
>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020= , for:
>>>
>>>
>>> https://urldefense.= com/v3/__https://datatracker.ietf.org/doc/draft-i
>>> et
>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYP= S2VjLq
>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
>>>
>>> The following IPR has been filed
>>> https://urldefense.= com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
>>> !NEt6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
>>> 5KtUHQ$
>>>
>>> Authors,
>>>
>>>=C2=A0 Please indicate to the list, your knowledge of any other= IPR
>>> related to this work.
>>>
>>> Thanks,
>>> Chris.
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org=
>> https://urldefense.com= /v3/__https://www.ietf.org/mailman/listinfo/lsr
>> __;!!NEt
>> 6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8 >> Lc$
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--

=

Gyan Mishra

Network Solutions Architect=C2=A0<= /p>

M 301 502-1347
13101 Columbia Pike=C2=A0
= Silver Spring, MD


--0000000000002306db05b1c261d6-- From nobody Thu Oct 15 22:04:17 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD433A09F4; Thu, 15 Oct 2020 22:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.59 X-Spam-Level: X-Spam-Status: No, score=-9.59 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=R1aNqpLz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sM77Ienv 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 oHHroXa5v0f7; Thu, 15 Oct 2020 22:04:10 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259193A09E5; Thu, 15 Oct 2020 22:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36086; q=dns/txt; s=iport; t=1602824650; x=1604034250; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NDCjPNX46WWwBcIVSkFVAHBRLCOb5kt0BT3aBq5fEnQ=; b=R1aNqpLzCl9uNJLCK8rVTD+HUh8wEL5AjsCOiWwue6o2Pm9bT1Pe006z /UKeFDTdRgCF36FGCAsMWOA60uy9JuXlgfwxC7ht3YwPmD+TiocfIJXiN Mh8SmI0hdS1TQLnhRJavmqk8+3NNF78gMWdnElSJMXWa9/sWHG+dO2YDO k=; IronPort-PHdr: =?us-ascii?q?9a23=3A+QpPPBAUgRuqE2RfQ2YdUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00A3GWIza77RPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGF8P3ZlmUqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWEADNKIlf/5xdJa1WBwMdAQE8AQU?= =?us-ascii?q?FAQIBCQGBZoEhLyMuB3BZLywKhDODRgONUooRjmqBQoERA1ULAQEBDQEBGAE?= =?us-ascii?q?KCgIEAQGESgIXgXECJTgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQIBAQE?= =?us-ascii?q?QEQoTAQEsCwEEBwQCAQgHBwMEAQEBIAcDAgICHwYLFAkIAgQBDQUIEweDBYF?= =?us-ascii?q?+TQMOIAEOogMCgTmIYXaBMoMBAQEFgTMBE0GDGg0LghAJgSEXAYJxg26GVhu?= =?us-ascii?q?BQT+BEAFDgk0+ghpCAQECAQGBJgEHCgIBBhwVCgUHCQgJglAXHIItkA2DBT6?= =?us-ascii?q?HD5waL1QKgmqJBIcdhUKCIYMMgxaKCJF6gjKRRYFninOCbJJOAgQCBAUCDgE?= =?us-ascii?q?BBYFrI0QjcHAVO4I1AQEBMQlHFwINjXyEFIUUhUJ0AjYCBgEJAQEDCXyMOwG?= =?us-ascii?q?BEAEB?= X-IronPort-AV: E=Sophos;i="5.77,381,1596499200"; d="scan'208,217";a="581451798" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Oct 2020 05:04:08 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 09G547kW018299 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2020 05:04:07 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 16 Oct 2020 00:04:07 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 16 Oct 2020 00:04:06 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 16 Oct 2020 00:04:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RnBFQtecUzufC6lczC2ulGBOkphinM/KanbNmKb4wPA2DkUIZtTp9azFF/e5bxZFyFJPsMsMcQAdBEDrKutwEsb/kvo2kMlaZIZw3E2T6bniW/5TQKvU8HukxGfHKjO8cOqL88b3zNOxAY6Sz7bEczhfYlxtx9xzaECrYfT/HzfB2WGqKAn6J5yl3UPLAsIsyNRHk2Uz2hP6/fhEcN/wG2tezXYE1RzpxRdPmy4z8UvW8i39JGeeiJCIE5P9X5ZqIWD+/MMGTK4e6EkAT8CvbEfPePJARrm+CRNVGgtV92jpxcO29+yXpDvg+ot4Q6Z2IzMecfCjsLDQjJxStLDyFw== 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=NDCjPNX46WWwBcIVSkFVAHBRLCOb5kt0BT3aBq5fEnQ=; b=XSpyJlSuIdhz/qnnUW8rIVCWhcbSZUOs5AWKIPqAxN9tgEo7swJTWf0qvzBo7tDoE4WFseHvn79xeqiaeavsnrJMNWMJG0A014ie1YPeHOPdmhrbkhG1vxzWMB4MdWx7cLw52k9mzBUQdK6iW7/fckSIY0zINMIQkNlbq6X2hxlqz9wDd4+Dz1fYqxvJ9+NykWzPNuS7zHQVxGsDlK1Y7BTG7PW+wrMYWe2+RHTZc1z2mkoBNiZ14gRYjWdSXQgdqyy8gYE7PluQ+jaml2Boyr87sb134Zc1vCvnG2vKBfApPgMSM9Chd++AfYhZc7JggJ8XdeSvVQMgpdCRYOadLg== 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=NDCjPNX46WWwBcIVSkFVAHBRLCOb5kt0BT3aBq5fEnQ=; b=sM77IenvvrcCZ3Q7wD/Vp2JKaRompzsZiSo5QELHb3lDla4JTeNtuqtNU3jQt0MmhYQe2aG7UWXENc7+NL2Q7Vb80yLRSYTeBVpBveVFzKVd9PQ4y3IymsYWBIRvKVLEiea+A2V/qOFyNFfinfNykQP9mNlk0GrN1IseZQmOSd4= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4572.namprd11.prod.outlook.com (2603:10b6:303:5e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.22; Fri, 16 Oct 2020 05:04:05 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3477.021; Fri, 16 Oct 2020 05:04:05 +0000 From: "Ketan Talaulikar (ketant)" To: Gyan Mishra , Aijun Wang CC: Christian Hopps , Jeff Tantsura , John E Drake , "Les Ginsberg (ginsberg)" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr@ietf.org" , "lsr-ads@ietf.org" , "lsr-chairs@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorqoC1KYinwtxka4W6+KBPi+NqmY3FwAgAAhZgCAADD9AIAASXsAgAAvhACAAAI+kA== Date: Fri, 16 Oct 2020 05:04:05 +0000 Message-ID: References: <006001d6a35e$d9136ab0$8b3a4010$@tsinghua.org.cn> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27ea5dfc-d092-4143-dbf3-08d87190e807 x-ms-traffictypediagnostic: MW3PR11MB4572: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: F0u7xVM+VNbzKnzU+S5He6k5j1sLX3PI3eWAonOjZgp9hPiOal4Dd9K71esVWNbskCl6qQO85GtYtZBGNWAPBn/GRQUAisvGp+vvuPoDUwAg/PD4ADxBWCpiv6mORQYmHCKWxmAOQzZNi+tK8J2QoUpfIexvaURQq+62T5IKhPiGVBIhnJbgTMf8znQpvQTHxo5woHGN8KtR2GrWr4sl5rhVQpKfdZwkt2/S9+OX/Ppv7KwE9gpa8tty/Rqth6IA29X97NgrywPUmr06i11ZwJTfcjAt9DfN1+a+8sxGZ0AX1ifQQYD9kPu+Oq+m4tR7X8g3eAH4lEDKWYjzxg04cf9sq71oLnd2lVIH95pHbbsXGF75RwYnl0Ea4IOymt2Z5eqVSUHhlyde36oZ0jshhA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(346002)(39860400002)(136003)(376002)(71200400001)(9686003)(966005)(186003)(83380400001)(8676002)(66556008)(66446008)(66946007)(110136005)(64756008)(66476007)(166002)(66574015)(8936002)(55016002)(2906002)(5660300002)(76116006)(9326002)(33656002)(7416002)(7696005)(26005)(53546011)(316002)(6506007)(4326008)(86362001)(54906003)(52536014)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: laax7RqIrKveOT1SYvog4+ekKtk1E8V0nShqke/bTitcJww5hkaIZLq7jsggsHrOrK89fsS3DeLIIX4F0UyDNgNRu9199fiFenquauY7PEtoLKSwQIHiXJB+bNDBcTi1z2+ciLLpPp8od/MeU2VKOUM8RLfnXa7/Q9U41auVX6iJOKqwCUfhaL4cfhzauHUVmwRqSIDfXxGQOyuD4r7siZ19vpKXw1PkEnwZx4kDUEcPmR5rvxD5jbU2w1F5OvmyB8THcnQw4xVppeLMih7gBTxnCQLA+QMexOWan91wvWZBjsC24W8VG7NFTQef8QfTQEcAV0lqF9i9wvNZuwWlPLtla2dxt9Es6wuaC0WdExfVi0LczFmU2bUbWhLYJV7O3cRmkhSF5i4GKljMVeHZ2vhA5VBsmx9ke6m1SIByvd67YgCAbIS3aE42nlETHXUOn/j+s2qYvN3O6reerxVbjSvQQ4xQpvUTpjDsdXaWHDJ5lw9z+Bqgx8WbGDvJ+yJSr6P9H6odRmE8GSgYXoqzBbuBXTRZ1Bdm3bMT3TtPPY4pETjowPjvmgFLMBe4bjcvFvncmGezu72H8jxiosnJIZD6kyVnhQxmfPi3gDlsbcQ8c5Iv8p5Eix+qy9jxKZWN1y/q5scIS/I/dh1bIVrqrg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570A3769257122BFE47E54CC1030MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 27ea5dfc-d092-4143-dbf3-08d87190e807 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 05:04:05.3883 (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: cjwuvrFMV1OLn+HWy9m4iqJ1Tl0T30hi3YZN5NFGr0bfYaSlp2QTFvOevvo9ZPDJAwcg052hrv+llOjfTEjceA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4572 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 05:04:14 -0000 --_000_MW3PR11MB4570A3769257122BFE47E54CC1030MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3lhbiwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgZmVlZGJhY2suIFBsZWFzZSBj aGVjayBpbmxpbmUgYmVsb3cuDQoNCkZyb206IEd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFp bC5jb20+DQpTZW50OiAxNiBPY3RvYmVyIDIwMjAgMTA6MTENClRvOiBBaWp1biBXYW5nIDx3YW5n YWlqdW5AdHNpbmdodWEub3JnLmNuPg0KQ2M6IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bw cy5vcmc+OyBKZWZmIFRhbnRzdXJhIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT47IEpvaG4gRSBE cmFrZSA8amRyYWtlPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+OyBMZXMgR2luc2Jlcmcg KGdpbnNiZXJnKSA8Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+OyBkcmFmdC1p ZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnOyBsc3JAaWV0Zi5vcmc7IGxz ci1hZHNAaWV0Zi5vcmc7IGxzci1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTHNyXSBX RyBMYXN0IENhbGwgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KDQpJ IHN1cHBvcnQgYWR2YW5jZW1lbnQgb2YgdGhlIGRyYWZ0Lg0KDQpUaGlzIGRyYWZ0IGZvbGxvd3Mg YWxvbmcgdGhlIGxpbmVzIG9mIElTSVMgUkZDIDc3OTQgdG8gcHJvdmlkZSBhbiBleHRlbnNpb24g dG8gaWRlbnRpZnkgdGhlIHByZWZpeCBvcmlnaW5hdG9yIGF0dHJpYnV0ZSB1c2luZyBhbiBvcmln aW5hdGluZyByb3V0ZXIgVExWIGFuZCBhIHJlYWNoYWJsZSBwcmVmaXguICBBIG5vZGUgaW4gb3Nw ZiBpcyByZXByZXNlbnRlZCBieSBhIHJvdXRlci1pZCB3aGljaCB0ZWNobmljYWxseSBjYW4gYmUg YSByYW5kb20gNCBvY3RldCBwcmVmaXggdGhhdCBkb2VzIG5vdCBoYXZlIHRvIGJlIHJlYWNoYWJs ZSBlbnRyeSBpbiB0aGUgSUdQIFJJQi4NCg0KVGhlIHJlYWNoYWJpbGl0eSBwcmVmaXggaXMgaW1w b3J0YW50IGluIGNhc2VzIHdoZXJlIHRoZSBvcmlnaW5hdG9yIHJvdXRlci1pZCBpcyBub3QgIGlu IHRoZSBSSUIgb3IgaW4gdHJhZmZpYyBlbmdpbmVlcmluZyBpbnRlciBhcyBwYXRoIGluc3RhbnRp YXRpb24gdXNlIGNhc2Ugd2hlcmUgdGhlIHJvdXRlci1pZCBvcmlnaW5hdG9yIG5vZGUgaXMgYWR2 ZXJ0aXNlZCwgaG93ZXZlciBzaW5jZSB0aGUgVEVEcyBkYXRhYmFzZSBsaW5rIGF0dHJpYnV0ZXMg YXJlIG5vdCBrbm93biBpbnRlci1hcyxoYXZpbmcgdGhlIHJlYWNoYWJpbGl0eSBhZGRyZXNzIGlz IGltcG9ydGFudCBhcyBkZWZpbmVkIGluIHRoZSBkcmFmdC4gIFRoaXMgZmVhdHVyZSBjYW4gYWxz byBiZSB1c2VkICBpZGVudGlmeWluZyB0aGUgcHJlZml4IG9yaWdpbmF0b3IgaW4gYSBub3JtYWwg dXNlciBjYXNlIG90aGVyIHRoZW4gdGhlIHRyYWZmaWMgZW5naW5lZXJpbmcgc2NlbmFyaW8gc3Vj aCBhcyBmb3IgdHJvdWJsZXNob290aW5nIHdoaWNoIGlzIGNvbW1vbiB0byB2aWV3IGFsbCB0aGUg cHJlZml4ZXMgYWR2ZXJ0aXNlZCBieSBhIG5vZGUgYnkgUHJlZml4IHR5cGUuDQoNClRoZXJlIG1h eWJlIGNhc2VzIHdoZXJlIHlvdSBuZWVkIHRvIGNyZWF0ZSAgYSBkYXRhYmFzZSBmaWx0ZXIgb3Ig cG9saWN5IGFuZCBpZiB5b3UgY2FuIHVzZSB0aGlzIGZlYXR1cmUgYXMgYSBtZWFucyBvZiBjb250 cm9sbGluZyBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgYmFzZWQgb24gc291cmNlIG5vZGUgdGhhdCBj YW4gYmUgcG93ZXJmdWwgYW5kIGNvdWxkIGhhdmUgdWJpcXVpdG91cyB1c2UgY2FzZXMuDQoNCldp dGggcmVnYXJkcyB0byB0aGUgYXBwZW5kaXggaXQgZG9lcyBhcHBlYXIgdG8gYmUgcGVydGluZW50 LCBhcyB0aGUgdXNlIGNhc2UgYXBwZWFycyB0byBiZSB0aGUgcHJpbWFyeSBmb2NhbCBwb2ludCBh bmQgcmVhc29uIGZvciB0aGUgZHJhZnQgYnkgdGhlIGF1dGhvcnMuICBJIGRvbuKAmXQgdGhpbmsg dGhhdCBoYXZpbmcgdGhlIGFwcGVuZGl4ICBwcmVjbHVkaW5nIG90aGVyIHVzZSBjYXNlcyBieSBh bnkgbWVhbnMuDQpbS1RdIFRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBvZiB0aGUgZHJhZnQgZG9l cyB0b3VjaCB1cG9uIHNvbWUgb2YgdGhlIHByaW1hcnkgdXNlLWNhc2VzIHRoYXQgYXV0aG9ycyBi ZWxpZXZlIGhhdmUgbW9yZSB3aWRlLXNwcmVhZCBhcHBsaWNhYmlsaXR5LiBZb3UgaGF2ZSBhbHNv IGFsbHVkZWQgdG8gc29tZSBvZiB0aGVtIGFuZCB0aGVuIHlvdSBoYXZlIGFsc28gYnJvdWdodCBv dXQgc29tZSBuZXdlciB1c2UtY2FzZXMvYXBwbGljYXRpb25zIG9mIHRoZSBleHRlbnNpb25zIGlu IHRoaXMgZHJhZnQuIFRoZXJlIHdlcmUgb3RoZXIgdXNlLWNhc2VzIGluIHByZXZpb3VzIHZlcnNp b25zIGxpa2UgRUxDIHdoaWNoIGxhdGVyIHdlbnQgYXdheSBiYXNlZCBvbiBob3cgd2UgYWRkcmVz c2VkIHRoYXQgaW4gZHJhZnQtaWV0Zi1vc3BmL2lzaXMtbXBscy1lbGMgZG9jdW1lbnRzLiBJIGFt IHN1cmUgdGhlcmUgd2lsbCBiZSBuZXdlciB1c2UtY2FzZXMuIFRoZSBmb2N1cyBvZiB0aGUgZHJh ZnQgaXMgcHJpbWFyeSB0byBjYXB0dXJlIHRoZSBwcm90b2NvbCBleHRlbnNpb25zIHNpbmNlIHRo YXQgaXMgd2hhdCB3ZSB3b3JrIG9uIGluIExTUi4gVGhlIHNjb3BlIG9mIHRoZSB1c2UtY2FzZXMg bWF5IGJlIGJleW9uZCBMU1IgYW5kIGluIG90aGVyIGFyZWFzIChlLmcuIFRFQVMgcGVyaGFwcyBm b3IgdGhlIG9uZSBpbiB0aGUgYXBwZW5kaXggPykuIFJlZ2FyZGluZyB0aGUgdXNlLWNhc2UgaW4g dGhlIGFwcGVuZGl4LCBpdCB3b3VsZCBiZSBmYWlyIHRvIHNheSB0aGF0IGl0IHdhcyBwcmltYXJ5 IGZvY2FsIHBvaW50IGZvciBzb21lIG9mIHRoZSBhdXRob3JzLg0KDQpJIHdpbGwgbGVhdmUgaXQg dG8gdGhlIFdHIGNvbnNlbnN1cyBvbiB3aGF0IGNvbnRlbnQgd2Ugc2hvdWxkIGJlIHNlbmRpbmcg dG8gdGhlIElFU0cuDQoNClRoYW5rcywNCktldGFuDQoNCktpbmQgUmVnYXJkcw0KDQpHeWFuDQoN Ck9uIFRodSwgT2N0IDE1LCAyMDIwIGF0IDk6NTEgUE0gQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRz aW5naHVhLm9yZy5jbjxtYWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4+IHdyb3RlOg0K SGksIExlcywgSm9obiBhbmQgSmVmZjoNCg0KTGV0J3MgcmVwbHkgeW91IGFsbCB0b2dldGhlci4N CkluIG15IFBPViwgVGhlIHN0YW5kYXJkIGRvY3VtZW50IHNob3VsZCBub3QgZGVmaW5lIHNvbGVs eSB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9uLCBidXQgdGhlaXIgdXNhZ2VzIGluIHRoZSBuZXR3b3Jr IGRlcGxveW1lbnQuIEFzIEkga25vd24sIGFsbW9zdCBhbGwgdGhlIElFVEYgZG9jdW1lbnRzIGZv bGxvd2luZyB0aGlzIHN0eWxlLg0KQW5kLCBiZWZvcmUgYWRvcHRpbmcgb25lIHdvcmssIHdlIGhh dmUgb2Z0ZW4gaW50ZW5zZSBkaXNjdXNzaW9uIGZvciB3aGF0J3MgdGhlaXIgdXNhZ2VzLg0KU3Vj aCBkaXNjdXNzaW9uIGluIHRoZSBtYWlsIGxpc3QgYW5kIHN0YXRlbWVudHMgaW4gdGhlIGRvY3Vt ZW50IGNhbiBjZXJ0YWlubHkgYXNzaXN0IHRoZSByZWFkZXIvdXNlciBvZiB0aGUgZG9jdW1lbnQg Z2V0IHRoZSBlc3NlbmNlIG9mIHRoZSBzdGFuZGFyZCwgYW5kIGZvbGxvdyB0aGVtIHVuYW1iaWd1 b3VzbHkuDQoNClJlZ2FyZGluZyB0aGUgY29udGVudHMgb2YgYXBwZW5kaWNlcywgYXMgc3RhdGVk IGluIHRoZSBzZWN0aW9uLCAiVGhlIEFwcGVuZGl4IEEgaGV1cmlzdGljIHRvIHJlYnVpbGQgdGhl IHRvcG9sb2d5IGNhbiBub3JtYWxseSBiZSB1c2VkIGlmIGFsbCBsaW5rcyBhcmUgbnVtYmVyZWQu IiBJIHRoaW5rIHRoaXMgY2FuIGFwcGx5IGFsbW9zdCBtb3N0IG9mIHRoZSBvcGVyYXRvcidzIG5l dHdvcmssIGFuZCBmYWNpbGl0YXRlIHRoZSBpbnRlci1hcmVhIFRFIHBhdGggY2FsY3VsYXRpb24g Zm9yIGNlbnRyYWwgY29udHJvbGxlciwgb3IgZXZlbiBmb3IgdGhlIGhlYWQtZW5kIHJvdXRlciB0 aGF0IGxvY2F0ZWQgaW4gb25lIGFyZWEgdGhhdCBkaWZmZXJlbnQgZnJvbSB0aGUgdGFpbC1lbmQg cm91dGVyLg0KDQpLZWVwaW5nIHRoZSBjb250ZW50cyBvZiBhcHBlbmRpY2VzIGRvZXMgbm90IGhh dmUgdGhlIG5lZ2F0aXZlIGltcGFjdCBvZiB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9uLCBpdCBpcyBq dXN0IG9uZSByZWZlcmVuY2UgZm9yIHRoZSB1c2FnZSBvZiB0aGlzIGV4dGVuc2lvbi4NCk9uZSBj YW4gc2VsZWN0IG5vdCByZWZlciB0byBpdCwgaWYgdGhlaXIgbmV0d29ya3MgYXJlIGRlcGxveWVk IHdpdGggbGFyZ2UgYW1vdW50IG9mIHVubnVtYmVyZWQgbGlua3MuIEJ1dCBmb3Igb3RoZXJzLCB0 aGUgaGV1cmlzdGljIGFwcGxpZXMuDQoNCkJlc3QgUmVnYXJkcw0KDQpBaWp1biBXYW5nDQpDaGlu YSBUZWxlY29tDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbHNyLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmxzci1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBKZWZmIFRhbnRzdXJhDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMjAgNToyOCBBTQ0K VG86IEpvaG4gRSBEcmFrZSA8amRyYWtlPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOjQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+Pg0KQ2M6IENocmlzdGlhbiBIb3BwcyA8 Y2hvcHBzQGNob3Bwcy5vcmc8bWFpbHRvOmNob3Bwc0BjaG9wcHMub3JnPj47IGxzci1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOmxzci1jaGFpcnNAaWV0Zi5vcmc+OyBMZXMgR2luc2JlcmcgKGdpbnNi ZXJnKSA8Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPj47IGxzckBpZXRmLm9yZzxtYWlsdG86bHNyQGlldGYub3JnPjsg bHNyLWFkc0BpZXRmLm9yZzxtYWlsdG86bHNyLWFkc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtbHNy LW9zcGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbHNyLW9z cGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0xzcl0gV0cgTGFz dCBDYWxsIGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCg0KKzENCg0K UmVnYXJkcywNCkplZmYNCg0KPiBPbiBPY3QgMTUsIDIwMjAsIGF0IDExOjMzLCBKb2huIEUgRHJh a2UgPGpkcmFrZT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGp1bmlwZXIu bmV0QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+DQo+IO+7v0hpLA0KPg0KPiBJIGFncmVlIHdp dGggTGVzLiAgVGhpcyBpcyBhIHNpbXBsZSBwcm90b2NvbCBleHRlbnNpb24gZm9yIGEgc3BlY2lm aWMgcHVycG9zZSBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIHRvIGluY2x1ZGUgc3BlY3VsYXRpb24g YWJvdXQgaXRzIHVzZSBmb3Igb3RoZXIgcHVycG9zZXMsIHBhcnRpY3VsYXJseSB3aGVuIGl0IGlz IGluaGVyZW50bHkgbm90IHN1aXRlZCBmb3IgdGhlbS4NCj4NCj4gWW91cnMgSXJyZXNwZWN0aXZl bHksDQo+DQo+IEpvaG4NCj4NCj4NCj4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KPg0KPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IExzciA8bHNyLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIExlcyBHaW5z YmVyZyAoZ2luc2JlcmcpDQo+PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNSwgMjAyMCAxMjoz MyBQTQ0KPj4gVG86IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc8bWFpbHRvOmNo b3Bwc0BjaG9wcHMub3JnPj47IGxzckBpZXRmLm9yZzxtYWlsdG86bHNyQGlldGYub3JnPg0KPj4g Q2M6IGxzci1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmxzci1jaGFpcnNAaWV0Zi5vcmc+OyBsc3It YWRzQGlldGYub3JnPG1haWx0bzpsc3ItYWRzQGlldGYub3JnPjsNCj4+IGRyYWZ0LWlldGYtbHNy LW9zcGYtcHJlZml4LSBvcmlnaW5hdG9yQGlldGYub3JnPG1haWx0bzpvcmlnaW5hdG9yQGlldGYu b3JnPg0KPj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbA0KPj4gZHJhZnQtaWV0Zi1s c3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KPj4NCj4+IFtFeHRlcm5hbCBFbWFpbC4gQmUg Y2F1dGlvdXMgb2YgY29udGVudF0NCj4+DQo+Pg0KPj4gSSBzdXBwb3J0IG1vdmluZyB0aGlzIGRv Y3VtZW50IGZvcndhcmQuDQo+PiBTaW1pbGFyIGZ1bmN0aW9uYWxpdHkgaW4gSVMtSVMgaGFzIHBy b3ZlZCB1c2VmdWwuDQo+Pg0KPj4gSSB3b3VsZCBob3dldmVyIGxpa2UgdG8gcmVwZWF0IGNvbW1l bnRzIEkgbWFkZSBlYXJsaWVyIGluIHRoZSByZXZpZXcNCj4+IG9mIHRoaXMgZG9jdW1lbnQuDQo+ PiBUaGUgY29udGVudCBvZiB0aGUgQXBwZW5kaWNlcyBzaG91bGQgYmUgcmVtb3ZlZC4NCj4+IFRo ZSBBcHBlbmRpY2VzIGRlZmluZSBhbmQgZGlzY3VzcyBkZXJpdmluZyB0b3BvbG9neSBpbmZvcm1h dGlvbiBmcm9tDQo+PiBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgLSB3aGljaCBpcyBmbGF3ZWQgYW5k IHNob3VsZCBub3QgYmUgZG9uZS4NCj4+IFBlcmhhcHMgbW9yZSByZWxldmFudCwgdGhlIHB1cnBv c2Ugb2YgdGhlIGRvY3VtZW50IGlzIHRvIGRlZmluZQ0KPj4gcHJvdG9jb2wgZXh0ZW5zaW9ucyBz dXBwb3J0aW5nIGFkdmVydGlzZW1lbnQgb2YgdGhlIG9yaWdpbmF0b3JzIG9mIGENCj4+IHByZWZp eCBhZHZlcnRpc2VtZW50LiBUaGVyZSBpcyBubyBuZWVkIHRvIGRpc2N1c3MgaG93IHRoaXMgbWVj aGFuaXNtDQo+PiBtaWdodCBiZSB1c2VkIHRvIGJ1aWxkIHRvcG9sb2d5IGluZm9ybWF0aW9uLg0K Pj4gVGhpcyBkb2N1bWVudCBzaG91bGQgY29uZmluZSBpdHNlbGYgdG8gZGVmaW5pbmcgdGhlIHBy b3RvY29sDQo+PiBleHRlbnNpb25zIC0gc2ltaWxhciB0aGUgUkZDIDc3OTQuDQo+Pg0KPj4gSWYg dGhlIGF1dGhvcnMgZG8gbm90IGFncmVlIHRvIGRvIHRoaXMsIEkgd291bGQgZW5jb3VyYWdlIHRo aXMgcG9pbnQNCj4+IHRvIGJlIGRpc2N1c3NlZCBkdXJpbmcgSUVTRyByZXZpZXcuDQo+Pg0KPj4g ICBMZXMNCj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBMc3Ig PGxzci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJl aGFsZiBPZiBDaHJpc3RpYW4gSG9wcHMNCj4+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTQs IDIwMjAgMTE6MTUgUE0NCj4+PiBUbzogbHNyQGlldGYub3JnPG1haWx0bzpsc3JAaWV0Zi5vcmc+ DQo+Pj4gQ2M6IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmc+Ow0K Pj4+IGxzci1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmxzci1jaGFpcnNAaWV0Zi5vcmc+OyBsc3It IGFkc0BpZXRmLm9yZzxtYWlsdG86YWRzQGlldGYub3JnPjsgQ2hyaXN0aWFuIEhvcHBzDQo+Pj4g PGNob3Bwc0BjaG9wcHMub3JnPG1haWx0bzpjaG9wcHNAY2hvcHBzLm9yZz4+DQo+Pj4gU3ViamVj dDogW0xzcl0gV0cgTGFzdCBDYWxsIGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0 b3ItMDYNCj4+Pg0KPj4+IFRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExhc3QgQ2FsbCwgZW5kaW5n IGFmdGVyIE9jdCAyOXRoLCAyMDIwLCBmb3I6DQo+Pj4NCj4+Pg0KPj4+IGh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pPGh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWk+DQo+Pj4gZXQNCj4+PiBmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yL19fOyEh TkV0NnlNYU8tZ2shVGFTelFUaGdodENGT3VZUFMyVmpMcQ0KPj4+IGhLIDhwMDNGZzNMOUx1Q0dY dzhDMFg2cVJRZHJIaktES0hjamtqQ2xwayQNCj4+Pg0KPj4+IFRoZSBmb2xsb3dpbmcgSVBSIGhh cyBiZWVuIGZpbGVkDQo+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzM0NDgvX188aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9f X2h0dHBzOi9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMzQ0OC9fXz47IQ0KPj4+ICFORXQ2eU1h Ty0NCj4+IGdrIVRhU3pRVGhnaHRDRk91WVBTMlZqTHFoSzhwMDNGZzNMOUx1Q0dYdzhDMFg2cVJR ZHJIaktES0hjeg0KPj4+IDVLdFVIUSQNCj4+Pg0KPj4+IEF1dGhvcnMsDQo+Pj4NCj4+PiAgUGxl YXNlIGluZGljYXRlIHRvIHRoZSBsaXN0LCB5b3VyIGtub3dsZWRnZSBvZiBhbnkgb3RoZXIgSVBS DQo+Pj4gcmVsYXRlZCB0byB0aGlzIHdvcmsuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gQ2hyaXMu DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IExzciBtYWlsaW5nIGxpc3QNCj4+IExzckBpZXRmLm9yZzxtYWlsdG86THNyQGlldGYub3Jn Pg0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbHNyPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyPg0KPj4gX187ISFORXQNCj4+IDZ5TWFPLQ0K Pj4gZ2shVGFTelFUaGdodENGT3VZUFMyVmpMcWhLOHAwM0ZnM0w5THVDR1h3OEMwWDZxUlFkckhq S0RLSGNVZG13OA0KPj4gTGMkDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IExzciBtYWlsaW5nIGxpc3QNCj4gTHNyQGlldGYub3JnPG1haWx0 bzpMc3JAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHNyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpM c3IgbWFpbGluZyBsaXN0DQpMc3JAaWV0Zi5vcmc8bWFpbHRvOkxzckBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMc3IgbWFpbGluZyBsaXN0DQpMc3JAaWV0 Zi5vcmc8bWFpbHRvOkxzckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHNyDQotLQ0KDQpbaHR0cDovL3NzNy52encuY29tL2lzL2ltYWdlL1Zlcml6b25X aXJlbGVzcy92ei1sb2dvLWVtYWlsXTxodHRwOi8vd3d3LnZlcml6b24uY29tLz4NCg0KR3lhbiBN aXNocmENCg0KTmV0d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0DQoNCk0gMzAxIDUwMi0xMzQ3DQox MzEwMSBDb2x1bWJpYSBQaWtlDQpTaWx2ZXIgU3ByaW5nLCBNRA0KDQo= --_000_MW3PR11MB4570A3769257122BFE47E54CC1030MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2VvcmdpYTsN CglwYW5vc2UtMToyIDQgNSAyIDUgNCA1IDIgMyAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUlOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEd5YW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgeW91 ciByZXZpZXcgYW5kIGZlZWRiYWNrLiBQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEd5YW4gTWlzaHJhICZs dDtoYXlhYnVzYWdzbUBnbWFpbC5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTYgT2N0b2Jl ciAyMDIwIDEwOjExPGJyPg0KPGI+VG86PC9iPiBBaWp1biBXYW5nICZsdDt3YW5nYWlqdW5AdHNp bmdodWEub3JnLmNuJmd0Ozxicj4NCjxiPkNjOjwvYj4gQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9w cHNAY2hvcHBzLm9yZyZndDs7IEplZmYgVGFudHN1cmEgJmx0O2plZmZ0YW50LmlldGZAZ21haWwu Y29tJmd0OzsgSm9obiBFIERyYWtlICZsdDtqZHJha2U9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRm Lm9yZyZndDs7IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpICZsdDtnaW5zYmVyZz00MGNpc2NvLmNv bUBkbWFyYy5pZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0 b3JAaWV0Zi5vcmc7IGxzckBpZXRmLm9yZzsNCiBsc3ItYWRzQGlldGYub3JnOyBsc3ItY2hhaXJz QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwgZHJh ZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VwcG9ydCBhZHZhbmNlbWVudCBv ZiB0aGUgZHJhZnQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRyYWZ0IGZvbGxvd3MgYWxvbmcgdGhlIGxpbmVzIG9mIElT SVMgUkZDIDc3OTQgdG8gcHJvdmlkZSBhbiBleHRlbnNpb24gdG8gaWRlbnRpZnkgdGhlIHByZWZp eCBvcmlnaW5hdG9yIGF0dHJpYnV0ZSB1c2luZyBhbiBvcmlnaW5hdGluZyByb3V0ZXIgVExWIGFu ZCBhIHJlYWNoYWJsZSBwcmVmaXguJm5ic3A7IEEgbm9kZSBpbiBvc3BmIGlzIHJlcHJlc2VudGVk IGJ5IGEgcm91dGVyLWlkIHdoaWNoIHRlY2huaWNhbGx5DQogY2FuIGJlIGEgcmFuZG9tIDQgb2N0 ZXQgcHJlZml4IHRoYXQgZG9lcyBub3QgaGF2ZSB0byBiZSByZWFjaGFibGUgZW50cnkgaW4gdGhl IElHUCBSSUIuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgcmVhY2hhYmlsaXR5IHByZWZpeCBpcyBpbXBvcnRhbnQgaW4gY2Fz ZXMgd2hlcmUgdGhlIG9yaWdpbmF0b3Igcm91dGVyLWlkIGlzIG5vdCAmbmJzcDtpbiB0aGUgUklC IG9yIGluIHRyYWZmaWMgZW5naW5lZXJpbmcgaW50ZXIgYXMgcGF0aCBpbnN0YW50aWF0aW9uIHVz ZSBjYXNlIHdoZXJlIHRoZSByb3V0ZXItaWQgb3JpZ2luYXRvciBub2RlIGlzIGFkdmVydGlzZWQs IGhvd2V2ZXIgc2luY2UgdGhlIFRFRHMgZGF0YWJhc2UNCiBsaW5rIGF0dHJpYnV0ZXMgYXJlIG5v dCBrbm93biBpbnRlci1hcyxoYXZpbmcgdGhlIHJlYWNoYWJpbGl0eSBhZGRyZXNzIGlzIGltcG9y dGFudCBhcyBkZWZpbmVkIGluIHRoZSBkcmFmdC4mbmJzcDsgVGhpcyBmZWF0dXJlIGNhbiBhbHNv IGJlIHVzZWQgJm5ic3A7aWRlbnRpZnlpbmcgdGhlIHByZWZpeCBvcmlnaW5hdG9yIGluIGEgbm9y bWFsIHVzZXIgY2FzZSBvdGhlciB0aGVuIHRoZSB0cmFmZmljIGVuZ2luZWVyaW5nIHNjZW5hcmlv IHN1Y2ggYXMgZm9yIHRyb3VibGVzaG9vdGluZw0KIHdoaWNoIGlzIGNvbW1vbiB0byB2aWV3IGFs bCB0aGUgcHJlZml4ZXMgYWR2ZXJ0aXNlZCBieSBhIG5vZGUgYnkgUHJlZml4IHR5cGUuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZXJlIG1heWJlIGNhc2VzIHdoZXJlIHlvdSBuZWVkIHRvIGNyZWF0ZSAmbmJzcDthIGRhdGFiYXNl IGZpbHRlciBvciBwb2xpY3kgYW5kIGlmIHlvdSBjYW4gdXNlIHRoaXMgZmVhdHVyZSBhcyBhIG1l YW5zIG9mIGNvbnRyb2xsaW5nIHByZWZpeCBhZHZlcnRpc2VtZW50cyBiYXNlZCBvbiBzb3VyY2Ug bm9kZSB0aGF0IGNhbiBiZSBwb3dlcmZ1bCBhbmQgY291bGQgaGF2ZSB1YmlxdWl0b3VzIHVzZSBj YXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2l0aCByZWdhcmRzIHRvIHRoZSBhcHBlbmRpeCBpdCBkb2VzIGFwcGVhciB0byBiZSBwZXJ0 aW5lbnQsIGFzIHRoZSB1c2UgY2FzZSBhcHBlYXJzIHRvIGJlIHRoZSBwcmltYXJ5IGZvY2FsIHBv aW50IGFuZCByZWFzb24gZm9yIHRoZSBkcmFmdCBieSB0aGUgYXV0aG9ycy4mbmJzcDsgSSBkb27i gJl0IHRoaW5rIHRoYXQgaGF2aW5nIHRoZSBhcHBlbmRpeCAmbmJzcDtwcmVjbHVkaW5nIG90aGVy IHVzZSBjYXNlcyBieSBhbnkgbWVhbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT5bS1RdIFRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBvZiB0aGUgZHJh ZnQgZG9lcyB0b3VjaCB1cG9uIHNvbWUgb2YgdGhlIHByaW1hcnkgdXNlLWNhc2VzIHRoYXQgYXV0 aG9ycyBiZWxpZXZlIGhhdmUgbW9yZSB3aWRlLXNwcmVhZCBhcHBsaWNhYmlsaXR5LiBZb3UgaGF2 ZSBhbHNvIGFsbHVkZWQgdG8gc29tZSBvZiB0aGVtIGFuZCB0aGVuIHlvdSBoYXZlIGFsc28gYnJv dWdodCBvdXQgc29tZSBuZXdlcg0KIHVzZS1jYXNlcy9hcHBsaWNhdGlvbnMgb2YgdGhlIGV4dGVu c2lvbnMgaW4gdGhpcyBkcmFmdC4gVGhlcmUgd2VyZSBvdGhlciB1c2UtY2FzZXMgaW4gcHJldmlv dXMgdmVyc2lvbnMgbGlrZSBFTEMgd2hpY2ggbGF0ZXIgd2VudCBhd2F5IGJhc2VkIG9uIGhvdyB3 ZSBhZGRyZXNzZWQgdGhhdCBpbiBkcmFmdC1pZXRmLW9zcGYvaXNpcy1tcGxzLWVsYyBkb2N1bWVu dHMuIEkgYW0gc3VyZSB0aGVyZSB3aWxsIGJlIG5ld2VyIHVzZS1jYXNlcy4gVGhlIGZvY3VzDQog b2YgdGhlIGRyYWZ0IGlzIHByaW1hcnkgdG8gY2FwdHVyZSB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9u cyBzaW5jZSB0aGF0IGlzIHdoYXQgd2Ugd29yayBvbiBpbiBMU1IuIFRoZSBzY29wZSBvZiB0aGUg dXNlLWNhc2VzIG1heSBiZSBiZXlvbmQgTFNSIGFuZCBpbiBvdGhlciBhcmVhcyAoZS5nLiBURUFT IHBlcmhhcHMgZm9yIHRoZSBvbmUgaW4gdGhlIGFwcGVuZGl4ID8pLiBSZWdhcmRpbmcgdGhlIHVz ZS1jYXNlIGluIHRoZSBhcHBlbmRpeCwgaXQgd291bGQNCiBiZSBmYWlyIHRvIHNheSB0aGF0IGl0 IHdhcyBwcmltYXJ5IGZvY2FsIHBvaW50IGZvciBzb21lIG9mIHRoZSBhdXRob3JzLjxvOnA+PC9v OnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48bzpwPiZuYnNwOzwv bzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+SSB3aWxsIGxlYXZl IGl0IHRvIHRoZSBXRyBjb25zZW5zdXMgb24gd2hhdCBjb250ZW50IHdlIHNob3VsZCBiZSBzZW5k aW5nIHRvIHRoZSBJRVNHLjxvOnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48bzpwPiZuYnNwOzwvbzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+VGhhbmtzLDwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT5LZXRhbjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktpbmQgUmVnYXJkcyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HeWFuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVGh1LCBPY3QgMTUsIDIwMjAgYXQgOTo1MSBQTSBBaWp1biBXYW5nICZsdDs8YSBocmVmPSJt YWlsdG86d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbiIgdGFyZ2V0PSJfYmxhbmsiPndhbmdhaWp1 bkB0c2luZ2h1YS5vcmcuY248L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBMZXMsIEpvaG4gYW5kIEplZmY6 PGJyPg0KPGJyPg0KTGV0J3MgcmVwbHkgeW91IGFsbCB0b2dldGhlci48YnI+DQpJbiBteSBQT1Ys IFRoZSBzdGFuZGFyZCBkb2N1bWVudCBzaG91bGQgbm90IGRlZmluZSBzb2xlbHkgdGhlIHByb3Rv Y29sIGV4dGVuc2lvbiwgYnV0IHRoZWlyIHVzYWdlcyBpbiB0aGUgbmV0d29yayBkZXBsb3ltZW50 LiBBcyBJIGtub3duLCBhbG1vc3QgYWxsIHRoZSBJRVRGIGRvY3VtZW50cyBmb2xsb3dpbmcgdGhp cyBzdHlsZS4NCjxicj4NCkFuZCwgYmVmb3JlIGFkb3B0aW5nIG9uZSB3b3JrLCB3ZSBoYXZlIG9m dGVuIGludGVuc2UgZGlzY3Vzc2lvbiBmb3Igd2hhdCdzIHRoZWlyIHVzYWdlcy4NCjxicj4NClN1 Y2ggZGlzY3Vzc2lvbiBpbiB0aGUgbWFpbCBsaXN0IGFuZCBzdGF0ZW1lbnRzIGluIHRoZSBkb2N1 bWVudCBjYW4gY2VydGFpbmx5IGFzc2lzdCB0aGUgcmVhZGVyL3VzZXIgb2YgdGhlIGRvY3VtZW50 IGdldCB0aGUgZXNzZW5jZSBvZiB0aGUgc3RhbmRhcmQsIGFuZCBmb2xsb3cgdGhlbSB1bmFtYmln dW91c2x5Ljxicj4NCjxicj4NClJlZ2FyZGluZyB0aGUgY29udGVudHMgb2YgYXBwZW5kaWNlcywg YXMgc3RhdGVkIGluIHRoZSBzZWN0aW9uLCAmcXVvdDtUaGUgQXBwZW5kaXggQSBoZXVyaXN0aWMg dG8gcmVidWlsZCB0aGUgdG9wb2xvZ3kgY2FuIG5vcm1hbGx5IGJlIHVzZWQgaWYgYWxsIGxpbmtz IGFyZSBudW1iZXJlZC4mcXVvdDsgSSB0aGluayB0aGlzIGNhbiBhcHBseSBhbG1vc3QgbW9zdCBv ZiB0aGUgb3BlcmF0b3IncyBuZXR3b3JrLCBhbmQgZmFjaWxpdGF0ZSB0aGUgaW50ZXItYXJlYSBU RQ0KIHBhdGggY2FsY3VsYXRpb24gZm9yIGNlbnRyYWwgY29udHJvbGxlciwgb3IgZXZlbiBmb3Ig dGhlIGhlYWQtZW5kIHJvdXRlciB0aGF0IGxvY2F0ZWQgaW4gb25lIGFyZWEgdGhhdCBkaWZmZXJl bnQgZnJvbSB0aGUgdGFpbC1lbmQgcm91dGVyLjxicj4NCjxicj4NCktlZXBpbmcgdGhlIGNvbnRl bnRzIG9mIGFwcGVuZGljZXMgZG9lcyBub3QgaGF2ZSB0aGUgbmVnYXRpdmUgaW1wYWN0IG9mIHRo ZSBwcm90b2NvbCBleHRlbnNpb24sIGl0IGlzIGp1c3Qgb25lIHJlZmVyZW5jZSBmb3IgdGhlIHVz YWdlIG9mIHRoaXMgZXh0ZW5zaW9uLg0KPGJyPg0KT25lIGNhbiBzZWxlY3Qgbm90IHJlZmVyIHRv IGl0LCBpZiB0aGVpciBuZXR3b3JrcyBhcmUgZGVwbG95ZWQgd2l0aCBsYXJnZSBhbW91bnQgb2Yg dW5udW1iZXJlZCBsaW5rcy4gQnV0IGZvciBvdGhlcnMsIHRoZSBoZXVyaXN0aWMgYXBwbGllcy48 YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHM8YnI+DQo8YnI+DQpBaWp1biBXYW5nPGJyPg0KQ2hpbmEg VGVsZWNvbTxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bHNyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRv Omxzci1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bHNyLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YgSmVmZiBUYW50c3VyYTxicj4NClNlbnQ6IEZyaWRheSwgT2N0 b2JlciAxNiwgMjAyMCA1OjI4IEFNPGJyPg0KVG86IEpvaG4gRSBEcmFrZSAmbHQ7amRyYWtlPTxh IGhyZWY9Im1haWx0bzo0MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KQ2M6IENocmlzdGlh biBIb3BwcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNob3Bwc0BjaG9wcHMub3JnIiB0YXJnZXQ9Il9i bGFuayI+Y2hvcHBzQGNob3Bwcy5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpsc3ItY2hh aXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bHNyLWNoYWlyc0BpZXRmLm9yZzwvYT47IExl cyBHaW5zYmVyZyAoZ2luc2JlcmcpICZsdDtnaW5zYmVyZz08YSBocmVmPSJtYWlsdG86NDBjaXNj by5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGNpc2NvLmNvbUBkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmxzckBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmxzckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpsc3ItYWRzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+DQpsc3ItYWRzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRv OmRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCmRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmc8 L2E+PGJyPg0KU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbCBkcmFmdC1pZXRmLWxzci1v c3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2PGJyPg0KPGJyPg0KKzE8YnI+DQo8YnI+DQpSZWdhcmRz LDxicj4NCkplZmY8YnI+DQo8YnI+DQomZ3Q7IE9uIE9jdCAxNSwgMjAyMCwgYXQgMTE6MzMsIEpv aG4gRSBEcmFrZSAmbHQ7amRyYWtlPTxhIGhyZWY9Im1haWx0bzo0MGp1bmlwZXIubmV0QGRtYXJj LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyDvu79IaSw8YnI+DQomZ3Q7IDxicj4N CiZndDsgSSBhZ3JlZSB3aXRoIExlcy4mbmJzcDsgVGhpcyBpcyBhIHNpbXBsZSBwcm90b2NvbCBl eHRlbnNpb24gZm9yIGEgc3BlY2lmaWMgcHVycG9zZSBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIHRv IGluY2x1ZGUgc3BlY3VsYXRpb24gYWJvdXQgaXRzIHVzZSBmb3Igb3RoZXIgcHVycG9zZXMsIHBh cnRpY3VsYXJseSB3aGVuIGl0IGlzIGluaGVyZW50bHkgbm90IHN1aXRlZCBmb3IgdGhlbS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgWW91cnMgSXJyZXNwZWN0aXZlbHksPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEpvaG48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBKdW5pcGVyIEJ1c2luZXNz IFVzZSBPbmx5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IExzciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxzci1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bHNyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 OyBPbiBCZWhhbGYgT2YgTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk8YnI+DQomZ3Q7Jmd0OyBTZW50 OiBUaHVyc2RheSwgT2N0b2JlciAxNSwgMjAyMCAxMjozMyBQTTxicj4NCiZndDsmZ3Q7IFRvOiBD aHJpc3RpYW4gSG9wcHMgJmx0OzxhIGhyZWY9Im1haWx0bzpjaG9wcHNAY2hvcHBzLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmNob3Bwc0BjaG9wcHMub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 bHNyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bHNyQGlldGYub3JnPC9hPjxicj4NCiZndDsm Z3Q7IENjOiA8YSBocmVmPSJtYWlsdG86bHNyLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmxzci1jaGFpcnNAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmxzci1hZHNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sc3ItYWRzQGlldGYub3JnPC9hPjsgPGJyPg0KJmd0OyZn dDsgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtIDxhIGhyZWY9Im1haWx0bzpvcmlnaW5hdG9y QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpvcmlnaW5hdG9yQGlldGYub3JnPC9hPjxicj4N CiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwgPGJyPg0KJmd0OyZndDsg ZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNjxicj4NCiZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7IFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF08YnI+ DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIHN1cHBvcnQgbW92aW5n IHRoaXMgZG9jdW1lbnQgZm9yd2FyZC48YnI+DQomZ3Q7Jmd0OyBTaW1pbGFyIGZ1bmN0aW9uYWxp dHkgaW4gSVMtSVMgaGFzIHByb3ZlZCB1c2VmdWwuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZn dDsgSSB3b3VsZCBob3dldmVyIGxpa2UgdG8gcmVwZWF0IGNvbW1lbnRzIEkgbWFkZSBlYXJsaWVy IGluIHRoZSByZXZpZXcgPGJyPg0KJmd0OyZndDsgb2YgdGhpcyBkb2N1bWVudC48YnI+DQomZ3Q7 Jmd0OyBUaGUgY29udGVudCBvZiB0aGUgQXBwZW5kaWNlcyBzaG91bGQgYmUgcmVtb3ZlZC48YnI+ DQomZ3Q7Jmd0OyBUaGUgQXBwZW5kaWNlcyBkZWZpbmUgYW5kIGRpc2N1c3MgZGVyaXZpbmcgdG9w b2xvZ3kgaW5mb3JtYXRpb24gZnJvbSA8YnI+DQomZ3Q7Jmd0OyBwcmVmaXggYWR2ZXJ0aXNlbWVu dHMgLSB3aGljaCBpcyBmbGF3ZWQgYW5kIHNob3VsZCBub3QgYmUgZG9uZS48YnI+DQomZ3Q7Jmd0 OyBQZXJoYXBzIG1vcmUgcmVsZXZhbnQsIHRoZSBwdXJwb3NlIG9mIHRoZSBkb2N1bWVudCBpcyB0 byBkZWZpbmUmbmJzcDsgPGJyPg0KJmd0OyZndDsgcHJvdG9jb2wgZXh0ZW5zaW9ucyBzdXBwb3J0 aW5nIGFkdmVydGlzZW1lbnQgb2YgdGhlIG9yaWdpbmF0b3JzIG9mIGEgPGJyPg0KJmd0OyZndDsg cHJlZml4IGFkdmVydGlzZW1lbnQuIFRoZXJlIGlzIG5vIG5lZWQgdG8gZGlzY3VzcyBob3cgdGhp cyBtZWNoYW5pc20gPGJyPg0KJmd0OyZndDsgbWlnaHQgYmUgdXNlZCB0byBidWlsZCB0b3BvbG9n eSBpbmZvcm1hdGlvbi48YnI+DQomZ3Q7Jmd0OyBUaGlzIGRvY3VtZW50IHNob3VsZCBjb25maW5l IGl0c2VsZiB0byBkZWZpbmluZyB0aGUgcHJvdG9jb2wgPGJyPg0KJmd0OyZndDsgZXh0ZW5zaW9u cyAtIHNpbWlsYXIgdGhlIFJGQyA3Nzk0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IElm IHRoZSBhdXRob3JzIGRvIG5vdCBhZ3JlZSB0byBkbyB0aGlzLCBJIHdvdWxkIGVuY291cmFnZSB0 aGlzIHBvaW50IDxicj4NCiZndDsmZ3Q7IHRvIGJlIGRpc2N1c3NlZCBkdXJpbmcgSUVTRyByZXZp ZXcuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7TGVzPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K Jmd0OyZndDsmZ3Q7IEZyb206IExzciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxzci1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bHNyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBC ZWhhbGYgT2YgQ2hyaXN0aWFuIEhvcHBzPGJyPg0KJmd0OyZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAxNCwgMjAyMCAxMToxNSBQTTxicj4NCiZndDsmZ3Q7Jmd0OyBUbzogPGEgaHJl Zj0ibWFpbHRvOmxzckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxzckBpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7Jmd0OyZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWxzci1vc3Bm LXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRm LWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnPC9hPjs8YnI+DQomZ3Q7Jmd0OyZn dDsgPGEgaHJlZj0ibWFpbHRvOmxzci1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5s c3ItY2hhaXJzQGlldGYub3JnPC9hPjsgbHNyLQ0KPGEgaHJlZj0ibWFpbHRvOmFkc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmFkc0BpZXRmLm9yZzwvYT47IENocmlzdGlhbiBIb3BwcyA8YnI+ DQomZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjaG9wcHNAY2hvcHBzLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmNob3Bwc0BjaG9wcHMub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg U3ViamVjdDogW0xzcl0gV0cgTGFzdCBDYWxsIGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9y aWdpbmF0b3ItMDY8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IFRoaXMgYmVn aW5zIGEgMiB3ZWVrIFdHIExhc3QgQ2FsbCwgZW5kaW5nIGFmdGVyIE9jdCAyOXRoLCAyMDIwLCBm b3I6PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn dDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZl bnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWk8L2E+ PGJyPg0KJmd0OyZndDsmZ3Q7IGV0IDxicj4NCiZndDsmZ3Q7Jmd0OyBmLWxzci1vc3BmLXByZWZp eC1vcmlnaW5hdG9yL19fOyEhTkV0NnlNYU8tZ2shVGFTelFUaGdodENGT3VZUFMyVmpMcTxicj4N CiZndDsmZ3Q7Jmd0OyBoSyA4cDAzRmczTDlMdUNHWHc4QzBYNnFSUWRySGpLREtIY2prakNscGsk PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgZm9sbG93aW5nIElQUiBo YXMgYmVlbiBmaWxlZDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8zNDQ4L19fIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pcHIvMzQ0OC9fXzwvYT47ITxicj4NCiZndDsmZ3Q7Jmd0OyAhTkV0NnlN YU8tPGJyPg0KJmd0OyZndDsgZ2shVGFTelFUaGdodENGT3VZUFMyVmpMcWhLOHAwM0ZnM0w5THVD R1h3OEMwWDZxUlFkckhqS0RLSGN6PGJyPg0KJmd0OyZndDsmZ3Q7IDVLdFVIUSQ8YnI+DQomZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEF1dGhvcnMsPGJyPg0KJmd0OyZndDsmZ3Q7IDxi cj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyBQbGVhc2UgaW5kaWNhdGUgdG8gdGhlIGxpc3QsIHlvdXIg a25vd2xlZGdlIG9mIGFueSBvdGhlciBJUFIgPGJyPg0KJmd0OyZndDsmZ3Q7IHJlbGF0ZWQgdG8g dGhpcyB3b3JrLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgVGhhbmtzLDxi cj4NCiZndDsmZ3Q7Jmd0OyBDaHJpcy48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7 IExzciBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86THNyQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+THNyQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHNyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3I8L2E+PGJyPg0K Jmd0OyZndDsgX187ISFORXQ8YnI+DQomZ3Q7Jmd0OyA2eU1hTy08YnI+DQomZ3Q7Jmd0OyBnayFU YVN6UVRoZ2h0Q0ZPdVlQUzJWakxxaEs4cDAzRmczTDlMdUNHWHc4QzBYNnFSUWRySGpLREtIY1Vk bXc4PGJyPg0KJmd0OyZndDsgTGMkPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBMc3IgbWFpbGluZyBs aXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86THNyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+THNyQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sc3IiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcjwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkxzciBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86THNyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+THNyQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHNyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sc3I8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpMc3IgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OkxzckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkxzckBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzciIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48YSBocmVmPSJodHRw Oi8vd3d3LnZlcml6b24uY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MTE1NUNDO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjgxIiBo ZWlnaHQ9IjE4IiBzdHlsZT0id2lkdGg6Ljg0MTZpbjtoZWlnaHQ6LjE5MTZpbiIgaWQ9Il94MDAw MF9pMTAyNSIgc3JjPSJodHRwOi8vc3M3LnZ6dy5jb20vaXMvaW1hZ2UvVmVyaXpvbldpcmVsZXNz L3Z6LWxvZ28tZW1haWwiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21zby1saW5lLWhlaWdo dC1hbHQ6OS43NXB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+R3lhbiBNaXNocmE8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttc28tbGluZS1o ZWlnaHQtYWx0OjkuNzVwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3Jn aWEmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPk5ldHdvcmsgU29sdXRpb25zIEFyY2hpdGVjdCZu YnNwOzwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21zby1saW5lLWhlaWdodC1hbHQ6OS43NXB0 Ij48aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtj b2xvcjpibGFjayI+TSAzMDEgNTAyLTEzNDc8YnI+DQoxMzEwMSBDb2x1bWJpYSBQaWtlJm5ic3A7 PGJyPg0KPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNpbHZlciBTcHJpbmcs IE1EPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_MW3PR11MB4570A3769257122BFE47E54CC1030MW3PR11MB4570namp_-- From nobody Thu Oct 15 22:51:26 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7802E3A0CA2; Thu, 15 Oct 2020 22:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=OBnBl4hQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=J4tUF+r9 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 Wi6qjNTG5cXJ; Thu, 15 Oct 2020 22:51:22 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1363A0C8F; Thu, 15 Oct 2020 22:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9960; q=dns/txt; s=iport; t=1602827482; x=1604037082; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pEtNxHgbJw7MzonwXwMuNfVCg0vGtBsoa+yXUEpEGA0=; b=OBnBl4hQgOFnaTtbveLefxNe1xjbdy1dyTkvPCkpatIHWKeVUaDfu7gp Vo6Z/hLmeckVkskQgnioEHjlFRkKnbPHwE9reoya96rtc3Z7AHbf+002+ BDR3oAfM+hOucvdBHkr9jtI/DYBIgiUBXd0adWTFcycUS2BzzSjtCPbJv E=; X-IPAS-Result: =?us-ascii?q?A0DGCQDFM4lf/4cNJK1gHgEBCxIMQIMhUQdwWS8shD2DR?= =?us-ascii?q?gONUYoRjmqBQoERA1ULAQEBDQEBGAsKAgQBAYRKAheBcQIlOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBG2FXAyFcgEBAQEDAQEQEREMAQEsCwELBAIBCBEEAQEBA?= =?us-ascii?q?gIjAwICAh8GCxQBCAgCBAENBQgagwWCSwMuAQ6iCAKBOYhhdoEygwEBAQWBM?= =?us-ascii?q?wETQYMZDQuCEAMGgQ4qgnKDboEGhVAbgUE/gRABQ4JNPoIaQgEBAgEBgSYBE?= =?us-ascii?q?QIBBhwVD4JxM4ItkAkEgwY9kxOQRVQKgmqJBIxfgiGDDIMWigiULJMsinOCb?= =?us-ascii?q?JJOAgQCBAUCDgEBBYFrI2dwcBU7gjUBAQExUBcCDY4fg3GFFIVCdAI2AgYBC?= =?us-ascii?q?QEBAwl8jUwBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AuxJh7xw/hQUmze3XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRaBt+l2jVnGXZjSrfVehKzdtfOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXifFzUrX2v5HgVAB?= =?us-ascii?q?q5PgwmbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,381,1596499200"; d="scan'208";a="556519468" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Oct 2020 05:51:20 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 09G5pK3l031515 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2020 05:51:20 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 16 Oct 2020 00:51:20 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 16 Oct 2020 01:51:19 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 16 Oct 2020 00:51:18 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+xpvbE7Ih0d59K20N+MW7NznNHsbeIC6ICsd1szjCVGn42NUX37Hfw3Bjw+U8A9lHLUEkdkV/8E7nmnH6rKvvD3c8AE/yGJQHtYwqBeJPUU7mu14d2+oRYPZ+iX3LdEBmyk5tzXeOMlE1Bie64HTqBRr7TOUCASaBghFraYFmf/+bzVqCkjuw3SotlOlx5q6pGle1J/xJR2iE6xMD7kBeNN0NAvyU+6bd4J8TmL7HnwbA8+5tELPr/91++7kiVs3UY7QTmpzB/pIZxzXJaUQueorxfqT99iCKSzL2AUdJgFEeJrEd1OKSoUjjsd2FUkjtAm7+1pCGoKhMftqVCEEA== 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=pEtNxHgbJw7MzonwXwMuNfVCg0vGtBsoa+yXUEpEGA0=; b=dJV0bkn62xbfjP/mKlVKctfMOn+m5rP6ilcNokIGQXLAK+pwpyCLDG56JALxq7Acy7dX/aXymBZ+MbiSWLXr7//e+kdQ9rtXB+hAJRKOPaWTPSpuppaPh4Ag1dRCb+T6Vbbo4aHTLo+gUTR8r5tvxZ8nXmS/ZyzGIBQ9bl7PL/KhcrtrHr0dgKjsskgWGm3UN9TTJd74E0xHfJUy/I3Q7klSH88mpb8Akl/LXY1v9B8a6KxKp+PM0VyhQuA/hMzASk4KTS4NO0DUqC1e6/Fbn0u7Xg0b4O3K++vEENm2rcXEr8hOeZHVxBA827wzAKRx1IyyagCx2qSijZIiE7IGPg== 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=pEtNxHgbJw7MzonwXwMuNfVCg0vGtBsoa+yXUEpEGA0=; b=J4tUF+r9zSM7SF1lbJmZCDmVpTuxrFfTnSnBeHUAcAZ14wFvUl5FzMBsETQRxaY5VBKtT90ppeuhZL8grQfnsulvXg0iQhi+w5oIEbpwmLu8AoaNjJ4J2eqEgVSgF4TpmrvHOyGNF8mENHHbpRGqIit1rIQnn3eV+l6KCsRk6V0= Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB3093.namprd11.prod.outlook.com (2603:10b6:a03:88::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Fri, 16 Oct 2020 05:51:17 +0000 Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf%3]) with mapi id 15.20.3455.030; Fri, 16 Oct 2020 05:51:17 +0000 From: "Les Ginsberg (ginsberg)" To: Aijun Wang , "'Jeff Tantsura'" , "'John E Drake'" CC: "'Christian Hopps'" , "lsr-chairs@ietf.org" , "lsr@ietf.org" , "lsr-ads@ietf.org" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorrKRY+9H8pM3U+ItYWSF6YHFamY2IdAgAAlOwCAADD9AIAASXsAgAA6BYA= Date: Fri, 16 Oct 2020 05:51:17 +0000 Message-ID: References: <006001d6a35e$d9136ab0$8b3a4010$@tsinghua.org.cn> In-Reply-To: <006001d6a35e$d9136ab0$8b3a4010$@tsinghua.org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2602:306:36ca:6640:2d9a:f9b6:44f7:40a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 36159d2b-497a-491f-3ab3-08d871978051 x-ms-traffictypediagnostic: BYAPR11MB3093: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TU/p1LGHbUn40j1uRPnP5NfHtFAgdA52qvRMMYwTSfCejS/z4jvp79APAHkf4hLDhA4Ot51tJiS9bhdjW0Wg/viJiZ1MvpRLIE7i6ashO3+gEHoUlAO3RPCygpcTjDrabP6S5WTk0Tl/HvHW9p3tBfHPctAV/bPB5W/sKM08sZCW/Y11xBnsh2AAbO5QVtbXNJjy5T+zVT9k4rWZ73NvHlcOvE2DtF8YCSLpu/m7OCqVHNgsYySzaYs5Y6YuXCajmOuAK5takfQN16jTTtUtRZ3FtL8VpazecGKC3jOW/H4qy92SyIgaPLGrl5JdW5LpIoy/D0TMqllcIuBe4OKizecJZmLHa9aEKdgcB7DxFy0rP9uAKeosd8XzKv4Ee7f8RqToNcqYaEOAxYhq1/quxA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(136003)(376002)(39860400002)(346002)(66556008)(71200400001)(66946007)(316002)(5660300002)(66476007)(55016002)(186003)(66446008)(66574015)(8676002)(83380400001)(64756008)(86362001)(9686003)(110136005)(4326008)(8936002)(33656002)(2906002)(7696005)(6506007)(76116006)(53546011)(52536014)(54906003)(966005)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: UG3c68oNOUat9b3JP18HWRFpkQ+lrc5aldS06pTrcEueHoWX5zlHbx/PcPi0QgXykpt6GYuexo1WgAIWnEyBu+bs8WRxmbh5nU7BevmkVdgMa7wx5woYuS7KOpwOpbOUl2EVjW7r4rLC2w0VIzs3+0bAT4pJj3AIJ2kxpz3/hNGoLrX+s2dVYKGkbQksDhPH5mcQ0pgqBHQlNiocTFzWGegIZIWqyXM5ovFRMCtsjaJQyG2y3U9/u6us+DcmhHxGfBVTYue/hPIi5C3hCoommgkPiY+rQSTQSsqRKzY1/7gqnekTWh0IK9EM9mFrDx5g5l/aAcGKQHOQHB/otcxnoFqhzE4gnzwjDK1C7+P+mznU9/4gWWKcfYKYmyt4cyoNgAJ8BRi2hZ0rMNBwz1c8aDVWX5bb/gkbBLElUazjWmJqcBCfGkzQm7Hr2f+qWkdoVn150kzqWLPz//Pm9gSQyAFgJ8M2F0IhG0p7b/T++5fLxniQ+lYhTEdZMYLkbtq+Q3OeY9+eJa5Msxi4dDQ5S9YBpzAoZrIwhmIIjbR8qkG59szHmooYi9LgzuBABfYFWNHGcPnYQREbic6saY9yfYGVvfeKU91URJY4KpLdAVlyixsXTC49IOx0y4NF8exFxOLmLw8h5iZDiqpum7ky1d2qMVZCaDm+UXDUvNvG/uPtlnbskuJLzxx0OYgJ5TzLffxfgq7VMNabU7h4buoOIA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36159d2b-497a-491f-3ab3-08d871978051 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 05:51:17.7793 (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: HKuSuKT9vYlHHbOyCEq/TK4H06Dhsv2Eao1wfru6NMChWuVH9EOZEEnemDzAXWoDAd4ypSeltpaZl2zrGfOt6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3093 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 05:51:25 -0000 QWlqdW4gLQ0KDQpUaGUgcG9pbnQgSSBhbSBtYWtpbmcgaXMgdmVyeSBmb2N1c2VkLg0KDQpUaGlz IGRyYWZ0IGlzIGRlZmluaW5nIGEgcHJvdG9jb2wgZXh0ZW5zaW9uLiBBcyBzdWNoIGl0IGlzIG5l Y2Vzc2FyeSB0aGF0IHRoaXMgYmUgU3RhbmRhcmRzIHRyYWNrIGFzIGFkaGVyaW5nIHRvIHRoZSBu b3JtYXRpdmUgc3RhdGVtZW50cyBpbiB0aGUgZHJhZnQgYXJlIG5lY2Vzc2FyeSBmb3IgaW50ZXJv cGVyYWJpbGl0eS4NCg0KV2hhdCBpcyBkaXNjdXNzZWQgaW4gdGhlIEFwcGVuZGl4IGlzIGEgdXNl IGNhc2UuIEl0IGlzIG5vdCBub3JtYXRpdmUgYW5kIHRoZXJlIGFyZSBzdHJvbmcgb3BpbmlvbnMg b24gYm90aCBzaWRlcyBhcyB0byB3aGV0aGVyIHRoaXMgaXMgYW4gYXBwcm9wcmlhdGUgdXNlIGNh c2Ugb3Igbm90Lg0KSW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkcmFmdCwgSSBoYXZlIG5vIGludGVy ZXN0IGluIHRyeWluZyB0byByZXNvbHZlIG91ciBkaWZmZXJlbmNlIG9mIG9waW5pb24gb24gdGhp cyB1c2UgY2FzZS4gSSBzaW1wbHkgd2FudCB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9uIHRvIG1vdmUg Zm9yd2FyZCBzbyB0aGF0IHdlIGhhdmUgYW5vdGhlciB0b29sIGF2YWlsYWJsZS4NCg0KSWYgeW91 IHdhbnQgdG8gd3JpdGUgYSBkcmFmdCBvbiB0aGUgdXNlIGNhc2UgZGlzY3Vzc2VkIGluIHRoZSBB cHBlbmRpeCBwbGVhc2UgZmVlbCBmcmVlIHRvIGRvIHNvLiBUaGF0IGRyYWZ0IG1heSB2ZXJ5IHdl bGwgbm90IGJlIG5vcm1hdGl2ZSAtIEluZm9ybWF0aW9uYWwgb3IgQkNQIG1heSBiZSBtb3JlIGFw cHJvcHJpYXRlIC0gYmVjYXVzZSBpdCB3aWxsIGJlIGRpc2N1c3NpbmcgYSBkZXBsb3ltZW50IHNj ZW5hcmlvIGFuZCBhIHByb3Bvc2FsIHRvIHVzZSBkZWZpbmVkIHByb3RvY29sIGV4dGVuc2lvbnMg YXMgb25lIHdheSB0byBzb2x2ZSBwcm9ibGVtcyBpbiB0aGF0IGRlcGxveW1lbnQgc2NlbmFyaW8u IFN1Y2ggYSBkcmFmdCBtaWdodCBhbHNvIGJlIG1vcmUgYXBwcm9wcmlhdGUgaW4gYW5vdGhlciBX RyAoZS5nLiwgVEVBUykuIFRoZSBtZXJpdHMgb2YgdXNpbmcgcHJlZml4IGFkdmVydGlzZW1lbnRz IHRvIGJ1aWxkIGEgdG9wb2xvZ3kgY291bGQgdGhlbiBiZSBkaXNjdXNzZWQgb24gaXRzIG93bi4g DQoNClBsZWFzZSBkbyBub3QgdHJ5IHRvIGF2b2lkIGhhdmluZyBhIGZ1bGwgZGlzY3Vzc2lvbiBv ZiB0aGUgbWVyaXRzIG9mIHVzaW5nIHByZWZpeCBhZHZlcnRpc2VtZW50cyB0byBkZXJpdmUgdG9w b2xvZ3kgYnkgYWRkaW5nIGl0IHRvIGEgZHJhZnQgdGhhdCBpcyAoYW5kIHNob3VsZCBiZSkgZm9j dXNlZCBvbiBzaW1wbGUgcHJvdG9jb2wgZXh0ZW5zaW9ucy4NCg0KVGhhbnguDQoNCiAgIExlcw0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWlqdW4gV2FuZyA8d2Fu Z2FpanVuQHRzaW5naHVhLm9yZy5jbj4NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTUsIDIw MjAgNjo1MSBQTQ0KPiBUbzogJ0plZmYgVGFudHN1cmEnIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNv bT47ICdKb2huIEUgRHJha2UnDQo+IDxqZHJha2VAanVuaXBlci5uZXQ+DQo+IENjOiAnQ2hyaXN0 aWFuIEhvcHBzJyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBsc3ItY2hhaXJzQGlldGYub3JnOyBMZXMg R2luc2JlcmcNCj4gKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsgbHNyQGlldGYub3Jn OyBsc3ItYWRzQGlldGYub3JnOyBkcmFmdC1pZXRmLQ0KPiBsc3Itb3NwZi1wcmVmaXgtb3JpZ2lu YXRvckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0xzcl0gV0cgTGFzdCBDYWxsIGRyYWZ0LWll dGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gDQo+IEhpLCBMZXMsIEpvaG4gYW5k IEplZmY6DQo+IA0KPiBMZXQncyByZXBseSB5b3UgYWxsIHRvZ2V0aGVyLg0KPiBJbiBteSBQT1Ys IFRoZSBzdGFuZGFyZCBkb2N1bWVudCBzaG91bGQgbm90IGRlZmluZSBzb2xlbHkgdGhlIHByb3Rv Y29sDQo+IGV4dGVuc2lvbiwgYnV0IHRoZWlyIHVzYWdlcyBpbiB0aGUgbmV0d29yayBkZXBsb3lt ZW50LiBBcyBJIGtub3duLCBhbG1vc3QNCj4gYWxsIHRoZSBJRVRGIGRvY3VtZW50cyBmb2xsb3dp bmcgdGhpcyBzdHlsZS4NCj4gQW5kLCBiZWZvcmUgYWRvcHRpbmcgb25lIHdvcmssIHdlIGhhdmUg b2Z0ZW4gaW50ZW5zZSBkaXNjdXNzaW9uIGZvciB3aGF0J3MNCj4gdGhlaXIgdXNhZ2VzLg0KPiBT dWNoIGRpc2N1c3Npb24gaW4gdGhlIG1haWwgbGlzdCBhbmQgc3RhdGVtZW50cyBpbiB0aGUgZG9j dW1lbnQgY2FuIGNlcnRhaW5seQ0KPiBhc3Npc3QgdGhlIHJlYWRlci91c2VyIG9mIHRoZSBkb2N1 bWVudCBnZXQgdGhlIGVzc2VuY2Ugb2YgdGhlIHN0YW5kYXJkLCBhbmQNCj4gZm9sbG93IHRoZW0g dW5hbWJpZ3VvdXNseS4NCj4gDQo+IFJlZ2FyZGluZyB0aGUgY29udGVudHMgb2YgYXBwZW5kaWNl cywgYXMgc3RhdGVkIGluIHRoZSBzZWN0aW9uLCAiVGhlDQo+IEFwcGVuZGl4IEEgaGV1cmlzdGlj IHRvIHJlYnVpbGQgdGhlIHRvcG9sb2d5IGNhbiBub3JtYWxseSBiZSB1c2VkIGlmIGFsbCBsaW5r cw0KPiBhcmUgbnVtYmVyZWQuIiBJIHRoaW5rIHRoaXMgY2FuIGFwcGx5IGFsbW9zdCBtb3N0IG9m IHRoZSBvcGVyYXRvcidzIG5ldHdvcmssDQo+IGFuZCBmYWNpbGl0YXRlIHRoZSBpbnRlci1hcmVh IFRFIHBhdGggY2FsY3VsYXRpb24gZm9yIGNlbnRyYWwgY29udHJvbGxlciwgb3IgZXZlbg0KPiBm b3IgdGhlIGhlYWQtZW5kIHJvdXRlciB0aGF0IGxvY2F0ZWQgaW4gb25lIGFyZWEgdGhhdCBkaWZm ZXJlbnQgZnJvbSB0aGUgdGFpbC0NCj4gZW5kIHJvdXRlci4NCj4gDQo+IEtlZXBpbmcgdGhlIGNv bnRlbnRzIG9mIGFwcGVuZGljZXMgZG9lcyBub3QgaGF2ZSB0aGUgbmVnYXRpdmUgaW1wYWN0IG9m DQo+IHRoZSBwcm90b2NvbCBleHRlbnNpb24sIGl0IGlzIGp1c3Qgb25lIHJlZmVyZW5jZSBmb3Ig dGhlIHVzYWdlIG9mIHRoaXMNCj4gZXh0ZW5zaW9uLg0KPiBPbmUgY2FuIHNlbGVjdCBub3QgcmVm ZXIgdG8gaXQsIGlmIHRoZWlyIG5ldHdvcmtzIGFyZSBkZXBsb3llZCB3aXRoIGxhcmdlDQo+IGFt b3VudCBvZiB1bm51bWJlcmVkIGxpbmtzLiBCdXQgZm9yIG90aGVycywgdGhlIGhldXJpc3RpYyBh cHBsaWVzLg0KPiANCj4gQmVzdCBSZWdhcmRzDQo+IA0KPiBBaWp1biBXYW5nDQo+IENoaW5hIFRl bGVjb20NCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog bHNyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEplZmYNCj4gVGFudHN1cmENCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDE2LCAyMDIw IDU6MjggQU0NCj4gVG86IEpvaG4gRSBEcmFrZSA8amRyYWtlPTQwanVuaXBlci5uZXRAZG1hcmMu aWV0Zi5vcmc+DQo+IENjOiBDaHJpc3RpYW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPjsgbHNy LWNoYWlyc0BpZXRmLm9yZzsgTGVzIEdpbnNiZXJnDQo+IChnaW5zYmVyZykgPGdpbnNiZXJnPTQw Y2lzY28uY29tQGRtYXJjLmlldGYub3JnPjsgbHNyQGlldGYub3JnOyBsc3ItDQo+IGFkc0BpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW0xzcl0gV0cgTGFzdCBDYWxsIGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4 LW9yaWdpbmF0b3ItMDYNCj4gDQo+ICsxDQo+IA0KPiBSZWdhcmRzLA0KPiBKZWZmDQo+IA0KPiA+ IE9uIE9jdCAxNSwgMjAyMCwgYXQgMTE6MzMsIEpvaG4gRSBEcmFrZQ0KPiA8amRyYWtlPTQwanVu aXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+DQo+ID4g77u/SGksDQo+ID4NCj4g PiBJIGFncmVlIHdpdGggTGVzLiAgVGhpcyBpcyBhIHNpbXBsZSBwcm90b2NvbCBleHRlbnNpb24g Zm9yIGEgc3BlY2lmaWMgcHVycG9zZQ0KPiBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIHRvIGluY2x1 ZGUgc3BlY3VsYXRpb24gYWJvdXQgaXRzIHVzZSBmb3Igb3RoZXINCj4gcHVycG9zZXMsIHBhcnRp Y3VsYXJseSB3aGVuIGl0IGlzIGluaGVyZW50bHkgbm90IHN1aXRlZCBmb3IgdGhlbS4NCj4gPg0K PiA+IFlvdXJzIElycmVzcGVjdGl2ZWx5LA0KPiA+DQo+ID4gSm9obg0KPiA+DQo+ID4NCj4gPiBK dW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogTHNyIDxsc3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1 LCAyMDIwIDEyOjMzIFBNDQo+ID4+IFRvOiBDaHJpc3RpYW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMu b3JnPjsgbHNyQGlldGYub3JnDQo+ID4+IENjOiBsc3ItY2hhaXJzQGlldGYub3JnOyBsc3ItYWRz QGlldGYub3JnOw0KPiA+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC0gb3JpZ2luYXRvckBp ZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW0xzcl0gV0cgTGFzdCBDYWxsDQo+ID4+IGRyYWZ0 LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gPj4NCj4gPj4gW0V4dGVybmFs IEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KPiA+Pg0KPiA+Pg0KPiA+PiBJIHN1cHBv cnQgbW92aW5nIHRoaXMgZG9jdW1lbnQgZm9yd2FyZC4NCj4gPj4gU2ltaWxhciBmdW5jdGlvbmFs aXR5IGluIElTLUlTIGhhcyBwcm92ZWQgdXNlZnVsLg0KPiA+Pg0KPiA+PiBJIHdvdWxkIGhvd2V2 ZXIgbGlrZSB0byByZXBlYXQgY29tbWVudHMgSSBtYWRlIGVhcmxpZXIgaW4gdGhlIHJldmlldw0K PiA+PiBvZiB0aGlzIGRvY3VtZW50Lg0KPiA+PiBUaGUgY29udGVudCBvZiB0aGUgQXBwZW5kaWNl cyBzaG91bGQgYmUgcmVtb3ZlZC4NCj4gPj4gVGhlIEFwcGVuZGljZXMgZGVmaW5lIGFuZCBkaXNj dXNzIGRlcml2aW5nIHRvcG9sb2d5IGluZm9ybWF0aW9uIGZyb20NCj4gPj4gcHJlZml4IGFkdmVy dGlzZW1lbnRzIC0gd2hpY2ggaXMgZmxhd2VkIGFuZCBzaG91bGQgbm90IGJlIGRvbmUuDQo+ID4+ IFBlcmhhcHMgbW9yZSByZWxldmFudCwgdGhlIHB1cnBvc2Ugb2YgdGhlIGRvY3VtZW50IGlzIHRv IGRlZmluZQ0KPiA+PiBwcm90b2NvbCBleHRlbnNpb25zIHN1cHBvcnRpbmcgYWR2ZXJ0aXNlbWVu dCBvZiB0aGUgb3JpZ2luYXRvcnMgb2YgYQ0KPiA+PiBwcmVmaXggYWR2ZXJ0aXNlbWVudC4gVGhl cmUgaXMgbm8gbmVlZCB0byBkaXNjdXNzIGhvdyB0aGlzIG1lY2hhbmlzbQ0KPiA+PiBtaWdodCBi ZSB1c2VkIHRvIGJ1aWxkIHRvcG9sb2d5IGluZm9ybWF0aW9uLg0KPiA+PiBUaGlzIGRvY3VtZW50 IHNob3VsZCBjb25maW5lIGl0c2VsZiB0byBkZWZpbmluZyB0aGUgcHJvdG9jb2wNCj4gPj4gZXh0 ZW5zaW9ucyAtIHNpbWlsYXIgdGhlIFJGQyA3Nzk0Lg0KPiA+Pg0KPiA+PiBJZiB0aGUgYXV0aG9y cyBkbyBub3QgYWdyZWUgdG8gZG8gdGhpcywgSSB3b3VsZCBlbmNvdXJhZ2UgdGhpcyBwb2ludA0K PiA+PiB0byBiZSBkaXNjdXNzZWQgZHVyaW5nIElFU0cgcmV2aWV3Lg0KPiA+Pg0KPiA+PiAgIExl cw0KPiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IExz ciA8bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gSG9wcHMNCj4g Pj4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNCwgMjAyMCAxMToxNSBQTQ0KPiA+Pj4gVG86 IGxzckBpZXRmLm9yZw0KPiA+Pj4gQ2M6IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdp bmF0b3JAaWV0Zi5vcmc7DQo+ID4+PiBsc3ItY2hhaXJzQGlldGYub3JnOyBsc3ItIGFkc0BpZXRm Lm9yZzsgQ2hyaXN0aWFuIEhvcHBzDQo+ID4+PiA8Y2hvcHBzQGNob3Bwcy5vcmc+DQo+ID4+PiBT dWJqZWN0OiBbTHNyXSBXRyBMYXN0IENhbGwgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3Jp Z2luYXRvci0wNg0KPiA+Pj4NCj4gPj4+IFRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExhc3QgQ2Fs bCwgZW5kaW5nIGFmdGVyIE9jdCAyOXRoLCAyMDIwLCBmb3I6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pDQo+ID4+PiBldA0KPiA+Pj4gZi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRv ci9fXzshIU5FdDZ5TWFPLQ0KPiBnayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxDQo+ID4+PiBoSyA4 cDAzRmczTDlMdUNHWHc4QzBYNnFSUWRySGpLREtIY2prakNscGskDQo+ID4+Pg0KPiA+Pj4gVGhl IGZvbGxvd2luZyBJUFIgaGFzIGJlZW4gZmlsZWQNCj4gPj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5j b20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8zNDQ4L19fOyENCj4gPj4+ ICFORXQ2eU1hTy0NCj4gPj4gZ2shVGFTelFUaGdodENGT3VZUFMyVmpMcWhLOHAwM0ZnM0w5THVD R1h3OEMwWDZxUlFkckhqS0RLSGN6DQo+ID4+PiA1S3RVSFEkDQo+ID4+Pg0KPiA+Pj4gQXV0aG9y cywNCj4gPj4+DQo+ID4+PiAgUGxlYXNlIGluZGljYXRlIHRvIHRoZSBsaXN0LCB5b3VyIGtub3ds ZWRnZSBvZiBhbnkgb3RoZXIgSVBSDQo+ID4+PiByZWxhdGVkIHRvIHRoaXMgd29yay4NCj4gPj4+ DQo+ID4+PiBUaGFua3MsDQo+ID4+PiBDaHJpcy4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gTHNyIG1haWxpbmcgbGlzdA0K PiA+PiBMc3JAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo+ID4+IF9fOyEhTkV0DQo+ID4+ IDZ5TWFPLQ0KPiA+Pg0KPiBnayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxaEs4cDAzRmczTDlMdUNH WHc4QzBYNnFSUWRySGpLREtIY1VkbQ0KPiB3OA0KPiA+PiBMYyQNCj4gPg0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTHNyIG1haWxpbmcg bGlzdA0KPiA+IExzckBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHNyDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBMc3IgbWFpbGluZyBsaXN0DQo+IExzckBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0KDQo= From nobody Fri Oct 16 00:15:52 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE41A3A0D73; Fri, 16 Oct 2020 00:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hw4gwDySnN8q; Fri, 16 Oct 2020 00:15:49 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 710CC3A0D71; Fri, 16 Oct 2020 00:15:48 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id DD8D46167D; Fri, 16 Oct 2020 07:15:46 +0000 (UTC) From: Christian Hopps Message-Id: <23602D73-2D66-434E-8C59-97BB33F4C207@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_104BA3C6-1338-4E4F-8BCF-5D5804B2F093"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 16 Oct 2020 03:15:45 -0400 In-Reply-To: Cc: Christian Hopps , Aijun Wang , Jeff Tantsura , John E Drake , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" , "lsr@ietf.org" To: "Les Ginsberg (ginsberg)" References: <006001d6a35e$d9136ab0$8b3a4010$@tsinghua.org.cn> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 07:15:51 -0000 --Apple-Mail=_104BA3C6-1338-4E4F-8BCF-5D5804B2F093 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) = wrote: >=20 > Aijun - >=20 > The point I am making is very focused. >=20 > This draft is defining a protocol extension. As such it is necessary = that this be Standards track as adhering to the normative statements in = the draft are necessary for interoperability. >=20 > What is discussed in the Appendix is a use case. It is not normative = and there are strong opinions on both sides as to whether this is an = appropriate use case or not. > In the context of this draft, I have no interest in trying to resolve = our difference of opinion on this use case. I simply want the protocol = extension to move forward so that we have another tool available. >=20 > If you want to write a draft on the use case discussed in the Appendix = please feel free to do so. That draft may very well not be normative - = Informational or BCP may be more appropriate - because it will be = discussing a deployment scenario and a proposal to use defined protocol = extensions as one way to solve problems in that deployment scenario. = Such a draft might also be more appropriate in another WG (e.g., TEAS). = The merits of using prefix advertisements to build a topology could then = be discussed on its own. >=20 > Please do not try to avoid having a full discussion of the merits of = using prefix advertisements to derive topology by adding it to a draft = that is (and should be) focused on simple protocol extensions. [As WG member] I find this very compelling and so support the removal of the referred = to non-normative appendices. Thanks, Chris. >=20 > Thanx. >=20 > Les >=20 >=20 >> -----Original Message----- >> From: Aijun Wang >> Sent: Thursday, October 15, 2020 6:51 PM >> To: 'Jeff Tantsura' ; 'John E Drake' >> >> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; Les = Ginsberg >> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; = draft-ietf- >> lsr-ospf-prefix-originator@ietf.org >> Subject: RE: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 >>=20 >> Hi, Les, John and Jeff: >>=20 >> Let's reply you all together. >> In my POV, The standard document should not define solely the = protocol >> extension, but their usages in the network deployment. As I known, = almost >> all the IETF documents following this style. >> And, before adopting one work, we have often intense discussion for = what's >> their usages. >> Such discussion in the mail list and statements in the document can = certainly >> assist the reader/user of the document get the essence of the = standard, and >> follow them unambiguously. >>=20 >> Regarding the contents of appendices, as stated in the section, "The >> Appendix A heuristic to rebuild the topology can normally be used if = all links >> are numbered." I think this can apply almost most of the operator's = network, >> and facilitate the inter-area TE path calculation for central = controller, or even >> for the head-end router that located in one area that different from = the tail- >> end router. >>=20 >> Keeping the contents of appendices does not have the negative impact = of >> the protocol extension, it is just one reference for the usage of = this >> extension. >> One can select not refer to it, if their networks are deployed with = large >> amount of unnumbered links. But for others, the heuristic applies. >>=20 >> Best Regards >>=20 >> Aijun Wang >> China Telecom >>=20 >>=20 >>=20 >> -----Original Message----- >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Jeff >> Tantsura >> Sent: Friday, October 16, 2020 5:28 AM >> To: John E Drake >> Cc: Christian Hopps ; lsr-chairs@ietf.org; Les = Ginsberg >> (ginsberg) ; lsr@ietf.org; = lsr- >> ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org >> Subject: Re: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 >>=20 >> +1 >>=20 >> Regards, >> Jeff >>=20 >>> On Oct 15, 2020, at 11:33, John E Drake >> wrote: >>>=20 >>> =EF=BB=BFHi, >>>=20 >>> I agree with Les. This is a simple protocol extension for a = specific purpose >> and there is no reason to include speculation about its use for other >> purposes, particularly when it is inherently not suited for them. >>>=20 >>> Yours Irrespectively, >>>=20 >>> John >>>=20 >>>=20 >>> Juniper Business Use Only >>>=20 >>>> -----Original Message----- >>>> From: Lsr On Behalf Of Les Ginsberg = (ginsberg) >>>> Sent: Thursday, October 15, 2020 12:33 PM >>>> To: Christian Hopps ; lsr@ietf.org >>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; >>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org >>>> Subject: Re: [Lsr] WG Last Call >>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>=20 >>>> [External Email. Be cautious of content] >>>>=20 >>>>=20 >>>> I support moving this document forward. >>>> Similar functionality in IS-IS has proved useful. >>>>=20 >>>> I would however like to repeat comments I made earlier in the = review >>>> of this document. >>>> The content of the Appendices should be removed. >>>> The Appendices define and discuss deriving topology information = from >>>> prefix advertisements - which is flawed and should not be done. >>>> Perhaps more relevant, the purpose of the document is to define >>>> protocol extensions supporting advertisement of the originators of = a >>>> prefix advertisement. There is no need to discuss how this = mechanism >>>> might be used to build topology information. >>>> This document should confine itself to defining the protocol >>>> extensions - similar the RFC 7794. >>>>=20 >>>> If the authors do not agree to do this, I would encourage this = point >>>> to be discussed during IESG review. >>>>=20 >>>> Les >>>>=20 >>>>> -----Original Message----- >>>>> From: Lsr On Behalf Of Christian Hopps >>>>> Sent: Wednesday, October 14, 2020 11:15 PM >>>>> To: lsr@ietf.org >>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >>>>> >>>>> Subject: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 >>>>>=20 >>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, = for: >>>>>=20 >>>>>=20 >>>>> = https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i >>>>> et >>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLq >>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>>>=20 >>>>> The following IPR has been filed >>>>> = https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! >>>>> !NEt6yMaO- >>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>>>> 5KtUHQ$ >>>>>=20 >>>>> Authors, >>>>>=20 >>>>> Please indicate to the list, your knowledge of any other IPR >>>>> related to this work. >>>>>=20 >>>>> Thanks, >>>>> Chris. >>>>=20 >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> = https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >>>> __;!!NEt >>>> 6yMaO- >>>>=20 >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >> w8 >>>> Lc$ >>>=20 >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >>=20 >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr --Apple-Mail=_104BA3C6-1338-4E4F-8BCF-5D5804B2F093 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+JSKEACgkQLh2DDte4 MCXymg/+Pbj4ll987GvHXZswFv696XD54q+w/KMIyr0B215bW4D8HOsUlMhMVqS2 tPolv8usuQUb73PXZ4FEHnuAE8N3jmJB1IHCw3vsTNQfznc44vLAjJXtASWJ9Anv GsegTkLOH2IYC42x7w/IBjwJtCvOI1+QmemCSwYJoT27Z8DrFMubmk2G6+Q0PNaY OEgtVCrtfgioTnVC8uFscuxi7A69NpYjjjLyiKC53U5KENl1b7DBhiMcDm441f6n sYnCXT7Iib9qC31k/s8uRvDjVVpogNZj4vNypOxKpxYayl+Ghxp5iERzYT6K/niN mcBffJ+JBiIqrCK+xevmOyEHHIcbSRVtXAJwnNDkefclEaeirvlqSElfzgxKXjHy Wz7FtgHMsRUbTFe9UDGwFJqCaqvEn7JnOwLqRRNgk6gqHRBi2S9EFvAhgk3rQ+bp tvlmKfaQSzmoZguacrFv2kRyDq+c/a1vV5IzY53ZcQ8bFE93pTviM845+wRzI9Tw re70VTR+S7yfOQyspXQGeQph1BSO7B89bfUBwBQXwsttCkZ0LrTcgd5KOoYp8G+P kCRHzUMNunzvd3eENb4eNPgknfiiLfRcwjDXxJ4E0siU4COlw+WJdWfW4umSitbv CcSpuBCCbYxf8KwhCb+jJAfoaEox5twKKQMFmI23CU1jz9BEDhY= =YfVz -----END PGP SIGNATURE----- --Apple-Mail=_104BA3C6-1338-4E4F-8BCF-5D5804B2F093-- From nobody Fri Oct 16 01:48:05 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099F23A0DEE; Fri, 16 Oct 2020 01:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OyR_ia__LRjY; Fri, 16 Oct 2020 01:48:00 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302E13A0DF3; Fri, 16 Oct 2020 01:47:58 -0700 (PDT) Received: from localhost.localdomain (unknown [106.121.6.236]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 36CA847F56; Fri, 16 Oct 2020 16:47:53 +0800 (CST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Aijun Wang Mime-Version: 1.0 (1.0) Date: Fri, 16 Oct 2020 16:47:52 +0800 Message-Id: <3E930E88-9404-4874-888B-881D022DFFEC@tsinghua.org.cn> References: Cc: Jeff Tantsura , John E Drake , Christian Hopps , lsr-chairs@ietf.org, lsr@ietf.org, lsr-ads@ietf.org, draft-ietf-lsr-ospf-prefix-originator@ietf.org In-Reply-To: To: "Les Ginsberg (ginsberg)" X-Mailer: iPhone Mail (18A373) X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTEwYQhhOGklNSEtOVkpNS0lDSENLTEhITUJVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hNSlVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NVE6Hgw6Kz8uATxISBQqGjwB TSgKC0NVSlVKTUtJQ0hDS0xIQ0xMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVU1VSUhNWVdZCAFZQU9NSE43Bg++ X-HM-Tid: 0a7530980f919865kuuu36ca847f56 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 08:48:04 -0000 Hi, Les and experts in LSR: I am open to the removal of the this appendix to forward this draft. But as stated in previous mail, providing this can assist the user/reader of= the draft. We often encounter the questions in the mail list that what the u= sage of protocol/bit definition in some drafts. Actually, we did not expand the discussion of this part in this draft. The d= escription of this part is very concise. If you insist this, I can update the draft in recent days, together with oth= er comments on this draft. Other comments are welcome also! Aijun Wang China Telecom > On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg) wr= ote: >=20 > =EF=BB=BFAijun - >=20 > The point I am making is very focused. >=20 > This draft is defining a protocol extension. As such it is necessary that t= his be Standards track as adhering to the normative statements in the draft a= re necessary for interoperability. >=20 > What is discussed in the Appendix is a use case. It is not normative and t= here are strong opinions on both sides as to whether this is an appropriate u= se case or not. > In the context of this draft, I have no interest in trying to resolve our d= ifference of opinion on this use case. I simply want the protocol extension t= o move forward so that we have another tool available. >=20 > If you want to write a draft on the use case discussed in the Appendix ple= ase feel free to do so. That draft may very well not be normative - Informat= ional or BCP may be more appropriate - because it will be discussing a deplo= yment scenario and a proposal to use defined protocol extensions as one way t= o solve problems in that deployment scenario. Such a draft might also be mor= e appropriate in another WG (e.g., TEAS). The merits of using prefix adverti= sements to build a topology could then be discussed on its own.=20 >=20 > Please do not try to avoid having a full discussion of the merits of using= prefix advertisements to derive topology by adding it to a draft that is (a= nd should be) focused on simple protocol extensions. >=20 > Thanx. >=20 > Les >=20 >=20 >> -----Original Message----- >> From: Aijun Wang >> Sent: Thursday, October 15, 2020 6:51 PM >> To: 'Jeff Tantsura' ; 'John E Drake' >> >> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; Les Ginsb= erg >> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; draft-ie= tf- >> lsr-ospf-prefix-originator@ietf.org >> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>=20 >> Hi, Les, John and Jeff: >>=20 >> Let's reply you all together. >> In my POV, The standard document should not define solely the protocol >> extension, but their usages in the network deployment. As I known, almost= >> all the IETF documents following this style. >> And, before adopting one work, we have often intense discussion for what'= s >> their usages. >> Such discussion in the mail list and statements in the doc From nobody Fri Oct 16 06:58:31 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C023A0F6E; Fri, 16 Oct 2020 06:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BK8I6zlc75L6; Fri, 16 Oct 2020 06:58:27 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 41FC23A0F6C; Fri, 16 Oct 2020 06:58:27 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id u74so1490701vsc.2; Fri, 16 Oct 2020 06:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Si4+Fq9NImUN35HfKlOPCX5NCiFYIIJV/rnEuR06DyY=; b=cWGZIF5YImXrJM2ql2bi0M/UNDwXIBrjTbFR2H1te0ChhRuDVY/FjNXXyAIFpoi1Uj BLlAXEBgbPZUuMQQq62hP81ngZeG9FuG//H1YGd0YyRWgzkIRPo5PQ8/qjua99S2nkFg cAPyECdhBH0bC5EEUyOinVKKUbAI6xfq0+xDHYqECQlgfeBNhfwciFZdzu8DiyDP/EYC lbUcRH5MOPiEvb46pRqiZzYj8Pjkbmi0cLsCrL08oXDM5fh5B97Cg3Gj+jJS3UiwPy5+ A/UVgg6+oeMMoazp64/rgkmh2IdpZ+Lk82AdX5e0js9Lricn7vb9JUudadsvX8WrbdNa 474w== 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=Si4+Fq9NImUN35HfKlOPCX5NCiFYIIJV/rnEuR06DyY=; b=gOFPRpYU96tt4UiBVSOimTe7PF952jzij30rtmHiEHJoHrTjbil5HPs3OWSGe4/r2g +Hnjk7QqnIMIp5OwtezaL8IjOzZ1UWi91a/42hNuVl8zsyda/vAiOSqVfFgstYov+PKd sKKRRE0voU0pnRBriqlvznCA2wzJSaiNY/pnDRUhoM0qnw5XxgJ1lqIy25suvSKp4Hj5 F7CI17QsSrvQtrRnFRkr9r4MiTkrinAsNa1WGzfo6HgNVBUydwIjfqbU7NCYk6pu8W80 TNKCifmabEXcxVhIn1mPvjxUXByxo22I78pDI7mvUjAXHti3Qq6B+GkN5j25bd75eufU mE7g== X-Gm-Message-State: AOAM533lkjnNG3+Erv71P806dQF+oUTo0ns8ecEAH8BoeY0VK/9TrIZZ 31oe0T2Rgkf0MIgFiiSaRA/Np0C5Rd5U2YgESp4= X-Google-Smtp-Source: ABdhPJynPsL/naExkyxtn0rbbCUrTKCKZ9x7xLX2UKoiWtEZ3mETG3LswWxSTf6zSXcFWYsSVPpDKQ7WNXQjus2NT4M= X-Received: by 2002:a67:fdc9:: with SMTP id l9mr1885659vsq.60.1602856706020; Fri, 16 Oct 2020 06:58:26 -0700 (PDT) MIME-Version: 1.0 References: <006001d6a35e$d9136ab0$8b3a4010$@tsinghua.org.cn> In-Reply-To: From: Gyan Mishra Date: Fri, 16 Oct 2020 09:58:15 -0400 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: Aijun Wang , Christian Hopps , Jeff Tantsura , John E Drake , "Les Ginsberg (ginsberg)" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" , "lsr-chairs@ietf.org" , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009698b105b1ca285a" Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 13:58:30 -0000 --0000000000009698b105b1ca285a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed. Also as use cases go that does delve into implementation aspects of which can vary significantly. So to your point as Les and Chris mentioned the focus of LSR and drafts published is on the protocol extension. How it=E2=80=99s used is out of sc= ope and could be a draft in another WG. In this case moreso not pertinent since the primary use case gets into the weeds on a TEAS or PCE topiic. Thanks Gyan On Fri, Oct 16, 2020 at 1:04 AM Ketan Talaulikar (ketant) wrote: > Hi Gyan, > > > > Thanks for your review and feedback. Please check inline below. > > > > *From:* Gyan Mishra > *Sent:* 16 October 2020 10:11 > *To:* Aijun Wang > *Cc:* Christian Hopps ; Jeff Tantsura < > jefftant.ietf@gmail.com>; John E Drake 40juniper.net@dmarc.ietf.org>; Les Ginsberg (ginsberg) 40cisco.com@dmarc.ietf.org>; > draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr@ietf.org; > lsr-ads@ietf.org; lsr-chairs@ietf.org > *Subject:* Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-0= 6 > > > > I support advancement of the draft. > > > > This draft follows along the lines of ISIS RFC 7794 to provide an > extension to identify the prefix originator attribute using an originatin= g > router TLV and a reachable prefix. A node in ospf is represented by a > router-id which technically can be a random 4 octet prefix that does not > have to be reachable entry in the IGP RIB. > > > > The reachability prefix is important in cases where the originator > router-id is not in the RIB or in traffic engineering inter as path > instantiation use case where the router-id originator node is advertised, > however since the TEDs database link attributes are not known > inter-as,having the reachability address is important as defined in the > draft. This feature can also be used identifying the prefix originator = in > a normal user case other then the traffic engineering scenario such as fo= r > troubleshooting which is common to view all the prefixes advertised by a > node by Prefix type. > > > > There maybe cases where you need to create a database filter or policy > and if you can use this feature as a means of controlling prefix > advertisements based on source node that can be powerful and could have > ubiquitous use cases. > > > > With regards to the appendix it does appear to be pertinent, as the use > case appears to be the primary focal point and reason for the draft by th= e > authors. I don=E2=80=99t think that having the appendix precluding othe= r use > cases by any means. > > *[KT] The Introduction section of the draft does touch upon some of the > primary use-cases that authors believe have more wide-spread applicabilit= y. > You have also alluded to some of them and then you have also brought out > some newer use-cases/applications of the extensions in this draft. There > were other use-cases in previous versions like ELC which later went away > based on how we addressed that in draft-ietf-ospf/isis-mpls-elc documents= . > I am sure there will be newer use-cases. The focus of the draft is primar= y > to capture the protocol extensions since that is what we work on in LSR. > The scope of the use-cases may be beyond LSR and in other areas (e.g. TEA= S > perhaps for the one in the appendix ?). Regarding the use-case in the > appendix, it would be fair to say that it was primary focal point for som= e > of the authors.* > > > > *I will leave it to the WG consensus on what content we should be sending > to the IESG.* > > > > *Thanks,* > > *Ketan* > > > > Kind Regards > > > > Gyan > > > > On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang > wrote: > > Hi, Les, John and Jeff: > > Let's reply you all together. > In my POV, The standard document should not define solely the protocol > extension, but their usages in the network deployment. As I known, almost > all the IETF documents following this style. > And, before adopting one work, we have often intense discussion for what'= s > their usages. > Such discussion in the mail list and statements in the document can > certainly assist the reader/user of the document get the essence of the > standard, and follow them unambiguously. > > Regarding the contents of appendices, as stated in the section, "The > Appendix A heuristic to rebuild the topology can normally be used if all > links are numbered." I think this can apply almost most of the operator's > network, and facilitate the inter-area TE path calculation for central > controller, or even for the head-end router that located in one area that > different from the tail-end router. > > Keeping the contents of appendices does not have the negative impact of > the protocol extension, it is just one reference for the usage of this > extension. > One can select not refer to it, if their networks are deployed with large > amount of unnumbered links. But for others, the heuristic applies. > > Best Regards > > Aijun Wang > China Telecom > > > > -----Original Message----- > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of > Jeff Tantsura > Sent: Friday, October 16, 2020 5:28 AM > To: John E Drake > Cc: Christian Hopps ; lsr-chairs@ietf.org; Les > Ginsberg (ginsberg) ; lsr@ietf.org= ; > lsr-ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org > Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > > +1 > > Regards, > Jeff > > > On Oct 15, 2020, at 11:33, John E Drake 40juniper.net@dmarc.ietf.org> wrote: > > > > =EF=BB=BFHi, > > > > I agree with Les. This is a simple protocol extension for a specific > purpose and there is no reason to include speculation about its use for > other purposes, particularly when it is inherently not suited for them. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > > >> -----Original Message----- > >> From: Lsr On Behalf Of Les Ginsberg (ginsberg) > >> Sent: Thursday, October 15, 2020 12:33 PM > >> To: Christian Hopps ; lsr@ietf.org > >> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; > >> draft-ietf-lsr-ospf-prefix- originator@ietf.org > >> Subject: Re: [Lsr] WG Last Call > >> draft-ietf-lsr-ospf-prefix-originator-06 > >> > >> [External Email. Be cautious of content] > >> > >> > >> I support moving this document forward. > >> Similar functionality in IS-IS has proved useful. > >> > >> I would however like to repeat comments I made earlier in the review > >> of this document. > >> The content of the Appendices should be removed. > >> The Appendices define and discuss deriving topology information from > >> prefix advertisements - which is flawed and should not be done. > >> Perhaps more relevant, the purpose of the document is to define > >> protocol extensions supporting advertisement of the originators of a > >> prefix advertisement. There is no need to discuss how this mechanism > >> might be used to build topology information. > >> This document should confine itself to defining the protocol > >> extensions - similar the RFC 7794. > >> > >> If the authors do not agree to do this, I would encourage this point > >> to be discussed during IESG review. > >> > >> Les > >> > >>> -----Original Message----- > >>> From: Lsr On Behalf Of Christian Hopps > >>> Sent: Wednesday, October 14, 2020 11:15 PM > >>> To: lsr@ietf.org > >>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; > >>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps > >>> > >>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 > >>> > >>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: > >>> > >>> > >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i > > >>> et > >>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLq > >>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ > >>> > >>> The following IPR has been filed > >>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__ > ;! > >>> !NEt6yMaO- > >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz > >>> 5KtUHQ$ > >>> > >>> Authors, > >>> > >>> Please indicate to the list, your knowledge of any other IPR > >>> related to this work. > >>> > >>> Thanks, > >>> Chris. > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > > >> __;!!NEt > >> 6yMaO- > >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8 > >> Lc$ > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-1347 13101 Columbia Pike > > *Silver > Spring, MD > > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000009698b105b1ca285a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Agreed.=C2=A0 Also as use cases go that do= es delve into implementation aspects of which can vary significantly.=C2=A0=

So to your point as Les= and Chris mentioned the focus of LSR and drafts published is on the protoc= ol extension.=C2=A0 How it=E2=80=99s used is out of scope and could be a dr= aft in another WG.=C2=A0 In this case moreso not pertinent since the primar= y use case gets into the weeds on a TEAS or PCE topiic.

Thanks=C2=A0

Gyan

On Fri, Oct 16, 2020 at 1:04 AM Ketan Talauli= kar (ketant) <ketant@cisco.com&g= t; wrote:

Hi Gyan,

=C2=A0

Thanks for your review and feedback. Please ch= eck inline below.

=C2=A0

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: 16 October 2020 10:11
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: Christian Hopps <chopps@chopps.org>; Jeff Tantsura <jefftant.ietf@gmail.com>;= John E Drake <jdrake=3D40juniper.net@dmarc.ietf.org>; Les Ginsberg (ginsb= erg) <ginsberg=3D40cisco.com@dmarc.ietf.org>; draft-ietf-lsr-ospf-p= refix-originator@ietf.org; lsr@ietf.org; lsr-ads@ietf.org= ; lsr-chairs@ietf.= org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originato= r-06

=C2=A0

I support advancement of the draft. =C2=A0=

=C2=A0

This draft follows along the lines of ISIS RFC 7794 = to provide an extension to identify the prefix originator attribute using a= n originating router TLV and a reachable prefix.=C2=A0 A node in ospf is re= presented by a router-id which technically can be a random 4 octet prefix that does not have to be reachable entry in= the IGP RIB. =C2=A0

=C2=A0

The reachability prefix is important in cases where = the originator router-id is not =C2=A0in the RIB or in traffic engineering = inter as path instantiation use case where the router-id originator node is= advertised, however since the TEDs database link attributes are not known inter-as,having the reachability address is = important as defined in the draft.=C2=A0 This feature can also be used =C2= =A0identifying the prefix originator in a normal user case other then the t= raffic engineering scenario such as for troubleshooting which is common to view all the prefixes advertised by a node by Prefix ty= pe.=C2=A0

=C2=A0

There maybe cases where you need to create =C2=A0a d= atabase filter or policy and if you can use this feature as a means of cont= rolling prefix advertisements based on source node that can be powerful and= could have ubiquitous use cases.

=C2=A0

With regards to the appendix it does appear to be pe= rtinent, as the use case appears to be the primary focal point and reason f= or the draft by the authors.=C2=A0 I don=E2=80=99t think that having the ap= pendix =C2=A0precluding other use cases by any means.=C2=A0

[KT] The Introduction section of the draft doe= s touch upon some of the primary use-cases that authors believe have more w= ide-spread applicability. You have also alluded to some of them and then yo= u have also brought out some newer use-cases/applications of the extensions in this draft. There were other u= se-cases in previous versions like ELC which later went away based on how w= e addressed that in draft-ietf-ospf/isis-mpls-elc documents. I am sure ther= e will be newer use-cases. The focus of the draft is primary to capture the protocol extensions since that is w= hat we work on in LSR. The scope of the use-cases may be beyond LSR and in = other areas (e.g. TEAS perhaps for the one in the appendix ?). Regarding th= e use-case in the appendix, it would be fair to say that it was primary focal point for some of the authors.=

=C2=A0

I will leave it to the WG consensus on what co= ntent we should be sending to the IESG.

=C2=A0

Thanks,

Ketan

=C2=A0

Kind Regards=C2=A0

=C2=A0

Gyan

=C2=A0

On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang <wangaijun@tsinghu= a.org.cn> wrote:

Hi, Les, John and Jeff:

Let's reply you all together.
In my POV, The standard document should not define solely the protocol exte= nsion, but their usages in the network deployment. As I known, almost all t= he IETF documents following this style.
And, before adopting one work, we have often intense discussion for what= 9;s their usages.
Such discussion in the mail list and statements in the document can certain= ly assist the reader/user of the document get the essence of the standard, = and follow them unambiguously.

Regarding the contents of appendices, as stated in the section, "The A= ppendix A heuristic to rebuild the topology can normally be used if all lin= ks are numbered." I think this can apply almost most of the operator&#= 39;s network, and facilitate the inter-area TE path calculation for central controller, or even for the head-end router t= hat located in one area that different from the tail-end router.

Keeping the contents of appendices does not have the negative impact of the= protocol extension, it is just one reference for the usage of this extensi= on.
One can select not refer to it, if their networks are deployed with large a= mount of unnumbered links. But for others, the heuristic applies.

Best Regards

Aijun Wang
China Telecom



-----Original Message-----
From: lsr-bounces= @ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake <jdrake=3D40juniper.net@dmarc.ietf.org>
Cc: Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.or= g; Les Ginsberg (ginsberg) <ginsberg=3D40cisco.com@dmarc.ietf.org>; lsr@ietf.org; lsr-ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org
Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
+1

Regards,
Jeff

> On Oct 15, 2020, at 11:33, John E Drake <jdrake=3D40juniper.net@dmarc.ietf.o= rg> wrote:
>
> =EF=BB=BFHi,
>
> I agree with Les.=C2=A0 This is a simple protocol extension for a spec= ific purpose and there is no reason to include speculation about its use fo= r other purposes, particularly when it is inherently not suited for them. >
> Yours Irrespectively,
>
> John
>
>
> Juniper Business Use Only
>
>> -----Original Message-----
>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Les Ginsberg (ginsberg)
>> Sent: Thursday, October 15, 2020 12:33 PM
>> To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org
>> Cc: lsr-c= hairs@ietf.org; lsr-ads@ietf.org;=
>> draft-ietf-lsr-ospf-prefix- originator@ietf.org
>> Subject: Re: [Lsr] WG Last Call
>> draft-ietf-lsr-ospf-prefix-originator-06
>>
>> [External Email. Be cautious of content]
>>
>>
>> I support moving this document forward.
>> Similar functionality in IS-IS has proved useful.
>>
>> I would however like to repeat comments I made earlier in the revi= ew
>> of this document.
>> The content of the Appendices should be removed.
>> The Appendices define and discuss deriving topology information fr= om
>> prefix advertisements - which is flawed and should not be done. >> Perhaps more relevant, the purpose of the document is to define=C2= =A0
>> protocol extensions supporting advertisement of the originators of= a
>> prefix advertisement. There is no need to discuss how this mechani= sm
>> might be used to build topology information.
>> This document should confine itself to defining the protocol
>> extensions - similar the RFC 7794.
>>
>> If the authors do not agree to do this, I would encourage this poi= nt
>> to be discussed during IESG review.
>>
>>=C2=A0 =C2=A0Les
>>
>>> -----Original Message-----
>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Christian Hopps
>>> Sent: Wednesday, October 14, 2020 11:15 PM
>>> To: lsr@ietf= .org
>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org;
>>> lsr-c= hairs@ietf.org; lsr- ads@ietf.org; Christi= an Hopps
>>> <cho= pps@chopps.org>
>>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-origina= tor-06
>>>
>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020= , for:
>>>
>>>
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i >>> et
>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYP= S2VjLq
>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
>>>
>>> The following IPR has been filed
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!<= br> >>> !NEt6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
>>> 5KtUHQ$
>>>
>>> Authors,
>>>
>>>=C2=A0 Please indicate to the list, your knowledge of any other= IPR
>>> related to this work.
>>>
>>> Thanks,
>>> Chris.
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org=
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >> __;!!NEt
>> 6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8 >> Lc$
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/lsr

--

Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
Silver Spring, MD

=C2=A0

--
--0000000000009698b105b1ca285a-- From nobody Fri Oct 16 07:38:04 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CCE3A0F8C; Fri, 16 Oct 2020 07:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 5yaALDOmRlBi; Fri, 16 Oct 2020 07:37:59 -0700 (PDT) Received: from mail-m127107.qiye.163.com (mail-m127107.qiye.163.com [115.236.127.107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817EE3A09F0; Fri, 16 Oct 2020 07:37:56 -0700 (PDT) Received: from tsinghua.org.cn (wm-12.qy.internal [127.0.0.1]) by mail-m127107.qiye.163.com (Hmail) with ESMTP id 0486482857; Fri, 16 Oct 2020 22:37:53 +0800 (CST) Content-Type: multipart/alternative; BOUNDARY="=_Part_912019_758899990.1602859073007" Message-ID: To: Christian Hopps Cc: "Les Ginsberg (ginsberg)" , John E Drake , Christian Hopps , "lsr-chairs@ietf.org" , "lsr@ietf.org" , Jeff Tantsura , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" X-Priority: 3 X-Mailer: HMail Webmail Server V2.0 Copyright (c) 2016-163.com X-Originating-IP: 106.121.6.236 In-Reply-To: <23602D73-2D66-434E-8C59-97BB33F4C207@chopps.org> MIME-Version: 1.0 Received: from wangaijun@tsinghua.org.cn( [106.121.6.236) ] by ajax-webmail ( [127.0.0.1] ) ; Fri, 16 Oct 2020 22:37:53 +0800 (GMT+08:00) From: =?UTF-8?B?546L54ix5L+K?= Date: Fri, 16 Oct 2020 22:37:53 +0800 (GMT+08:00) X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGUpPQ0pNT0IeHUNLVkpNS0lDTkJLTEhLQ0lVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0NISFVLWQY+ X-HM-Sender-Digest: e1kJHlYWEh9ZQU5CSk1OQ09CTEpLN1dZDB4ZWUEPCQ4eV1kSHx4VD1lB WUc6OhA6Mzo6Ez8sGTxMKxA2NBJJKDUaCjZVSFVKTUtJQ05CS0xITk1DVTMWGhIXVQwaFRwaEhEO FTsPCBIVHBMOGlUUCRxVGBVFWVdZEgtZQVlKS01VSklKVU1VSUhNWVdZCAFZQUhNTUtLNwY+ X-HM-Tid: 0a7531d87dfd986bkuuu0486482857 Archived-At: Subject: Re: [Lsr] =?utf-8?q?WG_Last_Call_draft-ietf-lsr-ospf-prefix-originat?= =?utf-8?q?or-06?= X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 14:38:03 -0000 --=_Part_912019_758899990.1602859073007 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 CkhpLCBDaHJpczogT3JpZ2luYWxseSwgdGhlIGFwcGVuZGl4IHBhcnQgaXMgd2l0aGluIHRoZSBk b2N1bWVudCwgd2hpY2ggaXMgdGhlIHN0YXJ0IHBvaW50L21haW4gbW90aXZhdGlvbiB0byBleHRl bmQgdGhlIHByZWZpeCBvcmlnaW4uClRoZXJlIG1heSBleGlzdHMgb3RoZXIgdXNhZ2VzIG9mIHRo aXMgaW5mb3JtYXRpb24uIFBhY2sgdGhlc2UgZXhhbXBsZXMgaW50byBzb21lIHNob3J0IHNlbnRl bmNlcyBvciBpbnRyb2R1Y3Rpb24gaXMgdmlhYmxlLCBidXQgZXhwYW5kIHNvbWUgb2YgdGhlbSBp cyBhbHNvIGhlbHBmdWwuQXMgSSBrbm93biwgd2hlbiB3ZSB3YW50IHRvIGRvIHByb3RvY29sIGV4 dGVuc2lvbiwgd2Ugc2hvdWxkICBhbHdheXMgY29udmluY2Ugb3RoZXIgdGhlIHJlYXNvbi9tb3Rp dmF0aW9uL3Byb3NwZWN0cyB0byBkbyBzby4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSB1c2UgY2Fz ZSBkZXNjcmliZWQgaW4gdGhlIGN1cnJlbnQgYXBwZW5kaXggaXMgdmVyeSBwcm9taW5lbnQgZm9y IG9wZXJhdG9yIHRvIGFjY29tcGxpc2ggdGhlIFRFIHRhc2sgaW4gbXVsdGktYXJlYSBlbnZpcm9u bWVudC4KCkFpanVuIFdhbmcKCuWcqDIwMjAtMTAtMTbvvIxDaHJpc3RpYW4gSG9wcHMgJmx0O2No b3Bwc0BjaG9wcHMub3JnJmd0O+WGmemBkzoKIC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0KIOWPkeS7 tuS6uu+8miBDaHJpc3RpYW4gSG9wcHMgJmx0O2Nob3Bwc0BjaG9wcHMub3JnJmd0Owog5Y+R5Lu2 5pe26Ze0OiAyMDIw5bm0MTDmnIgxNuaXpSDmmJ/mnJ/kupQKIOWGmemBkzogWyZxdW90O0xlcyBH aW5zYmVyZyAoZ2luc2JlcmcpJnF1b3Q7ICZsdDtnaW5zYmVyZz00MGNpc2NvLmNvbUBkbWFyYy5p ZXRmLm9yZyZndDtdCiDkuLvpopjvvJogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbCBkcmFmdC1pZXRm LWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2CgogPiBPbiBPY3QgMTYsIDIwMjAsIGF0IDE6 NTEgQU0sIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIDxnaW5zYmVyZz00MGNpc2NvLmNvbUBkbWFy Yy5pZXRmLm9yZz4gd3JvdGU6CiA+IAogPiBBaWp1biAtCiA+IAogPiBUaGUgcG9pbnQgSSBhbSBt YWtpbmcgaXMgdmVyeSBmb2N1c2VkLgogPiAKID4gVGhpcyBkcmFmdCBpcyBkZWZpbmluZyBhIHBy b3RvY29sIGV4dGVuc2lvbi4gQXMgc3VjaCBpdCBpcyBuZWNlc3NhcnkgdGhhdCB0aGlzIGJlIFN0 YW5kYXJkcyB0cmFjayBhcyBhZGhlcmluZyB0byB0aGUgbm9ybWF0aXZlIHN0YXRlbWVudHMgaW4g dGhlIGRyYWZ0IGFyZSBuZWNlc3NhcnkgZm9yIGludGVyb3BlcmFiaWxpdHkuCiA+IAogPiBXaGF0 IGlzIGRpc2N1c3NlZCBpbiB0aGUgQXBwZW5kaXggaXMgYSB1c2UgY2FzZS4gSXQgaXMgbm90IG5v cm1hdGl2ZSBhbmQgdGhlcmUgYXJlIHN0cm9uZyBvcGluaW9ucyBvbiBib3RoIHNpZGVzIGFzIHRv IHdoZXRoZXIgdGhpcyBpcyBhbiBhcHByb3ByaWF0ZSB1c2UgY2FzZSBvciBub3QuCiA+IEluIHRo ZSBjb250ZXh0IG9mIHRoaXMgZHJhZnQsIEkgaGF2ZSBubyBpbnRlcmVzdCBpbiB0cnlpbmcgdG8g cmVzb2x2ZSBvdXIgZGlmZmVyZW5jZSBvZiBvcGluaW9uIG9uIHRoaXMgdXNlIGNhc2UuIEkgc2lt cGx5IHdhbnQgdGhlIHByb3RvY29sIGV4dGVuc2lvbiB0byBtb3ZlIGZvcndhcmQgc28gdGhhdCB3 ZSBoYXZlIGFub3RoZXIgdG9vbCBhdmFpbGFibGUuCiA+IAogPiBJZiB5b3Ugd2FudCB0byB3cml0 ZSBhIGRyYWZ0IG9uIHRoZSB1c2UgY2FzZSBkaXNjdXNzZWQgaW4gdGhlIEFwcGVuZGl4IHBsZWFz ZSBmZWVsIGZyZWUgdG8gZG8gc28uIFRoYXQgZHJhZnQgbWF5IHZlcnkgd2VsbCBub3QgYmUgbm9y bWF0aXZlIC0gSW5mb3JtYXRpb25hbCBvciBCQ1AgbWF5IGJlIG1vcmUgYXBwcm9wcmlhdGUgLSBi ZWNhdXNlIGl0IHdpbGwgYmUgZGlzY3Vzc2luZyBhIGRlcGxveW1lbnQgc2NlbmFyaW8gYW5kIGEg cHJvcG9zYWwgdG8gdXNlIGRlZmluZWQgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhcyBvbmUgd2F5IHRv IHNvbHZlIHByb2JsZW1zIGluIHRoYXQgZGVwbG95bWVudCBzY2VuYXJpby4gU3VjaCBhIGRyYWZ0 IG1pZ2h0IGFsc28gYmUgbW9yZSBhcHByb3ByaWF0ZSBpbiBhbm90aGVyIFdHIChlLmcuLCBURUFT KS4gVGhlIG1lcml0cyBvZiB1c2luZyBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgdG8gYnVpbGQgYSB0 b3BvbG9neSBjb3VsZCB0aGVuIGJlIGRpc2N1c3NlZCBvbiBpdHMgb3duLgogPiAKID4gUGxlYXNl IGRvIG5vdCB0cnkgdG8gYXZvaWQgaGF2aW5nIGEgZnVsbCBkaXNjdXNzaW9uIG9mIHRoZSBtZXJp dHMgb2YgdXNpbmcgcHJlZml4IGFkdmVydGlzZW1lbnRzIHRvIGRlcml2ZSB0b3BvbG9neSBieSBh ZGRpbmcgaXQgdG8gYSBkcmFmdCB0aGF0IGlzIChhbmQgc2hvdWxkIGJlKSBmb2N1c2VkIG9uIHNp bXBsZSBwcm90b2NvbCBleHRlbnNpb25zLgoKIFtBcyBXRyBtZW1iZXJdCgogSSBmaW5kIHRoaXMg dmVyeSBjb21wZWxsaW5nIGFuZCBzbyBzdXBwb3J0IHRoZSByZW1vdmFsIG9mIHRoZSByZWZlcnJl ZCB0byBub24tbm9ybWF0aXZlIGFwcGVuZGljZXMuCgogVGhhbmtzLAogQ2hyaXMuCgogPiAKID4g VGhhbnguCiA+IAogPiAgIExlcwogPiAKID4gCiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQogPj4gRnJvbTogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4KID4+IFNl bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDIwIDY6NTEgUE0KID4+IFRvOiAnSmVmZiBUYW50 c3VyYScgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsgJ0pvaG4gRSBEcmFrZScKID4+IDxqZHJh a2VAanVuaXBlci5uZXQ+CiA+PiBDYzogJ0NocmlzdGlhbiBIb3BwcycgPGNob3Bwc0BjaG9wcHMu b3JnPjsgbHNyLWNoYWlyc0BpZXRmLm9yZzsgTGVzIEdpbnNiZXJnCiA+PiAoZ2luc2JlcmcpIDxn aW5zYmVyZ0BjaXNjby5jb20+OyBsc3JAaWV0Zi5vcmc7IGxzci1hZHNAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtCiA+PiBsc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZwogPj4gU3ViamVj dDogUkU6IFtMc3JdIFdHIExhc3QgQ2FsbCBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmln aW5hdG9yLTA2CiA+PiAKID4+IEhpLCBMZXMsIEpvaG4gYW5kIEplZmY6CiA+PiAKID4+IExldCdz IHJlcGx5IHlvdSBhbGwgdG9nZXRoZXIuCiA+PiBJbiBteSBQT1YsIFRoZSBzdGFuZGFyZCBkb2N1 bWVudCBzaG91bGQgbm90IGRlZmluZSBzb2xlbHkgdGhlIHByb3RvY29sCiA+PiBleHRlbnNpb24s IGJ1dCB0aGVpciB1c2FnZXMgaW4gdGhlIG5ldHdvcmsgZGVwbG95bWVudC4gQXMgSSBrbm93biwg YWxtb3N0CiA+PiBhbGwgdGhlIElFVEYgZG9jdW1lbnRzIGZvbGxvd2luZyB0aGlzIHN0eWxlLgog Pj4gQW5kLCBiZWZvcmUgYWRvcHRpbmcgb25lIHdvcmssIHdlIGhhdmUgb2Z0ZW4gaW50ZW5zZSBk aXNjdXNzaW9uIGZvciB3aGF0J3MKID4+IHRoZWlyIHVzYWdlcy4KID4+IFN1Y2ggZGlzY3Vzc2lv biBpbiB0aGUgbWFpbCBsaXN0IGFuZCBzdGF0ZW1lbnRzIGluIHRoZSBkb2N1bWVudCBjYW4gY2Vy dGFpbmx5CiA+PiBhc3Npc3QgdGhlIHJlYWRlci91c2VyIG9mIHRoZSBkb2N1bWVudCBnZXQgdGhl IGVzc2VuY2Ugb2YgdGhlIHN0YW5kYXJkLCBhbmQKID4+IGZvbGxvdyB0aGVtIHVuYW1iaWd1b3Vz bHkuCiA+PiAKID4+IFJlZ2FyZGluZyB0aGUgY29udGVudHMgb2YgYXBwZW5kaWNlcywgYXMgc3Rh dGVkIGluIHRoZSBzZWN0aW9uLCAiVGhlCiA+PiBBcHBlbmRpeCBBIGhldXJpc3RpYyB0byByZWJ1 aWxkIHRoZSB0b3BvbG9neSBjYW4gbm9ybWFsbHkgYmUgdXNlZCBpZiBhbGwgbGlua3MKID4+IGFy ZSBudW1iZXJlZC4iIEkgdGhpbmsgdGhpcyBjYW4gYXBwbHkgYWxtb3N0IG1vc3Qgb2YgdGhlIG9w ZXJhdG9yJ3MgbmV0d29yaywKID4+IGFuZCBmYWNpbGl0YXRlIHRoZSBpbnRlci1hcmVhIFRFIHBh dGggY2FsY3VsYXRpb24gZm9yIGNlbnRyYWwgY29udHJvbGxlciwgb3IgZXZlbgogPj4gZm9yIHRo ZSBoZWFkLWVuZCByb3V0ZXIgdGhhdCBsb2NhdGVkIGluIG9uZSBhcmVhIHRoYXQgZGlmZmVyZW50 IGZyb20gdGhlIHRhaWwtCiA+PiBlbmQgcm91dGVyLgogPj4gCiA+PiBLZWVwaW5nIHRoZSBjb250 ZW50cyBvZiBhcHBlbmRpY2VzIGRvZXMgbm90IGhhdmUgdGhlIG5lZ2F0aXZlIGltcGFjdCBvZgog Pj4gdGhlIHByb3RvY29sIGV4dGVuc2lvbiwgaXQgaXMganVzdCBvbmUgcmVmZXJlbmNlIGZvciB0 aGUgdXNhZ2Ugb2YgdGhpcwogPj4gZXh0ZW5zaW9uLgogPj4gT25lIGNhbiBzZWxlY3Qgbm90IHJl ZmVyIHRvIGl0LCBpZiB0aGVpciBuZXR3b3JrcyBhcmUgZGVwbG95ZWQgd2l0aCBsYXJnZQogPj4g YW1vdW50IG9mIHVubnVtYmVyZWQgbGlua3MuIEJ1dCBmb3Igb3RoZXJzLCB0aGUgaGV1cmlzdGlj IGFwcGxpZXMuCiA+PiAKID4+IEJlc3QgUmVnYXJkcwogPj4gCiA+PiBBaWp1biBXYW5nCiA+PiBD aGluYSBUZWxlY29tCiA+PiAKID4+IAogPj4gCiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQogPj4gRnJvbTogbHNyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsc3ItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEplZmYKID4+IFRhbnRzdXJhCiA+PiBTZW50OiBGcmlkYXksIE9j dG9iZXIgMTYsIDIwMjAgNToyOCBBTQogPj4gVG86IEpvaG4gRSBEcmFrZSA8amRyYWtlPTQwanVu aXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+CiA+PiBDYzogQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNA Y2hvcHBzLm9yZz47IGxzci1jaGFpcnNAaWV0Zi5vcmc7IExlcyBHaW5zYmVyZwogPj4gKGdpbnNi ZXJnKSA8Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+OyBsc3JAaWV0Zi5vcmc7 IGxzci0KID4+IGFkc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2lu YXRvckBpZXRmLm9yZwogPj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbCBkcmFmdC1p ZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2CiA+PiAKID4+ICsxCiA+PiAKID4+IFJl Z2FyZHMsCiA+PiBKZWZmCiA+PiAKID4+PiBPbiBPY3QgMTUsIDIwMjAsIGF0IDExOjMzLCBKb2hu IEUgRHJha2UKID4+IDxqZHJha2U9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6 CiA+Pj4gCiA+Pj4g77u/SGksCiA+Pj4gCiA+Pj4gSSBhZ3JlZSB3aXRoIExlcy4gIFRoaXMgaXMg YSBzaW1wbGUgcHJvdG9jb2wgZXh0ZW5zaW9uIGZvciBhIHNwZWNpZmljIHB1cnBvc2UKID4+IGFu ZCB0aGVyZSBpcyBubyByZWFzb24gdG8gaW5jbHVkZSBzcGVjdWxhdGlvbiBhYm91dCBpdHMgdXNl IGZvciBvdGhlcgogPj4gcHVycG9zZXMsIHBhcnRpY3VsYXJseSB3aGVuIGl0IGlzIGluaGVyZW50 bHkgbm90IHN1aXRlZCBmb3IgdGhlbS4KID4+PiAKID4+PiBZb3VycyBJcnJlc3BlY3RpdmVseSwK ID4+PiAKID4+PiBKb2huCiA+Pj4gCiA+Pj4gCiA+Pj4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25s eQogPj4+IAogPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQogPj4+PiBGcm9tOiBMc3Ig PGxzci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTGVzIEdpbnNiZXJnIChnaW5zYmVy ZykKID4+Pj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTUsIDIwMjAgMTI6MzMgUE0KID4+Pj4g VG86IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBsc3JAaWV0Zi5vcmcKID4+ Pj4gQ2M6IGxzci1jaGFpcnNAaWV0Zi5vcmc7IGxzci1hZHNAaWV0Zi5vcmc7CiA+Pj4+IGRyYWZ0 LWlldGYtbHNyLW9zcGYtcHJlZml4LSBvcmlnaW5hdG9yQGlldGYub3JnCiA+Pj4+IFN1YmplY3Q6 IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwKID4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgt b3JpZ2luYXRvci0wNgogPj4+PiAKID4+Pj4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBv ZiBjb250ZW50XQogPj4+PiAKID4+Pj4gCiA+Pj4+IEkgc3VwcG9ydCBtb3ZpbmcgdGhpcyBkb2N1 bWVudCBmb3J3YXJkLgogPj4+PiBTaW1pbGFyIGZ1bmN0aW9uYWxpdHkgaW4gSVMtSVMgaGFzIHBy b3ZlZCB1c2VmdWwuCiA+Pj4+IAogPj4+PiBJIHdvdWxkIGhvd2V2ZXIgbGlrZSB0byByZXBlYXQg Y29tbWVudHMgSSBtYWRlIGVhcmxpZXIgaW4gdGhlIHJldmlldwogPj4+PiBvZiB0aGlzIGRvY3Vt ZW50LgogPj4+PiBUaGUgY29udGVudCBvZiB0aGUgQXBwZW5kaWNlcyBzaG91bGQgYmUgcmVtb3Zl ZC4KID4+Pj4gVGhlIEFwcGVuZGljZXMgZGVmaW5lIGFuZCBkaXNjdXNzIGRlcml2aW5nIHRvcG9s b2d5IGluZm9ybWF0aW9uIGZyb20KID4+Pj4gcHJlZml4IGFkdmVydGlzZW1lbnRzIC0gd2hpY2gg aXMgZmxhd2VkIGFuZCBzaG91bGQgbm90IGJlIGRvbmUuCiA+Pj4+IFBlcmhhcHMgbW9yZSByZWxl dmFudCwgdGhlIHB1cnBvc2Ugb2YgdGhlIGRvY3VtZW50IGlzIHRvIGRlZmluZQogPj4+PiBwcm90 b2NvbCBleHRlbnNpb25zIHN1cHBvcnRpbmcgYWR2ZXJ0aXNlbWVudCBvZiB0aGUgb3JpZ2luYXRv cnMgb2YgYQogPj4+PiBwcmVmaXggYWR2ZXJ0aXNlbWVudC4gVGhlcmUgaXMgbm8gbmVlZCB0byBk aXNjdXNzIGhvdyB0aGlzIG1lY2hhbmlzbQogPj4+PiBtaWdodCBiZSB1c2VkIHRvIGJ1aWxkIHRv cG9sb2d5IGluZm9ybWF0aW9uLgogPj4+PiBUaGlzIGRvY3VtZW50IHNob3VsZCBjb25maW5lIGl0 c2VsZiB0byBkZWZpbmluZyB0aGUgcHJvdG9jb2wKID4+Pj4gZXh0ZW5zaW9ucyAtIHNpbWlsYXIg dGhlIFJGQyA3Nzk0LgogPj4+PiAKID4+Pj4gSWYgdGhlIGF1dGhvcnMgZG8gbm90IGFncmVlIHRv IGRvIHRoaXMsIEkgd291bGQgZW5jb3VyYWdlIHRoaXMgcG9pbnQKID4+Pj4gdG8gYmUgZGlzY3Vz c2VkIGR1cmluZyBJRVNHIHJldmlldy4KID4+Pj4gCiA+Pj4+ICBMZXMKID4+Pj4gCiA+Pj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQogPj4+Pj4gRnJvbTogTHNyIDxsc3ItYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIENocmlzdGlhbiBIb3BwcwogPj4+Pj4gU2VudDogV2VkbmVz ZGF5LCBPY3RvYmVyIDE0LCAyMDIwIDExOjE1IFBNCiA+Pj4+PiBUbzogbHNyQGlldGYub3JnCiA+ Pj4+PiBDYzogZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZzsK ID4+Pj4+IGxzci1jaGFpcnNAaWV0Zi5vcmc7IGxzci0gYWRzQGlldGYub3JnOyBDaHJpc3RpYW4g SG9wcHMKID4+Pj4+IDxjaG9wcHNAY2hvcHBzLm9yZz4KID4+Pj4+IFN1YmplY3Q6IFtMc3JdIFdH IExhc3QgQ2FsbCBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2CiA+Pj4+ PiAKID4+Pj4+IFRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExhc3QgQ2FsbCwgZW5kaW5nIGFmdGVy IE9jdCAyOXRoLCAyMDIwLCBmb3I6CiA+Pj4+PiAKID4+Pj4+IAogPj4+Pj4gaHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWkK ID4+Pj4+IGV0CiA+Pj4+PiBmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yL19fOyEhTkV0NnlN YU8tCiA+PiBnayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxCiA+Pj4+PiBoSyA4cDAzRmczTDlMdUNH WHc4QzBYNnFSUWRySGpLREtIY2prakNscGskCiA+Pj4+PiAKID4+Pj4+IFRoZSBmb2xsb3dpbmcg SVBSIGhhcyBiZWVuIGZpbGVkCiA+Pj4+PiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMzQ0OC9fXzshCiA+Pj4+PiAhTkV0NnlNYU8t CiA+Pj4+IGdrIVRhU3pRVGhnaHRDRk91WVBTMlZqTHFoSzhwMDNGZzNMOUx1Q0dYdzhDMFg2cVJR ZHJIaktES0hjegogPj4+Pj4gNUt0VUhRJAogPj4+Pj4gCiA+Pj4+PiBBdXRob3JzLAogPj4+Pj4g CiA+Pj4+PiBQbGVhc2UgaW5kaWNhdGUgdG8gdGhlIGxpc3QsIHlvdXIga25vd2xlZGdlIG9mIGFu eSBvdGhlciBJUFIKID4+Pj4+IHJlbGF0ZWQgdG8gdGhpcyB3b3JrLgogPj4+Pj4gCiA+Pj4+PiBU aGFua3MsCiA+Pj4+PiBDaHJpcy4KID4+Pj4gCiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCiA+Pj4+IExzciBtYWlsaW5nIGxpc3QKID4+Pj4gTHNy QGlldGYub3JnCiA+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcgogPj4+PiBfXzshIU5FdAogPj4+PiA2eU1hTy0K ID4+Pj4gCiA+PiBnayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxaEs4cDAzRmczTDlMdUNHWHc4QzBY NnFSUWRySGpLREtIY1VkbQogPj4gdzgKID4+Pj4gTGMkCiA+Pj4gCiA+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KID4+PiBMc3IgbWFpbGluZyBsaXN0 CiA+Pj4gTHNyQGlldGYub3JnCiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sc3IKID4+IAogPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KID4+IExzciBtYWlsaW5nIGxpc3QKID4+IExzckBpZXRmLm9yZwogPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3IKID4gCiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiA+IExzciBtYWlsaW5nIGxpc3QKID4g THNyQGlldGYub3JnCiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNy CgoKCgoKDQoNCg== --=_Part_912019_758899990.1602859073007 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGJyPkhpLCBDaHJpczombmJzcDs8ZGl2Pk9yaWdpbmFsbHksIHRoZSBhcHBlbmRpeCBwYXJ0IGlz IHdpdGhpbiB0aGUgZG9jdW1lbnQsIHdoaWNoIGlzIHRoZSBzdGFydCBwb2ludC9tYWluIG1vdGl2 YXRpb24gdG8gZXh0ZW5kIHRoZSBwcmVmaXggb3JpZ2luLjwvZGl2PjxkaXY+VGhlcmUgbWF5IGV4 aXN0cyBvdGhlciB1c2FnZXMgb2YgdGhpcyBpbmZvcm1hdGlvbi4gUGFjayB0aGVzZSBleGFtcGxl cyBpbnRvIHNvbWUgc2hvcnQgc2VudGVuY2VzIG9yIGludHJvZHVjdGlvbiBpcyB2aWFibGUsIGJ1 dCBleHBhbmQgc29tZSBvZiB0aGVtIGlzIGFsc28gaGVscGZ1bC48ZGl2PkFzIEkga25vd24sIHdo ZW4gd2Ugd2FudCB0byBkbyBwcm90b2NvbCBleHRlbnNpb24sIHdlIHNob3VsZCAmbmJzcDthbHdh eXMgY29udmluY2Ugb3RoZXIgdGhlIHJlYXNvbi9tb3RpdmF0aW9uL3Byb3NwZWN0cyB0byBkbyBz by4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSB1c2UgY2FzZSBkZXNjcmliZWQgaW4gdGhlIGN1cnJl bnQgYXBwZW5kaXggaXMgdmVyeSBwcm9taW5lbnQgZm9yIG9wZXJhdG9yIHRvIGFjY29tcGxpc2gg dGhlIFRFIHRhc2sgaW4gbXVsdGktYXJlYSBlbnZpcm9ubWVudC48L2Rpdj48ZGl2Pjxicj48ZGl2 IGlkPSJzcG5FZGl0b3JTaWduX2FwcCI+QWlqdW4gV2FuZzwvZGl2Pgo8YnI+5ZyoMjAyMC0xMC0x Nu+8jENocmlzdGlhbiZuYnNwO0hvcHBzJm5ic3A7JmFtcDtsdDtjaG9wcHNAY2hvcHBzLm9yZyZh bXA7Z3Q75YaZ6YGTOgo8YnI+LS0tLS3ljp/lp4vpgq7ku7YtLS0tLQo8YnI+5Y+R5Lu25Lq677ya Jm5ic3A7Q2hyaXN0aWFuJm5ic3A7SG9wcHMmbmJzcDsmYW1wO2x0O2Nob3Bwc0BjaG9wcHMub3Jn JmFtcDtndDsKPGJyPuWPkeS7tuaXtumXtDombmJzcDsyMDIw5bm0MTDmnIgxNuaXpSZuYnNwO+aY n+acn+S6lAo8YnI+5YaZ6YGTOiZuYnNwO1smYW1wO3F1b3Q7TGVzJm5ic3A7R2luc2JlcmcmbmJz cDsoZ2luc2JlcmcpJmFtcDtxdW90OyZuYnNwOyZhbXA7bHQ7Z2luc2Jlcmc9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmcmYW1wO2d0O10KPGJyPuS4u+mimO+8miZuYnNwO1JlOiZuYnNwO1tMc3Jd Jm5ic3A7V0cmbmJzcDtMYXN0Jm5ic3A7Q2FsbCZuYnNwO2RyYWZ0LWlldGYtbHNyLW9zcGYtcHJl Zml4LW9yaWdpbmF0b3ItMDYKPGJyPgo8YnI+Jmd0OyZuYnNwO09uJm5ic3A7T2N0Jm5ic3A7MTYs Jm5ic3A7MjAyMCwmbmJzcDthdCZuYnNwOzE6NTEmbmJzcDtBTSwmbmJzcDtMZXMmbmJzcDtHaW5z YmVyZyZuYnNwOyhnaW5zYmVyZykmbmJzcDsmbHQ7Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmcmZ3Q7Jm5ic3A7d3JvdGU6Cjxicj4mZ3Q7Jm5ic3A7Cjxicj4mZ3Q7Jm5ic3A7QWlq dW4mbmJzcDstCjxicj4mZ3Q7Jm5ic3A7Cjxicj4mZ3Q7Jm5ic3A7VGhlJm5ic3A7cG9pbnQmbmJz cDtJJm5ic3A7YW0mbmJzcDttYWtpbmcmbmJzcDtpcyZuYnNwO3ZlcnkmbmJzcDtmb2N1c2VkLgo8 YnI+Jmd0OyZuYnNwOwo8YnI+Jmd0OyZuYnNwO1RoaXMmbmJzcDtkcmFmdCZuYnNwO2lzJm5ic3A7 ZGVmaW5pbmcmbmJzcDthJm5ic3A7cHJvdG9jb2wmbmJzcDtleHRlbnNpb24uJm5ic3A7QXMmbmJz cDtzdWNoJm5ic3A7aXQmbmJzcDtpcyZuYnNwO25lY2Vzc2FyeSZuYnNwO3RoYXQmbmJzcDt0aGlz Jm5ic3A7YmUmbmJzcDtTdGFuZGFyZHMmbmJzcDt0cmFjayZuYnNwO2FzJm5ic3A7YWRoZXJpbmcm bmJzcDt0byZuYnNwO3RoZSZuYnNwO25vcm1hdGl2ZSZuYnNwO3N0YXRlbWVudHMmbmJzcDtpbiZu YnNwO3RoZSZuYnNwO2RyYWZ0Jm5ic3A7YXJlJm5ic3A7bmVjZXNzYXJ5Jm5ic3A7Zm9yJm5ic3A7 aW50ZXJvcGVyYWJpbGl0eS4KPGJyPiZndDsmbmJzcDsKPGJyPiZndDsmbmJzcDtXaGF0Jm5ic3A7 aXMmbmJzcDtkaXNjdXNzZWQmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO0FwcGVuZGl4Jm5ic3A7aXMm bmJzcDthJm5ic3A7dXNlJm5ic3A7Y2FzZS4mbmJzcDtJdCZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7 bm9ybWF0aXZlJm5ic3A7YW5kJm5ic3A7dGhlcmUmbmJzcDthcmUmbmJzcDtzdHJvbmcmbmJzcDtv cGluaW9ucyZuYnNwO29uJm5ic3A7Ym90aCZuYnNwO3NpZGVzJm5ic3A7YXMmbmJzcDt0byZuYnNw O3doZXRoZXImbmJzcDt0aGlzJm5ic3A7aXMmbmJzcDthbiZuYnNwO2FwcHJvcHJpYXRlJm5ic3A7 dXNlJm5ic3A7Y2FzZSZuYnNwO29yJm5ic3A7bm90Lgo8YnI+Jmd0OyZuYnNwO0luJm5ic3A7dGhl Jm5ic3A7Y29udGV4dCZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2RyYWZ0LCZuYnNwO0kmbmJzcDto YXZlJm5ic3A7bm8mbmJzcDtpbnRlcmVzdCZuYnNwO2luJm5ic3A7dHJ5aW5nJm5ic3A7dG8mbmJz cDtyZXNvbHZlJm5ic3A7b3VyJm5ic3A7ZGlmZmVyZW5jZSZuYnNwO29mJm5ic3A7b3BpbmlvbiZu YnNwO29uJm5ic3A7dGhpcyZuYnNwO3VzZSZuYnNwO2Nhc2UuJm5ic3A7SSZuYnNwO3NpbXBseSZu YnNwO3dhbnQmbmJzcDt0aGUmbmJzcDtwcm90b2NvbCZuYnNwO2V4dGVuc2lvbiZuYnNwO3RvJm5i c3A7bW92ZSZuYnNwO2ZvcndhcmQmbmJzcDtzbyZuYnNwO3RoYXQmbmJzcDt3ZSZuYnNwO2hhdmUm bmJzcDthbm90aGVyJm5ic3A7dG9vbCZuYnNwO2F2YWlsYWJsZS4KPGJyPiZndDsmbmJzcDsKPGJy PiZndDsmbmJzcDtJZiZuYnNwO3lvdSZuYnNwO3dhbnQmbmJzcDt0byZuYnNwO3dyaXRlJm5ic3A7 YSZuYnNwO2RyYWZ0Jm5ic3A7b24mbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtjYXNlJm5ic3A7ZGlz Y3Vzc2VkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtBcHBlbmRpeCZuYnNwO3BsZWFzZSZuYnNwO2Zl ZWwmbmJzcDtmcmVlJm5ic3A7dG8mbmJzcDtkbyZuYnNwO3NvLiZuYnNwO1RoYXQmbmJzcDtkcmFm dCZuYnNwO21heSZuYnNwO3ZlcnkmbmJzcDt3ZWxsJm5ic3A7bm90Jm5ic3A7YmUmbmJzcDtub3Jt YXRpdmUmbmJzcDstJm5ic3A7SW5mb3JtYXRpb25hbCZuYnNwO29yJm5ic3A7QkNQJm5ic3A7bWF5 Jm5ic3A7YmUmbmJzcDttb3JlJm5ic3A7YXBwcm9wcmlhdGUmbmJzcDstJm5ic3A7YmVjYXVzZSZu YnNwO2l0Jm5ic3A7d2lsbCZuYnNwO2JlJm5ic3A7ZGlzY3Vzc2luZyZuYnNwO2EmbmJzcDtkZXBs b3ltZW50Jm5ic3A7c2NlbmFyaW8mbmJzcDthbmQmbmJzcDthJm5ic3A7cHJvcG9zYWwmbmJzcDt0 byZuYnNwO3VzZSZuYnNwO2RlZmluZWQmbmJzcDtwcm90b2NvbCZuYnNwO2V4dGVuc2lvbnMmbmJz cDthcyZuYnNwO29uZSZuYnNwO3dheSZuYnNwO3RvJm5ic3A7c29sdmUmbmJzcDtwcm9ibGVtcyZu YnNwO2luJm5ic3A7dGhhdCZuYnNwO2RlcGxveW1lbnQmbmJzcDtzY2VuYXJpby4mbmJzcDtTdWNo Jm5ic3A7YSZuYnNwO2RyYWZ0Jm5ic3A7bWlnaHQmbmJzcDthbHNvJm5ic3A7YmUmbmJzcDttb3Jl Jm5ic3A7YXBwcm9wcmlhdGUmbmJzcDtpbiZuYnNwO2Fub3RoZXImbmJzcDtXRyZuYnNwOyhlLmcu LCZuYnNwO1RFQVMpLiZuYnNwO1RoZSZuYnNwO21lcml0cyZuYnNwO29mJm5ic3A7dXNpbmcmbmJz cDtwcmVmaXgmbmJzcDthZHZlcnRpc2VtZW50cyZuYnNwO3RvJm5ic3A7YnVpbGQmbmJzcDthJm5i c3A7dG9wb2xvZ3kmbmJzcDtjb3VsZCZuYnNwO3RoZW4mbmJzcDtiZSZuYnNwO2Rpc2N1c3NlZCZu YnNwO29uJm5ic3A7aXRzJm5ic3A7b3duLgo8YnI+Jmd0OyZuYnNwOwo8YnI+Jmd0OyZuYnNwO1Bs ZWFzZSZuYnNwO2RvJm5ic3A7bm90Jm5ic3A7dHJ5Jm5ic3A7dG8mbmJzcDthdm9pZCZuYnNwO2hh dmluZyZuYnNwO2EmbmJzcDtmdWxsJm5ic3A7ZGlzY3Vzc2lvbiZuYnNwO29mJm5ic3A7dGhlJm5i c3A7bWVyaXRzJm5ic3A7b2YmbmJzcDt1c2luZyZuYnNwO3ByZWZpeCZuYnNwO2FkdmVydGlzZW1l bnRzJm5ic3A7dG8mbmJzcDtkZXJpdmUmbmJzcDt0b3BvbG9neSZuYnNwO2J5Jm5ic3A7YWRkaW5n Jm5ic3A7aXQmbmJzcDt0byZuYnNwO2EmbmJzcDtkcmFmdCZuYnNwO3RoYXQmbmJzcDtpcyZuYnNw OyhhbmQmbmJzcDtzaG91bGQmbmJzcDtiZSkmbmJzcDtmb2N1c2VkJm5ic3A7b24mbmJzcDtzaW1w bGUmbmJzcDtwcm90b2NvbCZuYnNwO2V4dGVuc2lvbnMuCjxicj4KPGJyPltBcyZuYnNwO1dHJm5i c3A7bWVtYmVyXQo8YnI+Cjxicj5JJm5ic3A7ZmluZCZuYnNwO3RoaXMmbmJzcDt2ZXJ5Jm5ic3A7 Y29tcGVsbGluZyZuYnNwO2FuZCZuYnNwO3NvJm5ic3A7c3VwcG9ydCZuYnNwO3RoZSZuYnNwO3Jl bW92YWwmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3JlZmVycmVkJm5ic3A7dG8mbmJzcDtub24tbm9y bWF0aXZlJm5ic3A7YXBwZW5kaWNlcy4KPGJyPgo8YnI+VGhhbmtzLAo8YnI+Q2hyaXMuCjxicj4K PGJyPiZndDsmbmJzcDsKPGJyPiZndDsmbmJzcDtUaGFueC4KPGJyPiZndDsmbmJzcDsKPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDtMZXMKPGJyPiZndDsmbmJzcDsKPGJyPiZndDsmbmJzcDsKPGJy PiZndDsmZ3Q7Jm5ic3A7LS0tLS1PcmlnaW5hbCZuYnNwO01lc3NhZ2UtLS0tLQo8YnI+Jmd0OyZn dDsmbmJzcDtGcm9tOiZuYnNwO0FpanVuJm5ic3A7V2FuZyZuYnNwOyZsdDt3YW5nYWlqdW5AdHNp bmdodWEub3JnLmNuJmd0Owo8YnI+Jmd0OyZndDsmbmJzcDtTZW50OiZuYnNwO1RodXJzZGF5LCZu YnNwO09jdG9iZXImbmJzcDsxNSwmbmJzcDsyMDIwJm5ic3A7Njo1MSZuYnNwO1BNCjxicj4mZ3Q7 Jmd0OyZuYnNwO1RvOiZuYnNwOydKZWZmJm5ic3A7VGFudHN1cmEnJm5ic3A7Jmx0O2plZmZ0YW50 LmlldGZAZ21haWwuY29tJmd0OzsmbmJzcDsnSm9obiZuYnNwO0UmbmJzcDtEcmFrZScKPGJyPiZn dDsmZ3Q7Jm5ic3A7Jmx0O2pkcmFrZUBqdW5pcGVyLm5ldCZndDsKPGJyPiZndDsmZ3Q7Jm5ic3A7 Q2M6Jm5ic3A7J0NocmlzdGlhbiZuYnNwO0hvcHBzJyZuYnNwOyZsdDtjaG9wcHNAY2hvcHBzLm9y ZyZndDs7Jm5ic3A7bHNyLWNoYWlyc0BpZXRmLm9yZzsmbmJzcDtMZXMmbmJzcDtHaW5zYmVyZwo8 YnI+Jmd0OyZndDsmbmJzcDsoZ2luc2JlcmcpJm5ic3A7Jmx0O2dpbnNiZXJnQGNpc2NvLmNvbSZn dDs7Jm5ic3A7bHNyQGlldGYub3JnOyZuYnNwO2xzci1hZHNAaWV0Zi5vcmc7Jm5ic3A7ZHJhZnQt aWV0Zi0KPGJyPiZndDsmZ3Q7Jm5ic3A7bHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5v cmcKPGJyPiZndDsmZ3Q7Jm5ic3A7U3ViamVjdDombmJzcDtSRTombmJzcDtbTHNyXSZuYnNwO1dH Jm5ic3A7TGFzdCZuYnNwO0NhbGwmbmJzcDtkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmln aW5hdG9yLTA2Cjxicj4mZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZndDsmbmJzcDtIaSwmbmJzcDtM ZXMsJm5ic3A7Sm9obiZuYnNwO2FuZCZuYnNwO0plZmY6Cjxicj4mZ3Q7Jmd0OyZuYnNwOwo8YnI+ Jmd0OyZndDsmbmJzcDtMZXQncyZuYnNwO3JlcGx5Jm5ic3A7eW91Jm5ic3A7YWxsJm5ic3A7dG9n ZXRoZXIuCjxicj4mZ3Q7Jmd0OyZuYnNwO0luJm5ic3A7bXkmbmJzcDtQT1YsJm5ic3A7VGhlJm5i c3A7c3RhbmRhcmQmbmJzcDtkb2N1bWVudCZuYnNwO3Nob3VsZCZuYnNwO25vdCZuYnNwO2RlZmlu ZSZuYnNwO3NvbGVseSZuYnNwO3RoZSZuYnNwO3Byb3RvY29sCjxicj4mZ3Q7Jmd0OyZuYnNwO2V4 dGVuc2lvbiwmbmJzcDtidXQmbmJzcDt0aGVpciZuYnNwO3VzYWdlcyZuYnNwO2luJm5ic3A7dGhl Jm5ic3A7bmV0d29yayZuYnNwO2RlcGxveW1lbnQuJm5ic3A7QXMmbmJzcDtJJm5ic3A7a25vd24s Jm5ic3A7YWxtb3N0Cjxicj4mZ3Q7Jmd0OyZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO0lFVEYmbmJz cDtkb2N1bWVudHMmbmJzcDtmb2xsb3dpbmcmbmJzcDt0aGlzJm5ic3A7c3R5bGUuCjxicj4mZ3Q7 Jmd0OyZuYnNwO0FuZCwmbmJzcDtiZWZvcmUmbmJzcDthZG9wdGluZyZuYnNwO29uZSZuYnNwO3dv cmssJm5ic3A7d2UmbmJzcDtoYXZlJm5ic3A7b2Z0ZW4mbmJzcDtpbnRlbnNlJm5ic3A7ZGlzY3Vz c2lvbiZuYnNwO2ZvciZuYnNwO3doYXQncwo8YnI+Jmd0OyZndDsmbmJzcDt0aGVpciZuYnNwO3Vz YWdlcy4KPGJyPiZndDsmZ3Q7Jm5ic3A7U3VjaCZuYnNwO2Rpc2N1c3Npb24mbmJzcDtpbiZuYnNw O3RoZSZuYnNwO21haWwmbmJzcDtsaXN0Jm5ic3A7YW5kJm5ic3A7c3RhdGVtZW50cyZuYnNwO2lu Jm5ic3A7dGhlJm5ic3A7ZG9jdW1lbnQmbmJzcDtjYW4mbmJzcDtjZXJ0YWlubHkKPGJyPiZndDsm Z3Q7Jm5ic3A7YXNzaXN0Jm5ic3A7dGhlJm5ic3A7cmVhZGVyL3VzZXImbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO2RvY3VtZW50Jm5ic3A7Z2V0Jm5ic3A7dGhlJm5ic3A7ZXNzZW5jZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7c3RhbmRhcmQsJm5ic3A7YW5kCjxicj4mZ3Q7Jmd0OyZuYnNwO2ZvbGxvdyZu YnNwO3RoZW0mbmJzcDt1bmFtYmlndW91c2x5Lgo8YnI+Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsm Z3Q7Jm5ic3A7UmVnYXJkaW5nJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO2Fw cGVuZGljZXMsJm5ic3A7YXMmbmJzcDtzdGF0ZWQmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3NlY3Rp b24sJm5ic3A7IlRoZQo8YnI+Jmd0OyZndDsmbmJzcDtBcHBlbmRpeCZuYnNwO0EmbmJzcDtoZXVy aXN0aWMmbmJzcDt0byZuYnNwO3JlYnVpbGQmbmJzcDt0aGUmbmJzcDt0b3BvbG9neSZuYnNwO2Nh biZuYnNwO25vcm1hbGx5Jm5ic3A7YmUmbmJzcDt1c2VkJm5ic3A7aWYmbmJzcDthbGwmbmJzcDts aW5rcwo8YnI+Jmd0OyZndDsmbmJzcDthcmUmbmJzcDtudW1iZXJlZC4iJm5ic3A7SSZuYnNwO3Ro aW5rJm5ic3A7dGhpcyZuYnNwO2NhbiZuYnNwO2FwcGx5Jm5ic3A7YWxtb3N0Jm5ic3A7bW9zdCZu YnNwO29mJm5ic3A7dGhlJm5ic3A7b3BlcmF0b3IncyZuYnNwO25ldHdvcmssCjxicj4mZ3Q7Jmd0 OyZuYnNwO2FuZCZuYnNwO2ZhY2lsaXRhdGUmbmJzcDt0aGUmbmJzcDtpbnRlci1hcmVhJm5ic3A7 VEUmbmJzcDtwYXRoJm5ic3A7Y2FsY3VsYXRpb24mbmJzcDtmb3ImbmJzcDtjZW50cmFsJm5ic3A7 Y29udHJvbGxlciwmbmJzcDtvciZuYnNwO2V2ZW4KPGJyPiZndDsmZ3Q7Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7aGVhZC1lbmQmbmJzcDtyb3V0ZXImbmJzcDt0aGF0Jm5ic3A7bG9jYXRlZCZuYnNw O2luJm5ic3A7b25lJm5ic3A7YXJlYSZuYnNwO3RoYXQmbmJzcDtkaWZmZXJlbnQmbmJzcDtmcm9t Jm5ic3A7dGhlJm5ic3A7dGFpbC0KPGJyPiZndDsmZ3Q7Jm5ic3A7ZW5kJm5ic3A7cm91dGVyLgo8 YnI+Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsmZ3Q7Jm5ic3A7S2VlcGluZyZuYnNwO3RoZSZuYnNw O2NvbnRlbnRzJm5ic3A7b2YmbmJzcDthcHBlbmRpY2VzJm5ic3A7ZG9lcyZuYnNwO25vdCZuYnNw O2hhdmUmbmJzcDt0aGUmbmJzcDtuZWdhdGl2ZSZuYnNwO2ltcGFjdCZuYnNwO29mCjxicj4mZ3Q7 Jmd0OyZuYnNwO3RoZSZuYnNwO3Byb3RvY29sJm5ic3A7ZXh0ZW5zaW9uLCZuYnNwO2l0Jm5ic3A7 aXMmbmJzcDtqdXN0Jm5ic3A7b25lJm5ic3A7cmVmZXJlbmNlJm5ic3A7Zm9yJm5ic3A7dGhlJm5i c3A7dXNhZ2UmbmJzcDtvZiZuYnNwO3RoaXMKPGJyPiZndDsmZ3Q7Jm5ic3A7ZXh0ZW5zaW9uLgo8 YnI+Jmd0OyZndDsmbmJzcDtPbmUmbmJzcDtjYW4mbmJzcDtzZWxlY3QmbmJzcDtub3QmbmJzcDty ZWZlciZuYnNwO3RvJm5ic3A7aXQsJm5ic3A7aWYmbmJzcDt0aGVpciZuYnNwO25ldHdvcmtzJm5i c3A7YXJlJm5ic3A7ZGVwbG95ZWQmbmJzcDt3aXRoJm5ic3A7bGFyZ2UKPGJyPiZndDsmZ3Q7Jm5i c3A7YW1vdW50Jm5ic3A7b2YmbmJzcDt1bm51bWJlcmVkJm5ic3A7bGlua3MuJm5ic3A7QnV0Jm5i c3A7Zm9yJm5ic3A7b3RoZXJzLCZuYnNwO3RoZSZuYnNwO2hldXJpc3RpYyZuYnNwO2FwcGxpZXMu Cjxicj4mZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZndDsmbmJzcDtCZXN0Jm5ic3A7UmVnYXJkcwo8 YnI+Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsmZ3Q7Jm5ic3A7QWlqdW4mbmJzcDtXYW5nCjxicj4m Z3Q7Jmd0OyZuYnNwO0NoaW5hJm5ic3A7VGVsZWNvbQo8YnI+Jmd0OyZndDsmbmJzcDsKPGJyPiZn dDsmZ3Q7Jm5ic3A7Cjxicj4mZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZndDsmbmJzcDstLS0tLU9y aWdpbmFsJm5ic3A7TWVzc2FnZS0tLS0tCjxicj4mZ3Q7Jmd0OyZuYnNwO0Zyb206Jm5ic3A7bHNy LWJvdW5jZXNAaWV0Zi5vcmcmbmJzcDtbbWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnXSZuYnNw O09uJm5ic3A7QmVoYWxmJm5ic3A7T2YmbmJzcDtKZWZmCjxicj4mZ3Q7Jmd0OyZuYnNwO1RhbnRz dXJhCjxicj4mZ3Q7Jmd0OyZuYnNwO1NlbnQ6Jm5ic3A7RnJpZGF5LCZuYnNwO09jdG9iZXImbmJz cDsxNiwmbmJzcDsyMDIwJm5ic3A7NToyOCZuYnNwO0FNCjxicj4mZ3Q7Jmd0OyZuYnNwO1RvOiZu YnNwO0pvaG4mbmJzcDtFJm5ic3A7RHJha2UmbmJzcDsmbHQ7amRyYWtlPTQwanVuaXBlci5uZXRA ZG1hcmMuaWV0Zi5vcmcmZ3Q7Cjxicj4mZ3Q7Jmd0OyZuYnNwO0NjOiZuYnNwO0NocmlzdGlhbiZu YnNwO0hvcHBzJm5ic3A7Jmx0O2Nob3Bwc0BjaG9wcHMub3JnJmd0OzsmbmJzcDtsc3ItY2hhaXJz QGlldGYub3JnOyZuYnNwO0xlcyZuYnNwO0dpbnNiZXJnCjxicj4mZ3Q7Jmd0OyZuYnNwOyhnaW5z YmVyZykmbmJzcDsmbHQ7Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7OyZu YnNwO2xzckBpZXRmLm9yZzsmbmJzcDtsc3ItCjxicj4mZ3Q7Jmd0OyZuYnNwO2Fkc0BpZXRmLm9y ZzsmbmJzcDtkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnCjxi cj4mZ3Q7Jmd0OyZuYnNwO1N1YmplY3Q6Jm5ic3A7UmU6Jm5ic3A7W0xzcl0mbmJzcDtXRyZuYnNw O0xhc3QmbmJzcDtDYWxsJm5ic3A7ZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRv ci0wNgo8YnI+Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsmZ3Q7Jm5ic3A7KzEKPGJyPiZndDsmZ3Q7 Jm5ic3A7Cjxicj4mZ3Q7Jmd0OyZuYnNwO1JlZ2FyZHMsCjxicj4mZ3Q7Jmd0OyZuYnNwO0plZmYK PGJyPiZndDsmZ3Q7Jm5ic3A7Cjxicj4mZ3Q7Jmd0OyZndDsmbmJzcDtPbiZuYnNwO09jdCZuYnNw OzE1LCZuYnNwOzIwMjAsJm5ic3A7YXQmbmJzcDsxMTozMywmbmJzcDtKb2huJm5ic3A7RSZuYnNw O0RyYWtlCjxicj4mZ3Q7Jmd0OyZuYnNwOyZsdDtqZHJha2U9NDBqdW5pcGVyLm5ldEBkbWFyYy5p ZXRmLm9yZyZndDsmbmJzcDt3cm90ZToKPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZn dDsmZ3Q7Jm5ic3A777u/SGksCjxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsmZ3Q7Jmd0 OyZuYnNwO0kmbmJzcDthZ3JlZSZuYnNwO3dpdGgmbmJzcDtMZXMuJm5ic3A7Jm5ic3A7VGhpcyZu YnNwO2lzJm5ic3A7YSZuYnNwO3NpbXBsZSZuYnNwO3Byb3RvY29sJm5ic3A7ZXh0ZW5zaW9uJm5i c3A7Zm9yJm5ic3A7YSZuYnNwO3NwZWNpZmljJm5ic3A7cHVycG9zZQo8YnI+Jmd0OyZndDsmbmJz cDthbmQmbmJzcDt0aGVyZSZuYnNwO2lzJm5ic3A7bm8mbmJzcDtyZWFzb24mbmJzcDt0byZuYnNw O2luY2x1ZGUmbmJzcDtzcGVjdWxhdGlvbiZuYnNwO2Fib3V0Jm5ic3A7aXRzJm5ic3A7dXNlJm5i c3A7Zm9yJm5ic3A7b3RoZXIKPGJyPiZndDsmZ3Q7Jm5ic3A7cHVycG9zZXMsJm5ic3A7cGFydGlj dWxhcmx5Jm5ic3A7d2hlbiZuYnNwO2l0Jm5ic3A7aXMmbmJzcDtpbmhlcmVudGx5Jm5ic3A7bm90 Jm5ic3A7c3VpdGVkJm5ic3A7Zm9yJm5ic3A7dGhlbS4KPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOwo8 YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7WW91cnMmbmJzcDtJcnJlc3BlY3RpdmVseSwKPGJyPiZndDsm Z3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Sm9obgo8YnI+Jmd0OyZndDsmZ3Q7 Jm5ic3A7Cjxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsmZ3Q7Jmd0OyZuYnNwO0p1bmlw ZXImbmJzcDtCdXNpbmVzcyZuYnNwO1VzZSZuYnNwO09ubHkKPGJyPiZndDsmZ3Q7Jmd0OyZuYnNw Owo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOy0tLS0tT3JpZ2luYWwmbmJzcDtNZXNzYWdlLS0t LS0KPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtGcm9tOiZuYnNwO0xzciZuYnNwOyZsdDtsc3It Ym91bmNlc0BpZXRmLm9yZyZndDsmbmJzcDtPbiZuYnNwO0JlaGFsZiZuYnNwO09mJm5ic3A7TGVz Jm5ic3A7R2luc2JlcmcmbmJzcDsoZ2luc2JlcmcpCjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 U2VudDombmJzcDtUaHVyc2RheSwmbmJzcDtPY3RvYmVyJm5ic3A7MTUsJm5ic3A7MjAyMCZuYnNw OzEyOjMzJm5ic3A7UE0KPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtUbzombmJzcDtDaHJpc3Rp YW4mbmJzcDtIb3BwcyZuYnNwOyZsdDtjaG9wcHNAY2hvcHBzLm9yZyZndDs7Jm5ic3A7bHNyQGll dGYub3JnCjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Q2M6Jm5ic3A7bHNyLWNoYWlyc0BpZXRm Lm9yZzsmbmJzcDtsc3ItYWRzQGlldGYub3JnOwo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO2Ry YWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LSZuYnNwO29yaWdpbmF0b3JAaWV0Zi5vcmcKPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDtTdWJqZWN0OiZuYnNwO1JlOiZuYnNwO1tMc3JdJm5ic3A7V0cm bmJzcDtMYXN0Jm5ic3A7Q2FsbAo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO2RyYWZ0LWlldGYt bHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsK PGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtbRXh0ZXJuYWwmbmJzcDtFbWFpbC4mbmJzcDtCZSZu YnNwO2NhdXRpb3VzJm5ic3A7b2YmbmJzcDtjb250ZW50XQo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOwo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw O0kmbmJzcDtzdXBwb3J0Jm5ic3A7bW92aW5nJm5ic3A7dGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7 Zm9yd2FyZC4KPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtTaW1pbGFyJm5ic3A7ZnVuY3Rpb25h bGl0eSZuYnNwO2luJm5ic3A7SVMtSVMmbmJzcDtoYXMmbmJzcDtwcm92ZWQmbmJzcDt1c2VmdWwu Cjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Cjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7SSZu YnNwO3dvdWxkJm5ic3A7aG93ZXZlciZuYnNwO2xpa2UmbmJzcDt0byZuYnNwO3JlcGVhdCZuYnNw O2NvbW1lbnRzJm5ic3A7SSZuYnNwO21hZGUmbmJzcDtlYXJsaWVyJm5ic3A7aW4mbmJzcDt0aGUm bmJzcDtyZXZpZXcKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtk b2N1bWVudC4KPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtUaGUmbmJzcDtjb250ZW50Jm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtBcHBlbmRpY2VzJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtyZW1v dmVkLgo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO1RoZSZuYnNwO0FwcGVuZGljZXMmbmJzcDtk ZWZpbmUmbmJzcDthbmQmbmJzcDtkaXNjdXNzJm5ic3A7ZGVyaXZpbmcmbmJzcDt0b3BvbG9neSZu YnNwO2luZm9ybWF0aW9uJm5ic3A7ZnJvbQo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO3ByZWZp eCZuYnNwO2FkdmVydGlzZW1lbnRzJm5ic3A7LSZuYnNwO3doaWNoJm5ic3A7aXMmbmJzcDtmbGF3 ZWQmbmJzcDthbmQmbmJzcDtzaG91bGQmbmJzcDtub3QmbmJzcDtiZSZuYnNwO2RvbmUuCjxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7UGVyaGFwcyZuYnNwO21vcmUmbmJzcDtyZWxldmFudCwmbmJz cDt0aGUmbmJzcDtwdXJwb3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtkb2N1bWVudCZuYnNwO2lz Jm5ic3A7dG8mbmJzcDtkZWZpbmUKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtwcm90b2NvbCZu YnNwO2V4dGVuc2lvbnMmbmJzcDtzdXBwb3J0aW5nJm5ic3A7YWR2ZXJ0aXNlbWVudCZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvcnMmbmJzcDtvZiZuYnNwO2EKPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDtwcmVmaXgmbmJzcDthZHZlcnRpc2VtZW50LiZuYnNwO1RoZXJlJm5ic3A7aXMm bmJzcDtubyZuYnNwO25lZWQmbmJzcDt0byZuYnNwO2Rpc2N1c3MmbmJzcDtob3cmbmJzcDt0aGlz Jm5ic3A7bWVjaGFuaXNtCjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7bWlnaHQmbmJzcDtiZSZu YnNwO3VzZWQmbmJzcDt0byZuYnNwO2J1aWxkJm5ic3A7dG9wb2xvZ3kmbmJzcDtpbmZvcm1hdGlv bi4KPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtUaGlzJm5ic3A7ZG9jdW1lbnQmbmJzcDtzaG91 bGQmbmJzcDtjb25maW5lJm5ic3A7aXRzZWxmJm5ic3A7dG8mbmJzcDtkZWZpbmluZyZuYnNwO3Ro ZSZuYnNwO3Byb3RvY29sCjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ZXh0ZW5zaW9ucyZuYnNw Oy0mbmJzcDtzaW1pbGFyJm5ic3A7dGhlJm5ic3A7UkZDJm5ic3A7Nzc5NC4KPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtJZiZuYnNwO3RoZSZuYnNw O2F1dGhvcnMmbmJzcDtkbyZuYnNwO25vdCZuYnNwO2FncmVlJm5ic3A7dG8mbmJzcDtkbyZuYnNw O3RoaXMsJm5ic3A7SSZuYnNwO3dvdWxkJm5ic3A7ZW5jb3VyYWdlJm5ic3A7dGhpcyZuYnNwO3Bv aW50Cjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7dG8mbmJzcDtiZSZuYnNwO2Rpc2N1c3NlZCZu YnNwO2R1cmluZyZuYnNwO0lFU0cmbmJzcDtyZXZpZXcuCjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Cjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7TGVzCjxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Cjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOy0tLS0tT3JpZ2luYWwmbmJz cDtNZXNzYWdlLS0tLS0KPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7RnJvbTombmJzcDtM c3ImbmJzcDsmbHQ7bHNyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7Jm5ic3A7T24mbmJzcDtCZWhhbGYm bmJzcDtPZiZuYnNwO0NocmlzdGlhbiZuYnNwO0hvcHBzCjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwO1NlbnQ6Jm5ic3A7V2VkbmVzZGF5LCZuYnNwO09jdG9iZXImbmJzcDsxNCwmbmJzcDsy MDIwJm5ic3A7MTE6MTUmbmJzcDtQTQo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtUbzom bmJzcDtsc3JAaWV0Zi5vcmcKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Q2M6Jm5ic3A7 ZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZzsKPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7bHNyLWNoYWlyc0BpZXRmLm9yZzsmbmJzcDtsc3ItJm5ic3A7 YWRzQGlldGYub3JnOyZuYnNwO0NocmlzdGlhbiZuYnNwO0hvcHBzCjxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZsdDtjaG9wcHNAY2hvcHBzLm9yZyZndDsKPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7U3ViamVjdDombmJzcDtbTHNyXSZuYnNwO1dHJm5ic3A7TGFzdCZuYnNwO0Nh bGwmbmJzcDtkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2Cjxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtUaGlz Jm5ic3A7YmVnaW5zJm5ic3A7YSZuYnNwOzImbmJzcDt3ZWVrJm5ic3A7V0cmbmJzcDtMYXN0Jm5i c3A7Q2FsbCwmbmJzcDtlbmRpbmcmbmJzcDthZnRlciZuYnNwO09jdCZuYnNwOzI5dGgsJm5ic3A7 MjAyMCwmbmJzcDtmb3I6Cjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7aHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWkKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ZXQKPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci9fXzshIU5FdDZ5TWFPLQo8 YnI+Jmd0OyZndDsmbmJzcDtnayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxCjxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwO2hLJm5ic3A7OHAwM0ZnM0w5THVDR1h3OEMwWDZxUlFkckhqS0RLSGNq a2pDbHBrJAo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7VGhlJm5ic3A7Zm9sbG93aW5nJm5ic3A7SVBSJm5ic3A7aGFzJm5ic3A7YmVl biZuYnNwO2ZpbGVkCjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO2h0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8zNDQ4L19fOyEK PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IU5FdDZ5TWFPLQo8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwO2drIVRhU3pRVGhnaHRDRk91WVBTMlZqTHFoSzhwMDNGZzNMOUx1Q0dYdzhDMFg2 cVJRZHJIaktES0hjego8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs1S3RVSFEkCjxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtB dXRob3JzLAo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsKPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7UGxlYXNlJm5ic3A7aW5kaWNhdGUmbmJzcDt0byZuYnNwO3RoZSZuYnNwO2xp c3QsJm5ic3A7eW91ciZuYnNwO2tub3dsZWRnZSZuYnNwO29mJm5ic3A7YW55Jm5ic3A7b3RoZXIm bmJzcDtJUFIKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7cmVsYXRlZCZuYnNwO3RvJm5i c3A7dGhpcyZuYnNwO3dvcmsuCjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtUaGFua3MsCjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwO0NocmlzLgo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOwo8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7THNyJm5ic3A7bWFpbGluZyZuYnNwO2xpc3QKPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDtMc3JAaWV0Zi5vcmcKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJz cDtodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sc3IKPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtfXzshIU5FdAo8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOzZ5TWFPLQo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOwo8YnI+ Jmd0OyZndDsmbmJzcDtnayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxaEs4cDAzRmczTDlMdUNHWHc4 QzBYNnFSUWRySGpLREtIY1VkbQo8YnI+Jmd0OyZndDsmbmJzcDt3OAo8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwO0xjJAo8YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Cjxicj4mZ3Q7Jmd0OyZndDsmbmJz cDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo8YnI+Jmd0 OyZndDsmZ3Q7Jm5ic3A7THNyJm5ic3A7bWFpbGluZyZuYnNwO2xpc3QKPGJyPiZndDsmZ3Q7Jmd0 OyZuYnNwO0xzckBpZXRmLm9yZwo8YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3IKPGJyPiZndDsmZ3Q7Jm5ic3A7Cjxicj4mZ3Q7Jmd0 OyZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCjxi cj4mZ3Q7Jmd0OyZuYnNwO0xzciZuYnNwO21haWxpbmcmbmJzcDtsaXN0Cjxicj4mZ3Q7Jmd0OyZu YnNwO0xzckBpZXRmLm9yZwo8YnI+Jmd0OyZndDsmbmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2xzcgo8YnI+Jmd0OyZuYnNwOwo8YnI+Jmd0OyZuYnNwO19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCjxicj4mZ3Q7Jm5ic3A7THNy Jm5ic3A7bWFpbGluZyZuYnNwO2xpc3QKPGJyPiZndDsmbmJzcDtMc3JAaWV0Zi5vcmcKPGJyPiZn dDsmbmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcgo8YnI+Cjxi cj4KPGJyPjwvZGl2PjwvZGl2Pjxicj4= --=_Part_912019_758899990.1602859073007-- From nobody Fri Oct 16 07:42:20 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3FA3A0AA3; Fri, 16 Oct 2020 07:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, RCVD_IN_MSPIKE_H2=-0.001, 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=SuS+L0Tp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Gyw2fI69 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 EDMGJiPEnvWL; Fri, 16 Oct 2020 07:42:16 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2B53A09F1; Fri, 16 Oct 2020 07:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5288; q=dns/txt; s=iport; t=1602859336; x=1604068936; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gQMFDhcQV73JbAjWcUTWmiB55E/h5zaT8J+DarhFji0=; b=SuS+L0TpZPjIFjvPfHREgzGp9u9cCHyLBlwZpPZfE/vP5a6Ljy7mI3Ij mewno4Am1AgQs43co3Knf8cI9hjhUVwK6S+547Dpt7Rk6k4Rzf4Su168w QdmwYRoDTDaWQ8kAec79akISont1ZHJznBy0mtV45NnIheuMKFHnBNXyR A=; IronPort-PHdr: =?us-ascii?q?9a23=3AVI3iBBQEQavJXRl47nBevkd5INpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9uJ9+lFjeXWrqmmXnYPp52H4zgOc51JAh?= =?us-ascii?q?kCj8he3wktG9WMBkCzKvn2Jzc7E8JPWB4AnTm7PEFZFdy4awjUpXu/viIJGx?= =?us-ascii?q?PwNRd8YOPvFcjZiZf/2+W74ZaGZQJOiXK0aq9zKxPjqwLXu4EWjIJuJ7x3xA?= =?us-ascii?q?HOpy5Dev9dwiVjIlfAkg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7CADwsIlf/4YNJK1gHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFPgVJRB3BZLyyEPYNJA41RihCOaoJTA1ULAQEBDQEBGAsKAgQBAYR?= =?us-ascii?q?KAheBdAIlOBMCAwEBCwEBBQEBAQIBBgRthWEMhXIBAQEBAgEBARAREQwBASk?= =?us-ascii?q?DCwEEBwQCAQgRBAEBAQICJgICAh8GCxUICAIEDgUIGoMFgksDDiABDqMLAoE?= =?us-ascii?q?5iGh2gTKDBAEBBYUdDQuCEAMGgQ4qgnKDboEGhVAbgUE/gRFDgk0+ghpCAQG?= =?us-ascii?q?BPQEBIoMVM4IskAoEgwYBPaNYVAqCapVlgiGDDIMWigiUMJUqi2SSTQIEAgQ?= =?us-ascii?q?FAg4BAQWBayOBV3AVO4JpUBcCDY4fDBeDToUUhUJ0OAIGAQkBAQMJfI1MAQE?= X-IronPort-AV: E=Sophos;i="5.77,383,1596499200"; d="scan'208";a="581865025" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Oct 2020 14:42:15 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 09GEgEgZ031233 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2020 14:42:15 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 16 Oct 2020 09:42:14 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 16 Oct 2020 09:42:14 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 16 Oct 2020 09:42:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fNyMwmHDXRpy2BpG6KUSxLXqnpeZ/xjSYtK6wqv/AdUXNI6o0lnOrzf5JxKasXHOTLTFoKSSWVOjoNAX9P1mF0Fv8XTPwp8AFedLbINtx8+cK2qA5IJaaMqeURR9JN8oErOcwqUC+nxOYoXZjnafy2ral1pSs5tSRCSBgmUqcDdIdCzs2QbwrmFWXc5Pj9Mn4+VtTmwH7KIyDcwJTLbEnb5sN5VOPUc6dYCGvGIXUa5HGAJZNLaXk+H6lmndehZH4t706Lm753cxFk09Go3q1jQmbU1aMQv7Dd/IBpVzug4+QiyoG9OkC05HhbdSGH2juN0ZHqLDFPU2nPGVQSmz4g== 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=gQMFDhcQV73JbAjWcUTWmiB55E/h5zaT8J+DarhFji0=; b=gGadzhn/Jtdz4ynxxMwzbbtpxFOtLnwLu8QSUG+c1Vf93d1D96mXxvu4ueO+CZ1MEqBGsVipQWC+VahZ8YMHfb1oakAeZh+ZdkGZKVm2AAdXbFvhhP86k6MOedKSeg1W+rvLHout379aia0fbtBHVqVETvrc5HRaVr7Mlx6XEK5EmP+gMfP5gfqw9fvBV9C6bR3DJxdIAbIZwDd2T0VRLf0nYN2KQU8FfgYfsXJtO7Ps4dUwk1Mnc4CkPnItq2uyR+ceh8hNJV50qEi60N2MjfVgPmswl5ycPW4cGiYReJVbaZrIzPoKmY4L725ng1N9P0BIYYbDjhN4sosiRBv3lg== 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=gQMFDhcQV73JbAjWcUTWmiB55E/h5zaT8J+DarhFji0=; b=Gyw2fI69UsZIZVu9zpBY4giRlQ9QigspslTHsQun4r0rCnpVaUxsOqLQ56zz4PuRJW+LFnD1xTJke2Wywsl95tBjq93g2k6C/7ZU6162kyoVF8y1cGy9DhnxgXmcmQWFBmuAjTQrM2XalEpN4uJjTHKoJMO3Sks7p6BUs+xwN9g= Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB2614.namprd11.prod.outlook.com (2603:10b6:a02:cc::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.27; Fri, 16 Oct 2020 14:42:12 +0000 Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf%3]) with mapi id 15.20.3455.030; Fri, 16 Oct 2020 14:42:12 +0000 From: "Les Ginsberg (ginsberg)" To: Aijun Wang CC: John E Drake , Christian Hopps , "lsr-chairs@ietf.org" , "lsr@ietf.org" , Jeff Tantsura , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorrKRY+9H8pM3U+ItYWSF6YHFamY2IdAgAAlOwCAADD9AIAASXsAgAA6BYCAADpcAIAAYsZg Date: Fri, 16 Oct 2020 14:42:12 +0000 Message-ID: References: <3E930E88-9404-4874-888B-881D022DFFEC@tsinghua.org.cn> In-Reply-To: <3E930E88-9404-4874-888B-881D022DFFEC@tsinghua.org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2602:306:36ca:6640:2d9a:f9b6:44f7:40a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87593a38-9ee6-4ef6-ed54-08d871e1ab04 x-ms-traffictypediagnostic: BYAPR11MB2614: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WzwJea4jgkG1pXioGsANQQIrUjXFJTYod+haYeQy74+KtWGwrYovxIrEO13aUb/obp8XXaZjiK1obkdkA3156P+RBo7VuNB7I4SWWjjG3P/PWezYdAVioOXqY44u8CsPBZlen5HVtXUbFwL8sGWRUHUMqOLDCk+24V04Famm6r5HlsGnxXsqdl0PeiUrYAdl2xxB2T6mPuy2O+Jmt/W58xJUSeqSNbmDBsmU0r/pjuEPDPP1GaIgQNg3O1QwQ4XCCYSEgPxeowN84ho7PY7grZ24c5hfEHchK/gpLwMCHXkYj+oqyRpU6TTzfSncXNQQ1ovsRGec/Sf2KRBv4mxxgGbZCWU3cP7bX+XSlWTyWf36DriHf/1o/5eRU86wZ2GBNcPT3zMyB0mZc8BVUYYCiA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(366004)(346002)(376002)(136003)(66446008)(478600001)(7696005)(66556008)(186003)(5660300002)(52536014)(33656002)(966005)(64756008)(2906002)(6506007)(53546011)(316002)(54906003)(55016002)(86362001)(66476007)(66946007)(6916009)(4326008)(8936002)(83380400001)(9686003)(71200400001)(8676002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: A1mrWDTfsw84UNhUs7WCO5URqFKO29IMuG1gBMFrfO107Qe+rh0pVOthtQF+PVa0jsGrA6/lETsXjWGMXLsUEVo3wM87wn5Zlj158XVgIXYMUk4Sis0SXRLKIEE/7hx49CCx5s4DdFEDuZbUPTdaVdye/NnJ3s+esizTJYbM97/WgkchEH8LKi0ZNrrc7eB3y4uz46YuH3Ys85kOwjkLhKSzukCS2vBNVR+XHMI4MhXUs6gOTFu4OtVxWpL9SW6h8XHZdwzsKTmyaSqL56WdnRzHlSbe8B8rtnyvaLjNVy7BwXEHiHRB2suytSeQKrgpVsguVOr7H5NUMXdvWOglPYjZT3DX/bIJr9W62N2E9ahT0JhW85aa7/VI5TUi3EKj6kqwzCSXeGC6mQb0LDj8EFjU8eGKvmRAQfkXnHxIBEBRWcA0Y2O9ke8mJwGCg1pYfCwezg9n9+N3oAx+kiHTwjR2bwHxQ67oK4fWne4DK6pnZQstVDDx/2Dq0W2Lv4WA2Qs8a/qsMWD3yPvM96bMeRqZXvo2PS0jH3bekJHJMXQtzL+DKMDYSVSy4SFztWE4C9BTvl3rS+20ZyT7lgJF45G5in081A3HSPcfjBJ1fWSTK850Kit/KnhaGsilwKTz/6VqiJ7raA+CqHJE/pt3jKjPBSl9stRrdZJoOb5fqqS/WzvTP+FQ3RqzAfGQK5EWkKaG1f5NKzlrHbwm1lXHlQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87593a38-9ee6-4ef6-ed54-08d871e1ab04 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 14:42:12.2712 (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: YxQp4PWiEMuhUociDGqnWh7kMq3aRDfUA1nnUTIIggCZU7kJh5uJlirzi+WkVR2KrAwiFriQslVai9nBkFOhVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2614 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 14:42:19 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTHNyIDxsc3ItYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFpanVuIFdhbmcNCj4gU2VudDogRnJpZGF5LCBPY3Rv YmVyIDE2LCAyMDIwIDE6NDggQU0NCj4gVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIDxnaW5z YmVyZ0BjaXNjby5jb20+DQo+IENjOiBKb2huIEUgRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5ldD47 IENocmlzdGlhbiBIb3Bwcw0KPiA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBsc3ItY2hhaXJzQGlldGYu b3JnOyBsc3JAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmENCj4gPGplZmZ0YW50LmlldGZAZ21haWwu Y29tPjsgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZzsgbHNy LQ0KPiBhZHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbCBkcmFm dC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+IA0KPiBIaSwgTGVzIGFuZCBl eHBlcnRzIGluIExTUjoNCj4gDQo+IEkgYW0gb3BlbiB0byB0aGUgcmVtb3ZhbCBvZiB0aGUgdGhp cyBhcHBlbmRpeCB0byBmb3J3YXJkIHRoaXMgZHJhZnQuDQoNCltMZXM6XSBHcmVhdCEhIFBsZWFz ZSBkbyBzby4NCg0KICAgTGVzDQoNCg0KPiBCdXQgYXMgc3RhdGVkIGluIHByZXZpb3VzIG1haWws IHByb3ZpZGluZyB0aGlzIGNhbiBhc3Npc3QgdGhlIHVzZXIvcmVhZGVyIG9mIHRoZQ0KPiBkcmFm dC4gV2Ugb2Z0ZW4gZW5jb3VudGVyIHRoZSBxdWVzdGlvbnMgaW4gdGhlIG1haWwgbGlzdCB0aGF0 IHdoYXQgdGhlIHVzYWdlDQo+IG9mIHByb3RvY29sL2JpdCBkZWZpbml0aW9uIGluIHNvbWUgZHJh ZnRzLg0KPiANCj4gQWN0dWFsbHksIHdlIGRpZCBub3QgZXhwYW5kIHRoZSBkaXNjdXNzaW9uIG9m IHRoaXMgcGFydCBpbiB0aGlzIGRyYWZ0LiBUaGUNCj4gZGVzY3JpcHRpb24gb2YgdGhpcyBwYXJ0 IGlzIHZlcnkgY29uY2lzZS4NCj4gDQo+IElmIHlvdSBpbnNpc3QgdGhpcywgSSBjYW4gdXBkYXRl IHRoZSBkcmFmdCBpbiByZWNlbnQgZGF5cywgdG9nZXRoZXIgd2l0aCBvdGhlcg0KPiBjb21tZW50 cyBvbiB0aGlzIGRyYWZ0Lg0KPiANCj4gT3RoZXIgY29tbWVudHMgYXJlIHdlbGNvbWUgYWxzbyEN Cj4gDQo+IEFpanVuIFdhbmcNCj4gQ2hpbmEgVGVsZWNvbQ0KPiANCj4gPiBPbiBPY3QgMTYsIDIw MjAsIGF0IDEzOjUxLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29t Pg0KPiB3cm90ZToNCj4gPg0KPiA+IO+7v0FpanVuIC0NCj4gPg0KPiA+IFRoZSBwb2ludCBJIGFt IG1ha2luZyBpcyB2ZXJ5IGZvY3VzZWQuDQo+ID4NCj4gPiBUaGlzIGRyYWZ0IGlzIGRlZmluaW5n IGEgcHJvdG9jb2wgZXh0ZW5zaW9uLiBBcyBzdWNoIGl0IGlzIG5lY2Vzc2FyeSB0aGF0IHRoaXMN Cj4gYmUgU3RhbmRhcmRzIHRyYWNrIGFzIGFkaGVyaW5nIHRvIHRoZSBub3JtYXRpdmUgc3RhdGVt ZW50cyBpbiB0aGUgZHJhZnQgYXJlDQo+IG5lY2Vzc2FyeSBmb3IgaW50ZXJvcGVyYWJpbGl0eS4N Cj4gPg0KPiA+IFdoYXQgaXMgZGlzY3Vzc2VkIGluIHRoZSBBcHBlbmRpeCBpcyBhIHVzZSBjYXNl LiBJdCBpcyBub3Qgbm9ybWF0aXZlIGFuZA0KPiB0aGVyZSBhcmUgc3Ryb25nIG9waW5pb25zIG9u IGJvdGggc2lkZXMgYXMgdG8gd2hldGhlciB0aGlzIGlzIGFuIGFwcHJvcHJpYXRlDQo+IHVzZSBj YXNlIG9yIG5vdC4NCj4gPiBJbiB0aGUgY29udGV4dCBvZiB0aGlzIGRyYWZ0LCBJIGhhdmUgbm8g aW50ZXJlc3QgaW4gdHJ5aW5nIHRvIHJlc29sdmUgb3VyDQo+IGRpZmZlcmVuY2Ugb2Ygb3Bpbmlv biBvbiB0aGlzIHVzZSBjYXNlLiBJIHNpbXBseSB3YW50IHRoZSBwcm90b2NvbCBleHRlbnNpb24N Cj4gdG8gbW92ZSBmb3J3YXJkIHNvIHRoYXQgd2UgaGF2ZSBhbm90aGVyIHRvb2wgYXZhaWxhYmxl Lg0KPiA+DQo+ID4gSWYgeW91IHdhbnQgdG8gd3JpdGUgYSBkcmFmdCBvbiB0aGUgdXNlIGNhc2Ug ZGlzY3Vzc2VkIGluIHRoZSBBcHBlbmRpeA0KPiBwbGVhc2UgZmVlbCBmcmVlIHRvIGRvIHNvLiBU aGF0IGRyYWZ0IG1heSB2ZXJ5IHdlbGwgbm90IGJlIG5vcm1hdGl2ZSAtDQo+IEluZm9ybWF0aW9u YWwgb3IgQkNQIG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlIC0gYmVjYXVzZSBpdCB3aWxsIGJlIGRp c2N1c3NpbmcNCj4gYSBkZXBsb3ltZW50IHNjZW5hcmlvIGFuZCBhIHByb3Bvc2FsIHRvIHVzZSBk ZWZpbmVkIHByb3RvY29sIGV4dGVuc2lvbnMgYXMNCj4gb25lIHdheSB0byBzb2x2ZSBwcm9ibGVt cyBpbiB0aGF0IGRlcGxveW1lbnQgc2NlbmFyaW8uIFN1Y2ggYSBkcmFmdCBtaWdodA0KPiBhbHNv IGJlIG1vcmUgYXBwcm9wcmlhdGUgaW4gYW5vdGhlciBXRyAoZS5nLiwgVEVBUykuIFRoZSBtZXJp dHMgb2YgdXNpbmcNCj4gcHJlZml4IGFkdmVydGlzZW1lbnRzIHRvIGJ1aWxkIGEgdG9wb2xvZ3kg Y291bGQgdGhlbiBiZSBkaXNjdXNzZWQgb24gaXRzIG93bi4NCj4gPg0KPiA+IFBsZWFzZSBkbyBu b3QgdHJ5IHRvIGF2b2lkIGhhdmluZyBhIGZ1bGwgZGlzY3Vzc2lvbiBvZiB0aGUgbWVyaXRzIG9m IHVzaW5nDQo+IHByZWZpeCBhZHZlcnRpc2VtZW50cyB0byBkZXJpdmUgdG9wb2xvZ3kgYnkgYWRk aW5nIGl0IHRvIGEgZHJhZnQgdGhhdCBpcyAoYW5kDQo+IHNob3VsZCBiZSkgZm9jdXNlZCBvbiBz aW1wbGUgcHJvdG9jb2wgZXh0ZW5zaW9ucy4NCj4gPg0KPiA+IFRoYW54Lg0KPiA+DQo+ID4gICBM ZXMNCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206 IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+DQo+ID4+IFNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDE1LCAyMDIwIDY6NTEgUE0NCj4gPj4gVG86ICdKZWZmIFRhbnRzdXJhJyA8 amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+OyAnSm9obiBFIERyYWtlJw0KPiA+PiA8amRyYWtlQGp1 bmlwZXIubmV0Pg0KPiA+PiBDYzogJ0NocmlzdGlhbiBIb3BwcycgPGNob3Bwc0BjaG9wcHMub3Jn PjsgbHNyLWNoYWlyc0BpZXRmLm9yZzsgTGVzDQo+IEdpbnNiZXJnDQo+ID4+IChnaW5zYmVyZykg PGdpbnNiZXJnQGNpc2NvLmNvbT47IGxzckBpZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9yZzsgZHJh ZnQtDQo+IGlldGYtDQo+ID4+IGxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnDQo+ ID4+IFN1YmplY3Q6IFJFOiBbTHNyXSBXRyBMYXN0IENhbGwgZHJhZnQtaWV0Zi1sc3Itb3NwZi1w cmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+Pg0KPiA+PiBIaSwgTGVzLCBKb2huIGFuZCBKZWZmOg0K PiA+Pg0KPiA+PiBMZXQncyByZXBseSB5b3UgYWxsIHRvZ2V0aGVyLg0KPiA+PiBJbiBteSBQT1Ys IFRoZSBzdGFuZGFyZCBkb2N1bWVudCBzaG91bGQgbm90IGRlZmluZSBzb2xlbHkgdGhlIHByb3Rv Y29sDQo+ID4+IGV4dGVuc2lvbiwgYnV0IHRoZWlyIHVzYWdlcyBpbiB0aGUgbmV0d29yayBkZXBs b3ltZW50LiBBcyBJIGtub3duLA0KPiBhbG1vc3QNCj4gPj4gYWxsIHRoZSBJRVRGIGRvY3VtZW50 cyBmb2xsb3dpbmcgdGhpcyBzdHlsZS4NCj4gPj4gQW5kLCBiZWZvcmUgYWRvcHRpbmcgb25lIHdv cmssIHdlIGhhdmUgb2Z0ZW4gaW50ZW5zZSBkaXNjdXNzaW9uIGZvcg0KPiB3aGF0J3MNCj4gPj4g dGhlaXIgdXNhZ2VzLg0KPiA+PiBTdWNoIGRpc2N1c3Npb24gaW4gdGhlIG1haWwgbGlzdCBhbmQg c3RhdGVtZW50cyBpbiB0aGUgZG9jDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBMc3IgbWFpbGluZyBsaXN0DQo+IExzckBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0K From nobody Fri Oct 16 07:47:19 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B103A0F8C; Fri, 16 Oct 2020 07:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yq1hS2tFBQUX; Fri, 16 Oct 2020 07:47:16 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8C73D3A09F1; Fri, 16 Oct 2020 07:47:16 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A2D416167C; Fri, 16 Oct 2020 14:47:14 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_9BF42199-F56E-4AE8-A879-AE803D245516"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Christian Hopps X-Priority: 3 In-Reply-To: Date: Fri, 16 Oct 2020 10:47:13 -0400 Cc: Christian Hopps , "Les Ginsberg (ginsberg)" , John E Drake , "lsr-chairs@ietf.org" , "lsr@ietf.org" , Jeff Tantsura , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" Message-Id: <303E621F-47AA-4309-AC85-32A597604C7C@chopps.org> References: To: =?utf-8?B?546L54ix5L+K?= X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 14:47:19 -0000 --Apple-Mail=_9BF42199-F56E-4AE8-A879-AE803D245516 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Isn't this just adding an analogous extension that already exists in = RFC7794? I don't think we need to do a lot of convincing at this point. I agree = with Les, if you want to talk about use cases (especially ones that are = controversial!) then the correct place for that is in a new informative = draft. Otherwise, especially if the cases are controversial, this can be = seen as doing an "end-run" to avoid the debate b/c people want the = extension, but maybe don't agree with your use case. Legislators do this = sometimes adding things they want personally to popular bills, that = other people may not want, but since people want the main bill they vote = for it anyway, in the US it's called "adding pork" or "pork barrel = politics". :) Thanks, Chris. > On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A = wrote: >=20 >=20 > Hi, Chris: > Originally, the appendix part is within the document, which is the = start point/main motivation to extend the prefix origin. > There may exists other usages of this information. Pack these examples = into some short sentences or introduction is viable, but expand some of = them is also helpful. > As I known, when we want to do protocol extension, we should always = convince other the reason/motivation/prospects to do so. On the other = hand, the use case described in the current appendix is very prominent = for operator to accomplish the TE task in multi-area environment. >=20 > Aijun Wang >=20 > =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps = <chopps@chopps.org>=E5=86=99=E9=81=93: > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps = <chopps@chopps.org> > =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410=E6=9C=8816=E6=97=A5= =E6=98=9F=E6=9C=9F=E4=BA=94 > =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)" = <ginsberg=3D40cisco.com@dmarc.ietf.org>] > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 >=20 > > On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) = wrote: > > > > Aijun - > > > > The point I am making is very focused. > > > > This draft is defining a protocol extension. As such it is necessary = that this be Standards track as adhering to the normative statements in = the draft are necessary for interoperability. > > > > What is discussed in the Appendix is a use case. It is not normative = and there are strong opinions on both sides as to whether this is an = appropriate use case or not. > > In the context of this draft, I have no interest in trying to = resolve our difference of opinion on this use case. I simply want the = protocol extension to move forward so that we have another tool = available. > > > > If you want to write a draft on the use case discussed in the = Appendix please feel free to do so. That draft may very well not be = normative - Informational or BCP may be more appropriate - because it = will be discussing a deployment scenario and a proposal to use defined = protocol extensions as one way to solve problems in that deployment = scenario. Such a draft might also be more appropriate in another WG = (e.g., TEAS). The merits of using prefix advertisements to build a = topology could then be discussed on its own. > > > > Please do not try to avoid having a full discussion of the merits of = using prefix advertisements to derive topology by adding it to a draft = that is (and should be) focused on simple protocol extensions. >=20 > [As WG member] >=20 > I find this very compelling and so support the removal of the referred = to non-normative appendices. >=20 > Thanks, > Chris. >=20 > > > > Thanx. > > > > Les > > > > > >> -----Original Message----- > >> From: Aijun Wang > >> Sent: Thursday, October 15, 2020 6:51 PM > >> To: 'Jeff Tantsura' ; 'John E Drake' > >> > >> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; Les = Ginsberg > >> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; = draft-ietf- > >> lsr-ospf-prefix-originator@ietf.org > >> Subject: RE: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 > >> > >> Hi, Les, John and Jeff: > >> > >> Let's reply you all together. > >> In my POV, The standard document should not define solely the = protocol > >> extension, but their usages in the network deployment. As I known, = almost > >> all the IETF documents following this style. > >> And, before adopting one work, we have often intense discussion for = what's > >> their usages. > >> Such discussion in the mail list and statements in the document can = certainly > >> assist the reader/user of the document get the essence of the = standard, and > >> follow them unambiguously. > >> > >> Regarding the contents of appendices, as stated in the section, = "The > >> Appendix A heuristic to rebuild the topology can normally be used = if all links > >> are numbered." I think this can apply almost most of the operator's = network, > >> and facilitate the inter-area TE path calculation for central = controller, or even > >> for the head-end router that located in one area that different = from the tail- > >> end router. > >> > >> Keeping the contents of appendices does not have the negative = impact of > >> the protocol extension, it is just one reference for the usage of = this > >> extension. > >> One can select not refer to it, if their networks are deployed with = large > >> amount of unnumbered links. But for others, the heuristic applies. > >> > >> Best Regards > >> > >> Aijun Wang > >> China Telecom > >> > >> > >> > >> -----Original Message----- > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf = Of Jeff > >> Tantsura > >> Sent: Friday, October 16, 2020 5:28 AM > >> To: John E Drake > >> Cc: Christian Hopps ; lsr-chairs@ietf.org; Les = Ginsberg > >> (ginsberg) ; lsr@ietf.org; = lsr- > >> ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org > >> Subject: Re: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 > >> > >> +1 > >> > >> Regards, > >> Jeff > >> > >>> On Oct 15, 2020, at 11:33, John E Drake > >> wrote: > >>> > >>> =EF=BB=BFHi, > >>> > >>> I agree with Les. This is a simple protocol extension for a = specific purpose > >> and there is no reason to include speculation about its use for = other > >> purposes, particularly when it is inherently not suited for them. > >>> > >>> Yours Irrespectively, > >>> > >>> John > >>> > >>> > >>> Juniper Business Use Only > >>> > >>>> -----Original Message----- > >>>> From: Lsr On Behalf Of Les Ginsberg = (ginsberg) > >>>> Sent: Thursday, October 15, 2020 12:33 PM > >>>> To: Christian Hopps ; lsr@ietf.org > >>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; > >>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org > >>>> Subject: Re: [Lsr] WG Last Call > >>>> draft-ietf-lsr-ospf-prefix-originator-06 > >>>> > >>>> [External Email. Be cautious of content] > >>>> > >>>> > >>>> I support moving this document forward. > >>>> Similar functionality in IS-IS has proved useful. > >>>> > >>>> I would however like to repeat comments I made earlier in the = review > >>>> of this document. > >>>> The content of the Appendices should be removed. > >>>> The Appendices define and discuss deriving topology information = from > >>>> prefix advertisements - which is flawed and should not be done. > >>>> Perhaps more relevant, the purpose of the document is to define > >>>> protocol extensions supporting advertisement of the originators = of a > >>>> prefix advertisement. There is no need to discuss how this = mechanism > >>>> might be used to build topology information. > >>>> This document should confine itself to defining the protocol > >>>> extensions - similar the RFC 7794. > >>>> > >>>> If the authors do not agree to do this, I would encourage this = point > >>>> to be discussed during IESG review. > >>>> > >>>> Les > >>>> > >>>>> -----Original Message----- > >>>>> From: Lsr On Behalf Of Christian Hopps > >>>>> Sent: Wednesday, October 14, 2020 11:15 PM > >>>>> To: lsr@ietf.org > >>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; > >>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps > >>>>> > >>>>> Subject: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 > >>>>> > >>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, = for: > >>>>> > >>>>> > >>>>> = https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i > >>>>> et > >>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- > >> gk!TaSzQThghtCFOuYPS2VjLq > >>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ > >>>>> > >>>>> The following IPR has been filed > >>>>> = https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! > >>>>> !NEt6yMaO- > >>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz > >>>>> 5KtUHQ$ > >>>>> > >>>>> Authors, > >>>>> > >>>>> Please indicate to the list, your knowledge of any other IPR > >>>>> related to this work. > >>>>> > >>>>> Thanks, > >>>>> Chris. > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> = https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr > >>>> __;!!NEt > >>>> 6yMaO- > >>>> > >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm > >> w8 > >>>> Lc$ > >>> > >>> _______________________________________________ > >>> Lsr mailing list > >>> Lsr@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lsr > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr >=20 >=20 >=20 --Apple-Mail=_9BF42199-F56E-4AE8-A879-AE803D245516 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+JsnEACgkQLh2DDte4 MCWOtA/+JOdWBLMjJYGvUNxa1mKpSiqEw3gUIGmpNyv6E3eXAb+aqr7JbuaeBs8/ D+aw8puvPqmR9Nv2ozZMuhQyFCbw8n2A4U7RSn1sDWi+zX1cJn0WiRbEpqCrBUpq ADua9liExJNiS0kUYUnAbFP3H+84NGKwKUNhfRV41ycgUfgbi1eMN3MXGsgncYiU wQ+8uRquy/O0A/R4DO5VzWjzxVZnn3T0w1cvXdDk1Wf1FM2Ze/1DUah6C15ubptt YmOVGeyEHQixdY32NOPPO6cnAipkyD0/H5I9QhIy0UHz5zZSl5WMS+Id1WS/OH51 eeCPlZuOVtOR3VzTSWZo8Dq7EOJCW1CuiQlsd6bylB0pVuRjZEcGdIMQkm6bJUjN eMcctdS7VIE2MQrW1MPlGQK7Cp3bO5R27q7g85NaellpELCr+xet6x+xrQdWGgch TdFWTg3lZLOeAFHrF5Rxeq6QS9SW0+i+fqu4Z1ct6fGl59vVOc70mofmsfXYzbxT ZZQcBN+3UIhsRxNUkq/fx+swfdZMMmx7L0JtgVIuYttu5iMGeFAR/X/1yE67Oab2 y+OM6OhW+CJVQDCXvfCHcGP37JMASOQkSMi32uj2rpuajCIaeXDprcAfbY2S2RdC IVXe1Tw/YDM37860mWeU06khIcCu21cw18qowhQ+Uk54lPx8pxw= =EdGZ -----END PGP SIGNATURE----- --Apple-Mail=_9BF42199-F56E-4AE8-A879-AE803D245516-- From nobody Fri Oct 16 11:48:47 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2787D3A0799; Fri, 16 Oct 2020 11:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 75CWc5jLeMuR; Fri, 16 Oct 2020 11:48:44 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2074.outbound.protection.outlook.com [40.107.237.74]) (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 CC5023A03F1; Fri, 16 Oct 2020 11:48:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xr45Iq8Up0hfhvf9p4saRvNsRRE02e7ffKLxsSmkFUpv6o+kTrneZhVeyyxiAPsEbrtDIozXNvCNQ3VVeHoX2IFrwrwiC8e7bIJHdQ7IQ9dLTkrSyDhH39AKwfO5jhaa9YDugHrDiOZJwOg3OCRX0pqajUe+l+0yyZYv7hL5T6WKf74vvaRG8vimKmRh60MSQiz945zqYno6diWoyLyQsVqjiExW7eJaLYLsYoRQrUxPRWsj95HlYz/OkJoYBMGi7hcGZe/UaEMsN6zLymSnV3gCrKXVZvWjenX9TMl+lV4LMc2qV+hB/sOIW1ajhtiyusB0mVg0BWUDoZp8TsfT1A== 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=mAULEGt+3OPoskCGWE84/sLQq6Vzal8jZ1/LdOf6Juc=; b=amGiTsas9xSwmIp3GnxMjH4DAYH31ZMTesNPjcOzJ+Wm+UJ4zBFWdgfYWy1ndCoxsaUdm/XbMTke/YTHDjL75X6KbWv/cujXSsIkptaSlPKuJ4r1h9LBa1Foc1LBk6bZyRTJLO6mkrnNtalsiYUgVg21+7uiYxx0MbXNeabdmmKs4tgU63HOWl+W6mrulGHRPZB8WNJallrkjmTr9F0fVzZE3dI1JqQs1n0gKc9beZCSU7Xz8OFH3d94HhcLkdx++fO9Q/SPTcLb6QeLhcOaVeM2sIkovYMbUM7TEGVyuvDxxIoxrKlUMNSmsseZB+nYFDq6W9FsoMMblxFbUDAfgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mAULEGt+3OPoskCGWE84/sLQq6Vzal8jZ1/LdOf6Juc=; b=rixW3h67KlwYN72JBafDpE7VhuC23VYjcUM0g1LYUcCrxpqkgcW8wF4loWOU4Nxm+T86lip0lwHwc/CYDd/5oLss0rizCQXJUqx0o4SOEVNJcirrE5IfcJDlGLYMl23R0Mwoq0e1DJMTiTZSklljpfCJmDldtnaTWSvLzu8xI3I= Received: from MN2PR15MB3103.namprd15.prod.outlook.com (2603:10b6:208:f9::10) by MN2PR15MB3231.namprd15.prod.outlook.com (2603:10b6:208:a1::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Fri, 16 Oct 2020 18:48:40 +0000 Received: from MN2PR15MB3103.namprd15.prod.outlook.com ([fe80::c5d9:b745:9e88:257c]) by MN2PR15MB3103.namprd15.prod.outlook.com ([fe80::c5d9:b745:9e88:257c%3]) with mapi id 15.20.3477.025; Fri, 16 Oct 2020 18:48:40 +0000 From: Eric Gray To: "rtg-ads@ietf.org" , "lsr-chairs@ietf.org" CC: "rtg-dir@ietf.org" , "lsr@ietf.org" Thread-Topic: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo Thread-Index: Adaj5RbuL4NRT3uMSN6SXWsPfNq1nQ== Date: Fri, 16 Oct 2020 18:48:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [73.248.143.71] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 91206a9b-0b91-42da-cce5-08d87204196a x-ms-traffictypediagnostic: MN2PR15MB3231: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Yxb2E2DrVVmccJZKAOuxBTThp3BHvxSmawK6TLMECyny1BpeGnbo0m40KFiSsTzb07fcwhjSj90y6XIJMXanSkWOEIW68G8lhKLvk6Pa457aud1yNRJWnXDdVmE/GajVD4TM5JlThlWInTYJBGLD5iUyrJJ+uT33m0aqySuPQNHqo4+9hiKHBpshuYdRzO9uQcUCuDwGC6ikaFxADY+0DELCEP3FtcmE1cv/nW5r9Q+IsEdq1y4CvHD93xrZa4dL1L6aCM2LX1gxpBJ4yDazYkTDWfCsJ9Oz6x7UiH25hGB1LTDykvC9qyUs2SMW7mEChiV9v2dpi3jtlkqbOoDQNBoa3pukA0l0lmy1NBgaPzqw/iEWWj0kPH+5Xlp8RARcm0j4W5+Oq27Wpf8NAkGNgQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR15MB3103.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(376002)(346002)(136003)(83380400001)(66946007)(76116006)(52536014)(66556008)(5660300002)(66476007)(86362001)(55016002)(64756008)(66446008)(54906003)(110136005)(7696005)(33656002)(316002)(9686003)(478600001)(8676002)(186003)(44832011)(166002)(6506007)(9326002)(4326008)(450100002)(2906002)(966005)(26005)(71200400001)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: T6fylMRfrgVwuH89MJlQT9u/1c8dwLE3y1aUyrXA1Jgy2fvkms2/bBkhGXXY8DVSBI26mEBa8lZ0NvNX31xPW6BcyQ4NCCx1+3oGrof2+sYd2uCwkpmH4aaRZVYQSHzCnDK1PhdSV0RhMWWXpT/0ORTvDCoAwl9AeJjERc3NDJvWQRay/vxVWVjoxY1APvLFZG1NeZpyLep72K2I6oRAfHd0yKY5fJM4bBMNpfpunLV1hZzaxsxdgLq/mEIyqQzIv9zg9aRMTOrl0qPA3B3BhSRBDe9XxVQaw3c/xVhEexRjA8+SH7KBCyriunI5E148fMyDEumeWkogdiPjYdGBznUBG0Ct27m1jg5zJKmvvUxW9Nyt6H7yLyewfA+62Ye2+kuA635A+zdEfO0NmbgCWDzrDlzQa4gtWouQxAyNLsm1fJKK/0vwBt7bwCNcxZ/Ah2+7FSJOGNmhFoHHjD3ZE5TMvM2jlsehF7TrDYZ3kuzrM1Wtrxb2RI1EAMobHISdbwB9QLVGmwMY21rWJnfzqEE8baKZ20FYRmLgqaxyijhnJCOCXRsMxXjGbZNnQJH7NiJNHaFPpN7BDZUQzboi9rCRmzmzA+cTISeD9GY4cJrgktKKnH8BIIHeJncQf1Sf0hUiniJAJBhPq4Bp8BC0RA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR15MB31035D98D51D3A1E6C3B50F797030MN2PR15MB3103namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR15MB3103.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 91206a9b-0b91-42da-cce5-08d87204196a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 18:48:40.3091 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +IKILemWptBTtQAiIathytLQcOouk8Rm3FiHmyM8oSUL289w4o1BpAkeKJcRauD8Z+gbt1G21ULFkjAVFaDhuw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB3231 Archived-At: Subject: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 18:48:46 -0000 --_000_MN2PR15MB31035D98D51D3A1E6C3B50F797030MN2PR15MB3103namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIGh0dHBzOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyLg0KDQoNCg0KQWx0aG91Z2ggdGhl c2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMs IGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0 aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5k IHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5n IHRoZSBkcmFmdC4NCg0KDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLWxzci1mbGV4LWFsZ28tMTIu dHh0DQoNCg0KDQpSZXZpZXdlcjogRXJpYyBHcmF5DQoNClJldmlldyBEYXRlOiAxNiBPY3RvYmVy LCAyMDIwDQoNCklFVEYgTEMgRW5kIERhdGU6IFVua25vd24NCg0KSW50ZW5kZWQgU3RhdHVzOiBT dGFuZGFyZHMgVHJhY2sNCg0KDQoNClN1bW1hcnk6DQoNClRoaXMgZG9jdW1lbnQgaXMgd2VsbCBv cmdhbml6ZWQsIHJlbGF0aXZlbHkgZWFzeSB0byByZWFkLCBhbmQgcHJvYmFibHkgcmVhZHkgZm9y IHB1YmxpY2F0aW9uLCBidXQgaGFzIG9uZSBwb3RlbnRpYWwgbWlub3IgaXNzdWUgYW5kIGEgdmVy eSBzbWFsbCBudW1iZXIgb2YgTklUcyB0aGF0IG1pZ2h0IGJlIGNvbnNpZGVyZWQgcHJpb3IgdG8g cHVibGljYXRpb24uDQoNCg0KDQpNYWpvciBJc3N1ZXM6DQoNCk5vbmUNCg0KDQoNCk1pbm9yIElz c3VlczoNCg0KVGhlIHN0YXRlbWVudCBpbiBzZWN0aW9uIDE1IChCYWNrd2FyZCBDb21wYXRpYmls aXR5KSAtICJUaGlzIGV4dGVuc2lvbiBicmluZ3Mgbm8gbmV3IGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgaXNzdWVzIiAtIHNlZW1zIHNvbWV3aGF0IGZsaXAuDQoNCg0KDQpJIHN1c3BlY3QgdGhhdCBh IHRpbnkgYml0IG9mIGFuYWx5c2lzIHdvdWxkIG5vdCBodXJ0Lg0KDQoNCg0KVGhlIGV4dGVuc2lv bnMgaW4gdGhpcyBkcmFmdCBhcmUgY2xlYXJseSBpbnRlbmRlZCB0byB3b3JrIGluIGFuIGVudmly b25tZW50IHdoZXJlIHJvdXRlcnMgdGhhdCBfZG9fbm90XyBzdXBwb3J0IHRoZXNlIGV4dGVuc2lv bnMgYXJlIGFsc28gZGVwbG95ZWQsIGJ1dCBhcHBhcmVudGx5IHJlbGllcyBvbiBjb25maWd1cmF0 aW9uIG9mIHRob3NlIHJvdXRlcnMgdGhhdCBfZG9fIHN1cHBvcnQgdGhlIGV4dGVuc2lvbnMgdG8g YWRkcmVzcyB0aGlzLg0KDQoNCg0KVGhhdCBzZWVtcyBjb3JyZWN0Lg0KDQoNCg0KRnJvbSBteSBy ZWFkaW5nIG9mIHRoZSBkcmFmdCAod2hpY2ggSSBoYXZlIG5vdCBjbG9zZWx5IGZvbGxvd2VkIGZv ciBpdHMgZW50aXJlIGRldmVsb3BtZW50KSwgd2hpbGUgaXQgaW50cm9kdWNlcyBhdCBsZWFzdCBv bmUgbmV3IFRMViwgdGhlIE9TUEYgcm91dGluZyBwcm90b2NvbCBoYXMgd2VsbCBkZWZpbmVkIGhh bmRsaW5nIGZvciBUTFZzIHRoYXQgYXJlIG5vdCB1bmRlcnN0b29kIC0gaGVuY2UgdGhlIGludHJv ZHVjdGlvbiBvZiBvbmUgb3IgbW9yZSBuZXcgVExWcyBzaG91bGQgbm90IHByZXNlbnQgYSBwcm9i bGVtIGluIE9TUEYuDQoNCg0KDQpPYnZpb3VzbHkgU3ViLVRMVnMgb2YgdGhlIG5ldyBPU1BGIFRM ViB0eXBlIHdpbGwgbm90IGludHJvZHVjZSBjb21wYXRpYmlsaXR5IGlzc3Vlcy4NCg0KDQoNCkkg YXNzdW1lIChidXQgZG8gbm90IGFjdHVhbGx5IGtub3cpIHRoYXQgYSBzaW1pbGFyIHNpdHVhdGlv biBleGlzdHMgZm9yIHRoZSBuZXcgSVNJUyBGQUQgU3ViLVRMViBvZiB0aGUgZXhpc3RpbmcgVExW IFR5cGUgMjQyIC0gaS5lLiAtIElTSVMgcHJlc3VtYWJseSBoYXMgd2VsbCBkZWZpbmVkIGhhbmRs aW5nIGZvciBzdWItVExWcyAob2YgYXQgbGVhc3QgdHlwZSAyNDIpIHRoYXQgYXJlIG5vdCByZWNv Z25pemVkLiAgSWYgc28sIHRoYW4gdGhlIG5ldyBTdWItVExWIHR5cGVzIGRlZmluZWQgYXJlIGFs c28gbm90IGFuIGlzc3VlLg0KDQoNCg0KU2hvdWxkbid0IHRoaXMgc2VjdGlvbiBzYXkgc29tZXRo aW5nIGFsb25nIHRoZXNlIGxpbmVzPyAgSSBzdXNwZWN0IHRoYXQgaXQgd291bGQgYmUgbW9yZSBo ZWxwZnVsIGlmIHZlcmlmeWluZyB0aGUgY29udGVudCBvZiB0aGUgImNvbnNpZGVyYXRpb25zIiBz ZWN0aW9ucyB3ZXJlIG5vdCBsZWZ0IGFzIGFuIGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVyLiAg8J+Y ig0KDQoNCg0KTklUczoNCg0KSW4gdGhlIEludHJvZHVjdGlvbiwgdGhlIHBocmFzZSAibXVzdCBv ZnRlbiBiZSByZXBsYWNlZCIgc2VlbXMgdmVyeSBzbGlnaHRseSBwcm9ibGVtYXRpYyAoZXNwZWNp YWxseSBnaXZlbiB0aGlzIGlzIGEgc3RhbmRhcmRzIHRyYWNrIFJGQyB3YW5uYS1iZSkuICBXb3Vs ZCBpdCBiZSBiZXR0ZXIgdG8gc2F5ICJpcyBvZnRlbiByZXBsYWNlZCIgaW5zdGVhZD8NCg0KDQoN CkluIHNlY3Rpb24gMTcuMS4yIGFuZCAxNy4yIC0gJy4uLiBhICJJbnRlcmlvciBHYXRld2F5IC4u Licgc2hvdWxkIHByb2JhYmx5IGJlICcuLi4gYW4gIkludGVyaW9yIEdhdGV3YXkgLi4uIiBpbiBi b3RoIGNhc2VzLg0KDQoNCg0KLS0NCg0KRXJpYw0K --_000_MN2PR15MB31035D98D51D3A1E6C3B50F797030MN2PR15MB3103namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkhlbGxvLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2Vy IGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcg YWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3Vn aCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lh bCByZXF1ZXN0Lg0KIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Np c3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhl IFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUNCjxhIGhyZWY9Imh0dHBzOi8vdHJhYy50 b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIj5odHRwczovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvYT4uICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFy aWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBp ZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3Qg Q2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhl bSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcNCiB0aGUgZHJhZnQuIDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Eb2N1bWVudDogZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdv LTEyLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5SZXZpZXdlcjogRXJpYyBHcmF5PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5SZXZpZXcgRGF0ZTogMTYgT2N0b2JlciwgMjAyMDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SUVURiBMQyBFbmQgRGF0ZTogVW5rbm93bjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW50ZW5kZWQgU3RhdHVzOiBT dGFuZGFyZHMgVHJhY2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3VtbWFyeTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgZG9jdW1lbnQgaXMgd2Vs bCBvcmdhbml6ZWQsIHJlbGF0aXZlbHkgZWFzeSB0byByZWFkLCBhbmQgcHJvYmFibHkgcmVhZHkg Zm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIG9uZSBwb3RlbnRpYWwgbWlub3IgaXNzdWUgYW5kIGEg dmVyeSBzbWFsbCBudW1iZXIgb2YgTklUcyB0aGF0IG1pZ2h0IGJlIGNvbnNpZGVyZWQgcHJpb3Ig dG8gcHVibGljYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1ham9yIElzc3Vl czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5vbmU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+TWlub3IgSXNzdWVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+VGhlIHN0YXRlbWVudCBpbiBzZWN0aW9uIDE1IChCYWNrd2FyZCBD b21wYXRpYmlsaXR5KSAtICZxdW90O1RoaXMgZXh0ZW5zaW9uIGJyaW5ncyBubyBuZXcgYmFja3dh cmQgY29tcGF0aWJpbGl0eSBpc3N1ZXMmcXVvdDsgLSBzZWVtcyBzb21ld2hhdCBmbGlwLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIHN1c3BlY3QgdGhhdCBhIHRpbnkgYml0IG9mIGFu YWx5c2lzIHdvdWxkIG5vdCBodXJ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUg ZXh0ZW5zaW9ucyBpbiB0aGlzIGRyYWZ0IGFyZSBjbGVhcmx5IGludGVuZGVkIHRvIHdvcmsgaW4g YW4gZW52aXJvbm1lbnQgd2hlcmUgcm91dGVycyB0aGF0IF9kb19ub3RfIHN1cHBvcnQgdGhlc2Ug ZXh0ZW5zaW9ucyBhcmUgYWxzbyBkZXBsb3llZCwgYnV0IGFwcGFyZW50bHkgcmVsaWVzIG9uIGNv bmZpZ3VyYXRpb24gb2YgdGhvc2Ugcm91dGVycyB0aGF0IF9kb18gc3VwcG9ydCB0aGUgZXh0ZW5z aW9ucw0KIHRvIGFkZHJlc3MgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhh dCBzZWVtcyBjb3JyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Gcm9tIG15IHJl YWRpbmcgb2YgdGhlIGRyYWZ0ICh3aGljaCBJIGhhdmUgbm90IGNsb3NlbHkgZm9sbG93ZWQgZm9y IGl0cyBlbnRpcmUgZGV2ZWxvcG1lbnQpLCB3aGlsZSBpdCBpbnRyb2R1Y2VzIGF0IGxlYXN0IG9u ZSBuZXcgVExWLCB0aGUgT1NQRiByb3V0aW5nIHByb3RvY29sIGhhcyB3ZWxsIGRlZmluZWQgaGFu ZGxpbmcgZm9yIFRMVnMgdGhhdCBhcmUgbm90IHVuZGVyc3Rvb2QgLSBoZW5jZSB0aGUgaW50cm9k dWN0aW9uDQogb2Ygb25lIG9yIG1vcmUgbmV3IFRMVnMgc2hvdWxkIG5vdCBwcmVzZW50IGEgcHJv YmxlbSBpbiBPU1BGLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5PYnZpb3VzbHkgU3Vi LVRMVnMgb2YgdGhlIG5ldyBPU1BGIFRMViB0eXBlIHdpbGwgbm90IGludHJvZHVjZSBjb21wYXRp YmlsaXR5IGlzc3Vlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBhc3N1bWUgKGJ1 dCBkbyBub3QgYWN0dWFsbHkga25vdykgdGhhdCBhIHNpbWlsYXIgc2l0dWF0aW9uIGV4aXN0cyBm b3IgdGhlIG5ldyBJU0lTIEZBRCBTdWItVExWIG9mIHRoZSBleGlzdGluZyBUTFYgVHlwZSAyNDIg LSBpLmUuIC0gSVNJUyBwcmVzdW1hYmx5IGhhcyB3ZWxsIGRlZmluZWQgaGFuZGxpbmcgZm9yIHN1 Yi1UTFZzIChvZiBhdCBsZWFzdCB0eXBlIDI0MikgdGhhdCBhcmUgbm90IHJlY29nbml6ZWQuJm5i c3A7DQogSWYgc28sIHRoYW4gdGhlIG5ldyBTdWItVExWIHR5cGVzIGRlZmluZWQgYXJlIGFsc28g bm90IGFuIGlzc3VlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TaG91bGRuJ3QgdGhp cyBzZWN0aW9uIHNheSBzb21ldGhpbmcgYWxvbmcgdGhlc2UgbGluZXM/Jm5ic3A7IEkgc3VzcGVj dCB0aGF0IGl0IHdvdWxkIGJlIG1vcmUgaGVscGZ1bCBpZiB2ZXJpZnlpbmcgdGhlIGNvbnRlbnQg b2YgdGhlICZxdW90O2NvbnNpZGVyYXRpb25zJnF1b3Q7IHNlY3Rpb25zIHdlcmUgbm90IGxlZnQg YXMgYW4gZXhlcmNpc2UgZm9yIHRoZSByZWFkZXIuJm5ic3A7DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjg1MjI7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5OSVRzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SW4gdGhlIEludHJvZHVjdGlvbiwgdGhlIHBocmFzZSAmcXVvdDttdXN0IG9mdGVuIGJlIHJlcGxh Y2VkJnF1b3Q7IHNlZW1zIHZlcnkgc2xpZ2h0bHkgcHJvYmxlbWF0aWMgKGVzcGVjaWFsbHkgZ2l2 ZW4gdGhpcyBpcyBhIHN0YW5kYXJkcyB0cmFjayBSRkMgd2FubmEtYmUpLiZuYnNwOyBXb3VsZCBp dCBiZSBiZXR0ZXIgdG8gc2F5ICZxdW90O2lzIG9mdGVuIHJlcGxhY2VkJnF1b3Q7IGluc3RlYWQ/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gc2VjdGlvbiAxNy4xLjIgYW5kIDE3 LjIgLSAnLi4uIGEgJnF1b3Q7SW50ZXJpb3IgR2F0ZXdheSAuLi4nIHNob3VsZCBwcm9iYWJseSBi ZSAnLi4uIGFuICZxdW90O0ludGVyaW9yIEdhdGV3YXkgLi4uJnF1b3Q7IGluIGJvdGggY2FzZXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RXJpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_MN2PR15MB31035D98D51D3A1E6C3B50F797030MN2PR15MB3103namp_-- From nobody Fri Oct 16 12:59:18 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DE73A0AAF; Fri, 16 Oct 2020 12:59:13 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GL4KDWoD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WL8iNc/Y 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 mvShBNexp0fj; Fri, 16 Oct 2020 12:59:11 -0700 (PDT) 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 A931D3A0AAB; Fri, 16 Oct 2020 12:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19190; q=dns/txt; s=iport; t=1602878350; x=1604087950; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IORvhKHeU++UdfesXccOivJyKxBDhSZxRz+oMhK0TB4=; b=GL4KDWoDkztmS7PRnxQJO4wsHyB1pr16WZx1NljFmOR/P9WlSEIX2tcU 6uOrQSZDTNuDKwDPWryPxdHgDweoEG58caAcv3A7jicS767OgjmSsJQEm puSF2RXgSA7dembeGOb4wmv/6VfVU//KkxYozrmnfX2VzjmhLa4mwX4hx w=; IronPort-PHdr: =?us-ascii?q?9a23=3AsVgMVRHVxD3r+9e7k9d4y51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gObUYDS8fkCiufKvebnQ2NTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrni79zVUGx?= =?us-ascii?q?jjO0xyPOumUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwR?= =?us-ascii?q?rSqXwOcONTlm4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1CgBc+olf/5xdJa1gHgEBCxIMgzI?= =?us-ascii?q?vUQdwWS8shD2DSQONS4ECkwmEb4JTA1UDCAEBAQ0BASUIAgQBAYRKAheBdAI?= =?us-ascii?q?lOBMCAwEBCwEBBQEBAQIBBgRthWEMhXIBAQEBAxIRChMBATcBDwIBBgIRAwE?= =?us-ascii?q?BASsCAgIwHQgBAQQBDQUIGoMFgX5NAy4BDpJykGkCgTmIaHaBMoMEAQEFhQ4?= =?us-ascii?q?YghADBoE4gnKCYBI6QoZWG4FBP4EQAUOCGDU+glwCAoFfFQkGB4JqM4IskDm?= =?us-ascii?q?DGYcPJotekRkKgmqIAoECkg6DFooIhUeOaZMvinORC4QuAgQCBAUCDgEBBYF?= =?us-ascii?q?rI4FXcBWDJFAXAg2OH4NxhRSFQnQCNgIDAwEJAQEDCXyNTAEB?= X-IronPort-AV: E=Sophos;i="5.77,383,1596499200"; d="scan'208,217";a="564523331" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Oct 2020 19:59:09 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 09GJx9qQ009692 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2020 19:59:09 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 16 Oct 2020 14:59:08 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 16 Oct 2020 15:59:08 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 16 Oct 2020 15:59:07 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hDwebjpJs63OjYDFdJsZ/xz5Ul5VUfu1YgsJ4YwGkOcHGz4Ye9+3hRXmA78X38dyIw9E08p2YMQbyLFW8zyEKsucKLJBGCgj/vq3PbXjcOkBLsQd9jz0FAjoD+DWRgLyqNkePcrIiooaMsTiwmSdG1Yo1SRmWZ4Ef+A1/joiRmSi4pVW/jEr3qWgdXzn7vcpvRQsT308BrWduZMklbic8uoh3Z15GOKYRyAMaLEw7XSgoEXWRI8RpK6ufiG2Y4fwoVfGUgwzNI7VMzHBTfTrQ99+328ScDFYf5YG7M6bL1WOmInIupjnGdFo5jV8f0HLFU7yOtmZ4iUMLLDPqS0Crg== 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=IORvhKHeU++UdfesXccOivJyKxBDhSZxRz+oMhK0TB4=; b=gBYSKpsgT/GdN1G4hivTjo5tMXfspRfvXsftt4VyMk9r3XqI/B9bM0oraJiGRN4iKdj/7RI8iXWQMh1QdaVxnRasuIi0/nepSG952B+QmG5YcSR7dbz3+8ZkifuqMK6fUUffQ5NrIY0zlGUFH9PpphroS9+s0fhY8Q0SyW7UZsm94zb7y6SsijMhRsefIH6/WV9k0iVnv7URIRHi6LzqyLargabMFYdNRpAj0Mhb0BUPVRWA0EU2LnJ8uNctCDLUZm2CVEBsrdSN90t+YABRgMKgwQLhluA5mxCBrqm9jxL8M/cXGiOJazWXGZ9SOYcKy0mdOW9MKENlb6SFWXVyVA== 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=IORvhKHeU++UdfesXccOivJyKxBDhSZxRz+oMhK0TB4=; b=WL8iNc/YkoqKmnTuyMWSib8gyAkNzLIcNbofZCc7xKtFy8O7SpGQXVvtlwmnIYvUInbuDU+fIAuxrlogJjlwNa1kdEOynT+hAw9nvWQ+50tD3iGF+UCkUp3kSvglec8ZjjciA7bQS2nFpIoC243HYLgFu8BQG7y/ohD1XuQHwz8= Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB3640.namprd11.prod.outlook.com (2603:10b6:a03:f7::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.25; Fri, 16 Oct 2020 19:59:06 +0000 Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf%3]) with mapi id 15.20.3455.030; Fri, 16 Oct 2020 19:59:06 +0000 From: "Les Ginsberg (ginsberg)" To: Eric Gray , "rtg-ads@ietf.org" , "lsr-chairs@ietf.org" CC: "rtg-dir@ietf.org" , "lsr@ietf.org" Thread-Topic: Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo Thread-Index: Adaj5RbuL4NRT3uMSN6SXWsPfNq1nQAEEu1A Date: Fri, 16 Oct 2020 19:59:06 +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: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2602:306:36ca:6640:2d9a:f9b6:44f7:40a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 36b16de2-97f4-47f1-3572-08d8720df06b x-ms-traffictypediagnostic: BYAPR11MB3640: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YXv9TWCQz54ZkWMn3eEEeghTU1DHvs0Iz1xBkmgRdUni5AFpVu+2xVUcl6H26EdIIA+pPJyWWGLxiGewSqO/WbmZqXNwnThpVpyryXtAjQ6TtGwcUBdbouCz4tCi+3A5/PBFTrd1+xjFF8iS2WjXPFscMJosmUNlyriz/rdefuc7Z6ymkB/u+MajhE3WOS8r4zwp1cIp1/kAgkZ4hudNU6ekz76tMbvyfTAWOjQN8FWC0uFVys6CWlHoBvFKaTbRfOw5OiREeGQRGa6kECYViPx6FRcS1kYH4s0n3rQd4356nYlsMRq1zfR4WmDjf1nsw7n8kycrbZq6bApbye8IP8PbG+Xq2WZEXNIGrra8q2m06gOLSUvkKSow3fPiaslaEiCJ6+iWZVeJHgJsvo/Nmw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(136003)(376002)(366004)(39860400002)(316002)(83380400001)(8936002)(966005)(86362001)(166002)(55016002)(186003)(53546011)(6506007)(7696005)(478600001)(71200400001)(52536014)(4326008)(66476007)(66556008)(54906003)(66946007)(110136005)(76116006)(64756008)(66446008)(8676002)(9686003)(5660300002)(33656002)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: mULwEPz3eqR7iCRbhLfIBI7Lw7ySSSkkaijz6Xd4Ro2RazyvGGZqF1PRki0O9doI2o/y68WvI/6FeyIgyngyZRa5gGgC90T3O+oFiEnWolTFrMQqwXmkAO1uxq+8G+rGUyzLKjcL2OyAZ/DsjtKTYwF1bkeBZM55SBZNPMKJFtThaZSMj8BONtwaEcAgS6zRdEsamHOvPenazEkdSZeV6vGXoeiWHJUnOrIiQTNJvoonhEffCar45ho9MGoBvCBPef6I8QYNOeHS6u+RNYP+zAolHJLy+q500d1rAzuNM/otzAhOuW9L97+JuOfUpHsfKHGMaV5OZwGHuwRbjPjwls4BpLZXdusst8XKPHN14XSiQcgpP7Oj1eQc1wU5bqDiJIbW2GXP9B9H0w2SF9p9dmHWTETtgQYBuJbVcLbhd25mYPYuWePieAm3CSO1uxm9Y0MRrtYH8phhFzBgvKioEmZpG5Hryw/YaqjvQ60fu7NAQRbSYvzfHDBLikJ/et0L4azoBQolJ4jrnke25odSamp34NBZf4PZPtkDiunRRHP7+mQ7wHC4leB8H5n4AoTgbFBCJAj/2Zkyxd1mdG1FBwf9Y01oieTF7ygtJ6TH75ReXlpNvs/6sJWkIrWRcRVSeYWcJ1UG37hgHm1HuQqwmBrakcmO7N+XzyBox1HJ83C+EcjzZuBMXRtzBgRkdaJbeKDgZikG5Ext7w9IiVAr5g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR11MB43373DE4609578B4074F1813C1030BY5PR11MB4337namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36b16de2-97f4-47f1-3572-08d8720df06b X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 19:59:06.5864 (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: 50tESIgaRNExZ1hBhmm0a/NsflOPLCi1QuWKR8/IHDlxTYp/cWDF/kC1i2TopU4AtsT1ZPQyg55sPNp+YjTYWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3640 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 19:59:14 -0000 --_000_BY5PR11MB43373DE4609578B4074F1813C1030BY5PR11MB4337namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXJpYyDigJMNCg0KSSB3aWxsIGxldCB0aGUgZHJhZnQgYXV0aG9ycyByZXNwb25kIHRvIHRoZSBi dWxrIG9mIHlvdXIgY29tbWVudHMuIEJ1dCBpbiByZWdhcmRzIHRvIHlvdXIgcXVlc3Rpb24vY29t bWVudDoNCg0K4oCcSSBhc3N1bWUgKGJ1dCBkbyBub3QgYWN0dWFsbHkga25vdykgdGhhdCBhIHNp bWlsYXIgc2l0dWF0aW9uIGV4aXN0cyBmb3IgdGhlIG5ldyBJU0lTIEZBRCBTdWItVExWIG9mIHRo ZSBleGlzdGluZyBUTFYgVHlwZSAyNDIgLSBpLmUuIC0gSVNJUyBwcmVzdW1hYmx5IGhhcyB3ZWxs IGRlZmluZWQgaGFuZGxpbmcgZm9yIHN1Yi1UTFZzIChvZiBhdCBsZWFzdCB0eXBlIDI0MikgdGhh dCBhcmUgbm90IHJlY29nbml6ZWQuICBJZiBzbywgdGhhbiB0aGUgbmV3IFN1Yi1UTFYgdHlwZXMg ZGVmaW5lZCBhcmUgYWxzbyBub3QgYW4gaXNzdWUu4oCdDQoNCkluZGVlZCwgYmFzZSBiZWhhdmlv ciBmb3IgdGhlIElTLUlTIHByb3RvY29sIGFzIGRlZmluZWQgaW4gSVNPIDEwNTg5IGlzIHRvIGln bm9yZSB1bnJlY29nbml6ZWQgVExWcyAtIGFuZCB0aGlzIGV4dGVuZHMgdG8gdW5yZWNvZ25pemVk IHN1Yi1UTFZzIGFzIHdlbGwuIFRoaXMgaXMga2V5IHRvIHRoZSBhYmlsaXR5IHRvIGludHJvZHVj ZSB0aGUgbWFueSBleHRlbnNpb25zIHRoYXQgaGF2ZSBiZWVuIGRlZmluZWQgYnkgdGhlIHBsZXRo b3JhIG9mIElTLUlTIFJGQ3Mgb3ZlciB0aGUgbGFzdCAyMCsgeWVhcnMuDQpUaGlzIHBvaW50IGlz IGZ1cnRoZXIgZGlzY3Vzc2VkIGluIHRoZSByZWNlbnRseSBwdWJsaXNoZWQ6DQoNCmh0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM4OTE4Lmh0bWwjbmFtZS1oYW5kbGluZy1vZi1kaXNh bGxvd2VkLXRsdnMNCg0KU28gSSB0aGluayB5b3VyIGNvbmNlcm5zIGFib3V0IGJhY2t3YXJkcyBj b21wYXRpYmlsaXR5IGFyZSB1bndhcnJhbnRlZC4gSW4gcGFydGljdWxhciB0aGUgc3RhdGVtZW50 Og0KDQrigJxbYmFja3dhcmRzIGNvbXBhdGliaWxpdHldIGFwcGFyZW50bHkgcmVsaWVzIG9uIGNv bmZpZ3VyYXRpb24gb2YgdGhvc2Ugcm91dGVycyB0aGF0IF9kb18gc3VwcG9ydCB0aGUgZXh0ZW5z aW9ucyB0byBhZGRyZXNzIHRoaXPigJ0NCg0KSXMgbm90IGNvcnJlY3QuDQoNCiAgIExlcw0KDQpG cm9tOiBydGctZGlyIDxydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBFcmlj IEdyYXkNClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNiwgMjAyMCAxMTo0OSBBTQ0KVG86IHJ0Zy1h ZHNAaWV0Zi5vcmc7IGxzci1jaGFpcnNAaWV0Zi5vcmcNCkNjOiBydGctZGlyQGlldGYub3JnOyBs c3JAaWV0Zi5vcmcNClN1YmplY3Q6IFtSVEctRElSXSBSdGctRGlyIExhc3QgQ2FsbCByZXZpZXcg b2YgZHJhZnQtaWV0Zi1sc3ItZmxleC1hbGdvDQoNCg0KSGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNl bGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0 LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Ig cm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2Fs bCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUg cHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91 dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9y YXRlLCBwbGVhc2Ugc2VlIGh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFj L3dpa2kvUnRnRGlyLg0KDQoNCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmls eSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYg eW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENh bGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0g dGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCg0KDQoNCkRvY3Vt ZW50OiBkcmFmdC1pZXRmLWxzci1mbGV4LWFsZ28tMTIudHh0DQoNCg0KDQpSZXZpZXdlcjogRXJp YyBHcmF5DQoNClJldmlldyBEYXRlOiAxNiBPY3RvYmVyLCAyMDIwDQoNCklFVEYgTEMgRW5kIERh dGU6IFVua25vd24NCg0KSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNCg0KDQoNClN1 bW1hcnk6DQoNClRoaXMgZG9jdW1lbnQgaXMgd2VsbCBvcmdhbml6ZWQsIHJlbGF0aXZlbHkgZWFz eSB0byByZWFkLCBhbmQgcHJvYmFibHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIG9u ZSBwb3RlbnRpYWwgbWlub3IgaXNzdWUgYW5kIGEgdmVyeSBzbWFsbCBudW1iZXIgb2YgTklUcyB0 aGF0IG1pZ2h0IGJlIGNvbnNpZGVyZWQgcHJpb3IgdG8gcHVibGljYXRpb24uDQoNCg0KDQpNYWpv ciBJc3N1ZXM6DQoNCk5vbmUNCg0KDQoNCk1pbm9yIElzc3VlczoNCg0KVGhlIHN0YXRlbWVudCBp biBzZWN0aW9uIDE1IChCYWNrd2FyZCBDb21wYXRpYmlsaXR5KSAtICJUaGlzIGV4dGVuc2lvbiBi cmluZ3Mgbm8gbmV3IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzIiAtIHNlZW1zIHNvbWV3 aGF0IGZsaXAuDQoNCg0KDQpJIHN1c3BlY3QgdGhhdCBhIHRpbnkgYml0IG9mIGFuYWx5c2lzIHdv dWxkIG5vdCBodXJ0Lg0KDQoNCg0KVGhlIGV4dGVuc2lvbnMgaW4gdGhpcyBkcmFmdCBhcmUgY2xl YXJseSBpbnRlbmRlZCB0byB3b3JrIGluIGFuIGVudmlyb25tZW50IHdoZXJlIHJvdXRlcnMgdGhh dCBfZG9fbm90XyBzdXBwb3J0IHRoZXNlIGV4dGVuc2lvbnMgYXJlIGFsc28gZGVwbG95ZWQsIGJ1 dCBhcHBhcmVudGx5IHJlbGllcyBvbiBjb25maWd1cmF0aW9uIG9mIHRob3NlIHJvdXRlcnMgdGhh dCBfZG9fIHN1cHBvcnQgdGhlIGV4dGVuc2lvbnMgdG8gYWRkcmVzcyB0aGlzLg0KDQoNCg0KVGhh dCBzZWVtcyBjb3JyZWN0Lg0KDQoNCg0KRnJvbSBteSByZWFkaW5nIG9mIHRoZSBkcmFmdCAod2hp Y2ggSSBoYXZlIG5vdCBjbG9zZWx5IGZvbGxvd2VkIGZvciBpdHMgZW50aXJlIGRldmVsb3BtZW50 KSwgd2hpbGUgaXQgaW50cm9kdWNlcyBhdCBsZWFzdCBvbmUgbmV3IFRMViwgdGhlIE9TUEYgcm91 dGluZyBwcm90b2NvbCBoYXMgd2VsbCBkZWZpbmVkIGhhbmRsaW5nIGZvciBUTFZzIHRoYXQgYXJl IG5vdCB1bmRlcnN0b29kIC0gaGVuY2UgdGhlIGludHJvZHVjdGlvbiBvZiBvbmUgb3IgbW9yZSBu ZXcgVExWcyBzaG91bGQgbm90IHByZXNlbnQgYSBwcm9ibGVtIGluIE9TUEYuDQoNCg0KDQpPYnZp b3VzbHkgU3ViLVRMVnMgb2YgdGhlIG5ldyBPU1BGIFRMViB0eXBlIHdpbGwgbm90IGludHJvZHVj ZSBjb21wYXRpYmlsaXR5IGlzc3Vlcy4NCg0KDQoNCkkgYXNzdW1lIChidXQgZG8gbm90IGFjdHVh bGx5IGtub3cpIHRoYXQgYSBzaW1pbGFyIHNpdHVhdGlvbiBleGlzdHMgZm9yIHRoZSBuZXcgSVNJ UyBGQUQgU3ViLVRMViBvZiB0aGUgZXhpc3RpbmcgVExWIFR5cGUgMjQyIC0gaS5lLiAtIElTSVMg cHJlc3VtYWJseSBoYXMgd2VsbCBkZWZpbmVkIGhhbmRsaW5nIGZvciBzdWItVExWcyAob2YgYXQg bGVhc3QgdHlwZSAyNDIpIHRoYXQgYXJlIG5vdCByZWNvZ25pemVkLiAgSWYgc28sIHRoYW4gdGhl IG5ldyBTdWItVExWIHR5cGVzIGRlZmluZWQgYXJlIGFsc28gbm90IGFuIGlzc3VlLg0KDQoNCg0K U2hvdWxkbid0IHRoaXMgc2VjdGlvbiBzYXkgc29tZXRoaW5nIGFsb25nIHRoZXNlIGxpbmVzPyAg SSBzdXNwZWN0IHRoYXQgaXQgd291bGQgYmUgbW9yZSBoZWxwZnVsIGlmIHZlcmlmeWluZyB0aGUg Y29udGVudCBvZiB0aGUgImNvbnNpZGVyYXRpb25zIiBzZWN0aW9ucyB3ZXJlIG5vdCBsZWZ0IGFz IGFuIGV4ZXJjaXNlIGZvciB0aGUgcmVhZGVyLiAg8J+Yig0KDQoNCg0KTklUczoNCg0KSW4gdGhl IEludHJvZHVjdGlvbiwgdGhlIHBocmFzZSAibXVzdCBvZnRlbiBiZSByZXBsYWNlZCIgc2VlbXMg dmVyeSBzbGlnaHRseSBwcm9ibGVtYXRpYyAoZXNwZWNpYWxseSBnaXZlbiB0aGlzIGlzIGEgc3Rh bmRhcmRzIHRyYWNrIFJGQyB3YW5uYS1iZSkuICBXb3VsZCBpdCBiZSBiZXR0ZXIgdG8gc2F5ICJp cyBvZnRlbiByZXBsYWNlZCIgaW5zdGVhZD8NCg0KDQoNCkluIHNlY3Rpb24gMTcuMS4yIGFuZCAx Ny4yIC0gJy4uLiBhICJJbnRlcmlvciBHYXRld2F5IC4uLicgc2hvdWxkIHByb2JhYmx5IGJlICcu Li4gYW4gIkludGVyaW9yIEdhdGV3YXkgLi4uIiBpbiBib3RoIGNhc2VzLg0KDQoNCg0KLS0NCg0K RXJpYw0K --_000_BY5PR11MB43373DE4609578B4074F1813C1030BY5PR11MB4337namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9z ZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj MDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u UGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FcmljIOKAkzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHdpbGwgbGV0IHRoZSBkcmFmdCBhdXRob3JzIHJlc3BvbmQgdG8g dGhlIGJ1bGsgb2YgeW91ciBjb21tZW50cy4gQnV0IGluIHJlZ2FyZHMgdG8geW91ciBxdWVzdGlv bi9jb21tZW50OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxJIGFzc3VtZSAoYnV0IGRvIG5v dCBhY3R1YWxseSBrbm93KSB0aGF0IGEgc2ltaWxhciBzaXR1YXRpb24gZXhpc3RzIGZvciB0aGUg bmV3IElTSVMgRkFEIFN1Yi1UTFYgb2YgdGhlIGV4aXN0aW5nIFRMViBUeXBlIDI0MiAtIGkuZS4g LSBJU0lTIHByZXN1bWFibHkgaGFzIHdlbGwgZGVmaW5lZCBoYW5kbGluZyBmb3Igc3ViLVRMVnMg KG9mIGF0IGxlYXN0IHR5cGUgMjQyKSB0aGF0IGFyZSBub3QgcmVjb2duaXplZC4mbmJzcDsNCiBJ ZiBzbywgdGhhbiB0aGUgbmV3IFN1Yi1UTFYgdHlwZXMgZGVmaW5lZCBhcmUgYWxzbyBub3QgYW4g aXNzdWUu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluZGVlZCwgYmFzZSBiZWhhdmlvciBm b3IgdGhlIElTLUlTIHByb3RvY29sIGFzIGRlZmluZWQgaW4gSVNPIDEwNTg5IGlzIHRvIGlnbm9y ZSB1bnJlY29nbml6ZWQgVExWcyAtIGFuZCB0aGlzIGV4dGVuZHMgdG8gdW5yZWNvZ25pemVkIHN1 Yi1UTFZzIGFzIHdlbGwuIFRoaXMgaXMga2V5IHRvIHRoZSBhYmlsaXR5IHRvIGludHJvZHVjZSB0 aGUgbWFueSBleHRlbnNpb25zIHRoYXQgaGF2ZSBiZWVuIGRlZmluZWQNCiBieSB0aGUgcGxldGhv cmEgb2YgSVMtSVMgUkZDcyBvdmVyIHRoZSBsYXN0IDIwKyB5ZWFycy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgcG9pbnQgaXMgZnVydGhlciBkaXNjdXNzZWQgaW4g dGhlIHJlY2VudGx5IHB1Ymxpc2hlZDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0i aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg5MTguaHRtbCNuYW1lLWhhbmRsaW5n LW9mLWRpc2FsbG93ZWQtdGx2cyI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzg5 MTguaHRtbCNuYW1lLWhhbmRsaW5nLW9mLWRpc2FsbG93ZWQtdGx2czwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U28gSSB0aGluayB5b3VyIGNvbmNlcm5zIGFib3V0IGJhY2t3YXJkcyBjb21w YXRpYmlsaXR5IGFyZSB1bndhcnJhbnRlZC4gSW4gcGFydGljdWxhciB0aGUgc3RhdGVtZW50Ojxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxbYmFja3dhcmRzIGNvbXBhdGliaWxpdHldIGFwcGFy ZW50bHkgcmVsaWVzIG9uIGNvbmZpZ3VyYXRpb24gb2YgdGhvc2Ugcm91dGVycyB0aGF0IF9kb18g c3VwcG9ydCB0aGUgZXh0ZW5zaW9ucyB0byBhZGRyZXNzIHRoaXPigJ08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXMgbm90IGNvcnJlY3QuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsm bmJzcDsgTGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IHJ0Zy1kaXIg Jmx0O3J0Zy1kaXItYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mDQo8L2I+RXJp YyBHcmF5PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAxNiwgMjAyMCAxMTo0OSBB TTxicj4NCjxiPlRvOjwvYj4gcnRnLWFkc0BpZXRmLm9yZzsgbHNyLWNoYWlyc0BpZXRmLm9yZzxi cj4NCjxiPkNjOjwvYj4gcnRnLWRpckBpZXRmLm9yZzsgbHNyQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtSVEctRElSXSBSdGctRGlyIExhc3QgQ2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1sc3ItZmxleC1hbGdvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5IZWxsbywgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGhhdmUg YmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhp cyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0 aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBs YXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVz dC4NCiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0 byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5n IERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo8YSBocmVmPSJodHRwczovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+aHR0cHM6Ly90cmFjLnRvb2xzLmlldGYu b3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8L2E+LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3Ig dGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNv dWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29t bWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3Vn aCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nDQogdGhlIGRyYWZ0LiA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+RG9jdW1lbnQ6IGRyYWZ0LWlldGYtbHNyLWZsZXgtYWxnby0xMi50eHQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+UmV2aWV3ZXI6IEVyaWMgR3JheTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+UmV2aWV3IERhdGU6IDE2IE9jdG9iZXIsIDIwMjA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPklFVEYgTEMgRW5kIERhdGU6IFVua25vd248bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkludGVuZGVkIFN0YXR1czogU3RhbmRhcmRz IFRyYWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlN1bW1hcnk6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIGRvY3VtZW50IGlzIHdlbGwgb3JnYW5p emVkLCByZWxhdGl2ZWx5IGVhc3kgdG8gcmVhZCwgYW5kIHByb2JhYmx5IHJlYWR5IGZvciBwdWJs aWNhdGlvbiwgYnV0IGhhcyBvbmUgcG90ZW50aWFsIG1pbm9yIGlzc3VlIGFuZCBhIHZlcnkgc21h bGwgbnVtYmVyIG9mIE5JVHMgdGhhdCBtaWdodCBiZSBjb25zaWRlcmVkIHByaW9yIHRvIHB1Ymxp Y2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NYWpvciBJc3N1ZXM6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ob25lPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPk1pbm9yIElzc3Vlczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlRoZSBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAxNSAoQmFja3dhcmQgQ29tcGF0aWJp bGl0eSkgLSAmcXVvdDtUaGlzIGV4dGVuc2lvbiBicmluZ3Mgbm8gbmV3IGJhY2t3YXJkIGNvbXBh dGliaWxpdHkgaXNzdWVzJnF1b3Q7IC0gc2VlbXMgc29tZXdoYXQgZmxpcC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SSBzdXNwZWN0IHRoYXQgYSB0aW55IGJpdCBvZiBhbmFseXNpcyB3 b3VsZCBub3QgaHVydC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGV4dGVuc2lv bnMgaW4gdGhpcyBkcmFmdCBhcmUgY2xlYXJseSBpbnRlbmRlZCB0byB3b3JrIGluIGFuIGVudmly b25tZW50IHdoZXJlIHJvdXRlcnMgdGhhdCBfZG9fbm90XyBzdXBwb3J0IHRoZXNlIGV4dGVuc2lv bnMgYXJlIGFsc28gZGVwbG95ZWQsIGJ1dCBhcHBhcmVudGx5IHJlbGllcyBvbiBjb25maWd1cmF0 aW9uIG9mIHRob3NlIHJvdXRlcnMgdGhhdCBfZG9fIHN1cHBvcnQgdGhlIGV4dGVuc2lvbnMNCiB0 byBhZGRyZXNzIHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYXQgc2VlbXMg Y29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RnJvbSBteSByZWFkaW5nIG9m IHRoZSBkcmFmdCAod2hpY2ggSSBoYXZlIG5vdCBjbG9zZWx5IGZvbGxvd2VkIGZvciBpdHMgZW50 aXJlIGRldmVsb3BtZW50KSwgd2hpbGUgaXQgaW50cm9kdWNlcyBhdCBsZWFzdCBvbmUgbmV3IFRM ViwgdGhlIE9TUEYgcm91dGluZyBwcm90b2NvbCBoYXMgd2VsbCBkZWZpbmVkIGhhbmRsaW5nIGZv ciBUTFZzIHRoYXQgYXJlIG5vdCB1bmRlcnN0b29kIC0gaGVuY2UgdGhlIGludHJvZHVjdGlvbg0K IG9mIG9uZSBvciBtb3JlIG5ldyBUTFZzIHNob3VsZCBub3QgcHJlc2VudCBhIHByb2JsZW0gaW4g T1NQRi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T2J2aW91c2x5IFN1Yi1UTFZzIG9m IHRoZSBuZXcgT1NQRiBUTFYgdHlwZSB3aWxsIG5vdCBpbnRyb2R1Y2UgY29tcGF0aWJpbGl0eSBp c3N1ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgYXNzdW1lIChidXQgZG8gbm90 IGFjdHVhbGx5IGtub3cpIHRoYXQgYSBzaW1pbGFyIHNpdHVhdGlvbiBleGlzdHMgZm9yIHRoZSBu ZXcgSVNJUyBGQUQgU3ViLVRMViBvZiB0aGUgZXhpc3RpbmcgVExWIFR5cGUgMjQyIC0gaS5lLiAt IElTSVMgcHJlc3VtYWJseSBoYXMgd2VsbCBkZWZpbmVkIGhhbmRsaW5nIGZvciBzdWItVExWcyAo b2YgYXQgbGVhc3QgdHlwZSAyNDIpIHRoYXQgYXJlIG5vdCByZWNvZ25pemVkLiZuYnNwOw0KIElm IHNvLCB0aGFuIHRoZSBuZXcgU3ViLVRMViB0eXBlcyBkZWZpbmVkIGFyZSBhbHNvIG5vdCBhbiBp c3N1ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2hvdWxkbid0IHRoaXMgc2VjdGlv biBzYXkgc29tZXRoaW5nIGFsb25nIHRoZXNlIGxpbmVzPyZuYnNwOyBJIHN1c3BlY3QgdGhhdCBp dCB3b3VsZCBiZSBtb3JlIGhlbHBmdWwgaWYgdmVyaWZ5aW5nIHRoZSBjb250ZW50IG9mIHRoZSAm cXVvdDtjb25zaWRlcmF0aW9ucyZxdW90OyBzZWN0aW9ucyB3ZXJlIG5vdCBsZWZ0IGFzIGFuIGV4 ZXJjaXNlIGZvciB0aGUgcmVhZGVyLiZuYnNwOw0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4NTIyOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+TklUczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIHRoZSBJ bnRyb2R1Y3Rpb24sIHRoZSBwaHJhc2UgJnF1b3Q7bXVzdCBvZnRlbiBiZSByZXBsYWNlZCZxdW90 OyBzZWVtcyB2ZXJ5IHNsaWdodGx5IHByb2JsZW1hdGljIChlc3BlY2lhbGx5IGdpdmVuIHRoaXMg aXMgYSBzdGFuZGFyZHMgdHJhY2sgUkZDIHdhbm5hLWJlKS4mbmJzcDsgV291bGQgaXQgYmUgYmV0 dGVyIHRvIHNheSAmcXVvdDtpcyBvZnRlbiByZXBsYWNlZCZxdW90OyBpbnN0ZWFkPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkluIHNlY3Rpb24gMTcuMS4yIGFuZCAxNy4yIC0gJy4u LiBhICZxdW90O0ludGVyaW9yIEdhdGV3YXkgLi4uJyBzaG91bGQgcHJvYmFibHkgYmUgJy4uLiBh biAmcXVvdDtJbnRlcmlvciBHYXRld2F5IC4uLiZxdW90OyBpbiBib3RoIGNhc2VzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkVyaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_BY5PR11MB43373DE4609578B4074F1813C1030BY5PR11MB4337namp_-- From nobody Sun Oct 18 19:08:14 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F743A1218; Sun, 18 Oct 2020 19:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 j153hJW39M9I; Sun, 18 Oct 2020 19:08:10 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C273A1167; Sun, 18 Oct 2020 19:08:07 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 1745F47981; Mon, 19 Oct 2020 10:08:03 +0800 (CST) From: "Aijun Wang" To: "'Christian Hopps'" Cc: "'John E Drake'" , , "'Les Ginsberg \(ginsberg\)'" , , "'Jeff Tantsura'" , , References: <303E621F-47AA-4309-AC85-32A597604C7C@chopps.org> In-Reply-To: <303E621F-47AA-4309-AC85-32A597604C7C@chopps.org> Date: Mon, 19 Oct 2020 10:08:00 +0800 Message-ID: <00b401d6a5bc$ac44e800$04ceb800$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGsG2Mrpx4Nm+qaEBWGzRMrcJ3TyQFhBU4MqegrwZA= Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZH0sZSksYGE5CTxpCVkpNS0hLTEhJQ0hPQ0lVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0NISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PRA6Mhw*Pj8pCTI6FjQiOToV PQIwCRRVSlVKTUtIS0xISUNPSk5PVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpPTkhKNwY+ X-HM-Tid: 0a753e9d15389865kuuu1745f47981 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 02:08:13 -0000 Hi, Chris: I think we have "put the cart before the horse". For protocol extension = draft, the origin is the use case.=20 And I think we will not expand OSPF protocol, just because it lack = something as compared with ISIS, right? As I stated before, the use case in current appendix is the main = motivation of this draft, you can see this in main body of the earlier = version of this draft(from version 0 to version 5).=20 The reason that we move this part to the appendix, as that you said, is = to let person focus on the protocol extension itself. Moving this part to appendix is acceptable, but removing it from the = draft will erase the origin of this document.=20 Is it reasonable that one document discusses the "origin"(of the = prefix), can't keep its origin? More replies inline below[WAJ]. Best Regards Aijun Wang China Telecom =20 =20 -----Original Message----- From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Christian Hopps Sent: Friday, October 16, 2020 10:47 PM To: =E7=8E=8B=E7=88=B1=E4=BF=8A Cc: John E Drake ; Christian Hopps = ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) = ; lsr@ietf.org; Jeff Tantsura = ; = draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr-ads@ietf.org Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Isn't this just adding an analogous extension that already exists in = RFC7794? [WAJ] No. RFC7794 is just one example that to illustrate, as the = companion IGP protocol, OSPF can also accomplish this. And, actually, = there are differences consideration in this draft for the protocol = extension. I don't think we need to do a lot of convincing at this point. I agree = with Les, if you want to talk about use cases (especially ones that are = controversial!) then the correct place for that is in a new informative = draft.=20 [WAJ] we have discussed the use case before and state the discussion = results at the appendix part. We will not emphasis and expand the use = case more. If one does not agree the statement of this appendix, we can = discuss online or offline. We just need to make the statement in = appendix is correct.=20 Otherwise, especially if the cases are controversial, this can be seen = as doing an "end-run" to avoid the debate b/c people want the extension, = but maybe don't agree with your use case.=20 [WAJ] One should point out which statement in the appendix is = controversial, we can correct it. This use case is the origin of this = draft, not the results. Legislators do this sometimes adding things they want personally to = popular bills, that other people may not want, but since people want the = main bill they vote for it anyway, in the US it's called "adding pork" = or "pork barrel politics". :) [WAJ] The appendix is not added later, but exist at the first beginning. = This is the origin of the bills.=20 Thanks, Chris. > On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A = wrote: >=20 >=20 > Hi, Chris: > Originally, the appendix part is within the document, which is the = start point/main motivation to extend the prefix origin. > There may exists other usages of this information. Pack these examples = into some short sentences or introduction is viable, but expand some of = them is also helpful. > As I known, when we want to do protocol extension, we should always = convince other the reason/motivation/prospects to do so. On the other = hand, the use case described in the current appendix is very prominent = for operator to accomplish the TE task in multi-area environment. >=20 > Aijun Wang >=20 > =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps = <chopps@chopps.org>=E5=86=99=E9=81=93: > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps = <chopps@chopps.org> > =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: = 2020=E5=B9=B410=E6=9C=8816=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94 > =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)"=20 > <ginsberg=3D40cisco.com@dmarc.ietf.org>] > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 >=20 > > On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) = wrote: > > > > Aijun - > > > > The point I am making is very focused. > > > > This draft is defining a protocol extension. As such it is necessary = that this be Standards track as adhering to the normative statements in = the draft are necessary for interoperability. > > > > What is discussed in the Appendix is a use case. It is not normative = and there are strong opinions on both sides as to whether this is an = appropriate use case or not. > > In the context of this draft, I have no interest in trying to = resolve our difference of opinion on this use case. I simply want the = protocol extension to move forward so that we have another tool = available. > > > > If you want to write a draft on the use case discussed in the = Appendix please feel free to do so. That draft may very well not be = normative - Informational or BCP may be more appropriate - because it = will be discussing a deployment scenario and a proposal to use defined = protocol extensions as one way to solve problems in that deployment = scenario. Such a draft might also be more appropriate in another WG = (e.g., TEAS). The merits of using prefix advertisements to build a = topology could then be discussed on its own. > > > > Please do not try to avoid having a full discussion of the merits of = using prefix advertisements to derive topology by adding it to a draft = that is (and should be) focused on simple protocol extensions. >=20 > [As WG member] >=20 > I find this very compelling and so support the removal of the referred = to non-normative appendices. >=20 > Thanks, > Chris. >=20 > > > > Thanx. > > > > Les > > > > > >> -----Original Message----- > >> From: Aijun Wang > >> Sent: Thursday, October 15, 2020 6:51 PM > >> To: 'Jeff Tantsura' ; 'John E Drake' > >> > >> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; Les = > >> Ginsberg > >> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org;=20 > >> draft-ietf- lsr-ospf-prefix-originator@ietf.org > >> Subject: RE: [Lsr] WG Last Call=20 > >> draft-ietf-lsr-ospf-prefix-originator-06 > >> > >> Hi, Les, John and Jeff: > >> > >> Let's reply you all together. > >> In my POV, The standard document should not define solely the=20 > >> protocol extension, but their usages in the network deployment. As=20 > >> I known, almost all the IETF documents following this style. > >> And, before adopting one work, we have often intense discussion for = > >> what's their usages. > >> Such discussion in the mail list and statements in the document can = > >> certainly assist the reader/user of the document get the essence of = > >> the standard, and follow them unambiguously. > >> > >> Regarding the contents of appendices, as stated in the section,=20 > >> "The Appendix A heuristic to rebuild the topology can normally be=20 > >> used if all links are numbered." I think this can apply almost most = > >> of the operator's network, and facilitate the inter-area TE path=20 > >> calculation for central controller, or even for the head-end router = > >> that located in one area that different from the tail- end router. > >> > >> Keeping the contents of appendices does not have the negative=20 > >> impact of the protocol extension, it is just one reference for the=20 > >> usage of this extension. > >> One can select not refer to it, if their networks are deployed with = > >> large amount of unnumbered links. But for others, the heuristic = applies. > >> > >> Best Regards > >> > >> Aijun Wang > >> China Telecom > >> > >> > >> > >> -----Original Message----- > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf=20 > >> Of Jeff Tantsura > >> Sent: Friday, October 16, 2020 5:28 AM > >> To: John E Drake > >> Cc: Christian Hopps ; lsr-chairs@ietf.org; Les=20 > >> Ginsberg > >> (ginsberg) ; lsr@ietf.org;=20 > >> lsr- ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org > >> Subject: Re: [Lsr] WG Last Call=20 > >> draft-ietf-lsr-ospf-prefix-originator-06 > >> > >> +1 > >> > >> Regards, > >> Jeff > >> > >>> On Oct 15, 2020, at 11:33, John E Drake > >> wrote: > >>> > >>> =EF=BB=BFHi, > >>> > >>> I agree with Les. This is a simple protocol extension for a=20 > >>> specific purpose > >> and there is no reason to include speculation about its use for=20 > >> other purposes, particularly when it is inherently not suited for = them. > >>> > >>> Yours Irrespectively, > >>> > >>> John > >>> > >>> > >>> Juniper Business Use Only > >>> > >>>> -----Original Message----- > >>>> From: Lsr On Behalf Of Les Ginsberg=20 > >>>> (ginsberg) > >>>> Sent: Thursday, October 15, 2020 12:33 PM > >>>> To: Christian Hopps ; lsr@ietf.org > >>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; > >>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org > >>>> Subject: Re: [Lsr] WG Last Call > >>>> draft-ietf-lsr-ospf-prefix-originator-06 > >>>> > >>>> [External Email. Be cautious of content] > >>>> > >>>> > >>>> I support moving this document forward. > >>>> Similar functionality in IS-IS has proved useful. > >>>> > >>>> I would however like to repeat comments I made earlier in the=20 > >>>> review of this document. > >>>> The content of the Appendices should be removed. > >>>> The Appendices define and discuss deriving topology information=20 > >>>> from prefix advertisements - which is flawed and should not be = done. > >>>> Perhaps more relevant, the purpose of the document is to define=20 > >>>> protocol extensions supporting advertisement of the originators=20 > >>>> of a prefix advertisement. There is no need to discuss how this=20 > >>>> mechanism might be used to build topology information. > >>>> This document should confine itself to defining the protocol=20 > >>>> extensions - similar the RFC 7794. > >>>> > >>>> If the authors do not agree to do this, I would encourage this=20 > >>>> point to be discussed during IESG review. > >>>> > >>>> Les > >>>> > >>>>> -----Original Message----- > >>>>> From: Lsr On Behalf Of Christian Hopps > >>>>> Sent: Wednesday, October 14, 2020 11:15 PM > >>>>> To: lsr@ietf.org > >>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; > >>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps=20 > >>>>> > >>>>> Subject: [Lsr] WG Last Call=20 > >>>>> draft-ietf-lsr-ospf-prefix-originator-06 > >>>>> > >>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, = for: > >>>>> > >>>>> > >>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/dra > >>>>> ft-i > >>>>> et > >>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- > >> gk!TaSzQThghtCFOuYPS2VjLq > >>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ > >>>>> > >>>>> The following IPR has been filed=20 > >>>>> = https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! > >>>>> !NEt6yMaO- > >>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz > >>>>> 5KtUHQ$ > >>>>> > >>>>> Authors, > >>>>> > >>>>> Please indicate to the list, your knowledge of any other IPR=20 > >>>>> related to this work. > >>>>> > >>>>> Thanks, > >>>>> Chris. > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo > >>>> /lsr > >>>> __;!!NEt > >>>> 6yMaO- > >>>> > >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm > >> w8 > >>>> Lc$ > >>> > >>> _______________________________________________ > >>> Lsr mailing list > >>> Lsr@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lsr > >> > >> _______________________________________________ > >> Lsr mailing list > >> Lsr@ietf.org > >> https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr >=20 >=20 >=20 From nobody Sun Oct 18 19:45:58 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D193A125E; Sun, 18 Oct 2020 19:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 nV-R5G7A48wk; Sun, 18 Oct 2020 19:45:54 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D823A125C; Sun, 18 Oct 2020 19:45:52 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 923EB47721; Mon, 19 Oct 2020 10:45:47 +0800 (CST) From: "Aijun Wang" To: "'Gyan Mishra'" , "'Ketan Talaulikar \(ketant\)'" Cc: "'Christian Hopps'" , "'Jeff Tantsura'" , "'John E Drake'" , "'Les Ginsberg \(ginsberg\)'" , , , , References: <006001d6a35e$d9136ab0$8b3a4010$@tsinghua.org.cn> In-Reply-To: Date: Mon, 19 Oct 2020 10:45:45 +0800 Message-ID: <00d301d6a5c1$f2114ea0$d633ebe0$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01D6A605.003774D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKxZ4cxGLGkLReI9SxNqo7tLyH7tQFQI5z6Ae2yMJUCF3zXMQJ7PKzDAZ3Qy9+nnTmlsA== Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTUsfTEwYQkMeSksfVkpNS0hLTE5OT0NKS0NVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PUk6Hzo6GD8iDTIQFCFLLRBC FyMwCi1VSlVKTUtIS0xOTk9DQ09JVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQU5LS0JONwY+ X-HM-Tid: 0a753ebfa3449865kuuu923eb47721 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 02:45:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D4_01D6A605.003774D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Gyan: =20 Thanks for your considerations. The use case in the appendix is the start point of this draft, not the = application of it. =20 Putting it into the appendix just want to let the reader focus on the = protocol extension itself. For the usages of the protocol extension, the = reader can refer the description in the appendix. =20 We have discussed the contents in appendix before. The discussion = results are stated in the appendix now.=20 =20 For operators in SDN era, there are strong motivations to accomplish e2e = service assurance. To achieve this, the overall e2e topology is the = prerequisite information. Knowing the originator of the prefixes can = deduce the inter-area topology which is hidden by ABR. We don=E2=80=99t = preclude other use cases of this extension, but they are not prominent = as this case. =20 Best Regards =20 Aijun Wang China Telecom =20 From: Gyan Mishra [mailto:hayabusagsm@gmail.com]=20 Sent: Friday, October 16, 2020 9:58 PM To: Ketan Talaulikar (ketant) Cc: Aijun Wang ; Christian Hopps = ; Jeff Tantsura ; John E = Drake ; Les Ginsberg (ginsberg) = ; = draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr-ads@ietf.org; = lsr-chairs@ietf.org; lsr@ietf.org Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 =20 =20 Agreed. Also as use cases go that does delve into implementation = aspects of which can vary significantly.=20 =20 So to your point as Les and Chris mentioned the focus of LSR and drafts = published is on the protocol extension. How it=E2=80=99s used is out of = scope and could be a draft in another WG. In this case moreso not = pertinent since the primary use case gets into the weeds on a TEAS or = PCE topiic. =20 Thanks=20 =20 Gyan =20 On Fri, Oct 16, 2020 at 1:04 AM Ketan Talaulikar (ketant) = > wrote: Hi Gyan, =20 Thanks for your review and feedback. Please check inline below. =20 From: Gyan Mishra = >=20 Sent: 16 October 2020 10:11 To: Aijun Wang > Cc: Christian Hopps >; = Jeff Tantsura = >; John E Drake >; Les Ginsberg (ginsberg) = >; = draft-ietf-lsr-ospf-prefix-originator@ietf.org = ; lsr@ietf.org = ; lsr-ads@ietf.org ; = lsr-chairs@ietf.org =20 Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 =20 I support advancement of the draft. =20 =20 This draft follows along the lines of ISIS RFC 7794 to provide an = extension to identify the prefix originator attribute using an = originating router TLV and a reachable prefix. A node in ospf is = represented by a router-id which technically can be a random 4 octet = prefix that does not have to be reachable entry in the IGP RIB. =20 =20 The reachability prefix is important in cases where the originator = router-id is not in the RIB or in traffic engineering inter as path = instantiation use case where the router-id originator node is = advertised, however since the TEDs database link attributes are not = known inter-as,having the reachability address is important as defined = in the draft. This feature can also be used identifying the prefix = originator in a normal user case other then the traffic engineering = scenario such as for troubleshooting which is common to view all the = prefixes advertised by a node by Prefix type.=20 =20 There maybe cases where you need to create a database filter or policy = and if you can use this feature as a means of controlling prefix = advertisements based on source node that can be powerful and could have = ubiquitous use cases. =20 With regards to the appendix it does appear to be pertinent, as the use = case appears to be the primary focal point and reason for the draft by = the authors. I don=E2=80=99t think that having the appendix precluding = other use cases by any means.=20 [KT] The Introduction section of the draft does touch upon some of the = primary use-cases that authors believe have more wide-spread = applicability. You have also alluded to some of them and then you have = also brought out some newer use-cases/applications of the extensions in = this draft. There were other use-cases in previous versions like ELC = which later went away based on how we addressed that in = draft-ietf-ospf/isis-mpls-elc documents. I am sure there will be newer = use-cases. The focus of the draft is primary to capture the protocol = extensions since that is what we work on in LSR. The scope of the = use-cases may be beyond LSR and in other areas (e.g. TEAS perhaps for = the one in the appendix ?). Regarding the use-case in the appendix, it = would be fair to say that it was primary focal point for some of the = authors. =20 I will leave it to the WG consensus on what content we should be sending = to the IESG. =20 Thanks, Ketan =20 Kind Regards=20 =20 Gyan =20 On Thu, Oct 15, 2020 at 9:51 PM Aijun Wang > wrote: Hi, Les, John and Jeff: Let's reply you all together. In my POV, The standard document should not define solely the protocol = extension, but their usages in the network deployment. As I known, = almost all the IETF documents following this style.=20 And, before adopting one work, we have often intense discussion for = what's their usages.=20 Such discussion in the mail list and statements in the document can = certainly assist the reader/user of the document get the essence of the = standard, and follow them unambiguously. Regarding the contents of appendices, as stated in the section, "The = Appendix A heuristic to rebuild the topology can normally be used if all = links are numbered." I think this can apply almost most of the = operator's network, and facilitate the inter-area TE path calculation = for central controller, or even for the head-end router that located in = one area that different from the tail-end router. Keeping the contents of appendices does not have the negative impact of = the protocol extension, it is just one reference for the usage of this = extension.=20 One can select not refer to it, if their networks are deployed with = large amount of unnumbered links. But for others, the heuristic applies. Best Regards Aijun Wang China Telecom -----Original Message----- From: lsr-bounces@ietf.org = [mailto:lsr-bounces@ietf.org ] On Behalf = Of Jeff Tantsura Sent: Friday, October 16, 2020 5:28 AM To: John E Drake > Cc: Christian Hopps >; = lsr-chairs@ietf.org ; Les Ginsberg = (ginsberg) >; lsr@ietf.org = ; lsr-ads@ietf.org ; = draft-ietf-lsr-ospf-prefix-originator@ietf.org = =20 Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 +1 Regards, Jeff > On Oct 15, 2020, at 11:33, John E Drake = > wrote: >=20 > =EF=BB=BFHi, >=20 > I agree with Les. This is a simple protocol extension for a specific = purpose and there is no reason to include speculation about its use for = other purposes, particularly when it is inherently not suited for them. >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > Juniper Business Use Only >=20 >> -----Original Message----- >> From: Lsr > On = Behalf Of Les Ginsberg (ginsberg) >> Sent: Thursday, October 15, 2020 12:33 PM >> To: Christian Hopps >; = lsr@ietf.org =20 >> Cc: lsr-chairs@ietf.org ; = lsr-ads@ietf.org ;=20 >> draft-ietf-lsr-ospf-prefix- originator@ietf.org = =20 >> Subject: Re: [Lsr] WG Last Call=20 >> draft-ietf-lsr-ospf-prefix-originator-06 >>=20 >> [External Email. Be cautious of content] >>=20 >>=20 >> I support moving this document forward. >> Similar functionality in IS-IS has proved useful. >>=20 >> I would however like to repeat comments I made earlier in the review=20 >> of this document. >> The content of the Appendices should be removed. >> The Appendices define and discuss deriving topology information from=20 >> prefix advertisements - which is flawed and should not be done. >> Perhaps more relevant, the purpose of the document is to define =20 >> protocol extensions supporting advertisement of the originators of a=20 >> prefix advertisement. There is no need to discuss how this mechanism=20 >> might be used to build topology information. >> This document should confine itself to defining the protocol=20 >> extensions - similar the RFC 7794. >>=20 >> If the authors do not agree to do this, I would encourage this point=20 >> to be discussed during IESG review. >>=20 >> Les >>=20 >>> -----Original Message----- >>> From: Lsr > On = Behalf Of Christian Hopps >>> Sent: Wednesday, October 14, 2020 11:15 PM >>> To: lsr@ietf.org =20 >>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org = ; >>> lsr-chairs@ietf.org ; lsr- ads@ietf.org = ; Christian Hopps=20 >>> > >>> Subject: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>>=20 >>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: >>>=20 >>>=20 >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-i = =20 >>> et=20 >>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLq >>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>=20 >>> The following IPR has been filed >>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__ = ;! >>> !NEt6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>> 5KtUHQ$ >>>=20 >>> Authors, >>>=20 >>> Please indicate to the list, your knowledge of any other IPR=20 >>> related to this work. >>>=20 >>> Thanks, >>> Chris. >>=20 >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org =20 >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr = =20 >> __;!!NEt >> 6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8 >> Lc$ >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org =20 > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org =20 https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org =20 https://www.ietf.org/mailman/listinfo/lsr --=20 =20 Gyan Mishra Network Solutions Architect=20 M 301 502-1347 13101 Columbia Pike = =20 Silver Spring, MD = =20 =20 --=20 =20 Gyan Mishra Network Solutions Architect=20 M 301 502-1347 13101 Columbia Pike=20 Silver Spring, MD =20 ------=_NextPart_000_00D4_01D6A605.003774D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable _______________________________________________
Lsr ma= iling list
Lsr@ietf.org
https://www.ietf.org= /mailman/listinfo/lsr

H= i, Gyan:

<= o:p> 

T= hanks for your considerations.

T= he use case in the appendix is the start point of this draft, =C2=A0not = the application of it.=C2=A0

P= utting it into the appendix just want to let the reader focus on the = protocol extension itself. For the usages of the protocol extension, the = reader can refer the description in the appendix. = =C2=A0

W= e have discussed the contents in appendix before. The discussion results = are stated in the appendix now.

<= o:p> 

F= or operators in SDN era, there are strong motivations to accomplish e2e = service assurance. To achieve this, the overall e2e topology is the = prerequisite information. =C2=A0Knowing the originator of the prefixes = can deduce the inter-area topology which is hidden by ABR.=C2=A0 We = don=E2=80=99t preclude other use cases of this extension, but they are = not prominent as this case.

<= o:p> 

B= est Regards

<= o:p> 

A= ijun Wang

C= hina Telecom<= o:p>

<= o:p> 

From:<= /b> Gyan Mishra = [mailto:hayabusagsm@gmail.com]
Sent: Friday, October 16, 2020 = 9:58 PM
To: Ketan Talaulikar (ketant) = <ketant@cisco.com>
Cc: Aijun Wang = <wangaijun@tsinghua.org.cn>; Christian Hopps = <chopps@chopps.org>; Jeff Tantsura = <jefftant.ietf@gmail.com>; John E Drake = <jdrake=3D40juniper.net@dmarc.ietf.org>; Les Ginsberg (ginsberg) = <ginsberg=3D40cisco.com@dmarc.ietf.org>; = draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr-ads@ietf.org; = lsr-chairs@ietf.org; lsr@ietf.org
Subject: Re: [Lsr] WG Last = Call draft-ietf-lsr-ospf-prefix-originator-06

 

 

Agreed.  Also as use cases go that does delve into = implementation aspects of which can vary = significantly. 

 

So to your point as Les and Chris mentioned the focus of = LSR and drafts published is on the protocol extension.  How = it=E2=80=99s used is out of scope and could be a draft in another = WG.  In this case moreso not pertinent since the primary use case = gets into the weeds on a TEAS or PCE = topiic.

 

Thanks 

 

Gyan

 

Hi Gyan,

 

Thanks for your review and feedback. = Please check inline below.

 

From: = Gyan Mishra <hayabusagsm@gmail.com>
Sent: 16 = October 2020 10:11
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: = Christian Hopps <chopps@chopps.org>; Jeff Tantsura <jefftant.ietf@gmail.com>; John E Drake = <jdrake=3D40juniper.net@dmarc.ietf.org>; Les Ginsberg = (ginsberg) <ginsberg=3D40cisco.com@dmarc.ietf.org>; draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr@ietf.org; lsr-ads@ietf.org; = lsr-chairs@ietf.org
Subject: Re: [Lsr] = WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

 

I support advancement of the draft. =  

 

This draft follows along the lines of = ISIS RFC 7794 to provide an extension to identify the prefix originator = attribute using an originating router TLV and a reachable prefix.  = A node in ospf is represented by a router-id which technically can be a = random 4 octet prefix that does not have to be reachable entry in the = IGP RIB.  

 

The reachability prefix is important in = cases where the originator router-id is not  in the RIB or in = traffic engineering inter as path instantiation use case where the = router-id originator node is advertised, however since the TEDs database = link attributes are not known inter-as,having the reachability address = is important as defined in the draft.  This feature can also be = used  identifying the prefix originator in a normal user case other = then the traffic engineering scenario such as for troubleshooting which = is common to view all the prefixes advertised by a node by Prefix = type. 

 

There maybe cases where you need to = create  a database filter or policy and if you can use this feature = as a means of controlling prefix advertisements based on source node = that can be powerful and could have ubiquitous use = cases.

 

With regards to the appendix it does = appear to be pertinent, as the use case appears to be the primary focal = point and reason for the draft by the authors.  I don=E2=80=99t = think that having the appendix  precluding other use cases by any = means. 

[KT] The Introduction section of = the draft does touch upon some of the primary use-cases that authors = believe have more wide-spread applicability. You have also alluded to = some of them and then you have also brought out some newer = use-cases/applications of the extensions in this draft. There were other = use-cases in previous versions like ELC which later went away based on = how we addressed that in draft-ietf-ospf/isis-mpls-elc documents. I am = sure there will be newer use-cases. The focus of the draft is primary to = capture the protocol extensions since that is what we work on in LSR. = The scope of the use-cases may be beyond LSR and in other areas (e.g. = TEAS perhaps for the one in the appendix ?). Regarding the use-case in = the appendix, it would be fair to say that it was primary focal point = for some of the authors.

 

I will leave it to the WG = consensus on what content we should be sending to the = IESG.

 

Thanks,

Ketan

 

Kind = Regards 

 

Gyan

=

 

On Thu, Oct 15, 2020 at 9:51 PM Aijun = Wang <wangaijun@tsinghua.org.cn> = wrote:

Hi, Les, John and Jeff:

Let's = reply you all together.
In my POV, The standard document should not = define solely the protocol extension, but their usages in the network = deployment. As I known, almost all the IETF documents following this = style.
And, before adopting one work, we have often intense = discussion for what's their usages.
Such discussion in the mail list = and statements in the document can certainly assist the reader/user of = the document get the essence of the standard, and follow them = unambiguously.

Regarding the contents of appendices, as stated in = the section, "The Appendix A heuristic to rebuild the topology can = normally be used if all links are numbered." I think this can apply = almost most of the operator's network, and facilitate the inter-area TE = path calculation for central controller, or even for the head-end router = that located in one area that different from the tail-end = router.

Keeping the contents of appendices does not have the = negative impact of the protocol extension, it is just one reference for = the usage of this extension.
One can select not refer to it, if = their networks are deployed with large amount of unnumbered links. But = for others, the heuristic applies.

Best Regards

Aijun = Wang
China Telecom



-----Original Message-----
From: = lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Jeff = Tantsura
Sent: Friday, October 16, 2020 5:28 AM
To: John E Drake = <jdrake=3D40juniper.net@dmarc.ietf.org>
Cc: Christian = Hopps <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) = <ginsberg=3D40cisco.com@dmarc.ietf.org>; lsr@ietf.org; lsr-ads@ietf.org; = draft-ietf-lsr-ospf-prefix-originator@ietf.org
S= ubject: Re: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06

+1

Regards,
Jef= f

> On Oct 15, 2020, at 11:33, John E Drake <jdrake=3D40juniper.net@dmarc.ietf.org> wrote:
> =
> =EF=BB=BFHi,
>
> I agree with Les.  This is a = simple protocol extension for a specific purpose and there is no reason = to include speculation about its use for other purposes, particularly = when it is inherently not suited for them.
>
> Yours = Irrespectively,
>
> John
>
>
> Juniper = Business Use Only
>
>> -----Original = Message-----
>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Les Ginsberg = (ginsberg)
>> Sent: Thursday, October 15, 2020 12:33 = PM
>> To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org
>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; =
>> draft-ietf-lsr-ospf-prefix- originator@ietf.org
>> Subject: Re: [Lsr] = WG Last Call
>> = draft-ietf-lsr-ospf-prefix-originator-06
>>
>> = [External Email. Be cautious of content]
>>
>> =
>> I support moving this document forward.
>> Similar = functionality in IS-IS has proved useful.
>>
>> I = would however like to repeat comments I made earlier in the review =
>> of this document.
>> The content of the Appendices = should be removed.
>> The Appendices define and discuss = deriving topology information from
>> prefix advertisements - = which is flawed and should not be done.
>> Perhaps more = relevant, the purpose of the document is to define 
>> = protocol extensions supporting advertisement of the originators of a =
>> prefix advertisement. There is no need to discuss how this = mechanism
>> might be used to build topology = information.
>> This document should confine itself to defining = the protocol
>> extensions - similar the RFC 7794.
>> =
>> If the authors do not agree to do this, I would encourage = this point
>> to be discussed during IESG review.
>> =
>>   Les
>>
>>> -----Original = Message-----
>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Christian = Hopps
>>> Sent: Wednesday, October 14, 2020 11:15 = PM
>>> To: lsr@ietf.org
>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org;
= >>> lsr-chairs@ietf.org; lsr- ads@ietf.org; = Christian Hopps
>>> <chopps@chopps.org>
>>> Subject: = [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06
>>> =
>>> This begins a 2 week WG Last Call, ending after Oct = 29th, 2020, for:
>>>
>>>
>>> https://urldefense.com/v3/__https://datatracker.ietf.or= g/doc/draft-i
>>> et
>>> = f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-gk!TaSzQThghtCFOuYPS2VjLq
&= gt;>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
>>> =
>>> The following IPR has been filed
>>> https://urldefense.com/v3/__https://datatracker.ietf.or= g/ipr/3448/__;!
>>> !NEt6yMaO-
>> = gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
>>&= gt; 5KtUHQ$
>>>
>>> Authors,
>>> =
>>>  Please indicate to the list, your knowledge of = any other IPR
>>> related to this work.
>>> =
>>> Thanks,
>>> Chris.
>>
>> = _______________________________________________
>> Lsr mailing = list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailma= n/listinfo/lsr
>> __;!!NEt
>> 6yMaO-
>> = gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdmw8
>&= gt; Lc$
>
> = _______________________________________________
> Lsr mailing = list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

__= _____________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

__= _____________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

-- =

=

Gyan = Mishra

Network Solutions = Architect 

M 301 502-1347
13101 Columbia = Pike 
Silver Spring, = MD

 

-- =

=

Gyan = Mishra

Network = Solutions Architect 

M 301 = 502-1347
13101 Columbia Pike 
Silver Spring, = MD

 

------=_NextPart_000_00D4_01D6A605.003774D0-- From nobody Sun Oct 18 23:15:06 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688E23A13F8; Sun, 18 Oct 2020 23:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.698 X-Spam-Level: X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TQOQnFM+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=r84Za0Em 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 o5Dv0Kcf0uDE; Sun, 18 Oct 2020 23:14:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3C63A13F9; Sun, 18 Oct 2020 23:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20302; q=dns/txt; s=iport; t=1603088097; x=1604297697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tgbBqx+O4d25ZTqY5jNopoKN9//c6uGwMc3Tcsudpfk=; b=TQOQnFM+xDMPA5zYfGVpaTVIpL50dQcvEiBa9h4Rzv8hqBIbBVx+X/B4 MiUOfQbRnDNwE7zftk5MsnpeG9URjDBVFR/o2BH0woLrhEK37Kb1QAGkC yFL6UxtjKBPykck7waClKL4xuN1OSVds97PkQXp0ANUbxiUE2UG7CpIaJ I=; IronPort-PHdr: =?us-ascii?q?9a23=3Aqe8+OhVQ1i3ZPfEG2QnIyfK663DV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+Fue5fiuzZs73pH2sa7tCKtiNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0OAR?= =?us-ascii?q?T5OgpoL6LyAIGUhMLkn+y38ofYNgNPgjf1aLhuLRKw+APWsMRegYZrJqsrjB?= =?us-ascii?q?XTpX4dcOVNzmQuLlWWzBs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeCACOLo1f/4YNJK1WCh0BAQEBCQE?= =?us-ascii?q?SAQUFAUCBT4FSUQdwWS8shD2DSQONTYoQjmqBQoERA1ULAQEBDQEBGAsKAgQ?= =?us-ascii?q?BAYRKAheBdAIlOBMCAwEBCwEBBQEBAQIBBgRthWEMhXIBAQEEAQEQEREMAQE?= =?us-ascii?q?sCwELBAIBBgIRBAEBAQICIwMCAgIfBgsUAQgIAgQBDQUIGoMFgksDLgEOkje?= =?us-ascii?q?QaQKBOYhodoEygwQBAQWBMwETQYMhDQuCEAMGgQ4qgnKDboEGhVAbgUE/gRA?= =?us-ascii?q?BQ4JNPoIaQgEBAgEBgSYBBwoCAQYcFQ+CcTOCLJAKBIMGPqNYVAqCaokEjGK?= =?us-ascii?q?CIYMMgxaKCZQxkzGKc4JsjxdYgl8CBAIEBQIOAQEFgWsjZ3BwFTuCNQEBATF?= =?us-ascii?q?QFwINjh8MF4NOhRSFQnQCNgIGAQkBAQMJfI1MAQE?= X-IronPort-AV: E=Sophos;i="5.77,393,1596499200"; d="scan'208";a="824717053" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Oct 2020 06:14:49 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 09J6En7J023957 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2020 06:14:49 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 19 Oct 2020 01:14:49 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 19 Oct 2020 01:14:48 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 19 Oct 2020 02:14:48 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GVNHa+rewhMQNxgjZ75NXFIT8/xsC1I4qeVJK/mStlVkKVjXZ8GrAJS4bPUHo6BQRjagIqAsaWceKnqkK2tfC7uE+OV9ilwKJRrcJ+2lfptBatvhI0Wv5vyvQg3gB0Fi3Z2lW3oimqSJ42iZQxFk3AuyYizOhrEJg+E8NfhGAELhqcRCObqBp4J5U818vLh9XBEJCSzDv0VYr/nvZXyXQV0UYjxa2NbV4Q6qXOEVauYG780Z5PdZiIkSMHj7TKS/VAama0OGQUzBYhFBk9QiYPqWR83z83UHZqwrwPy4wTJCCjHl3EBuiMnb20aMuyc554oqoC63VGDFCS8gCCvSaQ== 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=tgbBqx+O4d25ZTqY5jNopoKN9//c6uGwMc3Tcsudpfk=; b=noyJnmZiehDbZWIF/iYAmUcOyhdcMps7taA3mzUn63s5OK32zAYCeLSrGzWDy/RMmy1l1+3MOx2eIZNRAZt77seveN2cLhZm6nZiam6w81GV3/Q517CNJ4yDlpctQFMR5fs7oOnU77pJpPna8HVR5OW8tyNY+erkFUUfq39qOrG5SMIwG0Nkm8YnrWwkG4l3k04j1gEd+EiM/XOSyZgJ/9RX0FzMb09I56zmkQ0AWBDzzfOTncU1yIpaLCEcbk9m2cYLhhVmSKMr9EmgV8VSc1mQ+2UYKI+I1SIGwiBG0F5sHst6AZiDY6xz5QFfWUVDQG4oNzoMebfnTZ6CXeEyFQ== 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=tgbBqx+O4d25ZTqY5jNopoKN9//c6uGwMc3Tcsudpfk=; b=r84Za0Emn9LoPeqnGTUqQllijorOlEZWH4KDQ1BY+187vUNboexY/CXZAmneX9pOAPXhtpRVdN47/73q923DlvxtLfgdHUWtsxGlYEryNlDNASf+50j3HdgDGkh2oeMaTmE4xYC26ps1R0X4zfNZbAUoOIYu/5YUaNTQyfnWG6E= Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB3160.namprd11.prod.outlook.com (2603:10b6:a03:1b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Mon, 19 Oct 2020 06:14:46 +0000 Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::e063:fc51:b359:2f39]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::e063:fc51:b359:2f39%7]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 06:14:46 +0000 From: "Les Ginsberg (ginsberg)" To: Aijun Wang , "'Christian Hopps'" CC: "'John E Drake'" , "lsr-chairs@ietf.org" , "'Les Ginsberg (ginsberg)'" , "lsr@ietf.org" , "'Jeff Tantsura'" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWo8tEkGkRfwue4kKs1uag2Lc//qmeMcAAgABCWSA= Date: Mon, 19 Oct 2020 06:14:46 +0000 Message-ID: References: <303E621F-47AA-4309-AC85-32A597604C7C@chopps.org> <00b401d6a5bc$ac44e800$04ceb800$@tsinghua.org.cn> In-Reply-To: <00b401d6a5bc$ac44e800$04ceb800$@tsinghua.org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2602:306:36ca:6640:2c60:818d:fe1c:43a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 15b4fe5d-739b-4293-ddf4-08d873f6475d x-ms-traffictypediagnostic: BYAPR11MB3160: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: r+zIo5+W3uwZbTxPrgw49TVyaAS52SbsIPfHX3ORKgop1j9mPoi1EqG3RsktH8vQInpUcSdYlLwe5Adk1Ad9RWMqgzimD9jOKcjK4H9DcjEBqOOHENajCkqWlkRKIu4PU1pqtVWmLVyzsU/5/Fcem47Kg+LeAfL/hLH4kiShO+nKhYt70+A12g1chl6byEfCSfjUMnf6gZPRWJT7TKVKOznuBBxa5CXEaxEPuuwN5AoCpDw66ahbLWdUtyflpGHI+MfcW6LbywcX5aLTmjv0r/mM9IuscriGlom7MzQhuns4vuKO+F6wD8EBRo+DYkcSZr6D6erECz8Gj89ZKusPm60LyEYIY8/KE8fUAbtFM51WNaK1jJQIZFdilcos0XjP++pN9bfT7xoLY8WQhCqKHg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(366004)(396003)(39860400002)(966005)(478600001)(186003)(6506007)(53546011)(8676002)(55016002)(8936002)(4326008)(71200400001)(66574015)(83380400001)(33656002)(30864003)(5660300002)(64756008)(66556008)(66946007)(76116006)(86362001)(2906002)(66476007)(9686003)(110136005)(52536014)(54906003)(7696005)(316002)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: c2egX4ugvUxUE+NFo5wqI3e5wYIvWcGwdAAhyJo9EsFWjq3Q0BfLX7pCo5v+zYQfx9UfD2CIFi4wiTFDYtUlHoB1dOZW1plZlTnBEh+m67Qh+76KA9AKRej647y0dXsBHAqhRjB6XZUG/Dzcf6VkeM/UtlgTf38OHiZkHnJHtEcOWVZ+ILEB5yDBafhAa/yVrbjpINRNfiloWPPOdC2iVCjufFxYPEAt1MSjlg/VRgwHZ2L4W2iESQuBjcUbWsLWhs9P3R8V1KgOuTIsn7YBAddmEQqq2CBIxFJ3qVzrcIJJLaN4Xa5gqD/j2h/JsQLlMn9LVx5t+6BRqRC/AYI40RkA3m/d0qS2cspn9KvUVYvPuVDsUhpBtH2Z63Tctrjt3lloq+CuXrtWLUlv2+b2zuIJwXUszexjqNmyLwMghbkjEAwzJH6qIVxHqKfjD++whWpec+tMvS33Ho+QF8E1yxqiXF4ZZPxoSMelKIFt96Od2oDV7k8Jnq28M1Ot4U4QqVnCCVpdsu9REEuAFhGY/nHHMDHh0Rw1dwHwjKWOVIeqoAqu6JoDQKlInRkNF2H2BblKO9Xo7DUSnpYCOzzVHFtaNKMTNrBAdSZ1ftqn8hGzRhg4lr0oXtH1wMIaPecZyIrrWdEZxLArB39eanvhhY2JZvdrRdZVi0bFYmGyepCAT6fzvpPMUN+n5qaP4BYWZv+mgzXUSrJ9BTZCCJpkDA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15b4fe5d-739b-4293-ddf4-08d873f6475d X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 06:14:46.7939 (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: 2a45E6Cys+cns+wjD7j4jGhkVivRQ8E/PCYZ5o0v0xszfno6S5vOVLVnrtvWYDf0woIX/ZVNFDiMrzXsm13/6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3160 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 06:15:04 -0000 QWlqdW4gLQ0KDQpUaGUgInVzZSBjYXNlIiBmb3IgdGhlIHByb3RvY29sIGV4dGVuc2lvbnMgaXMg Y2xlYXJseSBzdGF0ZWQgaW4gdGhlIEludHJvZHVjdGlvbjoNCg0KIlRoZSBwcmltYXJ5IHVzZSBj YXNlIGZvciB0aGUgZXh0ZW5zaW9ucyBwcm9wb3NlZCBpbiB0aGlzIGRvY3VtZW50IGlzDQogICB0 byBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBwcmVmaXggaW4gdGhl IG5ldHdvcmsuDQogICBJbiBjYXNlcyB3aGVyZSBtdWx0aXBsZSBwcmVmaXhlcyBhcmUgYWR2ZXJ0 aXNlZCBieSBhIGdpdmVuIHJvdXRlciwgaXQNCiAgIGlzIGFsc28gdXNlZnVsIHRvIGJlIGFibGUg dG8gYXNzb2NpYXRlIGFsbCB0aGVzZSBwcmVmaXhlcyB3aXRoIGENCiAgIHNpbmdsZSByb3V0ZXIg ZXZlbiB3aGVuIHByZWZpeGVzIGFyZSBhZHZlcnRpc2VkIG91dHNpZGUgb2YgdGhlIGFyZWENCiAg IGluIHdoaWNoIHRoZXkgb3JpZ2luYXRlZC4gIEl0IGFsc28gaGVscHMgdG8gZGV0ZXJtaW5lIHdo ZW4gdGhlIHNhbWUNCiAgIHByZWZpeCBpcyBiZWluZyBvcmlnaW5hdGVkIGJ5IG11bHRpcGxlIHJv dXRlcnMgYWNyb3NzIGFyZWFzLiINCg0KVGhpcyBpcyBlcXVpdmFsZW50IHRvIGxhbmd1YWdlIGlu IFJGQyA3Nzk0IHdoaWNoIGRlZmluZXMgdGhlIGFuYWxvZ291cyBleHRlbnNpb25zIGZvciBJUy1J Uy4NCg0KRXZlcnl0aGluZyB5b3UgaGF2ZSBpbiB0aGUgQXBwZW5kaXggaXMgbm90IHJlbGF0ZWQg dG8gdGhlIHByaW1hcnkgdXNlIGNhc2UgLSBhbmQgaXMgZmFjdCBhIHVzZSBjYXNlIHdoaWNoIG1h bnkgb2YgdXMgaGF2ZSBvYmplY3RlZCB0by4NCg0KWW91IGFyZSBlbnRpdGxlZCB0byB3cml0ZSBh bm90aGVyIGRyYWZ0IGFkdm9jYXRpbmcgZm9yIHlvdXIgbmV3IHVzZSBjYXNlIGlmIHlvdSB3aXNo LCBidXQgcmVxdWlyaW5nIHRoYXQgdGhlIHByb3RvY29sIGV4dGVuc2lvbnMgaW4gc3VwcG9ydCBv ZiB0aGUgcHJpbWFyeSB1c2UgY2FzZSBub3QgZ28gZm9yd2FyZCB3aXRob3V0IHlvdXIgbmV3IHVz ZSBjYXNlIGlzIC0gYXMgQ2hyaXMgaGFzIHN0YXRlZCB2ZXJ5IGNsZWFybHkgLSBob2xkaW5nIGFw cHJvdmFsIG9mIHRoZSBwcm90b2NvbCBleHRlbnNpb25zIGhvc3RhZ2UgdG8geW91ciBuZXcgdXNl IGNhc2UuDQoNCkkgYW0gYXNraW5nIHlvdSAoeWV0IGFnYWluKSBub3QgdG8gZG8gdGhpcy4NCg0K SSBjYW5ub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQgbW92aW5nIGZvcndhcmQgd2l0aCB0aGUgY29u dGVudCBpbiB0aGUgQXBwZW5kaWNlcyBpbmNsdWRlZC4NCg0KICAgTGVzDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMc3IgPGxzci1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KPiBTZW50OiBTdW5kYXksIE9jdG9iZXIgMTgsIDIwMjAg NzowOCBQTQ0KPiBUbzogJ0NocmlzdGlhbiBIb3BwcycgPGNob3Bwc0BjaG9wcHMub3JnPg0KPiBD YzogJ0pvaG4gRSBEcmFrZScgPGpkcmFrZUBqdW5pcGVyLm5ldD47IGxzci1jaGFpcnNAaWV0Zi5v cmc7ICdMZXMgR2luc2JlcmcNCj4gKGdpbnNiZXJnKScgPGdpbnNiZXJnPTQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnPjsgbHNyQGlldGYub3JnOyAnSmVmZg0KPiBUYW50c3VyYScgPGplZmZ0YW50 LmlldGZAZ21haWwuY29tPjsgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtDQo+IG9yaWdpbmF0 b3JAaWV0Zi5vcmc7IGxzci1hZHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExh c3QgQ2FsbCBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+IA0KPiBI aSwgQ2hyaXM6DQo+IA0KPiBJIHRoaW5rIHdlIGhhdmUgInB1dCB0aGUgY2FydCBiZWZvcmUgdGhl IGhvcnNlIi4gRm9yIHByb3RvY29sIGV4dGVuc2lvbiBkcmFmdCwNCj4gdGhlIG9yaWdpbiBpcyB0 aGUgdXNlIGNhc2UuDQo+IEFuZCBJIHRoaW5rIHdlIHdpbGwgbm90IGV4cGFuZCBPU1BGIHByb3Rv Y29sLCBqdXN0IGJlY2F1c2UgaXQgbGFjayBzb21ldGhpbmcNCj4gYXMgY29tcGFyZWQgd2l0aCBJ U0lTLCByaWdodD8NCj4gDQo+IEFzIEkgc3RhdGVkIGJlZm9yZSwgdGhlIHVzZSBjYXNlIGluIGN1 cnJlbnQgYXBwZW5kaXggaXMgdGhlIG1haW4gbW90aXZhdGlvbiBvZg0KPiB0aGlzIGRyYWZ0LCB5 b3UgY2FuIHNlZSB0aGlzIGluIG1haW4gYm9keSBvZiB0aGUgZWFybGllciB2ZXJzaW9uIG9mIHRo aXMNCj4gZHJhZnQoZnJvbSB2ZXJzaW9uIDAgdG8gdmVyc2lvbiA1KS4NCj4gVGhlIHJlYXNvbiB0 aGF0IHdlIG1vdmUgdGhpcyBwYXJ0IHRvIHRoZSBhcHBlbmRpeCwgYXMgdGhhdCB5b3Ugc2FpZCwg aXMgdG8gbGV0DQo+IHBlcnNvbiBmb2N1cyBvbiB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9uIGl0c2Vs Zi4NCj4gDQo+IE1vdmluZyB0aGlzIHBhcnQgdG8gYXBwZW5kaXggaXMgYWNjZXB0YWJsZSwgYnV0 IHJlbW92aW5nIGl0IGZyb20gdGhlIGRyYWZ0IHdpbGwNCj4gZXJhc2UgdGhlIG9yaWdpbiBvZiB0 aGlzIGRvY3VtZW50Lg0KPiBJcyBpdCByZWFzb25hYmxlIHRoYXQgb25lIGRvY3VtZW50IGRpc2N1 c3NlcyB0aGUgIm9yaWdpbiIob2YgdGhlIHByZWZpeCksIGNhbid0DQo+IGtlZXAgaXRzIG9yaWdp bj8NCj4gDQo+IE1vcmUgcmVwbGllcyBpbmxpbmUgYmVsb3dbV0FKXS4NCj4gDQo+IEJlc3QgUmVn YXJkcw0KPiANCj4gQWlqdW4gV2FuZw0KPiBDaGluYSBUZWxlY29tDQo+IA0KPiANCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHNyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IENocmlzdGlhbiBIb3Bwcw0K PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMjAgMTA6NDcgUE0NCj4gVG86IOeOi+eIseS/ iiA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4NCj4gQ2M6IEpvaG4gRSBEcmFrZSA8amRyYWtl QGp1bmlwZXIubmV0PjsgQ2hyaXN0aWFuIEhvcHBzDQo+IDxjaG9wcHNAY2hvcHBzLm9yZz47IGxz ci1jaGFpcnNAaWV0Zi5vcmc7IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQo+IDxnaW5zYmVyZz00 MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47IGxzckBpZXRmLm9yZzsgSmVmZiBUYW50c3VyYQ0K PiA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+OyBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1v cmlnaW5hdG9yQGlldGYub3JnOyBsc3ItDQo+IGFkc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W0xzcl0gV0cgTGFzdCBDYWxsIGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3It MDYNCj4gDQo+IElzbid0IHRoaXMganVzdCBhZGRpbmcgYW4gYW5hbG9nb3VzIGV4dGVuc2lvbiB0 aGF0IGFscmVhZHkgZXhpc3RzIGluIFJGQzc3OTQ/DQo+IFtXQUpdIE5vLiBSRkM3Nzk0IGlzIGp1 c3Qgb25lIGV4YW1wbGUgdGhhdCB0byBpbGx1c3RyYXRlLCBhcyB0aGUgY29tcGFuaW9uDQo+IElH UCBwcm90b2NvbCwgT1NQRiBjYW4gYWxzbyBhY2NvbXBsaXNoIHRoaXMuIEFuZCwgYWN0dWFsbHks IHRoZXJlIGFyZQ0KPiBkaWZmZXJlbmNlcyBjb25zaWRlcmF0aW9uIGluIHRoaXMgZHJhZnQgZm9y IHRoZSBwcm90b2NvbCBleHRlbnNpb24uDQo+IA0KPiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8g ZG8gYSBsb3Qgb2YgY29udmluY2luZyBhdCB0aGlzIHBvaW50LiBJIGFncmVlIHdpdGggTGVzLCBp Zg0KPiB5b3Ugd2FudCB0byB0YWxrIGFib3V0IHVzZSBjYXNlcyAoZXNwZWNpYWxseSBvbmVzIHRo YXQgYXJlIGNvbnRyb3ZlcnNpYWwhKQ0KPiB0aGVuIHRoZSBjb3JyZWN0IHBsYWNlIGZvciB0aGF0 IGlzIGluIGEgbmV3IGluZm9ybWF0aXZlIGRyYWZ0Lg0KPiBbV0FKXSB3ZSBoYXZlIGRpc2N1c3Nl ZCB0aGUgdXNlIGNhc2UgYmVmb3JlIGFuZCBzdGF0ZSB0aGUgZGlzY3Vzc2lvbg0KPiByZXN1bHRz IGF0IHRoZSBhcHBlbmRpeCBwYXJ0LiBXZSB3aWxsIG5vdCBlbXBoYXNpcyBhbmQgZXhwYW5kIHRo ZSB1c2UgY2FzZQ0KPiBtb3JlLiBJZiBvbmUgZG9lcyBub3QgYWdyZWUgdGhlIHN0YXRlbWVudCBv ZiB0aGlzIGFwcGVuZGl4LCB3ZSBjYW4gZGlzY3Vzcw0KPiBvbmxpbmUgb3Igb2ZmbGluZS4gV2Ug anVzdCBuZWVkIHRvIG1ha2UgdGhlIHN0YXRlbWVudCBpbiBhcHBlbmRpeCBpcyBjb3JyZWN0Lg0K PiANCj4gT3RoZXJ3aXNlLCBlc3BlY2lhbGx5IGlmIHRoZSBjYXNlcyBhcmUgY29udHJvdmVyc2lh bCwgdGhpcyBjYW4gYmUgc2VlbiBhcyBkb2luZw0KPiBhbiAiZW5kLXJ1biIgdG8gYXZvaWQgdGhl IGRlYmF0ZSBiL2MgcGVvcGxlIHdhbnQgdGhlIGV4dGVuc2lvbiwgYnV0IG1heWJlDQo+IGRvbid0 IGFncmVlIHdpdGggeW91ciB1c2UgY2FzZS4NCj4gW1dBSl0gT25lIHNob3VsZCBwb2ludCBvdXQg d2hpY2ggc3RhdGVtZW50IGluIHRoZSBhcHBlbmRpeCBpcw0KPiBjb250cm92ZXJzaWFsLCB3ZSBj YW4gY29ycmVjdCBpdC4gVGhpcyB1c2UgY2FzZSBpcyB0aGUgb3JpZ2luIG9mIHRoaXMgZHJhZnQs IG5vdA0KPiB0aGUgcmVzdWx0cy4NCj4gDQo+IExlZ2lzbGF0b3JzIGRvIHRoaXMgc29tZXRpbWVz IGFkZGluZyB0aGluZ3MgdGhleSB3YW50IHBlcnNvbmFsbHkgdG8gcG9wdWxhcg0KPiBiaWxscywg dGhhdCBvdGhlciBwZW9wbGUgbWF5IG5vdCB3YW50LCBidXQgc2luY2UgcGVvcGxlIHdhbnQgdGhl IG1haW4gYmlsbA0KPiB0aGV5IHZvdGUgZm9yIGl0IGFueXdheSwgaW4gdGhlIFVTIGl0J3MgY2Fs bGVkICJhZGRpbmcgcG9yayIgb3IgInBvcmsgYmFycmVsDQo+IHBvbGl0aWNzIi4gOikNCj4gW1dB Sl0gVGhlIGFwcGVuZGl4IGlzIG5vdCBhZGRlZCBsYXRlciwgYnV0IGV4aXN0IGF0IHRoZSBmaXJz dCBiZWdpbm5pbmcuIFRoaXMgaXMNCj4gdGhlIG9yaWdpbiBvZiB0aGUgYmlsbHMuDQo+IA0KPiBU aGFua3MsDQo+IENocmlzLg0KPiANCj4gPiBPbiBPY3QgMTYsIDIwMjAsIGF0IDEwOjM3IEFNLCDn jovniLHkv4ogPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+DQo+IHdyb3RlOg0KPiA+DQo+ID4N Cj4gPiBIaSwgQ2hyaXM6DQo+ID4gT3JpZ2luYWxseSwgdGhlIGFwcGVuZGl4IHBhcnQgaXMgd2l0 aGluIHRoZSBkb2N1bWVudCwgd2hpY2ggaXMgdGhlIHN0YXJ0DQo+IHBvaW50L21haW4gbW90aXZh dGlvbiB0byBleHRlbmQgdGhlIHByZWZpeCBvcmlnaW4uDQo+ID4gVGhlcmUgbWF5IGV4aXN0cyBv dGhlciB1c2FnZXMgb2YgdGhpcyBpbmZvcm1hdGlvbi4gUGFjayB0aGVzZSBleGFtcGxlcw0KPiBp bnRvIHNvbWUgc2hvcnQgc2VudGVuY2VzIG9yIGludHJvZHVjdGlvbiBpcyB2aWFibGUsIGJ1dCBl eHBhbmQgc29tZSBvZg0KPiB0aGVtIGlzIGFsc28gaGVscGZ1bC4NCj4gPiBBcyBJIGtub3duLCB3 aGVuIHdlIHdhbnQgdG8gZG8gcHJvdG9jb2wgZXh0ZW5zaW9uLCB3ZSBzaG91bGQgIGFsd2F5cw0K PiBjb252aW5jZSBvdGhlciB0aGUgcmVhc29uL21vdGl2YXRpb24vcHJvc3BlY3RzIHRvIGRvIHNv LiBPbiB0aGUgb3RoZXINCj4gaGFuZCwgdGhlIHVzZSBjYXNlIGRlc2NyaWJlZCBpbiB0aGUgY3Vy cmVudCBhcHBlbmRpeCBpcyB2ZXJ5IHByb21pbmVudCBmb3INCj4gb3BlcmF0b3IgdG8gYWNjb21w bGlzaCB0aGUgVEUgdGFzayBpbiBtdWx0aS1hcmVhIGVudmlyb25tZW50Lg0KPiA+DQo+ID4gQWlq dW4gV2FuZw0KPiA+DQo+ID4g5ZyoMjAyMC0xMC0xNu+8jENocmlzdGlhbiBIb3BwcyAmbHQ7Y2hv cHBzQGNob3Bwcy5vcmcmZ3Q75YaZ6YGTOg0KPiA+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCj4g PiDlj5Hku7bkurrvvJogQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9yZyZndDsN Cj4gPiDlj5Hku7bml7bpl7Q6IDIwMjDlubQxMOaciDE25pelIOaYn+acn+S6lA0KPiA+IOWGmemB kzogWyZxdW90O0xlcyBHaW5zYmVyZyAoZ2luc2JlcmcpJnF1b3Q7DQo+ID4gJmx0O2dpbnNiZXJn PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0O10NCj4gPiDkuLvpopjvvJogUmU6IFtMc3Jd IFdHIExhc3QgQ2FsbCBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ ID4NCj4gPiA+IE9uIE9jdCAxNiwgMjAyMCwgYXQgMTo1MSBBTSwgTGVzIEdpbnNiZXJnIChnaW5z YmVyZykNCj4gPGdpbnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4g PiA+DQo+ID4gPiBBaWp1biAtDQo+ID4gPg0KPiA+ID4gVGhlIHBvaW50IEkgYW0gbWFraW5nIGlz IHZlcnkgZm9jdXNlZC4NCj4gPiA+DQo+ID4gPiBUaGlzIGRyYWZ0IGlzIGRlZmluaW5nIGEgcHJv dG9jb2wgZXh0ZW5zaW9uLiBBcyBzdWNoIGl0IGlzIG5lY2Vzc2FyeSB0aGF0IHRoaXMNCj4gYmUg U3RhbmRhcmRzIHRyYWNrIGFzIGFkaGVyaW5nIHRvIHRoZSBub3JtYXRpdmUgc3RhdGVtZW50cyBp biB0aGUgZHJhZnQgYXJlDQo+IG5lY2Vzc2FyeSBmb3IgaW50ZXJvcGVyYWJpbGl0eS4NCj4gPiA+ DQo+ID4gPiBXaGF0IGlzIGRpc2N1c3NlZCBpbiB0aGUgQXBwZW5kaXggaXMgYSB1c2UgY2FzZS4g SXQgaXMgbm90IG5vcm1hdGl2ZSBhbmQNCj4gdGhlcmUgYXJlIHN0cm9uZyBvcGluaW9ucyBvbiBi b3RoIHNpZGVzIGFzIHRvIHdoZXRoZXIgdGhpcyBpcyBhbiBhcHByb3ByaWF0ZQ0KPiB1c2UgY2Fz ZSBvciBub3QuDQo+ID4gPiBJbiB0aGUgY29udGV4dCBvZiB0aGlzIGRyYWZ0LCBJIGhhdmUgbm8g aW50ZXJlc3QgaW4gdHJ5aW5nIHRvIHJlc29sdmUgb3VyDQo+IGRpZmZlcmVuY2Ugb2Ygb3Bpbmlv biBvbiB0aGlzIHVzZSBjYXNlLiBJIHNpbXBseSB3YW50IHRoZSBwcm90b2NvbCBleHRlbnNpb24N Cj4gdG8gbW92ZSBmb3J3YXJkIHNvIHRoYXQgd2UgaGF2ZSBhbm90aGVyIHRvb2wgYXZhaWxhYmxl Lg0KPiA+ID4NCj4gPiA+IElmIHlvdSB3YW50IHRvIHdyaXRlIGEgZHJhZnQgb24gdGhlIHVzZSBj YXNlIGRpc2N1c3NlZCBpbiB0aGUgQXBwZW5kaXgNCj4gcGxlYXNlIGZlZWwgZnJlZSB0byBkbyBz by4gVGhhdCBkcmFmdCBtYXkgdmVyeSB3ZWxsIG5vdCBiZSBub3JtYXRpdmUgLQ0KPiBJbmZvcm1h dGlvbmFsIG9yIEJDUCBtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZSAtIGJlY2F1c2UgaXQgd2lsbCBi ZSBkaXNjdXNzaW5nDQo+IGEgZGVwbG95bWVudCBzY2VuYXJpbyBhbmQgYSBwcm9wb3NhbCB0byB1 c2UgZGVmaW5lZCBwcm90b2NvbCBleHRlbnNpb25zIGFzDQo+IG9uZSB3YXkgdG8gc29sdmUgcHJv YmxlbXMgaW4gdGhhdCBkZXBsb3ltZW50IHNjZW5hcmlvLiBTdWNoIGEgZHJhZnQgbWlnaHQNCj4g YWxzbyBiZSBtb3JlIGFwcHJvcHJpYXRlIGluIGFub3RoZXIgV0cgKGUuZy4sIFRFQVMpLiBUaGUg bWVyaXRzIG9mIHVzaW5nDQo+IHByZWZpeCBhZHZlcnRpc2VtZW50cyB0byBidWlsZCBhIHRvcG9s b2d5IGNvdWxkIHRoZW4gYmUgZGlzY3Vzc2VkIG9uIGl0cyBvd24uDQo+ID4gPg0KPiA+ID4gUGxl YXNlIGRvIG5vdCB0cnkgdG8gYXZvaWQgaGF2aW5nIGEgZnVsbCBkaXNjdXNzaW9uIG9mIHRoZSBt ZXJpdHMgb2YgdXNpbmcNCj4gcHJlZml4IGFkdmVydGlzZW1lbnRzIHRvIGRlcml2ZSB0b3BvbG9n eSBieSBhZGRpbmcgaXQgdG8gYSBkcmFmdCB0aGF0IGlzIChhbmQNCj4gc2hvdWxkIGJlKSBmb2N1 c2VkIG9uIHNpbXBsZSBwcm90b2NvbCBleHRlbnNpb25zLg0KPiA+DQo+ID4gW0FzIFdHIG1lbWJl cl0NCj4gPg0KPiA+IEkgZmluZCB0aGlzIHZlcnkgY29tcGVsbGluZyBhbmQgc28gc3VwcG9ydCB0 aGUgcmVtb3ZhbCBvZiB0aGUgcmVmZXJyZWQgdG8NCj4gbm9uLW5vcm1hdGl2ZSBhcHBlbmRpY2Vz Lg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IENocmlzLg0KPiA+DQo+ID4gPg0KPiA+ID4gVGhhbngu DQo+ID4gPg0KPiA+ID4gICBMZXMNCj4gPiA+DQo+ID4gPg0KPiA+ID4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gPj4gRnJvbTogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVh Lm9yZy5jbj4NCj4gPiA+PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNSwgMjAyMCA2OjUxIFBN DQo+ID4gPj4gVG86ICdKZWZmIFRhbnRzdXJhJyA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+OyAn Sm9obiBFIERyYWtlJw0KPiA+ID4+IDxqZHJha2VAanVuaXBlci5uZXQ+DQo+ID4gPj4gQ2M6ICdD aHJpc3RpYW4gSG9wcHMnIDxjaG9wcHNAY2hvcHBzLm9yZz47IGxzci1jaGFpcnNAaWV0Zi5vcmc7 IExlcw0KPiA+ID4+IEdpbnNiZXJnDQo+ID4gPj4gKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28u Y29tPjsgbHNyQGlldGYub3JnOyBsc3ItYWRzQGlldGYub3JnOw0KPiA+ID4+IGRyYWZ0LWlldGYt IGxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnDQo+ID4gPj4gU3ViamVjdDogUkU6 IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+ID4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9y aWdpbmF0b3ItMDYNCj4gPiA+Pg0KPiA+ID4+IEhpLCBMZXMsIEpvaG4gYW5kIEplZmY6DQo+ID4g Pj4NCj4gPiA+PiBMZXQncyByZXBseSB5b3UgYWxsIHRvZ2V0aGVyLg0KPiA+ID4+IEluIG15IFBP ViwgVGhlIHN0YW5kYXJkIGRvY3VtZW50IHNob3VsZCBub3QgZGVmaW5lIHNvbGVseSB0aGUNCj4g PiA+PiBwcm90b2NvbCBleHRlbnNpb24sIGJ1dCB0aGVpciB1c2FnZXMgaW4gdGhlIG5ldHdvcmsg ZGVwbG95bWVudC4gQXMNCj4gPiA+PiBJIGtub3duLCBhbG1vc3QgYWxsIHRoZSBJRVRGIGRvY3Vt ZW50cyBmb2xsb3dpbmcgdGhpcyBzdHlsZS4NCj4gPiA+PiBBbmQsIGJlZm9yZSBhZG9wdGluZyBv bmUgd29yaywgd2UgaGF2ZSBvZnRlbiBpbnRlbnNlIGRpc2N1c3Npb24gZm9yDQo+ID4gPj4gd2hh dCdzIHRoZWlyIHVzYWdlcy4NCj4gPiA+PiBTdWNoIGRpc2N1c3Npb24gaW4gdGhlIG1haWwgbGlz dCBhbmQgc3RhdGVtZW50cyBpbiB0aGUgZG9jdW1lbnQgY2FuDQo+ID4gPj4gY2VydGFpbmx5IGFz c2lzdCB0aGUgcmVhZGVyL3VzZXIgb2YgdGhlIGRvY3VtZW50IGdldCB0aGUgZXNzZW5jZSBvZg0K PiA+ID4+IHRoZSBzdGFuZGFyZCwgYW5kIGZvbGxvdyB0aGVtIHVuYW1iaWd1b3VzbHkuDQo+ID4g Pj4NCj4gPiA+PiBSZWdhcmRpbmcgdGhlIGNvbnRlbnRzIG9mIGFwcGVuZGljZXMsIGFzIHN0YXRl ZCBpbiB0aGUgc2VjdGlvbiwNCj4gPiA+PiAiVGhlIEFwcGVuZGl4IEEgaGV1cmlzdGljIHRvIHJl YnVpbGQgdGhlIHRvcG9sb2d5IGNhbiBub3JtYWxseSBiZQ0KPiA+ID4+IHVzZWQgaWYgYWxsIGxp bmtzIGFyZSBudW1iZXJlZC4iIEkgdGhpbmsgdGhpcyBjYW4gYXBwbHkgYWxtb3N0IG1vc3QNCj4g PiA+PiBvZiB0aGUgb3BlcmF0b3IncyBuZXR3b3JrLCBhbmQgZmFjaWxpdGF0ZSB0aGUgaW50ZXIt YXJlYSBURSBwYXRoDQo+ID4gPj4gY2FsY3VsYXRpb24gZm9yIGNlbnRyYWwgY29udHJvbGxlciwg b3IgZXZlbiBmb3IgdGhlIGhlYWQtZW5kIHJvdXRlcg0KPiA+ID4+IHRoYXQgbG9jYXRlZCBpbiBv bmUgYXJlYSB0aGF0IGRpZmZlcmVudCBmcm9tIHRoZSB0YWlsLSBlbmQgcm91dGVyLg0KPiA+ID4+ DQo+ID4gPj4gS2VlcGluZyB0aGUgY29udGVudHMgb2YgYXBwZW5kaWNlcyBkb2VzIG5vdCBoYXZl IHRoZSBuZWdhdGl2ZQ0KPiA+ID4+IGltcGFjdCBvZiB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9uLCBp dCBpcyBqdXN0IG9uZSByZWZlcmVuY2UgZm9yIHRoZQ0KPiA+ID4+IHVzYWdlIG9mIHRoaXMgZXh0 ZW5zaW9uLg0KPiA+ID4+IE9uZSBjYW4gc2VsZWN0IG5vdCByZWZlciB0byBpdCwgaWYgdGhlaXIg bmV0d29ya3MgYXJlIGRlcGxveWVkIHdpdGgNCj4gPiA+PiBsYXJnZSBhbW91bnQgb2YgdW5udW1i ZXJlZCBsaW5rcy4gQnV0IGZvciBvdGhlcnMsIHRoZSBoZXVyaXN0aWMgYXBwbGllcy4NCj4gPiA+ Pg0KPiA+ID4+IEJlc3QgUmVnYXJkcw0KPiA+ID4+DQo+ID4gPj4gQWlqdW4gV2FuZw0KPiA+ID4+ IENoaW5hIFRlbGVjb20NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+ID4+IE9mIEplZmYgVGFudHN1 cmENCj4gPiA+PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMjAgNToyOCBBTQ0KPiA+ID4+ IFRvOiBKb2huIEUgRHJha2UgPGpkcmFrZT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPg0K PiA+ID4+IENjOiBDaHJpc3RpYW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPjsgbHNyLWNoYWly c0BpZXRmLm9yZzsgTGVzDQo+ID4gPj4gR2luc2JlcmcNCj4gPiA+PiAoZ2luc2JlcmcpIDxnaW5z YmVyZz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47IGxzckBpZXRmLm9yZzsNCj4gPiA+PiBs c3ItIGFkc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBp ZXRmLm9yZw0KPiA+ID4+IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPiA+PiBk cmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4gPj4NCj4gPiA+PiAr MQ0KPiA+ID4+DQo+ID4gPj4gUmVnYXJkcywNCj4gPiA+PiBKZWZmDQo+ID4gPj4NCj4gPiA+Pj4g T24gT2N0IDE1LCAyMDIwLCBhdCAxMTozMywgSm9obiBFIERyYWtlDQo+ID4gPj4gPGpkcmFrZT00 MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gPiA+Pj4NCj4gPiA+Pj4g77u/ SGksDQo+ID4gPj4+DQo+ID4gPj4+IEkgYWdyZWUgd2l0aCBMZXMuICBUaGlzIGlzIGEgc2ltcGxl IHByb3RvY29sIGV4dGVuc2lvbiBmb3IgYQ0KPiA+ID4+PiBzcGVjaWZpYyBwdXJwb3NlDQo+ID4g Pj4gYW5kIHRoZXJlIGlzIG5vIHJlYXNvbiB0byBpbmNsdWRlIHNwZWN1bGF0aW9uIGFib3V0IGl0 cyB1c2UgZm9yDQo+ID4gPj4gb3RoZXIgcHVycG9zZXMsIHBhcnRpY3VsYXJseSB3aGVuIGl0IGlz IGluaGVyZW50bHkgbm90IHN1aXRlZCBmb3IgdGhlbS4NCj4gPiA+Pj4NCj4gPiA+Pj4gWW91cnMg SXJyZXNwZWN0aXZlbHksDQo+ID4gPj4+DQo+ID4gPj4+IEpvaG4NCj4gPiA+Pj4NCj4gPiA+Pj4N Cj4gPiA+Pj4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KPiA+ID4+Pg0KPiA+ID4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4+IEZyb206IExzciA8bHNyLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBMZXMgR2luc2JlcmcNCj4gPiA+Pj4+IChnaW5zYmVyZykN Cj4gPiA+Pj4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDIwIDEyOjMzIFBNDQo+ID4g Pj4+PiBUbzogQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz47IGxzckBpZXRmLm9y Zw0KPiA+ID4+Pj4gQ2M6IGxzci1jaGFpcnNAaWV0Zi5vcmc7IGxzci1hZHNAaWV0Zi5vcmc7DQo+ ID4gPj4+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC0gb3JpZ2luYXRvckBpZXRmLm9yZw0K PiA+ID4+Pj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+ID4+Pj4gZHJhZnQt aWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IFtF eHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCj4gPiA+Pj4+DQo+ID4gPj4+ Pg0KPiA+ID4+Pj4gSSBzdXBwb3J0IG1vdmluZyB0aGlzIGRvY3VtZW50IGZvcndhcmQuDQo+ID4g Pj4+PiBTaW1pbGFyIGZ1bmN0aW9uYWxpdHkgaW4gSVMtSVMgaGFzIHByb3ZlZCB1c2VmdWwuDQo+ ID4gPj4+Pg0KPiA+ID4+Pj4gSSB3b3VsZCBob3dldmVyIGxpa2UgdG8gcmVwZWF0IGNvbW1lbnRz IEkgbWFkZSBlYXJsaWVyIGluIHRoZQ0KPiA+ID4+Pj4gcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQu DQo+ID4gPj4+PiBUaGUgY29udGVudCBvZiB0aGUgQXBwZW5kaWNlcyBzaG91bGQgYmUgcmVtb3Zl ZC4NCj4gPiA+Pj4+IFRoZSBBcHBlbmRpY2VzIGRlZmluZSBhbmQgZGlzY3VzcyBkZXJpdmluZyB0 b3BvbG9neSBpbmZvcm1hdGlvbg0KPiA+ID4+Pj4gZnJvbSBwcmVmaXggYWR2ZXJ0aXNlbWVudHMg LSB3aGljaCBpcyBmbGF3ZWQgYW5kIHNob3VsZCBub3QgYmUgZG9uZS4NCj4gPiA+Pj4+IFBlcmhh cHMgbW9yZSByZWxldmFudCwgdGhlIHB1cnBvc2Ugb2YgdGhlIGRvY3VtZW50IGlzIHRvIGRlZmlu ZQ0KPiA+ID4+Pj4gcHJvdG9jb2wgZXh0ZW5zaW9ucyBzdXBwb3J0aW5nIGFkdmVydGlzZW1lbnQg b2YgdGhlIG9yaWdpbmF0b3JzDQo+ID4gPj4+PiBvZiBhIHByZWZpeCBhZHZlcnRpc2VtZW50LiBU aGVyZSBpcyBubyBuZWVkIHRvIGRpc2N1c3MgaG93IHRoaXMNCj4gPiA+Pj4+IG1lY2hhbmlzbSBt aWdodCBiZSB1c2VkIHRvIGJ1aWxkIHRvcG9sb2d5IGluZm9ybWF0aW9uLg0KPiA+ID4+Pj4gVGhp cyBkb2N1bWVudCBzaG91bGQgY29uZmluZSBpdHNlbGYgdG8gZGVmaW5pbmcgdGhlIHByb3RvY29s DQo+ID4gPj4+PiBleHRlbnNpb25zIC0gc2ltaWxhciB0aGUgUkZDIDc3OTQuDQo+ID4gPj4+Pg0K PiA+ID4+Pj4gSWYgdGhlIGF1dGhvcnMgZG8gbm90IGFncmVlIHRvIGRvIHRoaXMsIEkgd291bGQg ZW5jb3VyYWdlIHRoaXMNCj4gPiA+Pj4+IHBvaW50IHRvIGJlIGRpc2N1c3NlZCBkdXJpbmcgSUVT RyByZXZpZXcuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gIExlcw0KPiA+ID4+Pj4NCj4gPiA+Pj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+Pj4+IEZyb206IExzciA8bHNyLWJvdW5j ZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gSG9wcHMNCj4gPiA+Pj4+PiBTZW50 OiBXZWRuZXNkYXksIE9jdG9iZXIgMTQsIDIwMjAgMTE6MTUgUE0NCj4gPiA+Pj4+PiBUbzogbHNy QGlldGYub3JnDQo+ID4gPj4+Pj4gQ2M6IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdp bmF0b3JAaWV0Zi5vcmc7DQo+ID4gPj4+Pj4gbHNyLWNoYWlyc0BpZXRmLm9yZzsgbHNyLSBhZHNA aWV0Zi5vcmc7IENocmlzdGlhbiBIb3Bwcw0KPiA+ID4+Pj4+IDxjaG9wcHNAY2hvcHBzLm9yZz4N Cj4gPiA+Pj4+PiBTdWJqZWN0OiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPiA+Pj4+PiBkcmFmdC1p ZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBU aGlzIGJlZ2lucyBhIDIgd2VlayBXRyBMYXN0IENhbGwsIGVuZGluZyBhZnRlciBPY3QgMjl0aCwg MjAyMCwgZm9yOg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhDQo+ID4g Pj4+Pj4gZnQtaQ0KPiA+ID4+Pj4+IGV0DQo+ID4gPj4+Pj4gZi1sc3Itb3NwZi1wcmVmaXgtb3Jp Z2luYXRvci9fXzshIU5FdDZ5TWFPLQ0KPiA+ID4+IGdrIVRhU3pRVGhnaHRDRk91WVBTMlZqTHEN Cj4gPiA+Pj4+PiBoSyA4cDAzRmczTDlMdUNHWHc4QzBYNnFSUWRySGpLREtIY2prakNscGskDQo+ ID4gPj4+Pj4NCj4gPiA+Pj4+PiBUaGUgZm9sbG93aW5nIElQUiBoYXMgYmVlbiBmaWxlZA0KPiA+ ID4+Pj4+DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2lwci8zNDQ4L19fOyENCj4gPiA+Pj4+PiAhTkV0NnlNYU8tDQo+ID4gPj4+Pg0K PiBnayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxaEs4cDAzRmczTDlMdUNHWHc4QzBYNnFSUWRySGpL REtIY3oNCj4gPiA+Pj4+PiA1S3RVSFEkDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBBdXRob3JzLA0K PiA+ID4+Pj4+DQo+ID4gPj4+Pj4gUGxlYXNlIGluZGljYXRlIHRvIHRoZSBsaXN0LCB5b3VyIGtu b3dsZWRnZSBvZiBhbnkgb3RoZXIgSVBSDQo+ID4gPj4+Pj4gcmVsYXRlZCB0byB0aGlzIHdvcmsu DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBUaGFua3MsDQo+ID4gPj4+Pj4gQ2hyaXMuDQo+ID4gPj4+ Pg0KPiA+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiA+Pj4+IExzciBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4+IExzckBpZXRmLm9yZw0KPiA+ ID4+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8NCj4gPiA+Pj4+IC9sc3INCj4gPiA+Pj4+IF9fOyEhTkV0DQo+ID4gPj4+ PiA2eU1hTy0NCj4gPiA+Pj4+DQo+ID4gPj4NCj4gZ2shVGFTelFUaGdodENGT3VZUFMyVmpMcWhL OHAwM0ZnM0w5THVDR1h3OEMwWDZxUlFkckhqS0RLSGNVZG0NCj4gPiA+PiB3OA0KPiA+ID4+Pj4g TGMkDQo+ID4gPj4+DQo+ID4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPj4+IExzciBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4gTHNyQGlldGYu b3JnDQo+ID4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo+ ID4gPj4NCj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+ID4+IExzciBtYWlsaW5nIGxpc3QNCj4gPiA+PiBMc3JAaWV0Zi5vcmcNCj4gPiA+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0KPiA+ID4NCj4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBM c3IgbWFpbGluZyBsaXN0DQo+ID4gPiBMc3JAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo+ID4NCj4gPg0KPiA+DQo+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHNyIG1haWxp bmcgbGlzdA0KPiBMc3JAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sc3INCg== From nobody Mon Oct 19 00:06:24 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51B53A1439; Mon, 19 Oct 2020 00:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 KF_YmAMDvT-x; Mon, 19 Oct 2020 00:06:19 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65D13A1154; Mon, 19 Oct 2020 00:06:17 -0700 (PDT) Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id A3DA8471CA; Mon, 19 Oct 2020 15:06:13 +0800 (CST) From: "Aijun Wang" To: "'Les Ginsberg \(ginsberg\)'" , "'Christian Hopps'" Cc: "'John E Drake'" , , , "'Jeff Tantsura'" , , References: <303E621F-47AA-4309-AC85-32A597604C7C@chopps.org> <00b401d6a5bc$ac44e800$04ceb800$@tsinghua.org.cn> In-Reply-To: Date: Mon, 19 Oct 2020 15:06:13 +0800 Message-ID: <00ea01d6a5e6$54f371f0$feda55d0$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGsG2Mrpx4Nm+qaEBWGzRMrcJ3TyQFhBU4MAnQQFpIBptEiXqnHro6g Content-Language: zh-cn X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTEMeGUNNS0hCGE1KVkpNS0hLQkpKTE9LQ0hVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0NISFVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Mio6Lgw5DD8ePzIDDy0yDEg6 IgJPCTNVSlVKTUtIS0JKSkxPTUxOVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpCSExDNwY+ X-HM-Tid: 0a753fae12719865kuuua3da8471ca Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 07:06:23 -0000 Hi, Les: As I stated clearly before, the appendix described in the draft is not = the new use case. It is the start point of this draft. Have you noticed that the introduction part is not the final usage of = such protocol extension information?=20 Certainly, we will not expand all the possible use cases in very detail, = but putting some of them(some interesting, prominent use cases) in the = appendix will not hamper the protocol extension itself. If the statements/descriptions in the appendix are not correct, we can = fix it, or remove it finally. If not, why not let it be for reference = to the user of such protocol extension? For the body part of this draft, we are also welcome comments. More replies inline below[WAJ] Best Regards Aijun Wang China Telecom -----Original Message----- From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of = Les Ginsberg (ginsberg) Sent: Monday, October 19, 2020 2:15 PM To: Aijun Wang ; 'Christian Hopps' = Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les = Ginsberg (ginsberg)' ; = lsr@ietf.org; 'Jeff Tantsura' ; = draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr-ads@ietf.org Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Aijun - The "use case" for the protocol extensions is clearly stated in the = Introduction: "The primary use case for the extensions proposed in this document is to be able to identify the originator of the prefix in the network. In cases where multiple prefixes are advertised by a given router, it is also useful to be able to associate all these prefixes with a single router even when prefixes are advertised outside of the area in which they originated. It also helps to determine when the same prefix is being originated by multiple routers across areas." This is equivalent to language in RFC 7794 which defines the analogous = extensions for IS-IS. Everything you have in the Appendix is not related to the primary use = case - and is fact a use case which many of us have objected to. [WAJ] Very glad to know the false statements in the appendix. You are entitled to write another draft advocating for your new use case = if you wish, but requiring that the protocol extensions in support of = the primary use case not go forward without your new use case is - as = Chris has stated very clearly - holding approval of the protocol = extensions hostage to your new use case. [WAJ] It is not new use case. As I sated before, I am open to this part, = but should on the conditions that the statements in this part are = incorrect. =20 I am asking you (yet again) not to do this. I cannot support the document moving forward with the content in the = Appendices included. [WAJ] Would like to hear more technical analysis. Les > -----Original Message----- > From: Lsr On Behalf Of Aijun Wang > Sent: Sunday, October 18, 2020 7:08 PM > To: 'Christian Hopps' > Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les=20 > Ginsberg (ginsberg)' ;=20 > lsr@ietf.org; 'Jeff Tantsura' ;=20 > draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org > Subject: Re: [Lsr] WG Last Call=20 > draft-ietf-lsr-ospf-prefix-originator-06 >=20 > Hi, Chris: >=20 > I think we have "put the cart before the horse". For protocol=20 > extension draft, the origin is the use case. > And I think we will not expand OSPF protocol, just because it lack=20 > something as compared with ISIS, right? >=20 > As I stated before, the use case in current appendix is the main=20 > motivation of this draft, you can see this in main body of the earlier = > version of this draft(from version 0 to version 5). > The reason that we move this part to the appendix, as that you said,=20 > is to let person focus on the protocol extension itself. >=20 > Moving this part to appendix is acceptable, but removing it from the=20 > draft will erase the origin of this document. > Is it reasonable that one document discusses the "origin"(of the=20 > prefix), can't keep its origin? >=20 > More replies inline below[WAJ]. >=20 > Best Regards >=20 > Aijun Wang > China Telecom >=20 >=20 > -----Original Message----- > From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of=20 > Christian Hopps > Sent: Friday, October 16, 2020 10:47 PM > To: =E7=8E=8B=E7=88=B1=E4=BF=8A > Cc: John E Drake ; Christian Hopps=20 > ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg)=20 > ; lsr@ietf.org; Jeff Tantsura=20 > ;=20 > draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org > Subject: Re: [Lsr] WG Last Call=20 > draft-ietf-lsr-ospf-prefix-originator-06 >=20 > Isn't this just adding an analogous extension that already exists in = RFC7794? > [WAJ] No. RFC7794 is just one example that to illustrate, as the=20 > companion IGP protocol, OSPF can also accomplish this. And, actually,=20 > there are differences consideration in this draft for the protocol = extension. >=20 > I don't think we need to do a lot of convincing at this point. I agree = > with Les, if you want to talk about use cases (especially ones that=20 > are controversial!) then the correct place for that is in a new = informative draft. > [WAJ] we have discussed the use case before and state the discussion=20 > results at the appendix part. We will not emphasis and expand the use=20 > case more. If one does not agree the statement of this appendix, we=20 > can discuss online or offline. We just need to make the statement in = appendix is correct. >=20 > Otherwise, especially if the cases are controversial, this can be seen = > as doing an "end-run" to avoid the debate b/c people want the=20 > extension, but maybe don't agree with your use case. > [WAJ] One should point out which statement in the appendix is=20 > controversial, we can correct it. This use case is the origin of this=20 > draft, not the results. >=20 > Legislators do this sometimes adding things they want personally to=20 > popular bills, that other people may not want, but since people want=20 > the main bill they vote for it anyway, in the US it's called "adding=20 > pork" or "pork barrel politics". :) [WAJ] The appendix is not added=20 > later, but exist at the first beginning. This is the origin of the=20 > bills. >=20 > Thanks, > Chris. >=20 > > On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A = > wrote: > > > > > > Hi, Chris: > > Originally, the appendix part is within the document, which is the=20 > > start > point/main motivation to extend the prefix origin. > > There may exists other usages of this information. Pack these=20 > > examples > into some short sentences or introduction is viable, but expand some=20 > of them is also helpful. > > As I known, when we want to do protocol extension, we should always > convince other the reason/motivation/prospects to do so. On the other=20 > hand, the use case described in the current appendix is very prominent = > for operator to accomplish the TE task in multi-area environment. > > > > Aijun Wang > > > > =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps = <chopps@chopps.org>=E5=86=99=E9=81=93: > > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps = <chopps@chopps.org> > > =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: = 2020=E5=B9=B410=E6=9C=8816=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94 > > =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)"=20 > > <ginsberg=3D40cisco.com@dmarc.ietf.org>] > > =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 > > > > > On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) > wrote: > > > > > > Aijun - > > > > > > The point I am making is very focused. > > > > > > This draft is defining a protocol extension. As such it is=20 > > > necessary that this > be Standards track as adhering to the normative statements in the=20 > draft are necessary for interoperability. > > > > > > What is discussed in the Appendix is a use case. It is not=20 > > > normative and > there are strong opinions on both sides as to whether this is an=20 > appropriate use case or not. > > > In the context of this draft, I have no interest in trying to=20 > > > resolve our > difference of opinion on this use case. I simply want the protocol=20 > extension to move forward so that we have another tool available. > > > > > > If you want to write a draft on the use case discussed in the=20 > > > Appendix > please feel free to do so. That draft may very well not be normative - = > Informational or BCP may be more appropriate - because it will be=20 > discussing a deployment scenario and a proposal to use defined=20 > protocol extensions as one way to solve problems in that deployment=20 > scenario. Such a draft might also be more appropriate in another WG=20 > (e.g., TEAS). The merits of using prefix advertisements to build a = topology could then be discussed on its own. > > > > > > Please do not try to avoid having a full discussion of the merits=20 > > > of using > prefix advertisements to derive topology by adding it to a draft that=20 > is (and should be) focused on simple protocol extensions. > > > > [As WG member] > > > > I find this very compelling and so support the removal of the=20 > > referred to > non-normative appendices. > > > > Thanks, > > Chris. > > > > > > > > Thanx. > > > > > > Les > > > > > > > > >> -----Original Message----- > > >> From: Aijun Wang > > >> Sent: Thursday, October 15, 2020 6:51 PM > > >> To: 'Jeff Tantsura' ; 'John E Drake' > > >> > > >> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org;=20 > > >> Les Ginsberg > > >> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; > > >> draft-ietf- lsr-ospf-prefix-originator@ietf.org > > >> Subject: RE: [Lsr] WG Last Call > > >> draft-ietf-lsr-ospf-prefix-originator-06 > > >> > > >> Hi, Les, John and Jeff: > > >> > > >> Let's reply you all together. > > >> In my POV, The standard document should not define solely the=20 > > >> protocol extension, but their usages in the network deployment.=20 > > >> As I known, almost all the IETF documents following this style. > > >> And, before adopting one work, we have often intense discussion=20 > > >> for what's their usages. > > >> Such discussion in the mail list and statements in the document=20 > > >> can certainly assist the reader/user of the document get the=20 > > >> essence of the standard, and follow them unambiguously. > > >> > > >> Regarding the contents of appendices, as stated in the section,=20 > > >> "The Appendix A heuristic to rebuild the topology can normally be = > > >> used if all links are numbered." I think this can apply almost=20 > > >> most of the operator's network, and facilitate the inter-area TE=20 > > >> path calculation for central controller, or even for the head-end = > > >> router that located in one area that different from the tail- end = router. > > >> > > >> Keeping the contents of appendices does not have the negative=20 > > >> impact of the protocol extension, it is just one reference for=20 > > >> the usage of this extension. > > >> One can select not refer to it, if their networks are deployed=20 > > >> with large amount of unnumbered links. But for others, the = heuristic applies. > > >> > > >> Best Regards > > >> > > >> Aijun Wang > > >> China Telecom > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On=20 > > >> Behalf Of Jeff Tantsura > > >> Sent: Friday, October 16, 2020 5:28 AM > > >> To: John E Drake > > >> Cc: Christian Hopps ; lsr-chairs@ietf.org; Les = > > >> Ginsberg > > >> (ginsberg) ; lsr@ietf.org; > > >> lsr- ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org > > >> Subject: Re: [Lsr] WG Last Call > > >> draft-ietf-lsr-ospf-prefix-originator-06 > > >> > > >> +1 > > >> > > >> Regards, > > >> Jeff > > >> > > >>> On Oct 15, 2020, at 11:33, John E Drake > > >> wrote: > > >>> > > >>> =EF=BB=BFHi, > > >>> > > >>> I agree with Les. This is a simple protocol extension for a=20 > > >>> specific purpose > > >> and there is no reason to include speculation about its use for=20 > > >> other purposes, particularly when it is inherently not suited for = them. > > >>> > > >>> Yours Irrespectively, > > >>> > > >>> John > > >>> > > >>> > > >>> Juniper Business Use Only > > >>> > > >>>> -----Original Message----- > > >>>> From: Lsr On Behalf Of Les Ginsberg > > >>>> (ginsberg) > > >>>> Sent: Thursday, October 15, 2020 12:33 PM > > >>>> To: Christian Hopps ; lsr@ietf.org > > >>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; > > >>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org > > >>>> Subject: Re: [Lsr] WG Last Call > > >>>> draft-ietf-lsr-ospf-prefix-originator-06 > > >>>> > > >>>> [External Email. Be cautious of content] > > >>>> > > >>>> > > >>>> I support moving this document forward. > > >>>> Similar functionality in IS-IS has proved useful. > > >>>> > > >>>> I would however like to repeat comments I made earlier in the=20 > > >>>> review of this document. > > >>>> The content of the Appendices should be removed. > > >>>> The Appendices define and discuss deriving topology information = > > >>>> from prefix advertisements - which is flawed and should not be = done. > > >>>> Perhaps more relevant, the purpose of the document is to define = > > >>>> protocol extensions supporting advertisement of the originators = > > >>>> of a prefix advertisement. There is no need to discuss how this = > > >>>> mechanism might be used to build topology information. > > >>>> This document should confine itself to defining the protocol=20 > > >>>> extensions - similar the RFC 7794. > > >>>> > > >>>> If the authors do not agree to do this, I would encourage this=20 > > >>>> point to be discussed during IESG review. > > >>>> > > >>>> Les > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Lsr On Behalf Of Christian Hopps > > >>>>> Sent: Wednesday, October 14, 2020 11:15 PM > > >>>>> To: lsr@ietf.org > > >>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; > > >>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps=20 > > >>>>> > > >>>>> Subject: [Lsr] WG Last Call > > >>>>> draft-ietf-lsr-ospf-prefix-originator-06 > > >>>>> > > >>>>> This begins a 2 week WG Last Call, ending after Oct 29th, = 2020, for: > > >>>>> > > >>>>> > > >>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/d > > >>>>> ra > > >>>>> ft-i > > >>>>> et > > >>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- > > >> gk!TaSzQThghtCFOuYPS2VjLq > > >>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ > > >>>>> > > >>>>> The following IPR has been filed > > >>>>> > https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! > > >>>>> !NEt6yMaO- > > >>>> > gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz > > >>>>> 5KtUHQ$ > > >>>>> > > >>>>> Authors, > > >>>>> > > >>>>> Please indicate to the list, your knowledge of any other IPR=20 > > >>>>> related to this work. > > >>>>> > > >>>>> Thanks, > > >>>>> Chris. > > >>>> > > >>>> _______________________________________________ > > >>>> Lsr mailing list > > >>>> Lsr@ietf.org > > >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin > > >>>> fo > > >>>> /lsr > > >>>> __;!!NEt > > >>>> 6yMaO- > > >>>> > > >> > gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm > > >> w8 > > >>>> Lc$ > > >>> > > >>> _______________________________________________ > > >>> Lsr mailing list > > >>> Lsr@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/lsr > > >> > > >> _______________________________________________ > > >> Lsr mailing list > > >> Lsr@ietf.org > > >> https://www.ietf.org/mailman/listinfo/lsr > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > >=20 >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr From nobody Mon Oct 19 00:32:36 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAA93A14A5; Mon, 19 Oct 2020 00:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.698 X-Spam-Level: X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=e80gihTw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=A1uBZOgy 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 b-ufS2ad2rks; Mon, 19 Oct 2020 00:32:33 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD703A14A2; Mon, 19 Oct 2020 00:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25930; q=dns/txt; s=iport; t=1603092752; x=1604302352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+ZhrJQ+9kwTmNgnPqg51JbQSSIDyaHtxhxVTJhX+jpc=; b=e80gihTwmiDRHJ9gz2VErJt1y4TJ78gwjgAZhOhdF9RbjPccstit+xb5 ukxtvWu2dsDVKce48C343u7APdxwSOOyZQDTNbws8fFSs3l5dDAho/VuY qo8kt5W9KT4Q1A44ME1qjJKIqoRDgaOeo2sHE/AZGGjLhpR5XyzybCtIc I=; IronPort-PHdr: =?us-ascii?q?9a23=3AJDWeQBB7mjGY+DVFtScDUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw30g3VRoTd5PJZgqzRqa+mUmpTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBvmaz6zESBx?= =?us-ascii?q?y5MhB6YO/zScbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0nx?= =?us-ascii?q?DIuXBPPe9RwDBl?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiBQARQI1f/5BdJa1WChwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFPgVIjLgdwWS8shD2DSQONTIoQjmqBQoERA1ULAQEBDQE?= =?us-ascii?q?BGAsKAgQBAYRKAheBdAIlOBMCAwEBCwEBBQEBAQIBBgRthWEMhXIBAQEEAQE?= =?us-ascii?q?QEREMAQEsCwELBAIBBgIRBAEBAQICIwMCAgIfBgsUAQgIAgQBDQUIGoMFgks?= =?us-ascii?q?DLgEOkkaQaQKBOYhodoEygwQBAQWBMwETQYMdDQuCEAMGgQ4qgnKDboEGhVA?= =?us-ascii?q?bgUE/gRABQ4JNPoIaQgEBAgEBgSYBBwoCAQYcFQ+CcTOCLJAKBIMGAT2jWFQ?= =?us-ascii?q?KgmqJBIxigiGDDIMWigmUMZMxinOCbI8XWIJfAgQCBAUCDgEBBYFrI2dwcBU?= =?us-ascii?q?7gjUBAQExUBcCDY4fDBeDToUUhUJ0AjYCBgEJAQEDCXyNTAEB?= X-IronPort-AV: E=Sophos;i="5.77,394,1596499200"; d="scan'208";a="586397249" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Oct 2020 07:32:30 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 09J7WUJw008397 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2020 07:32:30 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 19 Oct 2020 02:32:30 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 19 Oct 2020 02:32:29 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 19 Oct 2020 02:32:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cpBoIN9mJm0NJVihNvIRr92QHr6cLbzI0c/bxSnrKPQUnEYlS0uQ8yqHrRVBUdVWxoJ+3bvqONx4K6ZFsp4+r51u9aJOIrnOyU5kYNVrbJSHiOc2Ry2ly9vqwbX2CRO7mtAZPRzud4tZxa2XykTIawmkbE2V/0LseUwIEjVL0Bc0Yx2hXMHw39oXluP8795rUIav764iBY0JHxuky2boOgfRpI8JkdKHcu9BzMX1ga01i66LXniNJFAyXulVL25d7zYgbgixAJjgBOQ2I0mFzLIGnWy2XwzuV8Y65YObmT2QHith9rccJuh2n8RxrQlTlAYgAITa/vEdrWGZzxFvEA== 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=+ZhrJQ+9kwTmNgnPqg51JbQSSIDyaHtxhxVTJhX+jpc=; b=NBRWdBjxfcTLpLJ5XL18laHtMl6anmzb0GGKw2NSlcPVzgB2WMCLxTaL+qk668qBq58PYZB9ppgl8PVYPy5i11ZdhqG8u0Dr47hQuri/HzDWVTk81nR12IzUqzB2kDMIBrtPFEh96zwklAtvnAD+9ZjaPjlP+6sfCvBIZEmA7T19NkCt7Haeh1naEVEMQ3sv8mMmCM9tFaNzj7N9Annuqcy7uUYEIViVSURx+8J0QUAXCuQK2RBDF+p3Hx99aM//SCQofSAqujPDZxjYPIEe7l+HhwWtw3se3itugqV8CtnO1+9EJfhlCiMb87dk5M+05qXrhqxkwozy0F+ZZWQqFw== 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=+ZhrJQ+9kwTmNgnPqg51JbQSSIDyaHtxhxVTJhX+jpc=; b=A1uBZOgykJaGo9SvnFobqik83wMC9s9Pw1Ecr0C0vRI82cUN9hS8QgktI3E07VUCY8ED5tv0T1vOOREYMAH233UYp2nsEDVkfWckIdc5NCLX8doELxk/ib+95Y9k5zVLoZms8/IrqnBUavr7hg1nn1CUg6ZyKq1StmIyKVXOYr8= Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB3429.namprd11.prod.outlook.com (2603:10b6:a03:91::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.28; Mon, 19 Oct 2020 07:32:28 +0000 Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::e063:fc51:b359:2f39]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::e063:fc51:b359:2f39%7]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 07:32:28 +0000 From: "Les Ginsberg (ginsberg)" To: Aijun Wang , "'Christian Hopps'" CC: "'John E Drake'" , "lsr-chairs@ietf.org" , "lsr@ietf.org" , "'Jeff Tantsura'" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWo8tEkGkRfwue4kKs1uag2Lc//qmeMcAAgABCWSCAABD5gIAABGCQ Date: Mon, 19 Oct 2020 07:32:28 +0000 Message-ID: References: <303E621F-47AA-4309-AC85-32A597604C7C@chopps.org> <00b401d6a5bc$ac44e800$04ceb800$@tsinghua.org.cn> <00ea01d6a5e6$54f371f0$feda55d0$@tsinghua.org.cn> In-Reply-To: <00ea01d6a5e6$54f371f0$feda55d0$@tsinghua.org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2602:306:36ca:6640:2c60:818d:fe1c:43a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5e60a67-6358-4942-5429-08d8740121b7 x-ms-traffictypediagnostic: BYAPR11MB3429: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ijmn5A2jUFQOgI0RkMPMBuwBb4wcZDv3Tawp218aNT1LpSTsjN9V8XRX8aF4+dGnG+0Mdbrb2zdgKJhUDYl5pdjWENUlFsjVsEy/aMA576xl2fG46uri9mBpi9DOIXjbdYdezA0JyKpnat0eyA+FatujcvGXAYidVLF3Y1Fpnffq0IECaoYUR+AcrFzZjgPE3nV5Ly8PnsRvzZ+pelc2lEBJouPSxsJ6+ZqdvTjsTuJeUiGZGRk2ep3X6tGvsu1TWIK2ggYhHWPZsqhkSvhG4YFG1cUAk1O8itLhYjkszoqGf+Ek4+5Pvza+EXHxqU0KndjnnSe8QIHTf7MUSaQIM0b7rzA36QywJ1BJqK2mf1s8rGo8nCHTlhzpqMUo/qQMajkWfh5B8xQciSQgRMSphw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(396003)(39860400002)(136003)(366004)(8936002)(5660300002)(478600001)(316002)(86362001)(33656002)(110136005)(66946007)(52536014)(66476007)(66556008)(8676002)(66446008)(30864003)(64756008)(53546011)(6506007)(966005)(2906002)(76116006)(9686003)(55016002)(83380400001)(4326008)(66574015)(54906003)(186003)(7696005)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: e4XTqeOOG9F2dBnkiaRPDkQhTaYYuhm+VXrITgVUoOj/HrPaqX/qT34tenJo4MEqNoZF8wb0JmKWtozaRG2NXaRlGb42t7+dG5CvQTrA4ktCPPqWwVd4UAyWl85C5MzxLF1hTVNn1x3Spktrn6u6hFsuqelcvDUrLiljPYoDkXyJZ0LiQXg//dKTFtTyBPN9wztys9lnP3PExydQcxben7hr0lfarfWJnMbVn07j4BG0Sp0WP05i5wzq2fV+scs75JJROLPbwp8vohtY9g1rg6TkszSKHLnxKV/Y1jCxTYdT1NY1KWQuEqRjWAQpSG+uvx5sE/kreKlVnEN116EuFGciGUmRjjIN/a3f+xJElpsyp+1Rw7lQMI2LRH2vegPTpEAK7PsgL1o1GJgn86bGABVJoo4gMak1lksqUybZzTYgBYI8SjKjgrMrNrlCaFWqm2NW4HHC42oMJI12+snKsCeKbTlpYEzzQbr0RzFU8vkwEvdgMHBNr5LaKA18KMUtm4kBeESD1CG7FXUzw7AnqO5pY4jZS7UiT5BY++n/OwULMETkphWXQGGD3bsbVI6YeJqxhYlQ9S4Lnrm05Hkyybae6xVImFZ4KIaqTu4K2+AzrhBKgpkLWWMZB2dQOooMRGnHSul/SQSyKHOuCh8ap5TQPg7XaP/KJnF+NNvDF73Ya2FLnOEi+/12QBKkT5QDWb7dWnfeAPfOgNg5wXGDWA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5e60a67-6358-4942-5429-08d8740121b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 07:32:28.1048 (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: 0w23N+znZS8EP8RiL2PXn101ijozwPCRtodTljqeBuFOU1NaZFf685JVNpi9mppq9RQcv6RlFUmZcjhH6S6b9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3429 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 07:32:36 -0000 QWlqdW4gLQ0KDQpJIGFtIG5vdCBnb2luZyB0byBjb250aW51ZSB0aGVzZSBzaWRlIGRpc2N1c3Np b25zIHdpdGggeW91Lg0KDQpUaGUgcHJpbWFyeSBwdXJwb3NlIG9mIHRoZSBwcm90b2NvbCBleHRl bnNpb25zIGFyZSBhcyBzdGF0ZWQgaW4gdGhlIGRyYWZ0IEludHJvZHVjdGlvbi4gVGhpcyBpcyBh bmFsb2dvdXMgdG8gdGhlIHVzZSBjYXNlcyBmb3IgdGhlIGVxdWl2YWxlbnQgZXh0ZW5zaW9ucyBm b3IgSVMtSVMgYWxyZWFkeSBhcHByb3ZlZCBpbiBSRkMgNzc5NC4gV2UgbmVlZCB0aGUgZXF1aXZh bGVudCBpbiBPU1BGLg0KDQpZb3UgY2FuIHNob3cgdGhhdCB5b3UgYXJlIGxpc3RlbmluZyB0byB0 aGUgY29uY2VybnMgb2YgV0cgbWVtYmVycyBieSByZW1vdmluZyB0aGUgQXBwZW5kaWNlcyAtIGlu IHdoaWNoIGNhc2UgeW91IGhhdmUgKEkgYmVsaWV2ZSkgYnJvYWQgc3VwcG9ydCBmb3IgbW92aW5n IHRoZSBkcmFmdCBmb3J3YXJkLg0KWW91IGNhbiB0aGVuIHdyaXRlIGEgc2VwYXJhdGUgZHJhZnQg dG8gZGlzY3VzcyBvdGhlciB1c2UgY2FzZXMgYW5kIGFsbG93IHRoZSBXRyB0byBkaXNjdXNzIHRo b3NlIG90aGVyIHVzZSBjYXNlcyB3L28gcHJldmVudGluZyB0aGUgZXh0ZW5zaW9ucyBmcm9tIGJl aW5nIGFwcHJvdmVkIGFuZCBkZXBsb3llZCBmb3IgdGhlIHVzZSBjYXNlcyB3aGljaCBoYXZlIGFs cmVhZHkgYmVlbiBkZW1vbnN0cmF0ZWQgYXMgdXNlZnVsIGJ5IElTLUlTLg0KDQpJZiB5b3UgcmVt b3ZlIHRoZSBBcHBlbmRpY2VzIEkgY2FuIHN1cHBvcnQgdGhlIGRyYWZ0Lg0KSWYgeW91IGRvIG5v dCByZW1vdmUgdGhlIEFwcGVuZGljZXMgSSBjYW5ub3Qgc3VwcG9ydCB0aGUgZHJhZnQuDQoNClBs ZWFzZSBkaXNjdXNzIHRoaXMgd2l0aCB5b3VyIGNvLWF1dGhvcnMgYW5kIGNvbWUgdG8gY29uc2Vu c3VzIG9uIHlvdXIgbmV4dCBzdGVwLg0KDQogICBMZXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+ DQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAxOSwgMjAyMCAxMjowNiBBTQ0KPiBUbzogTGVzIEdp bnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbT47ICdDaHJpc3RpYW4gSG9wcHMn DQo+IDxjaG9wcHNAY2hvcHBzLm9yZz4NCj4gQ2M6ICdKb2huIEUgRHJha2UnIDxqZHJha2VAanVu aXBlci5uZXQ+OyBsc3ItY2hhaXJzQGlldGYub3JnOyBsc3JAaWV0Zi5vcmc7DQo+ICdKZWZmIFRh bnRzdXJhJyA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+OyBkcmFmdC1pZXRmLWxzci1vc3BmLXBy ZWZpeC0NCj4gb3JpZ2luYXRvckBpZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSRTogW0xzcl0gV0cgTGFzdCBDYWxsIGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdp bmF0b3ItMDYNCj4gDQo+IEhpLCBMZXM6DQo+IA0KPiBBcyBJIHN0YXRlZCBjbGVhcmx5IGJlZm9y ZSwgdGhlIGFwcGVuZGl4IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgaXMgbm90IHRoZSBuZXcNCj4g dXNlIGNhc2UuIEl0IGlzIHRoZSBzdGFydCBwb2ludCBvZiB0aGlzIGRyYWZ0Lg0KPiBIYXZlIHlv dSBub3RpY2VkIHRoYXQgdGhlIGludHJvZHVjdGlvbiBwYXJ0IGlzIG5vdCB0aGUgZmluYWwgdXNh Z2Ugb2Ygc3VjaA0KPiBwcm90b2NvbCBleHRlbnNpb24gaW5mb3JtYXRpb24/DQo+IENlcnRhaW5s eSwgd2Ugd2lsbCBub3QgZXhwYW5kIGFsbCB0aGUgcG9zc2libGUgdXNlIGNhc2VzIGluIHZlcnkg ZGV0YWlsLCBidXQNCj4gcHV0dGluZyBzb21lIG9mIHRoZW0oc29tZSBpbnRlcmVzdGluZywgcHJv bWluZW50IHVzZSBjYXNlcykgaW4gdGhlDQo+IGFwcGVuZGl4IHdpbGwgbm90IGhhbXBlciB0aGUg cHJvdG9jb2wgZXh0ZW5zaW9uIGl0c2VsZi4NCj4gDQo+IElmIHRoZSBzdGF0ZW1lbnRzL2Rlc2Ny aXB0aW9ucyBpbiB0aGUgYXBwZW5kaXggYXJlIG5vdCBjb3JyZWN0LCB3ZSBjYW4gZml4IGl0LA0K PiBvciByZW1vdmUgaXQgZmluYWxseS4gIElmIG5vdCwgd2h5IG5vdCBsZXQgaXQgYmUgZm9yIHJl ZmVyZW5jZSB0byB0aGUgdXNlciBvZiBzdWNoDQo+IHByb3RvY29sIGV4dGVuc2lvbj8NCj4gRm9y IHRoZSBib2R5IHBhcnQgb2YgdGhpcyBkcmFmdCwgd2UgYXJlIGFsc28gd2VsY29tZSBjb21tZW50 cy4NCj4gDQo+IE1vcmUgcmVwbGllcyBpbmxpbmUgYmVsb3dbV0FKXQ0KPiANCj4gQmVzdCBSZWdh cmRzDQo+IA0KPiBBaWp1biBXYW5nDQo+IENoaW5hIFRlbGVjb20NCj4gDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHNy LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZXMNCj4gR2luc2JlcmcgKGdpbnNiZXJn KQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMjAgMjoxNSBQTQ0KPiBUbzogQWlqdW4g V2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj47ICdDaHJpc3RpYW4gSG9wcHMnDQo+IDxj aG9wcHNAY2hvcHBzLm9yZz4NCj4gQ2M6ICdKb2huIEUgRHJha2UnIDxqZHJha2VAanVuaXBlci5u ZXQ+OyBsc3ItY2hhaXJzQGlldGYub3JnOyAnTGVzIEdpbnNiZXJnDQo+IChnaW5zYmVyZyknIDxn aW5zYmVyZz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47IGxzckBpZXRmLm9yZzsgJ0plZmYN Cj4gVGFudHN1cmEnIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT47IGRyYWZ0LWlldGYtbHNyLW9z cGYtcHJlZml4LQ0KPiBvcmlnaW5hdG9yQGlldGYub3JnOyBsc3ItYWRzQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgt b3JpZ2luYXRvci0wNg0KPiANCj4gQWlqdW4gLQ0KPiANCj4gVGhlICJ1c2UgY2FzZSIgZm9yIHRo ZSBwcm90b2NvbCBleHRlbnNpb25zIGlzIGNsZWFybHkgc3RhdGVkIGluIHRoZQ0KPiBJbnRyb2R1 Y3Rpb246DQo+IA0KPiAiVGhlIHByaW1hcnkgdXNlIGNhc2UgZm9yIHRoZSBleHRlbnNpb25zIHBy b3Bvc2VkIGluIHRoaXMgZG9jdW1lbnQgaXMNCj4gICAgdG8gYmUgYWJsZSB0byBpZGVudGlmeSB0 aGUgb3JpZ2luYXRvciBvZiB0aGUgcHJlZml4IGluIHRoZSBuZXR3b3JrLg0KPiAgICBJbiBjYXNl cyB3aGVyZSBtdWx0aXBsZSBwcmVmaXhlcyBhcmUgYWR2ZXJ0aXNlZCBieSBhIGdpdmVuIHJvdXRl ciwgaXQNCj4gICAgaXMgYWxzbyB1c2VmdWwgdG8gYmUgYWJsZSB0byBhc3NvY2lhdGUgYWxsIHRo ZXNlIHByZWZpeGVzIHdpdGggYQ0KPiAgICBzaW5nbGUgcm91dGVyIGV2ZW4gd2hlbiBwcmVmaXhl cyBhcmUgYWR2ZXJ0aXNlZCBvdXRzaWRlIG9mIHRoZSBhcmVhDQo+ICAgIGluIHdoaWNoIHRoZXkg b3JpZ2luYXRlZC4gIEl0IGFsc28gaGVscHMgdG8gZGV0ZXJtaW5lIHdoZW4gdGhlIHNhbWUNCj4g ICAgcHJlZml4IGlzIGJlaW5nIG9yaWdpbmF0ZWQgYnkgbXVsdGlwbGUgcm91dGVycyBhY3Jvc3Mg YXJlYXMuIg0KPiANCj4gVGhpcyBpcyBlcXVpdmFsZW50IHRvIGxhbmd1YWdlIGluIFJGQyA3Nzk0 IHdoaWNoIGRlZmluZXMgdGhlIGFuYWxvZ291cw0KPiBleHRlbnNpb25zIGZvciBJUy1JUy4NCj4g DQo+IEV2ZXJ5dGhpbmcgeW91IGhhdmUgaW4gdGhlIEFwcGVuZGl4IGlzIG5vdCByZWxhdGVkIHRv IHRoZSBwcmltYXJ5IHVzZSBjYXNlIC0NCj4gYW5kIGlzIGZhY3QgYSB1c2UgY2FzZSB3aGljaCBt YW55IG9mIHVzIGhhdmUgb2JqZWN0ZWQgdG8uDQo+IFtXQUpdIFZlcnkgZ2xhZCB0byBrbm93IHRo ZSBmYWxzZSBzdGF0ZW1lbnRzIGluIHRoZSBhcHBlbmRpeC4NCj4gDQo+IFlvdSBhcmUgZW50aXRs ZWQgdG8gd3JpdGUgYW5vdGhlciBkcmFmdCBhZHZvY2F0aW5nIGZvciB5b3VyIG5ldyB1c2UgY2Fz ZSBpZg0KPiB5b3Ugd2lzaCwgYnV0IHJlcXVpcmluZyB0aGF0IHRoZSBwcm90b2NvbCBleHRlbnNp b25zIGluIHN1cHBvcnQgb2YgdGhlDQo+IHByaW1hcnkgdXNlIGNhc2Ugbm90IGdvIGZvcndhcmQg d2l0aG91dCB5b3VyIG5ldyB1c2UgY2FzZSBpcyAtIGFzIENocmlzIGhhcw0KPiBzdGF0ZWQgdmVy eSBjbGVhcmx5IC0gaG9sZGluZyBhcHByb3ZhbCBvZiB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9ucyBo b3N0YWdlIHRvDQo+IHlvdXIgbmV3IHVzZSBjYXNlLg0KPiBbV0FKXSBJdCBpcyBub3QgbmV3IHVz ZSBjYXNlLiBBcyBJIHNhdGVkIGJlZm9yZSwgSSBhbSBvcGVuIHRvIHRoaXMgcGFydCwgYnV0DQo+ IHNob3VsZCBvbiB0aGUgY29uZGl0aW9ucyB0aGF0IHRoZSBzdGF0ZW1lbnRzIGluIHRoaXMgcGFy dCBhcmUgaW5jb3JyZWN0Lg0KPiANCj4gSSBhbSBhc2tpbmcgeW91ICh5ZXQgYWdhaW4pIG5vdCB0 byBkbyB0aGlzLg0KPiANCj4gSSBjYW5ub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQgbW92aW5nIGZv cndhcmQgd2l0aCB0aGUgY29udGVudCBpbiB0aGUNCj4gQXBwZW5kaWNlcyBpbmNsdWRlZC4NCj4g W1dBSl0gV291bGQgbGlrZSB0byBoZWFyIG1vcmUgdGVjaG5pY2FsIGFuYWx5c2lzLg0KPiANCj4g ICAgTGVzDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IExzciA8bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBBaWp1biBXYW5nDQo+ID4g U2VudDogU3VuZGF5LCBPY3RvYmVyIDE4LCAyMDIwIDc6MDggUE0NCj4gPiBUbzogJ0NocmlzdGlh biBIb3BwcycgPGNob3Bwc0BjaG9wcHMub3JnPg0KPiA+IENjOiAnSm9obiBFIERyYWtlJyA8amRy YWtlQGp1bmlwZXIubmV0PjsgbHNyLWNoYWlyc0BpZXRmLm9yZzsgJ0xlcw0KPiA+IEdpbnNiZXJn IChnaW5zYmVyZyknIDxnaW5zYmVyZz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47DQo+ID4g bHNyQGlldGYub3JnOyAnSmVmZiBUYW50c3VyYScgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsN Cj4gPiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC0gb3JpZ2luYXRvckBpZXRmLm9yZzsgbHNy LWFkc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPiBk cmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4NCj4gPiBIaSwgQ2hy aXM6DQo+ID4NCj4gPiBJIHRoaW5rIHdlIGhhdmUgInB1dCB0aGUgY2FydCBiZWZvcmUgdGhlIGhv cnNlIi4gRm9yIHByb3RvY29sDQo+ID4gZXh0ZW5zaW9uIGRyYWZ0LCB0aGUgb3JpZ2luIGlzIHRo ZSB1c2UgY2FzZS4NCj4gPiBBbmQgSSB0aGluayB3ZSB3aWxsIG5vdCBleHBhbmQgT1NQRiBwcm90 b2NvbCwganVzdCBiZWNhdXNlIGl0IGxhY2sNCj4gPiBzb21ldGhpbmcgYXMgY29tcGFyZWQgd2l0 aCBJU0lTLCByaWdodD8NCj4gPg0KPiA+IEFzIEkgc3RhdGVkIGJlZm9yZSwgdGhlIHVzZSBjYXNl IGluIGN1cnJlbnQgYXBwZW5kaXggaXMgdGhlIG1haW4NCj4gPiBtb3RpdmF0aW9uIG9mIHRoaXMg ZHJhZnQsIHlvdSBjYW4gc2VlIHRoaXMgaW4gbWFpbiBib2R5IG9mIHRoZSBlYXJsaWVyDQo+ID4g dmVyc2lvbiBvZiB0aGlzIGRyYWZ0KGZyb20gdmVyc2lvbiAwIHRvIHZlcnNpb24gNSkuDQo+ID4g VGhlIHJlYXNvbiB0aGF0IHdlIG1vdmUgdGhpcyBwYXJ0IHRvIHRoZSBhcHBlbmRpeCwgYXMgdGhh dCB5b3Ugc2FpZCwNCj4gPiBpcyB0byBsZXQgcGVyc29uIGZvY3VzIG9uIHRoZSBwcm90b2NvbCBl eHRlbnNpb24gaXRzZWxmLg0KPiA+DQo+ID4gTW92aW5nIHRoaXMgcGFydCB0byBhcHBlbmRpeCBp cyBhY2NlcHRhYmxlLCBidXQgcmVtb3ZpbmcgaXQgZnJvbSB0aGUNCj4gPiBkcmFmdCB3aWxsIGVy YXNlIHRoZSBvcmlnaW4gb2YgdGhpcyBkb2N1bWVudC4NCj4gPiBJcyBpdCByZWFzb25hYmxlIHRo YXQgb25lIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgIm9yaWdpbiIob2YgdGhlDQo+ID4gcHJlZml4 KSwgY2FuJ3Qga2VlcCBpdHMgb3JpZ2luPw0KPiA+DQo+ID4gTW9yZSByZXBsaWVzIGlubGluZSBi ZWxvd1tXQUpdLg0KPiA+DQo+ID4gQmVzdCBSZWdhcmRzDQo+ID4NCj4gPiBBaWp1biBXYW5nDQo+ ID4gQ2hpbmEgVGVsZWNvbQ0KPiA+DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+IENocmlzdGlhbiBIb3Bwcw0KPiA+IFNlbnQ6IEZyaWRh eSwgT2N0b2JlciAxNiwgMjAyMCAxMDo0NyBQTQ0KPiA+IFRvOiDnjovniLHkv4ogPHdhbmdhaWp1 bkB0c2luZ2h1YS5vcmcuY24+DQo+ID4gQ2M6IEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIu bmV0PjsgQ2hyaXN0aWFuIEhvcHBzDQo+ID4gPGNob3Bwc0BjaG9wcHMub3JnPjsgbHNyLWNoYWly c0BpZXRmLm9yZzsgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCj4gPiA8Z2luc2Jlcmc9NDBjaXNj by5jb21AZG1hcmMuaWV0Zi5vcmc+OyBsc3JAaWV0Zi5vcmc7IEplZmYgVGFudHN1cmENCj4gPiA8 amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+Ow0KPiA+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4 LW9yaWdpbmF0b3JAaWV0Zi5vcmc7IGxzci0gYWRzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6 IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdp bmF0b3ItMDYNCj4gPg0KPiA+IElzbid0IHRoaXMganVzdCBhZGRpbmcgYW4gYW5hbG9nb3VzIGV4 dGVuc2lvbiB0aGF0IGFscmVhZHkgZXhpc3RzIGluIFJGQzc3OTQ/DQo+ID4gW1dBSl0gTm8uIFJG Qzc3OTQgaXMganVzdCBvbmUgZXhhbXBsZSB0aGF0IHRvIGlsbHVzdHJhdGUsIGFzIHRoZQ0KPiA+ IGNvbXBhbmlvbiBJR1AgcHJvdG9jb2wsIE9TUEYgY2FuIGFsc28gYWNjb21wbGlzaCB0aGlzLiBB bmQsIGFjdHVhbGx5LA0KPiA+IHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBjb25zaWRlcmF0aW9uIGlu IHRoaXMgZHJhZnQgZm9yIHRoZSBwcm90b2NvbCBleHRlbnNpb24uDQo+ID4NCj4gPiBJIGRvbid0 IHRoaW5rIHdlIG5lZWQgdG8gZG8gYSBsb3Qgb2YgY29udmluY2luZyBhdCB0aGlzIHBvaW50LiBJ IGFncmVlDQo+ID4gd2l0aCBMZXMsIGlmIHlvdSB3YW50IHRvIHRhbGsgYWJvdXQgdXNlIGNhc2Vz IChlc3BlY2lhbGx5IG9uZXMgdGhhdA0KPiA+IGFyZSBjb250cm92ZXJzaWFsISkgdGhlbiB0aGUg Y29ycmVjdCBwbGFjZSBmb3IgdGhhdCBpcyBpbiBhIG5ldyBpbmZvcm1hdGl2ZQ0KPiBkcmFmdC4N Cj4gPiBbV0FKXSB3ZSBoYXZlIGRpc2N1c3NlZCB0aGUgdXNlIGNhc2UgYmVmb3JlIGFuZCBzdGF0 ZSB0aGUgZGlzY3Vzc2lvbg0KPiA+IHJlc3VsdHMgYXQgdGhlIGFwcGVuZGl4IHBhcnQuIFdlIHdp bGwgbm90IGVtcGhhc2lzIGFuZCBleHBhbmQgdGhlIHVzZQ0KPiA+IGNhc2UgbW9yZS4gSWYgb25l IGRvZXMgbm90IGFncmVlIHRoZSBzdGF0ZW1lbnQgb2YgdGhpcyBhcHBlbmRpeCwgd2UNCj4gPiBj YW4gZGlzY3VzcyBvbmxpbmUgb3Igb2ZmbGluZS4gV2UganVzdCBuZWVkIHRvIG1ha2UgdGhlIHN0 YXRlbWVudCBpbg0KPiBhcHBlbmRpeCBpcyBjb3JyZWN0Lg0KPiA+DQo+ID4gT3RoZXJ3aXNlLCBl c3BlY2lhbGx5IGlmIHRoZSBjYXNlcyBhcmUgY29udHJvdmVyc2lhbCwgdGhpcyBjYW4gYmUgc2Vl bg0KPiA+IGFzIGRvaW5nIGFuICJlbmQtcnVuIiB0byBhdm9pZCB0aGUgZGViYXRlIGIvYyBwZW9w bGUgd2FudCB0aGUNCj4gPiBleHRlbnNpb24sIGJ1dCBtYXliZSBkb24ndCBhZ3JlZSB3aXRoIHlv dXIgdXNlIGNhc2UuDQo+ID4gW1dBSl0gT25lIHNob3VsZCBwb2ludCBvdXQgd2hpY2ggc3RhdGVt ZW50IGluIHRoZSBhcHBlbmRpeCBpcw0KPiA+IGNvbnRyb3ZlcnNpYWwsIHdlIGNhbiBjb3JyZWN0 IGl0LiBUaGlzIHVzZSBjYXNlIGlzIHRoZSBvcmlnaW4gb2YgdGhpcw0KPiA+IGRyYWZ0LCBub3Qg dGhlIHJlc3VsdHMuDQo+ID4NCj4gPiBMZWdpc2xhdG9ycyBkbyB0aGlzIHNvbWV0aW1lcyBhZGRp bmcgdGhpbmdzIHRoZXkgd2FudCBwZXJzb25hbGx5IHRvDQo+ID4gcG9wdWxhciBiaWxscywgdGhh dCBvdGhlciBwZW9wbGUgbWF5IG5vdCB3YW50LCBidXQgc2luY2UgcGVvcGxlIHdhbnQNCj4gPiB0 aGUgbWFpbiBiaWxsIHRoZXkgdm90ZSBmb3IgaXQgYW55d2F5LCBpbiB0aGUgVVMgaXQncyBjYWxs ZWQgImFkZGluZw0KPiA+IHBvcmsiIG9yICJwb3JrIGJhcnJlbCBwb2xpdGljcyIuIDopIFtXQUpd IFRoZSBhcHBlbmRpeCBpcyBub3QgYWRkZWQNCj4gPiBsYXRlciwgYnV0IGV4aXN0IGF0IHRoZSBm aXJzdCBiZWdpbm5pbmcuIFRoaXMgaXMgdGhlIG9yaWdpbiBvZiB0aGUNCj4gPiBiaWxscy4NCj4g Pg0KPiA+IFRoYW5rcywNCj4gPiBDaHJpcy4NCj4gPg0KPiA+ID4gT24gT2N0IDE2LCAyMDIwLCBh dCAxMDozNyBBTSwg546L54ix5L+KIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPg0KPiA+IHdy b3RlOg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBIaSwgQ2hyaXM6DQo+ID4gPiBPcmlnaW5hbGx5LCB0 aGUgYXBwZW5kaXggcGFydCBpcyB3aXRoaW4gdGhlIGRvY3VtZW50LCB3aGljaCBpcyB0aGUNCj4g PiA+IHN0YXJ0DQo+ID4gcG9pbnQvbWFpbiBtb3RpdmF0aW9uIHRvIGV4dGVuZCB0aGUgcHJlZml4 IG9yaWdpbi4NCj4gPiA+IFRoZXJlIG1heSBleGlzdHMgb3RoZXIgdXNhZ2VzIG9mIHRoaXMgaW5m b3JtYXRpb24uIFBhY2sgdGhlc2UNCj4gPiA+IGV4YW1wbGVzDQo+ID4gaW50byBzb21lIHNob3J0 IHNlbnRlbmNlcyBvciBpbnRyb2R1Y3Rpb24gaXMgdmlhYmxlLCBidXQgZXhwYW5kIHNvbWUNCj4g PiBvZiB0aGVtIGlzIGFsc28gaGVscGZ1bC4NCj4gPiA+IEFzIEkga25vd24sIHdoZW4gd2Ugd2Fu dCB0byBkbyBwcm90b2NvbCBleHRlbnNpb24sIHdlIHNob3VsZCAgYWx3YXlzDQo+ID4gY29udmlu Y2Ugb3RoZXIgdGhlIHJlYXNvbi9tb3RpdmF0aW9uL3Byb3NwZWN0cyB0byBkbyBzby4gT24gdGhl IG90aGVyDQo+ID4gaGFuZCwgdGhlIHVzZSBjYXNlIGRlc2NyaWJlZCBpbiB0aGUgY3VycmVudCBh cHBlbmRpeCBpcyB2ZXJ5IHByb21pbmVudA0KPiA+IGZvciBvcGVyYXRvciB0byBhY2NvbXBsaXNo IHRoZSBURSB0YXNrIGluIG11bHRpLWFyZWEgZW52aXJvbm1lbnQuDQo+ID4gPg0KPiA+ID4gQWlq dW4gV2FuZw0KPiA+ID4NCj4gPiA+IOWcqDIwMjAtMTAtMTbvvIxDaHJpc3RpYW4gSG9wcHMgJmx0 O2Nob3Bwc0BjaG9wcHMub3JnJmd0O+WGmemBkzoNCj4gPiA+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0t LS0NCj4gPiA+IOWPkeS7tuS6uu+8miBDaHJpc3RpYW4gSG9wcHMgJmx0O2Nob3Bwc0BjaG9wcHMu b3JnJmd0Ow0KPiA+ID4g5Y+R5Lu25pe26Ze0OiAyMDIw5bm0MTDmnIgxNuaXpSDmmJ/mnJ/kupQN Cj4gPiA+IOWGmemBkzogWyZxdW90O0xlcyBHaW5zYmVyZyAoZ2luc2JlcmcpJnF1b3Q7DQo+ID4g PiAmbHQ7Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7XQ0KPiA+ID4g5Li7 6aKY77yaIFJlOiBbTHNyXSBXRyBMYXN0IENhbGwgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgt b3JpZ2luYXRvci0wNg0KPiA+ID4NCj4gPiA+ID4gT24gT2N0IDE2LCAyMDIwLCBhdCAxOjUxIEFN LCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KPiA+IDxnaW5zYmVyZz00MGNpc2NvLmNvbUBkbWFy Yy5pZXRmLm9yZz4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+IEFpanVuIC0NCj4gPiA+ID4NCj4g PiA+ID4gVGhlIHBvaW50IEkgYW0gbWFraW5nIGlzIHZlcnkgZm9jdXNlZC4NCj4gPiA+ID4NCj4g PiA+ID4gVGhpcyBkcmFmdCBpcyBkZWZpbmluZyBhIHByb3RvY29sIGV4dGVuc2lvbi4gQXMgc3Vj aCBpdCBpcw0KPiA+ID4gPiBuZWNlc3NhcnkgdGhhdCB0aGlzDQo+ID4gYmUgU3RhbmRhcmRzIHRy YWNrIGFzIGFkaGVyaW5nIHRvIHRoZSBub3JtYXRpdmUgc3RhdGVtZW50cyBpbiB0aGUNCj4gPiBk cmFmdCBhcmUgbmVjZXNzYXJ5IGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KPiA+ID4gPg0KPiA+ID4g PiBXaGF0IGlzIGRpc2N1c3NlZCBpbiB0aGUgQXBwZW5kaXggaXMgYSB1c2UgY2FzZS4gSXQgaXMg bm90DQo+ID4gPiA+IG5vcm1hdGl2ZSBhbmQNCj4gPiB0aGVyZSBhcmUgc3Ryb25nIG9waW5pb25z IG9uIGJvdGggc2lkZXMgYXMgdG8gd2hldGhlciB0aGlzIGlzIGFuDQo+ID4gYXBwcm9wcmlhdGUg dXNlIGNhc2Ugb3Igbm90Lg0KPiA+ID4gPiBJbiB0aGUgY29udGV4dCBvZiB0aGlzIGRyYWZ0LCBJ IGhhdmUgbm8gaW50ZXJlc3QgaW4gdHJ5aW5nIHRvDQo+ID4gPiA+IHJlc29sdmUgb3VyDQo+ID4g ZGlmZmVyZW5jZSBvZiBvcGluaW9uIG9uIHRoaXMgdXNlIGNhc2UuIEkgc2ltcGx5IHdhbnQgdGhl IHByb3RvY29sDQo+ID4gZXh0ZW5zaW9uIHRvIG1vdmUgZm9yd2FyZCBzbyB0aGF0IHdlIGhhdmUg YW5vdGhlciB0b29sIGF2YWlsYWJsZS4NCj4gPiA+ID4NCj4gPiA+ID4gSWYgeW91IHdhbnQgdG8g d3JpdGUgYSBkcmFmdCBvbiB0aGUgdXNlIGNhc2UgZGlzY3Vzc2VkIGluIHRoZQ0KPiA+ID4gPiBB cHBlbmRpeA0KPiA+IHBsZWFzZSBmZWVsIGZyZWUgdG8gZG8gc28uIFRoYXQgZHJhZnQgbWF5IHZl cnkgd2VsbCBub3QgYmUgbm9ybWF0aXZlIC0NCj4gPiBJbmZvcm1hdGlvbmFsIG9yIEJDUCBtYXkg YmUgbW9yZSBhcHByb3ByaWF0ZSAtIGJlY2F1c2UgaXQgd2lsbCBiZQ0KPiA+IGRpc2N1c3Npbmcg YSBkZXBsb3ltZW50IHNjZW5hcmlvIGFuZCBhIHByb3Bvc2FsIHRvIHVzZSBkZWZpbmVkDQo+ID4g cHJvdG9jb2wgZXh0ZW5zaW9ucyBhcyBvbmUgd2F5IHRvIHNvbHZlIHByb2JsZW1zIGluIHRoYXQg ZGVwbG95bWVudA0KPiA+IHNjZW5hcmlvLiBTdWNoIGEgZHJhZnQgbWlnaHQgYWxzbyBiZSBtb3Jl IGFwcHJvcHJpYXRlIGluIGFub3RoZXIgV0cNCj4gPiAoZS5nLiwgVEVBUykuIFRoZSBtZXJpdHMg b2YgdXNpbmcgcHJlZml4IGFkdmVydGlzZW1lbnRzIHRvIGJ1aWxkIGEgdG9wb2xvZ3kNCj4gY291 bGQgdGhlbiBiZSBkaXNjdXNzZWQgb24gaXRzIG93bi4NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNl IGRvIG5vdCB0cnkgdG8gYXZvaWQgaGF2aW5nIGEgZnVsbCBkaXNjdXNzaW9uIG9mIHRoZSBtZXJp dHMNCj4gPiA+ID4gb2YgdXNpbmcNCj4gPiBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgdG8gZGVyaXZl IHRvcG9sb2d5IGJ5IGFkZGluZyBpdCB0byBhIGRyYWZ0IHRoYXQNCj4gPiBpcyAoYW5kIHNob3Vs ZCBiZSkgZm9jdXNlZCBvbiBzaW1wbGUgcHJvdG9jb2wgZXh0ZW5zaW9ucy4NCj4gPiA+DQo+ID4g PiBbQXMgV0cgbWVtYmVyXQ0KPiA+ID4NCj4gPiA+IEkgZmluZCB0aGlzIHZlcnkgY29tcGVsbGlu ZyBhbmQgc28gc3VwcG9ydCB0aGUgcmVtb3ZhbCBvZiB0aGUNCj4gPiA+IHJlZmVycmVkIHRvDQo+ ID4gbm9uLW5vcm1hdGl2ZSBhcHBlbmRpY2VzLg0KPiA+ID4NCj4gPiA+IFRoYW5rcywNCj4gPiA+ IENocmlzLg0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gVGhhbnguDQo+ID4gPiA+DQo+ID4gPiA+ ICAgTGVzDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+ID4gPj4gRnJvbTogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5j bj4NCj4gPiA+ID4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDIwIDY6NTEgUE0NCj4g PiA+ID4+IFRvOiAnSmVmZiBUYW50c3VyYScgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsgJ0pv aG4gRSBEcmFrZScNCj4gPiA+ID4+IDxqZHJha2VAanVuaXBlci5uZXQ+DQo+ID4gPiA+PiBDYzog J0NocmlzdGlhbiBIb3BwcycgPGNob3Bwc0BjaG9wcHMub3JnPjsgbHNyLWNoYWlyc0BpZXRmLm9y ZzsNCj4gPiA+ID4+IExlcyBHaW5zYmVyZw0KPiA+ID4gPj4gKGdpbnNiZXJnKSA8Z2luc2JlcmdA Y2lzY28uY29tPjsgbHNyQGlldGYub3JnOyBsc3ItYWRzQGlldGYub3JnOw0KPiA+ID4gPj4gZHJh ZnQtaWV0Zi0gbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmcNCj4gPiA+ID4+IFN1 YmplY3Q6IFJFOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPiA+ID4+IGRyYWZ0LWlldGYtbHNyLW9z cGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gPiA+ID4+DQo+ID4gPiA+PiBIaSwgTGVzLCBKb2hu IGFuZCBKZWZmOg0KPiA+ID4gPj4NCj4gPiA+ID4+IExldCdzIHJlcGx5IHlvdSBhbGwgdG9nZXRo ZXIuDQo+ID4gPiA+PiBJbiBteSBQT1YsIFRoZSBzdGFuZGFyZCBkb2N1bWVudCBzaG91bGQgbm90 IGRlZmluZSBzb2xlbHkgdGhlDQo+ID4gPiA+PiBwcm90b2NvbCBleHRlbnNpb24sIGJ1dCB0aGVp ciB1c2FnZXMgaW4gdGhlIG5ldHdvcmsgZGVwbG95bWVudC4NCj4gPiA+ID4+IEFzIEkga25vd24s IGFsbW9zdCBhbGwgdGhlIElFVEYgZG9jdW1lbnRzIGZvbGxvd2luZyB0aGlzIHN0eWxlLg0KPiA+ ID4gPj4gQW5kLCBiZWZvcmUgYWRvcHRpbmcgb25lIHdvcmssIHdlIGhhdmUgb2Z0ZW4gaW50ZW5z ZSBkaXNjdXNzaW9uDQo+ID4gPiA+PiBmb3Igd2hhdCdzIHRoZWlyIHVzYWdlcy4NCj4gPiA+ID4+ IFN1Y2ggZGlzY3Vzc2lvbiBpbiB0aGUgbWFpbCBsaXN0IGFuZCBzdGF0ZW1lbnRzIGluIHRoZSBk b2N1bWVudA0KPiA+ID4gPj4gY2FuIGNlcnRhaW5seSBhc3Npc3QgdGhlIHJlYWRlci91c2VyIG9m IHRoZSBkb2N1bWVudCBnZXQgdGhlDQo+ID4gPiA+PiBlc3NlbmNlIG9mIHRoZSBzdGFuZGFyZCwg YW5kIGZvbGxvdyB0aGVtIHVuYW1iaWd1b3VzbHkuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gUmVnYXJk aW5nIHRoZSBjb250ZW50cyBvZiBhcHBlbmRpY2VzLCBhcyBzdGF0ZWQgaW4gdGhlIHNlY3Rpb24s DQo+ID4gPiA+PiAiVGhlIEFwcGVuZGl4IEEgaGV1cmlzdGljIHRvIHJlYnVpbGQgdGhlIHRvcG9s b2d5IGNhbiBub3JtYWxseSBiZQ0KPiA+ID4gPj4gdXNlZCBpZiBhbGwgbGlua3MgYXJlIG51bWJl cmVkLiIgSSB0aGluayB0aGlzIGNhbiBhcHBseSBhbG1vc3QNCj4gPiA+ID4+IG1vc3Qgb2YgdGhl IG9wZXJhdG9yJ3MgbmV0d29yaywgYW5kIGZhY2lsaXRhdGUgdGhlIGludGVyLWFyZWEgVEUNCj4g PiA+ID4+IHBhdGggY2FsY3VsYXRpb24gZm9yIGNlbnRyYWwgY29udHJvbGxlciwgb3IgZXZlbiBm b3IgdGhlIGhlYWQtZW5kDQo+ID4gPiA+PiByb3V0ZXIgdGhhdCBsb2NhdGVkIGluIG9uZSBhcmVh IHRoYXQgZGlmZmVyZW50IGZyb20gdGhlIHRhaWwtIGVuZCByb3V0ZXIuDQo+ID4gPiA+Pg0KPiA+ ID4gPj4gS2VlcGluZyB0aGUgY29udGVudHMgb2YgYXBwZW5kaWNlcyBkb2VzIG5vdCBoYXZlIHRo ZSBuZWdhdGl2ZQ0KPiA+ID4gPj4gaW1wYWN0IG9mIHRoZSBwcm90b2NvbCBleHRlbnNpb24sIGl0 IGlzIGp1c3Qgb25lIHJlZmVyZW5jZSBmb3INCj4gPiA+ID4+IHRoZSB1c2FnZSBvZiB0aGlzIGV4 dGVuc2lvbi4NCj4gPiA+ID4+IE9uZSBjYW4gc2VsZWN0IG5vdCByZWZlciB0byBpdCwgaWYgdGhl aXIgbmV0d29ya3MgYXJlIGRlcGxveWVkDQo+ID4gPiA+PiB3aXRoIGxhcmdlIGFtb3VudCBvZiB1 bm51bWJlcmVkIGxpbmtzLiBCdXQgZm9yIG90aGVycywgdGhlIGhldXJpc3RpYw0KPiBhcHBsaWVz Lg0KPiA+ID4gPj4NCj4gPiA+ID4+IEJlc3QgUmVnYXJkcw0KPiA+ID4gPj4NCj4gPiA+ID4+IEFp anVuIFdhbmcNCj4gPiA+ID4+IENoaW5hIFRlbGVjb20NCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ ID4gPj4NCj4gPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+PiBGcm9t OiBsc3ItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnXSBPbg0K PiA+ID4gPj4gQmVoYWxmIE9mIEplZmYgVGFudHN1cmENCj4gPiA+ID4+IFNlbnQ6IEZyaWRheSwg T2N0b2JlciAxNiwgMjAyMCA1OjI4IEFNDQo+ID4gPiA+PiBUbzogSm9obiBFIERyYWtlIDxqZHJh a2U9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4NCj4gPiA+ID4+IENjOiBDaHJpc3RpYW4g SG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPjsgbHNyLWNoYWlyc0BpZXRmLm9yZzsgTGVzDQo+ID4g PiA+PiBHaW5zYmVyZw0KPiA+ID4gPj4gKGdpbnNiZXJnKSA8Z2luc2Jlcmc9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmc+OyBsc3JAaWV0Zi5vcmc7DQo+ID4gPiA+PiBsc3ItIGFkc0BpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZw0KPiA+ID4g Pj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+ID4gPj4gZHJhZnQtaWV0Zi1s c3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+ID4gPj4NCj4gPiA+ID4+ICsxDQo+ID4g PiA+Pg0KPiA+ID4gPj4gUmVnYXJkcywNCj4gPiA+ID4+IEplZmYNCj4gPiA+ID4+DQo+ID4gPiA+ Pj4gT24gT2N0IDE1LCAyMDIwLCBhdCAxMTozMywgSm9obiBFIERyYWtlDQo+ID4gPiA+PiA8amRy YWtlPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ID4gPj4+DQo+ID4g PiA+Pj4g77u/SGksDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBJIGFncmVlIHdpdGggTGVzLiAgVGhp cyBpcyBhIHNpbXBsZSBwcm90b2NvbCBleHRlbnNpb24gZm9yIGENCj4gPiA+ID4+PiBzcGVjaWZp YyBwdXJwb3NlDQo+ID4gPiA+PiBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIHRvIGluY2x1ZGUgc3Bl Y3VsYXRpb24gYWJvdXQgaXRzIHVzZSBmb3INCj4gPiA+ID4+IG90aGVyIHB1cnBvc2VzLCBwYXJ0 aWN1bGFybHkgd2hlbiBpdCBpcyBpbmhlcmVudGx5IG5vdCBzdWl0ZWQgZm9yIHRoZW0uDQo+ID4g PiA+Pj4NCj4gPiA+ID4+PiBZb3VycyBJcnJlc3BlY3RpdmVseSwNCj4gPiA+ID4+Pg0KPiA+ID4g Pj4+IEpvaG4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSnVuaXBlciBCdXNpbmVz cyBVc2UgT25seQ0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gPiA+Pj4+IEZyb206IExzciA8bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBMZXMgR2luc2JlcmcNCj4gPiA+ID4+Pj4gKGdpbnNiZXJnKQ0KPiA+ID4gPj4+PiBTZW50 OiBUaHVyc2RheSwgT2N0b2JlciAxNSwgMjAyMCAxMjozMyBQTQ0KPiA+ID4gPj4+PiBUbzogQ2hy aXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz47IGxzckBpZXRmLm9yZw0KPiA+ID4gPj4+ PiBDYzogbHNyLWNoYWlyc0BpZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9yZzsNCj4gPiA+ID4+Pj4g ZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtIG9yaWdpbmF0b3JAaWV0Zi5vcmcNCj4gPiA+ID4+ Pj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+ID4gPj4+PiBkcmFmdC1pZXRm LWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+IFtF eHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCj4gPiA+ID4+Pj4NCj4gPiA+ ID4+Pj4NCj4gPiA+ID4+Pj4gSSBzdXBwb3J0IG1vdmluZyB0aGlzIGRvY3VtZW50IGZvcndhcmQu DQo+ID4gPiA+Pj4+IFNpbWlsYXIgZnVuY3Rpb25hbGl0eSBpbiBJUy1JUyBoYXMgcHJvdmVkIHVz ZWZ1bC4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gSSB3b3VsZCBob3dldmVyIGxpa2UgdG8gcmVw ZWF0IGNvbW1lbnRzIEkgbWFkZSBlYXJsaWVyIGluIHRoZQ0KPiA+ID4gPj4+PiByZXZpZXcgb2Yg dGhpcyBkb2N1bWVudC4NCj4gPiA+ID4+Pj4gVGhlIGNvbnRlbnQgb2YgdGhlIEFwcGVuZGljZXMg c2hvdWxkIGJlIHJlbW92ZWQuDQo+ID4gPiA+Pj4+IFRoZSBBcHBlbmRpY2VzIGRlZmluZSBhbmQg ZGlzY3VzcyBkZXJpdmluZyB0b3BvbG9neSBpbmZvcm1hdGlvbg0KPiA+ID4gPj4+PiBmcm9tIHBy ZWZpeCBhZHZlcnRpc2VtZW50cyAtIHdoaWNoIGlzIGZsYXdlZCBhbmQgc2hvdWxkIG5vdCBiZQ0K PiBkb25lLg0KPiA+ID4gPj4+PiBQZXJoYXBzIG1vcmUgcmVsZXZhbnQsIHRoZSBwdXJwb3NlIG9m IHRoZSBkb2N1bWVudCBpcyB0byBkZWZpbmUNCj4gPiA+ID4+Pj4gcHJvdG9jb2wgZXh0ZW5zaW9u cyBzdXBwb3J0aW5nIGFkdmVydGlzZW1lbnQgb2YgdGhlIG9yaWdpbmF0b3JzDQo+ID4gPiA+Pj4+ IG9mIGEgcHJlZml4IGFkdmVydGlzZW1lbnQuIFRoZXJlIGlzIG5vIG5lZWQgdG8gZGlzY3VzcyBo b3cgdGhpcw0KPiA+ID4gPj4+PiBtZWNoYW5pc20gbWlnaHQgYmUgdXNlZCB0byBidWlsZCB0b3Bv bG9neSBpbmZvcm1hdGlvbi4NCj4gPiA+ID4+Pj4gVGhpcyBkb2N1bWVudCBzaG91bGQgY29uZmlu ZSBpdHNlbGYgdG8gZGVmaW5pbmcgdGhlIHByb3RvY29sDQo+ID4gPiA+Pj4+IGV4dGVuc2lvbnMg LSBzaW1pbGFyIHRoZSBSRkMgNzc5NC4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gSWYgdGhlIGF1 dGhvcnMgZG8gbm90IGFncmVlIHRvIGRvIHRoaXMsIEkgd291bGQgZW5jb3VyYWdlIHRoaXMNCj4g PiA+ID4+Pj4gcG9pbnQgdG8gYmUgZGlzY3Vzc2VkIGR1cmluZyBJRVNHIHJldmlldy4NCj4gPiA+ ID4+Pj4NCj4gPiA+ID4+Pj4gIExlcw0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+Pj4+IEZyb206IExzciA8bHNyLWJvdW5jZXNAaWV0 Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gSG9wcHMNCj4gPiA+ID4+Pj4+IFNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAxNCwgMjAyMCAxMToxNSBQTQ0KPiA+ID4gPj4+Pj4gVG86IGxzckBp ZXRmLm9yZw0KPiA+ID4gPj4+Pj4gQ2M6IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdp bmF0b3JAaWV0Zi5vcmc7DQo+ID4gPiA+Pj4+PiBsc3ItY2hhaXJzQGlldGYub3JnOyBsc3ItIGFk c0BpZXRmLm9yZzsgQ2hyaXN0aWFuIEhvcHBzDQo+ID4gPiA+Pj4+PiA8Y2hvcHBzQGNob3Bwcy5v cmc+DQo+ID4gPiA+Pj4+PiBTdWJqZWN0OiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPiA+ID4+Pj4+ IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gPiA+ID4+Pj4+DQo+ ID4gPiA+Pj4+PiBUaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBMYXN0IENhbGwsIGVuZGluZyBhZnRl ciBPY3QgMjl0aCwgMjAyMCwgZm9yOg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+ Pj4+PiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZA0KPiA+ID4gPj4+Pj4gcmENCj4gPiA+ID4+Pj4+IGZ0LWkNCj4gPiA+ID4+Pj4+ IGV0DQo+ID4gPiA+Pj4+PiBmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yL19fOyEhTkV0NnlN YU8tDQo+ID4gPiA+PiBnayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxDQo+ID4gPiA+Pj4+PiBoSyA4 cDAzRmczTDlMdUNHWHc4QzBYNnFSUWRySGpLREtIY2prakNscGskDQo+ID4gPiA+Pj4+Pg0KPiA+ ID4gPj4+Pj4gVGhlIGZvbGxvd2luZyBJUFIgaGFzIGJlZW4gZmlsZWQNCj4gPiA+ID4+Pj4+DQo+ ID4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvaXByLzM0NDgvX187IQ0KPiA+ID4gPj4+Pj4gIU5FdDZ5TWFPLQ0KPiA+ID4gPj4+Pg0KPiA+ IGdrIVRhU3pRVGhnaHRDRk91WVBTMlZqTHFoSzhwMDNGZzNMOUx1Q0dYdzhDMFg2cVJRZHJIaktE S0hjeg0KPiA+ID4gPj4+Pj4gNUt0VUhRJA0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IEF1dGhv cnMsDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gUGxlYXNlIGluZGljYXRlIHRvIHRoZSBsaXN0 LCB5b3VyIGtub3dsZWRnZSBvZiBhbnkgb3RoZXIgSVBSDQo+ID4gPiA+Pj4+PiByZWxhdGVkIHRv IHRoaXMgd29yay4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBUaGFua3MsDQo+ID4gPiA+Pj4+ PiBDaHJpcy4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4+Pj4gTHNyIG1haWxpbmcgbGlzdA0KPiA+ ID4gPj4+PiBMc3JAaWV0Zi5vcmcNCj4gPiA+ID4+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluDQo+ID4gPiA+Pj4+IGZvDQo+ ID4gPiA+Pj4+IC9sc3INCj4gPiA+ID4+Pj4gX187ISFORXQNCj4gPiA+ID4+Pj4gNnlNYU8tDQo+ ID4gPiA+Pj4+DQo+ID4gPiA+Pg0KPiA+DQo+IGdrIVRhU3pRVGhnaHRDRk91WVBTMlZqTHFoSzhw MDNGZzNMOUx1Q0dYdzhDMFg2cVJRZHJIaktES0hjVWRtDQo+ID4gPiA+PiB3OA0KPiA+ID4gPj4+ PiBMYyQNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPiA+Pj4gTHNyIG1haWxpbmcgbGlzdA0KPiA+ID4gPj4+ IExzckBpZXRmLm9yZw0KPiA+ID4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbHNyDQo+ID4gPiA+Pg0KPiA+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4+IExzciBtYWlsaW5nIGxpc3QNCj4gPiA+ID4+ IExzckBpZXRmLm9yZw0KPiA+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9sc3INCj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiA+ID4gTHNyIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBMc3JA aWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s c3INCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBMc3IgbWFpbGluZyBsaXN0DQo+ID4g THNyQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s c3INCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g THNyIG1haWxpbmcgbGlzdA0KPiBMc3JAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sc3INCg0K From nobody Mon Oct 19 02:13:45 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55823A0475; Mon, 19 Oct 2020 02:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.948 X-Spam-Level: X-Spam-Status: No, score=-7.948 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uGwXwyR0FAI; Mon, 19 Oct 2020 02:13:40 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31523A044E; Mon, 19 Oct 2020 02:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19062; q=dns/txt; s=iport; t=1603098820; x=1604308420; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=GvOCzVCbIVRSAh/LGQaBh6zli9olo434z1piDs1N0Xo=; b=RiI6uILjG95x8X22ElRFg0NlM4TZU6eYkv/ab6c9oWDGpQbE3oJTRWMF Ui452EyoeeMQTTxOE+IiqJHTWduNKEUynR8BIyMKKwDTFGkefF4PwW6HD dpcKUyTlkfg/JPJsiAsy/V6ECgL3Pliz8UiUWdkNy2sV1+JVSa2G5mbo2 U=; X-IronPort-AV: E=Sophos;i="5.77,394,1596499200"; d="scan'208";a="30399661" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Oct 2020 09:13:38 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 09J9Dbxg030571; Mon, 19 Oct 2020 09:13:37 GMT To: "Les Ginsberg (ginsberg)" , Aijun Wang , "'Christian Hopps'" Cc: "'John E Drake'" , "lsr-chairs@ietf.org" , "lsr@ietf.org" , "'Jeff Tantsura'" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" References: <303E621F-47AA-4309-AC85-32A597604C7C@chopps.org> <00b401d6a5bc$ac44e800$04ceb800$@tsinghua.org.cn> <00ea01d6a5e6$54f371f0$feda55d0$@tsinghua.org.cn> From: Peter Psenak Message-ID: Date: Mon, 19 Oct 2020 11:13:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 09:13:45 -0000 Aijun, On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote: > Aijun - > > I am not going to continue these side discussions with you. > > The primary purpose of the protocol extensions are as stated in the draft Introduction. This is analogous to the use cases for the equivalent extensions for IS-IS already approved in RFC 7794. We need the equivalent in OSPF. > > You can show that you are listening to the concerns of WG members by removing the Appendices - in which case you have (I believe) broad support for moving the draft forward. I agree with Les. As a co-author, I have asked you several times to get rid of the use case described in appendix. Trying to use prefix advertisement to derive topological data is simply broken. The reason we are adding the prefix originator extension to OSPF is NOT the broken use case in the appendix of the draft. thanks, Peter > You can then write a separate draft to discuss other use cases and allow the WG to discuss those other use cases w/o preventing the extensions from being approved and deployed for the use cases which have already been demonstrated as useful by IS-IS. > > If you remove the Appendices I can support the draft. > If you do not remove the Appendices I cannot support the draft. > > Please discuss this with your co-authors and come to consensus on your next step. > > Les > > >> -----Original Message----- >> From: Aijun Wang >> Sent: Monday, October 19, 2020 12:06 AM >> To: Les Ginsberg (ginsberg) ; 'Christian Hopps' >> >> Cc: 'John E Drake' ; lsr-chairs@ietf.org; lsr@ietf.org; >> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix- >> originator@ietf.org; lsr-ads@ietf.org >> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >> >> Hi, Les: >> >> As I stated clearly before, the appendix described in the draft is not the new >> use case. It is the start point of this draft. >> Have you noticed that the introduction part is not the final usage of such >> protocol extension information? >> Certainly, we will not expand all the possible use cases in very detail, but >> putting some of them(some interesting, prominent use cases) in the >> appendix will not hamper the protocol extension itself. >> >> If the statements/descriptions in the appendix are not correct, we can fix it, >> or remove it finally. If not, why not let it be for reference to the user of such >> protocol extension? >> For the body part of this draft, we are also welcome comments. >> >> More replies inline below[WAJ] >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> -----Original Message----- >> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Les >> Ginsberg (ginsberg) >> Sent: Monday, October 19, 2020 2:15 PM >> To: Aijun Wang ; 'Christian Hopps' >> >> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les Ginsberg >> (ginsberg)' ; lsr@ietf.org; 'Jeff >> Tantsura' ; draft-ietf-lsr-ospf-prefix- >> originator@ietf.org; lsr-ads@ietf.org >> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >> >> Aijun - >> >> The "use case" for the protocol extensions is clearly stated in the >> Introduction: >> >> "The primary use case for the extensions proposed in this document is >> to be able to identify the originator of the prefix in the network. >> In cases where multiple prefixes are advertised by a given router, it >> is also useful to be able to associate all these prefixes with a >> single router even when prefixes are advertised outside of the area >> in which they originated. It also helps to determine when the same >> prefix is being originated by multiple routers across areas." >> >> This is equivalent to language in RFC 7794 which defines the analogous >> extensions for IS-IS. >> >> Everything you have in the Appendix is not related to the primary use case - >> and is fact a use case which many of us have objected to. >> [WAJ] Very glad to know the false statements in the appendix. >> >> You are entitled to write another draft advocating for your new use case if >> you wish, but requiring that the protocol extensions in support of the >> primary use case not go forward without your new use case is - as Chris has >> stated very clearly - holding approval of the protocol extensions hostage to >> your new use case. >> [WAJ] It is not new use case. As I sated before, I am open to this part, but >> should on the conditions that the statements in this part are incorrect. >> >> I am asking you (yet again) not to do this. >> >> I cannot support the document moving forward with the content in the >> Appendices included. >> [WAJ] Would like to hear more technical analysis. >> >> Les >> >> >>> -----Original Message----- >>> From: Lsr On Behalf Of Aijun Wang >>> Sent: Sunday, October 18, 2020 7:08 PM >>> To: 'Christian Hopps' >>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >>> Ginsberg (ginsberg)' ; >>> lsr@ietf.org; 'Jeff Tantsura' ; >>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>> Subject: Re: [Lsr] WG Last Call >>> draft-ietf-lsr-ospf-prefix-originator-06 >>> >>> Hi, Chris: >>> >>> I think we have "put the cart before the horse". For protocol >>> extension draft, the origin is the use case. >>> And I think we will not expand OSPF protocol, just because it lack >>> something as compared with ISIS, right? >>> >>> As I stated before, the use case in current appendix is the main >>> motivation of this draft, you can see this in main body of the earlier >>> version of this draft(from version 0 to version 5). >>> The reason that we move this part to the appendix, as that you said, >>> is to let person focus on the protocol extension itself. >>> >>> Moving this part to appendix is acceptable, but removing it from the >>> draft will erase the origin of this document. >>> Is it reasonable that one document discusses the "origin"(of the >>> prefix), can't keep its origin? >>> >>> More replies inline below[WAJ]. >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> >>> -----Original Message----- >>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of >>> Christian Hopps >>> Sent: Friday, October 16, 2020 10:47 PM >>> To: 王爱俊 >>> Cc: John E Drake ; Christian Hopps >>> ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) >>> ; lsr@ietf.org; Jeff Tantsura >>> ; >>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org >>> Subject: Re: [Lsr] WG Last Call >>> draft-ietf-lsr-ospf-prefix-originator-06 >>> >>> Isn't this just adding an analogous extension that already exists in RFC7794? >>> [WAJ] No. RFC7794 is just one example that to illustrate, as the >>> companion IGP protocol, OSPF can also accomplish this. And, actually, >>> there are differences consideration in this draft for the protocol extension. >>> >>> I don't think we need to do a lot of convincing at this point. I agree >>> with Les, if you want to talk about use cases (especially ones that >>> are controversial!) then the correct place for that is in a new informative >> draft. >>> [WAJ] we have discussed the use case before and state the discussion >>> results at the appendix part. We will not emphasis and expand the use >>> case more. If one does not agree the statement of this appendix, we >>> can discuss online or offline. We just need to make the statement in >> appendix is correct. >>> >>> Otherwise, especially if the cases are controversial, this can be seen >>> as doing an "end-run" to avoid the debate b/c people want the >>> extension, but maybe don't agree with your use case. >>> [WAJ] One should point out which statement in the appendix is >>> controversial, we can correct it. This use case is the origin of this >>> draft, not the results. >>> >>> Legislators do this sometimes adding things they want personally to >>> popular bills, that other people may not want, but since people want >>> the main bill they vote for it anyway, in the US it's called "adding >>> pork" or "pork barrel politics". :) [WAJ] The appendix is not added >>> later, but exist at the first beginning. This is the origin of the >>> bills. >>> >>> Thanks, >>> Chris. >>> >>>> On Oct 16, 2020, at 10:37 AM, 王爱俊 >>> wrote: >>>> >>>> >>>> Hi, Chris: >>>> Originally, the appendix part is within the document, which is the >>>> start >>> point/main motivation to extend the prefix origin. >>>> There may exists other usages of this information. Pack these >>>> examples >>> into some short sentences or introduction is viable, but expand some >>> of them is also helpful. >>>> As I known, when we want to do protocol extension, we should always >>> convince other the reason/motivation/prospects to do so. On the other >>> hand, the use case described in the current appendix is very prominent >>> for operator to accomplish the TE task in multi-area environment. >>>> >>>> Aijun Wang >>>> >>>> 在2020-10-16，Christian Hopps <chopps@chopps.org>写道: >>>> -----原始邮件----- >>>> 发件人： Christian Hopps <chopps@chopps.org> >>>> 发件时间: 2020年10月16日 星期五 >>>> 写道: ["Les Ginsberg (ginsberg)" >>>> <ginsberg=40cisco.com@dmarc.ietf.org>] >>>> 主题： Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>>> >>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) >>> wrote: >>>>> >>>>> Aijun - >>>>> >>>>> The point I am making is very focused. >>>>> >>>>> This draft is defining a protocol extension. As such it is >>>>> necessary that this >>> be Standards track as adhering to the normative statements in the >>> draft are necessary for interoperability. >>>>> >>>>> What is discussed in the Appendix is a use case. It is not >>>>> normative and >>> there are strong opinions on both sides as to whether this is an >>> appropriate use case or not. >>>>> In the context of this draft, I have no interest in trying to >>>>> resolve our >>> difference of opinion on this use case. I simply want the protocol >>> extension to move forward so that we have another tool available. >>>>> >>>>> If you want to write a draft on the use case discussed in the >>>>> Appendix >>> please feel free to do so. That draft may very well not be normative - >>> Informational or BCP may be more appropriate - because it will be >>> discussing a deployment scenario and a proposal to use defined >>> protocol extensions as one way to solve problems in that deployment >>> scenario. Such a draft might also be more appropriate in another WG >>> (e.g., TEAS). The merits of using prefix advertisements to build a topology >> could then be discussed on its own. >>>>> >>>>> Please do not try to avoid having a full discussion of the merits >>>>> of using >>> prefix advertisements to derive topology by adding it to a draft that >>> is (and should be) focused on simple protocol extensions. >>>> >>>> [As WG member] >>>> >>>> I find this very compelling and so support the removal of the >>>> referred to >>> non-normative appendices. >>>> >>>> Thanks, >>>> Chris. >>>> >>>>> >>>>> Thanx. >>>>> >>>>> Les >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Aijun Wang >>>>>> Sent: Thursday, October 15, 2020 6:51 PM >>>>>> To: 'Jeff Tantsura' ; 'John E Drake' >>>>>> >>>>>> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; >>>>>> Les Ginsberg >>>>>> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; >>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org >>>>>> Subject: RE: [Lsr] WG Last Call >>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>> >>>>>> Hi, Les, John and Jeff: >>>>>> >>>>>> Let's reply you all together. >>>>>> In my POV, The standard document should not define solely the >>>>>> protocol extension, but their usages in the network deployment. >>>>>> As I known, almost all the IETF documents following this style. >>>>>> And, before adopting one work, we have often intense discussion >>>>>> for what's their usages. >>>>>> Such discussion in the mail list and statements in the document >>>>>> can certainly assist the reader/user of the document get the >>>>>> essence of the standard, and follow them unambiguously. >>>>>> >>>>>> Regarding the contents of appendices, as stated in the section, >>>>>> "The Appendix A heuristic to rebuild the topology can normally be >>>>>> used if all links are numbered." I think this can apply almost >>>>>> most of the operator's network, and facilitate the inter-area TE >>>>>> path calculation for central controller, or even for the head-end >>>>>> router that located in one area that different from the tail- end router. >>>>>> >>>>>> Keeping the contents of appendices does not have the negative >>>>>> impact of the protocol extension, it is just one reference for >>>>>> the usage of this extension. >>>>>> One can select not refer to it, if their networks are deployed >>>>>> with large amount of unnumbered links. But for others, the heuristic >> applies. >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Aijun Wang >>>>>> China Telecom >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >>>>>> Behalf Of Jeff Tantsura >>>>>> Sent: Friday, October 16, 2020 5:28 AM >>>>>> To: John E Drake >>>>>> Cc: Christian Hopps ; lsr-chairs@ietf.org; Les >>>>>> Ginsberg >>>>>> (ginsberg) ; lsr@ietf.org; >>>>>> lsr- ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org >>>>>> Subject: Re: [Lsr] WG Last Call >>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>> >>>>>> +1 >>>>>> >>>>>> Regards, >>>>>> Jeff >>>>>> >>>>>>> On Oct 15, 2020, at 11:33, John E Drake >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I agree with Les. This is a simple protocol extension for a >>>>>>> specific purpose >>>>>> and there is no reason to include speculation about its use for >>>>>> other purposes, particularly when it is inherently not suited for them. >>>>>>> >>>>>>> Yours Irrespectively, >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> Juniper Business Use Only >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Lsr On Behalf Of Les Ginsberg >>>>>>>> (ginsberg) >>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM >>>>>>>> To: Christian Hopps ; lsr@ietf.org >>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; >>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org >>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>> >>>>>>>> [External Email. Be cautious of content] >>>>>>>> >>>>>>>> >>>>>>>> I support moving this document forward. >>>>>>>> Similar functionality in IS-IS has proved useful. >>>>>>>> >>>>>>>> I would however like to repeat comments I made earlier in the >>>>>>>> review of this document. >>>>>>>> The content of the Appendices should be removed. >>>>>>>> The Appendices define and discuss deriving topology information >>>>>>>> from prefix advertisements - which is flawed and should not be >> done. >>>>>>>> Perhaps more relevant, the purpose of the document is to define >>>>>>>> protocol extensions supporting advertisement of the originators >>>>>>>> of a prefix advertisement. There is no need to discuss how this >>>>>>>> mechanism might be used to build topology information. >>>>>>>> This document should confine itself to defining the protocol >>>>>>>> extensions - similar the RFC 7794. >>>>>>>> >>>>>>>> If the authors do not agree to do this, I would encourage this >>>>>>>> point to be discussed during IESG review. >>>>>>>> >>>>>>>> Les >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lsr On Behalf Of Christian Hopps >>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM >>>>>>>>> To: lsr@ietf.org >>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >>>>>>>>> >>>>>>>>> Subject: [Lsr] WG Last Call >>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>> >>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/d >>>>>>>>> ra >>>>>>>>> ft-i >>>>>>>>> et >>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- >>>>>> gk!TaSzQThghtCFOuYPS2VjLq >>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>>>>>>> >>>>>>>>> The following IPR has been filed >>>>>>>>> >>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! >>>>>>>>> !NEt6yMaO- >>>>>>>> >>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>>>>>>>> 5KtUHQ$ >>>>>>>>> >>>>>>>>> Authors, >>>>>>>>> >>>>>>>>> Please indicate to the list, your knowledge of any other IPR >>>>>>>>> related to this work. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Chris. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Lsr mailing list >>>>>>>> Lsr@ietf.org >>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin >>>>>>>> fo >>>>>>>> /lsr >>>>>>>> __;!!NEt >>>>>>>> 6yMaO- >>>>>>>> >>>>>> >>> >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >>>>>> w8 >>>>>>>> Lc$ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Lsr mailing list >>>>>>> Lsr@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>> >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>> >>>>> _______________________________________________ >>>>> Lsr mailing list >>>>> Lsr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lsr >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > > From nobody Mon Oct 19 02:45:51 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7414C3A0989; Mon, 19 Oct 2020 02:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.948 X-Spam-Level: X-Spam-Status: No, score=-7.948 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfuVethwaTLj; Mon, 19 Oct 2020 02:45:49 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5AB3A097B; Mon, 19 Oct 2020 02:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3614; q=dns/txt; s=iport; t=1603100748; x=1604310348; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LDzqk2u8vmRj1TmHCANiK61V+nfb6cqhr7iVgLu3ddU=; b=WoD0qXD0eg5XdB9UgrJIsvk9hDpMT72j/Ji4gJMomjKc7FVArPr9fbcM QF498Xgc3qW59uOGmtu0E+n3akuqDPDa98gg0Os0ahuvR86KC7BbGTgwF sGzjhU4MO01RxwIi6XvxLh5qb/aqcWiTnY+yYlDK0YzPcpM2k1wYH2c6d A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAwBmX41f/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+DGlUBIBIshD2JBYdkLoECmyMLAQEBDyMMBAEBhEoCgg4?= =?us-ascii?q?mOBMCAwEBCwEBBQEBAQIBBgRthWEMhXIBAQEDASMPAQVBEAkCFAQCAiYCAlc?= =?us-ascii?q?GAQwIAQGDIgGCXCAPkkmbDHaBMoVXg0CBPAaBDiqFUhI6hzOBQT+BESeCNAc?= =?us-ascii?q?uPoJcAoR2gl8EpmGRGYJ0gxaFbpFhBQcDH4MWigmFHimOapMxinORDIRWgWs?= =?us-ascii?q?jgVczGggbFYMlTxkNlySFRD8DMjYCBgEJAQEDCY5IAQE?= X-IronPort-AV: E=Sophos;i="5.77,394,1596499200"; d="scan'208";a="30459987" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Oct 2020 09:45:44 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 09J9jhtm020221; Mon, 19 Oct 2020 09:45:43 GMT To: Eric Gray , "rtg-ads@ietf.org" , "lsr-chairs@ietf.org" Cc: "rtg-dir@ietf.org" , "lsr@ietf.org" References: From: Peter Psenak Message-ID: Date: Mon, 19 Oct 2020 11:45:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Lsr] Rtg-Dir Last Call review of draft-ietf-lsr-flex-algo X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 09:45:51 -0000 Hi Eric, thanks for the review, please see inline: On 16/10/2020 20:48, Eric Gray wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see > https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir. > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-lsr-flex-algo-12.txt > > Reviewer: Eric Gray > > Review Date: 16 October, 2020 > > IETF LC End Date: Unknown > > Intended Status: Standards Track > > Summary: > > This document is well organized, relatively easy to read, and probably > ready for publication, but has one potential minor issue and a very > small number of NITs that might be considered prior to publication. > > Major Issues: > > None > > Minor Issues: > > The statement in section 15 (Backward Compatibility) - "This extension > brings no new backward compatibility issues" - seems somewhat flip. > > I suspect that a tiny bit of analysis would not hurt. > > The extensions in this draft are clearly intended to work in an > environment where routers that _do_not_ support these extensions are > also deployed, but apparently relies on configuration of those routers > that _do_ support the extensions to address this. > > That seems correct. > > From my reading of the draft (which I have not closely followed for its > entire development), while it introduces at least one new TLV, the OSPF > routing protocol has well defined handling for TLVs that are not > understood - hence the introduction of one or more new TLVs should not > present a problem in OSPF. > > Obviously Sub-TLVs of the new OSPF TLV type will not introduce > compatibility issues. > > I assume (but do not actually know) that a similar situation exists for > the new ISIS FAD Sub-TLV of the existing TLV Type 242 - i.e. - ISIS > presumably has well defined handling for sub-TLVs (of at least type 242) > that are not recognized.  If so, than the new Sub-TLV types defined are > also not an issue. > > Shouldn't this section say something along these lines?  I suspect that > it would be more helpful if verifying the content of the > "considerations" sections were not left as an exercise for the reader. 😊 What about the "Backward Compatibility" section to be updated to: "This extension brings no new backward compatibility issues. ISIS, OSPFv2 and OSPFv3 all have well defined handling of unrecognized TLVs and sub-TLVs, that allows the introduction of the new extensions, similar to those defined here, without introducing any interoperability problems." > > NITs: > > In the Introduction, the phrase "must often be replaced" seems very > slightly problematic (especially given this is a standards track RFC > wanna-be).  Would it be better to say "is often replaced" instead? done. > > In section 17.1.2 and 17.2 - '... a "Interior Gateway ...' should > probably be '... an "Interior Gateway ..." in both cases. done. thanks, Peter > > -- > > Eric > From nobody Mon Oct 19 03:11:25 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A873A0A25; Mon, 19 Oct 2020 03:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[MIME_QP_LONG_LINE=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 fPlHjSEVJdgV; Mon, 19 Oct 2020 03:11:18 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id EC5BF3A0A13; Mon, 19 Oct 2020 03:11:16 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.92:11291.878567291 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-106.121.66.233?logid-7eb5f1d9cb8f4df9bc74cae9dbfdea4b (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 7988828008E; Mon, 19 Oct 2020 18:10:40 +0800 (CST) X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn Received: from ([172.18.0.92]) by App0021 with ESMTP id 7eb5f1d9cb8f4df9bc74cae9dbfdea4b for wangaijun@tsinghua.org.cn; Mon Oct 19 18:11:13 2020 X-Transaction-ID: 7eb5f1d9cb8f4df9bc74cae9dbfdea4b X-filter-score: filter<0> X-Real-From: wangaj3@chinatelecom.cn X-Receive-IP: 172.18.0.92 X-MEDUSA-Status: 0 Sender: wangaj3@chinatelecom.cn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Aijun Wang Mime-Version: 1.0 (1.0) Date: Mon, 19 Oct 2020 18:10:38 +0800 Message-Id: References: Cc: "Les Ginsberg (ginsberg)" , Aijun Wang , Christian Hopps , John E Drake , lsr-chairs@ietf.org, lsr@ietf.org, Jeff Tantsura , draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-ads@ietf.org In-Reply-To: To: Peter Psenak X-Mailer: iPhone Mail (18A373) Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 10:11:23 -0000 Hi. Peter, Les: We have defined many extensions for protocol, but only a small part of them a= re deployed. Have you ever considered the reason? Adding more contents for their potential usages can certainly be helpful fo= r their influences, or else, they will just stay at the IETF repository. More replies inline below. Aijun Wang China Telecom > On Oct 19, 2020, at 17:14, Peter Psenak wrote: >=20 > =EF=BB=BFAijun, >=20 >> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote: >> Aijun - >> I am not going to continue these side discussions with you. >> The primary purpose of the protocol extensions are as stated in the draft= Introduction. This is analogous to the use cases for the equivalent extensi= ons for IS-IS already approved in RFC 7794. We need the equivalent in OSPF. >> You can show that you are listening to the concerns of WG members by remo= ving the Appendices - in which case you have (I believe) broad support for m= oving the draft forward. >=20 > I agree with Les. >=20 > As a co-author, I have asked you several times to get rid of the use case d= escribed in appendix. [WAJ] Moving the expansion of this use case from body part of this draft to i= ts appendix is our initial consensus, not remove it totally. We have discuss= ed intensely for its application in vary situations. The discussion results a= re stated clearly in the appendix. Wish to hear more technical analysis/comments for the current statements of t= his part from other experts, or from you if you have fresh consideration. > Trying to use prefix advertisement to derive topological data is simply br= oken. The reason we are adding the prefix originator extension to OSPF is NO= T the broken use case in the appendix of the draft. >=20 > thanks, > Peter >=20 >=20 >=20 >> You can then write a separate draft to discuss other use cases and allow t= he WG to discuss those other use cases w/o preventing the extensions from be= ing approved and deployed for the use cases which have already been demonstr= ated as useful by IS-IS. >> If you remove the Appendices I can support the draft. >> If you do not remove the Appendices I cannot support the draft. >> Please discuss this with your co-authors and come to consensus on your ne= xt step. >> Les >>> -----Original Message----- >>> From: Aijun Wang >>> Sent: Monday, October 19, 2020 12:06 AM >>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps' >>> >>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; lsr@ietf.o= rg; >>> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix- >>> originator@ietf.org; lsr-ads@ietf.org >>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06= >>>=20 >>> Hi, Les: >>>=20 >>> As I stated clearly before, the appendix described in the draft is not t= he new >>> use case. It is the start point of this draft. >>> Have you noticed that the introduction part is not the final usage of su= ch >>> protocol extension information? >>> Certainly, we will not expand all the possible use cases in very detail,= but >>> putting some of them(some interesting, prominent use cases) in the >>> appendix will not hamper the protocol extension itself. >>>=20 >>> If the statements/descriptions in the appendix are not correct, we can f= ix it, >>> or remove it finally. If not, why not let it be for reference to the us= er of such >>> protocol extension? >>> For the body part of this draft, we are also welcome comments. >>>=20 >>> More replies inline below[WAJ] >>>=20 >>> Best Regards >>>=20 >>> Aijun Wang >>> China Telecom >>>=20 >>> -----Original Message----- >>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Le= s >>> Ginsberg (ginsberg) >>> Sent: Monday, October 19, 2020 2:15 PM >>> To: Aijun Wang ; 'Christian Hopps' >>> >>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les Ginsb= erg >>> (ginsberg)' ; lsr@ietf.org; 'Jeff= >>> Tantsura' ; draft-ietf-lsr-ospf-prefix- >>> originator@ietf.org; lsr-ads@ietf.org >>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06= >>>=20 >>> Aijun - >>>=20 >>> The "use case" for the protocol extensions is clearly stated in the >>> Introduction: >>>=20 >>> "The primary use case for the extensions proposed in this document is >>> to be able to identify the originator of the prefix in the network. >>> In cases where multiple prefixes are advertised by a given router, it= >>> is also useful to be able to associate all these prefixes with a >>> single router even when prefixes are advertised outside of the area >>> in which they originated. It also helps to determine when the same >>> prefix is being originated by multiple routers across areas." >>>=20 >>> This is equivalent to language in RFC 7794 which defines the analogous >>> extensions for IS-IS. >>>=20 >>> Everything you have in the Appendix is not related to the primary use ca= se - >>> and is fact a use case which many of us have objected to. >>> [WAJ] Very glad to know the false statements in the appendix. >>>=20 >>> You are entitled to write another draft advocating for your new use case= if >>> you wish, but requiring that the protocol extensions in support of the >>> primary use case not go forward without your new use case is - as Chris h= as >>> stated very clearly - holding approval of the protocol extensions hostag= e to >>> your new use case. >>> [WAJ] It is not new use case. As I sated before, I am open to this part,= but >>> should on the conditions that the statements in this part are incorrect.= >>>=20 >>> I am asking you (yet again) not to do this. >>>=20 >>> I cannot support the document moving forward with the content in the >>> Appendices included. >>> [WAJ] Would like to hear more technical analysis. >>>=20 >>> Les >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Lsr On Behalf Of Aijun Wang >>>> Sent: Sunday, October 18, 2020 7:08 PM >>>> To: 'Christian Hopps' >>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >>>> Ginsberg (ginsberg)' ; >>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>> Subject: Re: [Lsr] WG Last Call >>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>=20 >>>> Hi, Chris: >>>>=20 >>>> I think we have "put the cart before the horse". For protocol >>>> extension draft, the origin is the use case. >>>> And I think we will not expand OSPF protocol, just because it lack >>>> something as compared with ISIS, right? >>>>=20 >>>> As I stated before, the use case in current appendix is the main >>>> motivation of this draft, you can see this in main body of the earlier >>>> version of this draft(from version 0 to version 5). >>>> The reason that we move this part to the appendix, as that you said, >>>> is to let person focus on the protocol extension itself. >>>>=20 >>>> Moving this part to appendix is acceptable, but removing it from the >>>> draft will erase the origin of this document. >>>> Is it reasonable that one document discusses the "origin"(of the >>>> prefix), can't keep its origin? >>>>=20 >>>> More replies inline below[WAJ]. >>>>=20 >>>> Best Regards >>>>=20 >>>> Aijun Wang >>>> China Telecom >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of >>>> Christian Hopps >>>> Sent: Friday, October 16, 2020 10:47 PM >>>> To: =E7=8E=8B=E7=88=B1=E4=BF=8A >>>> Cc: John E Drake ; Christian Hopps >>>> ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) >>>> ; lsr@ietf.org; Jeff Tantsura >>>> ; >>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org >>>> Subject: Re: [Lsr] WG Last Call >>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>=20 >>>> Isn't this just adding an analogous extension that already exists in RFC= 7794? >>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the >>>> companion IGP protocol, OSPF can also accomplish this. And, actually, >>>> there are differences consideration in this draft for the protocol exte= nsion. >>>>=20 >>>> I don't think we need to do a lot of convincing at this point. I agree >>>> with Les, if you want to talk about use cases (especially ones that >>>> are controversial!) then the correct place for that is in a new informa= tive >>> draft. >>>> [WAJ] we have discussed the use case before and state the discussion >>>> results at the appendix part. We will not emphasis and expand the use >>>> case more. If one does not agree the statement of this appendix, we >>>> can discuss online or offline. We just need to make the statement in >>> appendix is correct. >>>>=20 >>>> Otherwise, especially if the cases are controversial, this can be seen >>>> as doing an "end-run" to avoid the debate b/c people want the >>>> extension, but maybe don't agree with your use case. >>>> [WAJ] One should point out which statement in the appendix is >>>> controversial, we can correct it. This use case is the origin of this >>>> draft, not the results. >>>>=20 >>>> Legislators do this sometimes adding things they want personally to >>>> popular bills, that other people may not want, but since people want >>>> the main bill they vote for it anyway, in the US it's called "adding >>>> pork" or "pork barrel politics". :) [WAJ] The appendix is not added >>>> later, but exist at the first beginning. This is the origin of the >>>> bills. >>>>=20 >>>> Thanks, >>>> Chris. >>>>=20 >>>>> On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A >>>> wrote: >>>>>=20 >>>>>=20 >>>>> Hi, Chris: >>>>> Originally, the appendix part is within the document, which is the >>>>> start >>>> point/main motivation to extend the prefix origin. >>>>> There may exists other usages of this information. Pack these >>>>> examples >>>> into some short sentences or introduction is viable, but expand some >>>> of them is also helpful. >>>>> As I known, when we want to do protocol extension, we should always >>>> convince other the reason/motivation/prospects to do so. On the other >>>> hand, the use case described in the current appendix is very prominent >>>> for operator to accomplish the TE task in multi-area environment. >>>>>=20 >>>>> Aijun Wang >>>>>=20 >>>>> =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps <chopps@chopps.org>=E5= =86=99=E9=81=93: >>>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps <chopps@chopps= .org> >>>>> =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410=E6=9C=8816=E6=97= =A5 =E6=98=9F=E6=9C=9F=E4=BA=94 >>>>> =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)" >>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org>] >>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call draft-ietf-lsr-ospf= -prefix-originator-06 >>>>>=20 >>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) >>>> wrote: >>>>>>=20 >>>>>> Aijun - >>>>>>=20 >>>>>> The point I am making is very focused. >>>>>>=20 >>>>>> This draft is defining a protocol extension. As such it is >>>>>> necessary that this >>>> be Standards track as adhering to the normative statements in the >>>> draft are necessary for interoperability. >>>>>>=20 >>>>>> What is discussed in the Appendix is a use case. It is not >>>>>> normative and >>>> there are strong opinions on both sides as to whether this is an >>>> appropriate use case or not. >>>>>> In the context of this draft, I have no interest in trying to >>>>>> resolve our >>>> difference of opinion on this use case. I simply want the protocol >>>> extension to move forward so that we have another tool available. >>>>>>=20 >>>>>> If you want to write a draft on the use case discussed in the >>>>>> Appendix >>>> please feel free to do so. That draft may very well not be normative - >>>> Informational or BCP may be more appropriate - because it will be >>>> discussing a deployment scenario and a proposal to use defined >>>> protocol extensions as one way to solve problems in that deployment >>>> scenario. Such a draft might also be more appropriate in another WG >>>> (e.g., TEAS). The merits of using prefix advertisements to build a topo= logy >>> could then be discussed on its own. >>>>>>=20 >>>>>> Please do not try to avoid having a full discussion of the merits >>>>>> of using >>>> prefix advertisements to derive topology by adding it to a draft that >>>> is (and should be) focused on simple protocol extensions. >>>>>=20 >>>>> [As WG member] >>>>>=20 >>>>> I find this very compelling and so support the removal of the >>>>> referred to >>>> non-normative appendices. >>>>>=20 >>>>> Thanks, >>>>> Chris. >>>>>=20 >>>>>>=20 >>>>>> Thanx. >>>>>>=20 >>>>>> Les >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Aijun Wang >>>>>>> Sent: Thursday, October 15, 2020 6:51 PM >>>>>>> To: 'Jeff Tantsura' ; 'John E Drake' >>>>>>> >>>>>>> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; >>>>>>> Les Ginsberg >>>>>>> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; >>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org >>>>>>> Subject: RE: [Lsr] WG Last Call >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>=20 >>>>>>> Hi, Les, John and Jeff: >>>>>>>=20 >>>>>>> Let's reply you all together. >>>>>>> In my POV, The standard document should not define solely the >>>>>>> protocol extension, but their usages in the network deployment. >>>>>>> As I known, almost all the IETF documents following this style. >>>>>>> And, before adopting one work, we have often intense discussion >>>>>>> for what's their usages. >>>>>>> Such discussion in the mail list and statements in the document >>>>>>> can certainly assist the reader/user of the document get the >>>>>>> essence of the standard, and follow them unambiguously. >>>>>>>=20 >>>>>>> Regarding the contents of appendices, as stated in the section, >>>>>>> "The Appendix A heuristic to rebuild the topology can normally be >>>>>>> used if all links are numbered." I think this can apply almost >>>>>>> most of the operator's network, and facilitate the inter-area TE >>>>>>> path calculation for central controller, or even for the head-end >>>>>>> router that located in one area that different from the tail- end ro= uter. >>>>>>>=20 >>>>>>> Keeping the contents of appendices does not have the negative >>>>>>> impact of the protocol extension, it is just one reference for >>>>>>> the usage of this extension. >>>>>>> One can select not refer to it, if their networks are deployed >>>>>>> with large amount of unnumbered links. But for others, the heuristic= >>> applies. >>>>>>>=20 >>>>>>> Best Regards >>>>>>>=20 >>>>>>> Aijun Wang >>>>>>> China Telecom >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >>>>>>> Behalf Of Jeff Tantsura >>>>>>> Sent: Friday, October 16, 2020 5:28 AM >>>>>>> To: John E Drake >>>>>>> Cc: Christian Hopps ; lsr-chairs@ietf.org; Les >>>>>>> Ginsberg >>>>>>> (ginsberg) ; lsr@ietf.org; >>>>>>> lsr- ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org >>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>=20 >>>>>>> +1 >>>>>>>=20 >>>>>>> Regards, >>>>>>> Jeff >>>>>>>=20 >>>>>>>> On Oct 15, 2020, at 11:33, John E Drake >>>>>>> wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> I agree with Les. This is a simple protocol extension for a >>>>>>>> specific purpose >>>>>>> and there is no reason to include speculation about its use for >>>>>>> other purposes, particularly when it is inherently not suited for th= em. >>>>>>>>=20 >>>>>>>> Yours Irrespectively, >>>>>>>>=20 >>>>>>>> John >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Juniper Business Use Only >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lsr On Behalf Of Les Ginsberg >>>>>>>>> (ginsberg) >>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM >>>>>>>>> To: Christian Hopps ; lsr@ietf.org >>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; >>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org >>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>=20 >>>>>>>>> [External Email. Be cautious of content] >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I support moving this document forward. >>>>>>>>> Similar functionality in IS-IS has proved useful. >>>>>>>>>=20 >>>>>>>>> I would however like to repeat comments I made earlier in the >>>>>>>>> review of this document. >>>>>>>>> The content of the Appendices should be removed. >>>>>>>>> The Appendices define and discuss deriving topology information >>>>>>>>> from prefix advertisements - which is flawed and should not be >>> done. >>>>>>>>> Perhaps more relevant, the purpose of the document is to define >>>>>>>>> protocol extensions supporting advertisement of the originators >>>>>>>>> of a prefix advertisement. There is no need to discuss how this >>>>>>>>> mechanism might be used to build topology information. >>>>>>>>> This document should confine itself to defining the protocol >>>>>>>>> extensions - similar the RFC 7794. >>>>>>>>>=20 >>>>>>>>> If the authors do not agree to do this, I would encourage this >>>>>>>>> point to be discussed during IESG review. >>>>>>>>>=20 >>>>>>>>> Les >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lsr On Behalf Of Christian Hopps >>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM >>>>>>>>>> To: lsr@ietf.org >>>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >>>>>>>>>> >>>>>>>>>> Subject: [Lsr] WG Last Call >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>=20 >>>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, f= or: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/d >>>>>>>>>> ra >>>>>>>>>> ft-i >>>>>>>>>> et >>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- >>>>>>> gk!TaSzQThghtCFOuYPS2VjLq >>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>>>>>>>>=20 >>>>>>>>>> The following IPR has been filed >>>>>>>>>>=20 >>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! >>>>>>>>>> !NEt6yMaO- >>>>>>>>>=20 >>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>>>>>>>>> 5KtUHQ$ >>>>>>>>>>=20 >>>>>>>>>> Authors, >>>>>>>>>>=20 >>>>>>>>>> Please indicate to the list, your knowledge of any other IPR >>>>>>>>>> related to this work. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Chris. >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Lsr mailing list >>>>>>>>> Lsr@ietf.org >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin >>>>>>>>> fo >>>>>>>>> /lsr >>>>>>>>> __;!!NEt >>>>>>>>> 6yMaO- >>>>>>>>>=20 >>>>>>>=20 >>>>=20 >>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >>>>>>> w8 >>>>>>>>> Lc$ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Lsr mailing list >>>>>>>> Lsr@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Lsr mailing list >>>>>>> Lsr@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Mon Oct 19 03:31:38 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68793A0AAA; Mon, 19 Oct 2020 03:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.948 X-Spam-Level: X-Spam-Status: No, score=-7.948 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUUJ--0rtPyy; Mon, 19 Oct 2020 03:31:34 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE383A0AA9; Mon, 19 Oct 2020 03:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21509; q=dns/txt; s=iport; t=1603103494; x=1604313094; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=152+0Qji2JMX0EvW5VxtQdTBbmAOlicI6uMzgmRcnbw=; b=FLlKna38+PD6NL8CDcCqTiD/52FVZUF2UoaCu4oJNfWh1LefimFwaZU5 NbFoPryThacG/DmzvB6O/E9fGckcS6L7HVQYX5SAQZfCGDFzafiQScFYU 3EKF0TTmXswbRdAkzMWlBoGu9hx7AoMMsFHsTbzJ5Euj7abUWz9kJMuxy I=; X-IronPort-AV: E=Sophos;i="5.77,394,1596499200"; d="scan'208";a="28026554" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Oct 2020 10:31:32 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 09JAVV6O022447; Mon, 19 Oct 2020 10:31:31 GMT To: Aijun Wang , Peter Psenak Cc: "Les Ginsberg (ginsberg)" , Aijun Wang , Christian Hopps , John E Drake , lsr-chairs@ietf.org, lsr@ietf.org, Jeff Tantsura , draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-ads@ietf.org References: From: Peter Psenak Message-ID: Date: Mon, 19 Oct 2020 12:31:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 10:31:38 -0000 Hi Aijun, please see inline: On 19/10/2020 12:10, Aijun Wang wrote: > Hi. Peter, Les: > > We have defined many extensions for protocol, but only a small part of them are deployed. Have you ever considered the reason? > > Adding more contents for their potential usages can certainly be helpful for their influences, or else, they will just stay at the IETF repository. I disagree. RFCs are not deployment or use case documents. They exists to address the interoperability. > > More replies inline below. > > > > Aijun Wang > China Telecom > >> On Oct 19, 2020, at 17:14, Peter Psenak wrote: >> >> Aijun, >> >>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote: >>> Aijun - >>> I am not going to continue these side discussions with you. >>> The primary purpose of the protocol extensions are as stated in the draft Introduction. This is analogous to the use cases for the equivalent extensions for IS-IS already approved in RFC 7794. We need the equivalent in OSPF. >>> You can show that you are listening to the concerns of WG members by removing the Appendices - in which case you have (I believe) broad support for moving the draft forward. >> >> I agree with Les. >> >> As a co-author, I have asked you several times to get rid of the use case described in appendix. > [WAJ] Moving the expansion of this use case from body part of this draft to its appendix is our initial consensus, not remove it totally. We have discussed intensely for its application in vary situations. The discussion results are stated clearly in the appendix. just because you insisted and did not listen to rest of us. > Wish to hear more technical analysis/comments for the current statements of this part from other experts, or from you if you have fresh consideration. we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan, myself) are telling you that using IP address advertisement to derive topological data is broken and you keep repeating it is valid use case and ask for more reasoning. thanks, Peter > >> Trying to use prefix advertisement to derive topological data is simply broken. The reason we are adding the prefix originator extension to OSPF is NOT the broken use case in the appendix of the draft. >> >> thanks, >> Peter >> >> >> >>> You can then write a separate draft to discuss other use cases and allow the WG to discuss those other use cases w/o preventing the extensions from being approved and deployed for the use cases which have already been demonstrated as useful by IS-IS. >>> If you remove the Appendices I can support the draft. >>> If you do not remove the Appendices I cannot support the draft. >>> Please discuss this with your co-authors and come to consensus on your next step. >>> Les >>>> -----Original Message----- >>>> From: Aijun Wang >>>> Sent: Monday, October 19, 2020 12:06 AM >>>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps' >>>> >>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; lsr@ietf.org; >>>> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix- >>>> originator@ietf.org; lsr-ads@ietf.org >>>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>>> >>>> Hi, Les: >>>> >>>> As I stated clearly before, the appendix described in the draft is not the new >>>> use case. It is the start point of this draft. >>>> Have you noticed that the introduction part is not the final usage of such >>>> protocol extension information? >>>> Certainly, we will not expand all the possible use cases in very detail, but >>>> putting some of them(some interesting, prominent use cases) in the >>>> appendix will not hamper the protocol extension itself. >>>> >>>> If the statements/descriptions in the appendix are not correct, we can fix it, >>>> or remove it finally. If not, why not let it be for reference to the user of such >>>> protocol extension? >>>> For the body part of this draft, we are also welcome comments. >>>> >>>> More replies inline below[WAJ] >>>> >>>> Best Regards >>>> >>>> Aijun Wang >>>> China Telecom >>>> >>>> -----Original Message----- >>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Les >>>> Ginsberg (ginsberg) >>>> Sent: Monday, October 19, 2020 2:15 PM >>>> To: Aijun Wang ; 'Christian Hopps' >>>> >>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les Ginsberg >>>> (ginsberg)' ; lsr@ietf.org; 'Jeff >>>> Tantsura' ; draft-ietf-lsr-ospf-prefix- >>>> originator@ietf.org; lsr-ads@ietf.org >>>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>>> >>>> Aijun - >>>> >>>> The "use case" for the protocol extensions is clearly stated in the >>>> Introduction: >>>> >>>> "The primary use case for the extensions proposed in this document is >>>> to be able to identify the originator of the prefix in the network. >>>> In cases where multiple prefixes are advertised by a given router, it >>>> is also useful to be able to associate all these prefixes with a >>>> single router even when prefixes are advertised outside of the area >>>> in which they originated. It also helps to determine when the same >>>> prefix is being originated by multiple routers across areas." >>>> >>>> This is equivalent to language in RFC 7794 which defines the analogous >>>> extensions for IS-IS. >>>> >>>> Everything you have in the Appendix is not related to the primary use case - >>>> and is fact a use case which many of us have objected to. >>>> [WAJ] Very glad to know the false statements in the appendix. >>>> >>>> You are entitled to write another draft advocating for your new use case if >>>> you wish, but requiring that the protocol extensions in support of the >>>> primary use case not go forward without your new use case is - as Chris has >>>> stated very clearly - holding approval of the protocol extensions hostage to >>>> your new use case. >>>> [WAJ] It is not new use case. As I sated before, I am open to this part, but >>>> should on the conditions that the statements in this part are incorrect. >>>> >>>> I am asking you (yet again) not to do this. >>>> >>>> I cannot support the document moving forward with the content in the >>>> Appendices included. >>>> [WAJ] Would like to hear more technical analysis. >>>> >>>> Les >>>> >>>> >>>>> -----Original Message----- >>>>> From: Lsr On Behalf Of Aijun Wang >>>>> Sent: Sunday, October 18, 2020 7:08 PM >>>>> To: 'Christian Hopps' >>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >>>>> Ginsberg (ginsberg)' ; >>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>> Subject: Re: [Lsr] WG Last Call >>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>> >>>>> Hi, Chris: >>>>> >>>>> I think we have "put the cart before the horse". For protocol >>>>> extension draft, the origin is the use case. >>>>> And I think we will not expand OSPF protocol, just because it lack >>>>> something as compared with ISIS, right? >>>>> >>>>> As I stated before, the use case in current appendix is the main >>>>> motivation of this draft, you can see this in main body of the earlier >>>>> version of this draft(from version 0 to version 5). >>>>> The reason that we move this part to the appendix, as that you said, >>>>> is to let person focus on the protocol extension itself. >>>>> >>>>> Moving this part to appendix is acceptable, but removing it from the >>>>> draft will erase the origin of this document. >>>>> Is it reasonable that one document discusses the "origin"(of the >>>>> prefix), can't keep its origin? >>>>> >>>>> More replies inline below[WAJ]. >>>>> >>>>> Best Regards >>>>> >>>>> Aijun Wang >>>>> China Telecom >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of >>>>> Christian Hopps >>>>> Sent: Friday, October 16, 2020 10:47 PM >>>>> To: 王爱俊 >>>>> Cc: John E Drake ; Christian Hopps >>>>> ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) >>>>> ; lsr@ietf.org; Jeff Tantsura >>>>> ; >>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org >>>>> Subject: Re: [Lsr] WG Last Call >>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>> >>>>> Isn't this just adding an analogous extension that already exists in RFC7794? >>>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the >>>>> companion IGP protocol, OSPF can also accomplish this. And, actually, >>>>> there are differences consideration in this draft for the protocol extension. >>>>> >>>>> I don't think we need to do a lot of convincing at this point. I agree >>>>> with Les, if you want to talk about use cases (especially ones that >>>>> are controversial!) then the correct place for that is in a new informative >>>> draft. >>>>> [WAJ] we have discussed the use case before and state the discussion >>>>> results at the appendix part. We will not emphasis and expand the use >>>>> case more. If one does not agree the statement of this appendix, we >>>>> can discuss online or offline. We just need to make the statement in >>>> appendix is correct. >>>>> >>>>> Otherwise, especially if the cases are controversial, this can be seen >>>>> as doing an "end-run" to avoid the debate b/c people want the >>>>> extension, but maybe don't agree with your use case. >>>>> [WAJ] One should point out which statement in the appendix is >>>>> controversial, we can correct it. This use case is the origin of this >>>>> draft, not the results. >>>>> >>>>> Legislators do this sometimes adding things they want personally to >>>>> popular bills, that other people may not want, but since people want >>>>> the main bill they vote for it anyway, in the US it's called "adding >>>>> pork" or "pork barrel politics". :) [WAJ] The appendix is not added >>>>> later, but exist at the first beginning. This is the origin of the >>>>> bills. >>>>> >>>>> Thanks, >>>>> Chris. >>>>> >>>>>> On Oct 16, 2020, at 10:37 AM, 王爱俊 >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi, Chris: >>>>>> Originally, the appendix part is within the document, which is the >>>>>> start >>>>> point/main motivation to extend the prefix origin. >>>>>> There may exists other usages of this information. Pack these >>>>>> examples >>>>> into some short sentences or introduction is viable, but expand some >>>>> of them is also helpful. >>>>>> As I known, when we want to do protocol extension, we should always >>>>> convince other the reason/motivation/prospects to do so. On the other >>>>> hand, the use case described in the current appendix is very prominent >>>>> for operator to accomplish the TE task in multi-area environment. >>>>>> >>>>>> Aijun Wang >>>>>> >>>>>> 在2020-10-16，Christian Hopps <chopps@chopps.org>写道: >>>>>> -----原始邮件----- >>>>>> 发件人： Christian Hopps <chopps@chopps.org> >>>>>> 发件时间: 2020年10月16日 星期五 >>>>>> 写道: ["Les Ginsberg (ginsberg)" >>>>>> <ginsberg=40cisco.com@dmarc.ietf.org>] >>>>>> 主题： Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>>>>> >>>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) >>>>> wrote: >>>>>>> >>>>>>> Aijun - >>>>>>> >>>>>>> The point I am making is very focused. >>>>>>> >>>>>>> This draft is defining a protocol extension. As such it is >>>>>>> necessary that this >>>>> be Standards track as adhering to the normative statements in the >>>>> draft are necessary for interoperability. >>>>>>> >>>>>>> What is discussed in the Appendix is a use case. It is not >>>>>>> normative and >>>>> there are strong opinions on both sides as to whether this is an >>>>> appropriate use case or not. >>>>>>> In the context of this draft, I have no interest in trying to >>>>>>> resolve our >>>>> difference of opinion on this use case. I simply want the protocol >>>>> extension to move forward so that we have another tool available. >>>>>>> >>>>>>> If you want to write a draft on the use case discussed in the >>>>>>> Appendix >>>>> please feel free to do so. That draft may very well not be normative - >>>>> Informational or BCP may be more appropriate - because it will be >>>>> discussing a deployment scenario and a proposal to use defined >>>>> protocol extensions as one way to solve problems in that deployment >>>>> scenario. Such a draft might also be more appropriate in another WG >>>>> (e.g., TEAS). The merits of using prefix advertisements to build a topology >>>> could then be discussed on its own. >>>>>>> >>>>>>> Please do not try to avoid having a full discussion of the merits >>>>>>> of using >>>>> prefix advertisements to derive topology by adding it to a draft that >>>>> is (and should be) focused on simple protocol extensions. >>>>>> >>>>>> [As WG member] >>>>>> >>>>>> I find this very compelling and so support the removal of the >>>>>> referred to >>>>> non-normative appendices. >>>>>> >>>>>> Thanks, >>>>>> Chris. >>>>>> >>>>>>> >>>>>>> Thanx. >>>>>>> >>>>>>> Les >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Aijun Wang >>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM >>>>>>>> To: 'Jeff Tantsura' ; 'John E Drake' >>>>>>>> >>>>>>>> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; >>>>>>>> Les Ginsberg >>>>>>>> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; >>>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org >>>>>>>> Subject: RE: [Lsr] WG Last Call >>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>> >>>>>>>> Hi, Les, John and Jeff: >>>>>>>> >>>>>>>> Let's reply you all together. >>>>>>>> In my POV, The standard document should not define solely the >>>>>>>> protocol extension, but their usages in the network deployment. >>>>>>>> As I known, almost all the IETF documents following this style. >>>>>>>> And, before adopting one work, we have often intense discussion >>>>>>>> for what's their usages. >>>>>>>> Such discussion in the mail list and statements in the document >>>>>>>> can certainly assist the reader/user of the document get the >>>>>>>> essence of the standard, and follow them unambiguously. >>>>>>>> >>>>>>>> Regarding the contents of appendices, as stated in the section, >>>>>>>> "The Appendix A heuristic to rebuild the topology can normally be >>>>>>>> used if all links are numbered." I think this can apply almost >>>>>>>> most of the operator's network, and facilitate the inter-area TE >>>>>>>> path calculation for central controller, or even for the head-end >>>>>>>> router that located in one area that different from the tail- end router. >>>>>>>> >>>>>>>> Keeping the contents of appendices does not have the negative >>>>>>>> impact of the protocol extension, it is just one reference for >>>>>>>> the usage of this extension. >>>>>>>> One can select not refer to it, if their networks are deployed >>>>>>>> with large amount of unnumbered links. But for others, the heuristic >>>> applies. >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Aijun Wang >>>>>>>> China Telecom >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >>>>>>>> Behalf Of Jeff Tantsura >>>>>>>> Sent: Friday, October 16, 2020 5:28 AM >>>>>>>> To: John E Drake >>>>>>>> Cc: Christian Hopps ; lsr-chairs@ietf.org; Les >>>>>>>> Ginsberg >>>>>>>> (ginsberg) ; lsr@ietf.org; >>>>>>>> lsr- ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org >>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> Regards, >>>>>>>> Jeff >>>>>>>> >>>>>>>>> On Oct 15, 2020, at 11:33, John E Drake >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I agree with Les. This is a simple protocol extension for a >>>>>>>>> specific purpose >>>>>>>> and there is no reason to include speculation about its use for >>>>>>>> other purposes, particularly when it is inherently not suited for them. >>>>>>>>> >>>>>>>>> Yours Irrespectively, >>>>>>>>> >>>>>>>>> John >>>>>>>>> >>>>>>>>> >>>>>>>>> Juniper Business Use Only >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Lsr On Behalf Of Les Ginsberg >>>>>>>>>> (ginsberg) >>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM >>>>>>>>>> To: Christian Hopps ; lsr@ietf.org >>>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; >>>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org >>>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>> >>>>>>>>>> [External Email. Be cautious of content] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I support moving this document forward. >>>>>>>>>> Similar functionality in IS-IS has proved useful. >>>>>>>>>> >>>>>>>>>> I would however like to repeat comments I made earlier in the >>>>>>>>>> review of this document. >>>>>>>>>> The content of the Appendices should be removed. >>>>>>>>>> The Appendices define and discuss deriving topology information >>>>>>>>>> from prefix advertisements - which is flawed and should not be >>>> done. >>>>>>>>>> Perhaps more relevant, the purpose of the document is to define >>>>>>>>>> protocol extensions supporting advertisement of the originators >>>>>>>>>> of a prefix advertisement. There is no need to discuss how this >>>>>>>>>> mechanism might be used to build topology information. >>>>>>>>>> This document should confine itself to defining the protocol >>>>>>>>>> extensions - similar the RFC 7794. >>>>>>>>>> >>>>>>>>>> If the authors do not agree to do this, I would encourage this >>>>>>>>>> point to be discussed during IESG review. >>>>>>>>>> >>>>>>>>>> Les >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Lsr On Behalf Of Christian Hopps >>>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM >>>>>>>>>>> To: lsr@ietf.org >>>>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >>>>>>>>>>> >>>>>>>>>>> Subject: [Lsr] WG Last Call >>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>> >>>>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/d >>>>>>>>>>> ra >>>>>>>>>>> ft-i >>>>>>>>>>> et >>>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- >>>>>>>> gk!TaSzQThghtCFOuYPS2VjLq >>>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>>>>>>>>> >>>>>>>>>>> The following IPR has been filed >>>>>>>>>>> >>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! >>>>>>>>>>> !NEt6yMaO- >>>>>>>>>> >>>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>>>>>>>>>> 5KtUHQ$ >>>>>>>>>>> >>>>>>>>>>> Authors, >>>>>>>>>>> >>>>>>>>>>> Please indicate to the list, your knowledge of any other IPR >>>>>>>>>>> related to this work. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Chris. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Lsr mailing list >>>>>>>>>> Lsr@ietf.org >>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin >>>>>>>>>> fo >>>>>>>>>> /lsr >>>>>>>>>> __;!!NEt >>>>>>>>>> 6yMaO- >>>>>>>>>> >>>>>>>> >>>>> >>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >>>>>>>> w8 >>>>>>>>>> Lc$ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Lsr mailing list >>>>>>>>> Lsr@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Lsr mailing list >>>>>>>> Lsr@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Lsr mailing list >>>>>>> Lsr@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/lsr >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Lsr mailing list >>>>> Lsr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lsr >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > > From nobody Mon Oct 19 03:34:16 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425B53A0AB7 for ; Mon, 19 Oct 2020 03:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=raszuk.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 M70vdQWKXNfy for ; Mon, 19 Oct 2020 03:34:12 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 CF5E23A0AB3 for ; Mon, 19 Oct 2020 03:34:11 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id lw21so13170650ejb.6 for ; Mon, 19 Oct 2020 03:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tFYvhAvVQWM9FEAeBLd7TnyOauDIYtP42IuTud+v364=; b=GHv6e1Wa30OGz0ZDUF57dOnM19o2PnlvilaoGpHTEhtSFVXs8rwj+qgsDNf9v+/Z3J dfV+w5AXaOD8XxehuLE8aXqzUoXsGlXBZXjOETlEvIopcwN0Oc+4g9/Iv0OoclJe3ftA BP0t+RzYOfOa1vcqos4P5FXHpr/djS3gVXklqrdht1T2Ipj/MX1V/pPG9fvG9jphl/fA tAw7UW6Mc8qtSvd0ACjQHr4IjwTxE2LyhxBqDHF+HPGQPZZUByVCHqPQcAiqICIOLA0L kTd16ndLlVS/o60mzJn/ypVw56QNfKgz9JWfWe35HXGCUyKG6i6R3CceMMXgyGS6FMyx qPpA== 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=tFYvhAvVQWM9FEAeBLd7TnyOauDIYtP42IuTud+v364=; b=GI+02v2nDetHy5YutL23dpgdS3Qt5WIGF1IbAv+Hz9Zr7r28cojpInkj4jz+QTFq/X ilxf9v5dxRZAWKYqIBnxwyz3rk6O0dqfe3AxfuberCoCf1LRdZWIrPoIf9E4zeoD/N0Z 0p6hprV9W5PfuHsd7mfVbv0LkP8ofuwS/98NPxdAnds5Pjzj1yiY7N0wQgGYd69vXPp/ JZze4cVtr34sUffPzIXbp87/h7lIWqqO9E/y77W6Ruc/bLzJPjWgi/TiqBuHJeXgjGCz 8JZqCKm+K/E/ME0eP95sYI1Q81Q9zI3MiwB1r6WWNFsoVjnoZBK0H76b1t6gv37/Nm3d i0ZQ== X-Gm-Message-State: AOAM533MzKYxdiR5DWCfaJLnHq9uzxrXWNzrQdibwUJpRSwoSREUgc5F KgdlY/OI3MuIhZPZUyyAHNu+rzMuy0L4DwegRqpBKA== X-Google-Smtp-Source: ABdhPJzwH+ii9Ado1pwGTdlEKaPhR4m3c+0/A7kSfI5QDhd2CC5btbgBL1HnPruUhdTUKSkFo/8/TuxXCKfF3AHKb9g= X-Received: by 2002:a17:906:d964:: with SMTP id rp4mr16447268ejb.110.1603103650102; Mon, 19 Oct 2020 03:34:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Mon, 19 Oct 2020 12:34:04 +0200 Message-ID: To: Aijun Wang Cc: Peter Psenak , "Les Ginsberg (ginsberg)" , John E Drake , Christian Hopps , Aijun Wang , lsr-chairs@ietf.org, lsr , Jeff Tantsura , draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-ads@ietf.org Content-Type: multipart/alternative; boundary="0000000000009a579205b203a7f3" Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 10:34:15 -0000 --0000000000009a579205b203a7f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Aijun, Regarding your appendix A - * How can we "rebuild" topology based on comparison of prefixes and rtr-id ? * If link between S1 & S2 is not in LSDB there may be a valid operational reasons for it. "Rebuilding it" will be actually harmful from all points of view. * You should be exporting topology from all areas not just from backbone and guessing the topology based on the prefix to rtr_id associations * Imaging someone is using multiaccess in areas. Are you also going to rebuild DR & BDR ? I must agree with comments from Peter & Les here. Cheers, R. On Mon, Oct 19, 2020 at 12:11 PM Aijun Wang wrote= : > Hi. Peter, Les: > > We have defined many extensions for protocol, but only a small part of > them are deployed. Have you ever considered the reason? > > Adding more contents for their potential usages can certainly be helpful > for their influences, or else, they will just stay at the IETF repository= . > > More replies inline below. > > > > Aijun Wang > China Telecom > > > On Oct 19, 2020, at 17:14, Peter Psenak 40cisco.com@dmarc.ietf.org> wrote: > > > > =EF=BB=BFAijun, > > > >> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote: > >> Aijun - > >> I am not going to continue these side discussions with you. > >> The primary purpose of the protocol extensions are as stated in the > draft Introduction. This is analogous to the use cases for the equivalent > extensions for IS-IS already approved in RFC 7794. We need the equivalent > in OSPF. > >> You can show that you are listening to the concerns of WG members by > removing the Appendices - in which case you have (I believe) broad suppor= t > for moving the draft forward. > > > > I agree with Les. > > > > As a co-author, I have asked you several times to get rid of the use > case described in appendix. > [WAJ] Moving the expansion of this use case from body part of this draft > to its appendix is our initial consensus, not remove it totally. We have > discussed intensely for its application in vary situations. The discussio= n > results are stated clearly in the appendix. > Wish to hear more technical analysis/comments for the current statements > of this part from other experts, or from you if you have fresh > consideration. > > > Trying to use prefix advertisement to derive topological data is simply > broken. The reason we are adding the prefix originator extension to OSPF = is > NOT the broken use case in the appendix of the draft. > > > > thanks, > > Peter > > > > > > > >> You can then write a separate draft to discuss other use cases and > allow the WG to discuss those other use cases w/o preventing the extensio= ns > from being approved and deployed for the use cases which have already bee= n > demonstrated as useful by IS-IS. > >> If you remove the Appendices I can support the draft. > >> If you do not remove the Appendices I cannot support the draft. > >> Please discuss this with your co-authors and come to consensus on your > next step. > >> Les > >>> -----Original Message----- > >>> From: Aijun Wang > >>> Sent: Monday, October 19, 2020 12:06 AM > >>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps' > >>> > >>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; > lsr@ietf.org; > >>> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix= - > >>> originator@ietf.org; lsr-ads@ietf.org > >>> Subject: RE: [Lsr] WG Last Call > draft-ietf-lsr-ospf-prefix-originator-06 > >>> > >>> Hi, Les: > >>> > >>> As I stated clearly before, the appendix described in the draft is no= t > the new > >>> use case. It is the start point of this draft. > >>> Have you noticed that the introduction part is not the final usage of > such > >>> protocol extension information? > >>> Certainly, we will not expand all the possible use cases in very > detail, but > >>> putting some of them(some interesting, prominent use cases) in the > >>> appendix will not hamper the protocol extension itself. > >>> > >>> If the statements/descriptions in the appendix are not correct, we ca= n > fix it, > >>> or remove it finally. If not, why not let it be for reference to the > user of such > >>> protocol extension? > >>> For the body part of this draft, we are also welcome comments. > >>> > >>> More replies inline below[WAJ] > >>> > >>> Best Regards > >>> > >>> Aijun Wang > >>> China Telecom > >>> > >>> -----Original Message----- > >>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of > Les > >>> Ginsberg (ginsberg) > >>> Sent: Monday, October 19, 2020 2:15 PM > >>> To: Aijun Wang ; 'Christian Hopps' > >>> > >>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les > Ginsberg > >>> (ginsberg)' ; lsr@ietf.org; 'J= eff > >>> Tantsura' ; draft-ietf-lsr-ospf-prefix- > >>> originator@ietf.org; lsr-ads@ietf.org > >>> Subject: Re: [Lsr] WG Last Call > draft-ietf-lsr-ospf-prefix-originator-06 > >>> > >>> Aijun - > >>> > >>> The "use case" for the protocol extensions is clearly stated in the > >>> Introduction: > >>> > >>> "The primary use case for the extensions proposed in this document is > >>> to be able to identify the originator of the prefix in the network= . > >>> In cases where multiple prefixes are advertised by a given router, > it > >>> is also useful to be able to associate all these prefixes with a > >>> single router even when prefixes are advertised outside of the are= a > >>> in which they originated. It also helps to determine when the sam= e > >>> prefix is being originated by multiple routers across areas." > >>> > >>> This is equivalent to language in RFC 7794 which defines the analogou= s > >>> extensions for IS-IS. > >>> > >>> Everything you have in the Appendix is not related to the primary use > case - > >>> and is fact a use case which many of us have objected to. > >>> [WAJ] Very glad to know the false statements in the appendix. > >>> > >>> You are entitled to write another draft advocating for your new use > case if > >>> you wish, but requiring that the protocol extensions in support of th= e > >>> primary use case not go forward without your new use case is - as > Chris has > >>> stated very clearly - holding approval of the protocol extensions > hostage to > >>> your new use case. > >>> [WAJ] It is not new use case. As I sated before, I am open to this > part, but > >>> should on the conditions that the statements in this part are > incorrect. > >>> > >>> I am asking you (yet again) not to do this. > >>> > >>> I cannot support the document moving forward with the content in the > >>> Appendices included. > >>> [WAJ] Would like to hear more technical analysis. > >>> > >>> Les > >>> > >>> > >>>> -----Original Message----- > >>>> From: Lsr On Behalf Of Aijun Wang > >>>> Sent: Sunday, October 18, 2020 7:08 PM > >>>> To: 'Christian Hopps' > >>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les > >>>> Ginsberg (ginsberg)' ; > >>>> lsr@ietf.org; 'Jeff Tantsura' ; > >>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org > >>>> Subject: Re: [Lsr] WG Last Call > >>>> draft-ietf-lsr-ospf-prefix-originator-06 > >>>> > >>>> Hi, Chris: > >>>> > >>>> I think we have "put the cart before the horse". For protocol > >>>> extension draft, the origin is the use case. > >>>> And I think we will not expand OSPF protocol, just because it lack > >>>> something as compared with ISIS, right? > >>>> > >>>> As I stated before, the use case in current appendix is the main > >>>> motivation of this draft, you can see this in main body of the earli= er > >>>> version of this draft(from version 0 to version 5). > >>>> The reason that we move this part to the appendix, as that you said, > >>>> is to let person focus on the protocol extension itself. > >>>> > >>>> Moving this part to appendix is acceptable, but removing it from the > >>>> draft will erase the origin of this document. > >>>> Is it reasonable that one document discusses the "origin"(of the > >>>> prefix), can't keep its origin? > >>>> > >>>> More replies inline below[WAJ]. > >>>> > >>>> Best Regards > >>>> > >>>> Aijun Wang > >>>> China Telecom > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf O= f > >>>> Christian Hopps > >>>> Sent: Friday, October 16, 2020 10:47 PM > >>>> To: =E7=8E=8B=E7=88=B1=E4=BF=8A > >>>> Cc: John E Drake ; Christian Hopps > >>>> ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) > >>>> ; lsr@ietf.org; Jeff Tantsura > >>>> ; > >>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org > >>>> Subject: Re: [Lsr] WG Last Call > >>>> draft-ietf-lsr-ospf-prefix-originator-06 > >>>> > >>>> Isn't this just adding an analogous extension that already exists in > RFC7794? > >>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the > >>>> companion IGP protocol, OSPF can also accomplish this. And, actually= , > >>>> there are differences consideration in this draft for the protocol > extension. > >>>> > >>>> I don't think we need to do a lot of convincing at this point. I agr= ee > >>>> with Les, if you want to talk about use cases (especially ones that > >>>> are controversial!) then the correct place for that is in a new > informative > >>> draft. > >>>> [WAJ] we have discussed the use case before and state the discussion > >>>> results at the appendix part. We will not emphasis and expand the us= e > >>>> case more. If one does not agree the statement of this appendix, we > >>>> can discuss online or offline. We just need to make the statement in > >>> appendix is correct. > >>>> > >>>> Otherwise, especially if the cases are controversial, this can be se= en > >>>> as doing an "end-run" to avoid the debate b/c people want the > >>>> extension, but maybe don't agree with your use case. > >>>> [WAJ] One should point out which statement in the appendix is > >>>> controversial, we can correct it. This use case is the origin of thi= s > >>>> draft, not the results. > >>>> > >>>> Legislators do this sometimes adding things they want personally to > >>>> popular bills, that other people may not want, but since people want > >>>> the main bill they vote for it anyway, in the US it's called "adding > >>>> pork" or "pork barrel politics". :) [WAJ] The appendix is not added > >>>> later, but exist at the first beginning. This is the origin of the > >>>> bills. > >>>> > >>>> Thanks, > >>>> Chris. > >>>> > >>>>> On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A > >>>> wrote: > >>>>> > >>>>> > >>>>> Hi, Chris: > >>>>> Originally, the appendix part is within the document, which is the > >>>>> start > >>>> point/main motivation to extend the prefix origin. > >>>>> There may exists other usages of this information. Pack these > >>>>> examples > >>>> into some short sentences or introduction is viable, but expand some > >>>> of them is also helpful. > >>>>> As I known, when we want to do protocol extension, we should alway= s > >>>> convince other the reason/motivation/prospects to do so. On the othe= r > >>>> hand, the use case described in the current appendix is very promine= nt > >>>> for operator to accomplish the TE task in multi-area environment. > >>>>> > >>>>> Aijun Wang > >>>>> > >>>>> =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps <chopps@chopps.org&g= t;=E5=86=99=E9=81=93: > >>>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps <chopps@cho= pps.org> > >>>>> =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410=E6=9C=8816=E6= =97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94 > >>>>> =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)" > >>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org>] > >>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call draft-ietf-lsr-o= spf-prefix-originator-06 > >>>>> > >>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) > >>>> wrote: > >>>>>> > >>>>>> Aijun - > >>>>>> > >>>>>> The point I am making is very focused. > >>>>>> > >>>>>> This draft is defining a protocol extension. As such it is > >>>>>> necessary that this > >>>> be Standards track as adhering to the normative statements in the > >>>> draft are necessary for interoperability. > >>>>>> > >>>>>> What is discussed in the Appendix is a use case. It is not > >>>>>> normative and > >>>> there are strong opinions on both sides as to whether this is an > >>>> appropriate use case or not. > >>>>>> In the context of this draft, I have no interest in trying to > >>>>>> resolve our > >>>> difference of opinion on this use case. I simply want the protocol > >>>> extension to move forward so that we have another tool available. > >>>>>> > >>>>>> If you want to write a draft on the use case discussed in the > >>>>>> Appendix > >>>> please feel free to do so. That draft may very well not be normative= - > >>>> Informational or BCP may be more appropriate - because it will be > >>>> discussing a deployment scenario and a proposal to use defined > >>>> protocol extensions as one way to solve problems in that deployment > >>>> scenario. Such a draft might also be more appropriate in another WG > >>>> (e.g., TEAS). The merits of using prefix advertisements to build a > topology > >>> could then be discussed on its own. > >>>>>> > >>>>>> Please do not try to avoid having a full discussion of the merits > >>>>>> of using > >>>> prefix advertisements to derive topology by adding it to a draft tha= t > >>>> is (and should be) focused on simple protocol extensions. > >>>>> > >>>>> [As WG member] > >>>>> > >>>>> I find this very compelling and so support the removal of the > >>>>> referred to > >>>> non-normative appendices. > >>>>> > >>>>> Thanks, > >>>>> Chris. > >>>>> > >>>>>> > >>>>>> Thanx. > >>>>>> > >>>>>> Les > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Aijun Wang > >>>>>>> Sent: Thursday, October 15, 2020 6:51 PM > >>>>>>> To: 'Jeff Tantsura' ; 'John E Drake' > >>>>>>> > >>>>>>> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; > >>>>>>> Les Ginsberg > >>>>>>> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; > >>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org > >>>>>>> Subject: RE: [Lsr] WG Last Call > >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 > >>>>>>> > >>>>>>> Hi, Les, John and Jeff: > >>>>>>> > >>>>>>> Let's reply you all together. > >>>>>>> In my POV, The standard document should not define solely the > >>>>>>> protocol extension, but their usages in the network deployment. > >>>>>>> As I known, almost all the IETF documents following this style. > >>>>>>> And, before adopting one work, we have often intense discussion > >>>>>>> for what's their usages. > >>>>>>> Such discussion in the mail list and statements in the document > >>>>>>> can certainly assist the reader/user of the document get the > >>>>>>> essence of the standard, and follow them unambiguously. > >>>>>>> > >>>>>>> Regarding the contents of appendices, as stated in the section, > >>>>>>> "The Appendix A heuristic to rebuild the topology can normally be > >>>>>>> used if all links are numbered." I think this can apply almost > >>>>>>> most of the operator's network, and facilitate the inter-area TE > >>>>>>> path calculation for central controller, or even for the head-end > >>>>>>> router that located in one area that different from the tail- end > router. > >>>>>>> > >>>>>>> Keeping the contents of appendices does not have the negative > >>>>>>> impact of the protocol extension, it is just one reference for > >>>>>>> the usage of this extension. > >>>>>>> One can select not refer to it, if their networks are deployed > >>>>>>> with large amount of unnumbered links. But for others, the > heuristic > >>> applies. > >>>>>>> > >>>>>>> Best Regards > >>>>>>> > >>>>>>> Aijun Wang > >>>>>>> China Telecom > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On > >>>>>>> Behalf Of Jeff Tantsura > >>>>>>> Sent: Friday, October 16, 2020 5:28 AM > >>>>>>> To: John E Drake > >>>>>>> Cc: Christian Hopps ; lsr-chairs@ietf.org; Les > >>>>>>> Ginsberg > >>>>>>> (ginsberg) ; lsr@ietf.org; > >>>>>>> lsr- ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org > >>>>>>> Subject: Re: [Lsr] WG Last Call > >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 > >>>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> Regards, > >>>>>>> Jeff > >>>>>>> > >>>>>>>> On Oct 15, 2020, at 11:33, John E Drake > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I agree with Les. This is a simple protocol extension for a > >>>>>>>> specific purpose > >>>>>>> and there is no reason to include speculation about its use for > >>>>>>> other purposes, particularly when it is inherently not suited for > them. > >>>>>>>> > >>>>>>>> Yours Irrespectively, > >>>>>>>> > >>>>>>>> John > >>>>>>>> > >>>>>>>> > >>>>>>>> Juniper Business Use Only > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Lsr On Behalf Of Les Ginsberg > >>>>>>>>> (ginsberg) > >>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM > >>>>>>>>> To: Christian Hopps ; lsr@ietf.org > >>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; > >>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org > >>>>>>>>> Subject: Re: [Lsr] WG Last Call > >>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 > >>>>>>>>> > >>>>>>>>> [External Email. Be cautious of content] > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I support moving this document forward. > >>>>>>>>> Similar functionality in IS-IS has proved useful. > >>>>>>>>> > >>>>>>>>> I would however like to repeat comments I made earlier in the > >>>>>>>>> review of this document. > >>>>>>>>> The content of the Appendices should be removed. > >>>>>>>>> The Appendices define and discuss deriving topology information > >>>>>>>>> from prefix advertisements - which is flawed and should not be > >>> done. > >>>>>>>>> Perhaps more relevant, the purpose of the document is to define > >>>>>>>>> protocol extensions supporting advertisement of the originators > >>>>>>>>> of a prefix advertisement. There is no need to discuss how this > >>>>>>>>> mechanism might be used to build topology information. > >>>>>>>>> This document should confine itself to defining the protocol > >>>>>>>>> extensions - similar the RFC 7794. > >>>>>>>>> > >>>>>>>>> If the authors do not agree to do this, I would encourage this > >>>>>>>>> point to be discussed during IESG review. > >>>>>>>>> > >>>>>>>>> Les > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Lsr On Behalf Of Christian Hopps > >>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM > >>>>>>>>>> To: lsr@ietf.org > >>>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; > >>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps > >>>>>>>>>> > >>>>>>>>>> Subject: [Lsr] WG Last Call > >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 > >>>>>>>>>> > >>>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020= , > for: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/d > >>>>>>>>>> ra > >>>>>>>>>> ft-i > >>>>>>>>>> et > >>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- > >>>>>>> gk!TaSzQThghtCFOuYPS2VjLq > >>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ > >>>>>>>>>> > >>>>>>>>>> The following IPR has been filed > >>>>>>>>>> > >>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__ > ;! > >>>>>>>>>> !NEt6yMaO- > >>>>>>>>> > >>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz > >>>>>>>>>> 5KtUHQ$ > >>>>>>>>>> > >>>>>>>>>> Authors, > >>>>>>>>>> > >>>>>>>>>> Please indicate to the list, your knowledge of any other IPR > >>>>>>>>>> related to this work. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Chris. > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Lsr mailing list > >>>>>>>>> Lsr@ietf.org > >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin > >>>>>>>>> fo > >>>>>>>>> /lsr > >>>>>>>>> __;!!NEt > >>>>>>>>> 6yMaO- > >>>>>>>>> > >>>>>>> > >>>> > >>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm > >>>>>>> w8 > >>>>>>>>> Lc$ > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Lsr mailing list > >>>>>>>> Lsr@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Lsr mailing list > >>>>>>> Lsr@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Lsr mailing list > >>>>>> Lsr@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lsr > >>> _______________________________________________ > >>> Lsr mailing list > >>> Lsr@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --0000000000009a579205b203a7f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aijun,

Regarding your appendix A -=C2= =A0

* How can we "rebuild" topology base= d on comparison of prefixes and rtr-id ?=C2=A0

* I= f link between S1 & S2 is not in LSDB there may be a valid operational = reasons for it. "Rebuilding it" will be actually harmful from all= points of view.=C2=A0

* You should be exporting t= opology from all areas not just from backbone and guessing the topology bas= ed on the prefix to rtr_id associations=C2=A0

* Im= aging someone is using multiaccess in areas. Are you also going to rebuild = DR & BDR ?=C2=A0

I must agree with comments fr= om Peter & Les here.=C2=A0

Cheers,
R.
=





On Mon, Oct 19,= 2020 at 12:11 PM Aijun Wang <wangaj3@chinatelecom.cn> wrote:
Hi. Peter, Les:

We have defined many extensions for protocol, but only a small part of them= are deployed. Have you ever considered the reason?

Adding more contents for their=C2=A0 potential usages can certainly be help= ful for their influences, or else, they will just stay at the IETF reposito= ry.

More replies inline below.



Aijun Wang
China Telecom

> On Oct 19, 2020, at 17:14, Peter Psenak <ppsenak=3D40cisco.com@dmarc.ietf.org<= /a>> wrote:
>
> =EF=BB=BFAijun,
>
>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
>> Aijun -
>> I am not going to continue these side discussions with you.
>> The primary purpose of the protocol extensions are as stated in th= e draft Introduction. This is analogous to the use cases for the equivalent= extensions for IS-IS already approved in RFC 7794. We need the equivalent = in OSPF.
>> You can show that you are listening to the concerns of WG members = by removing the Appendices - in which case you have (I believe) broad suppo= rt for moving the draft forward.
>
> I agree with Les.
>
> As a co-author, I have asked you several times to get rid of the use c= ase described in appendix.
[WAJ] Moving the expansion of this use case from body part of this draft to= its appendix is our initial consensus, not remove it totally. We have disc= ussed intensely for its application in vary situations. The discussion resu= lts are stated clearly in the appendix.
Wish to hear more technical analysis/comments for the current statements of= this part from other experts, or from you if you have fresh consideration.=

> Trying to use prefix advertisement to derive topological data is simpl= y broken. The reason we are adding the prefix originator extension to OSPF = is NOT the broken use case in the appendix of the draft.
>
> thanks,
> Peter
>
>
>
>> You can then write a separate draft to discuss other use cases and= allow the WG to discuss those other use cases w/o preventing the extension= s from being approved and deployed for the use cases which have already bee= n demonstrated as useful by IS-IS.
>> If you remove the Appendices I can support the draft.
>> If you do not remove the Appendices I cannot support the draft. >> Please discuss this with your co-authors and come to consensus on = your next step.
>>=C2=A0 =C2=A0 Les
>>> -----Original Message-----
>>> From: Aijun Wang <wangaijun@tsinghua.org.cn>
>>> Sent: Monday, October 19, 2020 12:06 AM
>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; 'Christian Hopps&= #39;
>>> <cho= pps@chopps.org>
>>> Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; lsr@ietf.org;
>>> 'Jeff Tantsura' <jefftant.ietf@gmail.com>; draft-ietf-lsr-= ospf-prefix-
>>> origi= nator@ietf.org; l= sr-ads@ietf.org
>>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-ori= ginator-06
>>>
>>> Hi, Les:
>>>
>>> As I stated clearly before, the appendix described in the draf= t is not the new
>>> use case. It is the start point of this draft.
>>> Have you noticed that the introduction part is not the final u= sage of such
>>> protocol extension information?
>>> Certainly, we will not expand all the possible use cases in ve= ry detail, but
>>> putting some of them(some interesting, prominent use cases) in= the
>>> appendix will not hamper the protocol extension itself.
>>>
>>> If the statements/descriptions in the appendix are not correct= , we can fix it,
>>> or remove it finally.=C2=A0 If not, why not let it be for refe= rence to the user of such
>>> protocol extension?
>>> For the body part of this draft, we are also welcome comments.=
>>>
>>> More replies inline below[WAJ]
>>>
>>> Best Regards
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> -----Original Message-----
>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Les
>>> Ginsberg (ginsberg)
>>> Sent: Monday, October 19, 2020 2:15 PM
>>> To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Christian Hopps= '
>>> <cho= pps@chopps.org>
>>> Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; 'Les Ginsbe= rg
>>> (ginsberg)' <ginsberg=3D40cisco.com@dmarc.ietf.org>; lsr@ietf.org; 'Jeff
>>> Tantsura' <jefftant.ietf@gmail.com>; draft-ietf-lsr-ospf-prefi= x-
>>> origi= nator@ietf.org; l= sr-ads@ietf.org
>>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-ori= ginator-06
>>>
>>> Aijun -
>>>
>>> The "use case" for the protocol extensions is clearl= y stated in the
>>> Introduction:
>>>
>>> "The primary use case for the extensions proposed in this= document is
>>>=C2=A0 =C2=A0 to be able to identify the originator of the pref= ix in the network.
>>>=C2=A0 =C2=A0 In cases where multiple prefixes are advertised b= y a given router, it
>>>=C2=A0 =C2=A0 is also useful to be able to associate all these = prefixes with a
>>>=C2=A0 =C2=A0 single router even when prefixes are advertised o= utside of the area
>>>=C2=A0 =C2=A0 in which they originated.=C2=A0 It also helps to = determine when the same
>>>=C2=A0 =C2=A0 prefix is being originated by multiple routers ac= ross areas."
>>>
>>> This is equivalent to language in RFC 7794 which defines the a= nalogous
>>> extensions for IS-IS.
>>>
>>> Everything you have in the Appendix is not related to the prim= ary use case -
>>> and is fact a use case which many of us have objected to.
>>> [WAJ] Very glad to know the false statements in the appendix.<= br> >>>
>>> You are entitled to write another draft advocating for your ne= w use case if
>>> you wish, but requiring that the protocol extensions in suppor= t of the
>>> primary use case not go forward without your new use case is -= as Chris has
>>> stated very clearly - holding approval of the protocol extensi= ons hostage to
>>> your new use case.
>>> [WAJ] It is not new use case. As I sated before, I am open to = this part, but
>>> should on the conditions that the statements in this part are = incorrect.
>>>
>>> I am asking you (yet again) not to do this.
>>>
>>> I cannot support the document moving forward with the content = in the
>>> Appendices included.
>>> [WAJ] Would like to hear more technical analysis.
>>>
>>>=C2=A0 =C2=A0 Les
>>>
>>>
>>>> -----Original Message-----
>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Aijun Wang
>>>> Sent: Sunday, October 18, 2020 7:08 PM
>>>> To: 'Christian Hopps' <chopps@chopps.org>
>>>> Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; 'Les >>>> Ginsberg (ginsberg)' <ginsberg=3D40cisco.com@dmarc.ietf.org>;
>>>> lsr@ietf= .org; 'Jeff Tantsura' <jefftant.ietf@gmail.com>;
>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org
>>>> Subject: Re: [Lsr] WG Last Call
>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>
>>>> Hi, Chris:
>>>>
>>>> I think we have "put the cart before the horse".= For protocol
>>>> extension draft, the origin is the use case.
>>>> And I think we will not expand OSPF protocol, just because= it lack
>>>> something as compared with ISIS, right?
>>>>
>>>> As I stated before, the use case in current appendix is th= e main
>>>> motivation of this draft, you can see this in main body of= the earlier
>>>> version of this draft(from version 0 to version 5).
>>>> The reason that we move this part to the appendix, as that= you said,
>>>> is to let person focus on the protocol extension itself. >>>>
>>>> Moving this part to appendix is acceptable, but removing i= t from the
>>>> draft will erase the origin of this document.
>>>> Is it reasonable that one document discusses the "ori= gin"(of the
>>>> prefix), can't keep its origin?
>>>>
>>>> More replies inline below[WAJ].
>>>>
>>>> Best Regards
>>>>
>>>> Aijun Wang
>>>> China Telecom
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of
>>>> Christian Hopps
>>>> Sent: Friday, October 16, 2020 10:47 PM
>>>> To: =E7=8E=8B=E7=88=B1=E4=BF=8A <wangaijun@tsinghua.org.cn><= br> >>>> Cc: John E Drake <jdrake@juniper.net>; Christian Hopps
>>>> <chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg (ginsberg)
>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org>; lsr@ietf.org; Jeff Tantsura
>>>> <jefftant.ietf@gmail.com>;
>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org<= br> >>>> Subject: Re: [Lsr] WG Last Call
>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>
>>>> Isn't this just adding an analogous extension that alr= eady exists in RFC7794?
>>>> [WAJ] No. RFC7794 is just one example that to illustrate, = as the
>>>> companion IGP protocol, OSPF can also accomplish this. And= , actually,
>>>> there are differences consideration in this draft for the = protocol extension.
>>>>
>>>> I don't think we need to do a lot of convincing at thi= s point. I agree
>>>> with Les, if you want to talk about use cases (especially = ones that
>>>> are controversial!) then the correct place for that is in = a new informative
>>> draft.
>>>> [WAJ] we have discussed the use case before and state the = discussion
>>>> results at the appendix part. We will not emphasis and exp= and the use
>>>> case more. If one does not agree the statement of this app= endix, we
>>>> can discuss online or offline. We just need to make the st= atement in
>>> appendix is correct.
>>>>
>>>> Otherwise, especially if the cases are controversial, this= can be seen
>>>> as doing an "end-run" to avoid the debate b/c pe= ople want the
>>>> extension, but maybe don't agree with your use case. >>>> [WAJ] One should point out which statement in the appendix= is
>>>> controversial, we can correct it. This use case is the ori= gin of this
>>>> draft, not the results.
>>>>
>>>> Legislators do this sometimes adding things they want pers= onally to
>>>> popular bills, that other people may not want, but since p= eople want
>>>> the main bill they vote for it anyway, in the US it's = called "adding
>>>> pork" or "pork barrel politics". :) [WAJ] T= he appendix is not added
>>>> later, but exist at the first beginning. This is the origi= n of the
>>>> bills.
>>>>
>>>> Thanks,
>>>> Chris.
>>>>
>>>>> On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF= =8A <wang= aijun@tsinghua.org.cn>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi, Chris:
>>>>> Originally, the appendix part is within the document, = which is the
>>>>> start
>>>> point/main motivation to extend the prefix origin.
>>>>> There may exists other usages of this information. Pac= k these
>>>>> examples
>>>> into some short sentences or introduction is viable, but e= xpand some
>>>> of them is also helpful.
>>>>> As I known, when we want to do protocol extension, we = should=C2=A0 always
>>>> convince other the reason/motivation/prospects to do so. O= n the other
>>>> hand, the use case described in the current appendix is ve= ry prominent
>>>> for operator to accomplish the TE task in multi-area envir= onment.
>>>>>
>>>>> Aijun Wang
>>>>>
>>>>> =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps &lt;chopps@chopps.org= &gt;=E5=86=99=E9=81=93:
>>>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----
>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps &= amp;lt;chopps@c= hopps.org&gt;
>>>>> =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410= =E6=9C=8816=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94
>>>>> =E5=86=99=E9=81=93: [&quot;Les Ginsberg (ginsberg)= &quot;
>>>>> &lt;ginsberg=3D40cisco.com@dmarc.ietf.org&gt;]
>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call dra= ft-ietf-lsr-ospf-prefix-originator-06
>>>>>
>>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsber= g)
>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org> wrote:
>>>>>>
>>>>>> Aijun -
>>>>>>
>>>>>> The point I am making is very focused.
>>>>>>
>>>>>> This draft is defining a protocol extension. As su= ch it is
>>>>>> necessary that this
>>>> be Standards track as adhering to the normative statements= in the
>>>> draft are necessary for interoperability.
>>>>>>
>>>>>> What is discussed in the Appendix is a use case. I= t is not
>>>>>> normative and
>>>> there are strong opinions on both sides as to whether this= is an
>>>> appropriate use case or not.
>>>>>> In the context of this draft, I have no interest i= n trying to
>>>>>> resolve our
>>>> difference of opinion on this use case. I simply want the = protocol
>>>> extension to move forward so that we have another tool ava= ilable.
>>>>>>
>>>>>> If you want to write a draft on the use case discu= ssed in the
>>>>>> Appendix
>>>> please feel free to do so. That draft may very well not be= normative -
>>>> Informational or BCP may be more appropriate - because it = will be
>>>> discussing a deployment scenario and a proposal to use def= ined
>>>> protocol extensions as one way to solve problems in that d= eployment
>>>> scenario. Such a draft might also be more appropriate in a= nother WG
>>>> (e.g., TEAS). The merits of using prefix advertisements to= build a topology
>>> could then be discussed on its own.
>>>>>>
>>>>>> Please do not try to avoid having a full discussio= n of the merits
>>>>>> of using
>>>> prefix advertisements to derive topology by adding it to a= draft that
>>>> is (and should be) focused on simple protocol extensions.<= br> >>>>>
>>>>> [As WG member]
>>>>>
>>>>> I find this very compelling and so support the removal= of the
>>>>> referred to
>>>> non-normative appendices.
>>>>>
>>>>> Thanks,
>>>>> Chris.
>>>>>
>>>>>>
>>>>>> Thanx.
>>>>>>
>>>>>>=C2=A0 =C2=A0Les
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Aijun Wang <wangaijun@tsinghua.org.cn>
>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM
>>>>>>> To: 'Jeff Tantsura' <jefftant.ietf@gmail.com&= gt;; 'John E Drake'
>>>>>>> <jdrake@juniper.net>
>>>>>>> Cc: 'Christian Hopps' <chopps@chopps.org>; lsr-chairs@ietf.org= ;
>>>>>>> Les Ginsberg
>>>>>>> (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org; lsr-ads@ietf.org;
>>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org<= /a>
>>>>>>> Subject: RE: [Lsr] WG Last Call
>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>>
>>>>>>> Hi, Les, John and Jeff:
>>>>>>>
>>>>>>> Let's reply you all together.
>>>>>>> In my POV, The standard document should not de= fine solely the
>>>>>>> protocol extension, but their usages in the ne= twork deployment.
>>>>>>> As I known, almost all the IETF documents foll= owing this style.
>>>>>>> And, before adopting one work, we have often i= ntense discussion
>>>>>>> for what's their usages.
>>>>>>> Such discussion in the mail list and statement= s in the document
>>>>>>> can certainly assist the reader/user of the do= cument get the
>>>>>>> essence of the standard, and follow them unamb= iguously.
>>>>>>>
>>>>>>> Regarding the contents of appendices, as state= d in the section,
>>>>>>> "The Appendix A heuristic to rebuild the = topology can normally be
>>>>>>> used if all links are numbered." I think = this can apply almost
>>>>>>> most of the operator's network, and facili= tate the inter-area TE
>>>>>>> path calculation for central controller, or ev= en for the head-end
>>>>>>> router that located in one area that different= from the tail- end router.
>>>>>>>
>>>>>>> Keeping the contents of appendices does not ha= ve the negative
>>>>>>> impact of the protocol extension, it is just o= ne reference for
>>>>>>> the usage of this extension.
>>>>>>> One can select not refer to it, if their netwo= rks are deployed
>>>>>>> with large amount of unnumbered links. But for= others, the heuristic
>>> applies.
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>> Aijun Wang
>>>>>>> China Telecom
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On
>>>>>>> Behalf Of Jeff Tantsura
>>>>>>> Sent: Friday, October 16, 2020 5:28 AM
>>>>>>> To: John E Drake <jdrake=3D40juniper.net@dmarc.ietf.= org>
>>>>>>> Cc: Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.org; Les
>>>>>>> Ginsberg
>>>>>>> (ginsberg) <ginsberg=3D40cisco.com@dmarc.ietf.org&= gt;; lsr@ietf.org; >>>>>>> lsr- ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@i= etf.org
>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jeff
>>>>>>>
>>>>>>>> On Oct 15, 2020, at 11:33, John E Drake >>>>>>> <jdrake=3D40juniper.net@dmarc.ietf.org> wrote= :
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I agree with Les.=C2=A0 This is a simple p= rotocol extension for a
>>>>>>>> specific purpose
>>>>>>> and there is no reason to include speculation = about its use for
>>>>>>> other purposes, particularly when it is inhere= ntly not suited for them.
>>>>>>>>
>>>>>>>> Yours Irrespectively,
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> Juniper Business Use Only
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of= Les Ginsberg
>>>>>>>>> (ginsberg)
>>>>>>>>> Sent: Thursday, October 15, 2020 12:33= PM
>>>>>>>>> To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org
>>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org;
>>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org
>>>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-= 06
>>>>>>>>>
>>>>>>>>> [External Email. Be cautious of conten= t]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I support moving this document forward= .
>>>>>>>>> Similar functionality in IS-IS has pro= ved useful.
>>>>>>>>>
>>>>>>>>> I would however like to repeat comment= s I made earlier in the
>>>>>>>>> review of this document.
>>>>>>>>> The content of the Appendices should b= e removed.
>>>>>>>>> The Appendices define and discuss deri= ving topology information
>>>>>>>>> from prefix advertisements - which is = flawed and should not be
>>> done.
>>>>>>>>> Perhaps more relevant, the purpose of = the document is to define
>>>>>>>>> protocol extensions supporting adverti= sement of the originators
>>>>>>>>> of a prefix advertisement. There is no= need to discuss how this
>>>>>>>>> mechanism might be used to build topol= ogy information.
>>>>>>>>> This document should confine itself to= defining the protocol
>>>>>>>>> extensions - similar the RFC 7794.
>>>>>>>>>
>>>>>>>>> If the authors do not agree to do this= , I would encourage this
>>>>>>>>> point to be discussed during IESG revi= ew.
>>>>>>>>>
>>>>>>>>>=C2=A0 Les
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Lsr <lsr-bounces@ietf.org> On Behal= f Of Christian Hopps
>>>>>>>>>> Sent: Wednesday, October 14, 2020 = 11:15 PM
>>>>>>>>>> To: lsr@ietf.org
>>>>>>>>>> Cc: draft-ietf-lsr-ospf-p= refix-originator@ietf.org;
>>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps
>>>>>>>>>> <chopps@chopps.org>
>>>>>>>>>> Subject: [Lsr] WG Last Call
>>>>>>>>>> draft-ietf-lsr-ospf-prefix-origina= tor-06
>>>>>>>>>>
>>>>>>>>>> This begins a 2 week WG Last Call,= ending after Oct 29th, 2020, for:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/d
>>>>>>>>>> ra
>>>>>>>>>> ft-i
>>>>>>>>>> et
>>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!= NEt6yMaO-
>>>>>>> gk!TaSzQThghtCFOuYPS2VjLq
>>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKH= cjkjClpk$
>>>>>>>>>>
>>>>>>>>>> The following IPR has been filed >>>>>>>>>>
>>>> https://urldefe= nse.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
>>>>>>>>>> !NEt6yMaO-
>>>>>>>>>
>>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKH= cz
>>>>>>>>>> 5KtUHQ$
>>>>>>>>>>
>>>>>>>>>> Authors,
>>>>>>>>>>
>>>>>>>>>> Please indicate to the list, your = knowledge of any other IPR
>>>>>>>>>> related to this work.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Chris.
>>>>>>>>>
>>>>>>>>> ______________________________________= _________
>>>>>>>>> Lsr mailing list
>>>>>>>>> Lsr@ietf.org
>>>>>>>>> = https://urldefense.com/v3/__https://www.ietf.org/mailman/listin
>>>>>>>>> fo
>>>>>>>>> /lsr
>>>>>>>>> __;!!NEt
>>>>>>>>> 6yMaO-
>>>>>>>>>
>>>>>>>
>>>>
>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm=
>>>>>>> w8
>>>>>>>>> Lc$
>>>>>>>>
>>>>>>>> __________________________________________= _____
>>>>>>>> Lsr mailing list
>>>>>>>> Lsr@ietf.org
>>>>>>>> https://www.ietf.org/mailm= an/listinfo/lsr
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> Lsr mailing list
>>>>>>> Lsr@ietf.org
>>>>>>> https://www.ietf.org/mailman/l= istinfo/lsr
>>>>>>
>>>>>> _______________________________________________ >>>>>> Lsr mailing list
>>>>>> = Lsr@ietf.org
>>>>>> https://www.ietf.org/mailman/listi= nfo/lsr
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> Lsr@ietf= .org
>>>> https://www.ietf.org/mailman/listinfo/lsr=
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/lsr<= br> >
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--0000000000009a579205b203a7f3-- From nobody Mon Oct 19 04:21:06 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA353A0B1D; Mon, 19 Oct 2020 04:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 aDolHp0Z8iSP; Mon, 19 Oct 2020 04:21:00 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7227B3A0B1C; Mon, 19 Oct 2020 04:20:57 -0700 (PDT) Received: from localhost.localdomain (unknown [106.121.66.233]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 307FD45659; Mon, 19 Oct 2020 19:20:51 +0800 (CST) Content-Type: multipart/alternative; boundary=Apple-Mail-1290217C-36F7-477C-9AB5-4C5CD9529144 Content-Transfer-Encoding: 7bit From: Aijun Wang Mime-Version: 1.0 (1.0) Date: Mon, 19 Oct 2020 19:20:49 +0800 Message-Id: <00418BE6-89AA-462D-9397-DE408BF944F8@tsinghua.org.cn> References: Cc: Aijun Wang , Peter Psenak , "Les Ginsberg (ginsberg)" , John E Drake , Christian Hopps , lsr-chairs@ietf.org, lsr , Jeff Tantsura , draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-ads@ietf.org In-Reply-To: To: Robert Raszuk X-Mailer: iPhone Mail (18A373) X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSBgaTE9PHUxDHh0YVkpNS0hKS01PTkpOSk9VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6K006CDo5AT8aGTE3LjgOKhFW TB5PC0xVSlVKTUtISktNT05JSkhJVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVU1NVUlISFlXWQgBWUFNTEhPTDcG X-HM-Tid: 0a7540972f099865kuuu307fd45659 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 11:21:05 -0000 --Apple-Mail-1290217C-36F7-477C-9AB5-4C5CD9529144 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Robert: Aijun Wang China Telecom > On Oct 19, 2020, at 18:34, Robert Raszuk wrote: >=20 > =EF=BB=BF > Aijun, >=20 > Regarding your appendix A -=20 >=20 > * How can we "rebuild" topology based on comparison of prefixes and rtr-id= ?=20 [WAJ]: The two ends of the link will advertise the same prefixes. The collec= tor of BGP-LS can compare them and interconnect the two ends, which are iden= tified by the originator of the said prefixes. >=20 > * If link between S1 & S2 is not in LSDB there may be a valid operational r= easons for it. "Rebuilding it" will be actually harmful from all points of v= iew.=20 [WAJ] The rebuild process will also omit this link. >=20 > * You should be exporting topology from all areas not just from backbone a= nd guessing the topology based on the prefix to rtr_id associations=20 >=20 [WAJ] Exporting the topology from all areas requires the BGP-LS speakers in a= ll areas, which is the burden of deployment. > * Imaging someone is using multiaccess in areas. Are you also going to reb= uild DR & BDR ?=20 >=20 [WAJ] For OSPF, the DR/BDR is the real node. There will be no difference for= the topology retrieval. For ISIS, the pseudo-nodes can be identified/exclud= ed via the circuit-ID of LSP.=20 > I must agree with comments from Peter & Les here.=20 >=20 > Cheers, > R. >=20 >=20 >=20 >=20 >=20 >> On Mon, Oct 19, 2020 at 12:11 PM Aijun Wang wro= te: >> Hi. Peter, Les: >>=20 >> We have defined many extensions for protocol, but only a small part of th= em are deployed. Have you ever considered the reason? >>=20 >> Adding more contents for their potential usages can certainly be helpful= for their influences, or else, they will just stay at the IETF repository. >>=20 >> More replies inline below. >>=20 >>=20 >>=20 >> Aijun Wang >> China Telecom >>=20 >> > On Oct 19, 2020, at 17:14, Peter Psenak wrote: >> >=20 >> > =EF=BB=BFAijun, >> >=20 >> >> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote: >> >> Aijun - >> >> I am not going to continue these side discussions with you. >> >> The primary purpose of the protocol extensions are as stated in the dr= aft Introduction. This is analogous to the use cases for the equivalent exte= nsions for IS-IS already approved in RFC 7794. We need the equivalent in OSP= F. >> >> You can show that you are listening to the concerns of WG members by r= emoving the Appendices - in which case you have (I believe) broad support fo= r moving the draft forward. >> >=20 >> > I agree with Les. >> >=20 >> > As a co-author, I have asked you several times to get rid of the use ca= se described in appendix. >> [WAJ] Moving the expansion of this use case from body part of this draft t= o its appendix is our initial consensus, not remove it totally. We have disc= ussed intensely for its application in vary situations. The discussion resul= ts are stated clearly in the appendix. >> Wish to hear more technical analysis/comments for the current statements o= f this part from other experts, or from you if you have fresh consideration.= >>=20 >> > Trying to use prefix advertisement to derive topological data is simply= broken. The reason we are adding the prefix originator extension to OSPF is= NOT the broken use case in the appendix of the draft. >> >=20 >> > thanks, >> > Peter >> >=20 >> >=20 >> >=20 >> >> You can then write a separate draft to discuss other use cases and all= ow the WG to discuss those other use cases w/o preventing the extensions fro= m being approved and deployed for the use cases which have already been demo= nstrated as useful by IS-IS. >> >> If you remove the Appendices I can support the draft. >> >> If you do not remove the Appendices I cannot support the draft. >> >> Please discuss this with your co-authors and come to consensus on your= next step. >> >> Les >> >>> -----Original Message----- >> >>> From: Aijun Wang >> >>> Sent: Monday, October 19, 2020 12:06 AM >> >>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps' >> >>> >> >>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; lsr@iet= f.org; >> >>> 'Jeff Tantsura' ; draft-ietf-lsr-ospf-prefix= - >> >>> originator@ietf.org; lsr-ads@ietf.org >> >>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator= -06 >> >>>=20 >> >>> Hi, Les: >> >>>=20 >> >>> As I stated clearly before, the appendix described in the draft is no= t the new >> >>> use case. It is the start point of this draft. >> >>> Have you noticed that the introduction part is not the final usage of= such >> >>> protocol extension information? >> >>> Certainly, we will not expand all the possible use cases in very deta= il, but >> >>> putting some of them(some interesting, prominent use cases) in the >> >>> appendix will not hamper the protocol extension itself. >> >>>=20 >> >>> If the statements/descriptions in the appendix are not correct, we ca= n fix it, >> >>> or remove it finally. If not, why not let it be for reference to the= user of such >> >>> protocol extension? >> >>> For the body part of this draft, we are also welcome comments. >> >>>=20 >> >>> More replies inline below[WAJ] >> >>>=20 >> >>> Best Regards >> >>>=20 >> >>> Aijun Wang >> >>> China Telecom >> >>>=20 >> >>> -----Original Message----- >> >>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of= Les >> >>> Ginsberg (ginsberg) >> >>> Sent: Monday, October 19, 2020 2:15 PM >> >>> To: Aijun Wang ; 'Christian Hopps' >> >>> >> >>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les Gi= nsberg >> >>> (ginsberg)' ; lsr@ietf.org; 'J= eff >> >>> Tantsura' ; draft-ietf-lsr-ospf-prefix- >> >>> originator@ietf.org; lsr-ads@ietf.org >> >>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator= -06 >> >>>=20 >> >>> Aijun - >> >>>=20 >> >>> The "use case" for the protocol extensions is clearly stated in the >> >>> Introduction: >> >>>=20 >> >>> "The primary use case for the extensions proposed in this document is= >> >>> to be able to identify the originator of the prefix in the network= . >> >>> In cases where multiple prefixes are advertised by a given router,= it >> >>> is also useful to be able to associate all these prefixes with a >> >>> single router even when prefixes are advertised outside of the are= a >> >>> in which they originated. It also helps to determine when the sam= e >> >>> prefix is being originated by multiple routers across areas." >> >>>=20 >> >>> This is equivalent to language in RFC 7794 which defines the analogou= s >> >>> extensions for IS-IS. >> >>>=20 >> >>> Everything you have in the Appendix is not related to the primary use= case - >> >>> and is fact a use case which many of us have objected to. >> >>> [WAJ] Very glad to know the false statements in the appendix. >> >>>=20 >> >>> You are entitled to write another draft advocating for your new use c= ase if >> >>> you wish, but requiring that the protocol extensions in support of th= e >> >>> primary use case not go forward without your new use case is - as Chr= is has >> >>> stated very clearly - holding approval of the protocol extensions hos= tage to >> >>> your new use case. >> >>> [WAJ] It is not new use case. As I sated before, I am open to this pa= rt, but >> >>> should on the conditions that the statements in this part are incorre= ct. >> >>>=20 >> >>> I am asking you (yet again) not to do this. >> >>>=20 >> >>> I cannot support the document moving forward with the content in the >> >>> Appendices included. >> >>> [WAJ] Would like to hear more technical analysis. >> >>>=20 >> >>> Les >> >>>=20 >> >>>=20 >> >>>> -----Original Message----- >> >>>> From: Lsr On Behalf Of Aijun Wang >> >>>> Sent: Sunday, October 18, 2020 7:08 PM >> >>>> To: 'Christian Hopps' >> >>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >> >>>> Ginsberg (ginsberg)' ; >> >>>> lsr@ietf.org; 'Jeff Tantsura' ; >> >>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >> >>>> Subject: Re: [Lsr] WG Last Call >> >>>> draft-ietf-lsr-ospf-prefix-originator-06 >> >>>>=20 >> >>>> Hi, Chris: >> >>>>=20 >> >>>> I think we have "put the cart before the horse". For protocol >> >>>> extension draft, the origin is the use case. >> >>>> And I think we will not expand OSPF protocol, just because it lack >> >>>> something as compared with ISIS, right? >> >>>>=20 >> >>>> As I stated before, the use case in current appendix is the main >> >>>> motivation of this draft, you can see this in main body of the earli= er >> >>>> version of this draft(from version 0 to version 5). >> >>>> The reason that we move this part to the appendix, as that you said,= >> >>>> is to let person focus on the protocol extension itself. >> >>>>=20 >> >>>> Moving this part to appendix is acceptable, but removing it from the= >> >>>> draft will erase the origin of this document. >> >>>> Is it reasonable that one document discusses the "origin"(of the >> >>>> prefix), can't keep its origin? >> >>>>=20 >> >>>> More replies inline below[WAJ]. >> >>>>=20 >> >>>> Best Regards >> >>>>=20 >> >>>> Aijun Wang >> >>>> China Telecom >> >>>>=20 >> >>>>=20 >> >>>> -----Original Message----- >> >>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf O= f >> >>>> Christian Hopps >> >>>> Sent: Friday, October 16, 2020 10:47 PM >> >>>> To: =E7=8E=8B=E7=88=B1=E4=BF=8A >> >>>> Cc: John E Drake ; Christian Hopps >> >>>> ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) >> >>>> ; lsr@ietf.org; Jeff Tantsura= >> >>>> ; >> >>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org >> >>>> Subject: Re: [Lsr] WG Last Call >> >>>> draft-ietf-lsr-ospf-prefix-originator-06 >> >>>>=20 >> >>>> Isn't this just adding an analogous extension that already exists in= RFC7794? >> >>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the >> >>>> companion IGP protocol, OSPF can also accomplish this. And, actually= , >> >>>> there are differences consideration in this draft for the protocol e= xtension. >> >>>>=20 >> >>>> I don't think we need to do a lot of convincing at this point. I agr= ee >> >>>> with Les, if you want to talk about use cases (especially ones that >> >>>> are controversial!) then the correct place for that is in a new info= rmative >> >>> draft. >> >>>> [WAJ] we have discussed the use case before and state the discussion= >> >>>> results at the appendix part. We will not emphasis and expand the us= e >> >>>> case more. If one does not agree the statement of this appendix, we >> >>>> can discuss online or offline. We just need to make the statement in= >> >>> appendix is correct. >> >>>>=20 >> >>>> Otherwise, especially if the cases are controversial, this can be se= en >> >>>> as doing an "end-run" to avoid the debate b/c people want the >> >>>> extension, but maybe don't agree with your use case. >> >>>> [WAJ] One should point out which statement in the appendix is >> >>>> controversial, we can correct it. This use case is the origin of thi= s >> >>>> draft, not the results. >> >>>>=20 >> >>>> Legislators do this sometimes adding things they want personally to >> >>>> popular bills, that other people may not want, but since people want= >> >>>> the main bill they vote for it anyway, in the US it's called "adding= >> >>>> pork" or "pork barrel politics". :) [WAJ] The appendix is not added >> >>>> later, but exist at the first beginning. This is the origin of the >> >>>> bills. >> >>>>=20 >> >>>> Thanks, >> >>>> Chris. >> >>>>=20 >> >>>>> On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A >> >>>> wrote: >> >>>>>=20 >> >>>>>=20 >> >>>>> Hi, Chris: >> >>>>> Originally, the appendix part is within the document, which is the >> >>>>> start >> >>>> point/main motivation to extend the prefix origin. >> >>>>> There may exists other usages of this information. Pack these >> >>>>> examples >> >>>> into some short sentences or introduction is viable, but expand some= >> >>>> of them is also helpful. >> >>>>> As I known, when we want to do protocol extension, we should alway= s >> >>>> convince other the reason/motivation/prospects to do so. On the othe= r >> >>>> hand, the use case described in the current appendix is very promine= nt >> >>>> for operator to accomplish the TE task in multi-area environment. >> >>>>>=20 >> >>>>> Aijun Wang >> >>>>>=20 >> >>>>> =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps <chopps@chopps.org&g= t;=E5=86=99=E9=81=93: >> >>>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- >> >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps <chopps@cho= pps.org> >> >>>>> =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410=E6=9C=8816=E6= =97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94 >> >>>>> =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)" >> >>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org>] >> >>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call draft-ietf-lsr-o= spf-prefix-originator-06 >> >>>>>=20 >> >>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) >> >>>> wrote: >> >>>>>>=20 >> >>>>>> Aijun - >> >>>>>>=20 >> >>>>>> The point I am making is very focused. >> >>>>>>=20 >> >>>>>> This draft is defining a protocol extension. As such it is >> >>>>>> necessary that this >> >>>> be Standards track as adhering to the normative statements in the >> >>>> draft are necessary for interoperability. >> >>>>>>=20 >> >>>>>> What is discussed in the Appendix is a use case. It is not >> >>>>>> normative and >> >>>> there are strong opinions on both sides as to whether this is an >> >>>> appropriate use case or not. >> >>>>>> In the context of this draft, I have no interest in trying to >> >>>>>> resolve our >> >>>> difference of opinion on this use case. I simply want the protocol >> >>>> extension to move forward so that we have another tool available. >> >>>>>>=20 >> >>>>>> If you want to write a draft on the use case discussed in the >> >>>>>> Appendix >> >>>> please feel free to do so. That draft may very well not be normative= - >> >>>> Informational or BCP may be more appropriate - because it will be >> >>>> discussing a deployment scenario and a proposal to use defined >> >>>> protocol extensions as one way to solve problems in that deployment >> >>>> scenario. Such a draft might also be more appropriate in another WG >> >>>> (e.g., TEAS). The merits of using prefix advertisements to build a t= opology >> >>> could then be discussed on its own. >> >>>>>>=20 >> >>>>>> Please do not try to avoid having a full discussion of the merits >> >>>>>> of using >> >>>> prefix advertisements to derive topology by adding it to a draft tha= t >> >>>> is (and should be) focused on simple protocol extensions. >> >>>>>=20 >> >>>>> [As WG member] >> >>>>>=20 >> >>>>> I find this very compelling and so support the removal of the >> >>>>> referred to >> >>>> non-normative appendices. >> >>>>>=20 >> >>>>> Thanks, >> >>>>> Chris. >> >>>>>=20 >> >>>>>>=20 >> >>>>>> Thanx. >> >>>>>>=20 >> >>>>>> Les >> >>>>>>=20 >> >>>>>>=20 >> >>>>>>> -----Original Message----- >> >>>>>>> From: Aijun Wang >> >>>>>>> Sent: Thursday, October 15, 2020 6:51 PM >> >>>>>>> To: 'Jeff Tantsura' ; 'John E Drake' >> >>>>>>> >> >>>>>>> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; >> >>>>>>> Les Ginsberg >> >>>>>>> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; >> >>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org >> >>>>>>> Subject: RE: [Lsr] WG Last Call >> >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >> >>>>>>>=20 >> >>>>>>> Hi, Les, John and Jeff: >> >>>>>>>=20 >> >>>>>>> Let's reply you all together. >> >>>>>>> In my POV, The standard document should not define solely the >> >>>>>>> protocol extension, but their usages in the network deployment. >> >>>>>>> As I known, almost all the IETF documents following this style. >> >>>>>>> And, before adopting one work, we have often intense discussion >> >>>>>>> for what's their usages. >> >>>>>>> Such discussion in the mail list and statements in the document >> >>>>>>> can certainly assist the reader/user of the document get the >> >>>>>>> essence of the standard, and follow them unambiguously. >> >>>>>>>=20 >> >>>>>>> Regarding the contents of appendices, as stated in the section, >> >>>>>>> "The Appendix A heuristic to rebuild the topology can normally be= >> >>>>>>> used if all links are numbered." I think this can apply almost >> >>>>>>> most of the operator's network, and facilitate the inter-area TE >> >>>>>>> path calculation for central controller, or even for the head-end= >> >>>>>>> router that located in one area that different from the tail- end= router. >> >>>>>>>=20 >> >>>>>>> Keeping the contents of appendices does not have the negative >> >>>>>>> impact of the protocol extension, it is just one reference for >> >>>>>>> the usage of this extension. >> >>>>>>> One can select not refer to it, if their networks are deployed >> >>>>>>> with large amount of unnumbered links. But for others, the heuris= tic >> >>> applies. >> >>>>>>>=20 >> >>>>>>> Best Regards >> >>>>>>>=20 >> >>>>>>> Aijun Wang >> >>>>>>> China Telecom >> >>>>>>>=20 >> >>>>>>>=20 >> >>>>>>>=20 >> >>>>>>> -----Original Message----- >> >>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >> >>>>>>> Behalf Of Jeff Tantsura >> >>>>>>> Sent: Friday, October 16, 2020 5:28 AM >> >>>>>>> To: John E Drake >> >>>>>>> Cc: Christian Hopps ; lsr-chairs@ietf.org; Les= >> >>>>>>> Ginsberg >> >>>>>>> (ginsberg) ; lsr@ietf.org;= >> >>>>>>> lsr- ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf.org= >> >>>>>>> Subject: Re: [Lsr] WG Last Call >> >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >> >>>>>>>=20 >> >>>>>>> +1 >> >>>>>>>=20 >> >>>>>>> Regards, >> >>>>>>> Jeff >> >>>>>>>=20 >> >>>>>>>> On Oct 15, 2020, at 11:33, John E Drake >> >>>>>>> wrote: >> >>>>>>>>=20 >> >>>>>>>> Hi, >> >>>>>>>>=20 >> >>>>>>>> I agree with Les. This is a simple protocol extension for a >> >>>>>>>> specific purpose >> >>>>>>> and there is no reason to include speculation about its use for >> >>>>>>> other purposes, particularly when it is inherently not suited for= them. >> >>>>>>>>=20 >> >>>>>>>> Yours Irrespectively, >> >>>>>>>>=20 >> >>>>>>>> John >> >>>>>>>>=20 >> >>>>>>>>=20 >> >>>>>>>> Juniper Business Use Only >> >>>>>>>>=20 >> >>>>>>>>> -----Original Message----- >> >>>>>>>>> From: Lsr On Behalf Of Les Ginsberg >> >>>>>>>>> (ginsberg) >> >>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM >> >>>>>>>>> To: Christian Hopps ; lsr@ietf.org >> >>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; >> >>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org >> >>>>>>>>> Subject: Re: [Lsr] WG Last Call >> >>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >> >>>>>>>>>=20 >> >>>>>>>>> [External Email. Be cautious of content] >> >>>>>>>>>=20 >> >>>>>>>>>=20 >> >>>>>>>>> I support moving this document forward. >> >>>>>>>>> Similar functionality in IS-IS has proved useful. >> >>>>>>>>>=20 >> >>>>>>>>> I would however like to repeat comments I made earlier in the >> >>>>>>>>> review of this document. >> >>>>>>>>> The content of the Appendices should be removed. >> >>>>>>>>> The Appendices define and discuss deriving topology information= >> >>>>>>>>> from prefix advertisements - which is flawed and should not be >> >>> done. >> >>>>>>>>> Perhaps more relevant, the purpose of the document is to define= >> >>>>>>>>> protocol extensions supporting advertisement of the originators= >> >>>>>>>>> of a prefix advertisement. There is no need to discuss how this= >> >>>>>>>>> mechanism might be used to build topology information. >> >>>>>>>>> This document should confine itself to defining the protocol >> >>>>>>>>> extensions - similar the RFC 7794. >> >>>>>>>>>=20 >> >>>>>>>>> If the authors do not agree to do this, I would encourage this >> >>>>>>>>> point to be discussed during IESG review. >> >>>>>>>>>=20 >> >>>>>>>>> Les >> >>>>>>>>>=20 >> >>>>>>>>>> -----Original Message----- >> >>>>>>>>>> From: Lsr On Behalf Of Christian Hopps >> >>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM >> >>>>>>>>>> To: lsr@ietf.org >> >>>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >> >>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >> >>>>>>>>>> >> >>>>>>>>>> Subject: [Lsr] WG Last Call >> >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >> >>>>>>>>>>=20 >> >>>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020= , for: >> >>>>>>>>>>=20 >> >>>>>>>>>>=20 >> >>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/d= >> >>>>>>>>>> ra >> >>>>>>>>>> ft-i >> >>>>>>>>>> et >> >>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- >> >>>>>>> gk!TaSzQThghtCFOuYPS2VjLq >> >>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >> >>>>>>>>>>=20 >> >>>>>>>>>> The following IPR has been filed >> >>>>>>>>>>=20 >> >>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__= ;! >> >>>>>>>>>> !NEt6yMaO- >> >>>>>>>>>=20 >> >>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >> >>>>>>>>>> 5KtUHQ$ >> >>>>>>>>>>=20 >> >>>>>>>>>> Authors, >> >>>>>>>>>>=20 >> >>>>>>>>>> Please indicate to the list, your knowledge of any other IPR >> >>>>>>>>>> related to this work. >> >>>>>>>>>>=20 >> >>>>>>>>>> Thanks, >> >>>>>>>>>> Chris. >> >>>>>>>>>=20 >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> Lsr mailing list >> >>>>>>>>> Lsr@ietf.org >> >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin= >> >>>>>>>>> fo >> >>>>>>>>> /lsr >> >>>>>>>>> __;!!NEt >> >>>>>>>>> 6yMaO- >> >>>>>>>>>=20 >> >>>>>>>=20 >> >>>>=20 >> >>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >> >>>>>>> w8 >> >>>>>>>>> Lc$ >> >>>>>>>>=20 >> >>>>>>>> _______________________________________________ >> >>>>>>>> Lsr mailing list >> >>>>>>>> Lsr@ietf.org >> >>>>>>>> https://www.ietf.org/mailman/listinfo/lsr >> >>>>>>>=20 >> >>>>>>> _______________________________________________ >> >>>>>>> Lsr mailing list >> >>>>>>> Lsr@ietf.org >> >>>>>>> https://www.ietf.org/mailman/listinfo/lsr >> >>>>>>=20 >> >>>>>> _______________________________________________ >> >>>>>> Lsr mailing list >> >>>>>> Lsr@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/lsr >> >>>>>=20 >> >>>>>=20 >> >>>>>=20 >> >>>>=20 >> >>>>=20 >> >>>> _______________________________________________ >> >>>> Lsr mailing list >> >>>> Lsr@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/lsr >> >>> _______________________________________________ >> >>> Lsr mailing list >> >>> Lsr@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/lsr >> >=20 >> > _______________________________________________ >> > Lsr mailing list >> > Lsr@ietf.org >> > https://www.ietf.org/mailman/listinfo/lsr >>=20 >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr --Apple-Mail-1290217C-36F7-477C-9AB5-4C5CD9529144 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Robert:

Aijun W= ang
China Telecom

On Oct 19, 2020, at 18:34, Robert Raszuk <robert@raszuk.net> wrote= :

=EF=BB= =BF
Aijun,

Regarding your appendix A -&nb= sp;

* How can we "rebuild" topology based on compar= ison of prefixes and rtr-id ? 

<= /div>[WAJ]: The two ends of the link will advertise the same prefixes. The c= ollector of BGP-LS can compare them and interconnect the two ends, which are= identified by the originator of the said prefixes.

* If link between= S1 & S2 is not in LSDB there may be a valid operational reasons for it.= "Rebuilding it" will be actually harmful from all points of view. 

[WAJ] The rebuild process wil= l also omit this link.

<= div dir=3D"ltr">

* You should be exporting topology from a= ll areas not just from backbone and guessing the topology based on the prefi= x to rtr_id associations 

=
[WAJ] Exporting the topology from all areas requires the BGP-LS speaker= s in all areas, which is the burden of deployment.

* Imaging someone is using m= ultiaccess in areas. Are you also going to rebuild DR & BDR ? 

[WAJ] For OSPF, the DR/BDR is the r= eal node. There will be no difference for the topology retrieval. For ISIS, t= he pseudo-nodes can be identified/excluded via the circuit-ID of LSP. <= div>
I m= ust agree with comments from Peter & Les here. 

Cheers,
R.



<= br>

On Mon, Oct 19, 2020 at 12:11 PM Aijun Wang <wangaj3@chinatelecom.cn> wrote:
Hi. Peter, Les:

We have defined many extensions for protocol, but only a small part of them a= re deployed. Have you ever considered the reason?

Adding more contents for their  potential usages can certainly be helpf= ul for their influences, or else, they will just stay at the IETF repository= .

More replies inline below.



Aijun Wang
China Telecom

> On Oct 19, 2020, at 17:14, Peter Psenak <ppsenak=3D40cisco.com@dmarc.ietf.org> wrote:
>
> =EF=BB=BFAijun,
>
>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
>> Aijun -
>> I am not going to continue these side discussions with you.
>> The primary purpose of the protocol extensions are as stated in the= draft Introduction. This is analogous to the use cases for the equivalent e= xtensions for IS-IS already approved in RFC 7794. We need the equivalent in O= SPF.
>> You can show that you are listening to the concerns of WG members b= y removing the Appendices - in which case you have (I believe) broad support= for moving the draft forward.
>
> I agree with Les.
>
> As a co-author, I have asked you several times to get rid of the use ca= se described in appendix.
[WAJ] Moving the expansion of this use case from body part of this draft to i= ts appendix is our initial consensus, not remove it totally. We have discuss= ed intensely for its application in vary situations. The discussion results a= re stated clearly in the appendix.
Wish to hear more technical analysis/comments for the current statements of t= his part from other experts, or from you if you have fresh consideration.
> Trying to use prefix advertisement to derive topological data is simply= broken. The reason we are adding the prefix originator extension to OSPF is= NOT the broken use case in the appendix of the draft.
>
> thanks,
> Peter
>
>
>
>> You can then write a separate draft to discuss other use cases and a= llow the WG to discuss those other use cases w/o preventing the extensions f= rom being approved and deployed for the use cases which have already been de= monstrated as useful by IS-IS.
>> If you remove the Appendices I can support the draft.
>> If you do not remove the Appendices I cannot support the draft.
= >> Please discuss this with your co-authors and come to consensus on y= our next step.
>>    Les
>>> -----Original Message-----
>>> From: Aijun Wang <wangaijun@tsinghua.org.cn>
>>> Sent: Monday, October 19, 2020 12:06 AM
>>> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; 'Christian Hopps'
>>> <chop= ps@chopps.org>
>>> Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; lsr@ietf.org;
>>> 'Jeff Tantsura' <jefftant.ietf@gmail.com>; draft-ietf-lsr-ospf-prefix= -
>>> origin= ator@ietf.org; lsr= -ads@ietf.org
>>> Subject: RE: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-orig= inator-06
>>>
>>> Hi, Les:
>>>
>>> As I stated clearly before, the appendix described in the draft= is not the new
>>> use case. It is the start point of this draft.
>>> Have you noticed that the introduction part is not the final us= age of such
>>> protocol extension information?
>>> Certainly, we will not expand all the possible use cases in ver= y detail, but
>>> putting some of them(some interesting, prominent use cases) in t= he
>>> appendix will not hamper the protocol extension itself.
>>>
>>> If the statements/descriptions in the appendix are not correct,= we can fix it,
>>> or remove it finally.  If not, why not let it be for refer= ence to the user of such
>>> protocol extension?
>>> For the body part of this draft, we are also welcome comments.<= br> >>>
>>> More replies inline below[WAJ]
>>>
>>> Best Regards
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> -----Original Message-----
>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of Les
>>> Ginsberg (ginsberg)
>>> Sent: Monday, October 19, 2020 2:15 PM
>>> To: Aijun Wang <wangaijun@tsinghua.org.cn>; 'Christian Hopps'
>>> <chop= ps@chopps.org>
>>> Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; 'Les Ginsberg
>>> (ginsberg)' <ginsberg=3D40cisco.com@dmarc.ietf.org>; lsr@ietf.org; 'Jeff
>>> Tantsura' <jefftant.ietf@gmail.com>; draft-ietf-lsr-ospf-prefix-
= >>> origin= ator@ietf.org; lsr= -ads@ietf.org
>>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-orig= inator-06
>>>
>>> Aijun -
>>>
>>> The "use case" for the protocol extensions is clearly stated in= the
>>> Introduction:
>>>
>>> "The primary use case for the extensions proposed in this docum= ent is
>>>    to be able to identify the originator of the prefi= x in the network.
>>>    In cases where multiple prefixes are advertised by= a given router, it
>>>    is also useful to be able to associate all these p= refixes with a
>>>    single router even when prefixes are advertised ou= tside of the area
>>>    in which they originated.  It also helps to d= etermine when the same
>>>    prefix is being originated by multiple routers acr= oss areas."
>>>
>>> This is equivalent to language in RFC 7794 which defines the an= alogous
>>> extensions for IS-IS.
>>>
>>> Everything you have in the Appendix is not related to the prima= ry use case -
>>> and is fact a use case which many of us have objected to.
>>> [WAJ] Very glad to know the false statements in the appendix. >>>
>>> You are entitled to write another draft advocating for your new= use case if
>>> you wish, but requiring that the protocol extensions in support= of the
>>> primary use case not go forward without your new use case is - a= s Chris has
>>> stated very clearly - holding approval of the protocol extensio= ns hostage to
>>> your new use case.
>>> [WAJ] It is not new use case. As I sated before, I am open to t= his part, but
>>> should on the conditions that the statements in this part are i= ncorrect.
>>>
>>> I am asking you (yet again) not to do this.
>>>
>>> I cannot support the document moving forward with the content i= n the
>>> Appendices included.
>>> [WAJ] Would like to hear more technical analysis.
>>>
>>>    Les
>>>
>>>
>>>> -----Original Message-----
>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Aijun Wang
>>>> Sent: Sunday, October 18, 2020 7:08 PM
>>>> To: 'Christian Hopps' <chopps@chopps.org>
>>>> Cc: 'John E Drake' <jdrake@juniper.net>; lsr-chairs@ietf.org; 'Les
>>>> Ginsberg (ginsberg)' <ginsberg=3D40cisco.com@dmarc.ietf.org>;=
>>>> lsr@ietf.= org; 'Jeff Tantsura' <jefftant.ietf@gmail.com>;
>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org
>>>> Subject: Re: [Lsr] WG Last Call
>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>
>>>> Hi, Chris:
>>>>
>>>> I think we have "put the cart before the horse". For protoc= ol
>>>> extension draft, the origin is the use case.
>>>> And I think we will not expand OSPF protocol, just because i= t lack
>>>> something as compared with ISIS, right?
>>>>
>>>> As I stated before, the use case in current appendix is the= main
>>>> motivation of this draft, you can see this in main body of t= he earlier
>>>> version of this draft(from version 0 to version 5).
>>>> The reason that we move this part to the appendix, as that y= ou said,
>>>> is to let person focus on the protocol extension itself. >>>>
>>>> Moving this part to appendix is acceptable, but removing it= from the
>>>> draft will erase the origin of this document.
>>>> Is it reasonable that one document discusses the "origin"(o= f the
>>>> prefix), can't keep its origin?
>>>>
>>>> More replies inline below[WAJ].
>>>>
>>>> Best Regards
>>>>
>>>> Aijun Wang
>>>> China Telecom
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf Of
>>>> Christian Hopps
>>>> Sent: Friday, October 16, 2020 10:47 PM
>>>> To: =E7=8E=8B=E7=88=B1=E4=BF=8A <wangaijun@tsinghua.org.cn> >>>> Cc: John E Drake <jdrake@juniper.net>; Christian Hopps
>>>> <= chopps@chopps.org>; lsr-chairs@ietf.org; Les Ginsberg (ginsberg)
>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org>; lsr@ietf.org; Jeff Tantsura
>>>> <jefftant.ietf@gmail.com>;
>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org;= lsr- ads@ietf.org
= >>>> Subject: Re: [Lsr] WG Last Call
>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>
>>>> Isn't this just adding an analogous extension that already e= xists in RFC7794?
>>>> [WAJ] No. RFC7794 is just one example that to illustrate, a= s the
>>>> companion IGP protocol, OSPF can also accomplish this. And,= actually,
>>>> there are differences consideration in this draft for the p= rotocol extension.
>>>>
>>>> I don't think we need to do a lot of convincing at this poi= nt. I agree
>>>> with Les, if you want to talk about use cases (especially o= nes that
>>>> are controversial!) then the correct place for that is in a= new informative
>>> draft.
>>>> [WAJ] we have discussed the use case before and state the d= iscussion
>>>> results at the appendix part. We will not emphasis and expa= nd the use
>>>> case more. If one does not agree the statement of this appe= ndix, we
>>>> can discuss online or offline. We just need to make the sta= tement in
>>> appendix is correct.
>>>>
>>>> Otherwise, especially if the cases are controversial, this c= an be seen
>>>> as doing an "end-run" to avoid the debate b/c people want t= he
>>>> extension, but maybe don't agree with your use case.
>>>> [WAJ] One should point out which statement in the appendix i= s
>>>> controversial, we can correct it. This use case is the orig= in of this
>>>> draft, not the results.
>>>>
>>>> Legislators do this sometimes adding things they want perso= nally to
>>>> popular bills, that other people may not want, but since pe= ople want
>>>> the main bill they vote for it anyway, in the US it's calle= d "adding
>>>> pork" or "pork barrel politics". :) [WAJ] The appendix is n= ot added
>>>> later, but exist at the first beginning. This is the origin= of the
>>>> bills.
>>>>
>>>> Thanks,
>>>> Chris.
>>>>
>>>>> On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A= <wangaiju= n@tsinghua.org.cn>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi, Chris:
>>>>> Originally, the appendix part is within the document, w= hich is the
>>>>> start
>>>> point/main motivation to extend the prefix origin.
>>>>> There may exists other usages of this information. Pack= these
>>>>> examples
>>>> into some short sentences or introduction is viable, but ex= pand some
>>>> of them is also helpful.
>>>>> As I known, when we want to do protocol extension, we s= hould  always
>>>> convince other the reason/motivation/prospects to do so. On= the other
>>>> hand, the use case described in the current appendix is ver= y prominent
>>>> for operator to accomplish the TE task in multi-area enviro= nment.
>>>>>
>>>>> Aijun Wang
>>>>>
>>>>> =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps &lt;chopps@chopps.org&gt;=E5=86=99=E9=81=93:
>>>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----
>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps &a= mp;lt;chopps@cho= pps.org&gt;
>>>>> =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410=E6= =9C=8816=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94
>>>>> =E5=86=99=E9=81=93: [&quot;Les Ginsberg (ginsberg)&= amp;quot;
>>>>> &lt;ginsberg=3D40cisco.com@dmarc.ietf.org&gt;]
>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call draf= t-ietf-lsr-ospf-prefix-originator-06
>>>>>
>>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg= )
>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org> wrote:
>>>>>>
>>>>>> Aijun -
>>>>>>
>>>>>> The point I am making is very focused.
>>>>>>
>>>>>> This draft is defining a protocol extension. As suc= h it is
>>>>>> necessary that this
>>>> be Standards track as adhering to the normative statements i= n the
>>>> draft are necessary for interoperability.
>>>>>>
>>>>>> What is discussed in the Appendix is a use case. It= is not
>>>>>> normative and
>>>> there are strong opinions on both sides as to whether this i= s an
>>>> appropriate use case or not.
>>>>>> In the context of this draft, I have no interest in= trying to
>>>>>> resolve our
>>>> difference of opinion on this use case. I simply want the p= rotocol
>>>> extension to move forward so that we have another tool avai= lable.
>>>>>>
>>>>>> If you want to write a draft on the use case discus= sed in the
>>>>>> Appendix
>>>> please feel free to do so. That draft may very well not be n= ormative -
>>>> Informational or BCP may be more appropriate - because it w= ill be
>>>> discussing a deployment scenario and a proposal to use defi= ned
>>>> protocol extensions as one way to solve problems in that de= ployment
>>>> scenario. Such a draft might also be more appropriate in an= other WG
>>>> (e.g., TEAS). The merits of using prefix advertisements to b= uild a topology
>>> could then be discussed on its own.
>>>>>>
>>>>>> Please do not try to avoid having a full discussion= of the merits
>>>>>> of using
>>>> prefix advertisements to derive topology by adding it to a d= raft that
>>>> is (and should be) focused on simple protocol extensions. >>>>>
>>>>> [As WG member]
>>>>>
>>>>> I find this very compelling and so support the removal o= f the
>>>>> referred to
>>>> non-normative appendices.
>>>>>
>>>>> Thanks,
>>>>> Chris.
>>>>>
>>>>>>
>>>>>> Thanx.
>>>>>>
>>>>>>   Les
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Aijun Wang <wangaijun@tsinghua.org.cn>
>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM
>>>>>>> To: 'Jeff Tantsura' <jefftant.ietf@gmail.com>; 'John= E Drake'
>>>>>>> <jdrake@juniper.net>
>>>>>>> Cc: 'Christian Hopps' <chopps@chopps.org>; lsr-chairs@ietf.org;
>>>>>>> Les Ginsberg
>>>>>>> (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org; lsr-ads@ietf.org;
>>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org
>>>>>>> Subject: RE: [Lsr] WG Last Call
>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>>
>>>>>>> Hi, Les, John and Jeff:
>>>>>>>
>>>>>>> Let's reply you all together.
>>>>>>> In my POV, The standard document should not def= ine solely the
>>>>>>> protocol extension, but their usages in the net= work deployment.
>>>>>>> As I known, almost all the IETF documents follo= wing this style.
>>>>>>> And, before adopting one work, we have often in= tense discussion
>>>>>>> for what's their usages.
>>>>>>> Such discussion in the mail list and statements= in the document
>>>>>>> can certainly assist the reader/user of the doc= ument get the
>>>>>>> essence of the standard, and follow them unambi= guously.
>>>>>>>
>>>>>>> Regarding the contents of appendices, as stated= in the section,
>>>>>>> "The Appendix A heuristic to rebuild the topolo= gy can normally be
>>>>>>> used if all links are numbered." I think this c= an apply almost
>>>>>>> most of the operator's network, and facilitate t= he inter-area TE
>>>>>>> path calculation for central controller, or eve= n for the head-end
>>>>>>> router that located in one area that different f= rom the tail- end router.
>>>>>>>
>>>>>>> Keeping the contents of appendices does not hav= e the negative
>>>>>>> impact of the protocol extension, it is just on= e reference for
>>>>>>> the usage of this extension.
>>>>>>> One can select not refer to it, if their networ= ks are deployed
>>>>>>> with large amount of unnumbered links. But for o= thers, the heuristic
>>> applies.
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>> Aijun Wang
>>>>>>> China Telecom
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On
>>>>>>> Behalf Of Jeff Tantsura
>>>>>>> Sent: Friday, October 16, 2020 5:28 AM
>>>>>>> To: John E Drake <jdrake=3D40juniper.net@dmarc.ietf.or= g>
>>>>>>> Cc: Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.org; Les
>>>>>>> Ginsberg
>>>>>>> (ginsberg) <ginsberg=3D40cisco.com@dmarc.ietf.org>= ;; lsr@ietf.org;
>>>>>>> lsr- ads@ietf.org; draft-ietf-lsr-ospf-prefix-originator@ietf= .org
>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jeff
>>>>>>>
>>>>>>>> On Oct 15, 2020, at 11:33, John E Drake
= >>>>>>> <jdrake=3D40juniper.net@dmarc.ietf.org> wrote:<= br> >>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I agree with Les.  This is a simple pr= otocol extension for a
>>>>>>>> specific purpose
>>>>>>> and there is no reason to include speculation a= bout its use for
>>>>>>> other purposes, particularly when it is inheren= tly not suited for them.
>>>>>>>>
>>>>>>>> Yours Irrespectively,
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>
>>>>>>>> Juniper Business Use Only
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of L= es Ginsberg
>>>>>>>>> (ginsberg)
>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 P= M
>>>>>>>>> To: Christian Hopps <chopps@chopps.org>; lsr@ietf.org
>>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org;
>>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org
>>>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-0= 6
>>>>>>>>>
>>>>>>>>> [External Email. Be cautious of content= ]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I support moving this document forward.=
>>>>>>>>> Similar functionality in IS-IS has prov= ed useful.
>>>>>>>>>
>>>>>>>>> I would however like to repeat comments= I made earlier in the
>>>>>>>>> review of this document.
>>>>>>>>> The content of the Appendices should be= removed.
>>>>>>>>> The Appendices define and discuss deriv= ing topology information
>>>>>>>>> from prefix advertisements - which is f= lawed and should not be
>>> done.
>>>>>>>>> Perhaps more relevant, the purpose of t= he document is to define
>>>>>>>>> protocol extensions supporting advertis= ement of the originators
>>>>>>>>> of a prefix advertisement. There is no n= eed to discuss how this
>>>>>>>>> mechanism might be used to build topolo= gy information.
>>>>>>>>> This document should confine itself to d= efining the protocol
>>>>>>>>> extensions - similar the RFC 7794.
>>>>>>>>>
>>>>>>>>> If the authors do not agree to do this,= I would encourage this
>>>>>>>>> point to be discussed during IESG revie= w.
>>>>>>>>>
>>>>>>>>>  Les
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Lsr <lsr-bounces@ietf.org> On Behalf O= f Christian Hopps
>>>>>>>>>> Sent: Wednesday, October 14, 2020 1= 1:15 PM
>>>>>>>>>> To: lsr@ietf.org
>>>>>>>>>> Cc: draft-ietf-lsr-ospf-pre= fix-originator@ietf.org;
>>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps
>>>>>>>>>> <chopps@chopps.org>
>>>>>>>>>> Subject: [Lsr] WG Last Call
>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originat= or-06
>>>>>>>>>>
>>>>>>>>>> This begins a 2 week WG Last Call, e= nding after Oct 29th, 2020, for:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/d
>>>>>>>>>> ra
>>>>>>>>>> ft-i
>>>>>>>>>> et
>>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!N= Et6yMaO-
>>>>>>> gk!TaSzQThghtCFOuYPS2VjLq
>>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHc= jkjClpk$
>>>>>>>>>>
>>>>>>>>>> The following IPR has been filed >>>>>>>>>>
>>>> https://urldefens= e.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
>>>>>>>>>> !NEt6yMaO-
>>>>>>>>>
>>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHc= z
>>>>>>>>>> 5KtUHQ$
>>>>>>>>>>
>>>>>>>>>> Authors,
>>>>>>>>>>
>>>>>>>>>> Please indicate to the list, your k= nowledge of any other IPR
>>>>>>>>>> related to this work.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Chris.
>>>>>>>>>
>>>>>>>>> _______________________________________= ________
>>>>>>>>> Lsr mailing list
>>>>>>>>> Lsr@ietf.org
>>>>>>>>> ht= tps://urldefense.com/v3/__https://www.ietf.org/mailman/listin
>>>>>>>>> fo
>>>>>>>>> /lsr
>>>>>>>>> __;!!NEt
>>>>>>>>> 6yMaO-
>>>>>>>>>
>>>>>>>
>>>>
>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm<= br> >>>>>>> w8
>>>>>>>>> Lc$
>>>>>>>>
>>>>>>>> ___________________________________________= ____
>>>>>>>> Lsr mailing list
>>>>>>>> Lsr@ietf.org
>>>>>>>> https://www.ietf.org/mailman= /listinfo/lsr
>>>>>>>
>>>>>>> _______________________________________________=
>>>>>>> Lsr mailing list
>>>>>>> Lsr@ietf.org
>>>>>>> https://www.ietf.org/mailman/lis= tinfo/lsr
>>>>>>
>>>>>> _______________________________________________
= >>>>>> Lsr mailing list
>>>>>> L= sr@ietf.org
>>>>>> https://www.ietf.org/mailman/listinf= o/lsr
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> Lsr@ietf.= org
>>>> https://www.ietf.org/mailman/listinfo/lsr=
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org<= /a>
>>> https://www.ietf.org/mailman/listinfo/lsr >
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
= --Apple-Mail-1290217C-36F7-477C-9AB5-4C5CD9529144-- From nobody Mon Oct 19 07:09:14 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37A03A0A7E; Mon, 19 Oct 2020 07:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=VT6/mnAK; dkim=pass (1024-bit key) header.d=juniper.net header.b=XFvCqgP9 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 h_pTRs3DiKxE; Mon, 19 Oct 2020 07:09:10 -0700 (PDT) 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 D7B753A0A8F; Mon, 19 Oct 2020 07:08:56 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09JE8ZfT013379; Mon, 19 Oct 2020 07:08:52 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=dAR6D8VbKRfy42OUVkx1H91wib5wFKlp/pak1p23o0E=; b=VT6/mnAKNcM08iCKKUnhgJVcawId1g+FbtTZqMlIGIS6AC3QLaBeefyjL1y6Tw3t5+RZ VR8AWFwXJz3nyp5XGzdT55It5j/HV6Qq91UU+F9xS2ehgQcX8qWtqN0BMF+0joxznyFP CCiRVz/wa3YbVmFWXZ3KISg/ytM/WMdF3VIAglINdXquQ8U15iyndvzQDpgOxQ+kv/nC H7Y51jLfgevKvLA6a2eTC4LdIGzWmK/GamCcDCKMOSRn0dBFVikKqN+QqPytqL2Qr80D ZpYXBRGTTr3SBeY4WpXZjZhMCZ9RNdTsmdLMxobvjxG/3pwJnjnZ3MXq5qh1SE5lJVmN 3A== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2175.outbound.protection.outlook.com [104.47.59.175]) by mx0a-00273201.pphosted.com with ESMTP id 347ympaf95-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 07:08:52 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hUwJz2zwSPi56suqUGPcDpAtyJAPocDRIlwzRVMd2vv1X9sCUkeSER1ksP0IihRErkVnHYrcFTKWyXaXPVHC6QF80UGuOlOGLx+JKw/9riZD9kauYwaQMVXlrpZ9D5whGPjgOo3d/3Hfnl1FkOOVHg0+gM0yn5OA6Ce2vJiV1qfIOp3lvVWN4xJDSkLG0GjInHiY/BqjLtg9i76Ikwtv1qIoZEySW+tLkD60CxyaO712GDBaw651pOabuMS2gTxzL6iq89b5IOlwPhzvdK6sgIx3T/kMA5greOVMM5dtsDRW117LTOsAjQnRsgxWXYk9wFqeFfmHnPogJhR5Y5QjfQ== 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=dAR6D8VbKRfy42OUVkx1H91wib5wFKlp/pak1p23o0E=; b=LliZHrPdqNq9sAeebAdrVzyw8jPSXuntYcDWf+w5QPTtVAeUcKtmJx+ql/Qab053bVgw2XzQmCsRwho2B+d8EbagrfaAp8iJuHyxCFLTQ8fQq8Kn9/0ZHjOpxOnrW+TXnMeNzAOkV2f4KfiP3FUo4dyjtBoDf7Lr4SFTkpt4XhA7Ytw3A1d5Oa+tTvcVst2XkVnQceXf4t54vlEMmKwsQQnOhc1NPxNYmdcTcG+mFmCWFr48mMOZI2VHxbm3Rk6sh1MVOv3EG/5Agt3INQYG02eqRTrA4RqzPGbVjRvpimKiGFNrNK2WLJaXJcgQaRFpFCmySA3cgKan5Dl1ub/5xg== 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=dAR6D8VbKRfy42OUVkx1H91wib5wFKlp/pak1p23o0E=; b=XFvCqgP9MBi74pClZmhL07BQSSRcCq2fMUbwWY8y1ofmKZITytSb8aPf4g6v/q1dB1nrCZm6hKxp38zS+wotjjy+2LKGqZ3mYLKFM0c+uRPlfWXoFJSloj+FBpZ7TSeZPIKUPHNaon6vZa0Jg5mCB1ilEZ9fiGXpe+fT+ZPfCAI= Received: from DM5PR05MB3388.namprd05.prod.outlook.com (2603:10b6:4:40::18) by DM6PR05MB4364.namprd05.prod.outlook.com (2603:10b6:5:a2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.15; Mon, 19 Oct 2020 14:08:48 +0000 Received: from DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865]) by DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865%7]) with mapi id 15.20.3499.015; Mon, 19 Oct 2020 14:08:48 +0000 From: John E Drake To: "Les Ginsberg (ginsberg)" , Aijun Wang , 'Christian Hopps' CC: "lsr-chairs@ietf.org" , "lsr@ietf.org" , 'Jeff Tantsura' , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWo8tCJIqrzId5sUmXrpGJFDH2DqmeMcAAgABE8gCAAA5ggIAAB1UAgABubBA= Date: Mon, 19 Oct 2020 14:08:47 +0000 Message-ID: References: <303E621F-47AA-4309-AC85-32A597604C7C@chopps.org> <00b401d6a5bc$ac44e800$04ceb800$@tsinghua.org.cn> <00ea01d6a5e6$54f371f0$feda55d0$@tsinghua.org.cn> 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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-19T14:08:43Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=07176a2d-0e7d-474b-b46c-bcfd857e7735; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 29eca1f5-4266-4265-6658-08d874387fb7 x-ms-traffictypediagnostic: DM6PR05MB4364: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HrLiLft4zxQLJ64iWGs+JuEtLisfw8m0Z7r70ALCjSd/dCXycP1amEz3540/avRrDsl3FMIzB0++RIKQa90Tr9xIqqeGi5AS4QbIXtKm+QTuG8RRFHZgqusxIBnz5eXMgNqWRDftyi1DgFjSGpX5D9qvJPa9YbZYKhlegy02bmgB8F42zIIC/m5kmrnWTveCrXkrH+falJ10M7oYuKllysP75KVQZvlT51yghqUvnj7XJcZuduPpSZCQ7xlG3AHH42yWqOhhCJ1DNuane/Fq4fqSrTrP0RjlSLHzrs5kR83MrBcy/EtSMS218O/J05yQzu7YoKAIRgKMTW0YTNx8vF3k4cAJ2lPRqvwNqIAn/o2kDqsopnkx0BYMUZET4DuTya23uYUNfkw5GJinD1h88w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3388.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(346002)(39860400002)(376002)(2906002)(83380400001)(8936002)(4326008)(186003)(66574015)(76116006)(26005)(316002)(7696005)(66476007)(66556008)(64756008)(66446008)(52536014)(66946007)(478600001)(55016002)(9686003)(966005)(71200400001)(53546011)(6506007)(54906003)(86362001)(8676002)(33656002)(5660300002)(110136005)(30864003)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: xLzNF5z/8xRlnhud2xBqUBn3MTgzmaSr6HpV+d8L1yKNeniOdsziu1h+mMWIQMA7NBLISPJMdXMaqdwI1HlAibZ3goEFdoB3T4+iFtgJiT+7I2coTOH8ckF9OespePVAgFdhqdsjXyxxtWfUcEL1ZXG/9PaNN2hEFN4boCXKo3yXS3phb5VXx6ExxAnpwMRpULD7pWWHkY3kjtwc2szIwgcCst8c9YOwZICfT8reyUO6cLr9FciU1iScBXa4xSMGLZuV2xZ6KFjdPgu3TEW/NKjt/29JrpDFNstbK/b/v1grFkBztHIvwKonAB1PHkCnTGnHg2wAkE2pPEtqsJrkQ+fx6Skbp7pYb9RjiqSVVT72Al1eMQzL6NX+OJHKD73WB830ot9mCxpsdcswMAiNQlEdFjSwR+kd4SE/Li1tWYiI+tRl707SOtyuG8Y7ywVV8+d0/8Kc/eIrwRWRJOQORPD4r3vEhphQD/JyLNJU6KXIkA9y6KPvQq5SJNf49giHYX626gL3RI+B+cGeOQtNcIccJ3Rba1VTsg5uyKf6ushW/uZ7LUrA8ow66gJm6En12sxbzDg147eXky9PEkVzZl3RSd9D3UscUjBNOL503E3rroBQHa6TG0SXkMtMFfk04wLjxwCf2Mxb+ucTLNwzgQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR05MB3388.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29eca1f5-4266-4265-6658-08d874387fb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 14:08:48.0192 (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: QEsyIdK0aK1FSbCE+59ZcKoWJxRixdPtbZrHflZHxtCJJsTOXy6LKMJequ+cHWOo8B6C6NUyBzunce05LmaLqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4364 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-19_06:2020-10-16, 2020-10-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 suspectscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 clxscore=1015 lowpriorityscore=0 adultscore=0 spamscore=0 impostorscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190097 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:09:14 -0000 SSBhZ3JlZSB3LyBMZXMsIHdobyBJIHRoaW5rIGhhcyBiZWVuIGV4dHJlbWVseSByZWFzb25hYmxl IHRocm91Z2hvdXQgdGhpcyBkaXNjdXNzaW9uLg0KDQpZb3VycyBJcnJlc3BlY3RpdmVseSwNCg0K Sm9obg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lz Y28uY29tPg0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMjAgMzozMiBBTQ0KPiBUbzog QWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj47ICdDaHJpc3RpYW4gSG9wcHMn DQo+IDxjaG9wcHNAY2hvcHBzLm9yZz4NCj4gQ2M6IEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlw ZXIubmV0PjsgbHNyLWNoYWlyc0BpZXRmLm9yZzsgbHNyQGlldGYub3JnOyAnSmVmZg0KPiBUYW50 c3VyYScgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVm aXgtDQo+IG9yaWdpbmF0b3JAaWV0Zi5vcmc7IGxzci1hZHNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UkU6IFtMc3JdIFdHIExhc3QgQ2FsbCBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5h dG9yLTA2DQo+IA0KPiBbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQo+ IA0KPiANCj4gQWlqdW4gLQ0KPiANCj4gSSBhbSBub3QgZ29pbmcgdG8gY29udGludWUgdGhlc2Ug c2lkZSBkaXNjdXNzaW9ucyB3aXRoIHlvdS4NCj4gDQo+IFRoZSBwcmltYXJ5IHB1cnBvc2Ugb2Yg dGhlIHByb3RvY29sIGV4dGVuc2lvbnMgYXJlIGFzIHN0YXRlZCBpbiB0aGUgZHJhZnQNCj4gSW50 cm9kdWN0aW9uLiBUaGlzIGlzIGFuYWxvZ291cyB0byB0aGUgdXNlIGNhc2VzIGZvciB0aGUgZXF1 aXZhbGVudCBleHRlbnNpb25zIGZvcg0KPiBJUy1JUyBhbHJlYWR5IGFwcHJvdmVkIGluIFJGQyA3 Nzk0LiBXZSBuZWVkIHRoZSBlcXVpdmFsZW50IGluIE9TUEYuDQo+IA0KPiBZb3UgY2FuIHNob3cg dGhhdCB5b3UgYXJlIGxpc3RlbmluZyB0byB0aGUgY29uY2VybnMgb2YgV0cgbWVtYmVycyBieQ0K PiByZW1vdmluZyB0aGUgQXBwZW5kaWNlcyAtIGluIHdoaWNoIGNhc2UgeW91IGhhdmUgKEkgYmVs aWV2ZSkgYnJvYWQgc3VwcG9ydCBmb3INCj4gbW92aW5nIHRoZSBkcmFmdCBmb3J3YXJkLg0KPiBZ b3UgY2FuIHRoZW4gd3JpdGUgYSBzZXBhcmF0ZSBkcmFmdCB0byBkaXNjdXNzIG90aGVyIHVzZSBj YXNlcyBhbmQgYWxsb3cgdGhlIFdHDQo+IHRvIGRpc2N1c3MgdGhvc2Ugb3RoZXIgdXNlIGNhc2Vz IHcvbyBwcmV2ZW50aW5nIHRoZSBleHRlbnNpb25zIGZyb20gYmVpbmcNCj4gYXBwcm92ZWQgYW5k IGRlcGxveWVkIGZvciB0aGUgdXNlIGNhc2VzIHdoaWNoIGhhdmUgYWxyZWFkeSBiZWVuDQo+IGRl bW9uc3RyYXRlZCBhcyB1c2VmdWwgYnkgSVMtSVMuDQo+IA0KPiBJZiB5b3UgcmVtb3ZlIHRoZSBB cHBlbmRpY2VzIEkgY2FuIHN1cHBvcnQgdGhlIGRyYWZ0Lg0KPiBJZiB5b3UgZG8gbm90IHJlbW92 ZSB0aGUgQXBwZW5kaWNlcyBJIGNhbm5vdCBzdXBwb3J0IHRoZSBkcmFmdC4NCj4gDQo+IFBsZWFz ZSBkaXNjdXNzIHRoaXMgd2l0aCB5b3VyIGNvLWF1dGhvcnMgYW5kIGNvbWUgdG8gY29uc2Vuc3Vz IG9uIHlvdXIgbmV4dA0KPiBzdGVwLg0KPiANCj4gICAgTGVzDQo+IA0KPiANCj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2lu Z2h1YS5vcmcuY24+DQo+ID4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDIwIDEyOjA2IEFN DQo+ID4gVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb20+OyAn Q2hyaXN0aWFuIEhvcHBzJw0KPiA+IDxjaG9wcHNAY2hvcHBzLm9yZz4NCj4gPiBDYzogJ0pvaG4g RSBEcmFrZScgPGpkcmFrZUBqdW5pcGVyLm5ldD47IGxzci1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4g bHNyQGlldGYub3JnOyAnSmVmZiBUYW50c3VyYScgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsN Cj4gPiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC0gb3JpZ2luYXRvckBpZXRmLm9yZzsgbHNy LWFkc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPiBk cmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4NCj4gPiBIaSwgTGVz Og0KPiA+DQo+ID4gQXMgSSBzdGF0ZWQgY2xlYXJseSBiZWZvcmUsIHRoZSBhcHBlbmRpeCBkZXNj cmliZWQgaW4gdGhlIGRyYWZ0IGlzIG5vdA0KPiA+IHRoZSBuZXcgdXNlIGNhc2UuIEl0IGlzIHRo ZSBzdGFydCBwb2ludCBvZiB0aGlzIGRyYWZ0Lg0KPiA+IEhhdmUgeW91IG5vdGljZWQgdGhhdCB0 aGUgaW50cm9kdWN0aW9uIHBhcnQgaXMgbm90IHRoZSBmaW5hbCB1c2FnZSBvZg0KPiA+IHN1Y2gg cHJvdG9jb2wgZXh0ZW5zaW9uIGluZm9ybWF0aW9uPw0KPiA+IENlcnRhaW5seSwgd2Ugd2lsbCBu b3QgZXhwYW5kIGFsbCB0aGUgcG9zc2libGUgdXNlIGNhc2VzIGluIHZlcnkNCj4gPiBkZXRhaWws IGJ1dCBwdXR0aW5nIHNvbWUgb2YgdGhlbShzb21lIGludGVyZXN0aW5nLCBwcm9taW5lbnQgdXNl DQo+ID4gY2FzZXMpIGluIHRoZSBhcHBlbmRpeCB3aWxsIG5vdCBoYW1wZXIgdGhlIHByb3RvY29s IGV4dGVuc2lvbiBpdHNlbGYuDQo+ID4NCj4gPiBJZiB0aGUgc3RhdGVtZW50cy9kZXNjcmlwdGlv bnMgaW4gdGhlIGFwcGVuZGl4IGFyZSBub3QgY29ycmVjdCwgd2UgY2FuDQo+ID4gZml4IGl0LCBv ciByZW1vdmUgaXQgZmluYWxseS4gIElmIG5vdCwgd2h5IG5vdCBsZXQgaXQgYmUgZm9yIHJlZmVy ZW5jZQ0KPiA+IHRvIHRoZSB1c2VyIG9mIHN1Y2ggcHJvdG9jb2wgZXh0ZW5zaW9uPw0KPiA+IEZv ciB0aGUgYm9keSBwYXJ0IG9mIHRoaXMgZHJhZnQsIHdlIGFyZSBhbHNvIHdlbGNvbWUgY29tbWVu dHMuDQo+ID4NCj4gPiBNb3JlIHJlcGxpZXMgaW5saW5lIGJlbG93W1dBSl0NCj4gPg0KPiA+IEJl c3QgUmVnYXJkcw0KPiA+DQo+ID4gQWlqdW4gV2FuZw0KPiA+IENoaW5hIFRlbGVjb20NCj4gPg0K PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbHNyLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gTGVz IEdpbnNiZXJnIChnaW5zYmVyZykNCj4gPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMjAg MjoxNSBQTQ0KPiA+IFRvOiBBaWp1biBXYW5nIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPjsg J0NocmlzdGlhbiBIb3BwcycNCj4gPiA8Y2hvcHBzQGNob3Bwcy5vcmc+DQo+ID4gQ2M6ICdKb2hu IEUgRHJha2UnIDxqZHJha2VAanVuaXBlci5uZXQ+OyBsc3ItY2hhaXJzQGlldGYub3JnOyAnTGVz DQo+ID4gR2luc2JlcmcgKGdpbnNiZXJnKScgPGdpbnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmll dGYub3JnPjsNCj4gPiBsc3JAaWV0Zi5vcmc7ICdKZWZmIFRhbnRzdXJhJyA8amVmZnRhbnQuaWV0 ZkBnbWFpbC5jb20+Ow0KPiA+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LSBvcmlnaW5hdG9y QGlldGYub3JnOyBsc3ItYWRzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExh c3QgQ2FsbA0KPiA+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4g Pg0KPiA+IEFpanVuIC0NCj4gPg0KPiA+IFRoZSAidXNlIGNhc2UiIGZvciB0aGUgcHJvdG9jb2wg ZXh0ZW5zaW9ucyBpcyBjbGVhcmx5IHN0YXRlZCBpbiB0aGUNCj4gPiBJbnRyb2R1Y3Rpb246DQo+ ID4NCj4gPiAiVGhlIHByaW1hcnkgdXNlIGNhc2UgZm9yIHRoZSBleHRlbnNpb25zIHByb3Bvc2Vk IGluIHRoaXMgZG9jdW1lbnQgaXMNCj4gPiAgICB0byBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZSBv cmlnaW5hdG9yIG9mIHRoZSBwcmVmaXggaW4gdGhlIG5ldHdvcmsuDQo+ID4gICAgSW4gY2FzZXMg d2hlcmUgbXVsdGlwbGUgcHJlZml4ZXMgYXJlIGFkdmVydGlzZWQgYnkgYSBnaXZlbiByb3V0ZXIs IGl0DQo+ID4gICAgaXMgYWxzbyB1c2VmdWwgdG8gYmUgYWJsZSB0byBhc3NvY2lhdGUgYWxsIHRo ZXNlIHByZWZpeGVzIHdpdGggYQ0KPiA+ICAgIHNpbmdsZSByb3V0ZXIgZXZlbiB3aGVuIHByZWZp eGVzIGFyZSBhZHZlcnRpc2VkIG91dHNpZGUgb2YgdGhlIGFyZWENCj4gPiAgICBpbiB3aGljaCB0 aGV5IG9yaWdpbmF0ZWQuICBJdCBhbHNvIGhlbHBzIHRvIGRldGVybWluZSB3aGVuIHRoZSBzYW1l DQo+ID4gICAgcHJlZml4IGlzIGJlaW5nIG9yaWdpbmF0ZWQgYnkgbXVsdGlwbGUgcm91dGVycyBh Y3Jvc3MgYXJlYXMuIg0KPiA+DQo+ID4gVGhpcyBpcyBlcXVpdmFsZW50IHRvIGxhbmd1YWdlIGlu IFJGQyA3Nzk0IHdoaWNoIGRlZmluZXMgdGhlIGFuYWxvZ291cw0KPiA+IGV4dGVuc2lvbnMgZm9y IElTLUlTLg0KPiA+DQo+ID4gRXZlcnl0aGluZyB5b3UgaGF2ZSBpbiB0aGUgQXBwZW5kaXggaXMg bm90IHJlbGF0ZWQgdG8gdGhlIHByaW1hcnkgdXNlDQo+ID4gY2FzZSAtIGFuZCBpcyBmYWN0IGEg dXNlIGNhc2Ugd2hpY2ggbWFueSBvZiB1cyBoYXZlIG9iamVjdGVkIHRvLg0KPiA+IFtXQUpdIFZl cnkgZ2xhZCB0byBrbm93IHRoZSBmYWxzZSBzdGF0ZW1lbnRzIGluIHRoZSBhcHBlbmRpeC4NCj4g Pg0KPiA+IFlvdSBhcmUgZW50aXRsZWQgdG8gd3JpdGUgYW5vdGhlciBkcmFmdCBhZHZvY2F0aW5n IGZvciB5b3VyIG5ldyB1c2UNCj4gPiBjYXNlIGlmIHlvdSB3aXNoLCBidXQgcmVxdWlyaW5nIHRo YXQgdGhlIHByb3RvY29sIGV4dGVuc2lvbnMgaW4NCj4gPiBzdXBwb3J0IG9mIHRoZSBwcmltYXJ5 IHVzZSBjYXNlIG5vdCBnbyBmb3J3YXJkIHdpdGhvdXQgeW91ciBuZXcgdXNlDQo+ID4gY2FzZSBp cyAtIGFzIENocmlzIGhhcyBzdGF0ZWQgdmVyeSBjbGVhcmx5IC0gaG9sZGluZyBhcHByb3ZhbCBv ZiB0aGUNCj4gPiBwcm90b2NvbCBleHRlbnNpb25zIGhvc3RhZ2UgdG8geW91ciBuZXcgdXNlIGNh c2UuDQo+ID4gW1dBSl0gSXQgaXMgbm90IG5ldyB1c2UgY2FzZS4gQXMgSSBzYXRlZCBiZWZvcmUs IEkgYW0gb3BlbiB0byB0aGlzDQo+ID4gcGFydCwgYnV0IHNob3VsZCBvbiB0aGUgY29uZGl0aW9u cyB0aGF0IHRoZSBzdGF0ZW1lbnRzIGluIHRoaXMgcGFydCBhcmUNCj4gaW5jb3JyZWN0Lg0KPiA+ DQo+ID4gSSBhbSBhc2tpbmcgeW91ICh5ZXQgYWdhaW4pIG5vdCB0byBkbyB0aGlzLg0KPiA+DQo+ ID4gSSBjYW5ub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQgbW92aW5nIGZvcndhcmQgd2l0aCB0aGUg Y29udGVudCBpbiB0aGUNCj4gPiBBcHBlbmRpY2VzIGluY2x1ZGVkLg0KPiA+IFtXQUpdIFdvdWxk IGxpa2UgdG8gaGVhciBtb3JlIHRlY2huaWNhbCBhbmFseXNpcy4NCj4gPg0KPiA+ICAgIExlcw0K PiA+DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBM c3IgPGxzci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KPiA+ID4g U2VudDogU3VuZGF5LCBPY3RvYmVyIDE4LCAyMDIwIDc6MDggUE0NCj4gPiA+IFRvOiAnQ2hyaXN0 aWFuIEhvcHBzJyA8Y2hvcHBzQGNob3Bwcy5vcmc+DQo+ID4gPiBDYzogJ0pvaG4gRSBEcmFrZScg PGpkcmFrZUBqdW5pcGVyLm5ldD47IGxzci1jaGFpcnNAaWV0Zi5vcmc7ICdMZXMNCj4gPiA+IEdp bnNiZXJnIChnaW5zYmVyZyknIDxnaW5zYmVyZz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47 DQo+ID4gPiBsc3JAaWV0Zi5vcmc7ICdKZWZmIFRhbnRzdXJhJyA8amVmZnRhbnQuaWV0ZkBnbWFp bC5jb20+Ow0KPiA+ID4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtIG9yaWdpbmF0b3JAaWV0 Zi5vcmc7IGxzci1hZHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0 IENhbGwNCj4gPiA+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4g PiA+DQo+ID4gPiBIaSwgQ2hyaXM6DQo+ID4gPg0KPiA+ID4gSSB0aGluayB3ZSBoYXZlICJwdXQg dGhlIGNhcnQgYmVmb3JlIHRoZSBob3JzZSIuIEZvciBwcm90b2NvbA0KPiA+ID4gZXh0ZW5zaW9u IGRyYWZ0LCB0aGUgb3JpZ2luIGlzIHRoZSB1c2UgY2FzZS4NCj4gPiA+IEFuZCBJIHRoaW5rIHdl IHdpbGwgbm90IGV4cGFuZCBPU1BGIHByb3RvY29sLCBqdXN0IGJlY2F1c2UgaXQgbGFjaw0KPiA+ ID4gc29tZXRoaW5nIGFzIGNvbXBhcmVkIHdpdGggSVNJUywgcmlnaHQ/DQo+ID4gPg0KPiA+ID4g QXMgSSBzdGF0ZWQgYmVmb3JlLCB0aGUgdXNlIGNhc2UgaW4gY3VycmVudCBhcHBlbmRpeCBpcyB0 aGUgbWFpbg0KPiA+ID4gbW90aXZhdGlvbiBvZiB0aGlzIGRyYWZ0LCB5b3UgY2FuIHNlZSB0aGlz IGluIG1haW4gYm9keSBvZiB0aGUNCj4gPiA+IGVhcmxpZXIgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0 KGZyb20gdmVyc2lvbiAwIHRvIHZlcnNpb24gNSkuDQo+ID4gPiBUaGUgcmVhc29uIHRoYXQgd2Ug bW92ZSB0aGlzIHBhcnQgdG8gdGhlIGFwcGVuZGl4LCBhcyB0aGF0IHlvdSBzYWlkLA0KPiA+ID4g aXMgdG8gbGV0IHBlcnNvbiBmb2N1cyBvbiB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9uIGl0c2VsZi4N Cj4gPiA+DQo+ID4gPiBNb3ZpbmcgdGhpcyBwYXJ0IHRvIGFwcGVuZGl4IGlzIGFjY2VwdGFibGUs IGJ1dCByZW1vdmluZyBpdCBmcm9tIHRoZQ0KPiA+ID4gZHJhZnQgd2lsbCBlcmFzZSB0aGUgb3Jp Z2luIG9mIHRoaXMgZG9jdW1lbnQuDQo+ID4gPiBJcyBpdCByZWFzb25hYmxlIHRoYXQgb25lIGRv Y3VtZW50IGRpc2N1c3NlcyB0aGUgIm9yaWdpbiIob2YgdGhlDQo+ID4gPiBwcmVmaXgpLCBjYW4n dCBrZWVwIGl0cyBvcmlnaW4/DQo+ID4gPg0KPiA+ID4gTW9yZSByZXBsaWVzIGlubGluZSBiZWxv d1tXQUpdLg0KPiA+ID4NCj4gPiA+IEJlc3QgUmVnYXJkcw0KPiA+ID4NCj4gPiA+IEFpanVuIFdh bmcNCj4gPiA+IENoaW5hIFRlbGVjb20NCj4gPiA+DQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+ID4gT2YgQ2hyaXN0aWFuIEhvcHBz DQo+ID4gPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMjAgMTA6NDcgUE0NCj4gPiA+IFRv OiDnjovniLHkv4ogPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+DQo+ID4gPiBDYzogSm9obiBF IERyYWtlIDxqZHJha2VAanVuaXBlci5uZXQ+OyBDaHJpc3RpYW4gSG9wcHMNCj4gPiA+IDxjaG9w cHNAY2hvcHBzLm9yZz47IGxzci1jaGFpcnNAaWV0Zi5vcmc7IExlcyBHaW5zYmVyZyAoZ2luc2Jl cmcpDQo+ID4gPiA8Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+OyBsc3JAaWV0 Zi5vcmc7IEplZmYgVGFudHN1cmENCj4gPiA+IDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT47DQo+ ID4gPiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnOyBsc3It IGFkc0BpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+ ID4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+ID4NCj4gPiA+ IElzbid0IHRoaXMganVzdCBhZGRpbmcgYW4gYW5hbG9nb3VzIGV4dGVuc2lvbiB0aGF0IGFscmVh ZHkgZXhpc3RzIGluIFJGQzc3OTQ/DQo+ID4gPiBbV0FKXSBOby4gUkZDNzc5NCBpcyBqdXN0IG9u ZSBleGFtcGxlIHRoYXQgdG8gaWxsdXN0cmF0ZSwgYXMgdGhlDQo+ID4gPiBjb21wYW5pb24gSUdQ IHByb3RvY29sLCBPU1BGIGNhbiBhbHNvIGFjY29tcGxpc2ggdGhpcy4gQW5kLA0KPiA+ID4gYWN0 dWFsbHksIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBjb25zaWRlcmF0aW9uIGluIHRoaXMgZHJhZnQg Zm9yIHRoZSBwcm90b2NvbA0KPiBleHRlbnNpb24uDQo+ID4gPg0KPiA+ID4gSSBkb24ndCB0aGlu ayB3ZSBuZWVkIHRvIGRvIGEgbG90IG9mIGNvbnZpbmNpbmcgYXQgdGhpcyBwb2ludC4gSQ0KPiA+ ID4gYWdyZWUgd2l0aCBMZXMsIGlmIHlvdSB3YW50IHRvIHRhbGsgYWJvdXQgdXNlIGNhc2VzIChl c3BlY2lhbGx5IG9uZXMNCj4gPiA+IHRoYXQgYXJlIGNvbnRyb3ZlcnNpYWwhKSB0aGVuIHRoZSBj b3JyZWN0IHBsYWNlIGZvciB0aGF0IGlzIGluIGEgbmV3DQo+ID4gPiBpbmZvcm1hdGl2ZQ0KPiA+ IGRyYWZ0Lg0KPiA+ID4gW1dBSl0gd2UgaGF2ZSBkaXNjdXNzZWQgdGhlIHVzZSBjYXNlIGJlZm9y ZSBhbmQgc3RhdGUgdGhlIGRpc2N1c3Npb24NCj4gPiA+IHJlc3VsdHMgYXQgdGhlIGFwcGVuZGl4 IHBhcnQuIFdlIHdpbGwgbm90IGVtcGhhc2lzIGFuZCBleHBhbmQgdGhlDQo+ID4gPiB1c2UgY2Fz ZSBtb3JlLiBJZiBvbmUgZG9lcyBub3QgYWdyZWUgdGhlIHN0YXRlbWVudCBvZiB0aGlzIGFwcGVu ZGl4LA0KPiA+ID4gd2UgY2FuIGRpc2N1c3Mgb25saW5lIG9yIG9mZmxpbmUuIFdlIGp1c3QgbmVl ZCB0byBtYWtlIHRoZSBzdGF0ZW1lbnQNCj4gPiA+IGluDQo+ID4gYXBwZW5kaXggaXMgY29ycmVj dC4NCj4gPiA+DQo+ID4gPiBPdGhlcndpc2UsIGVzcGVjaWFsbHkgaWYgdGhlIGNhc2VzIGFyZSBj b250cm92ZXJzaWFsLCB0aGlzIGNhbiBiZQ0KPiA+ID4gc2VlbiBhcyBkb2luZyBhbiAiZW5kLXJ1 biIgdG8gYXZvaWQgdGhlIGRlYmF0ZSBiL2MgcGVvcGxlIHdhbnQgdGhlDQo+ID4gPiBleHRlbnNp b24sIGJ1dCBtYXliZSBkb24ndCBhZ3JlZSB3aXRoIHlvdXIgdXNlIGNhc2UuDQo+ID4gPiBbV0FK XSBPbmUgc2hvdWxkIHBvaW50IG91dCB3aGljaCBzdGF0ZW1lbnQgaW4gdGhlIGFwcGVuZGl4IGlz DQo+ID4gPiBjb250cm92ZXJzaWFsLCB3ZSBjYW4gY29ycmVjdCBpdC4gVGhpcyB1c2UgY2FzZSBp cyB0aGUgb3JpZ2luIG9mDQo+ID4gPiB0aGlzIGRyYWZ0LCBub3QgdGhlIHJlc3VsdHMuDQo+ID4g Pg0KPiA+ID4gTGVnaXNsYXRvcnMgZG8gdGhpcyBzb21ldGltZXMgYWRkaW5nIHRoaW5ncyB0aGV5 IHdhbnQgcGVyc29uYWxseSB0bw0KPiA+ID4gcG9wdWxhciBiaWxscywgdGhhdCBvdGhlciBwZW9w bGUgbWF5IG5vdCB3YW50LCBidXQgc2luY2UgcGVvcGxlIHdhbnQNCj4gPiA+IHRoZSBtYWluIGJp bGwgdGhleSB2b3RlIGZvciBpdCBhbnl3YXksIGluIHRoZSBVUyBpdCdzIGNhbGxlZCAiYWRkaW5n DQo+ID4gPiBwb3JrIiBvciAicG9yayBiYXJyZWwgcG9saXRpY3MiLiA6KSBbV0FKXSBUaGUgYXBw ZW5kaXggaXMgbm90IGFkZGVkDQo+ID4gPiBsYXRlciwgYnV0IGV4aXN0IGF0IHRoZSBmaXJzdCBi ZWdpbm5pbmcuIFRoaXMgaXMgdGhlIG9yaWdpbiBvZiB0aGUNCj4gPiA+IGJpbGxzLg0KPiA+ID4N Cj4gPiA+IFRoYW5rcywNCj4gPiA+IENocmlzLg0KPiA+ID4NCj4gPiA+ID4gT24gT2N0IDE2LCAy MDIwLCBhdCAxMDozNyBBTSwg546L54ix5L+KIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPg0K PiA+ID4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEhpLCBDaHJpczoNCj4gPiA+ ID4gT3JpZ2luYWxseSwgdGhlIGFwcGVuZGl4IHBhcnQgaXMgd2l0aGluIHRoZSBkb2N1bWVudCwg d2hpY2ggaXMgdGhlDQo+ID4gPiA+IHN0YXJ0DQo+ID4gPiBwb2ludC9tYWluIG1vdGl2YXRpb24g dG8gZXh0ZW5kIHRoZSBwcmVmaXggb3JpZ2luLg0KPiA+ID4gPiBUaGVyZSBtYXkgZXhpc3RzIG90 aGVyIHVzYWdlcyBvZiB0aGlzIGluZm9ybWF0aW9uLiBQYWNrIHRoZXNlDQo+ID4gPiA+IGV4YW1w bGVzDQo+ID4gPiBpbnRvIHNvbWUgc2hvcnQgc2VudGVuY2VzIG9yIGludHJvZHVjdGlvbiBpcyB2 aWFibGUsIGJ1dCBleHBhbmQgc29tZQ0KPiA+ID4gb2YgdGhlbSBpcyBhbHNvIGhlbHBmdWwuDQo+ ID4gPiA+IEFzIEkga25vd24sIHdoZW4gd2Ugd2FudCB0byBkbyBwcm90b2NvbCBleHRlbnNpb24s IHdlIHNob3VsZA0KPiA+ID4gPiBhbHdheXMNCj4gPiA+IGNvbnZpbmNlIG90aGVyIHRoZSByZWFz b24vbW90aXZhdGlvbi9wcm9zcGVjdHMgdG8gZG8gc28uIE9uIHRoZQ0KPiA+ID4gb3RoZXIgaGFu ZCwgdGhlIHVzZSBjYXNlIGRlc2NyaWJlZCBpbiB0aGUgY3VycmVudCBhcHBlbmRpeCBpcyB2ZXJ5 DQo+ID4gPiBwcm9taW5lbnQgZm9yIG9wZXJhdG9yIHRvIGFjY29tcGxpc2ggdGhlIFRFIHRhc2sg aW4gbXVsdGktYXJlYSBlbnZpcm9ubWVudC4NCj4gPiA+ID4NCj4gPiA+ID4gQWlqdW4gV2FuZw0K PiA+ID4gPg0KPiA+ID4gPiDlnKgyMDIwLTEwLTE277yMQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9w cHNAY2hvcHBzLm9yZyZndDvlhpnpgZM6DQo+ID4gPiA+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0N Cj4gPiA+ID4g5Y+R5Lu25Lq677yaIENocmlzdGlhbiBIb3BwcyAmbHQ7Y2hvcHBzQGNob3Bwcy5v cmcmZ3Q7DQo+ID4gPiA+IOWPkeS7tuaXtumXtDogMjAyMOW5tDEw5pyIMTbml6Ug5pif5pyf5LqU DQo+ID4gPiA+IOWGmemBkzogWyZxdW90O0xlcyBHaW5zYmVyZyAoZ2luc2JlcmcpJnF1b3Q7DQo+ ID4gPiA+ICZsdDtnaW5zYmVyZz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyZndDtdDQo+ID4g PiA+IOS4u+mimO+8miBSZTogW0xzcl0gV0cgTGFzdCBDYWxsDQo+ID4gPiA+IGRyYWZ0LWlldGYt bHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gPiA+ID4NCj4gPiA+ID4gPiBPbiBPY3Qg MTYsIDIwMjAsIGF0IDE6NTEgQU0sIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQo+ID4gPiA8Z2lu c2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gQWlqdW4gLQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhlIHBvaW50IEkgYW0gbWFraW5n IGlzIHZlcnkgZm9jdXNlZC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoaXMgZHJhZnQgaXMgZGVm aW5pbmcgYSBwcm90b2NvbCBleHRlbnNpb24uIEFzIHN1Y2ggaXQgaXMNCj4gPiA+ID4gPiBuZWNl c3NhcnkgdGhhdCB0aGlzDQo+ID4gPiBiZSBTdGFuZGFyZHMgdHJhY2sgYXMgYWRoZXJpbmcgdG8g dGhlIG5vcm1hdGl2ZSBzdGF0ZW1lbnRzIGluIHRoZQ0KPiA+ID4gZHJhZnQgYXJlIG5lY2Vzc2Fy eSBmb3IgaW50ZXJvcGVyYWJpbGl0eS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdoYXQgaXMgZGlz Y3Vzc2VkIGluIHRoZSBBcHBlbmRpeCBpcyBhIHVzZSBjYXNlLiBJdCBpcyBub3QNCj4gPiA+ID4g PiBub3JtYXRpdmUgYW5kDQo+ID4gPiB0aGVyZSBhcmUgc3Ryb25nIG9waW5pb25zIG9uIGJvdGgg c2lkZXMgYXMgdG8gd2hldGhlciB0aGlzIGlzIGFuDQo+ID4gPiBhcHByb3ByaWF0ZSB1c2UgY2Fz ZSBvciBub3QuDQo+ID4gPiA+ID4gSW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkcmFmdCwgSSBoYXZl IG5vIGludGVyZXN0IGluIHRyeWluZyB0bw0KPiA+ID4gPiA+IHJlc29sdmUgb3VyDQo+ID4gPiBk aWZmZXJlbmNlIG9mIG9waW5pb24gb24gdGhpcyB1c2UgY2FzZS4gSSBzaW1wbHkgd2FudCB0aGUg cHJvdG9jb2wNCj4gPiA+IGV4dGVuc2lvbiB0byBtb3ZlIGZvcndhcmQgc28gdGhhdCB3ZSBoYXZl IGFub3RoZXIgdG9vbCBhdmFpbGFibGUuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJZiB5b3Ugd2Fu dCB0byB3cml0ZSBhIGRyYWZ0IG9uIHRoZSB1c2UgY2FzZSBkaXNjdXNzZWQgaW4gdGhlDQo+ID4g PiA+ID4gQXBwZW5kaXgNCj4gPiA+IHBsZWFzZSBmZWVsIGZyZWUgdG8gZG8gc28uIFRoYXQgZHJh ZnQgbWF5IHZlcnkgd2VsbCBub3QgYmUgbm9ybWF0aXZlDQo+ID4gPiAtIEluZm9ybWF0aW9uYWwg b3IgQkNQIG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlIC0gYmVjYXVzZSBpdCB3aWxsIGJlDQo+ID4g PiBkaXNjdXNzaW5nIGEgZGVwbG95bWVudCBzY2VuYXJpbyBhbmQgYSBwcm9wb3NhbCB0byB1c2Ug ZGVmaW5lZA0KPiA+ID4gcHJvdG9jb2wgZXh0ZW5zaW9ucyBhcyBvbmUgd2F5IHRvIHNvbHZlIHBy b2JsZW1zIGluIHRoYXQgZGVwbG95bWVudA0KPiA+ID4gc2NlbmFyaW8uIFN1Y2ggYSBkcmFmdCBt aWdodCBhbHNvIGJlIG1vcmUgYXBwcm9wcmlhdGUgaW4gYW5vdGhlciBXRw0KPiA+ID4gKGUuZy4s IFRFQVMpLiBUaGUgbWVyaXRzIG9mIHVzaW5nIHByZWZpeCBhZHZlcnRpc2VtZW50cyB0byBidWls ZCBhDQo+ID4gPiB0b3BvbG9neQ0KPiA+IGNvdWxkIHRoZW4gYmUgZGlzY3Vzc2VkIG9uIGl0cyBv d24uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBQbGVhc2UgZG8gbm90IHRyeSB0byBhdm9pZCBoYXZp bmcgYSBmdWxsIGRpc2N1c3Npb24gb2YgdGhlDQo+ID4gPiA+ID4gbWVyaXRzIG9mIHVzaW5nDQo+ ID4gPiBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgdG8gZGVyaXZlIHRvcG9sb2d5IGJ5IGFkZGluZyBp dCB0byBhIGRyYWZ0DQo+ID4gPiB0aGF0IGlzIChhbmQgc2hvdWxkIGJlKSBmb2N1c2VkIG9uIHNp bXBsZSBwcm90b2NvbCBleHRlbnNpb25zLg0KPiA+ID4gPg0KPiA+ID4gPiBbQXMgV0cgbWVtYmVy XQ0KPiA+ID4gPg0KPiA+ID4gPiBJIGZpbmQgdGhpcyB2ZXJ5IGNvbXBlbGxpbmcgYW5kIHNvIHN1 cHBvcnQgdGhlIHJlbW92YWwgb2YgdGhlDQo+ID4gPiA+IHJlZmVycmVkIHRvDQo+ID4gPiBub24t bm9ybWF0aXZlIGFwcGVuZGljZXMuDQo+ID4gPiA+DQo+ID4gPiA+IFRoYW5rcywNCj4gPiA+ID4g Q2hyaXMuDQo+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGFueC4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+ICAgTGVzDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+PiBGcm9tOiBBaWp1biBXYW5nIDx3YW5nYWlq dW5AdHNpbmdodWEub3JnLmNuPg0KPiA+ID4gPiA+PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAx NSwgMjAyMCA2OjUxIFBNDQo+ID4gPiA+ID4+IFRvOiAnSmVmZiBUYW50c3VyYScgPGplZmZ0YW50 LmlldGZAZ21haWwuY29tPjsgJ0pvaG4gRSBEcmFrZScNCj4gPiA+ID4gPj4gPGpkcmFrZUBqdW5p cGVyLm5ldD4NCj4gPiA+ID4gPj4gQ2M6ICdDaHJpc3RpYW4gSG9wcHMnIDxjaG9wcHNAY2hvcHBz Lm9yZz47IGxzci1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4gPiA+ID4+IExlcyBHaW5zYmVyZw0KPiA+ ID4gPiA+PiAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb20+OyBsc3JAaWV0Zi5vcmc7DQo+ ID4gPiA+ID4+IGxzci1hZHNAaWV0Zi5vcmc7DQo+ID4gPiA+ID4+IGRyYWZ0LWlldGYtIGxzci1v c3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnDQo+ID4gPiA+ID4+IFN1YmplY3Q6IFJFOiBb THNyXSBXRyBMYXN0IENhbGwNCj4gPiA+ID4gPj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgt b3JpZ2luYXRvci0wNg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBIaSwgTGVzLCBKb2huIGFuZCBK ZWZmOg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBMZXQncyByZXBseSB5b3UgYWxsIHRvZ2V0aGVy Lg0KPiA+ID4gPiA+PiBJbiBteSBQT1YsIFRoZSBzdGFuZGFyZCBkb2N1bWVudCBzaG91bGQgbm90 IGRlZmluZSBzb2xlbHkgdGhlDQo+ID4gPiA+ID4+IHByb3RvY29sIGV4dGVuc2lvbiwgYnV0IHRo ZWlyIHVzYWdlcyBpbiB0aGUgbmV0d29yayBkZXBsb3ltZW50Lg0KPiA+ID4gPiA+PiBBcyBJIGtu b3duLCBhbG1vc3QgYWxsIHRoZSBJRVRGIGRvY3VtZW50cyBmb2xsb3dpbmcgdGhpcyBzdHlsZS4N Cj4gPiA+ID4gPj4gQW5kLCBiZWZvcmUgYWRvcHRpbmcgb25lIHdvcmssIHdlIGhhdmUgb2Z0ZW4g aW50ZW5zZSBkaXNjdXNzaW9uDQo+ID4gPiA+ID4+IGZvciB3aGF0J3MgdGhlaXIgdXNhZ2VzLg0K PiA+ID4gPiA+PiBTdWNoIGRpc2N1c3Npb24gaW4gdGhlIG1haWwgbGlzdCBhbmQgc3RhdGVtZW50 cyBpbiB0aGUgZG9jdW1lbnQNCj4gPiA+ID4gPj4gY2FuIGNlcnRhaW5seSBhc3Npc3QgdGhlIHJl YWRlci91c2VyIG9mIHRoZSBkb2N1bWVudCBnZXQgdGhlDQo+ID4gPiA+ID4+IGVzc2VuY2Ugb2Yg dGhlIHN0YW5kYXJkLCBhbmQgZm9sbG93IHRoZW0gdW5hbWJpZ3VvdXNseS4NCj4gPiA+ID4gPj4N Cj4gPiA+ID4gPj4gUmVnYXJkaW5nIHRoZSBjb250ZW50cyBvZiBhcHBlbmRpY2VzLCBhcyBzdGF0 ZWQgaW4gdGhlIHNlY3Rpb24sDQo+ID4gPiA+ID4+ICJUaGUgQXBwZW5kaXggQSBoZXVyaXN0aWMg dG8gcmVidWlsZCB0aGUgdG9wb2xvZ3kgY2FuIG5vcm1hbGx5DQo+ID4gPiA+ID4+IGJlIHVzZWQg aWYgYWxsIGxpbmtzIGFyZSBudW1iZXJlZC4iIEkgdGhpbmsgdGhpcyBjYW4gYXBwbHkNCj4gPiA+ ID4gPj4gYWxtb3N0IG1vc3Qgb2YgdGhlIG9wZXJhdG9yJ3MgbmV0d29yaywgYW5kIGZhY2lsaXRh dGUgdGhlDQo+ID4gPiA+ID4+IGludGVyLWFyZWEgVEUgcGF0aCBjYWxjdWxhdGlvbiBmb3IgY2Vu dHJhbCBjb250cm9sbGVyLCBvciBldmVuDQo+ID4gPiA+ID4+IGZvciB0aGUgaGVhZC1lbmQgcm91 dGVyIHRoYXQgbG9jYXRlZCBpbiBvbmUgYXJlYSB0aGF0IGRpZmZlcmVudCBmcm9tIHRoZQ0KPiB0 YWlsLSBlbmQgcm91dGVyLg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBLZWVwaW5nIHRoZSBjb250 ZW50cyBvZiBhcHBlbmRpY2VzIGRvZXMgbm90IGhhdmUgdGhlIG5lZ2F0aXZlDQo+ID4gPiA+ID4+ IGltcGFjdCBvZiB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9uLCBpdCBpcyBqdXN0IG9uZSByZWZlcmVu Y2UgZm9yDQo+ID4gPiA+ID4+IHRoZSB1c2FnZSBvZiB0aGlzIGV4dGVuc2lvbi4NCj4gPiA+ID4g Pj4gT25lIGNhbiBzZWxlY3Qgbm90IHJlZmVyIHRvIGl0LCBpZiB0aGVpciBuZXR3b3JrcyBhcmUg ZGVwbG95ZWQNCj4gPiA+ID4gPj4gd2l0aCBsYXJnZSBhbW91bnQgb2YgdW5udW1iZXJlZCBsaW5r cy4gQnV0IGZvciBvdGhlcnMsIHRoZQ0KPiA+ID4gPiA+PiBoZXVyaXN0aWMNCj4gPiBhcHBsaWVz Lg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBCZXN0IFJlZ2FyZHMNCj4gPiA+ID4gPj4NCj4gPiA+ ID4gPj4gQWlqdW4gV2FuZw0KPiA+ID4gPiA+PiBDaGluYSBUZWxlY29tDQo+ID4gPiA+ID4+DQo+ ID4gPiA+ID4+DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gPiA+ID4+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHNyLWJv dW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gPiA+ID4+IEJlaGFsZiBPZiBKZWZmIFRhbnRzdXJhDQo+ ID4gPiA+ID4+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNiwgMjAyMCA1OjI4IEFNDQo+ID4gPiA+ ID4+IFRvOiBKb2huIEUgRHJha2UgPGpkcmFrZT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3Jn Pg0KPiA+ID4gPiA+PiBDYzogQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz47IGxz ci1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4gPiA+ID4+IExlcyBHaW5zYmVyZw0KPiA+ID4gPiA+PiAo Z2luc2JlcmcpIDxnaW5zYmVyZz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47IGxzckBpZXRm Lm9yZzsNCj4gPiA+ID4gPj4gbHNyLSBhZHNAaWV0Zi5vcmc7DQo+ID4gPiA+ID4+IGRyYWZ0LWll dGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmcNCj4gPiA+ID4gPj4gU3ViamVj dDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+ID4gPiA+PiBkcmFmdC1pZXRmLWxzci1vc3Bm LXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ICsxDQo+ID4gPiA+ ID4+DQo+ID4gPiA+ID4+IFJlZ2FyZHMsDQo+ID4gPiA+ID4+IEplZmYNCj4gPiA+ID4gPj4NCj4g PiA+ID4gPj4+IE9uIE9jdCAxNSwgMjAyMCwgYXQgMTE6MzMsIEpvaG4gRSBEcmFrZQ0KPiA+ID4g PiA+PiA8amRyYWtlPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ID4g PiA+Pj4NCj4gPiA+ID4gPj4+IO+7v0hpLA0KPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPj4+IEkgYWdy ZWUgd2l0aCBMZXMuICBUaGlzIGlzIGEgc2ltcGxlIHByb3RvY29sIGV4dGVuc2lvbiBmb3IgYQ0K PiA+ID4gPiA+Pj4gc3BlY2lmaWMgcHVycG9zZQ0KPiA+ID4gPiA+PiBhbmQgdGhlcmUgaXMgbm8g cmVhc29uIHRvIGluY2x1ZGUgc3BlY3VsYXRpb24gYWJvdXQgaXRzIHVzZSBmb3INCj4gPiA+ID4g Pj4gb3RoZXIgcHVycG9zZXMsIHBhcnRpY3VsYXJseSB3aGVuIGl0IGlzIGluaGVyZW50bHkgbm90 IHN1aXRlZCBmb3IgdGhlbS4NCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+PiBZb3VycyBJcnJlc3Bl Y3RpdmVseSwNCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+PiBKb2huDQo+ID4gPiA+ID4+Pg0KPiA+ ID4gPiA+Pj4NCj4gPiA+ID4gPj4+IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCj4gPiA+ID4g Pj4+DQo+ID4gPiA+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPj4+ PiBGcm9tOiBMc3IgPGxzci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTGVzIEdpbnNi ZXJnDQo+ID4gPiA+ID4+Pj4gKGdpbnNiZXJnKQ0KPiA+ID4gPiA+Pj4+IFNlbnQ6IFRodXJzZGF5 LCBPY3RvYmVyIDE1LCAyMDIwIDEyOjMzIFBNDQo+ID4gPiA+ID4+Pj4gVG86IENocmlzdGlhbiBI b3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBsc3JAaWV0Zi5vcmcNCj4gPiA+ID4gPj4+PiBDYzog bHNyLWNoYWlyc0BpZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9yZzsNCj4gPiA+ID4gPj4+PiBkcmFm dC1pZXRmLWxzci1vc3BmLXByZWZpeC0gb3JpZ2luYXRvckBpZXRmLm9yZw0KPiA+ID4gPiA+Pj4+ IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPiA+ID4gPj4+PiBkcmFmdC1pZXRm LWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+ PiBbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQo+ID4gPiA+ID4+Pj4N Cj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+IEkgc3VwcG9ydCBtb3ZpbmcgdGhpcyBkb2N1bWVu dCBmb3J3YXJkLg0KPiA+ID4gPiA+Pj4+IFNpbWlsYXIgZnVuY3Rpb25hbGl0eSBpbiBJUy1JUyBo YXMgcHJvdmVkIHVzZWZ1bC4NCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+IEkgd291bGQgaG93 ZXZlciBsaWtlIHRvIHJlcGVhdCBjb21tZW50cyBJIG1hZGUgZWFybGllciBpbiB0aGUNCj4gPiA+ ID4gPj4+PiByZXZpZXcgb2YgdGhpcyBkb2N1bWVudC4NCj4gPiA+ID4gPj4+PiBUaGUgY29udGVu dCBvZiB0aGUgQXBwZW5kaWNlcyBzaG91bGQgYmUgcmVtb3ZlZC4NCj4gPiA+ID4gPj4+PiBUaGUg QXBwZW5kaWNlcyBkZWZpbmUgYW5kIGRpc2N1c3MgZGVyaXZpbmcgdG9wb2xvZ3kNCj4gPiA+ID4g Pj4+PiBpbmZvcm1hdGlvbiBmcm9tIHByZWZpeCBhZHZlcnRpc2VtZW50cyAtIHdoaWNoIGlzIGZs YXdlZCBhbmQNCj4gPiA+ID4gPj4+PiBzaG91bGQgbm90IGJlDQo+ID4gZG9uZS4NCj4gPiA+ID4g Pj4+PiBQZXJoYXBzIG1vcmUgcmVsZXZhbnQsIHRoZSBwdXJwb3NlIG9mIHRoZSBkb2N1bWVudCBp cyB0bw0KPiA+ID4gPiA+Pj4+IGRlZmluZSBwcm90b2NvbCBleHRlbnNpb25zIHN1cHBvcnRpbmcg YWR2ZXJ0aXNlbWVudCBvZiB0aGUNCj4gPiA+ID4gPj4+PiBvcmlnaW5hdG9ycyBvZiBhIHByZWZp eCBhZHZlcnRpc2VtZW50LiBUaGVyZSBpcyBubyBuZWVkIHRvDQo+ID4gPiA+ID4+Pj4gZGlzY3Vz cyBob3cgdGhpcyBtZWNoYW5pc20gbWlnaHQgYmUgdXNlZCB0byBidWlsZCB0b3BvbG9neQ0KPiBp bmZvcm1hdGlvbi4NCj4gPiA+ID4gPj4+PiBUaGlzIGRvY3VtZW50IHNob3VsZCBjb25maW5lIGl0 c2VsZiB0byBkZWZpbmluZyB0aGUgcHJvdG9jb2wNCj4gPiA+ID4gPj4+PiBleHRlbnNpb25zIC0g c2ltaWxhciB0aGUgUkZDIDc3OTQuDQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiBJZiB0aGUg YXV0aG9ycyBkbyBub3QgYWdyZWUgdG8gZG8gdGhpcywgSSB3b3VsZCBlbmNvdXJhZ2UNCj4gPiA+ ID4gPj4+PiB0aGlzIHBvaW50IHRvIGJlIGRpc2N1c3NlZCBkdXJpbmcgSUVTRyByZXZpZXcuDQo+ ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+PiAgTGVzDQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPj4+Pj4gRnJvbTogTHNyIDxs c3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENocmlzdGlhbg0KPiA+ID4gPiA+Pj4+ PiBIb3Bwcw0KPiA+ID4gPiA+Pj4+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTQsIDIwMjAg MTE6MTUgUE0NCj4gPiA+ID4gPj4+Pj4gVG86IGxzckBpZXRmLm9yZw0KPiA+ID4gPiA+Pj4+PiBD YzogZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZzsNCj4gPiA+ ID4gPj4+Pj4gbHNyLWNoYWlyc0BpZXRmLm9yZzsgbHNyLSBhZHNAaWV0Zi5vcmc7IENocmlzdGlh biBIb3Bwcw0KPiA+ID4gPiA+Pj4+PiA8Y2hvcHBzQGNob3Bwcy5vcmc+DQo+ID4gPiA+ID4+Pj4+ IFN1YmplY3Q6IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+ID4gPiA+Pj4+PiBkcmFmdC1pZXRmLWxz ci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ IFRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIExhc3QgQ2FsbCwgZW5kaW5nIGFmdGVyIE9jdCAyOXRo LCAyMDIwLCBmb3I6DQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYw0KPiA+ID4gPiA+Pj4+PiAvZA0KPiA+ID4gPiA+Pj4+PiByYQ0KPiA+ID4gPiA+Pj4+PiBm dC1pDQo+ID4gPiA+ID4+Pj4+IGV0DQo+ID4gPiA+ID4+Pj4+IGYtbHNyLW9zcGYtcHJlZml4LW9y aWdpbmF0b3IvX187ISFORXQ2eU1hTy0NCj4gPiA+ID4gPj4gZ2shVGFTelFUaGdodENGT3VZUFMy VmpMcQ0KPiA+ID4gPiA+Pj4+PiBoSyA4cDAzRmczTDlMdUNHWHc4QzBYNnFSUWRySGpLREtIY2pr akNscGskDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+IFRoZSBmb2xsb3dpbmcgSVBSIGhh cyBiZWVuIGZpbGVkDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiBodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMzQ0OC9fXzshDQo+ID4gPiA+ ID4+Pj4+ICFORXQ2eU1hTy0NCj4gPiA+ID4gPj4+Pg0KPiA+ID4gZ2shVGFTelFUaGdodENGT3VZ UFMyVmpMcWhLOHAwM0ZnM0w5THVDR1h3OEMwWDZxUlFkckhqS0RLSGN6DQo+ID4gPiA+ID4+Pj4+ IDVLdFVIUSQNCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4gQXV0aG9ycywNCj4gPiA+ID4g Pj4+Pj4NCj4gPiA+ID4gPj4+Pj4gUGxlYXNlIGluZGljYXRlIHRvIHRoZSBsaXN0LCB5b3VyIGtu b3dsZWRnZSBvZiBhbnkgb3RoZXIgSVBSDQo+ID4gPiA+ID4+Pj4+IHJlbGF0ZWQgdG8gdGhpcyB3 b3JrLg0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+PiBUaGFua3MsDQo+ID4gPiA+ID4+Pj4+ IENocmlzLg0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPj4+PiBMc3IgbWFpbGluZyBsaXN0 DQo+ID4gPiA+ID4+Pj4gTHNyQGlldGYub3JnDQo+ID4gPiA+ID4+Pj4gaHR0cHM6Ly91cmxkZWZl bnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdA0KPiA+ID4gPiA+ Pj4+IGluDQo+ID4gPiA+ID4+Pj4gZm8NCj4gPiA+ID4gPj4+PiAvbHNyDQo+ID4gPiA+ID4+Pj4g X187ISFORXQNCj4gPiA+ID4gPj4+PiA2eU1hTy0NCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pg0K PiA+ID4NCj4gPiBnayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxaEs4cDAzRmczTDlMdUNHWHc4QzBY NnFSUWRySGpLREtIY1VkbQ0KPiA+ID4gPiA+PiB3OA0KPiA+ID4gPiA+Pj4+IExjJA0KPiA+ID4g PiA+Pj4NCj4gPiA+ID4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gPiA+ID4+PiBMc3IgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4+PiBMc3JA aWV0Zi5vcmcNCj4gPiA+ID4gPj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpDQo+ID4gPiA+ID4+PiBuZm8vbHNyX187ISFORXQ2 eU1hTy0NCj4gZ2shVWdFaTNieE5EUzZaTG5YTmxpT3ZrUXRNZVhDVEN3d1NlMFRvT1YNCj4gPiA+ ID4gPj4+IDlVTUQ1NFIzdzIwRV9DWEM1LWJWdVpyLWMkDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ ID4+IExzciBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPj4gTHNyQGlldGYub3JnDQo+ID4gPiA+ID4+ IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3Rpbg0KPiA+ID4gPiA+PiBmby9sc3JfXzshIU5FdDZ5TWFPLQ0KPiBnayFVZ0VpM2J4TkRT NlpMblhObGlPdmtRdE1lWENUQ3d3U2UwVG9PVjlVDQo+ID4gPiA+ID4+IE1ENTRSM3cyMEVfQ1hD NS1iVnVaci1jJA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiBMc3IgbWFpbGluZyBsaXN0DQo+ID4g PiA+ID4gTHNyQGlldGYub3JnDQo+ID4gPiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9f X2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZg0KPiA+ID4gPiA+IG8vbHNyX187 ISFORXQ2eU1hTy0NCj4gZ2shVWdFaTNieE5EUzZaTG5YTmxpT3ZrUXRNZVhDVEN3d1NlMFRvT1Y5 VU1EDQo+ID4gPiA+ID4gNTRSM3cyMEVfQ1hDNS1iVnVaci1jJA0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gTHNyIG1haWxpbmcgbGlzdA0KPiA+ID4gTHNyQGll dGYub3JnDQo+ID4gPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scw0KPiA+ID4gcl9fOyEhTkV0NnlNYU8tDQo+IGdrIVVn RWkzYnhORFM2WkxuWE5saU92a1F0TWVYQ1RDd3dTZTBUb09WOVVNRDU0UjN3MjBFDQo+ID4gPiBf Q1hDNS1iVnVaci1jJA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gTHNyIG1haWxpbmcgbGlzdA0KPiA+IExzckBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xzcl8NCj4gPiBfOyEhTkV0NnlNYU8tDQo+IGdrIVVnRWkzYnhORFM2WkxuWE5saU92 a1F0TWVYQ1RDd3dTZTBUb09WOVVNRDU0UjN3MjBFX0NYQw0KPiA+IDUtYlZ1WnItYyQNCg== From nobody Mon Oct 19 07:14:59 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4983A0A8C; Mon, 19 Oct 2020 07:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (2048-bit key) header.d=juniper.net header.b=eXGob4R+; dkim=pass (1024-bit key) header.d=juniper.net header.b=SY/zH1zR 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 BTia8deCy4uL; Mon, 19 Oct 2020 07:14:53 -0700 (PDT) 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 938003A0A86; Mon, 19 Oct 2020 07:14:53 -0700 (PDT) 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 09JE8u3c032245; Mon, 19 Oct 2020 07:14:39 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=5N+Iha/TfNzTO2Ft3eGL9cmWACbydPQ40ak6R35Tu/c=; b=eXGob4R+KvlFnHgH05zTh5WpFgx0Q5OuXaecjiELzb4tHSqDrPqxvXWaMu+DpXfvWFN9 JKw5k8DhGK+nWeTCIDoN+pjm10jWb9mTQB3P4Vr8gWgAd+iF0MM0kblFu2K5NuT6U2f8 PaV0QYr+nfOLXkp/a9ITjDym5H/HR45///1cO6C+70tZ/CaKCsF2wh7+yS1H3ne3t//r gWKcdTWDClRfx2jlseIM5F+try9Ftj6O+1HSAmOeE//ZC/QRvxVlHm0QoGELqvVn6BSB t1IBzb/ztBT90nbbMVHT+Y9IcgqHIfks5SXQDgyHdpizPhprb7M+r78EiWOJMt36uI9B Bw== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2109.outbound.protection.outlook.com [104.47.58.109]) by mx0a-00273201.pphosted.com with ESMTP id 347vaqan6q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 07:14:38 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ar/InBAmP8Ull3gnRNSamB/lrN1RirRSFylc0pRofKzmJWjllL/0oD3BheQzlJFFFJJq5ohuJQX/2TJCwij6+GkSIg4mzh65sZOvQtzbs6aPhcrqQBa5qncBKBkrEZzaQY5rCwFNOg+95NtUxHpGVlISuoCgHf7KWObzmwViVH7tbOF19zYCADnEq8K7ihlW/+rxPJe4/ue9iHl2I9LjiB4HFwNlh9C7wFFA6nGZPXfY+ITWbdOmjb6CBcxhfP1FatP1OgwiUIiyk9D/tNcNxXPbwvetlWKeEWKQmLw2fx8sNfESbw4n5PtLLSpartoWZcfvExhCWNPruurjtBhdzA== 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=5N+Iha/TfNzTO2Ft3eGL9cmWACbydPQ40ak6R35Tu/c=; b=BBhlUQQX21LZWFV/JzPyX+aXwrGAP4+ournKMoxpq0dCAmi9LvqPtM/f1la5Iy/mO+W+9B/0+a3m+yOa0n1n37bHGxlVOp5u/XBdNS2lhdlq3HneOpXjsSe4XMPMb4Y8d0uDEw5xIbFO6vLdAch2M072xcyKXcMaRbv3nGtlFbIG3txrE9vXty/YEX3i6JrU19/Bi2/+qpitHdH5sa+H1Uc6xrqBYE573tkV2vncYefn8wROPisg9gSsKKmCal9I8hL9qtzDZeqVVMxhf0HEr47WTst03hOQL/VXtZlYXoHBOGZ/u1VrsU5rSyPMt+u9HXomY5EnSNk9uRiQSR1UvQ== 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=5N+Iha/TfNzTO2Ft3eGL9cmWACbydPQ40ak6R35Tu/c=; b=SY/zH1zRTEuLYeAgx164r2/ORNR842gwhsL5hNAcpzyILowTnreJ3bojJ9ap22jDd9ZQppKdhjrMLP64eXnTOm/oOPLFu9wx2znezN9S+oxUxfhO/JzK7wUob3zBEgHsFcrtTu5MeLt8LL2iD4sd6WxCyvXc0mVmHlv0F0f7Bi0= Received: from DM5PR05MB3388.namprd05.prod.outlook.com (2603:10b6:4:40::18) by DM6PR05MB6666.namprd05.prod.outlook.com (2603:10b6:5:129::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.11; Mon, 19 Oct 2020 14:14:35 +0000 Received: from DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865]) by DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865%7]) with mapi id 15.20.3499.015; Mon, 19 Oct 2020 14:14:35 +0000 From: John E Drake To: Peter Psenak , Aijun Wang , Peter Psenak CC: "Les Ginsberg (ginsberg)" , Aijun Wang , Christian Hopps , "lsr-chairs@ietf.org" , "lsr@ietf.org" , Jeff Tantsura , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWo8tCJIqrzId5sUmXrpGJFDH2DqmeMcAAgABE8gCAAA5ggIAAB1UAgAAcQ4CAAA/uAIAABdaAgAA9T2A= Date: Mon, 19 Oct 2020 14:14:35 +0000 Message-ID: References: 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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-19T14:14:33Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=fea13837-f325-473c-b98a-7d236776db40; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9443aea6-c257-4cbe-19f4-08d874394eec x-ms-traffictypediagnostic: DM6PR05MB6666: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xdEN6k0fxQBpamgCM218/mNWfWoX1bsGO4kwvKNrgli+VIw7DRl2E1pcYaEbhfBdwvL7LUyQoyzTAjXp+KNLRpUDd1CeC28C/dXLHeCF8+7RIS5lwTCZc1CvVReEzqzZChmPYtdEKjgC8uH52FRd/gktmxqd9k/YQGgJUBNk76Etgw3A4RpxDLCqHBiFWjIrzh9yGAQi0+QkN5/vJVG6eEUvYI0moSrzgLuJxMIvN/VaEXGX55yiuf66/P4f8ovvveWR/zI7DWqwCasnarZ+i/IlzLksdb1fBvyQ3Zr9EEIGsMAGU0WWFAW7ghUERh9GgzDeQlTnYxYgrfn9Gt8KJwFLzD6FrgmVPNmmlCa/QmArswKXhlA55pY/kQIwqNfKgk8i/lX0D+7EvAcqq0JV8g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3388.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(376002)(346002)(136003)(396003)(9686003)(4326008)(5660300002)(52536014)(2906002)(66946007)(54906003)(76116006)(316002)(110136005)(66476007)(66556008)(64756008)(66446008)(33656002)(55016002)(53546011)(26005)(71200400001)(8676002)(7696005)(6506007)(186003)(8936002)(86362001)(30864003)(83380400001)(478600001)(966005)(66574015)(7416002)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: V3wYTtUk8sfj7fUMhatew38G7Ot6UmKeAKLbCct3Xsay/edRd8OXQDe0hK2+6kqkWSu1PBH2i5p2j6FEjrIIVYzcfuQDhkA2+KwLT7xe42wDw+43inA0+esFyi5orKzm/bKBGBmgTBVSzIjXPmpMVWQ/7knnQwP9V67fgLPAHnukU47GFdhifPOtW3drzzbSuG+W4CP56dUIyF70IZa2tfVIC1Woa7dX9PCj3AndubLprKZ910XAcB6HAjTQMcjrU2DP7bsycAK6XxTyTZ6erDxqY5rGoPNOgE2a1CzTxj6dVchcKngGHQ+AjiU0zsG7dVppg9ygdAwaOEgW+gyCuSE4R4we4880GdrkNbLHwD3L2P+lllozQjig0jx+VuJC3lFYGOzDnWswG5+MERGaVmGBnvHDEfEDbzjPoX2w03RLyxuUuYz7yO8tT+iNbxcx3YzMOUJIuVPHy3e2aGAbHgM5aFnVdesu4K2sUT03XcD3z5nGP5SGuViwMoZhb3sn7mhrjDLp4Q6gPmkusclBvJFwLnkazgEVpoEfUOSXKODEnOifPj0GjC+XrZZNk9srmGfknlRYofSWEZLO8GCYSX1VMdGRS7R1RYs3gUJHHFdrROp6P0ZEKlzH7Lr1ifgy586TGEvx5Gi/wKMkDqBnJw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR05MB3388.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9443aea6-c257-4cbe-19f4-08d874394eec X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 14:14:35.6770 (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: Fr+PvZaVMUZ94d29wqx839c04C0qxZztR4glkWg1NgXZ3NyYzTtRrbLjbSj0Kus2bBrHbmH63liC1bVhBkUylA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB6666 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-19_06:2020-10-16, 2020-10-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 adultscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 mlxscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 mlxlogscore=999 suspectscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190097 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:14:58 -0000 QWlqdW4sDQoNCldoYXQgcGFydCBvZiAidXNpbmcgSVAgYWRkcmVzcyBhZHZlcnRpc2VtZW50IHRv IGRlcml2ZSB0b3BvbG9naWNhbCBkYXRhIGlzIGJyb2tlbiIgZG8geW91IG5vdCB1bmRlcnN0YW5k Pw0KDQpZb3VycyBJcnJlc3BlY3RpdmVseSwNCg0KSm9obg0KDQoNCkp1bmlwZXIgQnVzaW5lc3Mg VXNlIE9ubHkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZXRlciBQ c2VuYWsgPHBwc2VuYWtAY2lzY28uY29tPg0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIw MjAgNjozMiBBTQ0KPiBUbzogQWlqdW4gV2FuZyA8d2FuZ2FqM0BjaGluYXRlbGVjb20uY24+OyBQ ZXRlciBQc2VuYWsNCj4gPHBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+DQo+IENj OiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsgQWlqdW4gV2Fu Zw0KPiA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj47IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBz QGNob3Bwcy5vcmc+OyBKb2huIEUNCj4gRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5ldD47IGxzci1j aGFpcnNAaWV0Zi5vcmc7IGxzckBpZXRmLm9yZzsgSmVmZiBUYW50c3VyYQ0KPiA8amVmZnRhbnQu aWV0ZkBnbWFpbC5jb20+OyBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGll dGYub3JnOyBsc3ItDQo+IGFkc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0xzcl0gV0cgTGFz dCBDYWxsIGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gDQo+IFtF eHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCj4gDQo+IA0KPiBIaSBBaWp1 biwNCj4gDQo+IHBsZWFzZSBzZWUgaW5saW5lOg0KPiANCj4gDQo+IE9uIDE5LzEwLzIwMjAgMTI6 MTAsIEFpanVuIFdhbmcgd3JvdGU6DQo+ID4gSGkuIFBldGVyLCBMZXM6DQo+ID4NCj4gPiBXZSBo YXZlIGRlZmluZWQgbWFueSBleHRlbnNpb25zIGZvciBwcm90b2NvbCwgYnV0IG9ubHkgYSBzbWFs bCBwYXJ0IG9mIHRoZW0NCj4gYXJlIGRlcGxveWVkLiBIYXZlIHlvdSBldmVyIGNvbnNpZGVyZWQg dGhlIHJlYXNvbj8NCj4gPg0KPiA+IEFkZGluZyBtb3JlIGNvbnRlbnRzIGZvciB0aGVpciAgcG90 ZW50aWFsIHVzYWdlcyBjYW4gY2VydGFpbmx5IGJlIGhlbHBmdWwgZm9yDQo+IHRoZWlyIGluZmx1 ZW5jZXMsIG9yIGVsc2UsIHRoZXkgd2lsbCBqdXN0IHN0YXkgYXQgdGhlIElFVEYgcmVwb3NpdG9y eS4NCj4gDQo+IEkgZGlzYWdyZWUuIFJGQ3MgYXJlIG5vdCBkZXBsb3ltZW50IG9yIHVzZSBjYXNl IGRvY3VtZW50cy4gVGhleSBleGlzdHMgdG8NCj4gYWRkcmVzcyB0aGUgaW50ZXJvcGVyYWJpbGl0 eS4NCj4gDQo+ID4NCj4gPiBNb3JlIHJlcGxpZXMgaW5saW5lIGJlbG93Lg0KPiA+DQo+ID4NCj4g Pg0KPiA+IEFpanVuIFdhbmcNCj4gPiBDaGluYSBUZWxlY29tDQo+ID4NCj4gPj4gT24gT2N0IDE5 LCAyMDIwLCBhdCAxNzoxNCwgUGV0ZXIgUHNlbmFrDQo+IDxwcHNlbmFrPTQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnPiB3cm90ZToNCj4gPj4NCj4gPj4gQWlqdW4sDQo+ID4+DQo+ID4+PiBPbiAx OS8xMC8yMDIwIDA5OjMyLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSB3cm90ZToNCj4gPj4+IEFp anVuIC0NCj4gPj4+IEkgYW0gbm90IGdvaW5nIHRvIGNvbnRpbnVlIHRoZXNlIHNpZGUgZGlzY3Vz c2lvbnMgd2l0aCB5b3UuDQo+ID4+PiBUaGUgcHJpbWFyeSBwdXJwb3NlIG9mIHRoZSBwcm90b2Nv bCBleHRlbnNpb25zIGFyZSBhcyBzdGF0ZWQgaW4gdGhlIGRyYWZ0DQo+IEludHJvZHVjdGlvbi4g VGhpcyBpcyBhbmFsb2dvdXMgdG8gdGhlIHVzZSBjYXNlcyBmb3IgdGhlIGVxdWl2YWxlbnQgZXh0 ZW5zaW9ucyBmb3INCj4gSVMtSVMgYWxyZWFkeSBhcHByb3ZlZCBpbiBSRkMgNzc5NC4gV2UgbmVl ZCB0aGUgZXF1aXZhbGVudCBpbiBPU1BGLg0KPiA+Pj4gWW91IGNhbiBzaG93IHRoYXQgeW91IGFy ZSBsaXN0ZW5pbmcgdG8gdGhlIGNvbmNlcm5zIG9mIFdHIG1lbWJlcnMgYnkNCj4gcmVtb3Zpbmcg dGhlIEFwcGVuZGljZXMgLSBpbiB3aGljaCBjYXNlIHlvdSBoYXZlIChJIGJlbGlldmUpIGJyb2Fk IHN1cHBvcnQgZm9yDQo+IG1vdmluZyB0aGUgZHJhZnQgZm9yd2FyZC4NCj4gPj4NCj4gPj4gSSBh Z3JlZSB3aXRoIExlcy4NCj4gPj4NCj4gPj4gQXMgYSBjby1hdXRob3IsIEkgaGF2ZSBhc2tlZCB5 b3Ugc2V2ZXJhbCB0aW1lcyB0byBnZXQgcmlkIG9mIHRoZSB1c2UgY2FzZQ0KPiBkZXNjcmliZWQg aW4gYXBwZW5kaXguDQo+ID4gW1dBSl0gTW92aW5nIHRoZSBleHBhbnNpb24gb2YgdGhpcyB1c2Ug Y2FzZSBmcm9tIGJvZHkgcGFydCBvZiB0aGlzIGRyYWZ0IHRvIGl0cw0KPiBhcHBlbmRpeCBpcyBv dXIgaW5pdGlhbCBjb25zZW5zdXMsIG5vdCByZW1vdmUgaXQgdG90YWxseS4gV2UgaGF2ZSBkaXNj dXNzZWQNCj4gaW50ZW5zZWx5IGZvciBpdHMgYXBwbGljYXRpb24gaW4gdmFyeSBzaXR1YXRpb25z LiBUaGUgZGlzY3Vzc2lvbiByZXN1bHRzIGFyZSBzdGF0ZWQNCj4gY2xlYXJseSBpbiB0aGUgYXBw ZW5kaXguDQo+IA0KPiBqdXN0IGJlY2F1c2UgeW91IGluc2lzdGVkIGFuZCBkaWQgbm90IGxpc3Rl biB0byByZXN0IG9mIHVzLg0KPiANCj4gPiBXaXNoIHRvIGhlYXIgbW9yZSB0ZWNobmljYWwgYW5h bHlzaXMvY29tbWVudHMgZm9yIHRoZSBjdXJyZW50IHN0YXRlbWVudHMgb2YNCj4gdGhpcyBwYXJ0 IGZyb20gb3RoZXIgZXhwZXJ0cywgb3IgZnJvbSB5b3UgaWYgeW91IGhhdmUgZnJlc2ggY29uc2lk ZXJhdGlvbi4NCj4gDQo+IHdlIGFyZSBpbiBhIGNpcmNsZS4gTXVsdGlwbGUgV0cgbWVtYmVycyAo TGVzLCBUb255IFAuIEFjZWUsIEtldGFuLA0KPiBteXNlbGYpIGFyZSB0ZWxsaW5nIHlvdSB0aGF0 IHVzaW5nIElQIGFkZHJlc3MgYWR2ZXJ0aXNlbWVudCB0byBkZXJpdmUgdG9wb2xvZ2ljYWwNCj4g ZGF0YSBpcyBicm9rZW4gYW5kIHlvdSBrZWVwIHJlcGVhdGluZyBpdCBpcyB2YWxpZCB1c2UgY2Fz ZSBhbmQgYXNrIGZvciBtb3JlDQo+IHJlYXNvbmluZy4NCj4gDQo+IHRoYW5rcywNCj4gUGV0ZXIN Cj4gDQo+ID4NCj4gPj4gVHJ5aW5nIHRvIHVzZSBwcmVmaXggYWR2ZXJ0aXNlbWVudCB0byBkZXJp dmUgdG9wb2xvZ2ljYWwgZGF0YSBpcyBzaW1wbHkNCj4gYnJva2VuLiBUaGUgcmVhc29uIHdlIGFy ZSBhZGRpbmcgdGhlIHByZWZpeCBvcmlnaW5hdG9yIGV4dGVuc2lvbiB0byBPU1BGIGlzIE5PVA0K PiB0aGUgYnJva2VuIHVzZSBjYXNlIGluIHRoZSBhcHBlbmRpeCBvZiB0aGUgZHJhZnQuDQo+ID4+ DQo+ID4+IHRoYW5rcywNCj4gPj4gUGV0ZXINCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4+IFlvdSBj YW4gdGhlbiB3cml0ZSBhIHNlcGFyYXRlIGRyYWZ0IHRvIGRpc2N1c3Mgb3RoZXIgdXNlIGNhc2Vz IGFuZCBhbGxvdyB0aGUNCj4gV0cgdG8gZGlzY3VzcyB0aG9zZSBvdGhlciB1c2UgY2FzZXMgdy9v IHByZXZlbnRpbmcgdGhlIGV4dGVuc2lvbnMgZnJvbSBiZWluZw0KPiBhcHByb3ZlZCBhbmQgZGVw bG95ZWQgZm9yIHRoZSB1c2UgY2FzZXMgd2hpY2ggaGF2ZSBhbHJlYWR5IGJlZW4NCj4gZGVtb25z dHJhdGVkIGFzIHVzZWZ1bCBieSBJUy1JUy4NCj4gPj4+IElmIHlvdSByZW1vdmUgdGhlIEFwcGVu ZGljZXMgSSBjYW4gc3VwcG9ydCB0aGUgZHJhZnQuDQo+ID4+PiBJZiB5b3UgZG8gbm90IHJlbW92 ZSB0aGUgQXBwZW5kaWNlcyBJIGNhbm5vdCBzdXBwb3J0IHRoZSBkcmFmdC4NCj4gPj4+IFBsZWFz ZSBkaXNjdXNzIHRoaXMgd2l0aCB5b3VyIGNvLWF1dGhvcnMgYW5kIGNvbWUgdG8gY29uc2Vuc3Vz IG9uIHlvdXINCj4gbmV4dCBzdGVwLg0KPiA+Pj4gICAgIExlcw0KPiA+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5n aHVhLm9yZy5jbj4NCj4gPj4+PiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMjAgMTI6MDYg QU0NCj4gPj4+PiBUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNv bT47ICdDaHJpc3RpYW4gSG9wcHMnDQo+ID4+Pj4gPGNob3Bwc0BjaG9wcHMub3JnPg0KPiA+Pj4+ IENjOiAnSm9obiBFIERyYWtlJyA8amRyYWtlQGp1bmlwZXIubmV0PjsgbHNyLWNoYWlyc0BpZXRm Lm9yZzsNCj4gPj4+PiBsc3JAaWV0Zi5vcmc7ICdKZWZmIFRhbnRzdXJhJyA8amVmZnRhbnQuaWV0 ZkBnbWFpbC5jb20+Ow0KPiA+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LSBvcmlnaW5h dG9yQGlldGYub3JnOyBsc3ItYWRzQGlldGYub3JnDQo+ID4+Pj4gU3ViamVjdDogUkU6IFtMc3Jd IFdHIExhc3QgQ2FsbA0KPiA+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0 b3ItMDYNCj4gPj4+Pg0KPiA+Pj4+IEhpLCBMZXM6DQo+ID4+Pj4NCj4gPj4+PiBBcyBJIHN0YXRl ZCBjbGVhcmx5IGJlZm9yZSwgdGhlIGFwcGVuZGl4IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgaXMN Cj4gPj4+PiBub3QgdGhlIG5ldyB1c2UgY2FzZS4gSXQgaXMgdGhlIHN0YXJ0IHBvaW50IG9mIHRo aXMgZHJhZnQuDQo+ID4+Pj4gSGF2ZSB5b3Ugbm90aWNlZCB0aGF0IHRoZSBpbnRyb2R1Y3Rpb24g cGFydCBpcyBub3QgdGhlIGZpbmFsIHVzYWdlDQo+ID4+Pj4gb2Ygc3VjaCBwcm90b2NvbCBleHRl bnNpb24gaW5mb3JtYXRpb24/DQo+ID4+Pj4gQ2VydGFpbmx5LCB3ZSB3aWxsIG5vdCBleHBhbmQg YWxsIHRoZSBwb3NzaWJsZSB1c2UgY2FzZXMgaW4gdmVyeQ0KPiA+Pj4+IGRldGFpbCwgYnV0IHB1 dHRpbmcgc29tZSBvZiB0aGVtKHNvbWUgaW50ZXJlc3RpbmcsIHByb21pbmVudCB1c2UNCj4gPj4+ PiBjYXNlcykgaW4gdGhlIGFwcGVuZGl4IHdpbGwgbm90IGhhbXBlciB0aGUgcHJvdG9jb2wgZXh0 ZW5zaW9uIGl0c2VsZi4NCj4gPj4+Pg0KPiA+Pj4+IElmIHRoZSBzdGF0ZW1lbnRzL2Rlc2NyaXB0 aW9ucyBpbiB0aGUgYXBwZW5kaXggYXJlIG5vdCBjb3JyZWN0LCB3ZQ0KPiA+Pj4+IGNhbiBmaXgg aXQsIG9yIHJlbW92ZSBpdCBmaW5hbGx5LiAgSWYgbm90LCB3aHkgbm90IGxldCBpdCBiZSBmb3IN Cj4gPj4+PiByZWZlcmVuY2UgdG8gdGhlIHVzZXIgb2Ygc3VjaCBwcm90b2NvbCBleHRlbnNpb24/ DQo+ID4+Pj4gRm9yIHRoZSBib2R5IHBhcnQgb2YgdGhpcyBkcmFmdCwgd2UgYXJlIGFsc28gd2Vs Y29tZSBjb21tZW50cy4NCj4gPj4+Pg0KPiA+Pj4+IE1vcmUgcmVwbGllcyBpbmxpbmUgYmVsb3db V0FKXQ0KPiA+Pj4+DQo+ID4+Pj4gQmVzdCBSZWdhcmRzDQo+ID4+Pj4NCj4gPj4+PiBBaWp1biBX YW5nDQo+ID4+Pj4gQ2hpbmEgVGVsZWNvbQ0KPiA+Pj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBsc3ItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmxz ci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPj4+PiBPZiBMZXMgR2luc2JlcmcgKGdp bnNiZXJnKQ0KPiA+Pj4+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAxOSwgMjAyMCAyOjE1IFBNDQo+ ID4+Pj4gVG86IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+OyAnQ2hyaXN0 aWFuIEhvcHBzJw0KPiA+Pj4+IDxjaG9wcHNAY2hvcHBzLm9yZz4NCj4gPj4+PiBDYzogJ0pvaG4g RSBEcmFrZScgPGpkcmFrZUBqdW5pcGVyLm5ldD47IGxzci1jaGFpcnNAaWV0Zi5vcmc7ICdMZXMN Cj4gPj4+PiBHaW5zYmVyZyAoZ2luc2JlcmcpJyA8Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmc+Ow0KPiA+Pj4+IGxzckBpZXRmLm9yZzsgJ0plZmYgVGFudHN1cmEnIDxqZWZmdGFu dC5pZXRmQGdtYWlsLmNvbT47DQo+ID4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtIG9y aWdpbmF0b3JAaWV0Zi5vcmc7IGxzci1hZHNAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTog W0xzcl0gV0cgTGFzdCBDYWxsDQo+ID4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3Jp Z2luYXRvci0wNg0KPiA+Pj4+DQo+ID4+Pj4gQWlqdW4gLQ0KPiA+Pj4+DQo+ID4+Pj4gVGhlICJ1 c2UgY2FzZSIgZm9yIHRoZSBwcm90b2NvbCBleHRlbnNpb25zIGlzIGNsZWFybHkgc3RhdGVkIGlu IHRoZQ0KPiA+Pj4+IEludHJvZHVjdGlvbjoNCj4gPj4+Pg0KPiA+Pj4+ICJUaGUgcHJpbWFyeSB1 c2UgY2FzZSBmb3IgdGhlIGV4dGVuc2lvbnMgcHJvcG9zZWQgaW4gdGhpcyBkb2N1bWVudCBpcw0K PiA+Pj4+ICAgICB0byBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBw cmVmaXggaW4gdGhlIG5ldHdvcmsuDQo+ID4+Pj4gICAgIEluIGNhc2VzIHdoZXJlIG11bHRpcGxl IHByZWZpeGVzIGFyZSBhZHZlcnRpc2VkIGJ5IGEgZ2l2ZW4gcm91dGVyLCBpdA0KPiA+Pj4+ICAg ICBpcyBhbHNvIHVzZWZ1bCB0byBiZSBhYmxlIHRvIGFzc29jaWF0ZSBhbGwgdGhlc2UgcHJlZml4 ZXMgd2l0aCBhDQo+ID4+Pj4gICAgIHNpbmdsZSByb3V0ZXIgZXZlbiB3aGVuIHByZWZpeGVzIGFy ZSBhZHZlcnRpc2VkIG91dHNpZGUgb2YgdGhlIGFyZWENCj4gPj4+PiAgICAgaW4gd2hpY2ggdGhl eSBvcmlnaW5hdGVkLiAgSXQgYWxzbyBoZWxwcyB0byBkZXRlcm1pbmUgd2hlbiB0aGUgc2FtZQ0K PiA+Pj4+ICAgICBwcmVmaXggaXMgYmVpbmcgb3JpZ2luYXRlZCBieSBtdWx0aXBsZSByb3V0ZXJz IGFjcm9zcyBhcmVhcy4iDQo+ID4+Pj4NCj4gPj4+PiBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gbGFu Z3VhZ2UgaW4gUkZDIDc3OTQgd2hpY2ggZGVmaW5lcyB0aGUNCj4gPj4+PiBhbmFsb2dvdXMgZXh0 ZW5zaW9ucyBmb3IgSVMtSVMuDQo+ID4+Pj4NCj4gPj4+PiBFdmVyeXRoaW5nIHlvdSBoYXZlIGlu IHRoZSBBcHBlbmRpeCBpcyBub3QgcmVsYXRlZCB0byB0aGUgcHJpbWFyeQ0KPiA+Pj4+IHVzZSBj YXNlIC0gYW5kIGlzIGZhY3QgYSB1c2UgY2FzZSB3aGljaCBtYW55IG9mIHVzIGhhdmUgb2JqZWN0 ZWQgdG8uDQo+ID4+Pj4gW1dBSl0gVmVyeSBnbGFkIHRvIGtub3cgdGhlIGZhbHNlIHN0YXRlbWVu dHMgaW4gdGhlIGFwcGVuZGl4Lg0KPiA+Pj4+DQo+ID4+Pj4gWW91IGFyZSBlbnRpdGxlZCB0byB3 cml0ZSBhbm90aGVyIGRyYWZ0IGFkdm9jYXRpbmcgZm9yIHlvdXIgbmV3IHVzZQ0KPiA+Pj4+IGNh c2UgaWYgeW91IHdpc2gsIGJ1dCByZXF1aXJpbmcgdGhhdCB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9u cyBpbg0KPiA+Pj4+IHN1cHBvcnQgb2YgdGhlIHByaW1hcnkgdXNlIGNhc2Ugbm90IGdvIGZvcndh cmQgd2l0aG91dCB5b3VyIG5ldyB1c2UNCj4gPj4+PiBjYXNlIGlzIC0gYXMgQ2hyaXMgaGFzIHN0 YXRlZCB2ZXJ5IGNsZWFybHkgLSBob2xkaW5nIGFwcHJvdmFsIG9mDQo+ID4+Pj4gdGhlIHByb3Rv Y29sIGV4dGVuc2lvbnMgaG9zdGFnZSB0byB5b3VyIG5ldyB1c2UgY2FzZS4NCj4gPj4+PiBbV0FK XSBJdCBpcyBub3QgbmV3IHVzZSBjYXNlLiBBcyBJIHNhdGVkIGJlZm9yZSwgSSBhbSBvcGVuIHRv IHRoaXMNCj4gPj4+PiBwYXJ0LCBidXQgc2hvdWxkIG9uIHRoZSBjb25kaXRpb25zIHRoYXQgdGhl IHN0YXRlbWVudHMgaW4gdGhpcyBwYXJ0IGFyZQ0KPiBpbmNvcnJlY3QuDQo+ID4+Pj4NCj4gPj4+ PiBJIGFtIGFza2luZyB5b3UgKHlldCBhZ2Fpbikgbm90IHRvIGRvIHRoaXMuDQo+ID4+Pj4NCj4g Pj4+PiBJIGNhbm5vdCBzdXBwb3J0IHRoZSBkb2N1bWVudCBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRo ZSBjb250ZW50IGluDQo+ID4+Pj4gdGhlIEFwcGVuZGljZXMgaW5jbHVkZWQuDQo+ID4+Pj4gW1dB Sl0gV291bGQgbGlrZSB0byBoZWFyIG1vcmUgdGVjaG5pY2FsIGFuYWx5c2lzLg0KPiA+Pj4+DQo+ ID4+Pj4gICAgIExlcw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4+Pj4gRnJvbTogTHNyIDxsc3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEFpanVuIFdhbmcNCj4gPj4+Pj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDE4LCAyMDIw IDc6MDggUE0NCj4gPj4+Pj4gVG86ICdDaHJpc3RpYW4gSG9wcHMnIDxjaG9wcHNAY2hvcHBzLm9y Zz4NCj4gPj4+Pj4gQ2M6ICdKb2huIEUgRHJha2UnIDxqZHJha2VAanVuaXBlci5uZXQ+OyBsc3It Y2hhaXJzQGlldGYub3JnOyAnTGVzDQo+ID4+Pj4+IEdpbnNiZXJnIChnaW5zYmVyZyknIDxnaW5z YmVyZz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47DQo+ID4+Pj4+IGxzckBpZXRmLm9yZzsg J0plZmYgVGFudHN1cmEnIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT47DQo+ID4+Pj4+IGRyYWZ0 LWlldGYtbHNyLW9zcGYtcHJlZml4LSBvcmlnaW5hdG9yQGlldGYub3JnOyBsc3ItYWRzQGlldGYu b3JnDQo+ID4+Pj4+IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPj4+Pj4gZHJh ZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+Pj4+Pg0KPiA+Pj4+PiBI aSwgQ2hyaXM6DQo+ID4+Pj4+DQo+ID4+Pj4+IEkgdGhpbmsgd2UgaGF2ZSAicHV0IHRoZSBjYXJ0 IGJlZm9yZSB0aGUgaG9yc2UiLiBGb3IgcHJvdG9jb2wNCj4gPj4+Pj4gZXh0ZW5zaW9uIGRyYWZ0 LCB0aGUgb3JpZ2luIGlzIHRoZSB1c2UgY2FzZS4NCj4gPj4+Pj4gQW5kIEkgdGhpbmsgd2Ugd2ls bCBub3QgZXhwYW5kIE9TUEYgcHJvdG9jb2wsIGp1c3QgYmVjYXVzZSBpdCBsYWNrDQo+ID4+Pj4+ IHNvbWV0aGluZyBhcyBjb21wYXJlZCB3aXRoIElTSVMsIHJpZ2h0Pw0KPiA+Pj4+Pg0KPiA+Pj4+ PiBBcyBJIHN0YXRlZCBiZWZvcmUsIHRoZSB1c2UgY2FzZSBpbiBjdXJyZW50IGFwcGVuZGl4IGlz IHRoZSBtYWluDQo+ID4+Pj4+IG1vdGl2YXRpb24gb2YgdGhpcyBkcmFmdCwgeW91IGNhbiBzZWUg dGhpcyBpbiBtYWluIGJvZHkgb2YgdGhlDQo+ID4+Pj4+IGVhcmxpZXIgdmVyc2lvbiBvZiB0aGlz IGRyYWZ0KGZyb20gdmVyc2lvbiAwIHRvIHZlcnNpb24gNSkuDQo+ID4+Pj4+IFRoZSByZWFzb24g dGhhdCB3ZSBtb3ZlIHRoaXMgcGFydCB0byB0aGUgYXBwZW5kaXgsIGFzIHRoYXQgeW91DQo+ID4+ Pj4+IHNhaWQsIGlzIHRvIGxldCBwZXJzb24gZm9jdXMgb24gdGhlIHByb3RvY29sIGV4dGVuc2lv biBpdHNlbGYuDQo+ID4+Pj4+DQo+ID4+Pj4+IE1vdmluZyB0aGlzIHBhcnQgdG8gYXBwZW5kaXgg aXMgYWNjZXB0YWJsZSwgYnV0IHJlbW92aW5nIGl0IGZyb20NCj4gPj4+Pj4gdGhlIGRyYWZ0IHdp bGwgZXJhc2UgdGhlIG9yaWdpbiBvZiB0aGlzIGRvY3VtZW50Lg0KPiA+Pj4+PiBJcyBpdCByZWFz b25hYmxlIHRoYXQgb25lIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgIm9yaWdpbiIob2YgdGhlDQo+ ID4+Pj4+IHByZWZpeCksIGNhbid0IGtlZXAgaXRzIG9yaWdpbj8NCj4gPj4+Pj4NCj4gPj4+Pj4g TW9yZSByZXBsaWVzIGlubGluZSBiZWxvd1tXQUpdLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBCZXN0IFJl Z2FyZHMNCj4gPj4+Pj4NCj4gPj4+Pj4gQWlqdW4gV2FuZw0KPiA+Pj4+PiBDaGluYSBUZWxlY29t DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+Pj4+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZg0KPiA+Pj4+PiBPZiBDaHJpc3RpYW4gSG9wcHMNCj4gPj4+Pj4gU2Vu dDogRnJpZGF5LCBPY3RvYmVyIDE2LCAyMDIwIDEwOjQ3IFBNDQo+ID4+Pj4+IFRvOiDnjovniLHk v4ogPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+DQo+ID4+Pj4+IENjOiBKb2huIEUgRHJha2Ug PGpkcmFrZUBqdW5pcGVyLm5ldD47IENocmlzdGlhbiBIb3Bwcw0KPiA+Pj4+PiA8Y2hvcHBzQGNo b3Bwcy5vcmc+OyBsc3ItY2hhaXJzQGlldGYub3JnOyBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0K PiA+Pj4+PiA8Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+OyBsc3JAaWV0Zi5v cmc7IEplZmYgVGFudHN1cmENCj4gPj4+Pj4gPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsNCj4g Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZzsgbHNy LSBhZHNAaWV0Zi5vcmcNCj4gPj4+Pj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbA0K PiA+Pj4+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4+Pj4+ DQo+ID4+Pj4+IElzbid0IHRoaXMganVzdCBhZGRpbmcgYW4gYW5hbG9nb3VzIGV4dGVuc2lvbiB0 aGF0IGFscmVhZHkgZXhpc3RzIGluDQo+IFJGQzc3OTQ/DQo+ID4+Pj4+IFtXQUpdIE5vLiBSRkM3 Nzk0IGlzIGp1c3Qgb25lIGV4YW1wbGUgdGhhdCB0byBpbGx1c3RyYXRlLCBhcyB0aGUNCj4gPj4+ Pj4gY29tcGFuaW9uIElHUCBwcm90b2NvbCwgT1NQRiBjYW4gYWxzbyBhY2NvbXBsaXNoIHRoaXMu IEFuZCwNCj4gPj4+Pj4gYWN0dWFsbHksIHRoZXJlIGFyZSBkaWZmZXJlbmNlcyBjb25zaWRlcmF0 aW9uIGluIHRoaXMgZHJhZnQgZm9yIHRoZSBwcm90b2NvbA0KPiBleHRlbnNpb24uDQo+ID4+Pj4+ DQo+ID4+Pj4+IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBkbyBhIGxvdCBvZiBjb252aW5jaW5n IGF0IHRoaXMgcG9pbnQuIEkNCj4gPj4+Pj4gYWdyZWUgd2l0aCBMZXMsIGlmIHlvdSB3YW50IHRv IHRhbGsgYWJvdXQgdXNlIGNhc2VzIChlc3BlY2lhbGx5DQo+ID4+Pj4+IG9uZXMgdGhhdCBhcmUg Y29udHJvdmVyc2lhbCEpIHRoZW4gdGhlIGNvcnJlY3QgcGxhY2UgZm9yIHRoYXQgaXMNCj4gPj4+ Pj4gaW4gYSBuZXcgaW5mb3JtYXRpdmUNCj4gPj4+PiBkcmFmdC4NCj4gPj4+Pj4gW1dBSl0gd2Ug aGF2ZSBkaXNjdXNzZWQgdGhlIHVzZSBjYXNlIGJlZm9yZSBhbmQgc3RhdGUgdGhlDQo+ID4+Pj4+ IGRpc2N1c3Npb24gcmVzdWx0cyBhdCB0aGUgYXBwZW5kaXggcGFydC4gV2Ugd2lsbCBub3QgZW1w aGFzaXMgYW5kDQo+ID4+Pj4+IGV4cGFuZCB0aGUgdXNlIGNhc2UgbW9yZS4gSWYgb25lIGRvZXMg bm90IGFncmVlIHRoZSBzdGF0ZW1lbnQgb2YNCj4gPj4+Pj4gdGhpcyBhcHBlbmRpeCwgd2UgY2Fu IGRpc2N1c3Mgb25saW5lIG9yIG9mZmxpbmUuIFdlIGp1c3QgbmVlZCB0bw0KPiA+Pj4+PiBtYWtl IHRoZSBzdGF0ZW1lbnQgaW4NCj4gPj4+PiBhcHBlbmRpeCBpcyBjb3JyZWN0Lg0KPiA+Pj4+Pg0K PiA+Pj4+PiBPdGhlcndpc2UsIGVzcGVjaWFsbHkgaWYgdGhlIGNhc2VzIGFyZSBjb250cm92ZXJz aWFsLCB0aGlzIGNhbiBiZQ0KPiA+Pj4+PiBzZWVuIGFzIGRvaW5nIGFuICJlbmQtcnVuIiB0byBh dm9pZCB0aGUgZGViYXRlIGIvYyBwZW9wbGUgd2FudCB0aGUNCj4gPj4+Pj4gZXh0ZW5zaW9uLCBi dXQgbWF5YmUgZG9uJ3QgYWdyZWUgd2l0aCB5b3VyIHVzZSBjYXNlLg0KPiA+Pj4+PiBbV0FKXSBP bmUgc2hvdWxkIHBvaW50IG91dCB3aGljaCBzdGF0ZW1lbnQgaW4gdGhlIGFwcGVuZGl4IGlzDQo+ ID4+Pj4+IGNvbnRyb3ZlcnNpYWwsIHdlIGNhbiBjb3JyZWN0IGl0LiBUaGlzIHVzZSBjYXNlIGlz IHRoZSBvcmlnaW4gb2YNCj4gPj4+Pj4gdGhpcyBkcmFmdCwgbm90IHRoZSByZXN1bHRzLg0KPiA+ Pj4+Pg0KPiA+Pj4+PiBMZWdpc2xhdG9ycyBkbyB0aGlzIHNvbWV0aW1lcyBhZGRpbmcgdGhpbmdz IHRoZXkgd2FudCBwZXJzb25hbGx5DQo+ID4+Pj4+IHRvIHBvcHVsYXIgYmlsbHMsIHRoYXQgb3Ro ZXIgcGVvcGxlIG1heSBub3Qgd2FudCwgYnV0IHNpbmNlIHBlb3BsZQ0KPiA+Pj4+PiB3YW50IHRo ZSBtYWluIGJpbGwgdGhleSB2b3RlIGZvciBpdCBhbnl3YXksIGluIHRoZSBVUyBpdCdzIGNhbGxl ZA0KPiA+Pj4+PiAiYWRkaW5nIHBvcmsiIG9yICJwb3JrIGJhcnJlbCBwb2xpdGljcyIuIDopIFtX QUpdIFRoZSBhcHBlbmRpeCBpcw0KPiA+Pj4+PiBub3QgYWRkZWQgbGF0ZXIsIGJ1dCBleGlzdCBh dCB0aGUgZmlyc3QgYmVnaW5uaW5nLiBUaGlzIGlzIHRoZQ0KPiA+Pj4+PiBvcmlnaW4gb2YgdGhl IGJpbGxzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3MsDQo+ID4+Pj4+IENocmlzLg0KPiA+Pj4+ Pg0KPiA+Pj4+Pj4gT24gT2N0IDE2LCAyMDIwLCBhdCAxMDozNyBBTSwg546L54ix5L+KIDx3YW5n YWlqdW5AdHNpbmdodWEub3JnLmNuPg0KPiA+Pj4+PiB3cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gSGksIENocmlzOg0KPiA+Pj4+Pj4gT3JpZ2luYWxseSwgdGhlIGFwcGVuZGl4 IHBhcnQgaXMgd2l0aGluIHRoZSBkb2N1bWVudCwgd2hpY2ggaXMNCj4gPj4+Pj4+IHRoZSBzdGFy dA0KPiA+Pj4+PiBwb2ludC9tYWluIG1vdGl2YXRpb24gdG8gZXh0ZW5kIHRoZSBwcmVmaXggb3Jp Z2luLg0KPiA+Pj4+Pj4gVGhlcmUgbWF5IGV4aXN0cyBvdGhlciB1c2FnZXMgb2YgdGhpcyBpbmZv cm1hdGlvbi4gUGFjayB0aGVzZQ0KPiA+Pj4+Pj4gZXhhbXBsZXMNCj4gPj4+Pj4gaW50byBzb21l IHNob3J0IHNlbnRlbmNlcyBvciBpbnRyb2R1Y3Rpb24gaXMgdmlhYmxlLCBidXQgZXhwYW5kDQo+ ID4+Pj4+IHNvbWUgb2YgdGhlbSBpcyBhbHNvIGhlbHBmdWwuDQo+ID4+Pj4+PiBBcyBJIGtub3du LCB3aGVuIHdlIHdhbnQgdG8gZG8gcHJvdG9jb2wgZXh0ZW5zaW9uLCB3ZSBzaG91bGQNCj4gPj4+ Pj4+IGFsd2F5cw0KPiA+Pj4+PiBjb252aW5jZSBvdGhlciB0aGUgcmVhc29uL21vdGl2YXRpb24v cHJvc3BlY3RzIHRvIGRvIHNvLiBPbiB0aGUNCj4gPj4+Pj4gb3RoZXIgaGFuZCwgdGhlIHVzZSBj YXNlIGRlc2NyaWJlZCBpbiB0aGUgY3VycmVudCBhcHBlbmRpeCBpcyB2ZXJ5DQo+ID4+Pj4+IHBy b21pbmVudCBmb3Igb3BlcmF0b3IgdG8gYWNjb21wbGlzaCB0aGUgVEUgdGFzayBpbiBtdWx0aS1h cmVhDQo+IGVudmlyb25tZW50Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEFpanVuIFdhbmcNCj4gPj4+ Pj4+DQo+ID4+Pj4+PiDlnKgyMDIwLTEwLTE277yMQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNA Y2hvcHBzLm9yZyZndDvlhpnpgZM6DQo+ID4+Pj4+PiAtLS0tLeWOn+Wni+mCruS7ti0tLS0tDQo+ ID4+Pj4+PiDlj5Hku7bkurrvvJogQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9y ZyZndDsNCj4gPj4+Pj4+IOWPkeS7tuaXtumXtDogMjAyMOW5tDEw5pyIMTbml6Ug5pif5pyf5LqU DQo+ID4+Pj4+PiDlhpnpgZM6IFsmcXVvdDtMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSZxdW90Ow0K PiA+Pj4+Pj4gJmx0O2dpbnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0O10NCj4g Pj4+Pj4+IOS4u+mimO+8miBSZTogW0xzcl0gV0cgTGFzdCBDYWxsDQo+ID4+Pj4+PiBkcmFmdC1p ZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IE9u IE9jdCAxNiwgMjAyMCwgYXQgMTo1MSBBTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCj4gPj4+ Pj4gPGdpbnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IEFpanVuIC0NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoZSBwb2ludCBJIGFt IG1ha2luZyBpcyB2ZXJ5IGZvY3VzZWQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGlzIGRyYWZ0 IGlzIGRlZmluaW5nIGEgcHJvdG9jb2wgZXh0ZW5zaW9uLiBBcyBzdWNoIGl0IGlzDQo+ID4+Pj4+ Pj4gbmVjZXNzYXJ5IHRoYXQgdGhpcw0KPiA+Pj4+PiBiZSBTdGFuZGFyZHMgdHJhY2sgYXMgYWRo ZXJpbmcgdG8gdGhlIG5vcm1hdGl2ZSBzdGF0ZW1lbnRzIGluIHRoZQ0KPiA+Pj4+PiBkcmFmdCBh cmUgbmVjZXNzYXJ5IGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g V2hhdCBpcyBkaXNjdXNzZWQgaW4gdGhlIEFwcGVuZGl4IGlzIGEgdXNlIGNhc2UuIEl0IGlzIG5v dA0KPiA+Pj4+Pj4+IG5vcm1hdGl2ZSBhbmQNCj4gPj4+Pj4gdGhlcmUgYXJlIHN0cm9uZyBvcGlu aW9ucyBvbiBib3RoIHNpZGVzIGFzIHRvIHdoZXRoZXIgdGhpcyBpcyBhbg0KPiA+Pj4+PiBhcHBy b3ByaWF0ZSB1c2UgY2FzZSBvciBub3QuDQo+ID4+Pj4+Pj4gSW4gdGhlIGNvbnRleHQgb2YgdGhp cyBkcmFmdCwgSSBoYXZlIG5vIGludGVyZXN0IGluIHRyeWluZyB0bw0KPiA+Pj4+Pj4+IHJlc29s dmUgb3VyDQo+ID4+Pj4+IGRpZmZlcmVuY2Ugb2Ygb3BpbmlvbiBvbiB0aGlzIHVzZSBjYXNlLiBJ IHNpbXBseSB3YW50IHRoZSBwcm90b2NvbA0KPiA+Pj4+PiBleHRlbnNpb24gdG8gbW92ZSBmb3J3 YXJkIHNvIHRoYXQgd2UgaGF2ZSBhbm90aGVyIHRvb2wgYXZhaWxhYmxlLg0KPiA+Pj4+Pj4+DQo+ ID4+Pj4+Pj4gSWYgeW91IHdhbnQgdG8gd3JpdGUgYSBkcmFmdCBvbiB0aGUgdXNlIGNhc2UgZGlz Y3Vzc2VkIGluIHRoZQ0KPiA+Pj4+Pj4+IEFwcGVuZGl4DQo+ID4+Pj4+IHBsZWFzZSBmZWVsIGZy ZWUgdG8gZG8gc28uIFRoYXQgZHJhZnQgbWF5IHZlcnkgd2VsbCBub3QgYmUNCj4gPj4+Pj4gbm9y bWF0aXZlIC0gSW5mb3JtYXRpb25hbCBvciBCQ1AgbWF5IGJlIG1vcmUgYXBwcm9wcmlhdGUgLSBi ZWNhdXNlDQo+ID4+Pj4+IGl0IHdpbGwgYmUgZGlzY3Vzc2luZyBhIGRlcGxveW1lbnQgc2NlbmFy aW8gYW5kIGEgcHJvcG9zYWwgdG8gdXNlDQo+ID4+Pj4+IGRlZmluZWQgcHJvdG9jb2wgZXh0ZW5z aW9ucyBhcyBvbmUgd2F5IHRvIHNvbHZlIHByb2JsZW1zIGluIHRoYXQNCj4gPj4+Pj4gZGVwbG95 bWVudCBzY2VuYXJpby4gU3VjaCBhIGRyYWZ0IG1pZ2h0IGFsc28gYmUgbW9yZSBhcHByb3ByaWF0 ZQ0KPiA+Pj4+PiBpbiBhbm90aGVyIFdHIChlLmcuLCBURUFTKS4gVGhlIG1lcml0cyBvZiB1c2lu ZyBwcmVmaXgNCj4gPj4+Pj4gYWR2ZXJ0aXNlbWVudHMgdG8gYnVpbGQgYSB0b3BvbG9neQ0KPiA+ Pj4+IGNvdWxkIHRoZW4gYmUgZGlzY3Vzc2VkIG9uIGl0cyBvd24uDQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+PiBQbGVhc2UgZG8gbm90IHRyeSB0byBhdm9pZCBoYXZpbmcgYSBmdWxsIGRpc2N1c3Npb24g b2YgdGhlDQo+ID4+Pj4+Pj4gbWVyaXRzIG9mIHVzaW5nDQo+ID4+Pj4+IHByZWZpeCBhZHZlcnRp c2VtZW50cyB0byBkZXJpdmUgdG9wb2xvZ3kgYnkgYWRkaW5nIGl0IHRvIGEgZHJhZnQNCj4gPj4+ Pj4gdGhhdCBpcyAoYW5kIHNob3VsZCBiZSkgZm9jdXNlZCBvbiBzaW1wbGUgcHJvdG9jb2wgZXh0 ZW5zaW9ucy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBbQXMgV0cgbWVtYmVyXQ0KPiA+Pj4+Pj4NCj4g Pj4+Pj4+IEkgZmluZCB0aGlzIHZlcnkgY29tcGVsbGluZyBhbmQgc28gc3VwcG9ydCB0aGUgcmVt b3ZhbCBvZiB0aGUNCj4gPj4+Pj4+IHJlZmVycmVkIHRvDQo+ID4+Pj4+IG5vbi1ub3JtYXRpdmUg YXBwZW5kaWNlcy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGFua3MsDQo+ID4+Pj4+PiBDaHJpcy4N Cj4gPj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGFueC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+ Pj4+ICAgIExlcw0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+Pj4gRnJvbTogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRz aW5naHVhLm9yZy5jbj4NCj4gPj4+Pj4+Pj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTUsIDIw MjAgNjo1MSBQTQ0KPiA+Pj4+Pj4+PiBUbzogJ0plZmYgVGFudHN1cmEnIDxqZWZmdGFudC5pZXRm QGdtYWlsLmNvbT47ICdKb2huIEUgRHJha2UnDQo+ID4+Pj4+Pj4+IDxqZHJha2VAanVuaXBlci5u ZXQ+DQo+ID4+Pj4+Pj4+IENjOiAnQ2hyaXN0aWFuIEhvcHBzJyA8Y2hvcHBzQGNob3Bwcy5vcmc+ OyBsc3ItY2hhaXJzQGlldGYub3JnOw0KPiA+Pj4+Pj4+PiBMZXMgR2luc2JlcmcNCj4gPj4+Pj4+ Pj4gKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsgbHNyQGlldGYub3JnOw0KPiA+Pj4+ Pj4+PiBsc3ItYWRzQGlldGYub3JnOw0KPiA+Pj4+Pj4+PiBkcmFmdC1pZXRmLSBsc3Itb3NwZi1w cmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZw0KPiA+Pj4+Pj4+PiBTdWJqZWN0OiBSRTogW0xzcl0g V0cgTGFzdCBDYWxsDQo+ID4+Pj4+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdp bmF0b3ItMDYNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gSGksIExlcywgSm9obiBhbmQgSmVmZjoN Cj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gTGV0J3MgcmVwbHkgeW91IGFsbCB0b2dldGhlci4NCj4g Pj4+Pj4+Pj4gSW4gbXkgUE9WLCBUaGUgc3RhbmRhcmQgZG9jdW1lbnQgc2hvdWxkIG5vdCBkZWZp bmUgc29sZWx5IHRoZQ0KPiA+Pj4+Pj4+PiBwcm90b2NvbCBleHRlbnNpb24sIGJ1dCB0aGVpciB1 c2FnZXMgaW4gdGhlIG5ldHdvcmsgZGVwbG95bWVudC4NCj4gPj4+Pj4+Pj4gQXMgSSBrbm93biwg YWxtb3N0IGFsbCB0aGUgSUVURiBkb2N1bWVudHMgZm9sbG93aW5nIHRoaXMgc3R5bGUuDQo+ID4+ Pj4+Pj4+IEFuZCwgYmVmb3JlIGFkb3B0aW5nIG9uZSB3b3JrLCB3ZSBoYXZlIG9mdGVuIGludGVu c2UgZGlzY3Vzc2lvbg0KPiA+Pj4+Pj4+PiBmb3Igd2hhdCdzIHRoZWlyIHVzYWdlcy4NCj4gPj4+ Pj4+Pj4gU3VjaCBkaXNjdXNzaW9uIGluIHRoZSBtYWlsIGxpc3QgYW5kIHN0YXRlbWVudHMgaW4g dGhlIGRvY3VtZW50DQo+ID4+Pj4+Pj4+IGNhbiBjZXJ0YWlubHkgYXNzaXN0IHRoZSByZWFkZXIv dXNlciBvZiB0aGUgZG9jdW1lbnQgZ2V0IHRoZQ0KPiA+Pj4+Pj4+PiBlc3NlbmNlIG9mIHRoZSBz dGFuZGFyZCwgYW5kIGZvbGxvdyB0aGVtIHVuYW1iaWd1b3VzbHkuDQo+ID4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+IFJlZ2FyZGluZyB0aGUgY29udGVudHMgb2YgYXBwZW5kaWNlcywgYXMgc3RhdGVkIGlu IHRoZSBzZWN0aW9uLA0KPiA+Pj4+Pj4+PiAiVGhlIEFwcGVuZGl4IEEgaGV1cmlzdGljIHRvIHJl YnVpbGQgdGhlIHRvcG9sb2d5IGNhbiBub3JtYWxseQ0KPiA+Pj4+Pj4+PiBiZSB1c2VkIGlmIGFs bCBsaW5rcyBhcmUgbnVtYmVyZWQuIiBJIHRoaW5rIHRoaXMgY2FuIGFwcGx5DQo+ID4+Pj4+Pj4+ IGFsbW9zdCBtb3N0IG9mIHRoZSBvcGVyYXRvcidzIG5ldHdvcmssIGFuZCBmYWNpbGl0YXRlIHRo ZQ0KPiA+Pj4+Pj4+PiBpbnRlci1hcmVhIFRFIHBhdGggY2FsY3VsYXRpb24gZm9yIGNlbnRyYWwg Y29udHJvbGxlciwgb3IgZXZlbg0KPiA+Pj4+Pj4+PiBmb3IgdGhlIGhlYWQtZW5kIHJvdXRlciB0 aGF0IGxvY2F0ZWQgaW4gb25lIGFyZWEgdGhhdCBkaWZmZXJlbnQgZnJvbQ0KPiB0aGUgdGFpbC0g ZW5kIHJvdXRlci4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gS2VlcGluZyB0aGUgY29udGVudHMg b2YgYXBwZW5kaWNlcyBkb2VzIG5vdCBoYXZlIHRoZSBuZWdhdGl2ZQ0KPiA+Pj4+Pj4+PiBpbXBh Y3Qgb2YgdGhlIHByb3RvY29sIGV4dGVuc2lvbiwgaXQgaXMganVzdCBvbmUgcmVmZXJlbmNlIGZv cg0KPiA+Pj4+Pj4+PiB0aGUgdXNhZ2Ugb2YgdGhpcyBleHRlbnNpb24uDQo+ID4+Pj4+Pj4+IE9u ZSBjYW4gc2VsZWN0IG5vdCByZWZlciB0byBpdCwgaWYgdGhlaXIgbmV0d29ya3MgYXJlIGRlcGxv eWVkDQo+ID4+Pj4+Pj4+IHdpdGggbGFyZ2UgYW1vdW50IG9mIHVubnVtYmVyZWQgbGlua3MuIEJ1 dCBmb3Igb3RoZXJzLCB0aGUNCj4gPj4+Pj4+Pj4gaGV1cmlzdGljDQo+ID4+Pj4gYXBwbGllcy4N Cj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+IEFpanVuIFdhbmcNCj4gPj4+Pj4+Pj4gQ2hpbmEgVGVsZWNvbQ0KPiA+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+Pj4+Pj4+PiBGcm9tOiBsc3ItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmxzci1ib3Vu Y2VzQGlldGYub3JnXSBPbg0KPiA+Pj4+Pj4+PiBCZWhhbGYgT2YgSmVmZiBUYW50c3VyYQ0KPiA+ Pj4+Pj4+PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMjAgNToyOCBBTQ0KPiA+Pj4+Pj4+ PiBUbzogSm9obiBFIERyYWtlIDxqZHJha2U9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4N Cj4gPj4+Pj4+Pj4gQ2M6IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBsc3It Y2hhaXJzQGlldGYub3JnOw0KPiA+Pj4+Pj4+PiBMZXMgR2luc2JlcmcNCj4gPj4+Pj4+Pj4gKGdp bnNiZXJnKSA8Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+OyBsc3JAaWV0Zi5v cmc7DQo+ID4+Pj4+Pj4+IGxzci0gYWRzQGlldGYub3JnOw0KPiA+Pj4+Pj4+PiBkcmFmdC1pZXRm LWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnDQo+ID4+Pj4+Pj4+IFN1YmplY3Q6 IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPj4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1w cmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiArMQ0KPiA+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+PiBSZWdhcmRzLA0KPiA+Pj4+Pj4+PiBKZWZmDQo+ID4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+PiBPbiBPY3QgMTUsIDIwMjAsIGF0IDExOjMzLCBKb2huIEUgRHJha2UNCj4gPj4+Pj4+ Pj4gPGpkcmFrZT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gPj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+PiBIaSwNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBJIGFncmVlIHdp dGggTGVzLiAgVGhpcyBpcyBhIHNpbXBsZSBwcm90b2NvbCBleHRlbnNpb24gZm9yIGENCj4gPj4+ Pj4+Pj4+IHNwZWNpZmljIHB1cnBvc2UNCj4gPj4+Pj4+Pj4gYW5kIHRoZXJlIGlzIG5vIHJlYXNv biB0byBpbmNsdWRlIHNwZWN1bGF0aW9uIGFib3V0IGl0cyB1c2UgZm9yDQo+ID4+Pj4+Pj4+IG90 aGVyIHB1cnBvc2VzLCBwYXJ0aWN1bGFybHkgd2hlbiBpdCBpcyBpbmhlcmVudGx5IG5vdCBzdWl0 ZWQgZm9yIHRoZW0uDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gWW91cnMgSXJyZXNwZWN0aXZl bHksDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gSm9obg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+PiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+ID4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4+Pj4gRnJv bTogTHNyIDxsc3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIExlcyBHaW5zYmVyZw0K PiA+Pj4+Pj4+Pj4+IChnaW5zYmVyZykNCj4gPj4+Pj4+Pj4+PiBTZW50OiBUaHVyc2RheSwgT2N0 b2JlciAxNSwgMjAyMCAxMjozMyBQTQ0KPiA+Pj4+Pj4+Pj4+IFRvOiBDaHJpc3RpYW4gSG9wcHMg PGNob3Bwc0BjaG9wcHMub3JnPjsgbHNyQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4gQ2M6IGxzci1j aGFpcnNAaWV0Zi5vcmc7IGxzci1hZHNAaWV0Zi5vcmc7DQo+ID4+Pj4+Pj4+Pj4gZHJhZnQtaWV0 Zi1sc3Itb3NwZi1wcmVmaXgtIG9yaWdpbmF0b3JAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+PiBTdWJq ZWN0OiBSZTogW0xzcl0gV0cgTGFzdCBDYWxsDQo+ID4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3It b3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gW0V4 dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KPiA+Pj4+Pj4+Pj4+DQo+ID4+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBJIHN1cHBvcnQgbW92aW5nIHRoaXMgZG9jdW1lbnQgZm9y d2FyZC4NCj4gPj4+Pj4+Pj4+PiBTaW1pbGFyIGZ1bmN0aW9uYWxpdHkgaW4gSVMtSVMgaGFzIHBy b3ZlZCB1c2VmdWwuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBJIHdvdWxkIGhvd2V2ZXIg bGlrZSB0byByZXBlYXQgY29tbWVudHMgSSBtYWRlIGVhcmxpZXIgaW4gdGhlDQo+ID4+Pj4+Pj4+ Pj4gcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQuDQo+ID4+Pj4+Pj4+Pj4gVGhlIGNvbnRlbnQgb2Yg dGhlIEFwcGVuZGljZXMgc2hvdWxkIGJlIHJlbW92ZWQuDQo+ID4+Pj4+Pj4+Pj4gVGhlIEFwcGVu ZGljZXMgZGVmaW5lIGFuZCBkaXNjdXNzIGRlcml2aW5nIHRvcG9sb2d5DQo+ID4+Pj4+Pj4+Pj4g aW5mb3JtYXRpb24gZnJvbSBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgLSB3aGljaCBpcyBmbGF3ZWQg YW5kDQo+ID4+Pj4+Pj4+Pj4gc2hvdWxkIG5vdCBiZQ0KPiA+Pj4+IGRvbmUuDQo+ID4+Pj4+Pj4+ Pj4gUGVyaGFwcyBtb3JlIHJlbGV2YW50LCB0aGUgcHVycG9zZSBvZiB0aGUgZG9jdW1lbnQgaXMg dG8NCj4gPj4+Pj4+Pj4+PiBkZWZpbmUgcHJvdG9jb2wgZXh0ZW5zaW9ucyBzdXBwb3J0aW5nIGFk dmVydGlzZW1lbnQgb2YgdGhlDQo+ID4+Pj4+Pj4+Pj4gb3JpZ2luYXRvcnMgb2YgYSBwcmVmaXgg YWR2ZXJ0aXNlbWVudC4gVGhlcmUgaXMgbm8gbmVlZCB0bw0KPiA+Pj4+Pj4+Pj4+IGRpc2N1c3Mg aG93IHRoaXMgbWVjaGFuaXNtIG1pZ2h0IGJlIHVzZWQgdG8gYnVpbGQgdG9wb2xvZ3kNCj4gaW5m b3JtYXRpb24uDQo+ID4+Pj4+Pj4+Pj4gVGhpcyBkb2N1bWVudCBzaG91bGQgY29uZmluZSBpdHNl bGYgdG8gZGVmaW5pbmcgdGhlIHByb3RvY29sDQo+ID4+Pj4+Pj4+Pj4gZXh0ZW5zaW9ucyAtIHNp bWlsYXIgdGhlIFJGQyA3Nzk0Lg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gSWYgdGhlIGF1 dGhvcnMgZG8gbm90IGFncmVlIHRvIGRvIHRoaXMsIEkgd291bGQgZW5jb3VyYWdlDQo+ID4+Pj4+ Pj4+Pj4gdGhpcyBwb2ludCB0byBiZSBkaXNjdXNzZWQgZHVyaW5nIElFU0cgcmV2aWV3Lg0KPiA+ Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gICBMZXMNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4+Pj4+PiBGcm9tOiBMc3IgPGxz ci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuDQo+ID4+Pj4+Pj4+Pj4+ IEhvcHBzDQo+ID4+Pj4+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNCwgMjAyMCAx MToxNSBQTQ0KPiA+Pj4+Pj4+Pj4+PiBUbzogbHNyQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+IENj OiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnOw0KPiA+Pj4+ Pj4+Pj4+PiBsc3ItY2hhaXJzQGlldGYub3JnOyBsc3ItIGFkc0BpZXRmLm9yZzsgQ2hyaXN0aWFu IEhvcHBzDQo+ID4+Pj4+Pj4+Pj4+IDxjaG9wcHNAY2hvcHBzLm9yZz4NCj4gPj4+Pj4+Pj4+Pj4g U3ViamVjdDogW0xzcl0gV0cgTGFzdCBDYWxsDQo+ID4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtbHNy LW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4g VGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTGFzdCBDYWxsLCBlbmRpbmcgYWZ0ZXIgT2N0IDI5dGgs IDIwMjAsDQo+IGZvcjoNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jDQo+ID4+Pj4+Pj4+Pj4+IC9kDQo+ID4+Pj4+Pj4+Pj4+IHJhDQo+ID4+Pj4+Pj4+Pj4+ IGZ0LWkNCj4gPj4+Pj4+Pj4+Pj4gZXQNCj4gPj4+Pj4+Pj4+Pj4gZi1sc3Itb3NwZi1wcmVmaXgt b3JpZ2luYXRvci9fXzshIU5FdDZ5TWFPLQ0KPiA+Pj4+Pj4+PiBnayFUYVN6UVRoZ2h0Q0ZPdVlQ UzJWakxxDQo+ID4+Pj4+Pj4+Pj4+IGhLIDhwMDNGZzNMOUx1Q0dYdzhDMFg2cVJRZHJIaktES0hj amtqQ2xwayQNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gVGhlIGZvbGxvd2luZyBJUFIg aGFzIGJlZW4gZmlsZWQNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4gaHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzM0NDgvX187IQ0KPiA+ Pj4+Pj4+Pj4+PiAhTkV0NnlNYU8tDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4gZ2shVGFTelFUaGdo dENGT3VZUFMyVmpMcWhLOHAwM0ZnM0w5THVDR1h3OEMwWDZxUlFkckhqS0RLSGN6DQo+ID4+Pj4+ Pj4+Pj4+IDVLdFVIUSQNCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gQXV0aG9ycywNCj4g Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gUGxlYXNlIGluZGljYXRlIHRvIHRoZSBsaXN0LCB5 b3VyIGtub3dsZWRnZSBvZiBhbnkgb3RoZXIgSVBSDQo+ID4+Pj4+Pj4+Pj4+IHJlbGF0ZWQgdG8g dGhpcyB3b3JrLg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBUaGFua3MsDQo+ID4+Pj4+ Pj4+Pj4+IENocmlzLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+PiBMc3IgbWFpbGlu ZyBsaXN0DQo+ID4+Pj4+Pj4+Pj4gTHNyQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4gaHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdA0KPiA+ Pj4+Pj4+Pj4+IGluDQo+ID4+Pj4+Pj4+Pj4gZm8NCj4gPj4+Pj4+Pj4+PiAvbHNyDQo+ID4+Pj4+ Pj4+Pj4gX187ISFORXQNCj4gPj4+Pj4+Pj4+PiA2eU1hTy0NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+DQo+IGdrIVRhU3pRVGhnaHRDRk91WVBTMlZqTHFoSzhwMDNG ZzNMOUx1Q0dYdzhDMFg2cVJRZHJIaktES0hjVWRtDQo+ID4+Pj4+Pj4+IHc4DQo+ID4+Pj4+Pj4+ Pj4gTGMkDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+IExzciBtYWlsaW5nIGxpc3QNCj4g Pj4+Pj4+Pj4+IExzckBpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNv bS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGkNCj4gPj4+Pj4+Pj4+IG5m by9sc3JfXzshIU5FdDZ5TWFPLQ0KPiBnayFTVkh2cUt4bzJrUmFHM3BOV2tkaUtHSWFlNDcyMVVL TFduZmZtbA0KPiA+Pj4+Pj4+Pj4gZTlUdm9BWndlNjRmbnpWdml6TnVqbXExTSQNCj4gPj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+Pj4+Pj4gTHNyIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+PiBMc3JAaWV0Zi5v cmcNCj4gPj4+Pj4+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluDQo+ID4+Pj4+Pj4+IGZvL2xzcl9fOyEhTkV0NnlNYU8tDQo+ IGdrIVNWSHZxS3hvMmtSYUczcE5Xa2RpS0dJYWU0NzIxVUtMV25mZm1sZTkNCj4gPj4+Pj4+Pj4g VHZvQVp3ZTY0Zm56VnZpek51am1xMU0kDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+IExzciBtYWls aW5nIGxpc3QNCj4gPj4+Pj4+PiBMc3JAaWV0Zi5vcmcNCj4gPj4+Pj4+PiBodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mDQo+ID4+ Pj4+Pj4gby9sc3JfXzshIU5FdDZ5TWFPLQ0KPiBnayFTVkh2cUt4bzJrUmFHM3BOV2tkaUtHSWFl NDcyMVVLTFduZmZtbGU5VHYNCj4gPj4+Pj4+PiBvQVp3ZTY0Zm56VnZpek51am1xMU0kDQo+ID4+ Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+IExzciBt YWlsaW5nIGxpc3QNCj4gPj4+Pj4gTHNyQGlldGYub3JnDQo+ID4+Pj4+IGh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLw0KPiA+ Pj4+PiBsc3JfXzshIU5FdDZ5TWFPLQ0KPiBnayFTVkh2cUt4bzJrUmFHM3BOV2tkaUtHSWFlNDcy MVVLTFduZmZtbGU5VHZvQVp3DQo+ID4+Pj4+IGU2NGZuelZ2aXpOdWptcTFNJA0KPiA+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4gTHNy IG1haWxpbmcgbGlzdA0KPiA+Pj4+IExzckBpZXRmLm9yZw0KPiA+Pj4+IGh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wNCj4g Pj4+PiBzcl9fOyEhTkV0NnlNYU8tDQo+IGdrIVNWSHZxS3hvMmtSYUczcE5Xa2RpS0dJYWU0NzIx VUtMV25mZm1sZTlUdm9BWndlNg0KPiA+Pj4+IDRmbnpWdml6TnVqbXExTSQNCj4gPj4NCj4gPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gTHNy IG1haWxpbmcgbGlzdA0KPiA+PiBMc3JAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo+ID4+ IF9fOyEhTkV0NnlNYU8tDQo+IGdrIVNWSHZxS3hvMmtSYUczcE5Xa2RpS0dJYWU0NzIxVUtMV25m Zm1sZTlUdm9BWndlNjRmbnoNCj4gPj4gVnZpek51am1xMU0kDQo+ID4NCj4gPg0KPiA+DQo= From nobody Mon Oct 19 07:42:26 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A958A3A0AFA; Mon, 19 Oct 2020 07:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 ANROBkbq5M-Q; Mon, 19 Oct 2020 07:42:19 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE43A0AFD; Mon, 19 Oct 2020 07:42:13 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:64126.1430900940 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-106.121.66.233?logid-c23347fea8674e979774d4ff41e07f22 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 78BFA28008D; Mon, 19 Oct 2020 22:41:22 +0800 (CST) X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id c23347fea8674e979774d4ff41e07f22 for jdrake=40juniper.net@dmarc.ietf.org; Mon Oct 19 22:42:02 2020 X-Transaction-ID: c23347fea8674e979774d4ff41e07f22 X-filter-score: filter<0> X-Real-From: wangaj3@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Sender: wangaj3@chinatelecom.cn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Aijun Wang Mime-Version: 1.0 (1.0) Message-Id: <533863DD-1DDD-47CE-AF69-07AFC0382239@chinatelecom.cn> Date: Mon, 19 Oct 2020 22:41:05 +0800 Cc: Peter Psenak , Peter Psenak , "Les Ginsberg (ginsberg)" , Christian Hopps , Aijun Wang , lsr-chairs@ietf.org, lsr@ietf.org, Jeff Tantsura , draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-ads@ietf.org To: John E Drake X-Mailer: iPhone Mail (18A373) Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:42:25 -0000 =EF=BB=BFHi, John: Would you like to illustrate your broken case more clearly and not make the c= onclusion so hurry? Aijun Wang China Telecom > On Oct 19, 2020, at 22:15, John E Drake wrote: >=20 > =EF=BB=BFAijun, >=20 > What part of "using IP address advertisement to derive topological data is= broken" do you not understand? >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > Juniper Business Use Only >=20 >> -----Original Message----- >> From: Peter Psenak >> Sent: Monday, October 19, 2020 6:32 AM >> To: Aijun Wang ; Peter Psenak >> >> Cc: Les Ginsberg (ginsberg) ; Aijun Wang >> ; Christian Hopps ; John E >> Drake ; lsr-chairs@ietf.org; lsr@ietf.org; Jeff Tants= ura >> ; draft-ietf-lsr-ospf-prefix-originator@ietf.org= ; lsr- >> ads@ietf.org >> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >> [External Email. Be cautious of content] >> Hi Aijun, >> please see inline: >>> On 19/10/2020 12:10, Aijun Wang wrote: >>> Hi. Peter, Les: >>> We have defined many extensions for protocol, but only a small part of t= hem >> are deployed. Have you ever considered the reason? >>> Adding more contents for their potential usages can certainly be helpfu= l for >> their influences, or else, they will just stay at the IETF repository. >> I disagree. RFCs are not deployment or use case documents. They exists to= >> address the interoperability. >>> More replies inline below. >>> Aijun Wang >>> China Telecom >>>> On Oct 19, 2020, at 17:14, Peter Psenak >> wrote: >>>> Aijun, >>>>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote: >>>>> Aijun - >>>>> I am not going to continue these side discussions with you. >>>>> The primary purpose of the protocol extensions are as stated in the dr= aft >> Introduction. This is analogous to the use cases for the equivalent exten= sions for >> IS-IS already approved in RFC 7794. We need the equivalent in OSPF. >>>>> You can show that you are listening to the concerns of WG members by >> removing the Appendices - in which case you have (I believe) broad suppor= t for >> moving the draft forward. >>>> I agree with Les. >>>> As a co-author, I have asked you several times to get rid of the use ca= se >> described in appendix. >>> [WAJ] Moving the expansion of this use case from body part of this draft= to its >> appendix is our initial consensus, not remove it totally. We have discuss= ed >> intensely for its application in vary situations. The discussion results a= re stated >> clearly in the appendix. >> just because you insisted and did not listen to rest of us. >>> Wish to hear more technical analysis/comments for the current statements= of >> this part from other experts, or from you if you have fresh consideration= . >> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan, >> myself) are telling you that using IP address advertisement to derive top= ological >> data is broken and you keep repeating it is valid use case and ask for mo= re >> reasoning. >> thanks, >> Peter >>>> Trying to use prefix advertisement to derive topological data is simply= >> broken. The reason we are adding the prefix originator extension to OSPF i= s NOT >> the broken use case in the appendix of the draft. >>>> thanks, >>>> Peter >>>>> You can then write a separate draft to discuss other use cases and all= ow the >> WG to discuss those other use cases w/o preventing the extensions from be= ing >> approved and deployed for the use cases which have already been >> demonstrated as useful by IS-IS. >>>>> If you remove the Appendices I can support the draft. >>>>> If you do not remove the Appendices I cannot support the draft. >>>>> Please discuss this with your co-authors and come to consensus on your= >> next step. >>>>> Les >>>>>> -----Original Message----- >>>>>> From: Aijun Wang >>>>>> Sent: Monday, October 19, 2020 12:06 AM >>>>>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps' >>>>>> >>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; >>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>> Subject: RE: [Lsr] WG Last Call >>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>> Hi, Les: >>>>>> As I stated clearly before, the appendix described in the draft is >>>>>> not the new use case. It is the start point of this draft. >>>>>> Have you noticed that the introduction part is not the final usage >>>>>> of such protocol extension information? >>>>>> Certainly, we will not expand all the possible use cases in very >>>>>> detail, but putting some of them(some interesting, prominent use >>>>>> cases) in the appendix will not hamper the protocol extension itself.= >>>>>> If the statements/descriptions in the appendix are not correct, we >>>>>> can fix it, or remove it finally. If not, why not let it be for >>>>>> reference to the user of such protocol extension? >>>>>> For the body part of this draft, we are also welcome comments. >>>>>> More replies inline below[WAJ] >>>>>> Best Regards >>>>>> Aijun Wang >>>>>> China Telecom >>>>>> -----Original Message----- >>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf >>>>>> Of Les Ginsberg (ginsberg) >>>>>> Sent: Monday, October 19, 2020 2:15 PM >>>>>> To: Aijun Wang ; 'Christian Hopps' >>>>>> >>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >>>>>> Ginsberg (ginsberg)' ; >>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>> Subject: Re: [Lsr] WG Last Call >>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>> Aijun - >>>>>> The "use case" for the protocol extensions is clearly stated in the >>>>>> Introduction: >>>>>> "The primary use case for the extensions proposed in this document is= >>>>>> to be able to identify the originator of the prefix in the network. >>>>>> In cases where multiple prefixes are advertised by a given router, i= t >>>>>> is also useful to be able to associate all these prefixes with a >>>>>> single router even when prefixes are advertised outside of the area >>>>>> in which they originated. It also helps to determine when the same >>>>>> prefix is being originated by multiple routers across areas." >>>>>> This is equivalent to language in RFC 7794 which defines the >>>>>> analogous extensions for IS-IS. >>>>>> Everything you have in the Appendix is not related to the primary >>>>>> use case - and is fact a use case which many of us have objected to. >>>>>> [WAJ] Very glad to know the false statements in the appendix. >>>>>> You are entitled to write another draft advocating for your new use >>>>>> case if you wish, but requiring that the protocol extensions in >>>>>> support of the primary use case not go forward without your new use >>>>>> case is - as Chris has stated very clearly - holding approval of >>>>>> the protocol extensions hostage to your new use case. >>>>>> [WAJ] It is not new use case. As I sated before, I am open to this >>>>>> part, but should on the conditions that the statements in this part a= re >> incorrect. >>>>>> I am asking you (yet again) not to do this. >>>>>> I cannot support the document moving forward with the content in >>>>>> the Appendices included. >>>>>> [WAJ] Would like to hear more technical analysis. >>>>>> Les >>>>>>> -----Original Message----- >>>>>>> From: Lsr On Behalf Of Aijun Wang >>>>>>> Sent: Sunday, October 18, 2020 7:08 PM >>>>>>> To: 'Christian Hopps' >>>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >>>>>>> Ginsberg (ginsberg)' ; >>>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>> Hi, Chris: >>>>>>> I think we have "put the cart before the horse". For protocol >>>>>>> extension draft, the origin is the use case. >>>>>>> And I think we will not expand OSPF protocol, just because it lack >>>>>>> something as compared with ISIS, right? >>>>>>> As I stated before, the use case in current appendix is the main >>>>>>> motivation of this draft, you can see this in main body of the >>>>>>> earlier version of this draft(from version 0 to version 5). >>>>>>> The reason that we move this part to the appendix, as that you >>>>>>> said, is to let person focus on the protocol extension itself. >>>>>>> Moving this part to appendix is acceptable, but removing it from >>>>>>> the draft will erase the origin of this document. >>>>>>> Is it reasonable that one document discusses the "origin"(of the >>>>>>> prefix), can't keep its origin? >>>>>>> More replies inline below[WAJ]. >>>>>>> Best Regards >>>>>>> Aijun Wang >>>>>>> China Telecom >>>>>>> -----Original Message----- >>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf >>>>>>> Of Christian Hopps >>>>>>> Sent: Friday, October 16, 2020 10:47 PM >>>>>>> To: =E7=8E=8B=E7=88=B1=E4=BF=8A >>>>>>> Cc: John E Drake ; Christian Hopps >>>>>>> ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) >>>>>>> ; lsr@ietf.org; Jeff Tantsura= >>>>>>> ; >>>>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org >>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>> Isn't this just adding an analogous extension that already exists in= >> RFC7794? >>>>>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the >>>>>>> companion IGP protocol, OSPF can also accomplish this. And, >>>>>>> actually, there are differences consideration in this draft for the p= rotocol >> extension. >>>>>>> I don't think we need to do a lot of convincing at this point. I >>>>>>> agree with Les, if you want to talk about use cases (especially >>>>>>> ones that are controversial!) then the correct place for that is >>>>>>> in a new informative >>>>>> draft. >>>>>>> [WAJ] we have discussed the use case before and state the >>>>>>> discussion results at the appendix part. We will not emphasis and >>>>>>> expand the use case more. If one does not agree the statement of >>>>>>> this appendix, we can discuss online or offline. We just need to >>>>>>> make the statement in >>>>>> appendix is correct. >>>>>>> Otherwise, especially if the cases are controversial, this can be >>>>>>> seen as doing an "end-run" to avoid the debate b/c people want the >>>>>>> extension, but maybe don't agree with your use case. >>>>>>> [WAJ] One should point out which statement in the appendix is >>>>>>> controversial, we can correct it. This use case is the origin of >>>>>>> this draft, not the results. >>>>>>> Legislators do this sometimes adding things they want personally >>>>>>> to popular bills, that other people may not want, but since people >>>>>>> want the main bill they vote for it anyway, in the US it's called >>>>>>> "adding pork" or "pork barrel politics". :) [WAJ] The appendix is >>>>>>> not added later, but exist at the first beginning. This is the >>>>>>> origin of the bills. >>>>>>> Thanks, >>>>>>> Chris. >>>>>>>> On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A >>>>>>> wrote: >>>>>>>> Hi, Chris: >>>>>>>> Originally, the appendix part is within the document, which is >>>>>>>> the start >>>>>>> point/main motivation to extend the prefix origin. >>>>>>>> There may exists other usages of this information. Pack these >>>>>>>> examples >>>>>>> into some short sentences or introduction is viable, but expand >>>>>>> some of them is also helpful. >>>>>>>> As I known, when we want to do protocol extension, we should >>>>>>>> always >>>>>>> convince other the reason/motivation/prospects to do so. On the >>>>>>> other hand, the use case described in the current appendix is very >>>>>>> prominent for operator to accomplish the TE task in multi-area >> environment. >>>>>>>> Aijun Wang >>>>>>>> =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps <chopps@chopps.org&g= t;=E5=86=99=E9=81=93: >>>>>>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- >>>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps <chopps@cho= pps.org> >>>>>>>> =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410=E6=9C=8816=E6= =97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94 >>>>>>>> =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)" >>>>>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org>] >>>>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call >>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) >>>>>>> wrote: >>>>>>>>> Aijun - >>>>>>>>> The point I am making is very focused. >>>>>>>>> This draft is defining a protocol extension. As such it is >>>>>>>>> necessary that this >>>>>>> be Standards track as adhering to the normative statements in the >>>>>>> draft are necessary for interoperability. >>>>>>>>> What is discussed in the Appendix is a use case. It is not >>>>>>>>> normative and >>>>>>> there are strong opinions on both sides as to whether this is an >>>>>>> appropriate use case or not. >>>>>>>>> In the context of this draft, I have no interest in trying to >>>>>>>>> resolve our >>>>>>> difference of opinion on this use case. I simply want the protocol >>>>>>> extension to move forward so that we have another tool available. >>>>>>>>> If you want to write a draft on the use case discussed in the >>>>>>>>> Appendix >>>>>>> please feel free to do so. That draft may very well not be >>>>>>> normative - Informational or BCP may be more appropriate - because >>>>>>> it will be discussing a deployment scenario and a proposal to use >>>>>>> defined protocol extensions as one way to solve problems in that >>>>>>> deployment scenario. Such a draft might also be more appropriate >>>>>>> in another WG (e.g., TEAS). The merits of using prefix >>>>>>> advertisements to build a topology >>>>>> could then be discussed on its own. >>>>>>>>> Please do not try to avoid having a full discussion of the >>>>>>>>> merits of using >>>>>>> prefix advertisements to derive topology by adding it to a draft >>>>>>> that is (and should be) focused on simple protocol extensions. >>>>>>>> [As WG member] >>>>>>>> I find this very compelling and so support the removal of the >>>>>>>> referred to >>>>>>> non-normative appendices. >>>>>>>> Thanks, >>>>>>>> Chris. >>>>>>>>> Thanx. >>>>>>>>> Les >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Aijun Wang >>>>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM >>>>>>>>>> To: 'Jeff Tantsura' ; 'John E Drake' >>>>>>>>>> >>>>>>>>>> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; >>>>>>>>>> Les Ginsberg >>>>>>>>>> (ginsberg) ; lsr@ietf.org; >>>>>>>>>> lsr-ads@ietf.org; >>>>>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org >>>>>>>>>> Subject: RE: [Lsr] WG Last Call >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>> Hi, Les, John and Jeff: >>>>>>>>>> Let's reply you all together. >>>>>>>>>> In my POV, The standard document should not define solely the >>>>>>>>>> protocol extension, but their usages in the network deployment. >>>>>>>>>> As I known, almost all the IETF documents following this style. >>>>>>>>>> And, before adopting one work, we have often intense discussion >>>>>>>>>> for what's their usages. >>>>>>>>>> Such discussion in the mail list and statements in the document >>>>>>>>>> can certainly assist the reader/user of the document get the >>>>>>>>>> essence of the standard, and follow them unambiguously. >>>>>>>>>> Regarding the contents of appendices, as stated in the section, >>>>>>>>>> "The Appendix A heuristic to rebuild the topology can normally >>>>>>>>>> be used if all links are numbered." I think this can apply >>>>>>>>>> almost most of the operator's network, and facilitate the >>>>>>>>>> inter-area TE path calculation for central controller, or even >>>>>>>>>> for the head-end router that located in one area that different f= rom >> the tail- end router. >>>>>>>>>> Keeping the contents of appendices does not have the negative >>>>>>>>>> impact of the protocol extension, it is just one reference for >>>>>>>>>> the usage of this extension. >>>>>>>>>> One can select not refer to it, if their networks are deployed >>>>>>>>>> with large amount of unnumbered links. But for others, the >>>>>>>>>> heuristic >>>>>> applies. >>>>>>>>>> Best Regards >>>>>>>>>> Aijun Wang >>>>>>>>>> China Telecom >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >>>>>>>>>> Behalf Of Jeff Tantsura >>>>>>>>>> Sent: Friday, October 16, 2020 5:28 AM >>>>>>>>>> To: John E Drake >>>>>>>>>> Cc: Christian Hopps ; lsr-chairs@ietf.org; >>>>>>>>>> Les Ginsberg >>>>>>>>>> (ginsberg) ; lsr@ietf.org;= >>>>>>>>>> lsr- ads@ietf.org; >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org >>>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>> +1 >>>>>>>>>> Regards, >>>>>>>>>> Jeff >>>>>>>>>>> On Oct 15, 2020, at 11:33, John E Drake >>>>>>>>>> wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> I agree with Les. This is a simple protocol extension for a >>>>>>>>>>> specific purpose >>>>>>>>>> and there is no reason to include speculation about its use for >>>>>>>>>> other purposes, particularly when it is inherently not suited for= them. >>>>>>>>>>> Yours Irrespectively, >>>>>>>>>>> John >>>>>>>>>>> Juniper Business Use Only >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lsr On Behalf Of Les Ginsberg >>>>>>>>>>>> (ginsberg) >>>>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM >>>>>>>>>>>> To: Christian Hopps ; lsr@ietf.org >>>>>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org >>>>>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>> [External Email. Be cautious of content] >>>>>>>>>>>> I support moving this document forward. >>>>>>>>>>>> Similar functionality in IS-IS has proved useful. >>>>>>>>>>>> I would however like to repeat comments I made earlier in the >>>>>>>>>>>> review of this document. >>>>>>>>>>>> The content of the Appendices should be removed. >>>>>>>>>>>> The Appendices define and discuss deriving topology >>>>>>>>>>>> information from prefix advertisements - which is flawed and >>>>>>>>>>>> should not be >>>>>> done. >>>>>>>>>>>> Perhaps more relevant, the purpose of the document is to >>>>>>>>>>>> define protocol extensions supporting advertisement of the >>>>>>>>>>>> originators of a prefix advertisement. There is no need to >>>>>>>>>>>> discuss how this mechanism might be used to build topology >> information. >>>>>>>>>>>> This document should confine itself to defining the protocol >>>>>>>>>>>> extensions - similar the RFC 7794. >>>>>>>>>>>> If the authors do not agree to do this, I would encourage >>>>>>>>>>>> this point to be discussed during IESG review. >>>>>>>>>>>> Les >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Lsr On Behalf Of Christian >>>>>>>>>>>>> Hopps >>>>>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM >>>>>>>>>>>>> To: lsr@ietf.org >>>>>>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>>>>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >>>>>>>>>>>>> >>>>>>>>>>>>> Subject: [Lsr] WG Last Call >>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020= , >> for: >>>>>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc >>>>>>>>>>>>> /d >>>>>>>>>>>>> ra >>>>>>>>>>>>> ft-i >>>>>>>>>>>>> et >>>>>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- >>>>>>>>>> gk!TaSzQThghtCFOuYPS2VjLq >>>>>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>>>>>>>>>>> The following IPR has been filed >>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__= ;! >>>>>>>>>>>>> !NEt6yMaO- >>>>>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>>>>>>>>>>>> 5KtUHQ$ >>>>>>>>>>>>> Authors, >>>>>>>>>>>>> Please indicate to the list, your knowledge of any other IPR >>>>>>>>>>>>> related to this work. >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Chris. >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Lsr mailing list >>>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/list >>>>>>>>>>>> in >>>>>>>>>>>> fo >>>>>>>>>>>> /lsr >>>>>>>>>>>> __;!!NEt >>>>>>>>>>>> 6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >>>>>>>>>> w8 >>>>>>>>>>>> Lc$ >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Lsr mailing list >>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>>>>>>>>>> nfo/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml >>>>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>>> _______________________________________________ >>>>>>>>>> Lsr mailing list >>>>>>>>>> Lsr@ietf.org >>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin >>>>>>>>>> fo/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9 >>>>>>>>>> TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>> _______________________________________________ >>>>>>>>> Lsr mailing list >>>>>>>>> Lsr@ietf.org >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf >>>>>>>>> o/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv >>>>>>>>> oAZwe64fnzVvizNujmq1M$ >>>>>>> _______________________________________________ >>>>>>> Lsr mailing list >>>>>>> Lsr@ietf.org >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >>>>>>> lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw >>>>>>> e64fnzVvizNujmq1M$ >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>>>> sr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6 >>>>>> 4fnzVvizNujmq1M$ >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >>>> __;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz >>>> VvizNujmq1M$ > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Mon Oct 19 07:43:23 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198AD3A0365; Mon, 19 Oct 2020 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 gfQOWEaSPO8h; Mon, 19 Oct 2020 07:43:18 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD373A0AFA; Mon, 19 Oct 2020 07:43:16 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:64126.1430900940 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-106.121.66.233?logid-c23347fea8674e979774d4ff41e07f22 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id A7C80280090; Mon, 19 Oct 2020 22:42:39 +0800 (CST) X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id c55a0d174a2444bb8678acd4eb2a41ec for jdrake=40juniper.net@dmarc.ietf.org; Mon Oct 19 22:43:08 2020 X-Transaction-ID: c55a0d174a2444bb8678acd4eb2a41ec X-filter-score: filter<0> X-Real-From: wangaj3@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Sender: wangaj3@chinatelecom.cn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Aijun Wang Mime-Version: 1.0 (1.0) Message-Id: <16446C82-481C-4D83-9A26-57335651A429@chinatelecom.cn> Date: Mon, 19 Oct 2020 22:42:24 +0800 Cc: Peter Psenak , Peter Psenak , "Les Ginsberg (ginsberg)" , Christian Hopps , Aijun Wang , lsr-chairs@ietf.org, lsr@ietf.org, Jeff Tantsura , draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-ads@ietf.org To: John E Drake X-Mailer: iPhone Mail (18A373) Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:43:21 -0000 =EF=BB=BFHi, John: Would you like to illustrate your broken case more clearly and not make the c= onclusion so hurry? Aijun Wang China Telecom > On Oct 19, 2020, at 22:15, John E Drake wrote: >=20 > =EF=BB=BFAijun, >=20 > What part of "using IP address advertisement to derive topological data is= broken" do you not understand? >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > Juniper Business Use Only >=20 >> -----Original Message----- >> From: Peter Psenak >> Sent: Monday, October 19, 2020 6:32 AM >> To: Aijun Wang ; Peter Psenak >> >> Cc: Les Ginsberg (ginsberg) ; Aijun Wang >> ; Christian Hopps ; John E >> Drake ; lsr-chairs@ietf.org; lsr@ietf.org; Jeff Tants= ura >> ; draft-ietf-lsr-ospf-prefix-originator@ietf.org= ; lsr- >> ads@ietf.org >> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >> [External Email. Be cautious of content] >> Hi Aijun, >> please see inline: >>> On 19/10/2020 12:10, Aijun Wang wrote: >>> Hi. Peter, Les: >>> We have defined many extensions for protocol, but only a small part of t= hem >> are deployed. Have you ever considered the reason? >>> Adding more contents for their potential usages can certainly be helpfu= l for >> their influences, or else, they will just stay at the IETF repository. >> I disagree. RFCs are not deployment or use case documents. They exists to= >> address the interoperability. >>> More replies inline below. >>> Aijun Wang >>> China Telecom >>>> On Oct 19, 2020, at 17:14, Peter Psenak >> wrote: >>>> Aijun, >>>>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote: >>>>> Aijun - >>>>> I am not going to continue these side discussions with you. >>>>> The primary purpose of the protocol extensions are as stated in the dr= aft >> Introduction. This is analogous to the use cases for the equivalent exten= sions for >> IS-IS already approved in RFC 7794. We need the equivalent in OSPF. >>>>> You can show that you are listening to the concerns of WG members by >> removing the Appendices - in which case you have (I believe) broad suppor= t for >> moving the draft forward. >>>> I agree with Les. >>>> As a co-author, I have asked you several times to get rid of the use ca= se >> described in appendix. >>> [WAJ] Moving the expansion of this use case from body part of this draft= to its >> appendix is our initial consensus, not remove it totally. We have discuss= ed >> intensely for its application in vary situations. The discussion results a= re stated >> clearly in the appendix. >> just because you insisted and did not listen to rest of us. >>> Wish to hear more technical analysis/comments for the current statements= of >> this part from other experts, or from you if you have fresh consideration= . >> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan, >> myself) are telling you that using IP address advertisement to derive top= ological >> data is broken and you keep repeating it is valid use case and ask for mo= re >> reasoning. >> thanks, >> Peter >>>> Trying to use prefix advertisement to derive topological data is simply= >> broken. The reason we are adding the prefix originator extension to OSPF i= s NOT >> the broken use case in the appendix of the draft. >>>> thanks, >>>> Peter >>>>> You can then write a separate draft to discuss other use cases and all= ow the >> WG to discuss those other use cases w/o preventing the extensions from be= ing >> approved and deployed for the use cases which have already been >> demonstrated as useful by IS-IS. >>>>> If you remove the Appendices I can support the draft. >>>>> If you do not remove the Appendices I cannot support the draft. >>>>> Please discuss this with your co-authors and come to consensus on your= >> next step. >>>>> Les >>>>>> -----Original Message----- >>>>>> From: Aijun Wang >>>>>> Sent: Monday, October 19, 2020 12:06 AM >>>>>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps' >>>>>> >>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; >>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>> Subject: RE: [Lsr] WG Last Call >>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>> Hi, Les: >>>>>> As I stated clearly before, the appendix described in the draft is >>>>>> not the new use case. It is the start point of this draft. >>>>>> Have you noticed that the introduction part is not the final usage >>>>>> of such protocol extension information? >>>>>> Certainly, we will not expand all the possible use cases in very >>>>>> detail, but putting some of them(some interesting, prominent use >>>>>> cases) in the appendix will not hamper the protocol extension itself.= >>>>>> If the statements/descriptions in the appendix are not correct, we >>>>>> can fix it, or remove it finally. If not, why not let it be for >>>>>> reference to the user of such protocol extension? >>>>>> For the body part of this draft, we are also welcome comments. >>>>>> More replies inline below[WAJ] >>>>>> Best Regards >>>>>> Aijun Wang >>>>>> China Telecom >>>>>> -----Original Message----- >>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf >>>>>> Of Les Ginsberg (ginsberg) >>>>>> Sent: Monday, October 19, 2020 2:15 PM >>>>>> To: Aijun Wang ; 'Christian Hopps' >>>>>> >>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >>>>>> Ginsberg (ginsberg)' ; >>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>> Subject: Re: [Lsr] WG Last Call >>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>> Aijun - >>>>>> The "use case" for the protocol extensions is clearly stated in the >>>>>> Introduction: >>>>>> "The primary use case for the extensions proposed in this document is= >>>>>> to be able to identify the originator of the prefix in the network. >>>>>> In cases where multiple prefixes are advertised by a given router, it= >>>>>> is also useful to be able to associate all these prefixes with a >>>>>> single router even when prefixes are advertised outside of the area >>>>>> in which they originated. It also helps to determine when the same >>>>>> prefix is being originated by multiple routers across areas." >>>>>> This is equivalent to language in RFC 7794 which defines the >>>>>> analogous extensions for IS-IS. >>>>>> Everything you have in the Appendix is not related to the primary >>>>>> use case - and is fact a use case which many of us have objected to. >>>>>> [WAJ] Very glad to know the false statements in the appendix. >>>>>> You are entitled to write another draft advocating for your new use >>>>>> case if you wish, but requiring that the protocol extensions in >>>>>> support of the primary use case not go forward without your new use >>>>>> case is - as Chris has stated very clearly - holding approval of >>>>>> the protocol extensions hostage to your new use case. >>>>>> [WAJ] It is not new use case. As I sated before, I am open to this >>>>>> part, but should on the conditions that the statements in this part a= re >> incorrect. >>>>>> I am asking you (yet again) not to do this. >>>>>> I cannot support the document moving forward with the content in >>>>>> the Appendices included. >>>>>> [WAJ] Would like to hear more technical analysis. >>>>>> Les >>>>>>> -----Original Message----- >>>>>>> From: Lsr On Behalf Of Aijun Wang >>>>>>> Sent: Sunday, October 18, 2020 7:08 PM >>>>>>> To: 'Christian Hopps' >>>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >>>>>>> Ginsberg (ginsberg)' ; >>>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>> Hi, Chris: >>>>>>> I think we have "put the cart before the horse". For protocol >>>>>>> extension draft, the origin is the use case. >>>>>>> And I think we will not expand OSPF protocol, just because it lack >>>>>>> something as compared with ISIS, right? >>>>>>> As I stated before, the use case in current appendix is the main >>>>>>> motivation of this draft, you can see this in main body of the >>>>>>> earlier version of this draft(from version 0 to version 5). >>>>>>> The reason that we move this part to the appendix, as that you >>>>>>> said, is to let person focus on the protocol extension itself. >>>>>>> Moving this part to appendix is acceptable, but removing it from >>>>>>> the draft will erase the origin of this document. >>>>>>> Is it reasonable that one document discusses the "origin"(of the >>>>>>> prefix), can't keep its origin? >>>>>>> More replies inline below[WAJ]. >>>>>>> Best Regards >>>>>>> Aijun Wang >>>>>>> China Telecom >>>>>>> -----Original Message----- >>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf >>>>>>> Of Christian Hopps >>>>>>> Sent: Friday, October 16, 2020 10:47 PM >>>>>>> To: =E7=8E=8B=E7=88=B1=E4=BF=8A >>>>>>> Cc: John E Drake ; Christian Hopps >>>>>>> ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) >>>>>>> ; lsr@ietf.org; Jeff Tantsura= >>>>>>> ; >>>>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org >>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>> Isn't this just adding an analogous extension that already exists in= >> RFC7794? >>>>>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the >>>>>>> companion IGP protocol, OSPF can also accomplish this. And, >>>>>>> actually, there are differences consideration in this draft for the p= rotocol >> extension. >>>>>>> I don't think we need to do a lot of convincing at this point. I >>>>>>> agree with Les, if you want to talk about use cases (especially >>>>>>> ones that are controversial!) then the correct place for that is >>>>>>> in a new informative >>>>>> draft. >>>>>>> [WAJ] we have discussed the use case before and state the >>>>>>> discussion results at the appendix part. We will not emphasis and >>>>>>> expand the use case more. If one does not agree the statement of >>>>>>> this appendix, we can discuss online or offline. We just need to >>>>>>> make the statement in >>>>>> appendix is correct. >>>>>>> Otherwise, especially if the cases are controversial, this can be >>>>>>> seen as doing an "end-run" to avoid the debate b/c people want the >>>>>>> extension, but maybe don't agree with your use case. >>>>>>> [WAJ] One should point out which statement in the appendix is >>>>>>> controversial, we can correct it. This use case is the origin of >>>>>>> this draft, not the results. >>>>>>> Legislators do this sometimes adding things they want personally >>>>>>> to popular bills, that other people may not want, but since people >>>>>>> want the main bill they vote for it anyway, in the US it's called >>>>>>> "adding pork" or "pork barrel politics". :) [WAJ] The appendix is >>>>>>> not added later, but exist at the first beginning. This is the >>>>>>> origin of the bills. >>>>>>> Thanks, >>>>>>> Chris. >>>>>>>> On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A >>>>>>> wrote: >>>>>>>> Hi, Chris: >>>>>>>> Originally, the appendix part is within the document, which is >>>>>>>> the start >>>>>>> point/main motivation to extend the prefix origin. >>>>>>>> There may exists other usages of this information. Pack these >>>>>>>> examples >>>>>>> into some short sentences or introduction is viable, but expand >>>>>>> some of them is also helpful. >>>>>>>> As I known, when we want to do protocol extension, we should >>>>>>>> always >>>>>>> convince other the reason/motivation/prospects to do so. On the >>>>>>> other hand, the use case described in the current appendix is very >>>>>>> prominent for operator to accomplish the TE task in multi-area >> environment. >>>>>>>> Aijun Wang >>>>>>>> =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps <chopps@chopps.org&g= t;=E5=86=99=E9=81=93: >>>>>>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- >>>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps <chopps@cho= pps.org> >>>>>>>> =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410=E6=9C=8816=E6= =97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94 >>>>>>>> =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)" >>>>>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org>] >>>>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call >>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) >>>>>>> wrote: >>>>>>>>> Aijun - >>>>>>>>> The point I am making is very focused. >>>>>>>>> This draft is defining a protocol extension. As such it is >>>>>>>>> necessary that this >>>>>>> be Standards track as adhering to the normative statements in the >>>>>>> draft are necessary for interoperability. >>>>>>>>> What is discussed in the Appendix is a use case. It is not >>>>>>>>> normative and >>>>>>> there are strong opinions on both sides as to whether this is an >>>>>>> appropriate use case or not. >>>>>>>>> In the context of this draft, I have no interest in trying to >>>>>>>>> resolve our >>>>>>> difference of opinion on this use case. I simply want the protocol >>>>>>> extension to move forward so that we have another tool available. >>>>>>>>> If you want to write a draft on the use case discussed in the >>>>>>>>> Appendix >>>>>>> please feel free to do so. That draft may very well not be >>>>>>> normative - Informational or BCP may be more appropriate - because >>>>>>> it will be discussing a deployment scenario and a proposal to use >>>>>>> defined protocol extensions as one way to solve problems in that >>>>>>> deployment scenario. Such a draft might also be more appropriate >>>>>>> in another WG (e.g., TEAS). The merits of using prefix >>>>>>> advertisements to build a topology >>>>>> could then be discussed on its own. >>>>>>>>> Please do not try to avoid having a full discussion of the >>>>>>>>> merits of using >>>>>>> prefix advertisements to derive topology by adding it to a draft >>>>>>> that is (and should be) focused on simple protocol extensions. >>>>>>>> [As WG member] >>>>>>>> I find this very compelling and so support the removal of the >>>>>>>> referred to >>>>>>> non-normative appendices. >>>>>>>> Thanks, >>>>>>>> Chris. >>>>>>>>> Thanx. >>>>>>>>> Les >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Aijun Wang >>>>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM >>>>>>>>>> To: 'Jeff Tantsura' ; 'John E Drake' >>>>>>>>>> >>>>>>>>>> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; >>>>>>>>>> Les Ginsberg >>>>>>>>>> (ginsberg) ; lsr@ietf.org; >>>>>>>>>> lsr-ads@ietf.org; >>>>>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org >>>>>>>>>> Subject: RE: [Lsr] WG Last Call >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>> Hi, Les, John and Jeff: >>>>>>>>>> Let's reply you all together. >>>>>>>>>> In my POV, The standard document should not define solely the >>>>>>>>>> protocol extension, but their usages in the network deployment. >>>>>>>>>> As I known, almost all the IETF documents following this style. >>>>>>>>>> And, before adopting one work, we have often intense discussion >>>>>>>>>> for what's their usages. >>>>>>>>>> Such discussion in the mail list and statements in the document >>>>>>>>>> can certainly assist the reader/user of the document get the >>>>>>>>>> essence of the standard, and follow them unambiguously. >>>>>>>>>> Regarding the contents of appendices, as stated in the section, >>>>>>>>>> "The Appendix A heuristic to rebuild the topology can normally >>>>>>>>>> be used if all links are numbered." I think this can apply >>>>>>>>>> almost most of the operator's network, and facilitate the >>>>>>>>>> inter-area TE path calculation for central controller, or even >>>>>>>>>> for the head-end router that located in one area that different f= rom >> the tail- end router. >>>>>>>>>> Keeping the contents of appendices does not have the negative >>>>>>>>>> impact of the protocol extension, it is just one reference for >>>>>>>>>> the usage of this extension. >>>>>>>>>> One can select not refer to it, if their networks are deployed >>>>>>>>>> with large amount of unnumbered links. But for others, the >>>>>>>>>> heuristic >>>>>> applies. >>>>>>>>>> Best Regards >>>>>>>>>> Aijun Wang >>>>>>>>>> China Telecom >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >>>>>>>>>> Behalf Of Jeff Tantsura >>>>>>>>>> Sent: Friday, October 16, 2020 5:28 AM >>>>>>>>>> To: John E Drake >>>>>>>>>> Cc: Christian Hopps ; lsr-chairs@ietf.org; >>>>>>>>>> Les Ginsberg >>>>>>>>>> (ginsberg) ; lsr@ietf.org;= >>>>>>>>>> lsr- ads@ietf.org; >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org >>>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>> +1 >>>>>>>>>> Regards, >>>>>>>>>> Jeff >>>>>>>>>>> On Oct 15, 2020, at 11:33, John E Drake >>>>>>>>>> wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> I agree with Les. This is a simple protocol extension for a >>>>>>>>>>> specific purpose >>>>>>>>>> and there is no reason to include speculation about its use for >>>>>>>>>> other purposes, particularly when it is inherently not suited for= them. >>>>>>>>>>> Yours Irrespectively, >>>>>>>>>>> John >>>>>>>>>>> Juniper Business Use Only >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lsr On Behalf Of Les Ginsberg >>>>>>>>>>>> (ginsberg) >>>>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM >>>>>>>>>>>> To: Christian Hopps ; lsr@ietf.org >>>>>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org >>>>>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>> [External Email. Be cautious of content] >>>>>>>>>>>> I support moving this document forward. >>>>>>>>>>>> Similar functionality in IS-IS has proved useful. >>>>>>>>>>>> I would however like to repeat comments I made earlier in the >>>>>>>>>>>> review of this document. >>>>>>>>>>>> The content of the Appendices should be removed. >>>>>>>>>>>> The Appendices define and discuss deriving topology >>>>>>>>>>>> information from prefix advertisements - which is flawed and >>>>>>>>>>>> should not be >>>>>> done. >>>>>>>>>>>> Perhaps more relevant, the purpose of the document is to >>>>>>>>>>>> define protocol extensions supporting advertisement of the >>>>>>>>>>>> originators of a prefix advertisement. There is no need to >>>>>>>>>>>> discuss how this mechanism might be used to build topology >> information. >>>>>>>>>>>> This document should confine itself to defining the protocol >>>>>>>>>>>> extensions - similar the RFC 7794. >>>>>>>>>>>> If the authors do not agree to do this, I would encourage >>>>>>>>>>>> this point to be discussed during IESG review. >>>>>>>>>>>> Les >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Lsr On Behalf Of Christian >>>>>>>>>>>>> Hopps >>>>>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM >>>>>>>>>>>>> To: lsr@ietf.org >>>>>>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>>>>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >>>>>>>>>>>>> >>>>>>>>>>>>> Subject: [Lsr] WG Last Call >>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020= , >> for: >>>>>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc >>>>>>>>>>>>> /d >>>>>>>>>>>>> ra >>>>>>>>>>>>> ft-i >>>>>>>>>>>>> et >>>>>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- >>>>>>>>>> gk!TaSzQThghtCFOuYPS2VjLq >>>>>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>>>>>>>>>>> The following IPR has been filed >>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__= ;! >>>>>>>>>>>>> !NEt6yMaO- >>>>>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>>>>>>>>>>>> 5KtUHQ$ >>>>>>>>>>>>> Authors, >>>>>>>>>>>>> Please indicate to the list, your knowledge of any other IPR >>>>>>>>>>>>> related to this work. >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Chris. >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Lsr mailing list >>>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/list >>>>>>>>>>>> in >>>>>>>>>>>> fo >>>>>>>>>>>> /lsr >>>>>>>>>>>> __;!!NEt >>>>>>>>>>>> 6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >>>>>>>>>> w8 >>>>>>>>>>>> Lc$ >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Lsr mailing list >>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>>>>>>>>>> nfo/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml >>>>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>>> _______________________________________________ >>>>>>>>>> Lsr mailing list >>>>>>>>>> Lsr@ietf.org >>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin >>>>>>>>>> fo/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9 >>>>>>>>>> TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>> _______________________________________________ >>>>>>>>> Lsr mailing list >>>>>>>>> Lsr@ietf.org >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf >>>>>>>>> o/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv >>>>>>>>> oAZwe64fnzVvizNujmq1M$ >>>>>>> _______________________________________________ >>>>>>> Lsr mailing list >>>>>>> Lsr@ietf.org >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >>>>>>> lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw >>>>>>> e64fnzVvizNujmq1M$ >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>>>> sr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6 >>>>>> 4fnzVvizNujmq1M$ >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >>>> __;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz >>>> VvizNujmq1M$ > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Mon Oct 19 07:50:42 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712FA3A03C9; Mon, 19 Oct 2020 07:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 lT5-7RN4ar9r; Mon, 19 Oct 2020 07:50:36 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id 5B04A3A0B10; Mon, 19 Oct 2020 07:50:33 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:64126.1430900940 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-106.121.66.233?logid-c23347fea8674e979774d4ff41e07f22 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id C3D4C28008E; Mon, 19 Oct 2020 22:42:02 +0800 (CST) X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn Received: from ([172.18.0.48]) by App0024 with ESMTP id a1984f098bfd4670a67a664b8d41dd45 for jdrake=40juniper.net@dmarc.ietf.org; Mon Oct 19 22:42:38 2020 X-Transaction-ID: a1984f098bfd4670a67a664b8d41dd45 X-filter-score: filter<0> X-Real-From: wangaj3@chinatelecom.cn X-Receive-IP: 172.18.0.48 X-MEDUSA-Status: 0 Sender: wangaj3@chinatelecom.cn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Aijun Wang Mime-Version: 1.0 (1.0) Message-Id: <286E3DC2-C8EC-4AAB-BF46-A2018E9341B5@chinatelecom.cn> Date: Mon, 19 Oct 2020 22:41:38 +0800 Cc: Peter Psenak , Peter Psenak , "Les Ginsberg (ginsberg)" , Christian Hopps , Aijun Wang , lsr-chairs@ietf.org, lsr@ietf.org, Jeff Tantsura , draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-ads@ietf.org To: John E Drake X-Mailer: iPhone Mail (18A373) Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:50:40 -0000 =EF=BB=BFHi, John: Would you like to illustrate your broken case more clearly and not make the c= onclusion so hurry? Aijun Wang China Telecom > On Oct 19, 2020, at 22:15, John E Drake wrote: >=20 > =EF=BB=BFAijun, >=20 > What part of "using IP address advertisement to derive topological data is= broken" do you not understand? >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > Juniper Business Use Only >=20 >> -----Original Message----- >> From: Peter Psenak >> Sent: Monday, October 19, 2020 6:32 AM >> To: Aijun Wang ; Peter Psenak >> >> Cc: Les Ginsberg (ginsberg) ; Aijun Wang >> ; Christian Hopps ; John E >> Drake ; lsr-chairs@ietf.org; lsr@ietf.org; Jeff Tants= ura >> ; draft-ietf-lsr-ospf-prefix-originator@ietf.org= ; lsr- >> ads@ietf.org >> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >> [External Email. Be cautious of content] >> Hi Aijun, >> please see inline: >>> On 19/10/2020 12:10, Aijun Wang wrote: >>> Hi. Peter, Les: >>> We have defined many extensions for protocol, but only a small part of t= hem >> are deployed. Have you ever considered the reason? >>> Adding more contents for their potential usages can certainly be helpfu= l for >> their influences, or else, they will just stay at the IETF repository. >> I disagree. RFCs are not deployment or use case documents. They exists to= >> address the interoperability. >>> More replies inline below. >>> Aijun Wang >>> China Telecom >>>> On Oct 19, 2020, at 17:14, Peter Psenak >> wrote: >>>> Aijun, >>>>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote: >>>>> Aijun - >>>>> I am not going to continue these side discussions with you. >>>>> The primary purpose of the protocol extensions are as stated in the dr= aft >> Introduction. This is analogous to the use cases for the equivalent exten= sions for >> IS-IS already approved in RFC 7794. We need the equivalent in OSPF. >>>>> You can show that you are listening to the concerns of WG members by >> removing the Appendices - in which case you have (I believe) broad suppor= t for >> moving the draft forward. >>>> I agree with Les. >>>> As a co-author, I have asked you several times to get rid of the use ca= se >> described in appendix. >>> [WAJ] Moving the expansion of this use case from body part of this draft= to its >> appendix is our initial consensus, not remove it totally. We have discuss= ed >> intensely for its application in vary situations. The discussion results a= re stated >> clearly in the appendix. >> just because you insisted and did not listen to rest of us. >>> Wish to hear more technical analysis/comments for the current statements= of >> this part from other experts, or from you if you have fresh consideration= . >> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan, >> myself) are telling you that using IP address advertisement to derive top= ological >> data is broken and you keep repeating it is valid use case and ask for mo= re >> reasoning. >> thanks, >> Peter >>>> Trying to use prefix advertisement to derive topological data is simply= >> broken. The reason we are adding the prefix originator extension to OSPF i= s NOT >> the broken use case in the appendix of the draft. >>>> thanks, >>>> Peter >>>>> You can then write a separate draft to discuss other use cases and all= ow the >> WG to discuss those other use cases w/o preventing the extensions from be= ing >> approved and deployed for the use cases which have already been >> demonstrated as useful by IS-IS. >>>>> If you remove the Appendices I can support the draft. >>>>> If you do not remove the Appendices I cannot support the draft. >>>>> Please discuss this with your co-authors and come to consensus on your= >> next step. >>>>> Les >>>>>> -----Original Message----- >>>>>> From: Aijun Wang >>>>>> Sent: Monday, October 19, 2020 12:06 AM >>>>>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps' >>>>>> >>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; >>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>> Subject: RE: [Lsr] WG Last Call >>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>> Hi, Les: >>>>>> As I stated clearly before, the appendix described in the draft is >>>>>> not the new use case. It is the start point of this draft. >>>>>> Have you noticed that the introduction part is not the final usage >>>>>> of such protocol extension information? >>>>>> Certainly, we will not expand all the possible use cases in very >>>>>> detail, but putting some of them(some interesting, prominent use >>>>>> cases) in the appendix will not hamper the protocol extension itself.= >>>>>> If the statements/descriptions in the appendix are not correct, we >>>>>> can fix it, or remove it finally. If not, why not let it be for >>>>>> reference to the user of such protocol extension? >>>>>> For the body part of this draft, we are also welcome comments. >>>>>> More replies inline below[WAJ] >>>>>> Best Regards >>>>>> Aijun Wang >>>>>> China Telecom >>>>>> -----Original Message----- >>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf >>>>>> Of Les Ginsberg (ginsberg) >>>>>> Sent: Monday, October 19, 2020 2:15 PM >>>>>> To: Aijun Wang ; 'Christian Hopps' >>>>>> >>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >>>>>> Ginsberg (ginsberg)' ; >>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>> Subject: Re: [Lsr] WG Last Call >>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>> Aijun - >>>>>> The "use case" for the protocol extensions is clearly stated in the >>>>>> Introduction: >>>>>> "The primary use case for the extensions proposed in this document is= >>>>>> to be able to identify the originator of the prefix in the network. >>>>>> In cases where multiple prefixes are advertised by a given router, it= >>>>>> is also useful to be able to associate all these prefixes with a >>>>>> single router even when prefixes are advertised outside of the area >>>>>> in which they originated. It also helps to determine when the same >>>>>> prefix is being originated by multiple routers across areas." >>>>>> This is equivalent to language in RFC 7794 which defines the >>>>>> analogous extensions for IS-IS. >>>>>> Everything you have in the Appendix is not related to the primary >>>>>> use case - and is fact a use case which many of us have objected to. >>>>>> [WAJ] Very glad to know the false statements in the appendix. >>>>>> You are entitled to write another draft advocating for your new use >>>>>> case if you wish, but requiring that the protocol extensions in >>>>>> support of the primary use case not go forward without your new use >>>>>> case is - as Chris has stated very clearly - holding approval of >>>>>> the protocol extensions hostage to your new use case. >>>>>> [WAJ] It is not new use case. As I sated before, I am open to this >>>>>> part, but should on the conditions that the statements in this part a= re >> incorrect. >>>>>> I am asking you (yet again) not to do this. >>>>>> I cannot support the document moving forward with the content in >>>>>> the Appendices included. >>>>>> [WAJ] Would like to hear more technical analysis. >>>>>> Les >>>>>>> -----Original Message----- >>>>>>> From: Lsr On Behalf Of Aijun Wang >>>>>>> Sent: Sunday, October 18, 2020 7:08 PM >>>>>>> To: 'Christian Hopps' >>>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; 'Les >>>>>>> Ginsberg (ginsberg)' ; >>>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>> Hi, Chris: >>>>>>> I think we have "put the cart before the horse". For protocol >>>>>>> extension draft, the origin is the use case. >>>>>>> And I think we will not expand OSPF protocol, just because it lack >>>>>>> something as compared with ISIS, right? >>>>>>> As I stated before, the use case in current appendix is the main >>>>>>> motivation of this draft, you can see this in main body of the >>>>>>> earlier version of this draft(from version 0 to version 5). >>>>>>> The reason that we move this part to the appendix, as that you >>>>>>> said, is to let person focus on the protocol extension itself. >>>>>>> Moving this part to appendix is acceptable, but removing it from >>>>>>> the draft will erase the origin of this document. >>>>>>> Is it reasonable that one document discusses the "origin"(of the >>>>>>> prefix), can't keep its origin? >>>>>>> More replies inline below[WAJ]. >>>>>>> Best Regards >>>>>>> Aijun Wang >>>>>>> China Telecom >>>>>>> -----Original Message----- >>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On Behalf >>>>>>> Of Christian Hopps >>>>>>> Sent: Friday, October 16, 2020 10:47 PM >>>>>>> To: =E7=8E=8B=E7=88=B1=E4=BF=8A >>>>>>> Cc: John E Drake ; Christian Hopps >>>>>>> ; lsr-chairs@ietf.org; Les Ginsberg (ginsberg) >>>>>>> ; lsr@ietf.org; Jeff Tantsura= >>>>>>> ; >>>>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org >>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>> Isn't this just adding an analogous extension that already exists in= >> RFC7794? >>>>>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the >>>>>>> companion IGP protocol, OSPF can also accomplish this. And, >>>>>>> actually, there are differences consideration in this draft for the p= rotocol >> extension. >>>>>>> I don't think we need to do a lot of convincing at this point. I >>>>>>> agree with Les, if you want to talk about use cases (especially >>>>>>> ones that are controversial!) then the correct place for that is >>>>>>> in a new informative >>>>>> draft. >>>>>>> [WAJ] we have discussed the use case before and state the >>>>>>> discussion results at the appendix part. We will not emphasis and >>>>>>> expand the use case more. If one does not agree the statement of >>>>>>> this appendix, we can discuss online or offline. We just need to >>>>>>> make the statement in >>>>>> appendix is correct. >>>>>>> Otherwise, especially if the cases are controversial, this can be >>>>>>> seen as doing an "end-run" to avoid the debate b/c people want the >>>>>>> extension, but maybe don't agree with your use case. >>>>>>> [WAJ] One should point out which statement in the appendix is >>>>>>> controversial, we can correct it. This use case is the origin of >>>>>>> this draft, not the results. >>>>>>> Legislators do this sometimes adding things they want personally >>>>>>> to popular bills, that other people may not want, but since people >>>>>>> want the main bill they vote for it anyway, in the US it's called >>>>>>> "adding pork" or "pork barrel politics". :) [WAJ] The appendix is >>>>>>> not added later, but exist at the first beginning. This is the >>>>>>> origin of the bills. >>>>>>> Thanks, >>>>>>> Chris. >>>>>>>> On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A >>>>>>> wrote: >>>>>>>> Hi, Chris: >>>>>>>> Originally, the appendix part is within the document, which is >>>>>>>> the start >>>>>>> point/main motivation to extend the prefix origin. >>>>>>>> There may exists other usages of this information. Pack these >>>>>>>> examples >>>>>>> into some short sentences or introduction is viable, but expand >>>>>>> some of them is also helpful. >>>>>>>> As I known, when we want to do protocol extension, we should >>>>>>>> always >>>>>>> convince other the reason/motivation/prospects to do so. On the >>>>>>> other hand, the use case described in the current appendix is very >>>>>>> prominent for operator to accomplish the TE task in multi-area >> environment. >>>>>>>> Aijun Wang >>>>>>>> =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps <chopps@chopps.org&g= t;=E5=86=99=E9=81=93: >>>>>>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- >>>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps <chopps@cho= pps.org> >>>>>>>> =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410=E6=9C=8816=E6= =97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94 >>>>>>>> =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)" >>>>>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org>] >>>>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call >>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) >>>>>>> wrote: >>>>>>>>> Aijun - >>>>>>>>> The point I am making is very focused. >>>>>>>>> This draft is defining a protocol extension. As such it is >>>>>>>>> necessary that this >>>>>>> be Standards track as adhering to the normative statements in the >>>>>>> draft are necessary for interoperability. >>>>>>>>> What is discussed in the Appendix is a use case. It is not >>>>>>>>> normative and >>>>>>> there are strong opinions on both sides as to whether this is an >>>>>>> appropriate use case or not. >>>>>>>>> In the context of this draft, I have no interest in trying to >>>>>>>>> resolve our >>>>>>> difference of opinion on this use case. I simply want the protocol >>>>>>> extension to move forward so that we have another tool available. >>>>>>>>> If you want to write a draft on the use case discussed in the >>>>>>>>> Appendix >>>>>>> please feel free to do so. That draft may very well not be >>>>>>> normative - Informational or BCP may be more appropriate - because >>>>>>> it will be discussing a deployment scenario and a proposal to use >>>>>>> defined protocol extensions as one way to solve problems in that >>>>>>> deployment scenario. Such a draft might also be more appropriate >>>>>>> in another WG (e.g., TEAS). The merits of using prefix >>>>>>> advertisements to build a topology >>>>>> could then be discussed on its own. >>>>>>>>> Please do not try to avoid having a full discussion of the >>>>>>>>> merits of using >>>>>>> prefix advertisements to derive topology by adding it to a draft >>>>>>> that is (and should be) focused on simple protocol extensions. >>>>>>>> [As WG member] >>>>>>>> I find this very compelling and so support the removal of the >>>>>>>> referred to >>>>>>> non-normative appendices. >>>>>>>> Thanks, >>>>>>>> Chris. >>>>>>>>> Thanx. >>>>>>>>> Les >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Aijun Wang >>>>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM >>>>>>>>>> To: 'Jeff Tantsura' ; 'John E Drake' >>>>>>>>>> >>>>>>>>>> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; >>>>>>>>>> Les Ginsberg >>>>>>>>>> (ginsberg) ; lsr@ietf.org; >>>>>>>>>> lsr-ads@ietf.org; >>>>>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org >>>>>>>>>> Subject: RE: [Lsr] WG Last Call >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>> Hi, Les, John and Jeff: >>>>>>>>>> Let's reply you all together. >>>>>>>>>> In my POV, The standard document should not define solely the >>>>>>>>>> protocol extension, but their usages in the network deployment. >>>>>>>>>> As I known, almost all the IETF documents following this style. >>>>>>>>>> And, before adopting one work, we have often intense discussion >>>>>>>>>> for what's their usages. >>>>>>>>>> Such discussion in the mail list and statements in the document >>>>>>>>>> can certainly assist the reader/user of the document get the >>>>>>>>>> essence of the standard, and follow them unambiguously. >>>>>>>>>> Regarding the contents of appendices, as stated in the section, >>>>>>>>>> "The Appendix A heuristic to rebuild the topology can normally >>>>>>>>>> be used if all links are numbered." I think this can apply >>>>>>>>>> almost most of the operator's network, and facilitate the >>>>>>>>>> inter-area TE path calculation for central controller, or even >>>>>>>>>> for the head-end router that located in one area that different f= rom >> the tail- end router. >>>>>>>>>> Keeping the contents of appendices does not have the negative >>>>>>>>>> impact of the protocol extension, it is just one reference for >>>>>>>>>> the usage of this extension. >>>>>>>>>> One can select not refer to it, if their networks are deployed >>>>>>>>>> with large amount of unnumbered links. But for others, the >>>>>>>>>> heuristic >>>>>> applies. >>>>>>>>>> Best Regards >>>>>>>>>> Aijun Wang >>>>>>>>>> China Telecom >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >>>>>>>>>> Behalf Of Jeff Tantsura >>>>>>>>>> Sent: Friday, October 16, 2020 5:28 AM >>>>>>>>>> To: John E Drake >>>>>>>>>> Cc: Christian Hopps ; lsr-chairs@ietf.org; >>>>>>>>>> Les Ginsberg >>>>>>>>>> (ginsberg) ; lsr@ietf.org;= >>>>>>>>>> lsr- ads@ietf.org; >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org >>>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>> +1 >>>>>>>>>> Regards, >>>>>>>>>> Jeff >>>>>>>>>>> On Oct 15, 2020, at 11:33, John E Drake >>>>>>>>>> wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> I agree with Les. This is a simple protocol extension for a >>>>>>>>>>> specific purpose >>>>>>>>>> and there is no reason to include speculation about its use for >>>>>>>>>> other purposes, particularly when it is inherently not suited for= them. >>>>>>>>>>> Yours Irrespectively, >>>>>>>>>>> John >>>>>>>>>>> Juniper Business Use Only >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Lsr On Behalf Of Les Ginsberg >>>>>>>>>>>> (ginsberg) >>>>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM >>>>>>>>>>>> To: Christian Hopps ; lsr@ietf.org >>>>>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org >>>>>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>> [External Email. Be cautious of content] >>>>>>>>>>>> I support moving this document forward. >>>>>>>>>>>> Similar functionality in IS-IS has proved useful. >>>>>>>>>>>> I would however like to repeat comments I made earlier in the >>>>>>>>>>>> review of this document. >>>>>>>>>>>> The content of the Appendices should be removed. >>>>>>>>>>>> The Appendices define and discuss deriving topology >>>>>>>>>>>> information from prefix advertisements - which is flawed and >>>>>>>>>>>> should not be >>>>>> done. >>>>>>>>>>>> Perhaps more relevant, the purpose of the document is to >>>>>>>>>>>> define protocol extensions supporting advertisement of the >>>>>>>>>>>> originators of a prefix advertisement. There is no need to >>>>>>>>>>>> discuss how this mechanism might be used to build topology >> information. >>>>>>>>>>>> This document should confine itself to defining the protocol >>>>>>>>>>>> extensions - similar the RFC 7794. >>>>>>>>>>>> If the authors do not agree to do this, I would encourage >>>>>>>>>>>> this point to be discussed during IESG review. >>>>>>>>>>>> Les >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Lsr On Behalf Of Christian >>>>>>>>>>>>> Hopps >>>>>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM >>>>>>>>>>>>> To: lsr@ietf.org >>>>>>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>>>>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >>>>>>>>>>>>> >>>>>>>>>>>>> Subject: [Lsr] WG Last Call >>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020= , >> for: >>>>>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc >>>>>>>>>>>>> /d >>>>>>>>>>>>> ra >>>>>>>>>>>>> ft-i >>>>>>>>>>>>> et >>>>>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- >>>>>>>>>> gk!TaSzQThghtCFOuYPS2VjLq >>>>>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>>>>>>>>>>> The following IPR has been filed >>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__= ;! >>>>>>>>>>>>> !NEt6yMaO- >>>>>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>>>>>>>>>>>> 5KtUHQ$ >>>>>>>>>>>>> Authors, >>>>>>>>>>>>> Please indicate to the list, your knowledge of any other IPR >>>>>>>>>>>>> related to this work. >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Chris. >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Lsr mailing list >>>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/list >>>>>>>>>>>> in >>>>>>>>>>>> fo >>>>>>>>>>>> /lsr >>>>>>>>>>>> __;!!NEt >>>>>>>>>>>> 6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >>>>>>>>>> w8 >>>>>>>>>>>> Lc$ >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Lsr mailing list >>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>>>>>>>>>> nfo/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml >>>>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>>> _______________________________________________ >>>>>>>>>> Lsr mailing list >>>>>>>>>> Lsr@ietf.org >>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin >>>>>>>>>> fo/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9 >>>>>>>>>> TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>> _______________________________________________ >>>>>>>>> Lsr mailing list >>>>>>>>> Lsr@ietf.org >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf >>>>>>>>> o/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv >>>>>>>>> oAZwe64fnzVvizNujmq1M$ >>>>>>> _______________________________________________ >>>>>>> Lsr mailing list >>>>>>> Lsr@ietf.org >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >>>>>>> lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw >>>>>>> e64fnzVvizNujmq1M$ >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>>>> sr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6 >>>>>> 4fnzVvizNujmq1M$ >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >>>> __;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz >>>> VvizNujmq1M$ > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Mon Oct 19 07:51:56 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B203A0B0C; Mon, 19 Oct 2020 07:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=r8tviAZj; dkim=pass (1024-bit key) header.d=juniper.net header.b=Pb1lAsmz 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 SYPqWuZ7ghwQ; Mon, 19 Oct 2020 07:51:51 -0700 (PDT) Received: from mx0b-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 945CB3A0B04; Mon, 19 Oct 2020 07:51:51 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09JEhY9d014148; Mon, 19 Oct 2020 07:51:40 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=AGqBE5GyrDaWKrv1nh98cQyeu61tIx1UFsfhzuzLGvc=; b=r8tviAZjphOM+sHHKz5lB5eZyAzYcqSCRjK9r76+w1VpwBMGgMHxQzdsYS4rQXx6kBct 9aAsIwXhvnp0VsCWRtL1+uUbyeCsiovOAHeMhh5HEt5AQPnuUYBLChvZvU+SSPBE5Lha SwD1v1IjC4cwkqNKsWSGCM8EAxX7Uk4SHeAqr0LouZXtuJ3yVkzHA5DyENbsFG1pyLBM Mdo3YDfILSVNm0LkghSBly5pNBzQ0tYUsEH3EouMgDMDFVbVme7xdXDePZVPbZuPz0Ru W+q8MPf3rngQ2qgX6NtHO+Y1c5Vr7ggljkd4znzaDsHYcR6tXwQmLsPZNXKXEEwxTLHQ kw== Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2047.outbound.protection.outlook.com [104.47.74.47]) by mx0a-00273201.pphosted.com with ESMTP id 348xans52b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 07:51:40 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lc3kGBVI2qpZRF15GkOzI3OBmF9lXTeSVLLIqznOACgrQbNwRNa/it9OKvQgSiDN6a9NymjNWpE1r6qeTO4Xr1NjHcpD07fU0PomjgoaUhJ0gdjD1/ltWtzXqtT82c1Tz5UDgEeCqhuvHg7PAxsVDDU+bcplTsjSCmKboffSzverUTgKYaTW616Gtgn4Sh8gat5mN/oCLo/6f0DLYack0VsAL+m0KRTDit/EoA18WGEIIQx9X+fSlM/1QcSc0U25EciXHrFrtOFWleqGbwwnSPKp9EUBitqhkU1tI7I0tkLwKEv8YLcjPGNvrdfHdbBFLEoOHoqjO+2KeGlVKEa98A== 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=AGqBE5GyrDaWKrv1nh98cQyeu61tIx1UFsfhzuzLGvc=; b=jjOiNeRtLUyuWmrqMGmfM+M6rlA50ec8ei5nJk/EQ2omX2hKG5N1OLfJh2lb8M9f3uwMgicgBo0cOtC8faJQ7ox1keDdtARyTbTvAjEVdINI+Rzr7ZF79Y2Z3v8I4XlwsK8h/YaSQY7lidOz37o6/ZuhcQ5cgOzutEkxDs607pqcAotw6zOCTI9wlZ3gtS3ER6WgbyqamFhQbnYlpoB3//LZhhL2noa38DKpHjRzOCYRjbBc8CsYvxL8gKWGlQYJ8Yk/RLqnBNuL7yNGEdM9loGv9a22uzfFhsOL2Jp2rtokPok5GyGcaRefl79JONxCK17Beq6YYiAG8d7OY3bW8Q== 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=AGqBE5GyrDaWKrv1nh98cQyeu61tIx1UFsfhzuzLGvc=; b=Pb1lAsmzQ97CHtgyUwDm4DEOrYiJ1zGLocFszdr5dGFADqvu1HT69u7vqbImQz79Cfa0YnzMw0xGZMicS5fLVY9BM67Hv83oNgIL2XufoyjGo/1o3DUL9Tsof7CHNClJrL89cskMNxSHeuhoKUG93/maLryklwf073EWA93lxyM= Received: from DM5PR05MB3388.namprd05.prod.outlook.com (2603:10b6:4:40::18) by DM6PR05MB4332.namprd05.prod.outlook.com (2603:10b6:5:9c::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.8; Mon, 19 Oct 2020 14:51:38 +0000 Received: from DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865]) by DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865%7]) with mapi id 15.20.3499.015; Mon, 19 Oct 2020 14:51:37 +0000 From: John E Drake To: "wangaj3@chinatelecom.cn" CC: Peter Psenak , Peter Psenak , "Les Ginsberg (ginsberg)" , Christian Hopps , Aijun Wang , "lsr-chairs@ietf.org" , "lsr@ietf.org" , Jeff Tantsura , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWpiYR0KcCJ8mdqUel/hfY/2+TFqmfAeew Date: Mon, 19 Oct 2020 14:51:37 +0000 Message-ID: References: <533863DD-1DDD-47CE-AF69-07AFC0382239@chinatelecom.cn> In-Reply-To: <533863DD-1DDD-47CE-AF69-07AFC0382239@chinatelecom.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-19T14:51:35Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=51711ba8-2b75-466c-860b-a332d1be418a; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: chinatelecom.cn; dkim=none (message not signed) header.d=none;chinatelecom.cn; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cae0cc3e-79cf-4785-8aeb-08d8743e7b51 x-ms-traffictypediagnostic: DM6PR05MB4332: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q6LS6jnxJrJlSKhFTeS/MGwBnLjnn3CAnCqh1DuXBMDuwcR2jOL8yRBm7gP12clKReNOEqK63Qh826JfrmhW5y6FgJ1vZBqd6aKgGWAmJiuUEy7RCisI4XG9xTVhKv4HnACLkUGTQObrnLyDh3Zne0KavHeN/Y0jcNoA/U+DgTBEiisG6XkZ18X1Q4BwbDDFo+jb+mCfMGCuKlBfmys6NfYM6gdB2mIDluIKeX4fLqdN4MZBhM3gOx1btnggipMVXTOHhuENFp/WXhD6mbWarV03qgQTZIOrX6wabvlxCyg4JItB0gdvFgnBK+kujmq1lsqeJY5pgfvqt5X5gp6rqje17IamEG9ZHvkuLBRJNq+Tp7dU1gneTV1clwNBMqcLJlJjJo/+sGsRH0DznYh2+w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3388.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(136003)(376002)(39860400002)(346002)(186003)(2906002)(54906003)(33656002)(478600001)(316002)(71200400001)(966005)(7696005)(53546011)(6506007)(7416002)(6916009)(26005)(66476007)(76116006)(64756008)(66446008)(66556008)(8936002)(5660300002)(30864003)(4326008)(9686003)(86362001)(55016002)(52536014)(66574015)(8676002)(66946007)(83380400001)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: HFJZ16fcGmMTgcreyeAJUDzDfMefVWIrDASl5tWPoGgPYN2O7uVrtASa2QUNZ19picpZCURnOv8yfgjSN0BxYJ6u4Kh8LDReDnREipekqYkgYuU07fYva8yzszaUKNv8ucRdZy2aYlkTp8+f9Lti1tVSLyxrKbAJomRFp1a73GlrQnTrDM9W4jZx5q/TfB7fDs546hceBTMGJKPRRoNHH0cweI/w5ddPgArkPqA8QYugWYP/PPs3TA4/TlfmEBy2SQwgG2CgD08AFOn3kf3m9v8r3cXGDq+a3JHM+j6tO8TvG2Urznd6czbGhig1Yoc02tRvH/WcUw1zH68Uo60WKAJ4TmLISM3zx7ByzAyqjUfo42/geEado3bH5Pp1fykavr11WpPDrHZ9NQ0MCZZG3Kb2uIyd3WJcLY006z1buJrEJu/dqe8GR5h7MlnDyD+6TYk/nzSu26Vr76slF631uhid3nYvJbgsHGSJR3DHV+4Au2ih+dg0GVZSE9XBoTJ57/84a2PkwVurBFwkmY+qXi1td750CBAYQF7ZW1FzstuQ7pA1YiQvz3CF+6qb82KBY3NPNccNVdTniafLE+3yW9ARphoXTq1/xU11RkO8jnAE02yFN7+JAfW0bGC8W5gwKDQzOZ1RzUzJ4D31IO/B9g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR05MB3388.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cae0cc3e-79cf-4785-8aeb-08d8743e7b51 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 14:51:37.6902 (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: 2ntHA9uTB2JfjffDmdy4QSTIcsxquHBL//QaiLCmpX0WuuhlXEa+cQCdP5H9EFE4I/5jlD9VcCLJD+KTe+02KA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4332 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-19_06:2020-10-16, 2020-10-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 lowpriorityscore=0 spamscore=0 phishscore=0 suspectscore=0 priorityscore=1501 adultscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190102 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 14:51:55 -0000 SGksDQoNCkl0IHNlZW1zIHRoYXQgd2UgaGF2ZSBiZWVuIGdvaW5nIGFyb3VuZCBvbiB0aGlzIHRv cGljIGZvciBhbiBldGVybml0eSwgc28gdG8gZXhwbGFpbiBpdCBhZ2FpbiB3b3VsZCBzaW1wbHkg YmUgYW4gZXhlcmNpc2UgaW4gcG91bmRpbmcgc2FuZC4NCg0KWW91cnMgSXJyZXNwZWN0aXZlbHks DQoNCkpvaG4NCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogd2FuZ2FqM0BjaGluYXRlbGVjb20uY24gPHdhbmdhajNA Y2hpbmF0ZWxlY29tLmNuPg0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMjAgMTA6NDEg QU0NCj4gVG86IEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0Pg0KPiBDYzogUGV0ZXIg UHNlbmFrIDxwcHNlbmFrQGNpc2NvLmNvbT47IFBldGVyIFBzZW5hayA8cHBzZW5ha0BjaXNjby5j b20+Ow0KPiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsgQ2hy aXN0aWFuIEhvcHBzDQo+IDxjaG9wcHNAY2hvcHBzLm9yZz47IEFpanVuIFdhbmcgPHdhbmdhaWp1 bkB0c2luZ2h1YS5vcmcuY24+OyBsc3ItDQo+IGNoYWlyc0BpZXRmLm9yZzsgbHNyQGlldGYub3Jn OyBKZWZmIFRhbnRzdXJhIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT47IGRyYWZ0LQ0KPiBpZXRm LWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnOyBsc3ItYWRzQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwgZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVm aXgtb3JpZ2luYXRvci0wNg0KPiANCj4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBj b250ZW50XQ0KPiANCj4gDQo+IEhpLCBKb2huOg0KPiANCj4gV291bGQgeW91IGxpa2UgdG8gaWxs dXN0cmF0ZSB5b3VyIGJyb2tlbiBjYXNlIG1vcmUgY2xlYXJseSBhbmQgbm90IG1ha2UgdGhlDQo+ IGNvbmNsdXNpb24gc28gaHVycnk/DQo+IA0KPiANCj4gQWlqdW4gV2FuZw0KPiBDaGluYSBUZWxl Y29tDQo+IA0KPiA+IE9uIE9jdCAxOSwgMjAyMCwgYXQgMjI6MTUsIEpvaG4gRSBEcmFrZQ0KPiA8 amRyYWtlPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+DQo+ID4g77u/ QWlqdW4sDQo+ID4NCj4gPiBXaGF0IHBhcnQgb2YgInVzaW5nIElQIGFkZHJlc3MgYWR2ZXJ0aXNl bWVudCB0byBkZXJpdmUgdG9wb2xvZ2ljYWwgZGF0YSBpcw0KPiBicm9rZW4iIGRvIHlvdSBub3Qg dW5kZXJzdGFuZD8NCj4gPg0KPiA+IFlvdXJzIElycmVzcGVjdGl2ZWx5LA0KPiA+DQo+ID4gSm9o bg0KPiA+DQo+ID4NCj4gPiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+ID4NCj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogUGV0ZXIgUHNlbmFrIDxwcHNlbmFr QGNpc2NvLmNvbT4NCj4gPj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDIwIDY6MzIgQU0N Cj4gPj4gVG86IEFpanVuIFdhbmcgPHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuPjsgUGV0ZXIgUHNl bmFrDQo+ID4+IDxwcHNlbmFrPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPg0KPiA+PiBDYzog TGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbT47IEFpanVuIFdhbmcN Cj4gPj4gPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+OyBDaHJpc3RpYW4gSG9wcHMgPGNob3Bw c0BjaG9wcHMub3JnPjsNCj4gPj4gSm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBlci5uZXQ+OyBs c3ItY2hhaXJzQGlldGYub3JnOyBsc3JAaWV0Zi5vcmc7DQo+ID4+IEplZmYgVGFudHN1cmEgPGpl ZmZ0YW50LmlldGZAZ21haWwuY29tPjsNCj4gPj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgt b3JpZ2luYXRvckBpZXRmLm9yZzsgbHNyLSBhZHNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6 IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmln aW5hdG9yLTA2DQo+ID4+IFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0g SGkgQWlqdW4sIHBsZWFzZSBzZWUgaW5saW5lOg0KPiA+Pj4gT24gMTkvMTAvMjAyMCAxMjoxMCwg QWlqdW4gV2FuZyB3cm90ZToNCj4gPj4+IEhpLiBQZXRlciwgTGVzOg0KPiA+Pj4gV2UgaGF2ZSBk ZWZpbmVkIG1hbnkgZXh0ZW5zaW9ucyBmb3IgcHJvdG9jb2wsIGJ1dCBvbmx5IGEgc21hbGwgcGFy dA0KPiA+Pj4gb2YgdGhlbQ0KPiA+PiBhcmUgZGVwbG95ZWQuIEhhdmUgeW91IGV2ZXIgY29uc2lk ZXJlZCB0aGUgcmVhc29uPw0KPiA+Pj4gQWRkaW5nIG1vcmUgY29udGVudHMgZm9yIHRoZWlyICBw b3RlbnRpYWwgdXNhZ2VzIGNhbiBjZXJ0YWlubHkgYmUNCj4gPj4+IGhlbHBmdWwgZm9yDQo+ID4+ IHRoZWlyIGluZmx1ZW5jZXMsIG9yIGVsc2UsIHRoZXkgd2lsbCBqdXN0IHN0YXkgYXQgdGhlIElF VEYgcmVwb3NpdG9yeS4NCj4gPj4gSSBkaXNhZ3JlZS4gUkZDcyBhcmUgbm90IGRlcGxveW1lbnQg b3IgdXNlIGNhc2UgZG9jdW1lbnRzLiBUaGV5DQo+ID4+IGV4aXN0cyB0byBhZGRyZXNzIHRoZSBp bnRlcm9wZXJhYmlsaXR5Lg0KPiA+Pj4gTW9yZSByZXBsaWVzIGlubGluZSBiZWxvdy4NCj4gPj4+ IEFpanVuIFdhbmcNCj4gPj4+IENoaW5hIFRlbGVjb20NCj4gPj4+PiBPbiBPY3QgMTksIDIwMjAs IGF0IDE3OjE0LCBQZXRlciBQc2VuYWsNCj4gPj4gPHBwc2VuYWs9NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmc+IHdyb3RlOg0KPiA+Pj4+IEFpanVuLA0KPiA+Pj4+PiBPbiAxOS8xMC8yMDIwIDA5 OjMyLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSB3cm90ZToNCj4gPj4+Pj4gQWlqdW4gLQ0KPiA+ Pj4+PiBJIGFtIG5vdCBnb2luZyB0byBjb250aW51ZSB0aGVzZSBzaWRlIGRpc2N1c3Npb25zIHdp dGggeW91Lg0KPiA+Pj4+PiBUaGUgcHJpbWFyeSBwdXJwb3NlIG9mIHRoZSBwcm90b2NvbCBleHRl bnNpb25zIGFyZSBhcyBzdGF0ZWQgaW4NCj4gPj4+Pj4gdGhlIGRyYWZ0DQo+ID4+IEludHJvZHVj dGlvbi4gVGhpcyBpcyBhbmFsb2dvdXMgdG8gdGhlIHVzZSBjYXNlcyBmb3IgdGhlIGVxdWl2YWxl bnQNCj4gPj4gZXh0ZW5zaW9ucyBmb3IgSVMtSVMgYWxyZWFkeSBhcHByb3ZlZCBpbiBSRkMgNzc5 NC4gV2UgbmVlZCB0aGUgZXF1aXZhbGVudCBpbg0KPiBPU1BGLg0KPiA+Pj4+PiBZb3UgY2FuIHNo b3cgdGhhdCB5b3UgYXJlIGxpc3RlbmluZyB0byB0aGUgY29uY2VybnMgb2YgV0cgbWVtYmVycw0K PiA+Pj4+PiBieQ0KPiA+PiByZW1vdmluZyB0aGUgQXBwZW5kaWNlcyAtIGluIHdoaWNoIGNhc2Ug eW91IGhhdmUgKEkgYmVsaWV2ZSkgYnJvYWQNCj4gPj4gc3VwcG9ydCBmb3IgbW92aW5nIHRoZSBk cmFmdCBmb3J3YXJkLg0KPiA+Pj4+IEkgYWdyZWUgd2l0aCBMZXMuDQo+ID4+Pj4gQXMgYSBjby1h dXRob3IsIEkgaGF2ZSBhc2tlZCB5b3Ugc2V2ZXJhbCB0aW1lcyB0byBnZXQgcmlkIG9mIHRoZQ0K PiA+Pj4+IHVzZSBjYXNlDQo+ID4+IGRlc2NyaWJlZCBpbiBhcHBlbmRpeC4NCj4gPj4+IFtXQUpd IE1vdmluZyB0aGUgZXhwYW5zaW9uIG9mIHRoaXMgdXNlIGNhc2UgZnJvbSBib2R5IHBhcnQgb2Yg dGhpcw0KPiA+Pj4gZHJhZnQgdG8gaXRzDQo+ID4+IGFwcGVuZGl4IGlzIG91ciBpbml0aWFsIGNv bnNlbnN1cywgbm90IHJlbW92ZSBpdCB0b3RhbGx5LiBXZSBoYXZlDQo+ID4+IGRpc2N1c3NlZCBp bnRlbnNlbHkgZm9yIGl0cyBhcHBsaWNhdGlvbiBpbiB2YXJ5IHNpdHVhdGlvbnMuIFRoZQ0KPiA+ PiBkaXNjdXNzaW9uIHJlc3VsdHMgYXJlIHN0YXRlZCBjbGVhcmx5IGluIHRoZSBhcHBlbmRpeC4N Cj4gPj4ganVzdCBiZWNhdXNlIHlvdSBpbnNpc3RlZCBhbmQgZGlkIG5vdCBsaXN0ZW4gdG8gcmVz dCBvZiB1cy4NCj4gPj4+IFdpc2ggdG8gaGVhciBtb3JlIHRlY2huaWNhbCBhbmFseXNpcy9jb21t ZW50cyBmb3IgdGhlIGN1cnJlbnQNCj4gPj4+IHN0YXRlbWVudHMgb2YNCj4gPj4gdGhpcyBwYXJ0 IGZyb20gb3RoZXIgZXhwZXJ0cywgb3IgZnJvbSB5b3UgaWYgeW91IGhhdmUgZnJlc2ggY29uc2lk ZXJhdGlvbi4NCj4gPj4gd2UgYXJlIGluIGEgY2lyY2xlLiBNdWx0aXBsZSBXRyBtZW1iZXJzIChM ZXMsIFRvbnkgUC4gQWNlZSwgS2V0YW4sDQo+ID4+IG15c2VsZikgYXJlIHRlbGxpbmcgeW91IHRo YXQgdXNpbmcgSVAgYWRkcmVzcyBhZHZlcnRpc2VtZW50IHRvIGRlcml2ZQ0KPiA+PiB0b3BvbG9n aWNhbCBkYXRhIGlzIGJyb2tlbiBhbmQgeW91IGtlZXAgcmVwZWF0aW5nIGl0IGlzIHZhbGlkIHVz ZQ0KPiA+PiBjYXNlIGFuZCBhc2sgZm9yIG1vcmUgcmVhc29uaW5nLg0KPiA+PiB0aGFua3MsDQo+ ID4+IFBldGVyDQo+ID4+Pj4gVHJ5aW5nIHRvIHVzZSBwcmVmaXggYWR2ZXJ0aXNlbWVudCB0byBk ZXJpdmUgdG9wb2xvZ2ljYWwgZGF0YSBpcw0KPiA+Pj4+IHNpbXBseQ0KPiA+PiBicm9rZW4uIFRo ZSByZWFzb24gd2UgYXJlIGFkZGluZyB0aGUgcHJlZml4IG9yaWdpbmF0b3IgZXh0ZW5zaW9uIHRv DQo+ID4+IE9TUEYgaXMgTk9UIHRoZSBicm9rZW4gdXNlIGNhc2UgaW4gdGhlIGFwcGVuZGl4IG9m IHRoZSBkcmFmdC4NCj4gPj4+PiB0aGFua3MsDQo+ID4+Pj4gUGV0ZXINCj4gPj4+Pj4gWW91IGNh biB0aGVuIHdyaXRlIGEgc2VwYXJhdGUgZHJhZnQgdG8gZGlzY3VzcyBvdGhlciB1c2UgY2FzZXMg YW5kDQo+ID4+Pj4+IGFsbG93IHRoZQ0KPiA+PiBXRyB0byBkaXNjdXNzIHRob3NlIG90aGVyIHVz ZSBjYXNlcyB3L28gcHJldmVudGluZyB0aGUgZXh0ZW5zaW9ucw0KPiA+PiBmcm9tIGJlaW5nIGFw cHJvdmVkIGFuZCBkZXBsb3llZCBmb3IgdGhlIHVzZSBjYXNlcyB3aGljaCBoYXZlIGFscmVhZHkN Cj4gPj4gYmVlbiBkZW1vbnN0cmF0ZWQgYXMgdXNlZnVsIGJ5IElTLUlTLg0KPiA+Pj4+PiBJZiB5 b3UgcmVtb3ZlIHRoZSBBcHBlbmRpY2VzIEkgY2FuIHN1cHBvcnQgdGhlIGRyYWZ0Lg0KPiA+Pj4+ PiBJZiB5b3UgZG8gbm90IHJlbW92ZSB0aGUgQXBwZW5kaWNlcyBJIGNhbm5vdCBzdXBwb3J0IHRo ZSBkcmFmdC4NCj4gPj4+Pj4gUGxlYXNlIGRpc2N1c3MgdGhpcyB3aXRoIHlvdXIgY28tYXV0aG9y cyBhbmQgY29tZSB0byBjb25zZW5zdXMgb24NCj4gPj4+Pj4geW91cg0KPiA+PiBuZXh0IHN0ZXAu DQo+ID4+Pj4+ICBMZXMNCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ Pj4+PiBGcm9tOiBBaWp1biBXYW5nIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPg0KPiA+Pj4+ Pj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDIwIDEyOjA2IEFNDQo+ID4+Pj4+PiBUbzog TGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbT47ICdDaHJpc3RpYW4g SG9wcHMnDQo+ID4+Pj4+PiA8Y2hvcHBzQGNob3Bwcy5vcmc+DQo+ID4+Pj4+PiBDYzogJ0pvaG4g RSBEcmFrZScgPGpkcmFrZUBqdW5pcGVyLm5ldD47IGxzci1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4+ Pj4+PiBsc3JAaWV0Zi5vcmc7ICdKZWZmIFRhbnRzdXJhJyA8amVmZnRhbnQuaWV0ZkBnbWFpbC5j b20+Ow0KPiA+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtIG9yaWdpbmF0b3JAaWV0 Zi5vcmc7IGxzci1hZHNAaWV0Zi5vcmcNCj4gPj4+Pj4+IFN1YmplY3Q6IFJFOiBbTHNyXSBXRyBM YXN0IENhbGwNCj4gPj4+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3It MDYNCj4gPj4+Pj4+IEhpLCBMZXM6DQo+ID4+Pj4+PiBBcyBJIHN0YXRlZCBjbGVhcmx5IGJlZm9y ZSwgdGhlIGFwcGVuZGl4IGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQNCj4gPj4+Pj4+IGlzIG5vdCB0 aGUgbmV3IHVzZSBjYXNlLiBJdCBpcyB0aGUgc3RhcnQgcG9pbnQgb2YgdGhpcyBkcmFmdC4NCj4g Pj4+Pj4+IEhhdmUgeW91IG5vdGljZWQgdGhhdCB0aGUgaW50cm9kdWN0aW9uIHBhcnQgaXMgbm90 IHRoZSBmaW5hbA0KPiA+Pj4+Pj4gdXNhZ2Ugb2Ygc3VjaCBwcm90b2NvbCBleHRlbnNpb24gaW5m b3JtYXRpb24/DQo+ID4+Pj4+PiBDZXJ0YWlubHksIHdlIHdpbGwgbm90IGV4cGFuZCBhbGwgdGhl IHBvc3NpYmxlIHVzZSBjYXNlcyBpbiB2ZXJ5DQo+ID4+Pj4+PiBkZXRhaWwsIGJ1dCBwdXR0aW5n IHNvbWUgb2YgdGhlbShzb21lIGludGVyZXN0aW5nLCBwcm9taW5lbnQgdXNlDQo+ID4+Pj4+PiBj YXNlcykgaW4gdGhlIGFwcGVuZGl4IHdpbGwgbm90IGhhbXBlciB0aGUgcHJvdG9jb2wgZXh0ZW5z aW9uIGl0c2VsZi4NCj4gPj4+Pj4+IElmIHRoZSBzdGF0ZW1lbnRzL2Rlc2NyaXB0aW9ucyBpbiB0 aGUgYXBwZW5kaXggYXJlIG5vdCBjb3JyZWN0LA0KPiA+Pj4+Pj4gd2UgY2FuIGZpeCBpdCwgb3Ig cmVtb3ZlIGl0IGZpbmFsbHkuICBJZiBub3QsIHdoeSBub3QgbGV0IGl0IGJlDQo+ID4+Pj4+PiBm b3IgcmVmZXJlbmNlIHRvIHRoZSB1c2VyIG9mIHN1Y2ggcHJvdG9jb2wgZXh0ZW5zaW9uPw0KPiA+ Pj4+Pj4gRm9yIHRoZSBib2R5IHBhcnQgb2YgdGhpcyBkcmFmdCwgd2UgYXJlIGFsc28gd2VsY29t ZSBjb21tZW50cy4NCj4gPj4+Pj4+IE1vcmUgcmVwbGllcyBpbmxpbmUgYmVsb3dbV0FKXQ0KPiA+ Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+ID4+Pj4+PiBBaWp1biBXYW5nDQo+ID4+Pj4+PiBDaGluYSBU ZWxlY29tDQo+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4gRnJv bTogbHNyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24N Cj4gPj4+Pj4+IEJlaGFsZiBPZiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KPiA+Pj4+Pj4gU2Vu dDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDIwIDI6MTUgUE0NCj4gPj4+Pj4+IFRvOiBBaWp1biBX YW5nIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPjsgJ0NocmlzdGlhbiBIb3BwcycNCj4gPj4+ Pj4+IDxjaG9wcHNAY2hvcHBzLm9yZz4NCj4gPj4+Pj4+IENjOiAnSm9obiBFIERyYWtlJyA8amRy YWtlQGp1bmlwZXIubmV0PjsgbHNyLWNoYWlyc0BpZXRmLm9yZzsNCj4gPj4+Pj4+ICdMZXMgR2lu c2JlcmcgKGdpbnNiZXJnKScgPGdpbnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPjsN Cj4gPj4+Pj4+IGxzckBpZXRmLm9yZzsgJ0plZmYgVGFudHN1cmEnIDxqZWZmdGFudC5pZXRmQGdt YWlsLmNvbT47DQo+ID4+Pj4+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC0gb3JpZ2luYXRv ckBpZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9yZw0KPiA+Pj4+Pj4gU3ViamVjdDogUmU6IFtMc3Jd IFdHIExhc3QgQ2FsbA0KPiA+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2lu YXRvci0wNg0KPiA+Pj4+Pj4gQWlqdW4gLQ0KPiA+Pj4+Pj4gVGhlICJ1c2UgY2FzZSIgZm9yIHRo ZSBwcm90b2NvbCBleHRlbnNpb25zIGlzIGNsZWFybHkgc3RhdGVkIGluDQo+ID4+Pj4+PiB0aGUN Cj4gPj4+Pj4+IEludHJvZHVjdGlvbjoNCj4gPj4+Pj4+ICJUaGUgcHJpbWFyeSB1c2UgY2FzZSBm b3IgdGhlIGV4dGVuc2lvbnMgcHJvcG9zZWQgaW4gdGhpcw0KPiA+Pj4+Pj4gZG9jdW1lbnQgaXMg IHRvIGJlIGFibGUgdG8gaWRlbnRpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIHByZWZpeCBpbiB0 aGUNCj4gbmV0d29yay4NCj4gPj4+Pj4+ICBJbiBjYXNlcyB3aGVyZSBtdWx0aXBsZSBwcmVmaXhl cyBhcmUgYWR2ZXJ0aXNlZCBieSBhIGdpdmVuDQo+ID4+Pj4+PiByb3V0ZXIsIGl0ICBpcyBhbHNv IHVzZWZ1bCB0byBiZSBhYmxlIHRvIGFzc29jaWF0ZSBhbGwgdGhlc2UNCj4gPj4+Pj4+IHByZWZp eGVzIHdpdGggYSAgc2luZ2xlIHJvdXRlciBldmVuIHdoZW4gcHJlZml4ZXMgYXJlIGFkdmVydGlz ZWQNCj4gPj4+Pj4+IG91dHNpZGUgb2YgdGhlIGFyZWEgIGluIHdoaWNoIHRoZXkgb3JpZ2luYXRl ZC4gIEl0IGFsc28gaGVscHMgdG8NCj4gPj4+Pj4+IGRldGVybWluZSB3aGVuIHRoZSBzYW1lICBw cmVmaXggaXMgYmVpbmcgb3JpZ2luYXRlZCBieSBtdWx0aXBsZSByb3V0ZXJzDQo+IGFjcm9zcyBh cmVhcy4iDQo+ID4+Pj4+PiBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gbGFuZ3VhZ2UgaW4gUkZDIDc3 OTQgd2hpY2ggZGVmaW5lcyB0aGUNCj4gPj4+Pj4+IGFuYWxvZ291cyBleHRlbnNpb25zIGZvciBJ Uy1JUy4NCj4gPj4+Pj4+IEV2ZXJ5dGhpbmcgeW91IGhhdmUgaW4gdGhlIEFwcGVuZGl4IGlzIG5v dCByZWxhdGVkIHRvIHRoZSBwcmltYXJ5DQo+ID4+Pj4+PiB1c2UgY2FzZSAtIGFuZCBpcyBmYWN0 IGEgdXNlIGNhc2Ugd2hpY2ggbWFueSBvZiB1cyBoYXZlIG9iamVjdGVkIHRvLg0KPiA+Pj4+Pj4g W1dBSl0gVmVyeSBnbGFkIHRvIGtub3cgdGhlIGZhbHNlIHN0YXRlbWVudHMgaW4gdGhlIGFwcGVu ZGl4Lg0KPiA+Pj4+Pj4gWW91IGFyZSBlbnRpdGxlZCB0byB3cml0ZSBhbm90aGVyIGRyYWZ0IGFk dm9jYXRpbmcgZm9yIHlvdXIgbmV3DQo+ID4+Pj4+PiB1c2UgY2FzZSBpZiB5b3Ugd2lzaCwgYnV0 IHJlcXVpcmluZyB0aGF0IHRoZSBwcm90b2NvbCBleHRlbnNpb25zDQo+ID4+Pj4+PiBpbiBzdXBw b3J0IG9mIHRoZSBwcmltYXJ5IHVzZSBjYXNlIG5vdCBnbyBmb3J3YXJkIHdpdGhvdXQgeW91cg0K PiA+Pj4+Pj4gbmV3IHVzZSBjYXNlIGlzIC0gYXMgQ2hyaXMgaGFzIHN0YXRlZCB2ZXJ5IGNsZWFy bHkgLSBob2xkaW5nDQo+ID4+Pj4+PiBhcHByb3ZhbCBvZiB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9u cyBob3N0YWdlIHRvIHlvdXIgbmV3IHVzZSBjYXNlLg0KPiA+Pj4+Pj4gW1dBSl0gSXQgaXMgbm90 IG5ldyB1c2UgY2FzZS4gQXMgSSBzYXRlZCBiZWZvcmUsIEkgYW0gb3BlbiB0bw0KPiA+Pj4+Pj4g dGhpcyBwYXJ0LCBidXQgc2hvdWxkIG9uIHRoZSBjb25kaXRpb25zIHRoYXQgdGhlIHN0YXRlbWVu dHMgaW4NCj4gPj4+Pj4+IHRoaXMgcGFydCBhcmUNCj4gPj4gaW5jb3JyZWN0Lg0KPiA+Pj4+Pj4g SSBhbSBhc2tpbmcgeW91ICh5ZXQgYWdhaW4pIG5vdCB0byBkbyB0aGlzLg0KPiA+Pj4+Pj4gSSBj YW5ub3Qgc3VwcG9ydCB0aGUgZG9jdW1lbnQgbW92aW5nIGZvcndhcmQgd2l0aCB0aGUgY29udGVu dCBpbg0KPiA+Pj4+Pj4gdGhlIEFwcGVuZGljZXMgaW5jbHVkZWQuDQo+ID4+Pj4+PiBbV0FKXSBX b3VsZCBsaWtlIHRvIGhlYXIgbW9yZSB0ZWNobmljYWwgYW5hbHlzaXMuDQo+ID4+Pj4+PiAgTGVz DQo+ID4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+PiBGcm9tOiBM c3IgPGxzci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KPiA+Pj4+ Pj4+IFNlbnQ6IFN1bmRheSwgT2N0b2JlciAxOCwgMjAyMCA3OjA4IFBNDQo+ID4+Pj4+Pj4gVG86 ICdDaHJpc3RpYW4gSG9wcHMnIDxjaG9wcHNAY2hvcHBzLm9yZz4NCj4gPj4+Pj4+PiBDYzogJ0pv aG4gRSBEcmFrZScgPGpkcmFrZUBqdW5pcGVyLm5ldD47IGxzci1jaGFpcnNAaWV0Zi5vcmc7DQo+ ID4+Pj4+Pj4gJ0xlcyBHaW5zYmVyZyAoZ2luc2JlcmcpJyA8Z2luc2Jlcmc9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmc+Ow0KPiA+Pj4+Pj4+IGxzckBpZXRmLm9yZzsgJ0plZmYgVGFudHN1cmEn IDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT47DQo+ID4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3Nw Zi1wcmVmaXgtIG9yaWdpbmF0b3JAaWV0Zi5vcmc7DQo+ID4+Pj4+Pj4gbHNyLWFkc0BpZXRmLm9y Zw0KPiA+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPj4+Pj4+PiBk cmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4+Pj4+Pj4gSGksIENo cmlzOg0KPiA+Pj4+Pj4+IEkgdGhpbmsgd2UgaGF2ZSAicHV0IHRoZSBjYXJ0IGJlZm9yZSB0aGUg aG9yc2UiLiBGb3IgcHJvdG9jb2wNCj4gPj4+Pj4+PiBleHRlbnNpb24gZHJhZnQsIHRoZSBvcmln aW4gaXMgdGhlIHVzZSBjYXNlLg0KPiA+Pj4+Pj4+IEFuZCBJIHRoaW5rIHdlIHdpbGwgbm90IGV4 cGFuZCBPU1BGIHByb3RvY29sLCBqdXN0IGJlY2F1c2UgaXQNCj4gPj4+Pj4+PiBsYWNrIHNvbWV0 aGluZyBhcyBjb21wYXJlZCB3aXRoIElTSVMsIHJpZ2h0Pw0KPiA+Pj4+Pj4+IEFzIEkgc3RhdGVk IGJlZm9yZSwgdGhlIHVzZSBjYXNlIGluIGN1cnJlbnQgYXBwZW5kaXggaXMgdGhlIG1haW4NCj4g Pj4+Pj4+PiBtb3RpdmF0aW9uIG9mIHRoaXMgZHJhZnQsIHlvdSBjYW4gc2VlIHRoaXMgaW4gbWFp biBib2R5IG9mIHRoZQ0KPiA+Pj4+Pj4+IGVhcmxpZXIgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0KGZy b20gdmVyc2lvbiAwIHRvIHZlcnNpb24gNSkuDQo+ID4+Pj4+Pj4gVGhlIHJlYXNvbiB0aGF0IHdl IG1vdmUgdGhpcyBwYXJ0IHRvIHRoZSBhcHBlbmRpeCwgYXMgdGhhdCB5b3UNCj4gPj4+Pj4+PiBz YWlkLCBpcyB0byBsZXQgcGVyc29uIGZvY3VzIG9uIHRoZSBwcm90b2NvbCBleHRlbnNpb24gaXRz ZWxmLg0KPiA+Pj4+Pj4+IE1vdmluZyB0aGlzIHBhcnQgdG8gYXBwZW5kaXggaXMgYWNjZXB0YWJs ZSwgYnV0IHJlbW92aW5nIGl0IGZyb20NCj4gPj4+Pj4+PiB0aGUgZHJhZnQgd2lsbCBlcmFzZSB0 aGUgb3JpZ2luIG9mIHRoaXMgZG9jdW1lbnQuDQo+ID4+Pj4+Pj4gSXMgaXQgcmVhc29uYWJsZSB0 aGF0IG9uZSBkb2N1bWVudCBkaXNjdXNzZXMgdGhlICJvcmlnaW4iKG9mIHRoZQ0KPiA+Pj4+Pj4+ IHByZWZpeCksIGNhbid0IGtlZXAgaXRzIG9yaWdpbj8NCj4gPj4+Pj4+PiBNb3JlIHJlcGxpZXMg aW5saW5lIGJlbG93W1dBSl0uDQo+ID4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+ID4+Pj4+Pj4gQWlq dW4gV2FuZw0KPiA+Pj4+Pj4+IENoaW5hIFRlbGVjb20NCj4gPj4+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+Pj4+Pj4gQmVoYWxmIE9mIENocmlzdGlh biBIb3Bwcw0KPiA+Pj4+Pj4+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNiwgMjAyMCAxMDo0NyBQ TQ0KPiA+Pj4+Pj4+IFRvOiDnjovniLHkv4ogPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+DQo+ ID4+Pj4+Pj4gQ2M6IEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0PjsgQ2hyaXN0aWFu IEhvcHBzDQo+ID4+Pj4+Pj4gPGNob3Bwc0BjaG9wcHMub3JnPjsgbHNyLWNoYWlyc0BpZXRmLm9y ZzsgTGVzIEdpbnNiZXJnDQo+ID4+Pj4+Pj4gKGdpbnNiZXJnKSA8Z2luc2Jlcmc9NDBjaXNjby5j b21AZG1hcmMuaWV0Zi5vcmc+OyBsc3JAaWV0Zi5vcmc7DQo+ID4+Pj4+Pj4gSmVmZiBUYW50c3Vy YSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+Ow0KPiA+Pj4+Pj4+IGRyYWZ0LWlldGYtbHNyLW9z cGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmc7IGxzci0NCj4gPj4+Pj4+PiBhZHNAaWV0Zi5v cmcNCj4gPj4+Pj4+PiBTdWJqZWN0OiBSZTogW0xzcl0gV0cgTGFzdCBDYWxsDQo+ID4+Pj4+Pj4g ZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+Pj4+Pj4+IElzbid0 IHRoaXMganVzdCBhZGRpbmcgYW4gYW5hbG9nb3VzIGV4dGVuc2lvbiB0aGF0IGFscmVhZHkNCj4g Pj4+Pj4+PiBleGlzdHMgaW4NCj4gPj4gUkZDNzc5ND8NCj4gPj4+Pj4+PiBbV0FKXSBOby4gUkZD Nzc5NCBpcyBqdXN0IG9uZSBleGFtcGxlIHRoYXQgdG8gaWxsdXN0cmF0ZSwgYXMgdGhlDQo+ID4+ Pj4+Pj4gY29tcGFuaW9uIElHUCBwcm90b2NvbCwgT1NQRiBjYW4gYWxzbyBhY2NvbXBsaXNoIHRo aXMuIEFuZCwNCj4gPj4+Pj4+PiBhY3R1YWxseSwgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIGNvbnNp ZGVyYXRpb24gaW4gdGhpcyBkcmFmdCBmb3INCj4gPj4+Pj4+PiB0aGUgcHJvdG9jb2wNCj4gPj4g ZXh0ZW5zaW9uLg0KPiA+Pj4+Pj4+IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBkbyBhIGxvdCBv ZiBjb252aW5jaW5nIGF0IHRoaXMgcG9pbnQuIEkNCj4gPj4+Pj4+PiBhZ3JlZSB3aXRoIExlcywg aWYgeW91IHdhbnQgdG8gdGFsayBhYm91dCB1c2UgY2FzZXMgKGVzcGVjaWFsbHkNCj4gPj4+Pj4+ PiBvbmVzIHRoYXQgYXJlIGNvbnRyb3ZlcnNpYWwhKSB0aGVuIHRoZSBjb3JyZWN0IHBsYWNlIGZv ciB0aGF0IGlzDQo+ID4+Pj4+Pj4gaW4gYSBuZXcgaW5mb3JtYXRpdmUNCj4gPj4+Pj4+IGRyYWZ0 Lg0KPiA+Pj4+Pj4+IFtXQUpdIHdlIGhhdmUgZGlzY3Vzc2VkIHRoZSB1c2UgY2FzZSBiZWZvcmUg YW5kIHN0YXRlIHRoZQ0KPiA+Pj4+Pj4+IGRpc2N1c3Npb24gcmVzdWx0cyBhdCB0aGUgYXBwZW5k aXggcGFydC4gV2Ugd2lsbCBub3QgZW1waGFzaXMNCj4gPj4+Pj4+PiBhbmQgZXhwYW5kIHRoZSB1 c2UgY2FzZSBtb3JlLiBJZiBvbmUgZG9lcyBub3QgYWdyZWUgdGhlDQo+ID4+Pj4+Pj4gc3RhdGVt ZW50IG9mIHRoaXMgYXBwZW5kaXgsIHdlIGNhbiBkaXNjdXNzIG9ubGluZSBvciBvZmZsaW5lLiBX ZQ0KPiA+Pj4+Pj4+IGp1c3QgbmVlZCB0byBtYWtlIHRoZSBzdGF0ZW1lbnQgaW4NCj4gPj4+Pj4+ IGFwcGVuZGl4IGlzIGNvcnJlY3QuDQo+ID4+Pj4+Pj4gT3RoZXJ3aXNlLCBlc3BlY2lhbGx5IGlm IHRoZSBjYXNlcyBhcmUgY29udHJvdmVyc2lhbCwgdGhpcyBjYW4NCj4gPj4+Pj4+PiBiZSBzZWVu IGFzIGRvaW5nIGFuICJlbmQtcnVuIiB0byBhdm9pZCB0aGUgZGViYXRlIGIvYyBwZW9wbGUNCj4g Pj4+Pj4+PiB3YW50IHRoZSBleHRlbnNpb24sIGJ1dCBtYXliZSBkb24ndCBhZ3JlZSB3aXRoIHlv dXIgdXNlIGNhc2UuDQo+ID4+Pj4+Pj4gW1dBSl0gT25lIHNob3VsZCBwb2ludCBvdXQgd2hpY2gg c3RhdGVtZW50IGluIHRoZSBhcHBlbmRpeCBpcw0KPiA+Pj4+Pj4+IGNvbnRyb3ZlcnNpYWwsIHdl IGNhbiBjb3JyZWN0IGl0LiBUaGlzIHVzZSBjYXNlIGlzIHRoZSBvcmlnaW4gb2YNCj4gPj4+Pj4+ PiB0aGlzIGRyYWZ0LCBub3QgdGhlIHJlc3VsdHMuDQo+ID4+Pj4+Pj4gTGVnaXNsYXRvcnMgZG8g dGhpcyBzb21ldGltZXMgYWRkaW5nIHRoaW5ncyB0aGV5IHdhbnQgcGVyc29uYWxseQ0KPiA+Pj4+ Pj4+IHRvIHBvcHVsYXIgYmlsbHMsIHRoYXQgb3RoZXIgcGVvcGxlIG1heSBub3Qgd2FudCwgYnV0 IHNpbmNlDQo+ID4+Pj4+Pj4gcGVvcGxlIHdhbnQgdGhlIG1haW4gYmlsbCB0aGV5IHZvdGUgZm9y IGl0IGFueXdheSwgaW4gdGhlIFVTDQo+ID4+Pj4+Pj4gaXQncyBjYWxsZWQgImFkZGluZyBwb3Jr IiBvciAicG9yayBiYXJyZWwgcG9saXRpY3MiLiA6KSBbV0FKXQ0KPiA+Pj4+Pj4+IFRoZSBhcHBl bmRpeCBpcyBub3QgYWRkZWQgbGF0ZXIsIGJ1dCBleGlzdCBhdCB0aGUgZmlyc3QNCj4gPj4+Pj4+ PiBiZWdpbm5pbmcuIFRoaXMgaXMgdGhlIG9yaWdpbiBvZiB0aGUgYmlsbHMuDQo+ID4+Pj4+Pj4g VGhhbmtzLA0KPiA+Pj4+Pj4+IENocmlzLg0KPiA+Pj4+Pj4+PiBPbiBPY3QgMTYsIDIwMjAsIGF0 IDEwOjM3IEFNLCDnjovniLHkv4ogPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+DQo+ID4+Pj4+ Pj4gd3JvdGU6DQo+ID4+Pj4+Pj4+IEhpLCBDaHJpczoNCj4gPj4+Pj4+Pj4gT3JpZ2luYWxseSwg dGhlIGFwcGVuZGl4IHBhcnQgaXMgd2l0aGluIHRoZSBkb2N1bWVudCwgd2hpY2ggaXMNCj4gPj4+ Pj4+Pj4gdGhlIHN0YXJ0DQo+ID4+Pj4+Pj4gcG9pbnQvbWFpbiBtb3RpdmF0aW9uIHRvIGV4dGVu ZCB0aGUgcHJlZml4IG9yaWdpbi4NCj4gPj4+Pj4+Pj4gVGhlcmUgbWF5IGV4aXN0cyBvdGhlciB1 c2FnZXMgb2YgdGhpcyBpbmZvcm1hdGlvbi4gUGFjayB0aGVzZQ0KPiA+Pj4+Pj4+PiBleGFtcGxl cw0KPiA+Pj4+Pj4+IGludG8gc29tZSBzaG9ydCBzZW50ZW5jZXMgb3IgaW50cm9kdWN0aW9uIGlz IHZpYWJsZSwgYnV0IGV4cGFuZA0KPiA+Pj4+Pj4+IHNvbWUgb2YgdGhlbSBpcyBhbHNvIGhlbHBm dWwuDQo+ID4+Pj4+Pj4+IEFzIEkga25vd24sIHdoZW4gd2Ugd2FudCB0byBkbyBwcm90b2NvbCBl eHRlbnNpb24sIHdlIHNob3VsZA0KPiA+Pj4+Pj4+PiBhbHdheXMNCj4gPj4+Pj4+PiBjb252aW5j ZSBvdGhlciB0aGUgcmVhc29uL21vdGl2YXRpb24vcHJvc3BlY3RzIHRvIGRvIHNvLiBPbiB0aGUN Cj4gPj4+Pj4+PiBvdGhlciBoYW5kLCB0aGUgdXNlIGNhc2UgZGVzY3JpYmVkIGluIHRoZSBjdXJy ZW50IGFwcGVuZGl4IGlzDQo+ID4+Pj4+Pj4gdmVyeSBwcm9taW5lbnQgZm9yIG9wZXJhdG9yIHRv IGFjY29tcGxpc2ggdGhlIFRFIHRhc2sgaW4NCj4gPj4+Pj4+PiBtdWx0aS1hcmVhDQo+ID4+IGVu dmlyb25tZW50Lg0KPiA+Pj4+Pj4+PiBBaWp1biBXYW5nDQo+ID4+Pj4+Pj4+IOWcqDIwMjAtMTAt MTbvvIxDaHJpc3RpYW4gSG9wcHMgJmx0O2Nob3Bwc0BjaG9wcHMub3JnJmd0O+WGmemBkzoNCj4g Pj4+Pj4+Pj4gLS0tLS3ljp/lp4vpgq7ku7YtLS0tLQ0KPiA+Pj4+Pj4+PiDlj5Hku7bkurrvvJog Q2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9yZyZndDsNCj4gPj4+Pj4+Pj4g5Y+R 5Lu25pe26Ze0OiAyMDIw5bm0MTDmnIgxNuaXpSDmmJ/mnJ/kupQNCj4gPj4+Pj4+Pj4g5YaZ6YGT OiBbJnF1b3Q7TGVzIEdpbnNiZXJnIChnaW5zYmVyZykmcXVvdDsNCj4gPj4+Pj4+Pj4gJmx0O2dp bnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0O10NCj4gPj4+Pj4+Pj4g5Li76aKY 77yaIFJlOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPj4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3Nw Zi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+Pj4+Pj4+Pj4gT24gT2N0IDE2LCAyMDIwLCBhdCAx OjUxIEFNLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KPiA+Pj4+Pj4+IDxnaW5zYmVyZz00MGNp c2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+ID4+Pj4+Pj4+PiBBaWp1biAtDQo+ID4+ Pj4+Pj4+PiBUaGUgcG9pbnQgSSBhbSBtYWtpbmcgaXMgdmVyeSBmb2N1c2VkLg0KPiA+Pj4+Pj4+ Pj4gVGhpcyBkcmFmdCBpcyBkZWZpbmluZyBhIHByb3RvY29sIGV4dGVuc2lvbi4gQXMgc3VjaCBp dCBpcw0KPiA+Pj4+Pj4+Pj4gbmVjZXNzYXJ5IHRoYXQgdGhpcw0KPiA+Pj4+Pj4+IGJlIFN0YW5k YXJkcyB0cmFjayBhcyBhZGhlcmluZyB0byB0aGUgbm9ybWF0aXZlIHN0YXRlbWVudHMgaW4NCj4g Pj4+Pj4+PiB0aGUgZHJhZnQgYXJlIG5lY2Vzc2FyeSBmb3IgaW50ZXJvcGVyYWJpbGl0eS4NCj4g Pj4+Pj4+Pj4+IFdoYXQgaXMgZGlzY3Vzc2VkIGluIHRoZSBBcHBlbmRpeCBpcyBhIHVzZSBjYXNl LiBJdCBpcyBub3QNCj4gPj4+Pj4+Pj4+IG5vcm1hdGl2ZSBhbmQNCj4gPj4+Pj4+PiB0aGVyZSBh cmUgc3Ryb25nIG9waW5pb25zIG9uIGJvdGggc2lkZXMgYXMgdG8gd2hldGhlciB0aGlzIGlzIGFu DQo+ID4+Pj4+Pj4gYXBwcm9wcmlhdGUgdXNlIGNhc2Ugb3Igbm90Lg0KPiA+Pj4+Pj4+Pj4gSW4g dGhlIGNvbnRleHQgb2YgdGhpcyBkcmFmdCwgSSBoYXZlIG5vIGludGVyZXN0IGluIHRyeWluZyB0 bw0KPiA+Pj4+Pj4+Pj4gcmVzb2x2ZSBvdXINCj4gPj4+Pj4+PiBkaWZmZXJlbmNlIG9mIG9waW5p b24gb24gdGhpcyB1c2UgY2FzZS4gSSBzaW1wbHkgd2FudCB0aGUNCj4gPj4+Pj4+PiBwcm90b2Nv bCBleHRlbnNpb24gdG8gbW92ZSBmb3J3YXJkIHNvIHRoYXQgd2UgaGF2ZSBhbm90aGVyIHRvb2wN Cj4gYXZhaWxhYmxlLg0KPiA+Pj4+Pj4+Pj4gSWYgeW91IHdhbnQgdG8gd3JpdGUgYSBkcmFmdCBv biB0aGUgdXNlIGNhc2UgZGlzY3Vzc2VkIGluIHRoZQ0KPiA+Pj4+Pj4+Pj4gQXBwZW5kaXgNCj4g Pj4+Pj4+PiBwbGVhc2UgZmVlbCBmcmVlIHRvIGRvIHNvLiBUaGF0IGRyYWZ0IG1heSB2ZXJ5IHdl bGwgbm90IGJlDQo+ID4+Pj4+Pj4gbm9ybWF0aXZlIC0gSW5mb3JtYXRpb25hbCBvciBCQ1AgbWF5 IGJlIG1vcmUgYXBwcm9wcmlhdGUgLQ0KPiA+Pj4+Pj4+IGJlY2F1c2UgaXQgd2lsbCBiZSBkaXNj dXNzaW5nIGEgZGVwbG95bWVudCBzY2VuYXJpbyBhbmQgYQ0KPiA+Pj4+Pj4+IHByb3Bvc2FsIHRv IHVzZSBkZWZpbmVkIHByb3RvY29sIGV4dGVuc2lvbnMgYXMgb25lIHdheSB0byBzb2x2ZQ0KPiA+ Pj4+Pj4+IHByb2JsZW1zIGluIHRoYXQgZGVwbG95bWVudCBzY2VuYXJpby4gU3VjaCBhIGRyYWZ0 IG1pZ2h0IGFsc28gYmUNCj4gPj4+Pj4+PiBtb3JlIGFwcHJvcHJpYXRlIGluIGFub3RoZXIgV0cg KGUuZy4sIFRFQVMpLiBUaGUgbWVyaXRzIG9mIHVzaW5nDQo+ID4+Pj4+Pj4gcHJlZml4IGFkdmVy dGlzZW1lbnRzIHRvIGJ1aWxkIGEgdG9wb2xvZ3kNCj4gPj4+Pj4+IGNvdWxkIHRoZW4gYmUgZGlz Y3Vzc2VkIG9uIGl0cyBvd24uDQo+ID4+Pj4+Pj4+PiBQbGVhc2UgZG8gbm90IHRyeSB0byBhdm9p ZCBoYXZpbmcgYSBmdWxsIGRpc2N1c3Npb24gb2YgdGhlDQo+ID4+Pj4+Pj4+PiBtZXJpdHMgb2Yg dXNpbmcNCj4gPj4+Pj4+PiBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgdG8gZGVyaXZlIHRvcG9sb2d5 IGJ5IGFkZGluZyBpdCB0byBhIGRyYWZ0DQo+ID4+Pj4+Pj4gdGhhdCBpcyAoYW5kIHNob3VsZCBi ZSkgZm9jdXNlZCBvbiBzaW1wbGUgcHJvdG9jb2wgZXh0ZW5zaW9ucy4NCj4gPj4+Pj4+Pj4gW0Fz IFdHIG1lbWJlcl0NCj4gPj4+Pj4+Pj4gSSBmaW5kIHRoaXMgdmVyeSBjb21wZWxsaW5nIGFuZCBz byBzdXBwb3J0IHRoZSByZW1vdmFsIG9mIHRoZQ0KPiA+Pj4+Pj4+PiByZWZlcnJlZCB0bw0KPiA+ Pj4+Pj4+IG5vbi1ub3JtYXRpdmUgYXBwZW5kaWNlcy4NCj4gPj4+Pj4+Pj4gVGhhbmtzLA0KPiA+ Pj4+Pj4+PiBDaHJpcy4NCj4gPj4+Pj4+Pj4+IFRoYW54Lg0KPiA+Pj4+Pj4+Pj4gTGVzDQo+ID4+ Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+Pj4+PiBGcm9tOiBB aWp1biBXYW5nIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPg0KPiA+Pj4+Pj4+Pj4+IFNlbnQ6 IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDIwIDY6NTEgUE0NCj4gPj4+Pj4+Pj4+PiBUbzogJ0pl ZmYgVGFudHN1cmEnIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT47ICdKb2huIEUgRHJha2UnDQo+ ID4+Pj4+Pj4+Pj4gPGpkcmFrZUBqdW5pcGVyLm5ldD4NCj4gPj4+Pj4+Pj4+PiBDYzogJ0Nocmlz dGlhbiBIb3BwcycgPGNob3Bwc0BjaG9wcHMub3JnPjsNCj4gPj4+Pj4+Pj4+PiBsc3ItY2hhaXJz QGlldGYub3JnOyBMZXMgR2luc2JlcmcNCj4gPj4+Pj4+Pj4+PiAoZ2luc2JlcmcpIDxnaW5zYmVy Z0BjaXNjby5jb20+OyBsc3JAaWV0Zi5vcmc7DQo+ID4+Pj4+Pj4+Pj4gbHNyLWFkc0BpZXRmLm9y ZzsNCj4gPj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLSBsc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBp ZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJFOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4g Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4+ Pj4+Pj4+Pj4gSGksIExlcywgSm9obiBhbmQgSmVmZjoNCj4gPj4+Pj4+Pj4+PiBMZXQncyByZXBs eSB5b3UgYWxsIHRvZ2V0aGVyLg0KPiA+Pj4+Pj4+Pj4+IEluIG15IFBPViwgVGhlIHN0YW5kYXJk IGRvY3VtZW50IHNob3VsZCBub3QgZGVmaW5lIHNvbGVseSB0aGUNCj4gPj4+Pj4+Pj4+PiBwcm90 b2NvbCBleHRlbnNpb24sIGJ1dCB0aGVpciB1c2FnZXMgaW4gdGhlIG5ldHdvcmsgZGVwbG95bWVu dC4NCj4gPj4+Pj4+Pj4+PiBBcyBJIGtub3duLCBhbG1vc3QgYWxsIHRoZSBJRVRGIGRvY3VtZW50 cyBmb2xsb3dpbmcgdGhpcyBzdHlsZS4NCj4gPj4+Pj4+Pj4+PiBBbmQsIGJlZm9yZSBhZG9wdGlu ZyBvbmUgd29yaywgd2UgaGF2ZSBvZnRlbiBpbnRlbnNlDQo+ID4+Pj4+Pj4+Pj4gZGlzY3Vzc2lv biBmb3Igd2hhdCdzIHRoZWlyIHVzYWdlcy4NCj4gPj4+Pj4+Pj4+PiBTdWNoIGRpc2N1c3Npb24g aW4gdGhlIG1haWwgbGlzdCBhbmQgc3RhdGVtZW50cyBpbiB0aGUNCj4gPj4+Pj4+Pj4+PiBkb2N1 bWVudCBjYW4gY2VydGFpbmx5IGFzc2lzdCB0aGUgcmVhZGVyL3VzZXIgb2YgdGhlIGRvY3VtZW50 DQo+ID4+Pj4+Pj4+Pj4gZ2V0IHRoZSBlc3NlbmNlIG9mIHRoZSBzdGFuZGFyZCwgYW5kIGZvbGxv dyB0aGVtIHVuYW1iaWd1b3VzbHkuDQo+ID4+Pj4+Pj4+Pj4gUmVnYXJkaW5nIHRoZSBjb250ZW50 cyBvZiBhcHBlbmRpY2VzLCBhcyBzdGF0ZWQgaW4gdGhlDQo+ID4+Pj4+Pj4+Pj4gc2VjdGlvbiwg IlRoZSBBcHBlbmRpeCBBIGhldXJpc3RpYyB0byByZWJ1aWxkIHRoZSB0b3BvbG9neQ0KPiA+Pj4+ Pj4+Pj4+IGNhbiBub3JtYWxseSBiZSB1c2VkIGlmIGFsbCBsaW5rcyBhcmUgbnVtYmVyZWQuIiBJ IHRoaW5rIHRoaXMNCj4gPj4+Pj4+Pj4+PiBjYW4gYXBwbHkgYWxtb3N0IG1vc3Qgb2YgdGhlIG9w ZXJhdG9yJ3MgbmV0d29yaywgYW5kDQo+ID4+Pj4+Pj4+Pj4gZmFjaWxpdGF0ZSB0aGUgaW50ZXIt YXJlYSBURSBwYXRoIGNhbGN1bGF0aW9uIGZvciBjZW50cmFsDQo+ID4+Pj4+Pj4+Pj4gY29udHJv bGxlciwgb3IgZXZlbiBmb3IgdGhlIGhlYWQtZW5kIHJvdXRlciB0aGF0IGxvY2F0ZWQgaW4NCj4g Pj4+Pj4+Pj4+PiBvbmUgYXJlYSB0aGF0IGRpZmZlcmVudCBmcm9tDQo+ID4+IHRoZSB0YWlsLSBl bmQgcm91dGVyLg0KPiA+Pj4+Pj4+Pj4+IEtlZXBpbmcgdGhlIGNvbnRlbnRzIG9mIGFwcGVuZGlj ZXMgZG9lcyBub3QgaGF2ZSB0aGUgbmVnYXRpdmUNCj4gPj4+Pj4+Pj4+PiBpbXBhY3Qgb2YgdGhl IHByb3RvY29sIGV4dGVuc2lvbiwgaXQgaXMganVzdCBvbmUgcmVmZXJlbmNlDQo+ID4+Pj4+Pj4+ Pj4gZm9yIHRoZSB1c2FnZSBvZiB0aGlzIGV4dGVuc2lvbi4NCj4gPj4+Pj4+Pj4+PiBPbmUgY2Fu IHNlbGVjdCBub3QgcmVmZXIgdG8gaXQsIGlmIHRoZWlyIG5ldHdvcmtzIGFyZQ0KPiA+Pj4+Pj4+ Pj4+IGRlcGxveWVkIHdpdGggbGFyZ2UgYW1vdW50IG9mIHVubnVtYmVyZWQgbGlua3MuIEJ1dCBm b3INCj4gPj4+Pj4+Pj4+PiBvdGhlcnMsIHRoZSBoZXVyaXN0aWMNCj4gPj4+Pj4+IGFwcGxpZXMu DQo+ID4+Pj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+ID4+Pj4+Pj4+Pj4gQWlqdW4gV2FuZw0KPiA+ Pj4+Pj4+Pj4+IENoaW5hIFRlbGVjb20NCj4gPj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+Pj4+Pj4+Pj4+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4+Pj4+Pj4+Pj4gQmVoYWxmIE9mIEplZmYgVGFu dHN1cmENCj4gPj4+Pj4+Pj4+PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTYsIDIwMjAgNToyOCBB TQ0KPiA+Pj4+Pj4+Pj4+IFRvOiBKb2huIEUgRHJha2UgPGpkcmFrZT00MGp1bmlwZXIubmV0QGRt YXJjLmlldGYub3JnPg0KPiA+Pj4+Pj4+Pj4+IENjOiBDaHJpc3RpYW4gSG9wcHMgPGNob3Bwc0Bj aG9wcHMub3JnPjsgbHNyLWNoYWlyc0BpZXRmLm9yZzsNCj4gPj4+Pj4+Pj4+PiBMZXMgR2luc2Jl cmcNCj4gPj4+Pj4+Pj4+PiAoZ2luc2JlcmcpIDxnaW5zYmVyZz00MGNpc2NvLmNvbUBkbWFyYy5p ZXRmLm9yZz47DQo+ID4+Pj4+Pj4+Pj4gbHNyQGlldGYub3JnOw0KPiA+Pj4+Pj4+Pj4+IGxzci0g YWRzQGlldGYub3JnOw0KPiA+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9y aWdpbmF0b3JAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0xzcl0gV0cgTGFz dCBDYWxsDQo+ID4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRv ci0wNg0KPiA+Pj4+Pj4+Pj4+ICsxDQo+ID4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4gPj4+Pj4+Pj4+ PiBKZWZmDQo+ID4+Pj4+Pj4+Pj4+IE9uIE9jdCAxNSwgMjAyMCwgYXQgMTE6MzMsIEpvaG4gRSBE cmFrZQ0KPiA+Pj4+Pj4+Pj4+IDxqZHJha2U9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4g d3JvdGU6DQo+ID4+Pj4+Pj4+Pj4+IEhpLA0KPiA+Pj4+Pj4+Pj4+PiBJIGFncmVlIHdpdGggTGVz LiAgVGhpcyBpcyBhIHNpbXBsZSBwcm90b2NvbCBleHRlbnNpb24gZm9yIGENCj4gPj4+Pj4+Pj4+ Pj4gc3BlY2lmaWMgcHVycG9zZQ0KPiA+Pj4+Pj4+Pj4+IGFuZCB0aGVyZSBpcyBubyByZWFzb24g dG8gaW5jbHVkZSBzcGVjdWxhdGlvbiBhYm91dCBpdHMgdXNlDQo+ID4+Pj4+Pj4+Pj4gZm9yIG90 aGVyIHB1cnBvc2VzLCBwYXJ0aWN1bGFybHkgd2hlbiBpdCBpcyBpbmhlcmVudGx5IG5vdCBzdWl0 ZWQgZm9yDQo+IHRoZW0uDQo+ID4+Pj4+Pj4+Pj4+IFlvdXJzIElycmVzcGVjdGl2ZWx5LA0KPiA+ Pj4+Pj4+Pj4+PiBKb2huDQo+ID4+Pj4+Pj4+Pj4+IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkN Cj4gPj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4+Pj4+ PiBGcm9tOiBMc3IgPGxzci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTGVzIEdpbnNi ZXJnDQo+ID4+Pj4+Pj4+Pj4+PiAoZ2luc2JlcmcpDQo+ID4+Pj4+Pj4+Pj4+PiBTZW50OiBUaHVy c2RheSwgT2N0b2JlciAxNSwgMjAyMCAxMjozMyBQTQ0KPiA+Pj4+Pj4+Pj4+Pj4gVG86IENocmlz dGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBsc3JAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+ Pj4+IENjOiBsc3ItY2hhaXJzQGlldGYub3JnOyBsc3ItYWRzQGlldGYub3JnOw0KPiA+Pj4+Pj4+ Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtIG9yaWdpbmF0b3JAaWV0Zi5vcmcNCj4g Pj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPj4+Pj4+Pj4+ Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gPj4+Pj4+Pj4+ Pj4+IFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0gSSBzdXBwb3J0IG1v dmluZw0KPiA+Pj4+Pj4+Pj4+Pj4gdGhpcyBkb2N1bWVudCBmb3J3YXJkLg0KPiA+Pj4+Pj4+Pj4+ Pj4gU2ltaWxhciBmdW5jdGlvbmFsaXR5IGluIElTLUlTIGhhcyBwcm92ZWQgdXNlZnVsLg0KPiA+ Pj4+Pj4+Pj4+Pj4gSSB3b3VsZCBob3dldmVyIGxpa2UgdG8gcmVwZWF0IGNvbW1lbnRzIEkgbWFk ZSBlYXJsaWVyIGluDQo+ID4+Pj4+Pj4+Pj4+PiB0aGUgcmV2aWV3IG9mIHRoaXMgZG9jdW1lbnQu DQo+ID4+Pj4+Pj4+Pj4+PiBUaGUgY29udGVudCBvZiB0aGUgQXBwZW5kaWNlcyBzaG91bGQgYmUg cmVtb3ZlZC4NCj4gPj4+Pj4+Pj4+Pj4+IFRoZSBBcHBlbmRpY2VzIGRlZmluZSBhbmQgZGlzY3Vz cyBkZXJpdmluZyB0b3BvbG9neQ0KPiA+Pj4+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gZnJvbSBwcmVm aXggYWR2ZXJ0aXNlbWVudHMgLSB3aGljaCBpcyBmbGF3ZWQNCj4gPj4+Pj4+Pj4+Pj4+IGFuZCBz aG91bGQgbm90IGJlDQo+ID4+Pj4+PiBkb25lLg0KPiA+Pj4+Pj4+Pj4+Pj4gUGVyaGFwcyBtb3Jl IHJlbGV2YW50LCB0aGUgcHVycG9zZSBvZiB0aGUgZG9jdW1lbnQgaXMgdG8NCj4gPj4+Pj4+Pj4+ Pj4+IGRlZmluZSBwcm90b2NvbCBleHRlbnNpb25zIHN1cHBvcnRpbmcgYWR2ZXJ0aXNlbWVudCBv ZiB0aGUNCj4gPj4+Pj4+Pj4+Pj4+IG9yaWdpbmF0b3JzIG9mIGEgcHJlZml4IGFkdmVydGlzZW1l bnQuIFRoZXJlIGlzIG5vIG5lZWQgdG8NCj4gPj4+Pj4+Pj4+Pj4+IGRpc2N1c3MgaG93IHRoaXMg bWVjaGFuaXNtIG1pZ2h0IGJlIHVzZWQgdG8gYnVpbGQgdG9wb2xvZ3kNCj4gPj4gaW5mb3JtYXRp b24uDQo+ID4+Pj4+Pj4+Pj4+PiBUaGlzIGRvY3VtZW50IHNob3VsZCBjb25maW5lIGl0c2VsZiB0 byBkZWZpbmluZyB0aGUNCj4gPj4+Pj4+Pj4+Pj4+IHByb3RvY29sIGV4dGVuc2lvbnMgLSBzaW1p bGFyIHRoZSBSRkMgNzc5NC4NCj4gPj4+Pj4+Pj4+Pj4+IElmIHRoZSBhdXRob3JzIGRvIG5vdCBh Z3JlZSB0byBkbyB0aGlzLCBJIHdvdWxkIGVuY291cmFnZQ0KPiA+Pj4+Pj4+Pj4+Pj4gdGhpcyBw b2ludCB0byBiZSBkaXNjdXNzZWQgZHVyaW5nIElFU0cgcmV2aWV3Lg0KPiA+Pj4+Pj4+Pj4+Pj4g TGVzDQo+ID4+Pj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+ Pj4+Pj4+PiBGcm9tOiBMc3IgPGxzci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hy aXN0aWFuDQo+ID4+Pj4+Pj4+Pj4+Pj4gSG9wcHMNCj4gPj4+Pj4+Pj4+Pj4+PiBTZW50OiBXZWRu ZXNkYXksIE9jdG9iZXIgMTQsIDIwMjAgMTE6MTUgUE0NCj4gPj4+Pj4+Pj4+Pj4+PiBUbzogbHNy QGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+Pj4gQ2M6IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4 LW9yaWdpbmF0b3JAaWV0Zi5vcmc7DQo+ID4+Pj4+Pj4+Pj4+Pj4gbHNyLWNoYWlyc0BpZXRmLm9y ZzsgbHNyLSBhZHNAaWV0Zi5vcmc7IENocmlzdGlhbiBIb3Bwcw0KPiA+Pj4+Pj4+Pj4+Pj4+IDxj aG9wcHNAY2hvcHBzLm9yZz4NCj4gPj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBbTHNyXSBXRyBMYXN0 IENhbGwNCj4gPj4+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5h dG9yLTA2DQo+ID4+Pj4+Pj4+Pj4+Pj4gVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTGFzdCBDYWxs LCBlbmRpbmcgYWZ0ZXIgT2N0IDI5dGgsDQo+ID4+Pj4+Pj4+Pj4+Pj4gMjAyMCwNCj4gPj4gZm9y Og0KPiA+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2QNCj4gPj4+Pj4+Pj4+Pj4+PiBvYw0KPiA+Pj4+Pj4+Pj4+Pj4+ IC9kDQo+ID4+Pj4+Pj4+Pj4+Pj4gcmENCj4gPj4+Pj4+Pj4+Pj4+PiBmdC1pDQo+ID4+Pj4+Pj4+ Pj4+Pj4gZXQNCj4gPj4+Pj4+Pj4+Pj4+PiBmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yL19f OyEhTkV0NnlNYU8tDQo+ID4+Pj4+Pj4+Pj4gZ2shVGFTelFUaGdodENGT3VZUFMyVmpMcQ0KPiA+ Pj4+Pj4+Pj4+Pj4+IGhLIDhwMDNGZzNMOUx1Q0dYdzhDMFg2cVJRZHJIaktES0hjamtqQ2xwayQN Cj4gPj4+Pj4+Pj4+Pj4+PiBUaGUgZm9sbG93aW5nIElQUiBoYXMgYmVlbiBmaWxlZA0KPiA+Pj4+ Pj4+DQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2lwci8zNDQ4L19fOyENCj4gPj4+Pj4+Pj4+Pj4+PiAhTkV0NnlNYU8tDQo+ID4+Pj4+ Pj4NCj4gZ2shVGFTelFUaGdodENGT3VZUFMyVmpMcWhLOHAwM0ZnM0w5THVDR1h3OEMwWDZxUlFk ckhqS0RLSGN6DQo+ID4+Pj4+Pj4+Pj4+Pj4gNUt0VUhRJA0KPiA+Pj4+Pj4+Pj4+Pj4+IEF1dGhv cnMsDQo+ID4+Pj4+Pj4+Pj4+Pj4gUGxlYXNlIGluZGljYXRlIHRvIHRoZSBsaXN0LCB5b3VyIGtu b3dsZWRnZSBvZiBhbnkgb3RoZXINCj4gPj4+Pj4+Pj4+Pj4+PiBJUFIgcmVsYXRlZCB0byB0aGlz IHdvcmsuDQo+ID4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPiA+Pj4+Pj4+Pj4+Pj4+IENocmlzLg0K PiA+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4+Pj4+Pj4+Pj4+IExzciBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4+IExz ckBpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGkNCj4gPj4+Pj4+Pj4+Pj4+IHN0DQo+ID4+Pj4+ Pj4+Pj4+PiBpbg0KPiA+Pj4+Pj4+Pj4+Pj4gZm8NCj4gPj4+Pj4+Pj4+Pj4+IC9sc3INCj4gPj4+ Pj4+Pj4+Pj4+IF9fOyEhTkV0DQo+ID4+Pj4+Pj4+Pj4+PiA2eU1hTy0NCj4gPj4gZ2shVGFTelFU aGdodENGT3VZUFMyVmpMcWhLOHAwM0ZnM0w5THVDR1h3OEMwWDZxUlFkckhqS0RLSGNVZG0NCj4g Pj4+Pj4+Pj4+PiB3OA0KPiA+Pj4+Pj4+Pj4+Pj4gTGMkDQo+ID4+Pj4+Pj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+Pj4+IExz ciBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4gTHNyQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+ IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpcw0KPiA+Pj4+Pj4+Pj4+PiB0aQ0KPiA+Pj4+Pj4+Pj4+PiBuZm8vbHNyX187ISFORXQ2eU1h Ty0NCj4gPj4gZ2shU1ZIdnFLeG8ya1JhRzNwTldrZGlLR0lhZTQ3MjFVS0xXbmZmbWwNCj4gPj4+ Pj4+Pj4+Pj4gZTlUdm9BWndlNjRmbnpWdml6TnVqbXExTSQNCj4gPj4+Pj4+Pj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+IExz ciBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+PiBMc3JAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+PiBo dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0DQo+ID4+Pj4+Pj4+Pj4gaW4NCj4gPj4+Pj4+Pj4+PiBmby9sc3JfXzshIU5FdDZ5TWFPLQ0K PiA+PiBnayFTVkh2cUt4bzJrUmFHM3BOV2tkaUtHSWFlNDcyMVVLTFduZmZtbGU5DQo+ID4+Pj4+ Pj4+Pj4gVHZvQVp3ZTY0Zm56VnZpek51am1xMU0kDQo+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4gTHNyIG1haWxp bmcgbGlzdA0KPiA+Pj4+Pj4+Pj4gTHNyQGlldGYub3JnDQo+ID4+Pj4+Pj4+PiBodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aQ0KPiA+ Pj4+Pj4+Pj4gbmYNCj4gPj4+Pj4+Pj4+IG8vbHNyX187ISFORXQ2eU1hTy0NCj4gPj4gZ2shU1ZI dnFLeG8ya1JhRzNwTldrZGlLR0lhZTQ3MjFVS0xXbmZmbWxlOVR2DQo+ID4+Pj4+Pj4+PiBvQVp3 ZTY0Zm56VnZpek51am1xMU0kDQo+ID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+PiBMc3IgbWFpbGluZyBsaXN0DQo+ID4+Pj4+ Pj4gTHNyQGlldGYub3JnDQo+ID4+Pj4+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZg0KPiA+Pj4+Pj4+IG8vDQo+ID4+Pj4+ Pj4gbHNyX187ISFORXQ2eU1hTy0NCj4gPj4gZ2shU1ZIdnFLeG8ya1JhRzNwTldrZGlLR0lhZTQ3 MjFVS0xXbmZmbWxlOVR2b0Fadw0KPiA+Pj4+Pj4+IGU2NGZuelZ2aXpOdWptcTFNJA0KPiA+Pj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ Pj4+IExzciBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+IExzckBpZXRmLm9yZw0KPiA+Pj4+Pj4gaHR0 cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8NCj4gPj4+Pj4+IC9sDQo+ID4+Pj4+PiBzcl9fOyEhTkV0NnlNYU8tDQo+ID4+IGdrIVNW SHZxS3hvMmtSYUczcE5Xa2RpS0dJYWU0NzIxVUtMV25mZm1sZTlUdm9BWndlNg0KPiA+Pj4+Pj4g NGZuelZ2aXpOdWptcTFNJA0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+Pj4gTHNyIG1haWxpbmcgbGlzdA0KPiA+Pj4+IExzckBpZXRm Lm9yZw0KPiA+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wNCj4gPj4+PiBzcg0KPiA+Pj4+IF9fOyEhTkV0NnlNYU8t DQo+ID4+IGdrIVNWSHZxS3hvMmtSYUczcE5Xa2RpS0dJYWU0NzIxVUtMV25mZm1sZTlUdm9BWndl NjRmbnoNCj4gPj4+PiBWdml6TnVqbXExTSQNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IExzciBtYWlsaW5nIGxpc3QNCj4gPiBMc3JAaWV0 Zi5vcmcNCj4gPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sc3JfDQo+ID4gXzshIU5FdDZ5TWFPLQ0KPiBnayFROGlIV2pN RG9LWXJreEUydDBoeHZGdGJfdVFfZUhiQ2pPblRjcm9QZl9IejJYejdpanYtOFQNCj4gPiBWdG9q SHEtTEEkDQo= From nobody Mon Oct 19 08:00:44 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666CA3A00D9; Mon, 19 Oct 2020 08:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 OMVYfhZiQUTP; Mon, 19 Oct 2020 08:00:38 -0700 (PDT) Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2293A00D2; Mon, 19 Oct 2020 08:00:35 -0700 (PDT) Received: from localhost.localdomain (unknown [106.121.66.233]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id A69BA4805A; Mon, 19 Oct 2020 23:00:29 +0800 (CST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Aijun Wang Mime-Version: 1.0 (1.0) Date: Mon, 19 Oct 2020 23:00:28 +0800 Message-Id: <039FF1DD-2186-4FCF-8CEA-105DF1F49E2F@tsinghua.org.cn> References: Cc: wangaj3@chinatelecom.cn, Peter Psenak , "Les Ginsberg (ginsberg)" , Christian Hopps , lsr-chairs@ietf.org, lsr@ietf.org, Jeff Tantsura , draft-ietf-lsr-ospf-prefix-originator@ietf.org, lsr-ads@ietf.org In-Reply-To: To: John E Drake X-Mailer: iPhone Mail (18A373) X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZTE8fTUlNSB9NT0IeVkpNS0hKSkJNSUJDTkxVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hNSlVLWQY+ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MUk6Ljo5Az8pPzFRMUhCSUM2 DENPCj1VSlVKTUtISkpCTUhLT0pLVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVU1NVUlISFlXWQgBWUFJQ0pMSDcG X-HM-Tid: 0a754160457c9865kuuua69ba4805a Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 15:00:42 -0000 Would you like to refer the cases raised from Robert? Such discussion can be fruitful for the refine or forwarding of this draft. One should convince others based on the fact, not subjective opinion. Aijun Wang China Telecom > On Oct 19, 2020, at 22:52, John E Drake wrote: >=20 > =EF=BB=BFHi, >=20 > It seems that we have been going around on this topic for an eternity, so t= o explain it again would simply be an exercise in pounding sand. >=20 > Yours Irrespectively, >=20 > John >=20 >=20 > Juniper Business Use Only >=20 >> -----Original Message----- >> From: wangaj3@chinatelecom.cn >> Sent: Monday, October 19, 2020 10:41 AM >> To: John E Drake >> Cc: Peter Psenak ; Peter Psenak ; >> Les Ginsberg (ginsberg) ; Christian Hopps >> ; Aijun Wang ; lsr- >> chairs@ietf.org; lsr@ietf.org; Jeff Tantsura ; d= raft- >> ietf-lsr-ospf-prefix-originator@ietf.org; lsr-ads@ietf.org >> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 >>=20 >> [External Email. Be cautious of content] >>=20 >>=20 >> Hi, John: >>=20 >> Would you like to illustrate your broken case more clearly and not make t= he >> conclusion so hurry? >>=20 >>=20 >> Aijun Wang >> China Telecom >>=20 >>> On Oct 19, 2020, at 22:15, John E Drake >> wrote: >>>=20 >>> =EF=BB=BFAijun, >>>=20 >>> What part of "using IP address advertisement to derive topological data i= s >> broken" do you not understand? >>>=20 >>> Yours Irrespectively, >>>=20 >>> John >>>=20 >>>=20 >>> Juniper Business Use Only >>>=20 >>>> -----Original Message----- >>>> From: Peter Psenak >>>> Sent: Monday, October 19, 2020 6:32 AM >>>> To: Aijun Wang ; Peter Psenak >>>> >>>> Cc: Les Ginsberg (ginsberg) ; Aijun Wang >>>> ; Christian Hopps ; >>>> John E Drake ; lsr-chairs@ietf.org; lsr@ietf.org; >>>> Jeff Tantsura ; >>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- ads@ietf.org >>>> Subject: Re: [Lsr] WG Last Call >>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>> [External Email. Be cautious of content] Hi Aijun, please see inline: >>>>> On 19/10/2020 12:10, Aijun Wang wrote: >>>>> Hi. Peter, Les: >>>>> We have defined many extensions for protocol, but only a small part >>>>> of them >>>> are deployed. Have you ever considered the reason? >>>>> Adding more contents for their potential usages can certainly be >>>>> helpful for >>>> their influences, or else, they will just stay at the IETF repository. >>>> I disagree. RFCs are not deployment or use case documents. They >>>> exists to address the interoperability. >>>>> More replies inline below. >>>>> Aijun Wang >>>>> China Telecom >>>>>> On Oct 19, 2020, at 17:14, Peter Psenak >>>> wrote: >>>>>> Aijun, >>>>>>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote: >>>>>>> Aijun - >>>>>>> I am not going to continue these side discussions with you. >>>>>>> The primary purpose of the protocol extensions are as stated in >>>>>>> the draft >>>> Introduction. This is analogous to the use cases for the equivalent >>>> extensions for IS-IS already approved in RFC 7794. We need the equivale= nt in >> OSPF. >>>>>>> You can show that you are listening to the concerns of WG members >>>>>>> by >>>> removing the Appendices - in which case you have (I believe) broad >>>> support for moving the draft forward. >>>>>> I agree with Les. >>>>>> As a co-author, I have asked you several times to get rid of the >>>>>> use case >>>> described in appendix. >>>>> [WAJ] Moving the expansion of this use case from body part of this >>>>> draft to its >>>> appendix is our initial consensus, not remove it totally. We have >>>> discussed intensely for its application in vary situations. The >>>> discussion results are stated clearly in the appendix. >>>> just because you insisted and did not listen to rest of us. >>>>> Wish to hear more technical analysis/comments for the current >>>>> statements of >>>> this part from other experts, or from you if you have fresh considerati= on. >>>> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan, >>>> myself) are telling you that using IP address advertisement to derive >>>> topological data is broken and you keep repeating it is valid use >>>> case and ask for more reasoning. >>>> thanks, >>>> Peter >>>>>> Trying to use prefix advertisement to derive topological data is >>>>>> simply >>>> broken. The reason we are adding the prefix originator extension to >>>> OSPF is NOT the broken use case in the appendix of the draft. >>>>>> thanks, >>>>>> Peter >>>>>>> You can then write a separate draft to discuss other use cases and >>>>>>> allow the >>>> WG to discuss those other use cases w/o preventing the extensions >>>> from being approved and deployed for the use cases which have already >>>> been demonstrated as useful by IS-IS. >>>>>>> If you remove the Appendices I can support the draft. >>>>>>> If you do not remove the Appendices I cannot support the draft. >>>>>>> Please discuss this with your co-authors and come to consensus on >>>>>>> your >>>> next step. >>>>>>> Les >>>>>>>> -----Original Message----- >>>>>>>> From: Aijun Wang >>>>>>>> Sent: Monday, October 19, 2020 12:06 AM >>>>>>>> To: Les Ginsberg (ginsberg) ; 'Christian Hopps'= >>>>>>>> >>>>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; >>>>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>>>> Subject: RE: [Lsr] WG Last Call >>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>> Hi, Les: >>>>>>>> As I stated clearly before, the appendix described in the draft >>>>>>>> is not the new use case. It is the start point of this draft. >>>>>>>> Have you noticed that the introduction part is not the final >>>>>>>> usage of such protocol extension information? >>>>>>>> Certainly, we will not expand all the possible use cases in very >>>>>>>> detail, but putting some of them(some interesting, prominent use >>>>>>>> cases) in the appendix will not hamper the protocol extension itsel= f. >>>>>>>> If the statements/descriptions in the appendix are not correct, >>>>>>>> we can fix it, or remove it finally. If not, why not let it be >>>>>>>> for reference to the user of such protocol extension? >>>>>>>> For the body part of this draft, we are also welcome comments. >>>>>>>> More replies inline below[WAJ] >>>>>>>> Best Regards >>>>>>>> Aijun Wang >>>>>>>> China Telecom >>>>>>>> -----Original Message----- >>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >>>>>>>> Behalf Of Les Ginsberg (ginsberg) >>>>>>>> Sent: Monday, October 19, 2020 2:15 PM >>>>>>>> To: Aijun Wang ; 'Christian Hopps' >>>>>>>> >>>>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; >>>>>>>> 'Les Ginsberg (ginsberg)' ; >>>>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; lsr-ads@ietf.org >>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>> Aijun - >>>>>>>> The "use case" for the protocol extensions is clearly stated in >>>>>>>> the >>>>>>>> Introduction: >>>>>>>> "The primary use case for the extensions proposed in this >>>>>>>> document is to be able to identify the originator of the prefix in= the >> network. >>>>>>>> In cases where multiple prefixes are advertised by a given >>>>>>>> router, it is also useful to be able to associate all these >>>>>>>> prefixes with a single router even when prefixes are advertised >>>>>>>> outside of the area in which they originated. It also helps to >>>>>>>> determine when the same prefix is being originated by multiple rou= ters >> across areas." >>>>>>>> This is equivalent to language in RFC 7794 which defines the >>>>>>>> analogous extensions for IS-IS. >>>>>>>> Everything you have in the Appendix is not related to the primary >>>>>>>> use case - and is fact a use case which many of us have objected to= . >>>>>>>> [WAJ] Very glad to know the false statements in the appendix. >>>>>>>> You are entitled to write another draft advocating for your new >>>>>>>> use case if you wish, but requiring that the protocol extensions >>>>>>>> in support of the primary use case not go forward without your >>>>>>>> new use case is - as Chris has stated very clearly - holding >>>>>>>> approval of the protocol extensions hostage to your new use case. >>>>>>>> [WAJ] It is not new use case. As I sated before, I am open to >>>>>>>> this part, but should on the conditions that the statements in >>>>>>>> this part are >>>> incorrect. >>>>>>>> I am asking you (yet again) not to do this. >>>>>>>> I cannot support the document moving forward with the content in >>>>>>>> the Appendices included. >>>>>>>> [WAJ] Would like to hear more technical analysis. >>>>>>>> Les >>>>>>>>> -----Original Message----- >>>>>>>>> From: Lsr On Behalf Of Aijun Wang >>>>>>>>> Sent: Sunday, October 18, 2020 7:08 PM >>>>>>>>> To: 'Christian Hopps' >>>>>>>>> Cc: 'John E Drake' ; lsr-chairs@ietf.org; >>>>>>>>> 'Les Ginsberg (ginsberg)' ;= >>>>>>>>> lsr@ietf.org; 'Jeff Tantsura' ; >>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org; >>>>>>>>> lsr-ads@ietf.org >>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>> Hi, Chris: >>>>>>>>> I think we have "put the cart before the horse". For protocol >>>>>>>>> extension draft, the origin is the use case. >>>>>>>>> And I think we will not expand OSPF protocol, just because it >>>>>>>>> lack something as compared with ISIS, right? >>>>>>>>> As I stated before, the use case in current appendix is the main >>>>>>>>> motivation of this draft, you can see this in main body of the >>>>>>>>> earlier version of this draft(from version 0 to version 5). >>>>>>>>> The reason that we move this part to the appendix, as that you >>>>>>>>> said, is to let person focus on the protocol extension itself. >>>>>>>>> Moving this part to appendix is acceptable, but removing it from >>>>>>>>> the draft will erase the origin of this document. >>>>>>>>> Is it reasonable that one document discusses the "origin"(of the >>>>>>>>> prefix), can't keep its origin? >>>>>>>>> More replies inline below[WAJ]. >>>>>>>>> Best Regards >>>>>>>>> Aijun Wang >>>>>>>>> China Telecom >>>>>>>>> -----Original Message----- >>>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >>>>>>>>> Behalf Of Christian Hopps >>>>>>>>> Sent: Friday, October 16, 2020 10:47 PM >>>>>>>>> To: =E7=8E=8B=E7=88=B1=E4=BF=8A >>>>>>>>> Cc: John E Drake ; Christian Hopps >>>>>>>>> ; lsr-chairs@ietf.org; Les Ginsberg >>>>>>>>> (ginsberg) ; lsr@ietf.org; >>>>>>>>> Jeff Tantsura ; >>>>>>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org; lsr- >>>>>>>>> ads@ietf.org >>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>> Isn't this just adding an analogous extension that already >>>>>>>>> exists in >>>> RFC7794? >>>>>>>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the >>>>>>>>> companion IGP protocol, OSPF can also accomplish this. And, >>>>>>>>> actually, there are differences consideration in this draft for >>>>>>>>> the protocol >>>> extension. >>>>>>>>> I don't think we need to do a lot of convincing at this point. I >>>>>>>>> agree with Les, if you want to talk about use cases (especially >>>>>>>>> ones that are controversial!) then the correct place for that is >>>>>>>>> in a new informative >>>>>>>> draft. >>>>>>>>> [WAJ] we have discussed the use case before and state the >>>>>>>>> discussion results at the appendix part. We will not emphasis >>>>>>>>> and expand the use case more. If one does not agree the >>>>>>>>> statement of this appendix, we can discuss online or offline. We >>>>>>>>> just need to make the statement in >>>>>>>> appendix is correct. >>>>>>>>> Otherwise, especially if the cases are controversial, this can >>>>>>>>> be seen as doing an "end-run" to avoid the debate b/c people >>>>>>>>> want the extension, but maybe don't agree with your use case. >>>>>>>>> [WAJ] One should point out which statement in the appendix is >>>>>>>>> controversial, we can correct it. This use case is the origin of >>>>>>>>> this draft, not the results. >>>>>>>>> Legislators do this sometimes adding things they want personally >>>>>>>>> to popular bills, that other people may not want, but since >>>>>>>>> people want the main bill they vote for it anyway, in the US >>>>>>>>> it's called "adding pork" or "pork barrel politics". :) [WAJ] >>>>>>>>> The appendix is not added later, but exist at the first >>>>>>>>> beginning. This is the origin of the bills. >>>>>>>>> Thanks, >>>>>>>>> Chris. >>>>>>>>>> On Oct 16, 2020, at 10:37 AM, =E7=8E=8B=E7=88=B1=E4=BF=8A >>>>>>>>> wrote: >>>>>>>>>> Hi, Chris: >>>>>>>>>> Originally, the appendix part is within the document, which is >>>>>>>>>> the start >>>>>>>>> point/main motivation to extend the prefix origin. >>>>>>>>>> There may exists other usages of this information. Pack these >>>>>>>>>> examples >>>>>>>>> into some short sentences or introduction is viable, but expand >>>>>>>>> some of them is also helpful. >>>>>>>>>> As I known, when we want to do protocol extension, we should >>>>>>>>>> always >>>>>>>>> convince other the reason/motivation/prospects to do so. On the >>>>>>>>> other hand, the use case described in the current appendix is >>>>>>>>> very prominent for operator to accomplish the TE task in >>>>>>>>> multi-area >>>> environment. >>>>>>>>>> Aijun Wang >>>>>>>>>> =E5=9C=A82020-10-16=EF=BC=8CChristian Hopps <chopps@chopps.org= >=E5=86=99=E9=81=93: >>>>>>>>>> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- >>>>>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Christian Hopps <chopps@c= hopps.org> >>>>>>>>>> =E5=8F=91=E4=BB=B6=E6=97=B6=E9=97=B4: 2020=E5=B9=B410=E6=9C=8816=E6= =97=A5 =E6=98=9F=E6=9C=9F=E4=BA=94 >>>>>>>>>> =E5=86=99=E9=81=93: ["Les Ginsberg (ginsberg)" >>>>>>>>>> <ginsberg=3D40cisco.com@dmarc.ietf.org>] >>>>>>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A Re: [Lsr] WG Last Call >>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) >>>>>>>>> wrote: >>>>>>>>>>> Aijun - >>>>>>>>>>> The point I am making is very focused. >>>>>>>>>>> This draft is defining a protocol extension. As such it is >>>>>>>>>>> necessary that this >>>>>>>>> be Standards track as adhering to the normative statements in >>>>>>>>> the draft are necessary for interoperability. >>>>>>>>>>> What is discussed in the Appendix is a use case. It is not >>>>>>>>>>> normative and >>>>>>>>> there are strong opinions on both sides as to whether this is an >>>>>>>>> appropriate use case or not. >>>>>>>>>>> In the context of this draft, I have no interest in trying to >>>>>>>>>>> resolve our >>>>>>>>> difference of opinion on this use case. I simply want the >>>>>>>>> protocol extension to move forward so that we have another tool >> available. >>>>>>>>>>> If you want to write a draft on the use case discussed in the >>>>>>>>>>> Appendix >>>>>>>>> please feel free to do so. That draft may very well not be >>>>>>>>> normative - Informational or BCP may be more appropriate - >>>>>>>>> because it will be discussing a deployment scenario and a >>>>>>>>> proposal to use defined protocol extensions as one way to solve >>>>>>>>> problems in that deployment scenario. Such a draft might also be >>>>>>>>> more appropriate in another WG (e.g., TEAS). The merits of using >>>>>>>>> prefix advertisements to build a topology >>>>>>>> could then be discussed on its own. >>>>>>>>>>> Please do not try to avoid having a full discussion of the >>>>>>>>>>> merits of using >>>>>>>>> prefix advertisements to derive topology by adding it to a draft >>>>>>>>> that is (and should be) focused on simple protocol extensions. >>>>>>>>>> [As WG member] >>>>>>>>>> I find this very compelling and so support the removal of the >>>>>>>>>> referred to >>>>>>>>> non-normative appendices. >>>>>>>>>> Thanks, >>>>>>>>>> Chris. >>>>>>>>>>> Thanx. >>>>>>>>>>> Les >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Aijun Wang >>>>>>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM >>>>>>>>>>>> To: 'Jeff Tantsura' ; 'John E Drake' >>>>>>>>>>>> >>>>>>>>>>>> Cc: 'Christian Hopps' ; >>>>>>>>>>>> lsr-chairs@ietf.org; Les Ginsberg >>>>>>>>>>>> (ginsberg) ; lsr@ietf.org; >>>>>>>>>>>> lsr-ads@ietf.org; >>>>>>>>>>>> draft-ietf- lsr-ospf-prefix-originator@ietf.org >>>>>>>>>>>> Subject: RE: [Lsr] WG Last Call >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>> Hi, Les, John and Jeff: >>>>>>>>>>>> Let's reply you all together. >>>>>>>>>>>> In my POV, The standard document should not define solely the >>>>>>>>>>>> protocol extension, but their usages in the network deployment.= >>>>>>>>>>>> As I known, almost all the IETF documents following this style.= >>>>>>>>>>>> And, before adopting one work, we have often intense >>>>>>>>>>>> discussion for what's their usages. >>>>>>>>>>>> Such discussion in the mail list and statements in the >>>>>>>>>>>> document can certainly assist the reader/user of the document >>>>>>>>>>>> get the essence of the standard, and follow them unambiguously.= >>>>>>>>>>>> Regarding the contents of appendices, as stated in the >>>>>>>>>>>> section, "The Appendix A heuristic to rebuild the topology >>>>>>>>>>>> can normally be used if all links are numbered." I think this >>>>>>>>>>>> can apply almost most of the operator's network, and >>>>>>>>>>>> facilitate the inter-area TE path calculation for central >>>>>>>>>>>> controller, or even for the head-end router that located in >>>>>>>>>>>> one area that different from >>>> the tail- end router. >>>>>>>>>>>> Keeping the contents of appendices does not have the negative >>>>>>>>>>>> impact of the protocol extension, it is just one reference >>>>>>>>>>>> for the usage of this extension. >>>>>>>>>>>> One can select not refer to it, if their networks are >>>>>>>>>>>> deployed with large amount of unnumbered links. But for >>>>>>>>>>>> others, the heuristic >>>>>>>> applies. >>>>>>>>>>>> Best Regards >>>>>>>>>>>> Aijun Wang >>>>>>>>>>>> China Telecom >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of Jeff Tantsura >>>>>>>>>>>> Sent: Friday, October 16, 2020 5:28 AM >>>>>>>>>>>> To: John E Drake >>>>>>>>>>>> Cc: Christian Hopps ; lsr-chairs@ietf.org; >>>>>>>>>>>> Les Ginsberg >>>>>>>>>>>> (ginsberg) ; >>>>>>>>>>>> lsr@ietf.org; >>>>>>>>>>>> lsr- ads@ietf.org; >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator@ietf.org >>>>>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>> +1 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Jeff >>>>>>>>>>>>> On Oct 15, 2020, at 11:33, John E Drake >>>>>>>>>>>> wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> I agree with Les. This is a simple protocol extension for a >>>>>>>>>>>>> specific purpose >>>>>>>>>>>> and there is no reason to include speculation about its use >>>>>>>>>>>> for other purposes, particularly when it is inherently not suit= ed for >> them. >>>>>>>>>>>>> Yours Irrespectively, >>>>>>>>>>>>> John >>>>>>>>>>>>> Juniper Business Use Only >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Lsr On Behalf Of Les Ginsberg >>>>>>>>>>>>>> (ginsberg) >>>>>>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM >>>>>>>>>>>>>> To: Christian Hopps ; lsr@ietf.org >>>>>>>>>>>>>> Cc: lsr-chairs@ietf.org; lsr-ads@ietf.org; >>>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix- originator@ietf.org >>>>>>>>>>>>>> Subject: Re: [Lsr] WG Last Call >>>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>>>> [External Email. Be cautious of content] I support moving >>>>>>>>>>>>>> this document forward. >>>>>>>>>>>>>> Similar functionality in IS-IS has proved useful. >>>>>>>>>>>>>> I would however like to repeat comments I made earlier in >>>>>>>>>>>>>> the review of this document. >>>>>>>>>>>>>> The content of the Appendices should be removed. >>>>>>>>>>>>>> The Appendices define and discuss deriving topology >>>>>>>>>>>>>> information from prefix advertisements - which is flawed >>>>>>>>>>>>>> and should not be >>>>>>>> done. >>>>>>>>>>>>>> Perhaps more relevant, the purpose of the document is to >>>>>>>>>>>>>> define protocol extensions supporting advertisement of the >>>>>>>>>>>>>> originators of a prefix advertisement. There is no need to >>>>>>>>>>>>>> discuss how this mechanism might be used to build topology >>>> information. >>>>>>>>>>>>>> This document should confine itself to defining the >>>>>>>>>>>>>> protocol extensions - similar the RFC 7794. >>>>>>>>>>>>>> If the authors do not agree to do this, I would encourage >>>>>>>>>>>>>> this point to be discussed during IESG review. >>>>>>>>>>>>>> Les >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Lsr On Behalf Of Christian >>>>>>>>>>>>>>> Hopps >>>>>>>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM >>>>>>>>>>>>>>> To: lsr@ietf.org >>>>>>>>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-originator@ietf.org; >>>>>>>>>>>>>>> lsr-chairs@ietf.org; lsr- ads@ietf.org; Christian Hopps >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Subject: [Lsr] WG Last Call >>>>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, >>>>>>>>>>>>>>> 2020, >>>> for: >>>>>>>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/d >>>>>>>>>>>>>>> oc >>>>>>>>>>>>>>> /d >>>>>>>>>>>>>>> ra >>>>>>>>>>>>>>> ft-i >>>>>>>>>>>>>>> et >>>>>>>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO- >>>>>>>>>>>> gk!TaSzQThghtCFOuYPS2VjLq >>>>>>>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$ >>>>>>>>>>>>>>> The following IPR has been filed >>>>>>>>>=20 >> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;! >>>>>>>>>>>>>>> !NEt6yMaO- >>>>>>>>>=20 >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz >>>>>>>>>>>>>>> 5KtUHQ$ >>>>>>>>>>>>>>> Authors, >>>>>>>>>>>>>>> Please indicate to the list, your knowledge of any other >>>>>>>>>>>>>>> IPR related to this work. >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Chris. >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Lsr mailing list >>>>>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/li >>>>>>>>>>>>>> st >>>>>>>>>>>>>> in >>>>>>>>>>>>>> fo >>>>>>>>>>>>>> /lsr >>>>>>>>>>>>>> __;!!NEt >>>>>>>>>>>>>> 6yMaO- >>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >>>>>>>>>>>> w8 >>>>>>>>>>>>>> Lc$ >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Lsr mailing list >>>>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/lis >>>>>>>>>>>>> ti >>>>>>>>>>>>> nfo/lsr__;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml >>>>>>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Lsr mailing list >>>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/list >>>>>>>>>>>> in >>>>>>>>>>>> fo/lsr__;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9 >>>>>>>>>>>> TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Lsr mailing list >>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>>>>>>>>>> nf >>>>>>>>>>> o/lsr__;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv >>>>>>>>>>> oAZwe64fnzVvizNujmq1M$ >>>>>>>>> _______________________________________________ >>>>>>>>> Lsr mailing list >>>>>>>>> Lsr@ietf.org >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf >>>>>>>>> o/ >>>>>>>>> lsr__;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw >>>>>>>>> e64fnzVvizNujmq1M$ >>>>>>>> _______________________________________________ >>>>>>>> Lsr mailing list >>>>>>>> Lsr@ietf.org >>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo >>>>>>>> /l >>>>>>>> sr__;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6 >>>>>>>> 4fnzVvizNujmq1M$ >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>>>> sr >>>>>> __;!!NEt6yMaO- >>>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz >>>>>> VvizNujmq1M$ >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ >>> _;!!NEt6yMaO- >> gk!Q8iHWjMDoKYrkxE2t0hxvFtb_uQ_eHbCjOnTcroPf_Hz2Xz7ijv-8T >>> VtojHq-LA$ From nobody Mon Oct 19 08:09:13 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF6B3A0365 for ; Mon, 19 Oct 2020 08:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 pL1Ko_iyabug for ; Mon, 19 Oct 2020 08:09:11 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2109.outbound.protection.outlook.com [40.107.243.109]) (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 F15243A0317 for ; Mon, 19 Oct 2020 08:09:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h6e9dAfzD3DuLpH81J7vyN/PT1GHaBvADfnqOOMSyyIzkQzyD2PbVYd4/vWCU1GBdxa3PKbHl7OctnFXuzMPCM5vehWwF56F5AoOvZY+dO1JTxeHdhLy9Lh/t0LdN8IR6h1/sRwP9gAGqI3rwYsewc4fZndH7FkpBM7O2+j1T1KMcdgh+nW5MtKcHr8CjjnEr8eOLFMffSYhSAkIDn36kWlyQnp2Vv1zdkdOb00LqAoN8YKZjLpywYoyizThyo9zIZ9FtOKTA6epGbCcFUJlfAktQgQHRd5j9XT8KJZM+HiuTbA6cJQ0JWc/zuAeMixTeN6vzRBrB/Mg+UaugIaQNw== 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=kj0n0fBYU7USkHOBsmGlu4HHeEkambqGRP+6wztbmp4=; b=eccxagVYDdebAmPKAZZrrKJGuIPy7avjLS34WP4f5v9sBZifkEuT1KfYITU6tTcjscZOvRanfy39bjP+UKCXRENKM/S2FtGEJ0tuFrEfHz5g+qmBnLJRR4vd5/rxDE2rvCp6kpmcJpqCjStVVXkFal7yP0v4b21GuJcOoWXxkFCa1qKGH7JMuvQXwtxoX2Alut4T+3cvme2YJAkyYjBgOUUImZ6z7lnwrrZuWfFO77neYon2qGArzBWLClXq8ah8o+N3DFdjEm7EjIp0duiHniVZZrS3OJlGjjVq+t9dFgKXUiOTF//YpY41S8/1sr9oq2ikoi8B8y8NvqwaB4NYFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kj0n0fBYU7USkHOBsmGlu4HHeEkambqGRP+6wztbmp4=; b=YTfSug7GMurp0rEoR/HmlzFcLgKjM7koqHCgnb99EbEQ2SkgrjFEzc1sNDTq4csJjPN/CcHcEM97oFNC30XMLkZ1nt4YI81JmrPV9EA9QWkLuUngtGnnH+Qwo30tq01RrsQ/YPa7KvmOXDO98gzLX0yZ7+fg2Euu3Aaha7qsOKk= Received: from MN2PR13MB4087.namprd13.prod.outlook.com (2603:10b6:208:263::16) by MN2PR13MB3535.namprd13.prod.outlook.com (2603:10b6:208:169::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.11; Mon, 19 Oct 2020 15:09:08 +0000 Received: from MN2PR13MB4087.namprd13.prod.outlook.com ([fe80::a85c:e7b3:4471:18f8]) by MN2PR13MB4087.namprd13.prod.outlook.com ([fe80::a85c:e7b3:4471:18f8%7]) with mapi id 15.20.3499.015; Mon, 19 Oct 2020 15:09:07 +0000 From: Huaimo Chen To: "lsr@ietf.org" Thread-Topic: draft-xie-lsr-isis-sr-vtn-mt-02 Thread-Index: AQHWph98qMRWSMMbYECf37g6lDukqQ== Date: Mon, 19 Oct 2020 15:09:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2601:199:4300:8e5a:dfd:1127:ed96:de02] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f15b9218-a8b3-4935-ca71-08d87440ed3e x-ms-traffictypediagnostic: MN2PR13MB3535: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0AnPSqk6WxbC9aae8Tzt/jozcMrYdwlv7vGxILNmGU9DCeC/44tLr4gSvsgM9eNr9ujU590+agnlL+fzLea1z2Hhgs5A4jAbBGO/ld/Vc3bwdoj1+McPRKeJbuavkJIdh1cq05zePgvweGPJ4krQcjDpQNxpj3c/V/J01uIhjHkt/y8P5yZHV8HFYg4vjKTdC/nES9vEtH07WOQgtyj7RXV0lIaDPYWOVqduMGizDXIJjpsBNQCsxt0aWlXhVxCei/7DCsgXc0GDK6HmSuwEUiQ1xxs/0y+/X8Nc/fErhxJdZtnK5WZEKMIj4xB3iC1rNCm9UdO1eYr6B4IRJOIBCw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB4087.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(136003)(39840400004)(376002)(346002)(478600001)(7696005)(19627405001)(83380400001)(8676002)(33656002)(86362001)(6506007)(55016002)(52536014)(8936002)(316002)(5660300002)(71200400001)(6916009)(2906002)(44832011)(64756008)(66446008)(66556008)(66476007)(66946007)(9686003)(76116006)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: b6ng2a899AYCxRXeDZX9o63tvICVS1boWb7LKDZAVpodA96VK6EvadQsIL3FziRSl+BARGVtbBwomGBul4cDBoGGW6vUqY6TU8451ngIOyBZljBzsmXaiWBFEY6+xuWdRjXL4qrNFkT+asw9Ll/wrUdrYYzjs6XQTjp9Phptxr38SX18UQbCzFfcIRZiew7P+bCP+5FKscvGqvCXJx2Sdixrwvi9GtAznMRbly/v7AgVt5X/JPC4bGULf9bPrea6nQRQaZhgp5YBO6umqWAbxlhoFiLAzBnw9c2FIGCKMKcjxQ3HOz+xjZemXuThzQBa/4cutvNXrQ5f4PKBFG+8eBzixPr2YxIxAol3BCldRO2rRwgq9wPG89gNQayzKzI6OI+1Msc7MRovy6zQMken/LhtTrOEvZ65UARkbaRyS2GO5najTQT3nR5vRzxh5meNm7DC1Zl8m05HpnWR51pBaNydEXf7hO7kOpTVDcuIdjuy2yQe7SBK2P4ibBO9KpOED6MDcAQe30R1kiGaTwUoG3TG9Lw5SxkJf6u3yXxnJhWIG3vKZl4nLFrUOrqf5lAak81pmAaLHnjbyFjHrpltfxlaczIt8IedkCWztw0EI6HuhcswaqinFvy5rm6sH4Uoa1nEmlUSj1g+jPWVM5y3UqUIDEe10/MdL/hpWlODbpf6r3gQugRpHaJqS2PLXLjpapAxFdTAxfW4YF6Hy4dliw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB40878C9C29F8332CA7CD69F1F21E0MN2PR13MB4087namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB4087.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f15b9218-a8b3-4935-ca71-08d87440ed3e X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 15:09:07.8386 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JXASO5LhK6nXQc2blia2jnZzythi/Dd+aLdKGrbq+sPhtyQH5PufnA0JE60+VFtHsV+a20D0odzD3wQAl+75Nw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3535 Archived-At: Subject: [Lsr] draft-xie-lsr-isis-sr-vtn-mt-02 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 15:09:12 -0000 --_000_MN2PR13MB40878C9C29F8332CA7CD69F1F21E0MN2PR13MB4087namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Authors, I have the following comments/questions: In a network, can we use other methods to define VTNs while MTs are use= d as VTNs? If so, other methods may be used to define VTNs in addition to using MT= s as VTNs in the same network. The draft says that MT-ID could be used as V= TN-ID. In this case, a block of VTN-IDs must be allocated/reserved speciall= y for using MT-IDs as VTN-IDs. It seems better to state something about thi= s in the draft. An IS-IS MT has the attributes of a VTN, including the specific topolog= y and resource. An IS-IS MT can be used as a VTN and MT-ID can be used as a= VTN ID. Is it possible for an IS-IS MT to be used/shared by two or more VT= Ns? If so, it seems better to have some details about how the multiple VTNs= use/share the resource in the same one MT. In section 5 "Scalability Considerations", the draft says that while mu= ltiple VTNs share the same topology attribute, the same topology is identif= ied by multiple different MT-IDs. This seems giving a way to let two or mor= e VTNs to use/share one MT if IS-IS MT allows multiple MT-IDs to be used fo= r the same one MT. It seems better to move the related text from section 5 = to some of the previous sections. Best Regards, Huaimo --_000_MN2PR13MB40878C9C29F8332CA7CD69F1F21E0MN2PR13MB4087namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Authors,

    I have the following comments/questions:

    In a network, can we use other methods to define VTNs while MTs are used as= VTNs? 

    If so, other methods may be used to define VTNs in addition t= o using MTs as VTNs in the same network. The draft says that MT-ID cou= ld be used as VTN-ID. In this case, a block of VTN-IDs must be allocated/re= served specially for using MT-IDs as VTN-IDs. It seems better to state something about this in the draft.
     
    An IS-IS MT has the attributes of a VTN, including th= e specific topology and resource. An IS-IS MT can be used as a VTN and MT-I= D can be used as a VTN ID. Is it possible for an IS-IS MT to be used/shared by two or more VTNs? If so, it seems better to = have some details about how the multiple VTNs use/share the resource in the= same one MT. 

    In section 5 "Scalability Considerations", the draf= t says that while multiple VTNs share the same topology attribute, the same= topology is identified by multiple different MT-IDs. This seems giving a w= ay to let two or more VTNs to use/share one MT if IS-IS MT allows multiple MT-IDs to be used for the same one MT. It seems better = to move the related text from section 5 to some of the previous sections.

Best Regards,
Huaimo
--_000_MN2PR13MB40878C9C29F8332CA7CD69F1F21E0MN2PR13MB4087namp_-- From nobody Mon Oct 19 08:22:03 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F126A3A0408; Mon, 19 Oct 2020 08:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=juniper.net header.b=kP+/6XH6; dkim=pass (1024-bit key) header.d=juniper.net header.b=eOdBB0GR 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 KFeYZGb2zZ3F; Mon, 19 Oct 2020 08:21:55 -0700 (PDT) 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 D041E3A0489; Mon, 19 Oct 2020 08:21:55 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 09JFIKvP032037; Mon, 19 Oct 2020 08:21:23 -0700 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 : content-transfer-encoding : mime-version; s=PPS1017; bh=updd6nQ37Z3r5aMpVWhIcWHbW6iDFD9hQDIX4w0Oi7c=; b=kP+/6XH6h3K0h5tarc/yzn/sYjOjxeSY9cCmKzfdpOc/X/S0UZIsw9WmpoX+ycvNITBy CGGKQaqFeRrxqlh3b+5+4u5d8DOBZpBbpNmNDTPqzrmbDdijGiT1YFUdJc0r4t9pfxKB N0ijLBl/KudArUZ8y5ZO7F7v+bNDLLwWH/bPJJHyHug6MVp6dF9WRVr/fFBv0BxKbA2/ 5jVH0CWYrj7fsdjdAJG48D7Axty0vme52wq7qdcx7/H4jDFAoocwxrZObgi74ks7OMAN SNOVQBgICYZI2v9xKULuAeOkBuqOXWQOPBeV8hJfvBPrw/1ZqZmpI1VuNtt0iQZeJkDx Jg== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2173.outbound.protection.outlook.com [104.47.58.173]) by mx0a-00273201.pphosted.com with ESMTP id 347ympakjn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 08:21:22 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nkT2kG5Xl++ABrTN18mzzpLa5/tXdLO3PjscraX1TiO3uNACSwaRaC9D3uMU69KxJ8oO3MLbGYZoG9F570zBH8nfv5jcufUj1AwSKUE5cwVmINnGq8Z1vySIaInIjhot55kfExIsnWel+WaKVI2oDDJmfbQpMvwUI/AP83tH5hNkO2gZLYm3jeFB9fA3lb/iNwgepTJGHHil5neH9v23LuL138HfVa165xXa2K8V7D0J/65TCUaZuEi0eXPXUt+KnYbExwIOxJYdihvQUFsoGKI/ViwcM757NawhUE1x8v8NNu0RrJlSsC50lQ6wLao+oGxwMzolxWBgDZYZR8woFQ== 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=updd6nQ37Z3r5aMpVWhIcWHbW6iDFD9hQDIX4w0Oi7c=; b=c+7Bevrn1Um6LpTr1KtmEeQOqQPd45jWHeg5NmQs08NXkuY1rDPZBszAeq1RLWlBFSI7d00doC2+qPDFDUMEOa4p4fJNSmZQsrOuu7wnCC5YjL/sBny2NZjTqsaM4alfdpZ9gnEW/nC3rLuSSdcPAcNEai79/Xh3o4ZIHIA9a8KDmzdandklx73lBw0LJfz7TJ2R+1E3SJKkmNykul6f34ZE/WSgGk1J6bcO1u3EmclT8pfFBLHkqeihmmCT3qsesHd6MSnNIDmDn2AQ+t3VIt7uU9ou66Bhmg6mhH50o65yQcNKzcGgNaAfDkj9vUWPNtu2N0k425xCBgyPBDMnsw== 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=updd6nQ37Z3r5aMpVWhIcWHbW6iDFD9hQDIX4w0Oi7c=; b=eOdBB0GR3E0Fnsudzw6w1ombdvVwbuimwd8NWol647unsXOvhZJMqICArAwUJgjJglGSBV/qRb9NHfsVV3J38S0u8raSatxQ1L0Uz5uwhY7G2blPtJGR9IN27koe/Ce+gOsse4jhVpaJFot13uVXp7KsppVrN9HvcYer9OlM+yk= Received: from DM5PR05MB3388.namprd05.prod.outlook.com (2603:10b6:4:40::18) by DM6PR05MB4922.namprd05.prod.outlook.com (2603:10b6:5:19::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.11; Mon, 19 Oct 2020 15:21:19 +0000 Received: from DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865]) by DM5PR05MB3388.namprd05.prod.outlook.com ([fe80::49db:8508:5310:7865%7]) with mapi id 15.20.3499.015; Mon, 19 Oct 2020 15:21:19 +0000 From: John E Drake To: Aijun Wang CC: "wangaj3@chinatelecom.cn" , Peter Psenak , "Les Ginsberg (ginsberg)" , Christian Hopps , "lsr-chairs@ietf.org" , "lsr@ietf.org" , Jeff Tantsura , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWpiYR0KcCJ8mdqUel/hfY/2+TFqmfAeewgAAC9gCAAAVHcA== Date: Mon, 19 Oct 2020 15:21:18 +0000 Message-ID: References: <039FF1DD-2186-4FCF-8CEA-105DF1F49E2F@tsinghua.org.cn> In-Reply-To: <039FF1DD-2186-4FCF-8CEA-105DF1F49E2F@tsinghua.org.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-10-19T15:21:17Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=c3e78fb6-1fa1-48eb-b513-21e62873f58f; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: tsinghua.org.cn; dkim=none (message not signed) header.d=none;tsinghua.org.cn; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: cf6f8b15-6ba1-4192-d509-08d87442a103 x-ms-traffictypediagnostic: DM6PR05MB4922: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZYJgcCetlzCDpXo5KdNacP0VRctQRuZDajqypzXAiwPLcr9xy8M1FYYWeoDmDcBlBA6rMTLhjWDP0twrnnUrQwY/FceIo3V36XtfDHO65bItTGV4N6oxfE9PAsjRaLJ7nQslQ1izN9rE5RgQlDMOtFgthTrwws+wiTCZD6mtixfTcVE1iwxyOEM2h1mXhzdv2vKNoAVH0QkwkrK/3iGUp8HUmTE6mqrG3Bn9ckzupoOfEsd8nFwdJ3kq5DM2HNT600iKhOZlwLNvLxFeI/owZS+Nb0Zsy4JK2fNjqZItbR/tkgPMaGAjtgsokn3kc1S0rptkr2htwvjJig2GHUco5N5KI/Aih/gioSkQbU2X2LvE90Vivl32CwX5jZlKDwzs+aTl/JGZZF1JN+UK49LZTQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3388.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(346002)(136003)(39860400002)(376002)(66476007)(9686003)(33656002)(316002)(66556008)(54906003)(55016002)(6916009)(4326008)(71200400001)(26005)(86362001)(5660300002)(30864003)(966005)(66574015)(478600001)(66446008)(53546011)(6506007)(186003)(7416002)(2906002)(7696005)(83380400001)(52536014)(64756008)(76116006)(8936002)(8676002)(66946007)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: G0jhP0abZl5SenNHG4D8LEQjVwx0Vyj0q6lDYkvoTa3hgNK5ruprQFO8aQknzbYySxGot0GsnKOyu1ZF546T2eLxC/evbvvPCivimCrAUIN7nwpOnJXAKvijCCSAC++gh5/n/oJNQMn+vUH9LpGZ+MO4i7zf9baKtPIPn9tvr4UfKmjSsGi3iTEDFRveeCBYvGTfls0xV8XAWck3HxnwEcPZNNt72acArX7Jj3jO4JQgoomSq57VLBlqBsuqeB1HUW92/IsGT9kdUdgP7v5l08NFmkGIQJxR/gtY6rVPPGLGUGJ6bc0KHXJC9gNQ6arC5DFytpX7UinvlRFO/m408er3pXPmnUxQUHbDqJXV0a4HuxMzTmB3WdE3ASWaCLDeABGeZW4Jc2I3mAU2uRz9rKxyAXvAMYZle0ME0ngWS+jHXFrP/7kJQYfLbahSwBjGWjgxaIy/q9N+efrOAQUD5+xw9HEbIs3FyyD7fZEhvoGhmBPCqaInpHBbpEmEUmAUTDEPfBxGbwxCfspK6iJFU9tIGcSv4FDy9Ba6r5J8D+85HjHzLxLXZR0w5mKJwIkmusQN9A3aemhtkA7lu1P4UnlhGT+oG08s2TmVCZa91rdNkpASxQ8CSGp6ZQifvxaG+8TKPrGXeEL+EhSZwruXLQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR05MB3388.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf6f8b15-6ba1-4192-d509-08d87442a103 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 15:21:19.0232 (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: Bhl8Ymyx9FHt1MsOqqq8gKaY6+yjjlKpmFF76WegWnPYBlmnGXwbnJ7liGMWNvZjKboVIUUtUfJwdPoUx3nshg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4922 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-19_06:2020-10-16, 2020-10-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 suspectscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 clxscore=1015 lowpriorityscore=0 adultscore=0 spamscore=0 impostorscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190107 Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 15:22:02 -0000 Tm8sIGFzIEkgaW5kaWNhdGVkIHByZXZpb3VzbHksIHRoaXMgZGlzY3Vzc2lvbiBoYXMgYmVlbiBo YWQgbWFueSB0aW1lcyAtIGl0IHJlbWluZHMgbWUgb2YgJ0dyb3VuZGhvZyBEYXknLg0KDQpZb3Vy cyBJcnJlc3BlY3RpdmVseSwNCg0KSm9obg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBaWp1biBXYW5nIDx3YW5n YWlqdW5AdHNpbmdodWEub3JnLmNuPg0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMjAg MTE6MDAgQU0NCj4gVG86IEpvaG4gRSBEcmFrZSA8amRyYWtlQGp1bmlwZXIubmV0Pg0KPiBDYzog d2FuZ2FqM0BjaGluYXRlbGVjb20uY247IFBldGVyIFBzZW5hayA8cHBzZW5ha0BjaXNjby5jb20+ OyBMZXMNCj4gR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsgQ2hyaXN0 aWFuIEhvcHBzDQo+IDxjaG9wcHNAY2hvcHBzLm9yZz47IGxzci1jaGFpcnNAaWV0Zi5vcmc7IGxz ckBpZXRmLm9yZzsgSmVmZiBUYW50c3VyYQ0KPiA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+OyBk cmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnOyBsc3ItDQo+IGFk c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0xzcl0gV0cgTGFzdCBDYWxsIGRyYWZ0LWlldGYt bHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gDQo+IFtFeHRlcm5hbCBFbWFpbC4gQmUg Y2F1dGlvdXMgb2YgY29udGVudF0NCj4gDQo+IA0KPiBXb3VsZCB5b3UgbGlrZSB0byByZWZlciB0 aGUgY2FzZXMgcmFpc2VkIGZyb20gUm9iZXJ0Pw0KPiBTdWNoIGRpc2N1c3Npb24gY2FuIGJlIGZy dWl0ZnVsIGZvciB0aGUgcmVmaW5lIG9yIGZvcndhcmRpbmcgb2YgdGhpcyBkcmFmdC4NCj4gT25l IHNob3VsZCBjb252aW5jZSBvdGhlcnMgYmFzZWQgb24gdGhlIGZhY3QsIG5vdCBzdWJqZWN0aXZl IG9waW5pb24uDQo+IA0KPiBBaWp1biBXYW5nDQo+IENoaW5hIFRlbGVjb20NCj4gDQo+ID4gT24g T2N0IDE5LCAyMDIwLCBhdCAyMjo1MiwgSm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBlci5uZXQ+ IHdyb3RlOg0KPiA+DQo+ID4g77u/SGksDQo+ID4NCj4gPiBJdCBzZWVtcyB0aGF0IHdlIGhhdmUg YmVlbiBnb2luZyBhcm91bmQgb24gdGhpcyB0b3BpYyBmb3IgYW4gZXRlcm5pdHksIHNvIHRvDQo+ IGV4cGxhaW4gaXQgYWdhaW4gd291bGQgc2ltcGx5IGJlIGFuIGV4ZXJjaXNlIGluIHBvdW5kaW5n IHNhbmQuDQo+ID4NCj4gPiBZb3VycyBJcnJlc3BlY3RpdmVseSwNCj4gPg0KPiA+IEpvaG4NCj4g Pg0KPiA+DQo+ID4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KPiA+DQo+ID4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IHdhbmdhajNAY2hpbmF0ZWxlY29tLmNuIDx3 YW5nYWozQGNoaW5hdGVsZWNvbS5jbj4NCj4gPj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAy MDIwIDEwOjQxIEFNDQo+ID4+IFRvOiBKb2huIEUgRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5ldD4N Cj4gPj4gQ2M6IFBldGVyIFBzZW5hayA8cHBzZW5ha0BjaXNjby5jb20+OyBQZXRlciBQc2VuYWsN Cj4gPj4gPHBwc2VuYWtAY2lzY28uY29tPjsgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNi ZXJnQGNpc2NvLmNvbT47DQo+ID4+IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+ OyBBaWp1biBXYW5nDQo+ID4+IDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPjsgbHNyLSBjaGFp cnNAaWV0Zi5vcmc7IGxzckBpZXRmLm9yZzsgSmVmZg0KPiA+PiBUYW50c3VyYSA8amVmZnRhbnQu aWV0ZkBnbWFpbC5jb20+OyBkcmFmdC0NCj4gPj4gaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2lu YXRvckBpZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW0xzcl0g V0cgTGFzdCBDYWxsDQo+ID4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3It MDYNCj4gPj4NCj4gPj4gW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0K PiA+Pg0KPiA+Pg0KPiA+PiBIaSwgSm9objoNCj4gPj4NCj4gPj4gV291bGQgeW91IGxpa2UgdG8g aWxsdXN0cmF0ZSB5b3VyIGJyb2tlbiBjYXNlIG1vcmUgY2xlYXJseSBhbmQgbm90DQo+ID4+IG1h a2UgdGhlIGNvbmNsdXNpb24gc28gaHVycnk/DQo+ID4+DQo+ID4+DQo+ID4+IEFpanVuIFdhbmcN Cj4gPj4gQ2hpbmEgVGVsZWNvbQ0KPiA+Pg0KPiA+Pj4gT24gT2N0IDE5LCAyMDIwLCBhdCAyMjox NSwgSm9obiBFIERyYWtlDQo+ID4+IDxqZHJha2U9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9y Zz4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4g77u/QWlqdW4sDQo+ID4+Pg0KPiA+Pj4gV2hhdCBwYXJ0 IG9mICJ1c2luZyBJUCBhZGRyZXNzIGFkdmVydGlzZW1lbnQgdG8gZGVyaXZlIHRvcG9sb2dpY2Fs DQo+ID4+PiBkYXRhIGlzDQo+ID4+IGJyb2tlbiIgZG8geW91IG5vdCB1bmRlcnN0YW5kPw0KPiA+ Pj4NCj4gPj4+IFlvdXJzIElycmVzcGVjdGl2ZWx5LA0KPiA+Pj4NCj4gPj4+IEpvaG4NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KPiA+Pj4NCj4gPj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IFBldGVyIFBzZW5hayA8cHBz ZW5ha0BjaXNjby5jb20+DQo+ID4+Pj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDIwIDY6 MzIgQU0NCj4gPj4+PiBUbzogQWlqdW4gV2FuZyA8d2FuZ2FqM0BjaGluYXRlbGVjb20uY24+OyBQ ZXRlciBQc2VuYWsNCj4gPj4+PiA8cHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4N Cj4gPj4+PiBDYzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbT47 IEFpanVuIFdhbmcNCj4gPj4+PiA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj47IENocmlzdGlh biBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+Ow0KPiA+Pj4+IEpvaG4gRSBEcmFrZSA8amRyYWtl QGp1bmlwZXIubmV0PjsgbHNyLWNoYWlyc0BpZXRmLm9yZzsNCj4gPj4+PiBsc3JAaWV0Zi5vcmc7 IEplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsNCj4gPj4+PiBkcmFmdC1p ZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnOyBsc3ItIGFkc0BpZXRmLm9y Zw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPj4+PiBkcmFmdC1p ZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4+Pj4gW0V4dGVybmFsIEVtYWls LiBCZSBjYXV0aW91cyBvZiBjb250ZW50XSBIaSBBaWp1biwgcGxlYXNlIHNlZSBpbmxpbmU6DQo+ ID4+Pj4+IE9uIDE5LzEwLzIwMjAgMTI6MTAsIEFpanVuIFdhbmcgd3JvdGU6DQo+ID4+Pj4+IEhp LiBQZXRlciwgTGVzOg0KPiA+Pj4+PiBXZSBoYXZlIGRlZmluZWQgbWFueSBleHRlbnNpb25zIGZv ciBwcm90b2NvbCwgYnV0IG9ubHkgYSBzbWFsbA0KPiA+Pj4+PiBwYXJ0IG9mIHRoZW0NCj4gPj4+ PiBhcmUgZGVwbG95ZWQuIEhhdmUgeW91IGV2ZXIgY29uc2lkZXJlZCB0aGUgcmVhc29uPw0KPiA+ Pj4+PiBBZGRpbmcgbW9yZSBjb250ZW50cyBmb3IgdGhlaXIgIHBvdGVudGlhbCB1c2FnZXMgY2Fu IGNlcnRhaW5seSBiZQ0KPiA+Pj4+PiBoZWxwZnVsIGZvcg0KPiA+Pj4+IHRoZWlyIGluZmx1ZW5j ZXMsIG9yIGVsc2UsIHRoZXkgd2lsbCBqdXN0IHN0YXkgYXQgdGhlIElFVEYgcmVwb3NpdG9yeS4N Cj4gPj4+PiBJIGRpc2FncmVlLiBSRkNzIGFyZSBub3QgZGVwbG95bWVudCBvciB1c2UgY2FzZSBk b2N1bWVudHMuIFRoZXkNCj4gPj4+PiBleGlzdHMgdG8gYWRkcmVzcyB0aGUgaW50ZXJvcGVyYWJp bGl0eS4NCj4gPj4+Pj4gTW9yZSByZXBsaWVzIGlubGluZSBiZWxvdy4NCj4gPj4+Pj4gQWlqdW4g V2FuZw0KPiA+Pj4+PiBDaGluYSBUZWxlY29tDQo+ID4+Pj4+PiBPbiBPY3QgMTksIDIwMjAsIGF0 IDE3OjE0LCBQZXRlciBQc2VuYWsNCj4gPj4+PiA8cHBzZW5haz00MGNpc2NvLmNvbUBkbWFyYy5p ZXRmLm9yZz4gd3JvdGU6DQo+ID4+Pj4+PiBBaWp1biwNCj4gPj4+Pj4+PiBPbiAxOS8xMC8yMDIw IDA5OjMyLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSB3cm90ZToNCj4gPj4+Pj4+PiBBaWp1biAt DQo+ID4+Pj4+Pj4gSSBhbSBub3QgZ29pbmcgdG8gY29udGludWUgdGhlc2Ugc2lkZSBkaXNjdXNz aW9ucyB3aXRoIHlvdS4NCj4gPj4+Pj4+PiBUaGUgcHJpbWFyeSBwdXJwb3NlIG9mIHRoZSBwcm90 b2NvbCBleHRlbnNpb25zIGFyZSBhcyBzdGF0ZWQgaW4NCj4gPj4+Pj4+PiB0aGUgZHJhZnQNCj4g Pj4+PiBJbnRyb2R1Y3Rpb24uIFRoaXMgaXMgYW5hbG9nb3VzIHRvIHRoZSB1c2UgY2FzZXMgZm9y IHRoZSBlcXVpdmFsZW50DQo+ID4+Pj4gZXh0ZW5zaW9ucyBmb3IgSVMtSVMgYWxyZWFkeSBhcHBy b3ZlZCBpbiBSRkMgNzc5NC4gV2UgbmVlZCB0aGUNCj4gPj4+PiBlcXVpdmFsZW50IGluDQo+ID4+ IE9TUEYuDQo+ID4+Pj4+Pj4gWW91IGNhbiBzaG93IHRoYXQgeW91IGFyZSBsaXN0ZW5pbmcgdG8g dGhlIGNvbmNlcm5zIG9mIFdHDQo+ID4+Pj4+Pj4gbWVtYmVycyBieQ0KPiA+Pj4+IHJlbW92aW5n IHRoZSBBcHBlbmRpY2VzIC0gaW4gd2hpY2ggY2FzZSB5b3UgaGF2ZSAoSSBiZWxpZXZlKSBicm9h ZA0KPiA+Pj4+IHN1cHBvcnQgZm9yIG1vdmluZyB0aGUgZHJhZnQgZm9yd2FyZC4NCj4gPj4+Pj4+ IEkgYWdyZWUgd2l0aCBMZXMuDQo+ID4+Pj4+PiBBcyBhIGNvLWF1dGhvciwgSSBoYXZlIGFza2Vk IHlvdSBzZXZlcmFsIHRpbWVzIHRvIGdldCByaWQgb2YgdGhlDQo+ID4+Pj4+PiB1c2UgY2FzZQ0K PiA+Pj4+IGRlc2NyaWJlZCBpbiBhcHBlbmRpeC4NCj4gPj4+Pj4gW1dBSl0gTW92aW5nIHRoZSBl eHBhbnNpb24gb2YgdGhpcyB1c2UgY2FzZSBmcm9tIGJvZHkgcGFydCBvZiB0aGlzDQo+ID4+Pj4+ IGRyYWZ0IHRvIGl0cw0KPiA+Pj4+IGFwcGVuZGl4IGlzIG91ciBpbml0aWFsIGNvbnNlbnN1cywg bm90IHJlbW92ZSBpdCB0b3RhbGx5LiBXZSBoYXZlDQo+ID4+Pj4gZGlzY3Vzc2VkIGludGVuc2Vs eSBmb3IgaXRzIGFwcGxpY2F0aW9uIGluIHZhcnkgc2l0dWF0aW9ucy4gVGhlDQo+ID4+Pj4gZGlz Y3Vzc2lvbiByZXN1bHRzIGFyZSBzdGF0ZWQgY2xlYXJseSBpbiB0aGUgYXBwZW5kaXguDQo+ID4+ Pj4ganVzdCBiZWNhdXNlIHlvdSBpbnNpc3RlZCBhbmQgZGlkIG5vdCBsaXN0ZW4gdG8gcmVzdCBv ZiB1cy4NCj4gPj4+Pj4gV2lzaCB0byBoZWFyIG1vcmUgdGVjaG5pY2FsIGFuYWx5c2lzL2NvbW1l bnRzIGZvciB0aGUgY3VycmVudA0KPiA+Pj4+PiBzdGF0ZW1lbnRzIG9mDQo+ID4+Pj4gdGhpcyBw YXJ0IGZyb20gb3RoZXIgZXhwZXJ0cywgb3IgZnJvbSB5b3UgaWYgeW91IGhhdmUgZnJlc2ggY29u c2lkZXJhdGlvbi4NCj4gPj4+PiB3ZSBhcmUgaW4gYSBjaXJjbGUuIE11bHRpcGxlIFdHIG1lbWJl cnMgKExlcywgVG9ueSBQLiBBY2VlLCBLZXRhbiwNCj4gPj4+PiBteXNlbGYpIGFyZSB0ZWxsaW5n IHlvdSB0aGF0IHVzaW5nIElQIGFkZHJlc3MgYWR2ZXJ0aXNlbWVudCB0bw0KPiA+Pj4+IGRlcml2 ZSB0b3BvbG9naWNhbCBkYXRhIGlzIGJyb2tlbiBhbmQgeW91IGtlZXAgcmVwZWF0aW5nIGl0IGlz DQo+ID4+Pj4gdmFsaWQgdXNlIGNhc2UgYW5kIGFzayBmb3IgbW9yZSByZWFzb25pbmcuDQo+ID4+ Pj4gdGhhbmtzLA0KPiA+Pj4+IFBldGVyDQo+ID4+Pj4+PiBUcnlpbmcgdG8gdXNlIHByZWZpeCBh ZHZlcnRpc2VtZW50IHRvIGRlcml2ZSB0b3BvbG9naWNhbCBkYXRhIGlzDQo+ID4+Pj4+PiBzaW1w bHkNCj4gPj4+PiBicm9rZW4uIFRoZSByZWFzb24gd2UgYXJlIGFkZGluZyB0aGUgcHJlZml4IG9y aWdpbmF0b3IgZXh0ZW5zaW9uIHRvDQo+ID4+Pj4gT1NQRiBpcyBOT1QgdGhlIGJyb2tlbiB1c2Ug Y2FzZSBpbiB0aGUgYXBwZW5kaXggb2YgdGhlIGRyYWZ0Lg0KPiA+Pj4+Pj4gdGhhbmtzLA0KPiA+ Pj4+Pj4gUGV0ZXINCj4gPj4+Pj4+PiBZb3UgY2FuIHRoZW4gd3JpdGUgYSBzZXBhcmF0ZSBkcmFm dCB0byBkaXNjdXNzIG90aGVyIHVzZSBjYXNlcw0KPiA+Pj4+Pj4+IGFuZCBhbGxvdyB0aGUNCj4g Pj4+PiBXRyB0byBkaXNjdXNzIHRob3NlIG90aGVyIHVzZSBjYXNlcyB3L28gcHJldmVudGluZyB0 aGUgZXh0ZW5zaW9ucw0KPiA+Pj4+IGZyb20gYmVpbmcgYXBwcm92ZWQgYW5kIGRlcGxveWVkIGZv ciB0aGUgdXNlIGNhc2VzIHdoaWNoIGhhdmUNCj4gPj4+PiBhbHJlYWR5IGJlZW4gZGVtb25zdHJh dGVkIGFzIHVzZWZ1bCBieSBJUy1JUy4NCj4gPj4+Pj4+PiBJZiB5b3UgcmVtb3ZlIHRoZSBBcHBl bmRpY2VzIEkgY2FuIHN1cHBvcnQgdGhlIGRyYWZ0Lg0KPiA+Pj4+Pj4+IElmIHlvdSBkbyBub3Qg cmVtb3ZlIHRoZSBBcHBlbmRpY2VzIEkgY2Fubm90IHN1cHBvcnQgdGhlIGRyYWZ0Lg0KPiA+Pj4+ Pj4+IFBsZWFzZSBkaXNjdXNzIHRoaXMgd2l0aCB5b3VyIGNvLWF1dGhvcnMgYW5kIGNvbWUgdG8g Y29uc2Vuc3VzDQo+ID4+Pj4+Pj4gb24geW91cg0KPiA+Pj4+IG5leHQgc3RlcC4NCj4gPj4+Pj4+ PiBMZXMNCj4gPj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+Pj4g RnJvbTogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4NCj4gPj4+Pj4+Pj4g U2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDIwIDEyOjA2IEFNDQo+ID4+Pj4+Pj4+IFRvOiBM ZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsgJ0NocmlzdGlhbiBI b3BwcycNCj4gPj4+Pj4+Pj4gPGNob3Bwc0BjaG9wcHMub3JnPg0KPiA+Pj4+Pj4+PiBDYzogJ0pv aG4gRSBEcmFrZScgPGpkcmFrZUBqdW5pcGVyLm5ldD47IGxzci1jaGFpcnNAaWV0Zi5vcmc7DQo+ ID4+Pj4+Pj4+IGxzckBpZXRmLm9yZzsgJ0plZmYgVGFudHN1cmEnIDxqZWZmdGFudC5pZXRmQGdt YWlsLmNvbT47DQo+ID4+Pj4+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LSBvcmlnaW5h dG9yQGlldGYub3JnOw0KPiA+Pj4+Pj4+PiBsc3ItYWRzQGlldGYub3JnDQo+ID4+Pj4+Pj4+IFN1 YmplY3Q6IFJFOiBbTHNyXSBXRyBMYXN0IENhbGwNCj4gPj4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3It b3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KPiA+Pj4+Pj4+PiBIaSwgTGVzOg0KPiA+Pj4+Pj4+ PiBBcyBJIHN0YXRlZCBjbGVhcmx5IGJlZm9yZSwgdGhlIGFwcGVuZGl4IGRlc2NyaWJlZCBpbiB0 aGUgZHJhZnQNCj4gPj4+Pj4+Pj4gaXMgbm90IHRoZSBuZXcgdXNlIGNhc2UuIEl0IGlzIHRoZSBz dGFydCBwb2ludCBvZiB0aGlzIGRyYWZ0Lg0KPiA+Pj4+Pj4+PiBIYXZlIHlvdSBub3RpY2VkIHRo YXQgdGhlIGludHJvZHVjdGlvbiBwYXJ0IGlzIG5vdCB0aGUgZmluYWwNCj4gPj4+Pj4+Pj4gdXNh Z2Ugb2Ygc3VjaCBwcm90b2NvbCBleHRlbnNpb24gaW5mb3JtYXRpb24/DQo+ID4+Pj4+Pj4+IENl cnRhaW5seSwgd2Ugd2lsbCBub3QgZXhwYW5kIGFsbCB0aGUgcG9zc2libGUgdXNlIGNhc2VzIGlu DQo+ID4+Pj4+Pj4+IHZlcnkgZGV0YWlsLCBidXQgcHV0dGluZyBzb21lIG9mIHRoZW0oc29tZSBp bnRlcmVzdGluZywNCj4gPj4+Pj4+Pj4gcHJvbWluZW50IHVzZQ0KPiA+Pj4+Pj4+PiBjYXNlcykg aW4gdGhlIGFwcGVuZGl4IHdpbGwgbm90IGhhbXBlciB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9uIGl0 c2VsZi4NCj4gPj4+Pj4+Pj4gSWYgdGhlIHN0YXRlbWVudHMvZGVzY3JpcHRpb25zIGluIHRoZSBh cHBlbmRpeCBhcmUgbm90IGNvcnJlY3QsDQo+ID4+Pj4+Pj4+IHdlIGNhbiBmaXggaXQsIG9yIHJl bW92ZSBpdCBmaW5hbGx5LiAgSWYgbm90LCB3aHkgbm90IGxldCBpdCBiZQ0KPiA+Pj4+Pj4+PiBm b3IgcmVmZXJlbmNlIHRvIHRoZSB1c2VyIG9mIHN1Y2ggcHJvdG9jb2wgZXh0ZW5zaW9uPw0KPiA+ Pj4+Pj4+PiBGb3IgdGhlIGJvZHkgcGFydCBvZiB0aGlzIGRyYWZ0LCB3ZSBhcmUgYWxzbyB3ZWxj b21lIGNvbW1lbnRzLg0KPiA+Pj4+Pj4+PiBNb3JlIHJlcGxpZXMgaW5saW5lIGJlbG93W1dBSl0N Cj4gPj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+ID4+Pj4+Pj4+IEFpanVuIFdhbmcNCj4gPj4+Pj4+ Pj4gQ2hpbmEgVGVsZWNvbQ0KPiA+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+Pj4+Pj4+PiBGcm9tOiBsc3ItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmxzci1ib3VuY2Vz QGlldGYub3JnXSBPbg0KPiA+Pj4+Pj4+PiBCZWhhbGYgT2YgTGVzIEdpbnNiZXJnIChnaW5zYmVy ZykNCj4gPj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDIwIDI6MTUgUE0NCj4g Pj4+Pj4+Pj4gVG86IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+OyAnQ2hy aXN0aWFuIEhvcHBzJw0KPiA+Pj4+Pj4+PiA8Y2hvcHBzQGNob3Bwcy5vcmc+DQo+ID4+Pj4+Pj4+ IENjOiAnSm9obiBFIERyYWtlJyA8amRyYWtlQGp1bmlwZXIubmV0PjsgbHNyLWNoYWlyc0BpZXRm Lm9yZzsNCj4gPj4+Pj4+Pj4gJ0xlcyBHaW5zYmVyZyAoZ2luc2JlcmcpJw0KPiA+Pj4+Pj4+PiA8 Z2luc2Jlcmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+Ow0KPiA+Pj4+Pj4+PiBsc3JAaWV0 Zi5vcmc7ICdKZWZmIFRhbnRzdXJhJyA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+Ow0KPiA+Pj4+ Pj4+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC0gb3JpZ2luYXRvckBpZXRmLm9yZzsNCj4g Pj4+Pj4+Pj4gbHNyLWFkc0BpZXRmLm9yZw0KPiA+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0xzcl0g V0cgTGFzdCBDYWxsDQo+ID4+Pj4+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdp bmF0b3ItMDYNCj4gPj4+Pj4+Pj4gQWlqdW4gLQ0KPiA+Pj4+Pj4+PiBUaGUgInVzZSBjYXNlIiBm b3IgdGhlIHByb3RvY29sIGV4dGVuc2lvbnMgaXMgY2xlYXJseSBzdGF0ZWQgaW4NCj4gPj4+Pj4+ Pj4gdGhlDQo+ID4+Pj4+Pj4+IEludHJvZHVjdGlvbjoNCj4gPj4+Pj4+Pj4gIlRoZSBwcmltYXJ5 IHVzZSBjYXNlIGZvciB0aGUgZXh0ZW5zaW9ucyBwcm9wb3NlZCBpbiB0aGlzDQo+ID4+Pj4+Pj4+ IGRvY3VtZW50IGlzICB0byBiZSBhYmxlIHRvIGlkZW50aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRo ZQ0KPiA+Pj4+Pj4+PiBwcmVmaXggaW4gdGhlDQo+ID4+IG5ldHdvcmsuDQo+ID4+Pj4+Pj4+IElu IGNhc2VzIHdoZXJlIG11bHRpcGxlIHByZWZpeGVzIGFyZSBhZHZlcnRpc2VkIGJ5IGEgZ2l2ZW4N Cj4gPj4+Pj4+Pj4gcm91dGVyLCBpdCAgaXMgYWxzbyB1c2VmdWwgdG8gYmUgYWJsZSB0byBhc3Nv Y2lhdGUgYWxsIHRoZXNlDQo+ID4+Pj4+Pj4+IHByZWZpeGVzIHdpdGggYSAgc2luZ2xlIHJvdXRl ciBldmVuIHdoZW4gcHJlZml4ZXMgYXJlDQo+ID4+Pj4+Pj4+IGFkdmVydGlzZWQgb3V0c2lkZSBv ZiB0aGUgYXJlYSAgaW4gd2hpY2ggdGhleSBvcmlnaW5hdGVkLiAgSXQNCj4gPj4+Pj4+Pj4gYWxz byBoZWxwcyB0byBkZXRlcm1pbmUgd2hlbiB0aGUgc2FtZSAgcHJlZml4IGlzIGJlaW5nDQo+ID4+ Pj4+Pj4+IG9yaWdpbmF0ZWQgYnkgbXVsdGlwbGUgcm91dGVycw0KPiA+PiBhY3Jvc3MgYXJlYXMu Ig0KPiA+Pj4+Pj4+PiBUaGlzIGlzIGVxdWl2YWxlbnQgdG8gbGFuZ3VhZ2UgaW4gUkZDIDc3OTQg d2hpY2ggZGVmaW5lcyB0aGUNCj4gPj4+Pj4+Pj4gYW5hbG9nb3VzIGV4dGVuc2lvbnMgZm9yIElT LUlTLg0KPiA+Pj4+Pj4+PiBFdmVyeXRoaW5nIHlvdSBoYXZlIGluIHRoZSBBcHBlbmRpeCBpcyBu b3QgcmVsYXRlZCB0byB0aGUNCj4gPj4+Pj4+Pj4gcHJpbWFyeSB1c2UgY2FzZSAtIGFuZCBpcyBm YWN0IGEgdXNlIGNhc2Ugd2hpY2ggbWFueSBvZiB1cyBoYXZlDQo+IG9iamVjdGVkIHRvLg0KPiA+ Pj4+Pj4+PiBbV0FKXSBWZXJ5IGdsYWQgdG8ga25vdyB0aGUgZmFsc2Ugc3RhdGVtZW50cyBpbiB0 aGUgYXBwZW5kaXguDQo+ID4+Pj4+Pj4+IFlvdSBhcmUgZW50aXRsZWQgdG8gd3JpdGUgYW5vdGhl ciBkcmFmdCBhZHZvY2F0aW5nIGZvciB5b3VyIG5ldw0KPiA+Pj4+Pj4+PiB1c2UgY2FzZSBpZiB5 b3Ugd2lzaCwgYnV0IHJlcXVpcmluZyB0aGF0IHRoZSBwcm90b2NvbA0KPiA+Pj4+Pj4+PiBleHRl bnNpb25zIGluIHN1cHBvcnQgb2YgdGhlIHByaW1hcnkgdXNlIGNhc2Ugbm90IGdvIGZvcndhcmQN Cj4gPj4+Pj4+Pj4gd2l0aG91dCB5b3VyIG5ldyB1c2UgY2FzZSBpcyAtIGFzIENocmlzIGhhcyBz dGF0ZWQgdmVyeSBjbGVhcmx5DQo+ID4+Pj4+Pj4+IC0gaG9sZGluZyBhcHByb3ZhbCBvZiB0aGUg cHJvdG9jb2wgZXh0ZW5zaW9ucyBob3N0YWdlIHRvIHlvdXIgbmV3DQo+IHVzZSBjYXNlLg0KPiA+ Pj4+Pj4+PiBbV0FKXSBJdCBpcyBub3QgbmV3IHVzZSBjYXNlLiBBcyBJIHNhdGVkIGJlZm9yZSwg SSBhbSBvcGVuIHRvDQo+ID4+Pj4+Pj4+IHRoaXMgcGFydCwgYnV0IHNob3VsZCBvbiB0aGUgY29u ZGl0aW9ucyB0aGF0IHRoZSBzdGF0ZW1lbnRzIGluDQo+ID4+Pj4+Pj4+IHRoaXMgcGFydCBhcmUN Cj4gPj4+PiBpbmNvcnJlY3QuDQo+ID4+Pj4+Pj4+IEkgYW0gYXNraW5nIHlvdSAoeWV0IGFnYWlu KSBub3QgdG8gZG8gdGhpcy4NCj4gPj4+Pj4+Pj4gSSBjYW5ub3Qgc3VwcG9ydCB0aGUgZG9jdW1l bnQgbW92aW5nIGZvcndhcmQgd2l0aCB0aGUgY29udGVudA0KPiA+Pj4+Pj4+PiBpbiB0aGUgQXBw ZW5kaWNlcyBpbmNsdWRlZC4NCj4gPj4+Pj4+Pj4gW1dBSl0gV291bGQgbGlrZSB0byBoZWFyIG1v cmUgdGVjaG5pY2FsIGFuYWx5c2lzLg0KPiA+Pj4+Pj4+PiBMZXMNCj4gPj4+Pj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4+PiBGcm9tOiBMc3IgPGxzci1ib3VuY2Vz QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWlqdW4gV2FuZw0KPiA+Pj4+Pj4+Pj4gU2VudDogU3Vu ZGF5LCBPY3RvYmVyIDE4LCAyMDIwIDc6MDggUE0NCj4gPj4+Pj4+Pj4+IFRvOiAnQ2hyaXN0aWFu IEhvcHBzJyA8Y2hvcHBzQGNob3Bwcy5vcmc+DQo+ID4+Pj4+Pj4+PiBDYzogJ0pvaG4gRSBEcmFr ZScgPGpkcmFrZUBqdW5pcGVyLm5ldD47IGxzci1jaGFpcnNAaWV0Zi5vcmc7DQo+ID4+Pj4+Pj4+ PiAnTGVzIEdpbnNiZXJnIChnaW5zYmVyZyknDQo+ID4+Pj4+Pj4+PiA8Z2luc2Jlcmc9NDBjaXNj by5jb21AZG1hcmMuaWV0Zi5vcmc+Ow0KPiA+Pj4+Pj4+Pj4gbHNyQGlldGYub3JnOyAnSmVmZiBU YW50c3VyYScgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsNCj4gPj4+Pj4+Pj4+IGRyYWZ0LWll dGYtbHNyLW9zcGYtcHJlZml4LSBvcmlnaW5hdG9yQGlldGYub3JnOw0KPiA+Pj4+Pj4+Pj4gbHNy LWFkc0BpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2Fs bA0KPiA+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0K PiA+Pj4+Pj4+Pj4gSGksIENocmlzOg0KPiA+Pj4+Pj4+Pj4gSSB0aGluayB3ZSBoYXZlICJwdXQg dGhlIGNhcnQgYmVmb3JlIHRoZSBob3JzZSIuIEZvciBwcm90b2NvbA0KPiA+Pj4+Pj4+Pj4gZXh0 ZW5zaW9uIGRyYWZ0LCB0aGUgb3JpZ2luIGlzIHRoZSB1c2UgY2FzZS4NCj4gPj4+Pj4+Pj4+IEFu ZCBJIHRoaW5rIHdlIHdpbGwgbm90IGV4cGFuZCBPU1BGIHByb3RvY29sLCBqdXN0IGJlY2F1c2Ug aXQNCj4gPj4+Pj4+Pj4+IGxhY2sgc29tZXRoaW5nIGFzIGNvbXBhcmVkIHdpdGggSVNJUywgcmln aHQ/DQo+ID4+Pj4+Pj4+PiBBcyBJIHN0YXRlZCBiZWZvcmUsIHRoZSB1c2UgY2FzZSBpbiBjdXJy ZW50IGFwcGVuZGl4IGlzIHRoZQ0KPiA+Pj4+Pj4+Pj4gbWFpbiBtb3RpdmF0aW9uIG9mIHRoaXMg ZHJhZnQsIHlvdSBjYW4gc2VlIHRoaXMgaW4gbWFpbiBib2R5DQo+ID4+Pj4+Pj4+PiBvZiB0aGUg ZWFybGllciB2ZXJzaW9uIG9mIHRoaXMgZHJhZnQoZnJvbSB2ZXJzaW9uIDAgdG8gdmVyc2lvbiA1 KS4NCj4gPj4+Pj4+Pj4+IFRoZSByZWFzb24gdGhhdCB3ZSBtb3ZlIHRoaXMgcGFydCB0byB0aGUg YXBwZW5kaXgsIGFzIHRoYXQgeW91DQo+ID4+Pj4+Pj4+PiBzYWlkLCBpcyB0byBsZXQgcGVyc29u IGZvY3VzIG9uIHRoZSBwcm90b2NvbCBleHRlbnNpb24gaXRzZWxmLg0KPiA+Pj4+Pj4+Pj4gTW92 aW5nIHRoaXMgcGFydCB0byBhcHBlbmRpeCBpcyBhY2NlcHRhYmxlLCBidXQgcmVtb3ZpbmcgaXQN Cj4gPj4+Pj4+Pj4+IGZyb20gdGhlIGRyYWZ0IHdpbGwgZXJhc2UgdGhlIG9yaWdpbiBvZiB0aGlz IGRvY3VtZW50Lg0KPiA+Pj4+Pj4+Pj4gSXMgaXQgcmVhc29uYWJsZSB0aGF0IG9uZSBkb2N1bWVu dCBkaXNjdXNzZXMgdGhlICJvcmlnaW4iKG9mDQo+ID4+Pj4+Pj4+PiB0aGUgcHJlZml4KSwgY2Fu J3Qga2VlcCBpdHMgb3JpZ2luPw0KPiA+Pj4+Pj4+Pj4gTW9yZSByZXBsaWVzIGlubGluZSBiZWxv d1tXQUpdLg0KPiA+Pj4+Pj4+Pj4gQmVzdCBSZWdhcmRzDQo+ID4+Pj4+Pj4+PiBBaWp1biBXYW5n DQo+ID4+Pj4+Pj4+PiBDaGluYSBUZWxlY29tDQo+ID4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4+Pj4gRnJvbTogbHNyLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPj4+Pj4+Pj4+IEJlaGFsZiBPZiBDaHJpc3Rp YW4gSG9wcHMNCj4gPj4+Pj4+Pj4+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNiwgMjAyMCAxMDo0 NyBQTQ0KPiA+Pj4+Pj4+Pj4gVG86IOeOi+eIseS/iiA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5j bj4NCj4gPj4+Pj4+Pj4+IENjOiBKb2huIEUgRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5ldD47IENo cmlzdGlhbiBIb3Bwcw0KPiA+Pj4+Pj4+Pj4gPGNob3Bwc0BjaG9wcHMub3JnPjsgbHNyLWNoYWly c0BpZXRmLm9yZzsgTGVzIEdpbnNiZXJnDQo+ID4+Pj4+Pj4+PiAoZ2luc2JlcmcpIDxnaW5zYmVy Zz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47DQo+ID4+Pj4+Pj4+PiBsc3JAaWV0Zi5vcmc7 IEplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsNCj4gPj4+Pj4+Pj4+IGRy YWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3JAaWV0Zi5vcmc7IGxzci0NCj4gPj4+ Pj4+Pj4+IGFkc0BpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtMc3JdIFdHIExh c3QgQ2FsbA0KPiA+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRv ci0wNg0KPiA+Pj4+Pj4+Pj4gSXNuJ3QgdGhpcyBqdXN0IGFkZGluZyBhbiBhbmFsb2dvdXMgZXh0 ZW5zaW9uIHRoYXQgYWxyZWFkeQ0KPiA+Pj4+Pj4+Pj4gZXhpc3RzIGluDQo+ID4+Pj4gUkZDNzc5 ND8NCj4gPj4+Pj4+Pj4+IFtXQUpdIE5vLiBSRkM3Nzk0IGlzIGp1c3Qgb25lIGV4YW1wbGUgdGhh dCB0byBpbGx1c3RyYXRlLCBhcw0KPiA+Pj4+Pj4+Pj4gdGhlIGNvbXBhbmlvbiBJR1AgcHJvdG9j b2wsIE9TUEYgY2FuIGFsc28gYWNjb21wbGlzaCB0aGlzLg0KPiA+Pj4+Pj4+Pj4gQW5kLCBhY3R1 YWxseSwgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIGNvbnNpZGVyYXRpb24gaW4gdGhpcw0KPiA+Pj4+ Pj4+Pj4gZHJhZnQgZm9yIHRoZSBwcm90b2NvbA0KPiA+Pj4+IGV4dGVuc2lvbi4NCj4gPj4+Pj4+ Pj4+IEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBkbyBhIGxvdCBvZiBjb252aW5jaW5nIGF0IHRo aXMgcG9pbnQuDQo+ID4+Pj4+Pj4+PiBJIGFncmVlIHdpdGggTGVzLCBpZiB5b3Ugd2FudCB0byB0 YWxrIGFib3V0IHVzZSBjYXNlcw0KPiA+Pj4+Pj4+Pj4gKGVzcGVjaWFsbHkgb25lcyB0aGF0IGFy ZSBjb250cm92ZXJzaWFsISkgdGhlbiB0aGUgY29ycmVjdA0KPiA+Pj4+Pj4+Pj4gcGxhY2UgZm9y IHRoYXQgaXMgaW4gYSBuZXcgaW5mb3JtYXRpdmUNCj4gPj4+Pj4+Pj4gZHJhZnQuDQo+ID4+Pj4+ Pj4+PiBbV0FKXSB3ZSBoYXZlIGRpc2N1c3NlZCB0aGUgdXNlIGNhc2UgYmVmb3JlIGFuZCBzdGF0 ZSB0aGUNCj4gPj4+Pj4+Pj4+IGRpc2N1c3Npb24gcmVzdWx0cyBhdCB0aGUgYXBwZW5kaXggcGFy dC4gV2Ugd2lsbCBub3QgZW1waGFzaXMNCj4gPj4+Pj4+Pj4+IGFuZCBleHBhbmQgdGhlIHVzZSBj YXNlIG1vcmUuIElmIG9uZSBkb2VzIG5vdCBhZ3JlZSB0aGUNCj4gPj4+Pj4+Pj4+IHN0YXRlbWVu dCBvZiB0aGlzIGFwcGVuZGl4LCB3ZSBjYW4gZGlzY3VzcyBvbmxpbmUgb3Igb2ZmbGluZS4NCj4g Pj4+Pj4+Pj4+IFdlIGp1c3QgbmVlZCB0byBtYWtlIHRoZSBzdGF0ZW1lbnQgaW4NCj4gPj4+Pj4+ Pj4gYXBwZW5kaXggaXMgY29ycmVjdC4NCj4gPj4+Pj4+Pj4+IE90aGVyd2lzZSwgZXNwZWNpYWxs eSBpZiB0aGUgY2FzZXMgYXJlIGNvbnRyb3ZlcnNpYWwsIHRoaXMgY2FuDQo+ID4+Pj4+Pj4+PiBi ZSBzZWVuIGFzIGRvaW5nIGFuICJlbmQtcnVuIiB0byBhdm9pZCB0aGUgZGViYXRlIGIvYyBwZW9w bGUNCj4gPj4+Pj4+Pj4+IHdhbnQgdGhlIGV4dGVuc2lvbiwgYnV0IG1heWJlIGRvbid0IGFncmVl IHdpdGggeW91ciB1c2UgY2FzZS4NCj4gPj4+Pj4+Pj4+IFtXQUpdIE9uZSBzaG91bGQgcG9pbnQg b3V0IHdoaWNoIHN0YXRlbWVudCBpbiB0aGUgYXBwZW5kaXggaXMNCj4gPj4+Pj4+Pj4+IGNvbnRy b3ZlcnNpYWwsIHdlIGNhbiBjb3JyZWN0IGl0LiBUaGlzIHVzZSBjYXNlIGlzIHRoZSBvcmlnaW4N Cj4gPj4+Pj4+Pj4+IG9mIHRoaXMgZHJhZnQsIG5vdCB0aGUgcmVzdWx0cy4NCj4gPj4+Pj4+Pj4+ IExlZ2lzbGF0b3JzIGRvIHRoaXMgc29tZXRpbWVzIGFkZGluZyB0aGluZ3MgdGhleSB3YW50DQo+ ID4+Pj4+Pj4+PiBwZXJzb25hbGx5IHRvIHBvcHVsYXIgYmlsbHMsIHRoYXQgb3RoZXIgcGVvcGxl IG1heSBub3Qgd2FudCwNCj4gPj4+Pj4+Pj4+IGJ1dCBzaW5jZSBwZW9wbGUgd2FudCB0aGUgbWFp biBiaWxsIHRoZXkgdm90ZSBmb3IgaXQgYW55d2F5LA0KPiA+Pj4+Pj4+Pj4gaW4gdGhlIFVTIGl0 J3MgY2FsbGVkICJhZGRpbmcgcG9yayIgb3IgInBvcmsgYmFycmVsIHBvbGl0aWNzIi4NCj4gPj4+ Pj4+Pj4+IDopIFtXQUpdIFRoZSBhcHBlbmRpeCBpcyBub3QgYWRkZWQgbGF0ZXIsIGJ1dCBleGlz dCBhdCB0aGUNCj4gPj4+Pj4+Pj4+IGZpcnN0IGJlZ2lubmluZy4gVGhpcyBpcyB0aGUgb3JpZ2lu IG9mIHRoZSBiaWxscy4NCj4gPj4+Pj4+Pj4+IFRoYW5rcywNCj4gPj4+Pj4+Pj4+IENocmlzLg0K PiA+Pj4+Pj4+Pj4+IE9uIE9jdCAxNiwgMjAyMCwgYXQgMTA6MzcgQU0sIOeOi+eIseS/ig0KPiA8 d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4NCj4gPj4+Pj4+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+ Pj4+IEhpLCBDaHJpczoNCj4gPj4+Pj4+Pj4+PiBPcmlnaW5hbGx5LCB0aGUgYXBwZW5kaXggcGFy dCBpcyB3aXRoaW4gdGhlIGRvY3VtZW50LCB3aGljaA0KPiA+Pj4+Pj4+Pj4+IGlzIHRoZSBzdGFy dA0KPiA+Pj4+Pj4+Pj4gcG9pbnQvbWFpbiBtb3RpdmF0aW9uIHRvIGV4dGVuZCB0aGUgcHJlZml4 IG9yaWdpbi4NCj4gPj4+Pj4+Pj4+PiBUaGVyZSBtYXkgZXhpc3RzIG90aGVyIHVzYWdlcyBvZiB0 aGlzIGluZm9ybWF0aW9uLiBQYWNrIHRoZXNlDQo+ID4+Pj4+Pj4+Pj4gZXhhbXBsZXMNCj4gPj4+ Pj4+Pj4+IGludG8gc29tZSBzaG9ydCBzZW50ZW5jZXMgb3IgaW50cm9kdWN0aW9uIGlzIHZpYWJs ZSwgYnV0DQo+ID4+Pj4+Pj4+PiBleHBhbmQgc29tZSBvZiB0aGVtIGlzIGFsc28gaGVscGZ1bC4N Cj4gPj4+Pj4+Pj4+PiBBcyBJIGtub3duLCB3aGVuIHdlIHdhbnQgdG8gZG8gcHJvdG9jb2wgZXh0 ZW5zaW9uLCB3ZSBzaG91bGQNCj4gPj4+Pj4+Pj4+PiBhbHdheXMNCj4gPj4+Pj4+Pj4+IGNvbnZp bmNlIG90aGVyIHRoZSByZWFzb24vbW90aXZhdGlvbi9wcm9zcGVjdHMgdG8gZG8gc28uIE9uDQo+ ID4+Pj4+Pj4+PiB0aGUgb3RoZXIgaGFuZCwgdGhlIHVzZSBjYXNlIGRlc2NyaWJlZCBpbiB0aGUg Y3VycmVudCBhcHBlbmRpeA0KPiA+Pj4+Pj4+Pj4gaXMgdmVyeSBwcm9taW5lbnQgZm9yIG9wZXJh dG9yIHRvIGFjY29tcGxpc2ggdGhlIFRFIHRhc2sgaW4NCj4gPj4+Pj4+Pj4+IG11bHRpLWFyZWEN Cj4gPj4+PiBlbnZpcm9ubWVudC4NCj4gPj4+Pj4+Pj4+PiBBaWp1biBXYW5nDQo+ID4+Pj4+Pj4+ Pj4g5ZyoMjAyMC0xMC0xNu+8jENocmlzdGlhbiBIb3BwcyAmbHQ7Y2hvcHBzQGNob3Bwcy5vcmcm Z3Q75YaZ6YGTOg0KPiA+Pj4+Pj4+Pj4+IC0tLS0t5Y6f5aeL6YKu5Lu2LS0tLS0NCj4gPj4+Pj4+ Pj4+PiDlj5Hku7bkurrvvJogQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9yZyZn dDsNCj4gPj4+Pj4+Pj4+PiDlj5Hku7bml7bpl7Q6IDIwMjDlubQxMOaciDE25pelIOaYn+acn+S6 lA0KPiA+Pj4+Pj4+Pj4+IOWGmemBkzogWyZxdW90O0xlcyBHaW5zYmVyZyAoZ2luc2JlcmcpJnF1 b3Q7DQo+ID4+Pj4+Pj4+Pj4gJmx0O2dpbnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3Jn Jmd0O10NCj4gPj4+Pj4+Pj4+PiDkuLvpopjvvJogUmU6IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+ Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCj4gPj4+ Pj4+Pj4+Pj4gT24gT2N0IDE2LCAyMDIwLCBhdCAxOjUxIEFNLCBMZXMgR2luc2JlcmcgKGdpbnNi ZXJnKQ0KPiA+Pj4+Pj4+Pj4gPGdpbnNiZXJnPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3 cm90ZToNCj4gPj4+Pj4+Pj4+Pj4gQWlqdW4gLQ0KPiA+Pj4+Pj4+Pj4+PiBUaGUgcG9pbnQgSSBh bSBtYWtpbmcgaXMgdmVyeSBmb2N1c2VkLg0KPiA+Pj4+Pj4+Pj4+PiBUaGlzIGRyYWZ0IGlzIGRl ZmluaW5nIGEgcHJvdG9jb2wgZXh0ZW5zaW9uLiBBcyBzdWNoIGl0IGlzDQo+ID4+Pj4+Pj4+Pj4+ IG5lY2Vzc2FyeSB0aGF0IHRoaXMNCj4gPj4+Pj4+Pj4+IGJlIFN0YW5kYXJkcyB0cmFjayBhcyBh ZGhlcmluZyB0byB0aGUgbm9ybWF0aXZlIHN0YXRlbWVudHMgaW4NCj4gPj4+Pj4+Pj4+IHRoZSBk cmFmdCBhcmUgbmVjZXNzYXJ5IGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KPiA+Pj4+Pj4+Pj4+PiBX aGF0IGlzIGRpc2N1c3NlZCBpbiB0aGUgQXBwZW5kaXggaXMgYSB1c2UgY2FzZS4gSXQgaXMgbm90 DQo+ID4+Pj4+Pj4+Pj4+IG5vcm1hdGl2ZSBhbmQNCj4gPj4+Pj4+Pj4+IHRoZXJlIGFyZSBzdHJv bmcgb3BpbmlvbnMgb24gYm90aCBzaWRlcyBhcyB0byB3aGV0aGVyIHRoaXMgaXMNCj4gPj4+Pj4+ Pj4+IGFuIGFwcHJvcHJpYXRlIHVzZSBjYXNlIG9yIG5vdC4NCj4gPj4+Pj4+Pj4+Pj4gSW4gdGhl IGNvbnRleHQgb2YgdGhpcyBkcmFmdCwgSSBoYXZlIG5vIGludGVyZXN0IGluIHRyeWluZw0KPiA+ Pj4+Pj4+Pj4+PiB0byByZXNvbHZlIG91cg0KPiA+Pj4+Pj4+Pj4gZGlmZmVyZW5jZSBvZiBvcGlu aW9uIG9uIHRoaXMgdXNlIGNhc2UuIEkgc2ltcGx5IHdhbnQgdGhlDQo+ID4+Pj4+Pj4+PiBwcm90 b2NvbCBleHRlbnNpb24gdG8gbW92ZSBmb3J3YXJkIHNvIHRoYXQgd2UgaGF2ZSBhbm90aGVyDQo+ ID4+Pj4+Pj4+PiB0b29sDQo+ID4+IGF2YWlsYWJsZS4NCj4gPj4+Pj4+Pj4+Pj4gSWYgeW91IHdh bnQgdG8gd3JpdGUgYSBkcmFmdCBvbiB0aGUgdXNlIGNhc2UgZGlzY3Vzc2VkIGluDQo+ID4+Pj4+ Pj4+Pj4+IHRoZSBBcHBlbmRpeA0KPiA+Pj4+Pj4+Pj4gcGxlYXNlIGZlZWwgZnJlZSB0byBkbyBz by4gVGhhdCBkcmFmdCBtYXkgdmVyeSB3ZWxsIG5vdCBiZQ0KPiA+Pj4+Pj4+Pj4gbm9ybWF0aXZl IC0gSW5mb3JtYXRpb25hbCBvciBCQ1AgbWF5IGJlIG1vcmUgYXBwcm9wcmlhdGUgLQ0KPiA+Pj4+ Pj4+Pj4gYmVjYXVzZSBpdCB3aWxsIGJlIGRpc2N1c3NpbmcgYSBkZXBsb3ltZW50IHNjZW5hcmlv IGFuZCBhDQo+ID4+Pj4+Pj4+PiBwcm9wb3NhbCB0byB1c2UgZGVmaW5lZCBwcm90b2NvbCBleHRl bnNpb25zIGFzIG9uZSB3YXkgdG8NCj4gPj4+Pj4+Pj4+IHNvbHZlIHByb2JsZW1zIGluIHRoYXQg ZGVwbG95bWVudCBzY2VuYXJpby4gU3VjaCBhIGRyYWZ0IG1pZ2h0DQo+ID4+Pj4+Pj4+PiBhbHNv IGJlIG1vcmUgYXBwcm9wcmlhdGUgaW4gYW5vdGhlciBXRyAoZS5nLiwgVEVBUykuIFRoZQ0KPiA+ Pj4+Pj4+Pj4gbWVyaXRzIG9mIHVzaW5nIHByZWZpeCBhZHZlcnRpc2VtZW50cyB0byBidWlsZCBh IHRvcG9sb2d5DQo+ID4+Pj4+Pj4+IGNvdWxkIHRoZW4gYmUgZGlzY3Vzc2VkIG9uIGl0cyBvd24u DQo+ID4+Pj4+Pj4+Pj4+IFBsZWFzZSBkbyBub3QgdHJ5IHRvIGF2b2lkIGhhdmluZyBhIGZ1bGwg ZGlzY3Vzc2lvbiBvZiB0aGUNCj4gPj4+Pj4+Pj4+Pj4gbWVyaXRzIG9mIHVzaW5nDQo+ID4+Pj4+ Pj4+PiBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgdG8gZGVyaXZlIHRvcG9sb2d5IGJ5IGFkZGluZyBp dCB0byBhDQo+ID4+Pj4+Pj4+PiBkcmFmdCB0aGF0IGlzIChhbmQgc2hvdWxkIGJlKSBmb2N1c2Vk IG9uIHNpbXBsZSBwcm90b2NvbCBleHRlbnNpb25zLg0KPiA+Pj4+Pj4+Pj4+IFtBcyBXRyBtZW1i ZXJdDQo+ID4+Pj4+Pj4+Pj4gSSBmaW5kIHRoaXMgdmVyeSBjb21wZWxsaW5nIGFuZCBzbyBzdXBw b3J0IHRoZSByZW1vdmFsIG9mIHRoZQ0KPiA+Pj4+Pj4+Pj4+IHJlZmVycmVkIHRvDQo+ID4+Pj4+ Pj4+PiBub24tbm9ybWF0aXZlIGFwcGVuZGljZXMuDQo+ID4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPiA+ Pj4+Pj4+Pj4+IENocmlzLg0KPiA+Pj4+Pj4+Pj4+PiBUaGFueC4NCj4gPj4+Pj4+Pj4+Pj4gTGVz DQo+ID4+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4+Pj4+ Pj4gRnJvbTogQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9yZy5jbj4NCj4gPj4+Pj4+ Pj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDIwIDY6NTEgUE0NCj4gPj4+Pj4+ Pj4+Pj4+IFRvOiAnSmVmZiBUYW50c3VyYScgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsgJ0pv aG4gRSBEcmFrZScNCj4gPj4+Pj4+Pj4+Pj4+IDxqZHJha2VAanVuaXBlci5uZXQ+DQo+ID4+Pj4+ Pj4+Pj4+PiBDYzogJ0NocmlzdGlhbiBIb3BwcycgPGNob3Bwc0BjaG9wcHMub3JnPjsNCj4gPj4+ Pj4+Pj4+Pj4+IGxzci1jaGFpcnNAaWV0Zi5vcmc7IExlcyBHaW5zYmVyZw0KPiA+Pj4+Pj4+Pj4+ Pj4gKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsgbHNyQGlldGYub3JnOw0KPiA+Pj4+ Pj4+Pj4+Pj4gbHNyLWFkc0BpZXRmLm9yZzsNCj4gPj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtIGxz ci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+PiBTdWJqZWN0 OiBSRTogW0xzcl0gV0cgTGFzdCBDYWxsDQo+ID4+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWxzci1v c3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+ID4+Pj4+Pj4+Pj4+PiBIaSwgTGVzLCBKb2huIGFu ZCBKZWZmOg0KPiA+Pj4+Pj4+Pj4+Pj4gTGV0J3MgcmVwbHkgeW91IGFsbCB0b2dldGhlci4NCj4g Pj4+Pj4+Pj4+Pj4+IEluIG15IFBPViwgVGhlIHN0YW5kYXJkIGRvY3VtZW50IHNob3VsZCBub3Qg ZGVmaW5lIHNvbGVseQ0KPiA+Pj4+Pj4+Pj4+Pj4gdGhlIHByb3RvY29sIGV4dGVuc2lvbiwgYnV0 IHRoZWlyIHVzYWdlcyBpbiB0aGUgbmV0d29yaw0KPiBkZXBsb3ltZW50Lg0KPiA+Pj4+Pj4+Pj4+ Pj4gQXMgSSBrbm93biwgYWxtb3N0IGFsbCB0aGUgSUVURiBkb2N1bWVudHMgZm9sbG93aW5nIHRo aXMgc3R5bGUuDQo+ID4+Pj4+Pj4+Pj4+PiBBbmQsIGJlZm9yZSBhZG9wdGluZyBvbmUgd29yaywg d2UgaGF2ZSBvZnRlbiBpbnRlbnNlDQo+ID4+Pj4+Pj4+Pj4+PiBkaXNjdXNzaW9uIGZvciB3aGF0 J3MgdGhlaXIgdXNhZ2VzLg0KPiA+Pj4+Pj4+Pj4+Pj4gU3VjaCBkaXNjdXNzaW9uIGluIHRoZSBt YWlsIGxpc3QgYW5kIHN0YXRlbWVudHMgaW4gdGhlDQo+ID4+Pj4+Pj4+Pj4+PiBkb2N1bWVudCBj YW4gY2VydGFpbmx5IGFzc2lzdCB0aGUgcmVhZGVyL3VzZXIgb2YgdGhlDQo+ID4+Pj4+Pj4+Pj4+ PiBkb2N1bWVudCBnZXQgdGhlIGVzc2VuY2Ugb2YgdGhlIHN0YW5kYXJkLCBhbmQgZm9sbG93IHRo ZW0NCj4gdW5hbWJpZ3VvdXNseS4NCj4gPj4+Pj4+Pj4+Pj4+IFJlZ2FyZGluZyB0aGUgY29udGVu dHMgb2YgYXBwZW5kaWNlcywgYXMgc3RhdGVkIGluIHRoZQ0KPiA+Pj4+Pj4+Pj4+Pj4gc2VjdGlv biwgIlRoZSBBcHBlbmRpeCBBIGhldXJpc3RpYyB0byByZWJ1aWxkIHRoZSB0b3BvbG9neQ0KPiA+ Pj4+Pj4+Pj4+Pj4gY2FuIG5vcm1hbGx5IGJlIHVzZWQgaWYgYWxsIGxpbmtzIGFyZSBudW1iZXJl ZC4iIEkgdGhpbmsNCj4gPj4+Pj4+Pj4+Pj4+IHRoaXMgY2FuIGFwcGx5IGFsbW9zdCBtb3N0IG9m IHRoZSBvcGVyYXRvcidzIG5ldHdvcmssIGFuZA0KPiA+Pj4+Pj4+Pj4+Pj4gZmFjaWxpdGF0ZSB0 aGUgaW50ZXItYXJlYSBURSBwYXRoIGNhbGN1bGF0aW9uIGZvciBjZW50cmFsDQo+ID4+Pj4+Pj4+ Pj4+PiBjb250cm9sbGVyLCBvciBldmVuIGZvciB0aGUgaGVhZC1lbmQgcm91dGVyIHRoYXQgbG9j YXRlZCBpbg0KPiA+Pj4+Pj4+Pj4+Pj4gb25lIGFyZWEgdGhhdCBkaWZmZXJlbnQgZnJvbQ0KPiA+ Pj4+IHRoZSB0YWlsLSBlbmQgcm91dGVyLg0KPiA+Pj4+Pj4+Pj4+Pj4gS2VlcGluZyB0aGUgY29u dGVudHMgb2YgYXBwZW5kaWNlcyBkb2VzIG5vdCBoYXZlIHRoZQ0KPiA+Pj4+Pj4+Pj4+Pj4gbmVn YXRpdmUgaW1wYWN0IG9mIHRoZSBwcm90b2NvbCBleHRlbnNpb24sIGl0IGlzIGp1c3Qgb25lDQo+ ID4+Pj4+Pj4+Pj4+PiByZWZlcmVuY2UgZm9yIHRoZSB1c2FnZSBvZiB0aGlzIGV4dGVuc2lvbi4N Cj4gPj4+Pj4+Pj4+Pj4+IE9uZSBjYW4gc2VsZWN0IG5vdCByZWZlciB0byBpdCwgaWYgdGhlaXIg bmV0d29ya3MgYXJlDQo+ID4+Pj4+Pj4+Pj4+PiBkZXBsb3llZCB3aXRoIGxhcmdlIGFtb3VudCBv ZiB1bm51bWJlcmVkIGxpbmtzLiBCdXQgZm9yDQo+ID4+Pj4+Pj4+Pj4+PiBvdGhlcnMsIHRoZSBo ZXVyaXN0aWMNCj4gPj4+Pj4+Pj4gYXBwbGllcy4NCj4gPj4+Pj4+Pj4+Pj4+IEJlc3QgUmVnYXJk cw0KPiA+Pj4+Pj4+Pj4+Pj4gQWlqdW4gV2FuZw0KPiA+Pj4+Pj4+Pj4+Pj4gQ2hpbmEgVGVsZWNv bQ0KPiA+Pj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+Pj4+ Pj4+IEZyb206IGxzci1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5v cmddIE9uDQo+ID4+Pj4+Pj4+Pj4+PiBCZWhhbGYgT2YgSmVmZiBUYW50c3VyYQ0KPiA+Pj4+Pj4+ Pj4+Pj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDE2LCAyMDIwIDU6MjggQU0NCj4gPj4+Pj4+Pj4+ Pj4+IFRvOiBKb2huIEUgRHJha2UgPGpkcmFrZT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3Jn Pg0KPiA+Pj4+Pj4+Pj4+Pj4gQ2M6IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+ Ow0KPiA+Pj4+Pj4+Pj4+Pj4gbHNyLWNoYWlyc0BpZXRmLm9yZzsgTGVzIEdpbnNiZXJnDQo+ID4+ Pj4+Pj4+Pj4+PiAoZ2luc2JlcmcpIDxnaW5zYmVyZz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9y Zz47DQo+ID4+Pj4+Pj4+Pj4+PiBsc3JAaWV0Zi5vcmc7DQo+ID4+Pj4+Pj4+Pj4+PiBsc3ItIGFk c0BpZXRmLm9yZzsNCj4gPj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9y aWdpbmF0b3JAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBM YXN0IENhbGwNCj4gPj4+Pj4+Pj4+Pj4+IGRyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdp bmF0b3ItMDYNCj4gPj4+Pj4+Pj4+Pj4+ICsxDQo+ID4+Pj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPiA+ Pj4+Pj4+Pj4+Pj4gSmVmZg0KPiA+Pj4+Pj4+Pj4+Pj4+IE9uIE9jdCAxNSwgMjAyMCwgYXQgMTE6 MzMsIEpvaG4gRSBEcmFrZQ0KPiA+Pj4+Pj4+Pj4+Pj4gPGpkcmFrZT00MGp1bmlwZXIubmV0QGRt YXJjLmlldGYub3JnPiB3cm90ZToNCj4gPj4+Pj4+Pj4+Pj4+PiBIaSwNCj4gPj4+Pj4+Pj4+Pj4+ PiBJIGFncmVlIHdpdGggTGVzLiAgVGhpcyBpcyBhIHNpbXBsZSBwcm90b2NvbCBleHRlbnNpb24g Zm9yDQo+ID4+Pj4+Pj4+Pj4+Pj4gYSBzcGVjaWZpYyBwdXJwb3NlDQo+ID4+Pj4+Pj4+Pj4+PiBh bmQgdGhlcmUgaXMgbm8gcmVhc29uIHRvIGluY2x1ZGUgc3BlY3VsYXRpb24gYWJvdXQgaXRzIHVz ZQ0KPiA+Pj4+Pj4+Pj4+Pj4gZm9yIG90aGVyIHB1cnBvc2VzLCBwYXJ0aWN1bGFybHkgd2hlbiBp dCBpcyBpbmhlcmVudGx5IG5vdA0KPiA+Pj4+Pj4+Pj4+Pj4gc3VpdGVkIGZvcg0KPiA+PiB0aGVt Lg0KPiA+Pj4+Pj4+Pj4+Pj4+IFlvdXJzIElycmVzcGVjdGl2ZWx5LA0KPiA+Pj4+Pj4+Pj4+Pj4+ IEpvaG4NCj4gPj4+Pj4+Pj4+Pj4+PiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+ID4+Pj4+ Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4+Pj4+Pj4+IEZy b206IExzciA8bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBMZXMNCj4gPj4+Pj4+ Pj4+Pj4+Pj4gR2luc2JlcmcNCj4gPj4+Pj4+Pj4+Pj4+Pj4gKGdpbnNiZXJnKQ0KPiA+Pj4+Pj4+ Pj4+Pj4+PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNSwgMjAyMCAxMjozMyBQTQ0KPiA+Pj4+ Pj4+Pj4+Pj4+PiBUbzogQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz47IGxzckBp ZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4+Pj4+PiBDYzogbHNyLWNoYWlyc0BpZXRmLm9yZzsgbHNyLWFk c0BpZXRmLm9yZzsNCj4gPj4+Pj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgt IG9yaWdpbmF0b3JAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtMc3Jd IFdHIExhc3QgQ2FsbA0KPiA+Pj4+Pj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZp eC1vcmlnaW5hdG9yLTA2DQo+ID4+Pj4+Pj4+Pj4+Pj4+IFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1 dGlvdXMgb2YgY29udGVudF0gSSBzdXBwb3J0IG1vdmluZw0KPiA+Pj4+Pj4+Pj4+Pj4+PiB0aGlz IGRvY3VtZW50IGZvcndhcmQuDQo+ID4+Pj4+Pj4+Pj4+Pj4+IFNpbWlsYXIgZnVuY3Rpb25hbGl0 eSBpbiBJUy1JUyBoYXMgcHJvdmVkIHVzZWZ1bC4NCj4gPj4+Pj4+Pj4+Pj4+Pj4gSSB3b3VsZCBo b3dldmVyIGxpa2UgdG8gcmVwZWF0IGNvbW1lbnRzIEkgbWFkZSBlYXJsaWVyIGluDQo+ID4+Pj4+ Pj4+Pj4+Pj4+IHRoZSByZXZpZXcgb2YgdGhpcyBkb2N1bWVudC4NCj4gPj4+Pj4+Pj4+Pj4+Pj4g VGhlIGNvbnRlbnQgb2YgdGhlIEFwcGVuZGljZXMgc2hvdWxkIGJlIHJlbW92ZWQuDQo+ID4+Pj4+ Pj4+Pj4+Pj4+IFRoZSBBcHBlbmRpY2VzIGRlZmluZSBhbmQgZGlzY3VzcyBkZXJpdmluZyB0b3Bv bG9neQ0KPiA+Pj4+Pj4+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBmcm9tIHByZWZpeCBhZHZlcnRpc2Vt ZW50cyAtIHdoaWNoIGlzIGZsYXdlZA0KPiA+Pj4+Pj4+Pj4+Pj4+PiBhbmQgc2hvdWxkIG5vdCBi ZQ0KPiA+Pj4+Pj4+PiBkb25lLg0KPiA+Pj4+Pj4+Pj4+Pj4+PiBQZXJoYXBzIG1vcmUgcmVsZXZh bnQsIHRoZSBwdXJwb3NlIG9mIHRoZSBkb2N1bWVudCBpcyB0bw0KPiA+Pj4+Pj4+Pj4+Pj4+PiBk ZWZpbmUgcHJvdG9jb2wgZXh0ZW5zaW9ucyBzdXBwb3J0aW5nIGFkdmVydGlzZW1lbnQgb2YNCj4g Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIG9yaWdpbmF0b3JzIG9mIGEgcHJlZml4IGFkdmVydGlzZW1lbnQu IFRoZXJlIGlzIG5vDQo+ID4+Pj4+Pj4+Pj4+Pj4+IG5lZWQgdG8gZGlzY3VzcyBob3cgdGhpcyBt ZWNoYW5pc20gbWlnaHQgYmUgdXNlZCB0byBidWlsZA0KPiA+Pj4+Pj4+Pj4+Pj4+PiB0b3BvbG9n eQ0KPiA+Pj4+IGluZm9ybWF0aW9uLg0KPiA+Pj4+Pj4+Pj4+Pj4+PiBUaGlzIGRvY3VtZW50IHNo b3VsZCBjb25maW5lIGl0c2VsZiB0byBkZWZpbmluZyB0aGUNCj4gPj4+Pj4+Pj4+Pj4+Pj4gcHJv dG9jb2wgZXh0ZW5zaW9ucyAtIHNpbWlsYXIgdGhlIFJGQyA3Nzk0Lg0KPiA+Pj4+Pj4+Pj4+Pj4+ PiBJZiB0aGUgYXV0aG9ycyBkbyBub3QgYWdyZWUgdG8gZG8gdGhpcywgSSB3b3VsZCBlbmNvdXJh Z2UNCj4gPj4+Pj4+Pj4+Pj4+Pj4gdGhpcyBwb2ludCB0byBiZSBkaXNjdXNzZWQgZHVyaW5nIElF U0cgcmV2aWV3Lg0KPiA+Pj4+Pj4+Pj4+Pj4+PiBMZXMNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBMc3IgPGxzci1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuDQo+ID4+Pj4+Pj4+Pj4+Pj4+ PiBIb3Bwcw0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAy MDIwIDExOjE1IFBNDQo+ID4+Pj4+Pj4+Pj4+Pj4+PiBUbzogbHNyQGlldGYub3JnDQo+ID4+Pj4+ Pj4+Pj4+Pj4+PiBDYzogZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRm Lm9yZzsNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IGxzci1jaGFpcnNAaWV0Zi5vcmc7IGxzci0gYWRzQGll dGYub3JnOyBDaHJpc3RpYW4gSG9wcHMNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IDxjaG9wcHNAY2hvcHBz Lm9yZz4NCj4gPj4+Pj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFtMc3JdIFdHIExhc3QgQ2FsbA0KPiA+ Pj4+Pj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0K PiA+Pj4+Pj4+Pj4+Pj4+Pj4gVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTGFzdCBDYWxsLCBlbmRp bmcgYWZ0ZXIgT2N0DQo+ID4+Pj4+Pj4+Pj4+Pj4+PiAyOXRoLCAyMDIwLA0KPiA+Pj4+IGZvcjoN Cj4gPj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+Pj4+PiAvZA0KPiA+Pj4+Pj4+Pj4+Pj4+ Pj4gb2MNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IC9kDQo+ID4+Pj4+Pj4+Pj4+Pj4+PiByYQ0KPiA+Pj4+ Pj4+Pj4+Pj4+Pj4gZnQtaQ0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gZXQNCj4gPj4+Pj4+Pj4+Pj4+Pj4+ IGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3IvX187ISFORXQ2eU1hTy0NCj4gPj4+Pj4+Pj4+ Pj4+IGdrIVRhU3pRVGhnaHRDRk91WVBTMlZqTHENCj4gPj4+Pj4+Pj4+Pj4+Pj4+IGhLIDhwMDNG ZzNMOUx1Q0dYdzhDMFg2cVJRZHJIaktES0hjamtqQ2xwayQNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IFRo ZSBmb2xsb3dpbmcgSVBSIGhhcyBiZWVuIGZpbGVkDQo+ID4+Pj4+Pj4+Pg0KPiA+PiBodHRwczov L3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMzQ0 OC9fXzshDQo+ID4+Pj4+Pj4+Pj4+Pj4+PiAhTkV0NnlNYU8tDQo+ID4+Pj4+Pj4+Pg0KPiA+PiBn ayFUYVN6UVRoZ2h0Q0ZPdVlQUzJWakxxaEs4cDAzRmczTDlMdUNHWHc4QzBYNnFSUWRySGpLREtI Y3oNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IDVLdFVIUSQNCj4gPj4+Pj4+Pj4+Pj4+Pj4+IEF1dGhvcnMs DQo+ID4+Pj4+Pj4+Pj4+Pj4+PiBQbGVhc2UgaW5kaWNhdGUgdG8gdGhlIGxpc3QsIHlvdXIga25v d2xlZGdlIG9mIGFueSBvdGhlcg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gSVBSIHJlbGF0ZWQgdG8gdGhp cyB3b3JrLg0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPiA+Pj4+Pj4+Pj4+Pj4+Pj4gQ2hy aXMuDQo+ID4+Pj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4+Pj4+Pj4+Pj4+Pj4+IExzciBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+ Pj4+Pj4+Pj4gTHNyQGlldGYub3JnDQo+ID4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLw0KPiA+Pj4+Pj4+Pj4+Pj4+ PiBsaQ0KPiA+Pj4+Pj4+Pj4+Pj4+PiBzdA0KPiA+Pj4+Pj4+Pj4+Pj4+PiBpbg0KPiA+Pj4+Pj4+ Pj4+Pj4+PiBmbw0KPiA+Pj4+Pj4+Pj4+Pj4+PiAvbHNyDQo+ID4+Pj4+Pj4+Pj4+Pj4+IF9fOyEh TkV0DQo+ID4+Pj4+Pj4+Pj4+Pj4+IDZ5TWFPLQ0KPiA+Pj4+DQo+IGdrIVRhU3pRVGhnaHRDRk91 WVBTMlZqTHFoSzhwMDNGZzNMOUx1Q0dYdzhDMFg2cVJRZHJIaktES0hjVWRtDQo+ID4+Pj4+Pj4+ Pj4+PiB3OA0KPiA+Pj4+Pj4+Pj4+Pj4+PiBMYyQNCj4gPj4+Pj4+Pj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+Pj4+IExz ciBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4+PiBMc3JAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+ Pj4+PiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9sDQo+ID4+Pj4+Pj4+Pj4+Pj4gaXMNCj4gPj4+Pj4+Pj4+Pj4+PiB0aQ0KPiA+Pj4+Pj4+ Pj4+Pj4+IG5mby9sc3JfXzshIU5FdDZ5TWFPLQ0KPiA+Pj4+IGdrIVNWSHZxS3hvMmtSYUczcE5X a2RpS0dJYWU0NzIxVUtMV25mZm1sDQo+ID4+Pj4+Pj4+Pj4+Pj4gZTlUdm9BWndlNjRmbnpWdml6 TnVqbXExTSQNCj4gPj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+Pj4+PiBMc3IgbWFpbGluZyBsaXN0DQo+ID4+Pj4+ Pj4+Pj4+PiBMc3JAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5j b20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpDQo+ID4+Pj4+Pj4+Pj4+PiBz dA0KPiA+Pj4+Pj4+Pj4+Pj4gaW4NCj4gPj4+Pj4+Pj4+Pj4+IGZvL2xzcl9fOyEhTkV0NnlNYU8t DQo+ID4+Pj4gZ2shU1ZIdnFLeG8ya1JhRzNwTldrZGlLR0lhZTQ3MjFVS0xXbmZmbWxlOQ0KPiA+ Pj4+Pj4+Pj4+Pj4gVHZvQVp3ZTY0Zm56VnZpek51am1xMU0kDQo+ID4+Pj4+Pj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+Pj4+ IExzciBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4+Pj4gTHNyQGlldGYub3JnDQo+ID4+Pj4+Pj4+ Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpcw0KPiA+Pj4+Pj4+Pj4+PiB0aQ0KPiA+Pj4+Pj4+Pj4+PiBuZg0KPiA+Pj4+Pj4+Pj4+ PiBvL2xzcl9fOyEhTkV0NnlNYU8tDQo+ID4+Pj4gZ2shU1ZIdnFLeG8ya1JhRzNwTldrZGlLR0lh ZTQ3MjFVS0xXbmZmbWxlOVR2DQo+ID4+Pj4+Pj4+Pj4+IG9BWndlNjRmbnpWdml6TnVqbXExTSQN Cj4gPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+Pj4+Pj4+PiBMc3IgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+PiBMc3JAaWV0Zi5v cmcNCj4gPj4+Pj4+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpDQo+ID4+Pj4+Pj4+PiBuZg0KPiA+Pj4+Pj4+Pj4gby8NCj4g Pj4+Pj4+Pj4+IGxzcl9fOyEhTkV0NnlNYU8tDQo+ID4+Pj4gZ2shU1ZIdnFLeG8ya1JhRzNwTldr ZGlLR0lhZTQ3MjFVS0xXbmZmbWxlOVR2b0Fadw0KPiA+Pj4+Pj4+Pj4gZTY0Zm56VnZpek51am1x MU0kDQo+ID4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+Pj4+Pj4+IExzciBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+Pj4gTHNyQGlldGYu b3JnDQo+ID4+Pj4+Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3Rpbg0KPiA+Pj4+Pj4+PiBmbw0KPiA+Pj4+Pj4+PiAvbA0KPiA+ Pj4+Pj4+PiBzcl9fOyEhTkV0NnlNYU8tDQo+ID4+Pj4gZ2shU1ZIdnFLeG8ya1JhRzNwTldrZGlL R0lhZTQ3MjFVS0xXbmZmbWxlOVR2b0Fad2U2DQo+ID4+Pj4+Pj4+IDRmbnpWdml6TnVqbXExTSQN Cj4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4+Pj4+PiBMc3IgbWFpbGluZyBsaXN0DQo+ID4+Pj4+PiBMc3JAaWV0Zi5vcmcNCj4gPj4+ Pj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvDQo+ID4+Pj4+PiAvbA0KPiA+Pj4+Pj4gc3INCj4gPj4+Pj4+IF9fOyEhTkV0 NnlNYU8tDQo+ID4+Pj4gZ2shU1ZIdnFLeG8ya1JhRzNwTldrZGlLR0lhZTQ3MjFVS0xXbmZmbWxl OVR2b0Fad2U2NGZueg0KPiA+Pj4+Pj4gVnZpek51am1xMU0kDQo+ID4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gTHNyIG1haWxpbmcgbGlz dA0KPiA+Pj4gTHNyQGlldGYub3JnDQo+ID4+PiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9scw0KPiA+Pj4gcl8NCj4gPj4+ IF87ISFORXQ2eU1hTy0NCj4gPj4gZ2shUThpSFdqTURvS1lya3hFMnQwaHh2RnRiX3VRX2VIYkNq T25UY3JvUGZfSHoyWHo3aWp2LThUDQo+ID4+PiBWdG9qSHEtTEEkDQo= From nobody Mon Oct 19 09:52:34 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C213A0C93 for ; Mon, 19 Oct 2020 09:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=orange.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 tfftVdvko7DQ for ; Mon, 19 Oct 2020 09:52:31 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB063A0C8E for ; Mon, 19 Oct 2020 09:52:31 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4CFN8s5NHpz5xwH; Mon, 19 Oct 2020 18:52:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603126349; bh=bPIeHT0G2dIAF14KEqSfZJsTaZsfvhVgnRgqf5srgEI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=qTIh/DqJRRx3P3TOM5X8l7+LTuxzb1Yv+UlvZojJ7MIkGsAfDx3Tww0XKfJQroOI/ mHL/e8O1Pk+vsCO7ybrkFfZpX16H2W4WB3QqLQY5mW8R9MwlNtlPN6vlfAzgxpjZB5 lCLan+X661Gumnigdy6n9Jf8/odqr0xP1tkh7ZvxgkmEXPYWGPdYG+uCJCP3pek61/ /N1k0YK3aoJF8uAJY2mBwdCTRN1RpzPdo1VVWPk0G1RT1PiU3hbh3cfYgUNkRi0VDI aI27PQxH+6yJOGl06W5yo1v3a08RBF2/2PVQduEBvkqCHvrS/LBuCBr0vqq6UpgOoZ bz4Sy2jeW/BWA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.89]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4CFN8s4XbczCqkd; Mon, 19 Oct 2020 18:52:29 +0200 (CEST) From: To: Ron Bonica , "lsr@ietf.org" Thread-Topic: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWlmVwC6ypd3I8xkyHSNG022ojU6l/nmSwgB+h5QA= Date: Mon, 19 Oct 2020 16:52:29 +0000 Message-ID: <5770_1603126349_5F8DC44D_5770_187_4_53C29892C857584299CBF5D05346208A48FC0918@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <160138654056.12980.329207214151594381@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 16:52:33 -0000 Ron, all, >From a use case standpoint, I have a use case for having both SR-MPLS and I= P flexalgo in the same network. >From a protocol standpoint, I think that the functionality could be equally= met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implic= it null) to instruct the LER/LSR to not use a label in the forwarding plane= . (while still advertising a label in the control plane because we have to). I feel that this would be less change in the protocol (no new tlv), a good = fit for network requiring both MPLS and IP flex algo, and would not require= implementations/network operator to duplicate the "prefix sub-TLV" [1] on = both advertisements (IP based and SR-MPLS based). That would still requires a protocol extension/STD track RFC as RFC 8667 do= es not allow for this. That would still require change to implementations a= s only the signalling is different while the feature/behavior is the same (= i.e. no magic). Regards, --Bruno [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability= , MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)" > -----Original Message----- > From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica > Sent: Tuesday, September 29, 2020 3:38 PM > To: lsr@ietf.org > Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexa= lgo- > 00.txt >=20 >=20 > Please review and comment >=20 > Ron >=20 >=20 >=20 > Juniper Business Use Only >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org > > Sent: Tuesday, September 29, 2020 9:36 AM > > To: Parag Kaneriya ; Shraddha Hegde > > ; Ron Bonica ; Rajesh M > > ; William Britto A J > > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.t= xt > > > > [External Email. Be cautious of content] > > > > > > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Name: draft-bonica-lsr-ip-flexalgo > > Revision: 00 > > Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > > Document date: 2020-09-29 > > Group: Individual Submission > > Pages: 14 > > URL: https://urldefense.com/v3/__https://www.ietf.org/id/dra= ft- > bonica- > > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > > Status: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > bonica-lsr- > > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > > Htmlized: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- > > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > > Htmlized: > https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > > > > > > Abstract: > > An IGP Flexible Algorithm computes a constraint-based path and maps > > that path to an identifier. As currently defined, Flexalgo can only > > map the paths that it computes to Segment Routing (SR) identifiers. > > Therefore, Flexalgo cannot be deployed in the absence of SR. > > > > This document extends Flexalgo, so that it can map the paths that it > > computes to IP addresses. This allows Flexalgo to be deployed in any > > IP network, even in the absence of SR. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Oct 19 10:06:37 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1D53A0C9B; Mon, 19 Oct 2020 10:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[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 q1UJIUGAyyMm; Mon, 19 Oct 2020 10:06:34 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8553A0C8A; Mon, 19 Oct 2020 10:06:34 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8758F6166D; Mon, 19 Oct 2020 17:06:32 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1E3197A5-E342-4644-8598-1B3AACE3E926"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 19 Oct 2020 13:06:31 -0400 In-Reply-To: <3E930E88-9404-4874-888B-881D022DFFEC@tsinghua.org.cn> Cc: Christian Hopps , "Les Ginsberg (ginsberg)" , Jeff Tantsura , John E Drake , lsr-chairs@ietf.org, lsr@ietf.org, lsr-ads@ietf.org, draft-ietf-lsr-ospf-prefix-originator@ietf.org To: Aijun Wang References: <3E930E88-9404-4874-888B-881D022DFFEC@tsinghua.org.cn> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 17:06:36 -0000 --Apple-Mail=_1E3197A5-E342-4644-8598-1B3AACE3E926 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 16, 2020, at 4:47 AM, Aijun Wang = wrote: >=20 > Hi, Les and experts in LSR: >=20 > I am open to the removal of the this appendix to forward this draft. That's good news, thank you Aijun. Speaking for the chairs, We believe we have reached WG consensus (seems better than just rough = even with some authors asking for the change) at this point on the = removal of the disputed use-case appendices. Could you please republish the document w/o the disputed sections? Thanks, Chris. > But as stated in previous mail, providing this can assist the = user/reader of the draft. We often encounter the questions in the mail = list that what the usage of protocol/bit definition in some drafts. >=20 > Actually, we did not expand the discussion of this part in this draft. = The description of this part is very concise. >=20 > If you insist this, I can update the draft in recent days, together = with other comments on this draft. >=20 > Other comments are welcome also! >=20 > Aijun Wang > China Telecom >=20 >> On Oct 16, 2020, at 13:51, Les Ginsberg (ginsberg) = wrote: >>=20 >> =EF=BB=BFAijun - >>=20 >> The point I am making is very focused. >>=20 >> This draft is defining a protocol extension. As such it is necessary = that this be Standards track as adhering to the normative statements in = the draft are necessary for interoperability. >>=20 >> What is discussed in the Appendix is a use case. It is not normative = and there are strong opinions on both sides as to whether this is an = appropriate use case or not. >> In the context of this draft, I have no interest in trying to resolve = our difference of opinion on this use case. I simply want the protocol = extension to move forward so that we have another tool available. >>=20 >> If you want to write a draft on the use case discussed in the = Appendix please feel free to do so. That draft may very well not be = normative - Informational or BCP may be more appropriate - because it = will be discussing a deployment scenario and a proposal to use defined = protocol extensions as one way to solve problems in that deployment = scenario. Such a draft might also be more appropriate in another WG = (e.g., TEAS). The merits of using prefix advertisements to build a = topology could then be discussed on its own. >>=20 >> Please do not try to avoid having a full discussion of the merits of = using prefix advertisements to derive topology by adding it to a draft = that is (and should be) focused on simple protocol extensions. >>=20 >> Thanx. >>=20 >> Les >>=20 >>=20 >>> -----Original Message----- >>> From: Aijun Wang >>> Sent: Thursday, October 15, 2020 6:51 PM >>> To: 'Jeff Tantsura' ; 'John E Drake' >>> >>> Cc: 'Christian Hopps' ; lsr-chairs@ietf.org; Les = Ginsberg >>> (ginsberg) ; lsr@ietf.org; lsr-ads@ietf.org; = draft-ietf- >>> lsr-ospf-prefix-originator@ietf.org >>> Subject: RE: [Lsr] WG Last Call = draft-ietf-lsr-ospf-prefix-originator-06 >>>=20 >>> Hi, Les, John and Jeff: >>>=20 >>> Let's reply you all together. >>> In my POV, The standard document should not define solely the = protocol >>> extension, but their usages in the network deployment. As I known, = almost >>> all the IETF documents following this style. >>> And, before adopting one work, we have often intense discussion for = what's >>> their usages. >>> Such discussion in the mail list and statements in the doc >=20 --Apple-Mail=_1E3197A5-E342-4644-8598-1B3AACE3E926 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl+Nx5cACgkQLh2DDte4 MCUtwxAAmgmSdNWu0BlXZtjzzEdjSarHd+ltc4pQy3b8E+ne6/GNM9fLogGBOjfj Hwd969B2D1kFjBVvo6cqDWYVn0YxakSFRqGG4um8TTU4fqU1cUkO3IJB5x5KcmyX sB4UCb5OG++KJ5v/WNa7gbBm3SCypikKm+4857E3BSBZ+Ook2s1iTZ9OYJQh6529 ddsgA3LvZfLnI+Dx0t1pfx8QGViQ/fYO/Z1z7HhBSsoo0IxSy2jAF/PpIvGXUKE+ FvpuwGYjZk52Zow4X8fchINZ5NkLTU4GajKHoDPrtOLcs471csgXR5t+6kotEViw EHZHB6jBGfpMbfB1YU5bemk+u7hfcKZXZhtGknxddn8mQs/dGbjHJknzMjQhBsBE ZCyFUgXDeqVMiITzcx9l1BFgFxZESmuSLAUrE2HTmLxDIK6MgZ9WjaRz1FYAnmAH DMmjxqlCcwtHqeJayeUOIEUq9sSsf7oN9VomACeqlhyuhteDh8N9UNrteIu6Dgnp 92dTdSjtLbW6CB8gvleQqpt2xzwiyYutTXHRL2eHJWdSuLasLHeLwIYDRq75GzbX 5HvjgQnGeYLV8kJVSBZcxbjzHbJXewZJLY/7NDKT9TK5qcrcRLLFH1LTjFvzNtbG 7TLATEDjqZEEr9Zwn3wiSzswa820PoWyznOCPmNQ+rrOcqmoBbY= =rz4k -----END PGP SIGNATURE----- --Apple-Mail=_1E3197A5-E342-4644-8598-1B3AACE3E926-- From nobody Mon Oct 19 10:19:19 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADBE3A0E60; Mon, 19 Oct 2020 10:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ao5akru7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=u+JUEV2R 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 apasZf5WWJIl; Mon, 19 Oct 2020 10:19:16 -0700 (PDT) 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 B85173A0E1C; Mon, 19 Oct 2020 10:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5572; q=dns/txt; s=iport; t=1603127955; x=1604337555; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JaCPkWBnkp7pwFgApzQPqch1Emc201mxLuLtGsyecaw=; b=ao5akru7td5eyD4swhL5EmualzjX03uvGxNm24I4hDv1rD/YVqhcgThh zWy5H4KfkxnfbbpokD3M9tfROCuqtDnnqi+08HxThLpRknKJWC2qS2EyS jQWZL0nF+rmQ290hwBQ1tXyr35/KICZozIs4bCCUgc34Zpt1uyxSeYW7b 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AZnM0bBc2IxDer8Tf9FY1Q9Z/lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQA9fQ6/Vck/GQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFbSpWWq9ngVAB?= =?us-ascii?q?qsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTCACTyY1f/51dJa1gHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFPgVJRB3BZLywKhDODSQONTYoQjmqCUwNVCwEBAQ0BASMKAgQBAYR?= =?us-ascii?q?KAheBdgIlOBMCAwEBCwEBBQEBAQIBBgRthWEMhXIBAQEDARIREQwBASkOAQs?= =?us-ascii?q?EAgEIDgMEAQEBAgImAgICHxEVCAgCBAENBRoIgwQBgksDDiABDqQjAoE5iGh?= =?us-ascii?q?2gTKDBAEBBYUlDQuCEAMGgQ4qgnKDboEGhVAbggCBESccgk0+ghpCAQECAYE?= =?us-ascii?q?6AQEggxczgiyQCgSDBgE9o1hUCoJqiQSMYoIhgmoDH4MWigmUMZMxgXuIeIJ?= =?us-ascii?q?skk4CBAIEBQIOAQEFgWsjgVdwFTsqAYI+UBcCDY4fDBeDToUUhUJ0AjYCBgE?= =?us-ascii?q?JAQEDCXyMOwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,395,1596499200"; d="scan'208";a="566414975" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Oct 2020 17:19:14 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 09JHJDuV000439 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2020 17:19:14 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 19 Oct 2020 12:19:13 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 19 Oct 2020 13:19:12 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 19 Oct 2020 12:19:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fr/ZcWDh21T3wdFZtqtfSwQj32++AwkteT+8lkPXgBQ31v15Loe2nl1TcFyElU3JZI3isLRE950S6T/fDFqeJAG2mMbIoxZgOFI/QURtuPLavROK9KF218cg28G2GtLqWbrw1z3X0/L+TmDO05XtunyjjgLkJknE0DUOn2iuc5wW8VQxo6HaL18pUrzIkD3EussrPSV9jZl3w0K5xn4wkCZxDxb29fOrWVxW1uzTuYz2XacFd/VEzKijKictskK0ErMKfvHXALPU/OgdwGQuuBQA45fXQzTMwesrK1/KUwt5pecC+YfTuE0nE7xgyA3YdGdPwkgIpissRdacezik5w== 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=JaCPkWBnkp7pwFgApzQPqch1Emc201mxLuLtGsyecaw=; b=l7lUIR95LRqRVEMnUWYEEStS8p25Mof/VXHwAb4j6lxD02aaSOSUNVNWZxuPq682sPQN8WPIHfInJVQJJpAysyGY+NERnbe4L+a9zy9WBjFTgJ9YqNNL/EUClpcCVBSp/oBtWc/LpLhEikzDCRvITDf/K6WXR6Ts0W8VQLIgkCppzYDHFfLLerloDAVl9Si2ts8S0xE0RdyVg6+mKdKy0KJbIIDpbAf8iCuIhWqesRz7TR15mSZlDBSPhDJkYGfa9eNxruNFRybGbqyb8nseBC3O4tpv/5oD8ykgb+Wqcy/mAs2dBziYplootRGq58/70xNbg7dosjzSSbD9olbeSw== 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=JaCPkWBnkp7pwFgApzQPqch1Emc201mxLuLtGsyecaw=; b=u+JUEV2RG8jqIsM97r3TginQXaxJs0I2bpm9UdnqfAIKBwDlqzPk4xVCw0MPSeZxZ2dc82HflVGnbwabh8Q1lHOS34IItqW0W2NZZRb50WvjNPSag8g+cJ4+WbN27KcVQPambzwePXMLdfqy66MTfu4TMdCRdB71gzzHvMG1y1Y= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3015.namprd11.prod.outlook.com (2603:10b6:a03:86::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.27; Mon, 19 Oct 2020 17:19:09 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 17:19:09 +0000 From: "Acee Lindem (acee)" To: Christian Hopps , Aijun Wang CC: "Les Ginsberg (ginsberg)" , Jeff Tantsura , John E Drake , "lsr-chairs@ietf.org" , "lsr@ietf.org" , "lsr-ads@ietf.org" , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorqiw9pv6soWMUKVhaUBbeDrx6mY3FwAgAAhZgCAADD9AIAASXsAgABDC4CAADFWAIAFQlGA///AdgA= Date: Mon, 19 Oct 2020 17:19:09 +0000 Message-ID: <839EE561-9CC4-4D65-935F-0312A6D6C4E7@cisco.com> References: <3E930E88-9404-4874-888B-881D022DFFEC@tsinghua.org.cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c765906f-2fda-497e-b810-08d874531761 x-ms-traffictypediagnostic: BYAPR11MB3015: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4mLACaFfLHwylbHDOd1VCc0Lsh1dt5y5+CqgEeQKYqCjJYoue2MK7J+gYQ2gqpDtiAOlSMl5oWkyzGx2lFd7GP3+DpLoxem5i2Uj9DzY9UegeCJ3c4WukscGel5U+J7NLunXYL6W3B9K2lSn3HoWMbbJFz25PlVlMMa9pgZQOcns9/K/7yaLRMobWz6uaGF9t+l/RO4chSPVx6kWoyKiOhW6/N0dHMluZ75WzmDh7UuqqHRCbslxnkKg/CMdCHYDBoinHJC9RQIicu9dtmJynAEsTA4RQArZFHuWHOs1epTleRaguZV9+Fjkcz70cFzp0viBFTUiFFT81duwAVftInIjnRJSC8ioQCy9cGAZtBOn18tnGNwGDumrU1e2Of5YvwMYyqJOhxuM1ayTTuy92Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(376002)(136003)(396003)(366004)(186003)(316002)(8676002)(36756003)(53546011)(86362001)(966005)(66946007)(6506007)(66476007)(4326008)(76116006)(66556008)(83380400001)(26005)(2906002)(64756008)(66446008)(5660300002)(110136005)(2616005)(33656002)(478600001)(54906003)(6486002)(6512007)(71200400001)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: srCdSoVCl4r05xQjzphBqWqjr2DTOE4zZkx8qv1VIpov0x4EYL010FN+IXzRFWW3qrUOb5hKAbbGnwcW+u1DbHws0s6WZgLa2ACvagq5VU195IkiV85XhKxVEA/of//yA8Nr5QA7DzNDVm5HQGkNLl56We11aBNqVJlyqKIxm6pWghgakTxZTRmLczIS8tZoujCR7Ceql679ntqz2/+xhGw+q2Xy/B+hNZgTrpN2g/+gqC/bRFC1931c6B5H0s949iEw6Yc+niemR4wqYHbfugQ/flWRsHQnOaReqGdhXkFKatpBXkS+wx5SsT8Q6vRGPdeIdr8Avqv5ViutEWz9ccASwdQ1N+fqv2YcvFykxf9DiJ8zOBVN1hVdFPCElY/HgA/TD1Plw8E9DgLfuc3anThW0NKOOEqOQfasLbI9i8Op1T5zGAIWaL/Ji1kVA0PlKxTN+cwWrBOupwX9GOpkhuLonZ0bapDGJ8j3Z2HvrziRuQI98+nbyVGOHWTxq/nkOIUTUm1vtMD7ojtu3rN4kr7LQiVgwwXEFAZKGV63BSTpHaS2taCskUHtFYlwioVZlIQ8vLvp3l8A93z3CbaDqNw6oCMOa88pwuRINnkB8Evcn57kMwaBILp1Vb9qZyfveYZwNf2IHdAV6mCj9q7hWg== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c765906f-2fda-497e-b810-08d874531761 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 17:19:09.4973 (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: gt66IzmAUjqT7HIqcqQcfaKTgMXxqjF3RAmnaOXOuZcQw84ANLPOzkks9z0Kod/g X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3015 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 17:19:18 -0000 U3BlYWtpbmcgYXMgV0cgY2hhaXI6IA0KDQrvu79PbiAxMC8xOS8yMCwgMTowNiBQTSwgIkNocmlz dGlhbiBIb3BwcyIgPGNob3Bwc0BjaG9wcHMub3JnPiB3cm90ZToNCg0KDQoNCiAgICA+IE9uIE9j dCAxNiwgMjAyMCwgYXQgNDo0NyBBTSwgQWlqdW4gV2FuZyA8d2FuZ2FpanVuQHRzaW5naHVhLm9y Zy5jbj4gd3JvdGU6DQogICAgPiANCiAgICA+IEhpLCBMZXMgYW5kIGV4cGVydHMgaW4gTFNSOg0K ICAgID4gDQogICAgPiBJIGFtIG9wZW4gdG8gdGhlIHJlbW92YWwgb2YgdGhlIHRoaXMgYXBwZW5k aXggdG8gZm9yd2FyZCB0aGlzIGRyYWZ0Lg0KDQogICAgVGhhdCdzIGdvb2QgbmV3cywgdGhhbmsg eW91IEFpanVuLg0KDQogICAgU3BlYWtpbmcgZm9yIHRoZSBjaGFpcnMsDQoNCiAgICBXZSBiZWxp ZXZlIHdlIGhhdmUgcmVhY2hlZCBXRyBjb25zZW5zdXMgKHNlZW1zIGJldHRlciB0aGFuIGp1c3Qg cm91Z2ggZXZlbiB3aXRoIHNvbWUgYXV0aG9ycyBhc2tpbmcgZm9yIHRoZSBjaGFuZ2UpIGF0IHRo aXMgcG9pbnQgb24gdGhlIHJlbW92YWwgb2YgdGhlIGRpc3B1dGVkIHVzZS1jYXNlIGFwcGVuZGlj ZXMuDQoNCiAgICBDb3VsZCB5b3UgcGxlYXNlIHJlcHVibGlzaCB0aGUgZG9jdW1lbnQgdy9vIHRo ZSBkaXNwdXRlZCBzZWN0aW9ucz8NCg0KICAgIFRoYW5rcywNCiAgICBDaHJpcy4NCg0KSSdsbCBh ZGQgdGhhdCBSRkMgNzIyMSwgc2VjdGlvbiAxLjIgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzcyMjEjc2VjdGlvbi0xLjIgIGluY2x1ZGVzIGEgdmVyeSBnb29kIGRlc2NyaXB0aW9uIG9m IHRoZSBJRVRGIHByb2Nlc3MgZm9yIFdHIGRvY3VtZW50IG93bmVyc2hpcCBhbmQgY29uc2Vuc3Vz LiANCg0KVGhhbmtzLA0KQWNlZQ0KDQogICAgPiBCdXQgYXMgc3RhdGVkIGluIHByZXZpb3VzIG1h aWwsIHByb3ZpZGluZyB0aGlzIGNhbiBhc3Npc3QgdGhlIHVzZXIvcmVhZGVyIG9mIHRoZSBkcmFm dC4gV2Ugb2Z0ZW4gZW5jb3VudGVyIHRoZSBxdWVzdGlvbnMgaW4gdGhlIG1haWwgbGlzdCB0aGF0 IHdoYXQgdGhlIHVzYWdlIG9mIHByb3RvY29sL2JpdCBkZWZpbml0aW9uIGluIHNvbWUgZHJhZnRz Lg0KICAgID4gDQogICAgPiBBY3R1YWxseSwgd2UgZGlkIG5vdCBleHBhbmQgdGhlIGRpc2N1c3Np b24gb2YgdGhpcyBwYXJ0IGluIHRoaXMgZHJhZnQuIFRoZSBkZXNjcmlwdGlvbiBvZiB0aGlzIHBh cnQgaXMgdmVyeSBjb25jaXNlLg0KICAgID4gDQogICAgPiBJZiB5b3UgaW5zaXN0IHRoaXMsIEkg Y2FuIHVwZGF0ZSB0aGUgZHJhZnQgaW4gcmVjZW50IGRheXMsIHRvZ2V0aGVyIHdpdGggb3RoZXIg Y29tbWVudHMgb24gdGhpcyBkcmFmdC4NCiAgICA+IA0KICAgID4gT3RoZXIgY29tbWVudHMgYXJl IHdlbGNvbWUgYWxzbyENCiAgICA+IA0KICAgID4gQWlqdW4gV2FuZw0KICAgID4gQ2hpbmEgVGVs ZWNvbQ0KICAgID4gDQogICAgPj4gT24gT2N0IDE2LCAyMDIwLCBhdCAxMzo1MSwgTGVzIEdpbnNi ZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbT4gd3JvdGU6DQogICAgPj4gDQogICAg Pj4g77u/QWlqdW4gLQ0KICAgID4+IA0KICAgID4+IFRoZSBwb2ludCBJIGFtIG1ha2luZyBpcyB2 ZXJ5IGZvY3VzZWQuDQogICAgPj4gDQogICAgPj4gVGhpcyBkcmFmdCBpcyBkZWZpbmluZyBhIHBy b3RvY29sIGV4dGVuc2lvbi4gQXMgc3VjaCBpdCBpcyBuZWNlc3NhcnkgdGhhdCB0aGlzIGJlIFN0 YW5kYXJkcyB0cmFjayBhcyBhZGhlcmluZyB0byB0aGUgbm9ybWF0aXZlIHN0YXRlbWVudHMgaW4g dGhlIGRyYWZ0IGFyZSBuZWNlc3NhcnkgZm9yIGludGVyb3BlcmFiaWxpdHkuDQogICAgPj4gDQog ICAgPj4gV2hhdCBpcyBkaXNjdXNzZWQgaW4gdGhlIEFwcGVuZGl4IGlzIGEgdXNlIGNhc2UuIEl0 IGlzIG5vdCBub3JtYXRpdmUgYW5kIHRoZXJlIGFyZSBzdHJvbmcgb3BpbmlvbnMgb24gYm90aCBz aWRlcyBhcyB0byB3aGV0aGVyIHRoaXMgaXMgYW4gYXBwcm9wcmlhdGUgdXNlIGNhc2Ugb3Igbm90 Lg0KICAgID4+IEluIHRoZSBjb250ZXh0IG9mIHRoaXMgZHJhZnQsIEkgaGF2ZSBubyBpbnRlcmVz dCBpbiB0cnlpbmcgdG8gcmVzb2x2ZSBvdXIgZGlmZmVyZW5jZSBvZiBvcGluaW9uIG9uIHRoaXMg dXNlIGNhc2UuIEkgc2ltcGx5IHdhbnQgdGhlIHByb3RvY29sIGV4dGVuc2lvbiB0byBtb3ZlIGZv cndhcmQgc28gdGhhdCB3ZSBoYXZlIGFub3RoZXIgdG9vbCBhdmFpbGFibGUuDQogICAgPj4gDQog ICAgPj4gSWYgeW91IHdhbnQgdG8gd3JpdGUgYSBkcmFmdCBvbiB0aGUgdXNlIGNhc2UgZGlzY3Vz c2VkIGluIHRoZSBBcHBlbmRpeCBwbGVhc2UgZmVlbCBmcmVlIHRvIGRvIHNvLiBUaGF0IGRyYWZ0 IG1heSB2ZXJ5IHdlbGwgbm90IGJlIG5vcm1hdGl2ZSAtIEluZm9ybWF0aW9uYWwgb3IgQkNQIG1h eSBiZSBtb3JlIGFwcHJvcHJpYXRlIC0gYmVjYXVzZSBpdCB3aWxsIGJlIGRpc2N1c3NpbmcgYSBk ZXBsb3ltZW50IHNjZW5hcmlvIGFuZCBhIHByb3Bvc2FsIHRvIHVzZSBkZWZpbmVkIHByb3RvY29s IGV4dGVuc2lvbnMgYXMgb25lIHdheSB0byBzb2x2ZSBwcm9ibGVtcyBpbiB0aGF0IGRlcGxveW1l bnQgc2NlbmFyaW8uIFN1Y2ggYSBkcmFmdCBtaWdodCBhbHNvIGJlIG1vcmUgYXBwcm9wcmlhdGUg aW4gYW5vdGhlciBXRyAoZS5nLiwgVEVBUykuIFRoZSBtZXJpdHMgb2YgdXNpbmcgcHJlZml4IGFk dmVydGlzZW1lbnRzIHRvIGJ1aWxkIGEgdG9wb2xvZ3kgY291bGQgdGhlbiBiZSBkaXNjdXNzZWQg b24gaXRzIG93bi4NCiAgICA+PiANCiAgICA+PiBQbGVhc2UgZG8gbm90IHRyeSB0byBhdm9pZCBo YXZpbmcgYSBmdWxsIGRpc2N1c3Npb24gb2YgdGhlIG1lcml0cyBvZiB1c2luZyBwcmVmaXggYWR2 ZXJ0aXNlbWVudHMgdG8gZGVyaXZlIHRvcG9sb2d5IGJ5IGFkZGluZyBpdCB0byBhIGRyYWZ0IHRo YXQgaXMgKGFuZCBzaG91bGQgYmUpIGZvY3VzZWQgb24gc2ltcGxlIHByb3RvY29sIGV4dGVuc2lv bnMuDQogICAgPj4gDQogICAgPj4gVGhhbnguDQogICAgPj4gDQogICAgPj4gIExlcw0KICAgID4+ IA0KICAgID4+IA0KICAgID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4+PiBG cm9tOiBBaWp1biBXYW5nIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNuPg0KICAgID4+PiBTZW50 OiBUaHVyc2RheSwgT2N0b2JlciAxNSwgMjAyMCA2OjUxIFBNDQogICAgPj4+IFRvOiAnSmVmZiBU YW50c3VyYScgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsgJ0pvaG4gRSBEcmFrZScNCiAgICA+ Pj4gPGpkcmFrZUBqdW5pcGVyLm5ldD4NCiAgICA+Pj4gQ2M6ICdDaHJpc3RpYW4gSG9wcHMnIDxj aG9wcHNAY2hvcHBzLm9yZz47IGxzci1jaGFpcnNAaWV0Zi5vcmc7IExlcyBHaW5zYmVyZw0KICAg ID4+PiAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb20+OyBsc3JAaWV0Zi5vcmc7IGxzci1h ZHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtDQogICAgPj4+IGxzci1vc3BmLXByZWZpeC1vcmlnaW5h dG9yQGlldGYub3JnDQogICAgPj4+IFN1YmplY3Q6IFJFOiBbTHNyXSBXRyBMYXN0IENhbGwgZHJh ZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci0wNg0KICAgID4+PiANCiAgICA+Pj4g SGksIExlcywgSm9obiBhbmQgSmVmZjoNCiAgICA+Pj4gDQogICAgPj4+IExldCdzIHJlcGx5IHlv dSBhbGwgdG9nZXRoZXIuDQogICAgPj4+IEluIG15IFBPViwgVGhlIHN0YW5kYXJkIGRvY3VtZW50 IHNob3VsZCBub3QgZGVmaW5lIHNvbGVseSB0aGUgcHJvdG9jb2wNCiAgICA+Pj4gZXh0ZW5zaW9u LCBidXQgdGhlaXIgdXNhZ2VzIGluIHRoZSBuZXR3b3JrIGRlcGxveW1lbnQuIEFzIEkga25vd24s IGFsbW9zdA0KICAgID4+PiBhbGwgdGhlIElFVEYgZG9jdW1lbnRzIGZvbGxvd2luZyB0aGlzIHN0 eWxlLg0KICAgID4+PiBBbmQsIGJlZm9yZSBhZG9wdGluZyBvbmUgd29yaywgd2UgaGF2ZSBvZnRl biBpbnRlbnNlIGRpc2N1c3Npb24gZm9yIHdoYXQncw0KICAgID4+PiB0aGVpciB1c2FnZXMuDQog ICAgPj4+IFN1Y2ggZGlzY3Vzc2lvbiBpbiB0aGUgbWFpbCBsaXN0IGFuZCBzdGF0ZW1lbnRzIGlu IHRoZSBkb2MNCiAgICA+IA0KDQoNCg== From nobody Mon Oct 19 10:55:23 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EDC3A0A22 for ; Mon, 19 Oct 2020 10:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.948 X-Spam-Level: X-Spam-Status: No, score=-7.948 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy9uf26vrskr for ; Mon, 19 Oct 2020 10:55:19 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1063A0EA9 for ; Mon, 19 Oct 2020 10:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5770; q=dns/txt; s=iport; t=1603130119; x=1604339719; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=XLp7DOCuW/O6gkqQsE1PVq3ssXXOK0XR7K5N1dicPHE=; b=fGktmdMSN0jfTIl/b+if0t9+DPjZMXLGmvgoxvSFUe6soLK/13b2RZ3P XvATOaQoN1FH4nChosyQQBy9la17KBOwOpWP5Z0WRjZojNu9im3LfEwe5 CgDYx5y5xvcuLR743Kfpsz8BmcCgBY5aTKjVIoXtSt47iXrcUdTkD4xan 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFAABf0o1f/xbLJq1gGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFPgxpVASASLIQ9iQWHZQgmmjyBaQsBAQE?= =?us-ascii?q?PGAsMBAEBhEoCgg4mOBMCAwEBCwEBBQEBAQIBBgRthWEMhXIBAQEDAQEBIRU?= =?us-ascii?q?2CQcHBAsRBAEBAQICIwMCAicfCQgGAQwGAgEBgyIBglwgD65HdoEyhFJBRIN?= =?us-ascii?q?MgUKBDiqNUYFBP4ERJwyCXT6CXAEBAgEBgSYBEgFNgmuCXwSQDop1gRmbXoJ?= =?us-ascii?q?0gxaFbpFhBQcDH4MWgSqIX4UejGGCMpMxinOVYoFrI2dwMxoIGxUaIYJpCUc?= =?us-ascii?q?ZDY4rF4NOhRSFRD8DMAI2AgYKAQEDCY5IAQE?= X-IronPort-AV: E=Sophos;i="5.77,395,1596499200"; d="scan'208";a="30472081" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Oct 2020 17:55:14 +0000 Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 09JHtEub026520; Mon, 19 Oct 2020 17:55:14 GMT To: bruno.decraene@orange.com, Ron Bonica , "lsr@ietf.org" References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <5770_1603126349_5F8DC44D_5770_187_4_53C29892C857584299CBF5D05346208A48FC0918@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: Peter Psenak Message-ID: <0f958743-3709-83cc-6e7f-8bb5d5746bc5@cisco.com> Date: Mon, 19 Oct 2020 19:55:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5770_1603126349_5F8DC44D_5770_187_4_53C29892C857584299CBF5D05346208A48FC0918@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 17:55:22 -0000 Bruno, On 19/10/2020 18:52, bruno.decraene@orange.com wrote: > Ron, all, > >>From a use case standpoint, I have a use case for having both SR-MPLS and IP flexalgo in the same network. > >>From a protocol standpoint, I think that the functionality could be equally met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit null) to instruct the LER/LSR to not use a label in the forwarding plane. (while still advertising a label in the control plane because we have to). does not work, as it does not allow you to associate the prefix with Flex-algo without advertising the reachability in algo 0. Making the prefix reachability in default algo conditional based on the presence of the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack. Not to mention that advertising a Prefix SID in pure IP network would be ugly. thanks, Peter > I feel that this would be less change in the protocol (no new tlv), a good fit for network requiring both MPLS and IP flex algo, and would not require implementations/network operator to duplicate the "prefix sub-TLV" [1] on both advertisements (IP based and SR-MPLS based). > > That would still requires a protocol extension/STD track RFC as RFC 8667 does not allow for this. That would still require change to implementations as only the signalling is different while the feature/behavior is the same (i.e. no magic). > > Regards, > --Bruno > > [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)" > > >> -----Original Message----- >> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >> Sent: Tuesday, September 29, 2020 3:38 PM >> To: lsr@ietf.org >> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo- >> 00.txt >> >> >> Please review and comment >> >> Ron >> >> >> >> Juniper Business Use Only >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org >>> Sent: Tuesday, September 29, 2020 9:36 AM >>> To: Parag Kaneriya ; Shraddha Hegde >>> ; Ron Bonica ; Rajesh M >>> ; William Britto A J >>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt >>> >>> [External Email. Be cautious of content] >>> >>> >>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt >>> has been successfully submitted by Ron Bonica and posted to the IETF >>> repository. >>> >>> Name: draft-bonica-lsr-ip-flexalgo >>> Revision: 00 >>> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks >>> Document date: 2020-09-29 >>> Group: Individual Submission >>> Pages: 14 >>> URL: https://urldefense.com/v3/__https://www.ietf.org/id/draft- >> bonica- >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ >>> Status: >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- >> bonica-lsr- >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ >>> Htmlized: >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- >>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ >>> Htmlized: >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft- >>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ >>> >>> >>> Abstract: >>> An IGP Flexible Algorithm computes a constraint-based path and maps >>> that path to an identifier. As currently defined, Flexalgo can only >>> map the paths that it computes to Segment Routing (SR) identifiers. >>> Therefore, Flexalgo cannot be deployed in the absence of SR. >>> >>> This document extends Flexalgo, so that it can map the paths that it >>> computes to IP addresses. This allows Flexalgo to be deployed in any >>> IP network, even in the absence of SR. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > From nobody Mon Oct 19 11:54:17 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FD23A0FD5; Mon, 19 Oct 2020 11:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 PH3s2yizvJqY; Mon, 19 Oct 2020 11:54:09 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 D6F8E3A1007; Mon, 19 Oct 2020 11:54:08 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id 33so356564edq.13; Mon, 19 Oct 2020 11:54:08 -0700 (PDT) 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=vyU36MMpbUOMK9kwgPZyerhYX7veo+NN7+iTWR8MKUw=; b=FNzBGE/Mu5F8fWe9QXBjMLuQwh05c/a9e6BMsHhJQwSRqh/ksLOhpt0GU3LSatLWoW BYIYvpV2ObRBOSirKfyhR/2Pmm6nbETOet/YrkIU1frrWR5HDTcxSI/XYY6E9swOgE78 jPu2GZtxzM6OtMg88TFOpQDJiHggnmrsG9a9O05Dyo/s8mTA3IL73qSONw1Abr1mnefp g62GfSlxKsGEDo2aOBuj3Z6CX7dKR7WdUKS9MHh97BOIiXDERnHtb0o1OwBRLEyOSiDJ M7xttIk4euLJyROJTHuZl6MDhABMSUeFIS7iRJHy/ROe6oe1FGVpGkPZHqEdQ8uqxK+0 KBXA== 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=vyU36MMpbUOMK9kwgPZyerhYX7veo+NN7+iTWR8MKUw=; b=qCspPdrkk95sVjuRJVjlF1UbB1OR1hTT2Q2iXu4jVs8RLkROt6rhS6zRPcC5vXsn4V g0RA4OyD7sPMbG4U/c3xZBwxVFnPNc7583dEz3lsge1ptQ1VbVr8RbWozxmAvnh5ghsX DKqklowmbMgSDaseIsHc8dMcaW9ScNeqE5XG0/p/UIbhEhHcqolDlWE7fxyIDO/6Zm08 vXjf5SS2grIl5+dNVxZJwhXEtqk59+VfkxaiK1XIAM4s7toK0ElntMFPOoLa71G5RaXu 9U3bUMsSAQALlzku5Gv0EVbMzVqWu+5o00qx9pazPofXsAgtg2Pjd6x5V3Xn6e6QfuXR M8Sw== X-Gm-Message-State: AOAM533GCueJDHmDMaDn57DnNIBAqACShh7jQflWMEEXM3bJWpUqRDw7 doHXnr4WVwpaTrpNL/vtoeM2CGbBna5fMDYub40= X-Google-Smtp-Source: ABdhPJwWi/apHELCbmIY658A7pbLWpxWulkx9lw9F2w1mQWnG2WDXwlLytB/+R56qFkKaTyl8JlVUVjiFjLjmseI8KI= X-Received: by 2002:a05:6402:359:: with SMTP id r25mr1291113edw.308.1603133647385; Mon, 19 Oct 2020 11:54:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: gjshep@gmail.com From: Greg Shepherd Date: Mon, 19 Oct 2020 11:53:56 -0700 Message-ID: To: Greg Mirsky , lsr@ietf.org Cc: BIER WG , BIER WG Chairs , Alvaro Retana , draft-ietf-bier-bar-ipa@ietf.org Content-Type: multipart/alternative; boundary="0000000000009478c705b20aa3b9" Archived-At: Subject: [Lsr] IS: draft-ietf-bier-bar-ipa review / WAS: Re: The Document Shepherd Write-Uo X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 18:54:16 -0000 --0000000000009478c705b20aa3b9 Content-Type: text/plain; charset="UTF-8" LSR-WG The following draft has completed WGLC in BIER and the Shepherd doc is published. Can you please review before we move to the queue? https://datatracker.ietf.org/doc/draft-ietf-bier-bar-ipa/ Thanks, The BIER WG (Shep/Chairs) On Thu, Sep 24, 2020 at 2:24 PM Greg Mirsky wrote: > Dear All, > the first version of the Document Shepherd's Write-Up is ready for your > review. Please let me know if you have any questions or comments. > > Regards, > Greg > --0000000000009478c705b20aa3b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LSR-WG

The following d= raft has completed WGLC in BIER and the Shepherd doc is published. Can you = please review before we move to the queue?


<= div>Thanks,
The BIER WG
(Shep/Chairs)

On Thu, Sep = 24, 2020 at 2:24 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
the first version of = the Document Shepherd's Write-Up is ready for your review. Please let m= e know if you have any questions or=C2=A0comments.

Regards,
Greg
--0000000000009478c705b20aa3b9-- From nobody Mon Oct 19 13:51:45 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1AC3A09C9; Mon, 19 Oct 2020 13:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 sfuQ_kvWWdH4; Mon, 19 Oct 2020 13:51:42 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 741803A09C3; Mon, 19 Oct 2020 13:51:42 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id w17so1749347ilg.8; Mon, 19 Oct 2020 13:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iNlyjxdrsXVmxfGz+9EedW1Cf1GmKW3UFcGteR/MNOM=; b=KAcxfOd18/8oIzS8WiD8SuQXfInYV0S0bNzx+5+XIXcnmOK+ZAqERhzy5SvZDjvnDi sK64Nz9ALdOw7eQ3EN3GWfQMO7EP0802IK+4oxLQl22MpuSOl/azFIunF0FeKu6rRJ/N f1p8/bTilMct2Rsv2K3Jj+D496ZXuT2T3fdf94/VL/tJtavFXfn9J5B3TNy95MbndvgY vPYFjQzSYz8v0PlqxaMS4AYhCKFBcNd+HyvI6ab7PdRaBL2yPz3T7gn7zWY6VDRWMHI5 31z2H63A2ycbyMUIBgnJUDH9bS3x38sN8vS5HynZ1zwZj82SVeBEQcThyoCjjdANCAse bOcg== 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=iNlyjxdrsXVmxfGz+9EedW1Cf1GmKW3UFcGteR/MNOM=; b=OJkMvzqwv5Zd/Ju0Jhe4sXQAl1OIjYokUaUCcICc1uD0jLNcDhcUWNoQGVlL82SsJU Al9dZjR/IiSoWZ0nVS64p+RgmoyKspZ51sTS/GayW9c0CfmliDGoddhKooOJ5mNLHIVH cy3/y7U2cv2Hw8Ny29eIqqN3JXN3e/GITmAEDIhLLmFBAy4ov9qbxZo3ESOZ4XNDPjZq Ztb+mLtY6cjqg1a0BHhXoH0h9nzIrElyB+m8ZbslBGAxJ6szJVlPISppD8ET4l3hqfLL nB1+6m1RotPi6zMz/PFU4YwxnHWlR76CNuELR9y2AkvQbc0SFnnyi5r62cEAQmG0EjPD zItA== X-Gm-Message-State: AOAM533GgRoHju07rWpw3LKnXkPn6AFIdEdDHCznIFPfCb2IR7ppiidR GbvO5YslTG7/q7Q1ksoL+qE6qAJ93iGe1u0l84oij8+PRg== X-Google-Smtp-Source: ABdhPJzqsMoDxWq9RnCpS+YMqw2s9AWVXKqCrOeFpcM3aOgS+3IPdNHShovWVnXczCZ6oa5Tn27fnaVn/Q4i1TGsmBc= X-Received: by 2002:a92:6504:: with SMTP id z4mr1551773ilb.282.1603140701429; Mon, 19 Oct 2020 13:51:41 -0700 (PDT) MIME-Version: 1.0 From: Yingzhen Qu Date: Mon, 19 Oct 2020 13:51:30 -0700 Message-ID: To: lsr@ietf.org, lsr-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000008a47005b20c485b" Archived-At: Subject: [Lsr] IETF 109 LSR Presentation Slot Requests X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 20:51:44 -0000 --00000000000008a47005b20c485b Content-Type: text/plain; charset="UTF-8" Hi all, We're now accepting agenda requests for the LSR Working Grouping meeting IETF 109. Please send your requests to lsr-chairs@ietf.org indicating draft name, speaker, and desired duration (covering presentation and discussion). LSR session is scheduled on Monday, Nov 16, 12:00-14:00 ICT. Thanks, Yingzhen --00000000000008a47005b20c485b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi all,=C2=A0

=C2=A0

We= 're now accepting agenda requests for the LSR Working Grouping meeting = IETF 109. Please = send your requests to=C2=A0lsr-chairs@ietf.org=C2=A0indicating draft name, = speaker, and desired duration (covering presentation and discussion).=C2=A0=

=C2=A0

LSR s= ession is scheduled on Monday, Nov 16, 12:00-14:00 ICT.

=C2=A0

= Thanks,

Yingzhen

--00000000000008a47005b20c485b-- From nobody Mon Oct 19 22:18:35 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3A53A0C61; Mon, 19 Oct 2020 22:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=DfCZg26i; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JckQ5IXv 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 wnqYgAkpFXog; Mon, 19 Oct 2020 22:18:31 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850433A0C8B; Mon, 19 Oct 2020 22:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24303; q=dns/txt; s=iport; t=1603171111; x=1604380711; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jbrjpp5qRpZt39bsslP4AJK3uwIGsEwL+LBN9rk4tRs=; b=DfCZg26i7zDkXV6VsuEGWDyq62UL//jy5Y8XpHDtST/4iGEHlXEWTu/a hDzt5on+6jN7tSPHyWKMWSfWJPC12omiLTiAv3v/6+W7czOnJeW8U0Wro GuDHewIZmppnV+lVPuV35XPGy7J7T2yyK2GHW7Vxbd2/RxXX9kUxhhVOq g=; IronPort-PHdr: =?us-ascii?q?9a23=3AoqGvahepJGMa7QgXQB29hUQelGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQA9fQ6/Vck/GQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFbSpWWq9ngVAB?= =?us-ascii?q?qsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/HgC4co5f/5BdJa1gHAEBATwBAQQ?= =?us-ascii?q?EAQECAQEHAQGBZAKBIS9RB3BZLywKhDODSQONU5h6glMDVQsBAQENAQEjCgI?= =?us-ascii?q?EAQGESgIXgXYCJTcGDgIDAQELAQEFAQEBAgEGBG2FYQyFcwIBAxIRBAYTAQE?= =?us-ascii?q?3AQ8CAQgOKgoCAgIwJQIEAQ0FIoMEAYF+TQMtAQEOpDICgTmIaHZ/M4MEAQE?= =?us-ascii?q?FgTMBE0GDIxiCEAMGgTgBgnGCYE5ChlYbggCBESccgk0+glwBAQMBgXIWgmo?= =?us-ascii?q?zgiyRToIGhxCMBZEZCoJqiQSRbwMfgxaKDZQykU+BZ4p0kQkFhC4CBAIEBQI?= =?us-ascii?q?OAQEFgWokgVdwFTsqAYI+CUcXAg2OKxeDToUUhUJ0OAIGAQkBAQMJfIw7AYE?= =?us-ascii?q?QAQE?= X-IronPort-AV: E=Sophos;i="5.77,396,1596499200"; d="scan'208,217";a="580980060" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Oct 2020 05:18:30 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 09K5IU2V025237 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2020 05:18:30 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.1497.2; Tue, 20 Oct 2020 00:18:29 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Oct 2020 01:18:29 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 20 Oct 2020 00:18:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NKzIW7vw10s82gXnzlZm1c5xWtx1SdHSJ9TN11gzN/0eN/7DVmqx7Z/bcPFDrNJWGeK0uqbSM/c4uxy5X6nY+RAK5cEgmI8mJR2+dDTdjby6DFQSg1dfKiH/F2nnUG28Q5XAZA3Rx/IS10mAO0jhXv6c+KHlnGfmj3za/1uzgTcXf4HucxpKfdp/KvkAxu3kkC0BCi//BCIGUU31GpBN4RNGHfU0TY2wf7zLBWYiHhZCRmQBua2lR+eZq2nXu1CEWvh5HNQyef0/DXlS//nEbxfbYUrnYFJhQGJWNIIoINjAj6ArI+sEO9BtO8ar1tsNiGhKL4PoVDxNxMxjmfy2cw== 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=jbrjpp5qRpZt39bsslP4AJK3uwIGsEwL+LBN9rk4tRs=; b=NP3J7+ChaTqhZRV8v9824pPISCLNQrkQ/DXaiMXGrRqmyRGhLFBw6mWHisNNQyKputzU4dK/y9U+pj+dMCK3BSmIqERZV0VYhie2ZH6s1eG2O5aUAQPajbbDIrg3dn97+M/nLUcSniSFzRBVywevH/V7g3opaEGFnut65Q1uTd0/1k2q0ykzViGn79w5dqVir4O/bD2rheiKCRRYFvWWAf1M0vdwdEZU3HoGpdNWRDGufL88ahq7qNorctyFKJvkWl7YtZgtK4XrHWbz6UzgFQZFb9X2BiIJduMj/lvbfQ1d5uhnBirTaTfMpL1uD2aGpQEj3VDaFC1qiFJWTifs0w== 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=jbrjpp5qRpZt39bsslP4AJK3uwIGsEwL+LBN9rk4tRs=; b=JckQ5IXv042rRHMkqBLqGJJ/Oqpl0FsnoQSb35dDjChbzY9R/F8pZYvvBJNBOteGy5pN5pH1ddj5/ui+56E3kEhgXKpRiRWNdhMfbC/syFkGb/20jVKH+leAJFk3hBwo3kwP9Y+q7elod3qegeEyfCufTHEi9IaWrU9EVIGZMf8= Received: from MWHPR11MB1373.namprd11.prod.outlook.com (2603:10b6:300:25::13) by MWHPR11MB1438.namprd11.prod.outlook.com (2603:10b6:301:8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Tue, 20 Oct 2020 05:18:27 +0000 Received: from MWHPR11MB1373.namprd11.prod.outlook.com ([fe80::d86e:e39b:3fae:3486]) by MWHPR11MB1373.namprd11.prod.outlook.com ([fe80::d86e:e39b:3fae:3486%10]) with mapi id 15.20.3477.028; Tue, 20 Oct 2020 05:18:27 +0000 From: "Baalajee S (basurend)" To: Christian Hopps , "lsr@ietf.org" CC: "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorrKh0IQds7Tq06Zq8QlTINtnamgV54A Date: Tue, 20 Oct 2020 05:18:27 +0000 Message-ID: <176BEDD1-AADE-4ACB-94E1-F99A420A1E40@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [122.178.184.195] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebf43524-dbf3-40c2-946b-08d874b793ab x-ms-traffictypediagnostic: MWHPR11MB1438: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ytvNh9Jzy8nEix0+gt3ODfalogkwn7CcoIdpKk/6IeUX8i4HrZA4f7eZUbq753q1K+qj5MkLml3d7z9UYaNg3K5SAGjmqvKgI7sG+xk2W4mZ6yxJOzl1Zt0xBsEJ0Ay6zlWovoXeOH2qjdPv/UAFqJAW3SDkA11GfPvo6mQMKdoJQXG0YPZFzMkmJHY1gG564hRgiPUj0QdnIruyNgzYJsHcdQgTZ7Z4U3hcb2WlfbkG9vRU9dO+FyRiX+NSz7n5J39jLYE/K2CgcsK4o542LKsLUJmI+NX6ukDGpUrLtmLyaiuZQF2XCq0InFGokFiOg2hWmZdwZt5oJu1le52PPYNHVOQQ+dUWhMbIYCJirf7cWrtb6GRSktWPifmDcmLEioMRKHEBOEWwjtXzth0J3g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1373.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(396003)(39860400002)(366004)(136003)(966005)(186003)(2616005)(8676002)(66574015)(33656002)(8936002)(4326008)(6486002)(6506007)(66946007)(26005)(76116006)(66556008)(66446008)(64756008)(91956017)(71200400001)(66476007)(6512007)(83380400001)(166002)(54906003)(316002)(5660300002)(478600001)(36756003)(2906002)(110136005)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: x5yAmnBCPKtKWB4YkyCfHZgfmvH3hTxSiY9iIWtEU6v4JLBFJ0bQnqKN3pj5Jyci+PbtrFnh68CwKb+SUkgoddSl/is8LWTHnch29z25QeSzvCdSNZSn8PuGH+/WAdHb9psGsequTd2K0s+X6dq3ro3XKoHlT5mcc0SZYh0tEcDmmC/RSMcEjlemlaW+Fj71p/pRVj3YMo9N1HTbir3t664BvkIUKCoyv7x9MKBTt2Mpv9tR/+Zs8HtaFdbDHv7YygX207nfeE3A5Cjvmmn2UMra+Vae0yxOxLcyVq9NOZftWQOGkfE9DWZ1BXhiTWauzDv8U9D7TtVtSdnrzyVx4wtkQ2qZx1nCpU0iJUNGTDckEHXVMZb5gzpAA5BQVwldlRFjHTiiYoo2s0nPktLKBrTc/w1LrDvExyrzBIrWBQ2WRmgDEO7fhDULRwPRxUX0I86mYlkc8JVIIUgjW2rLleWuNcyra+vI6l8qbC7HaN946aQ0ZA7+SQY1tmfW7b5MggCXhp5drEpsahZrMnGyxQsvY6172LUTYnZTuPH6ijPtozn/fNlBeKdmXxVr6em1WNCypWjuvIJZvSvGO5E5vs7p7iE3ToJ4N9Z9ZNvfzu3IC3bzg2moG23txol4SZJ2hsWuE2RBMvbvSM0qFDsnEA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_176BEDD1AADE4ACB94E1F99A420A1E40ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1373.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebf43524-dbf3-40c2-946b-08d874b793ab X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 05:18:27.7138 (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: w0dxW9quDBeNFRJMb4fiMrI0V1+36/R4oPOWBtEgN+6IwHTWtfGjOJE87x/+g1gjM1A48ayCCKt0pA0Mcg8AKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1438 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 05:18:34 -0000 --_000_176BEDD1AADE4ACB94E1F99A420A1E40ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYXV0aG9ycywNCg0KDQoNCkkgaGF2ZSBhIGNvdXBsZSBvZiBjb21tZW50cy4NCg0KDQoN CjEuDQogICBBIHJlY2VpdmVkIFByZWZpeCBPcmlnaW5hdG9yIFN1Yi1UTFYgdGhhdCBoYXMgYW4g aW52YWxpZCBsZW5ndGggKG5vdA0KICAgNCBvciAxNikgb3IgYSBSZWFjaGFibGUgQWRkcmVzcyBj b250YWluaW5nIGFuIGludmFsaWQgSVB2NCBvciBJUHY2DQogICBhZGRyZXNzIChkZXBlbmRlbnQg b24gYWRkcmVzcyBmYW1pbHkgb2YgdGhlIGFzc29jaWF0ZWQgcHJlZml4KSBNVVNUDQogICBiZSBj b25zaWRlcmVkIGludmFsaWQgYW5kIGlnbm9yZWQuICBBZGRpdGlvbmFsbHksIHJlY2VwdGlvbiBv ZiBzdWNoDQogICBTdWItVExWIFNIT1VMRCBiZSBsb2dnZWQgYXMgYW4gZXJyb3IgKHN1YmplY3Qg dG8gcmF0ZS1saW1pdGluZykuDQoNCg0KU2hvdWxkbuKAmXQgdGhhdCBiZSDigJxSb3V0ZXIgYWRk cmVzc+KAnT8NCg0KDQoyLg0KICAgSWYgdGhlIG9yaWdpbmF0aW5nIG5vZGUgaXMgYWR2ZXJ0aXNp bmcgYW4gT1NQRnYyIFJvdXRlciBBZGRyZXNzIFRMVg0KICAgW1JGQzM2MzA8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzM2MzA+XSBvciBhbiBPU1BGdjMgUm91dGVyIElQdjYgQWRkcmVz cyBUTFYgW1JGQzUzMjk8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUzMjk+XSwgdGhl biB0aGF0DQogICB2YWx1ZSBpcyBzZXQgaW4gdGhlIFJvdXRlciBBZGRyZXNzIGZpZWxkIG9mIHRo ZSBQcmVmaXggT3JpZ2luYXRvcg0KICAgU3ViLVRMVi4gIFdoZW4gdGhlIG9yaWduYXRpbmcgbm9k ZSBpcyBub3QgYWR2ZXJ0aXNpbmcgc3VjaCBhbg0KDQoNCg0KV2FuZywgZXQgYWwuICAgICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAxLCAyMDIxICAgICAgICAgICAgICAgIFtQYWdlIDVdDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpJbnRlcm5ldC1EcmFmdCAgICAgIE9TUEYg UHJlZml4IE9yaWdpbmF0b3IgRXh0ZW5zaW9ucyAgICAgICAgICBKdW5lIDIwMjANCg0KDQogICBh ZGRyZXNzLCBpbXBsZW1lbnRhdGlvbnMgTUFZIHN1cHBvcnQgbWVjaGFuaXNtcyB0byBkZXRlcm1p bmUgYQ0KICAgcmVhY2hhYmxlIGFkZHJlc3MgYmVsb25naW5nIHRvIHRoZSBvcmlnaW5hdGluZyBu b2RlIHRvIHNldCBpbiB0aGUNCiAgIFJvdXRlciBBZGRyZXNzIGZpZWxkLiAgU3VjaCBtZWNoYW5p c21zIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzDQogICBkb2N1bWVudC4NCg0KDQpPcmln aW5hdGluZyAtPiBvcmlnaW5hdGluZw0KDQoNCg0KSSBhc3N1bWUgdGhhdCB0aGUg4oCcUm91dGVy IGFkZHJlc3PigJ0gcGlja2VkIGJ5IGEgcm91dGVyIGNvdWxkIGJlIG9uZSBvZiB0aGUgYWRkcmVz c2VzIGFkdmVydGlzZWQgYnkgaXQgd2l0aCDigJxOLWJpdOKAnSAoTm9kZSBTSUQpIHNldCBvciBz b21lIG90aGVyIHJlYWNoYWJsZSBhZGRyZXNzIHdoaWNoIHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhl IHJvdXRlci4NCg0KDQoNClJlZ2FyZHMsDQoNClMuIEJhYWxhamVlDQoNCg0KDQrvu79PbiAxNS8x MC8yMCwgMTE6NDYgQU0sICJMc3Igb24gYmVoYWxmIG9mIENocmlzdGlhbiBIb3BwcyIgPGxzci1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaG9wcHNAY2hvcHBzLm9yZz4gd3JvdGU6DQoN Cg0KDQogICAgVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTGFzdCBDYWxsLCBlbmRpbmcgYWZ0ZXIg T2N0IDI5dGgsIDIwMjAsIGZvcjoNCg0KDQoNCiAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3IvDQoNCg0KDQog ICAgVGhlIGZvbGxvd2luZyBJUFIgaGFzIGJlZW4gZmlsZWQgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9pcHIvMzQ0OC8NCg0KDQoNCiAgICBBdXRob3JzLA0KDQoNCg0KICAgICAgUGxlYXNl IGluZGljYXRlIHRvIHRoZSBsaXN0LCB5b3VyIGtub3dsZWRnZSBvZiBhbnkgb3RoZXIgSVBSIHJl bGF0ZWQgdG8gdGhpcyB3b3JrLg0KDQoNCg0KICAgIFRoYW5rcywNCg0KICAgIENocmlzLg0K --_000_176BEDD1AADE4ACB94E1F99A420A1E40ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8EF798C2FBBAE543878F8C534EE17B7D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYu TXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252 ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1J TiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhlbGxvIGF1dGhvcnMsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkkgaGF2ZSBhIGNvdXBsZSBvZiBjb21tZW50cy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+MS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQSByZWNlaXZlZCBQcmVmaXgg T3JpZ2luYXRvciBTdWItVExWIHRoYXQgaGFzIGFuIGludmFsaWQgbGVuZ3RoIChub3Q8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1 dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgNCBvciAxNikgb3IgYTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3ciPlJlYWNoYWJsZTwvc3Bh bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QWRkcmVz cyBjb250YWluaW5nIGFuIGludmFsaWQgSVB2NCBvcg0KIElQdjY8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYWRkcmVz cyAoZGVwZW5kZW50IG9uIGFkZHJlc3MgZmFtaWx5IG9mIHRoZSBhc3NvY2lhdGVkIHByZWZpeCkg TVVTVDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0 O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBiZSBjb25zaWRlcmVkIGludmFsaWQgYW5kIGlnbm9yZWQuJm5ic3A7 IEFkZGl0aW9uYWxseSwgcmVjZXB0aW9uIG9mIHN1Y2g8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29y cGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNp emUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgU3ViLVRMViBTSE9V TEQgYmUgbG9nZ2VkIGFzIGFuIGVycm9yIChzdWJqZWN0IHRvIHJhdGUtbGltaXRpbmcpLjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog YXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29y cGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNp emUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+U2hvdWxk buKAmXQgdGhhdCBiZSDigJxSb3V0ZXIgYWRkcmVzc+KAnT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjoj NDQ3MkM0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4yLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBh dXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IElmIHRoZSBvcmlnaW5hdGluZyBu b2RlIGlzIGFkdmVydGlzaW5nIGFuIE9TUEZ2MiBSb3V0ZXIgQWRkcmVzcyBUTFY8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNjMwIiB0aXRsZT0i JnF1b3Q7VHJhZmZpYyBFbmdpbmVlcmluZyAoVEUpIEV4dGVuc2lvbnMgdG8gT1NQRiBWZXJzaW9u IDImcXVvdDsiPlJGQzM2MzA8L2E+XSBvciBhbiBPU1BGdjMgUm91dGVyIElQdjYgQWRkcmVzcyBU TFYgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MzI5IiB0aXRsZT0i JnF1b3Q7VHJhZmZpYyBFbmdpbmVlcmluZyBFeHRlbnNpb25zIHRvIE9TUEYgVmVyc2lvbiAzJnF1 b3Q7Ij5SRkM1MzI5PC9hPl0sDQogdGhlbiB0aGF0PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHZhbHVlIGlzIHNldCBp biB0aGUgUm91dGVyIEFkZHJlc3MgZmllbGQgb2YgdGhlIFByZWZpeCBPcmlnaW5hdG9yPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IFN1Yi1UTFYuJm5ic3A7IFdoZW4gdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdyI+b3Jp Z25hdGluZzwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+bm9kZSBpcyBub3QgYWR2ZXJ0aXNpbmcgc3VjaCBhbjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0 bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPldh bmcsIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEphbnVhcnkgMSwgMjAyMSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZSA1XTwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjxociBzaXplPSIyIiB3aWR0aD0iNzY4IiBzdHls ZT0id2lkdGg6NTc2LjBwdCIgYWxpZ249ImxlZnQiPg0KPC9zcGFuPjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRv Oy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YSBuYW1lPSJwYWdlLTYiPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3Rl eHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0 bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgT1NQRiBQcmVmaXggT3JpZ2luYXRvciBFeHRlbnNpb25zJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bmUgMjAyMDwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzst d2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czog YXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2Zv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dp ZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBhZGRyZXNzLCBpbXBsZW1lbnRhdGlvbnMgTUFZIHN1cHBvcnQgbWVjaGFu aXNtcyB0byBkZXRlcm1pbmUgYTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyByZWFjaGFibGUgYWRkcmVzcyBiZWxvbmdp bmcgdG8gdGhlIG9yaWdpbmF0aW5nIG5vZGUgdG8gc2V0IGluIHRoZTwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBSb3V0 ZXIgQWRkcmVzcyBmaWVsZC4mbmJzcDsgU3VjaCBtZWNoYW5pc21zIGFyZSBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0 bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCIj5PcmlnaW5hdGluZyAtJmd0OyBvcmlnaW5hdGluZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWdu OnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFy dDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+SSBhc3N1bWUgdGhhdCB0aGUg4oCcUm91dGVyIGFkZHJl c3PigJ0gcGlja2VkIGJ5IGEgcm91dGVyIGNvdWxkIGJlIG9uZSBvZiB0aGUgYWRkcmVzc2VzIGFk dmVydGlzZWQgYnkgaXQgd2l0aCDigJxOLWJpdOKAnSAoTm9kZSBTSUQpIHNldCBvciBzb21lIG90 aGVyIHJlYWNoYWJsZSBhZGRyZXNzIHdoaWNoIHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIHJvdXRl ci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs O29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1HQiI+Uy4gQmFhbGFqZWUgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPu+7v09uIDE1LzEwLzIwLCAxMTo0NiBBTSwgJnF1b3Q7THNyIG9uIGJlaGFs ZiBvZiBDaHJpc3RpYW4gSG9wcHMmcXVvdDsgJmx0O2xzci1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZiBjaG9wcHNAY2hvcHBzLm9yZyZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBMYXN0 IENhbGwsIGVuZGluZyBhZnRlciBPY3QgMjl0aCwgMjAyMCwgZm9yOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRv ci88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBm b2xsb3dpbmcgSVBSIGhhcyBiZWVuIGZpbGVkIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv aXByLzM0NDgvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyBBdXRob3JzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgUGxlYXNlIGluZGljYXRlIHRvIHRoZSBsaXN0LCB5b3VyIGtub3dsZWRn ZSBvZiBhbnkgb3RoZXIgSVBSIHJlbGF0ZWQgdG8gdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IENocmlzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_176BEDD1AADE4ACB94E1F99A420A1E40ciscocom_-- From nobody Tue Oct 20 00:10:18 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7809D3A11B2; Tue, 20 Oct 2020 00:10:17 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=I+NxLMwJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TG4egSQI 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 hQVA9GdJ86Ko; Tue, 20 Oct 2020 00:10:15 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E7E3A11B1; Tue, 20 Oct 2020 00:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27168; q=dns/txt; s=iport; t=1603177815; x=1604387415; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2alqab2Suw/8k/mGbITbrvibTEcJkQotBZAQDrmB6p8=; b=I+NxLMwJfZY3qOuK2UvKXNgJwASIffzdv5ESKvAkGqz4LXgRB0ppE6Bh M7xIWI60Q+Ygt8t83xVpoPY1Aq52Sf+/MyAtn8bXr11zxBw3FqUoYe8sJ n3Is/eqE70r2RwWwh3f75k0m9DHzCbb2Czt1fpFrEtJPtdG73n4kry6Ha Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AafGORR1hU1OCpgZlsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGuadmjUTCWsPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoOklOE8G4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPCAD9jI5f/4MNJK1gH4I5gSMvUQd?= =?us-ascii?q?wWS8sCoQzg0kDjVOYeoJTA1ULAQEBDQEBIwoCBAEBhEoCF4F2AiU3Bg4CAwE?= =?us-ascii?q?BCwEBBQEBAQIBBgRthWEMhXIBAQEBAxIRBAYTAQE3AQ8CAQgRBAEBIQcDAgI?= =?us-ascii?q?CMBQJCAIEAQ0FCBqDBYF+TQMuAQ6kKgKBOYhodn8zgwQBAQWBMwETQYMYGII?= =?us-ascii?q?QAwaBOIJygmBOQoZWG4FBP4ERQ4JNPoJcAQECAQGBXRUWCYJhM4IskU6CBoc?= =?us-ascii?q?QjAWRGQqCaokEkhGDFooNlDKRT4FngXyIeJEJBYQuAgQCBAUCDgEBBYFqJIF?= =?us-ascii?q?XcBU7gmkJRxcCDY4rF4NOhRSFQnQ4AgYBCQEBAwl8jDsBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.77,396,1596499200"; d="scan'208,217";a="602444390" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Oct 2020 07:09:59 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 09K79xoY021972 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2020 07:09:59 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Oct 2020 02:09:58 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Oct 2020 02:09:58 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 20 Oct 2020 02:09:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A4/Dr2Lzf0AcTg9Ly6KXfuCCgMskD8qacVxhIQcJeDZw51YXKpxA/nXTZFywR1kHnZKeTOrdRPYbMQ5WIVib8GwrnK3rYmti5IEwhqSWsWw5qi0cNQx3Gl1fEtb3a7zqUQoOcCGYF25BItlEIBs/sqNd2cCuvSvFYGXTPowYfLpd8xTYManyY2sls8Qz18/yiGd6erjJmMvNe5C7QQmgwcaLdT9I/EqHzOYJjPXQE8zt8ZKkOV6iM1vGmVRtBR6d8DbPJNEFj6UdlPf7JWQx5/YC8g0LMaUF5SUySGLyfwmMg1m4w8kpgUrBYod8/lh2HkLHmmSJkjyzeYWWhMrL7w== 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=2alqab2Suw/8k/mGbITbrvibTEcJkQotBZAQDrmB6p8=; b=TDWJdxJ0oEgnamvXEtsflPcuN6H3oRTf5FppEgjfENAYQ/10GY8pDD1kgDYJK412OVrOSufightHl8VTz90usFaevwxgLx5LB1lo/e7gzmf5Nxr3LYTHY3FXncD+idZgJmVwpf/+d/Tq8pBjJLsHah7pfoD6GZhR0njIudgSWX32Eu5a7gVMGirnNIz591Rf/U2cT6b2tK+lD+gsSqdIYlo09v75G1hS2R9NYZpCrRlnS10BVSugI8TplCD48FWZms0SwGUs0U9B1u3Wg5sdZSvmfJUeNdAnCkxpPrzHFfJ73bGC6bWwWDpMKZQgdpqCJ/MgbrXQguQFhj1QSMiSTQ== 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=2alqab2Suw/8k/mGbITbrvibTEcJkQotBZAQDrmB6p8=; b=TG4egSQIJKp+v8x9KC58c+Hca6EJxHhhkqWF3VR9wyLnNSAJ/djWX0xcMxvDMUUsFKB0fMNkVIzgZ7YxtjGX0ylmB+FvjyO8EQycPWKtAHOT3r5l7y6PqOhQmUAKbHsU58CHr/1dqXb0HlRUwemwUOrFxMiQ/771G681pLFCw+E= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB4964.namprd11.prod.outlook.com (2603:10b6:303:9e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Tue, 20 Oct 2020 07:09:57 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3477.028; Tue, 20 Oct 2020 07:09:57 +0000 From: "Ketan Talaulikar (ketant)" To: "Baalajee S (basurend)" , Christian Hopps , "lsr@ietf.org" CC: "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorqoC1KYinwtxka4W6+KBPi+Nqmf+2yAgAAe8uA= Date: Tue, 20 Oct 2020 07:09:57 +0000 Message-ID: References: <176BEDD1-AADE-4ACB-94E1-F99A420A1E40@cisco.com> In-Reply-To: <176BEDD1-AADE-4ACB-94E1-F99A420A1E40@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ed20fc2a-ddc9-41e7-7972-08d874c7270f x-ms-traffictypediagnostic: CO1PR11MB4964: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O3CklGJeCY6odonZzsIAA5TiU32LGZNpmwMdaXUs8xHv02dijt3SON8OOhAkMR15kfxRd3zm1y+lPhhe/NJPrWCZIwNXMbuSaUISJ07t+OhLwdkxJL2axxvJY2folD+LIB/2bH8S8b6z9xkvpfHNwfr69/XVA3CASPVn6kZBf3gP3ldgIpAT1iNNAOC/hCEY7TqvcbuRXzXuN7tNFYMejbCHJ4jRLyOuesewoShon5ZibUBWa2haNwP6OKrTSJjkYc0KHtGyyN0qrg72lWGipLYjBRkt3rK5CaBP91ZdTBL8tvQIUWYA35R56jbPjE9LksfAEbJB2DM4RW62HPuqNLBL1tIaGwsYpWaTJQrN+gTpaexJ5FzrUUJJJZjy0P1wqRmO8tlET2pKvhaJMvZL9A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(39860400002)(366004)(346002)(396003)(66946007)(2906002)(166002)(966005)(86362001)(6506007)(54906003)(110136005)(316002)(53546011)(8676002)(26005)(4326008)(9326002)(33656002)(8936002)(83380400001)(478600001)(186003)(5660300002)(76116006)(52536014)(66574015)(66446008)(66556008)(64756008)(9686003)(71200400001)(55016002)(7696005)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: GZP1gaNM2dOS9QT+sEXJHpFZNUloa4r2wA29G6CZdt6UgA+bnLsndpGwRGCoxE6tR4kLNJ9JnykdIpE4XEnr8vANnCoU/dmYhy5uoom6gvWbKS087exIXBp6b90dHq7VH6hUhEx9sDmeDsfzUXfqjYDNm6Bssulc/699uus7lhtZWdUcn+fZmn/pftpBHLS9XR0rhco/pUnqoLT6r3GQN8eecKznm6DfHy8FWytJ60SRZKS49Ny5korSffOuywDWYDbTrgoWQDaGXNCc/FVIWEcddTVfgM1JLzwKsqbynQWoR46Hlb9Pz+9q0d+/InownzhqPnF9Mmk8D545IPkXxrhRNKX0Od7tPOt7Mfs+5Sd99/5PfhhoOUmi0HqeeW4euZLIlvNhmwhC8Bah1IprdNI89hTD101l/mnUXHJxFHYBNg7A6majwNAJ/Ru7jNA1zTtQSL9VZDK9tALGH8VG0QrtBXkgF9X4VsMhiZIusNqqYse+QaaH61AWuiOPwwDO2G/2lRFRhg5tudcEFK5ViePryoELC5bJE7MSKZN4h4iMMxr+OpigE+SXmljmWbMwp2gAd61ceU5hIwrxqHXGdu8nRDiiN5EGLWsJBPDV8taITzbZ0yEJBH+iVbwKJkFVVibFbQYRPkfeVCbttyabOQ== Content-Type: multipart/alternative; boundary="_000_MW3PR11MB457028DC787EFA7C261DEE4AC11F0MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed20fc2a-ddc9-41e7-7972-08d874c7270f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 07:09:57.4534 (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: wFMeBDKe8bA8X4uGiWfjKqm+90uDsB0C72J5urF7cQ0Q/ENBIt6gAihi1d8BL2kGtCpDF3VeuTU6RYRjKEUugA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4964 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 07:10:17 -0000 --_000_MW3PR11MB457028DC787EFA7C261DEE4AC11F0MW3PR11MB4570namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmFhbGFqZWUsDQoNClRoYW5rcyBmb3IgeW91IHJldmlldyBhbmQgY29tbWVudHMuIFdl4oCZ bGwgaW5jb3Jwb3JhdGUgdGhlc2UgZml4ZXMvY2xhcmlmaWNhdGlvbnMgaW4gdGhlIHVwY29taW5n IHVwZGF0ZS4NCg0KVGhhbmtzLA0KS2V0YW4NCg0KRnJvbTogQmFhbGFqZWUgUyAoYmFzdXJlbmQp IDxiYXN1cmVuZEBjaXNjby5jb20+DQpTZW50OiAyMCBPY3RvYmVyIDIwMjAgMTA6NDgNClRvOiBD aHJpc3RpYW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPjsgbHNyQGlldGYub3JnDQpDYzogZHJh ZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvckBpZXRmLm9yZzsgbHNyLWNoYWlyc0Bp ZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMc3JdIFdHIExhc3QgQ2Fs bCBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQoNCg0KSGVsbG8gYXV0 aG9ycywNCg0KDQoNCkkgaGF2ZSBhIGNvdXBsZSBvZiBjb21tZW50cy4NCg0KDQoNCjEuDQogICBB IHJlY2VpdmVkIFByZWZpeCBPcmlnaW5hdG9yIFN1Yi1UTFYgdGhhdCBoYXMgYW4gaW52YWxpZCBs ZW5ndGggKG5vdA0KICAgNCBvciAxNikgb3IgYSBSZWFjaGFibGUgQWRkcmVzcyBjb250YWluaW5n IGFuIGludmFsaWQgSVB2NCBvciBJUHY2DQogICBhZGRyZXNzIChkZXBlbmRlbnQgb24gYWRkcmVz cyBmYW1pbHkgb2YgdGhlIGFzc29jaWF0ZWQgcHJlZml4KSBNVVNUDQogICBiZSBjb25zaWRlcmVk IGludmFsaWQgYW5kIGlnbm9yZWQuICBBZGRpdGlvbmFsbHksIHJlY2VwdGlvbiBvZiBzdWNoDQog ICBTdWItVExWIFNIT1VMRCBiZSBsb2dnZWQgYXMgYW4gZXJyb3IgKHN1YmplY3QgdG8gcmF0ZS1s aW1pdGluZykuDQoNCg0KU2hvdWxkbuKAmXQgdGhhdCBiZSDigJxSb3V0ZXIgYWRkcmVzc+KAnT8N Cg0KDQoyLg0KICAgSWYgdGhlIG9yaWdpbmF0aW5nIG5vZGUgaXMgYWR2ZXJ0aXNpbmcgYW4gT1NQ RnYyIFJvdXRlciBBZGRyZXNzIFRMVg0KICAgW1JGQzM2MzA8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzM2MzA+XSBvciBhbiBPU1BGdjMgUm91dGVyIElQdjYgQWRkcmVzcyBUTFYgW1JG QzUzMjk8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUzMjk+XSwgdGhlbiB0aGF0DQog ICB2YWx1ZSBpcyBzZXQgaW4gdGhlIFJvdXRlciBBZGRyZXNzIGZpZWxkIG9mIHRoZSBQcmVmaXgg T3JpZ2luYXRvcg0KICAgU3ViLVRMVi4gIFdoZW4gdGhlIG9yaWduYXRpbmcgbm9kZSBpcyBub3Qg YWR2ZXJ0aXNpbmcgc3VjaCBhbg0KDQoNCg0KV2FuZywgZXQgYWwuICAgICAgICAgICAgIEV4cGly ZXMgSmFudWFyeSAxLCAyMDIxICAgICAgICAgICAgICAgIFtQYWdlIDVdDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpJbnRlcm5ldC1EcmFmdCAgICAgIE9TUEYgUHJlZml4IE9y aWdpbmF0b3IgRXh0ZW5zaW9ucyAgICAgICAgICBKdW5lIDIwMjANCg0KDQogICBhZGRyZXNzLCBp bXBsZW1lbnRhdGlvbnMgTUFZIHN1cHBvcnQgbWVjaGFuaXNtcyB0byBkZXRlcm1pbmUgYQ0KICAg cmVhY2hhYmxlIGFkZHJlc3MgYmVsb25naW5nIHRvIHRoZSBvcmlnaW5hdGluZyBub2RlIHRvIHNl dCBpbiB0aGUNCiAgIFJvdXRlciBBZGRyZXNzIGZpZWxkLiAgU3VjaCBtZWNoYW5pc21zIGFyZSBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzDQogICBkb2N1bWVudC4NCg0KDQpPcmlnaW5hdGluZyAt PiBvcmlnaW5hdGluZw0KDQoNCg0KSSBhc3N1bWUgdGhhdCB0aGUg4oCcUm91dGVyIGFkZHJlc3Pi gJ0gcGlja2VkIGJ5IGEgcm91dGVyIGNvdWxkIGJlIG9uZSBvZiB0aGUgYWRkcmVzc2VzIGFkdmVy dGlzZWQgYnkgaXQgd2l0aCDigJxOLWJpdOKAnSAoTm9kZSBTSUQpIHNldCBvciBzb21lIG90aGVy IHJlYWNoYWJsZSBhZGRyZXNzIHdoaWNoIHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIHJvdXRlci4N Cg0KDQoNClJlZ2FyZHMsDQoNClMuIEJhYWxhamVlDQoNCg0KDQrvu79PbiAxNS8xMC8yMCwgMTE6 NDYgQU0sICJMc3Igb24gYmVoYWxmIG9mIENocmlzdGlhbiBIb3BwcyIgPGxzci1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBjaG9wcHNAY2hvcHBzLm9yZzxtYWlsdG86bHNyLWJvdW5jZXNA aWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIwY2hvcHBzQGNob3Bwcy5vcmc+PiB3cm90ZToN Cg0KDQoNCiAgICBUaGlzIGJlZ2lucyBhIDIgd2VlayBXRyBMYXN0IENhbGwsIGVuZGluZyBhZnRl ciBPY3QgMjl0aCwgMjAyMCwgZm9yOg0KDQoNCg0KICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgtb3JpZ2luYXRvci8NCg0KDQoN CiAgICBUaGUgZm9sbG93aW5nIElQUiBoYXMgYmVlbiBmaWxlZCBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2lwci8zNDQ4Lw0KDQoNCg0KICAgIEF1dGhvcnMsDQoNCg0KDQogICAgICBQbGVh c2UgaW5kaWNhdGUgdG8gdGhlIGxpc3QsIHlvdXIga25vd2xlZGdlIG9mIGFueSBvdGhlciBJUFIg cmVsYXRlZCB0byB0aGlzIHdvcmsuDQoNCg0KDQogICAgVGhhbmtzLA0KDQogICAgQ2hyaXMuDQo= --_000_MW3PR11MB457028DC787EFA7C261DEE4AC11F0MW3PR11MB4570namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uUGxh aW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUy Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1JTiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBCYWFsYWplZSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyBmb3IgeW91IHJldmlldyBhbmQg Y29tbWVudHMuIFdl4oCZbGwgaW5jb3Jwb3JhdGUgdGhlc2UgZml4ZXMvY2xhcmlmaWNhdGlvbnMg aW4gdGhlIHVwY29taW5nIHVwZGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+S2V0YW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1JTiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1JTiI+IEJhYWxhamVlIFMgKGJhc3VyZW5kKSAmbHQ7YmFzdXJlbmRA Y2lzY28uY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDIwIE9jdG9iZXIgMjAyMCAxMDo0ODxi cj4NCjxiPlRvOjwvYj4gQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9yZyZndDs7 IGxzckBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gZHJhZnQtaWV0Zi1sc3Itb3NwZi1wcmVmaXgt b3JpZ2luYXRvckBpZXRmLm9yZzsgbHNyLWNoYWlyc0BpZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0xzcl0gV0cgTGFzdCBDYWxsIGRyYWZ0LWlldGYt bHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5IZWxsbyBhdXRob3JzLDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5JIGhhdmUgYSBjb3VwbGUgb2YgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgcmVjZWl2ZWQgUHJlZml4IE9yaWdpbmF0 b3IgU3ViLVRMViB0aGF0IGhhcyBhbiBpbnZhbGlkIGxlbmd0aCAobm90PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IDQg b3IgMTYpIG9yIGE8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5SZWFjaGFibGU8L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkFkZHJlc3MgY29udGFp bmluZyBhbiBpbnZhbGlkIElQdjQgb3INCiBJUHY2PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBo YW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n OjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgKGRlcGVu ZGVudCBvbiBhZGRyZXNzIGZhbWlseSBvZiB0aGUgYXNzb2NpYXRlZCBwcmVmaXgpIE1VU1Q8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgYmUgY29uc2lkZXJlZCBpbnZhbGlkIGFuZCBpZ25vcmVkLiZuYnNwOyBBZGRpdGlv bmFsbHksIHJlY2VwdGlvbiBvZiBzdWNoPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBh dXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFN1Yi1UTFYgU0hPVUxEIGJlIGxv Z2dlZCBhcyBhbiBlcnJvciAoc3ViamVjdCB0byByYXRlLWxpbWl0aW5nKS48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdl YmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBh dXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+ DQo8c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPlNob3VsZG7igJl0IHRo YXQgYmUg4oCcUm91dGVyIGFkZHJlc3PigJ0/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Mi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBJZiB0aGUgb3JpZ2luYXRpbmcgbm9kZSBpcyBh ZHZlcnRpc2luZyBhbiBPU1BGdjIgUm91dGVyIEFkZHJlc3MgVExWPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzYzMCIgdGl0bGU9IiZxdW90O1Ry YWZmaWMgRW5naW5lZXJpbmcgKFRFKSBFeHRlbnNpb25zIHRvIE9TUEYgVmVyc2lvbiAyJnF1b3Q7 Ij5SRkMzNjMwPC9hPl0gb3IgYW4gT1NQRnYzIFJvdXRlciBJUHY2IEFkZHJlc3MgVExWIFs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTMyOSIgdGl0bGU9IiZxdW90O1Ry YWZmaWMgRW5naW5lZXJpbmcgRXh0ZW5zaW9ucyB0byBPU1BGIFZlcnNpb24gMyZxdW90OyI+UkZD NTMyOTwvYT5dLA0KIHRoZW4gdGhhdDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0 bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB2YWx1ZSBpcyBzZXQgaW4gdGhlIFJv dXRlciBBZGRyZXNzIGZpZWxkIG9mIHRoZSBQcmVmaXggT3JpZ2luYXRvcjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBT dWItVExWLiZuYnNwOyBXaGVuIHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3ciPm9yaWduYXRpbmc8 L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm5v ZGUgaXMgbm90IGFkdmVydGlzaW5nIHN1Y2ggYW48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhh bnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUt YWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs O29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5XYW5nLCBldCBh bC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDEsIDIwMjEmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgNV08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI3NjgiIHN0eWxl PSJ3aWR0aDo1NzYuMHB0IiBhbGlnbj0ibGVmdCI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93 czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGEgbmFtZT0icGFnZS02Ij48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczog YXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE9TUEYgUHJlZml4IE9yaWdpbmF0b3IgRXh0ZW5zaW9ucyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdW5lIDIwMjA8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6 IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3 aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpz dGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgYWRkcmVzcywgaW1wbGVtZW50YXRpb25zIE1BWSBzdXBwb3J0 IG1lY2hhbmlzbXMgdG8gZGV0ZXJtaW5lIGE8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6 IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVhY2hhYmxlIGFkZHJlc3Mg YmVsb25naW5nIHRvIHRoZSBvcmlnaW5hdGluZyBub2RlIHRvIHNldCBpbiB0aGU8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87 LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgUm91dGVyIEFkZHJlc3MgZmllbGQuJm5ic3A7IFN1Y2ggbWVjaGFuaXNtcyBhcmUgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpczwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBkb2N1bWVudC48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRv d3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1HQiI+T3JpZ2luYXRpbmcgLSZndDsgb3JpZ2luYXRpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4 dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkkgYXNzdW1lIHRoYXQgdGhlIOKAnFJvdXRl ciBhZGRyZXNz4oCdIHBpY2tlZCBieSBhIHJvdXRlciBjb3VsZCBiZSBvbmUgb2YgdGhlIGFkZHJl c3NlcyBhZHZlcnRpc2VkIGJ5IGl0IHdpdGgg4oCcTi1iaXTigJ0gKE5vZGUgU0lEKSBzZXQgb3Ig c29tZSBvdGhlciByZWFjaGFibGUgYWRkcmVzcyB3aGljaCB1bmlxdWVseSBpZGVudGlmaWVzIHRo ZSByb3V0ZXIuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPlMuIEJhYWxhamVlIDxvOnA+DQo8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij7vu79PbiAxNS8xMC8yMCwgMTE6NDYgQU0sICZxdW90O0xzciBv biBiZWhhbGYgb2YgQ2hyaXN0aWFuIEhvcHBzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bHNy LWJvdW5jZXNAaWV0Zi5vcmclMjBvbiUyMGJlaGFsZiUyMG9mJTIwY2hvcHBzQGNob3Bwcy5vcmci Pmxzci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaG9wcHNAY2hvcHBzLm9yZzwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgVGhpcyBiZWdpbnMgYSAyIHdlZWsgV0cgTGFzdCBDYWxsLCBlbmRpbmcgYWZ0ZXIgT2N0IDI5 dGgsIDIwMjAsIGZvcjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3IvIj4NCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0 b3IvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg VGhlIGZvbGxvd2luZyBJUFIgaGFzIGJlZW4gZmlsZWQgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pcHIvMzQ0OC8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9p cHIvMzQ0OC88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyBBdXRob3JzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUGxlYXNlIGluZGljYXRlIHRvIHRoZSBsaXN0LCB5b3VyIGtub3ds ZWRnZSBvZiBhbnkgb3RoZXIgSVBSIHJlbGF0ZWQgdG8gdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IENocmlzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MW3PR11MB457028DC787EFA7C261DEE4AC11F0MW3PR11MB4570namp_-- From nobody Tue Oct 20 02:44:04 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B16D3A1030 for ; Tue, 20 Oct 2020 02:44:03 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 98KoHTP5I06x for ; Tue, 20 Oct 2020 02:44:00 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91DE3A1031 for ; Tue, 20 Oct 2020 02:43:59 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 4CFpbx1xjnz228H; Tue, 20 Oct 2020 11:43:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603187037; bh=oW28CzyDT6icF2D1d9ZyylGf9kvSUgWZsQIA3REQRYQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=BqRB8wrDPzfgwOwhztnus7X5cPjtUjhEZI55GaYgQPzkY6QsXH7o47Otyla/ZGwlE JgmJeNDx1VxGTKvHX6b4O8fddRtIMHnzCJTbMIGS+AYr5cx5Herw9yxB7rVwJrEZGL YlApaXbJJddauNsdbSPc84zNeIjpmHmiKTiDvJ2jEO0wuBzohfbubIr5QTF7TjPhgL ZOWkgAyQNLmPdxputxMB2XB2umJFrVpqDt2HtwyWWsdvSQICr0d3t9WaC7hcBaJfEN twYJ3/DRs4mYc6mmCGV7hLz0JvpxUEbClzuJAz0CX5bVDu7bvICGkUB8/Hdb8GfGO4 mUNunpHV9mwPA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4CFpbx0WPXz1xqX; Tue, 20 Oct 2020 11:43:57 +0200 (CEST) From: To: Peter Psenak , Ron Bonica , "lsr@ietf.org" Thread-Topic: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Thread-Index: AQHWpkEBY6va2npi40a77IPSIkOW4qmgKrvQ Date: Tue, 20 Oct 2020 09:43:56 +0000 Message-ID: <15498_1603187037_5F8EB15D_15498_303_1_53C29892C857584299CBF5D05346208A48FC2194@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <5770_1603126349_5F8DC44D_5770_187_4_53C29892C857584299CBF5D05346208A48FC0918@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <0f958743-3709-83cc-6e7f-8bb5d5746bc5@cisco.com> In-Reply-To: <0f958743-3709-83cc-6e7f-8bb5d5746bc5@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 09:44:03 -0000 UGV0ZXIsDQoNCj4gRnJvbTogUGV0ZXIgUHNlbmFrIFttYWlsdG86cHBzZW5ha0BjaXNjby5jb21d DQo+IA0KPiBCcnVubywNCj4gDQo+IE9uIDE5LzEwLzIwMjAgMTg6NTIsIGJydW5vLmRlY3JhZW5l QG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gUm9uLCBhbGwsDQo+ID4NCj4gPj5Gcm9tIGEgdXNlIGNh c2Ugc3RhbmRwb2ludCwgSSBoYXZlIGEgdXNlIGNhc2UgZm9yIGhhdmluZyBib3RoIFNSLU1QTFMg YW5kDQo+IElQIGZsZXhhbGdvIGluIHRoZSBzYW1lIG5ldHdvcmsuDQo+ID4NCj4gPj5Gcm9tIGEg cHJvdG9jb2wgc3RhbmRwb2ludCwgSSB0aGluayB0aGF0IHRoZSBmdW5jdGlvbmFsaXR5IGNvdWxk IGJlIGVxdWFsbHkNCj4gbWV0IGJ5IGFkdmVydGlzaW5nIFNSLU1QTFMgU0lEIGFzIHBlciBSRkMg ODY2NyBidXQgdXNpbmcgYSBsYWJlbCAzIChpbXBsaWNpdA0KPiBudWxsKSB0byBpbnN0cnVjdCB0 aGUgTEVSL0xTUiB0byBub3QgdXNlIGEgbGFiZWwgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuICh3 aGlsZQ0KPiBzdGlsbCBhZHZlcnRpc2luZyBhIGxhYmVsIGluIHRoZSBjb250cm9sIHBsYW5lIGJl Y2F1c2Ugd2UgaGF2ZSB0bykuDQo+IA0KPiBkb2VzIG5vdCB3b3JrLA0KDQpJIGNvdWxkIHByb3Zp ZGUgbW9yZSBleHBsYW5hdGlvbnMsIGJ1dCByZWFkaW5nIHlvdXIgZW1haWwsIGl0IHNlZW1zIHRv IG1lIHRoYXQgeW91IHVuZGVyc3Rvb2QgdGhlIHByb3Bvc2FsLg0KU28gaXQgc2VlbXMgdG8gbWUg dGhhdCB0aGUgb3BpbmlvbiB0aGF0IHlvdSByZWFsbHkgbWVhbnQgaXM6IGl0IHdvcmtzIGJ1dCBp dCB3b3VsZCBiZSBhbiBuYXN0eSBoYWNrLg0KDQpSZWdhcmRpbmcgIm5hc3R5IGhhY2siIGl0IGNv dWxkIGJlIGludGVyZXN0aW5nIHRvIGhhdmUgYSBub3JtYXRpdmUgZGVmaW5pdGlvbi4gVGhpcyBj b3VsZCBwcm92ZSB1c2VmdWwgaW4gc29tZSBvdGhlciBjb250ZXh0cy4gDQpCVFcsIGlzICJtYXgg bWV0cmljIiBhIGhhY2sgKHZzIGNyZWF0aW5nIGEgbmV3IHRsdiBpZiB5b3UgZG9uJ3Qgd2FudCB0 aGUgbGluayBpbiB0aGUgSUdQIFNQRiksIGlzICJpbXBsaWNpdCBudWxsIGxhYmVsIiBhIGhhY2su IEFuZCBmb3IgQkdQLCBlbmNvZGluZyB0aGUgbGFiZWwgaW4gdGhlIE5MUkkuLi4NCg0KDQpDb21p bmcgYmFjayB0byB0ZWNobmljYWwgY29tbWVudHMsIG5vdGUgdGhhdCBjcmVhdGluZyB5ZXQgYW5v dGhlciBUTFYgdG8gY2FycnkgSVAgcHJlZml4IGFsc28gYnJpbmdzIHF1ZXN0aW9ucyB0aGF0IHRo ZSBkcmFmdCBkb2VzIG5vdCBhbnN3ZXIgb3IgZXZlbiByYWlzZS4NCi0gV2hhdCBhYm91dCB0aGUg c3ViLVRMVnM/IEFyZSB0aGV5IHNoYXJlZCB3aXRoIHRoZSBleGlzdGluZyByZWdpc3RyeSBmb3Ig cHJlZml4IFRMViBbMV0gPyBEbyB3ZSB3YW50IHRvIGV4Y2x1ZGUgc29tZT8gRS5nLiwgUHJlZml4 IFNlZ21lbnQgSWRlbnRpZmllciAod2Ugd291bGQgaGF2ZSB0d28gYWxnbyBmaWVsZHMsIHR3byB3 YXlzIHRvIHNpZ25hbCBTSURzLi4uKQ0KLSBmb3IgSVB2NiwgdGhlIGNvbnRlbnQgYW5kIG1lYW5p bmcgb2YgICJJU0lTIE1UIElQdjYgRmxleGFsZ28gUHJlZml4IFJlYWNoYWJpbGl0eSBUTFYiIGlz IGVzc2VudGlhbGx5IHRoZSBzYW1lIHRoYW4gdGhlICJTUnY2IExvY2F0b3IgVExWIi4NCgktIE9u bHkgdGhlIG5hbWluZyBhbmQgdGhlIG9yZGVyaW5nIG9mIHRoZSBmaWVsZHMgYXJlIGRpZmZlcmVu dC4NCgktIFdoeSBkbyB3ZSBuZWVkIHR3byBUTFZzIHRvIGFkdmVydGlzZSB0aGUgc2FtZSB0aGlu ZyAoZXNzZW50aWFsbHkgYSBSb3V0aW5nIEFsZ28pPyBEdXBsaWNhdGlvbiBtZWFucyBtb3JlIHNw ZWMsIG1vcmUgY29kZSwgbW9yZSBmZWF0dXJlcyB0byBpbXBsZW1lbnQsIG1vcmUgZXJyb3IgYW5k IGJ1Z3MuIChhbmQgaXQgZGlkIG5vdCB0b29rIGxvbmc6IHRoZSBkcmFmdCBkZWZpbmVzIHRoZSBN VElEIGZpZWxkIGFzIDggYml0cyB3aGlsZSBSRkMgNTEyMCBkZWZpbmVzIGl0IGEgMTIgYml0cy4N CgktIFdoYXQgaXMgdGhlIGZ1bmN0aW9uYWwgZGlmZmVyZW50IGJldHdlZW4gRmxleEFsZ28gZm9y IFNSdjYgYW5kIEZsZXhBbGdvIGZvciBJUHY2PyBCb3RoIHVzZSB0aGUgSVB2NiBkZXN0aW5hdGlv biBhZGRyZXNzIGluIHRoZSBwYWNrZXQgYW5kIHRoZSBJUHY2IEZJQiBpbiB0aGUgcm91dGVyLg0K DQpUaGFua3MsDQpCcnVubw0KDQo+IGFzIGl0IGRvZXMgbm90IGFsbG93IHlvdSB0byBhc3NvY2lh dGUgdGhlIHByZWZpeCB3aXRoDQo+IEZsZXgtYWxnbyB3aXRob3V0IGFkdmVydGlzaW5nIHRoZSBy ZWFjaGFiaWxpdHkgaW4gYWxnbyAwLiBNYWtpbmcgdGhlDQo+IHByZWZpeCByZWFjaGFiaWxpdHkg aW4gZGVmYXVsdCBhbGdvIGNvbmRpdGlvbmFsIGJhc2VkIG9uIHRoZSBwcmVzZW5jZSBvZg0KPiB0 aGUgUHJlZml4IFNJRCBTdWItVExWIHdpdGggSW1ucGxpY2l0IE51bGwgd291bGQgYmUgYSBuYXN0 eSBoYWNrLg0KPiANCj4gTm90IHRvIG1lbnRpb24gdGhhdCBhZHZlcnRpc2luZyBhIFByZWZpeCBT SUQgaW4gcHVyZSBJUCBuZXR3b3JrIHdvdWxkIGJlDQo+IHVnbHkuDQo+IA0KPiB0aGFua3MsDQo+ IFBldGVyDQo+IA0KPiANCj4gDQo+ID4gSSBmZWVsIHRoYXQgdGhpcyB3b3VsZCBiZSBsZXNzIGNo YW5nZSBpbiB0aGUgcHJvdG9jb2wgKG5vIG5ldyB0bHYpLCBhIGdvb2QgZml0DQo+IGZvciBuZXR3 b3JrIHJlcXVpcmluZyBib3RoIE1QTFMgYW5kIElQIGZsZXggYWxnbywgYW5kIHdvdWxkIG5vdCBy ZXF1aXJlDQo+IGltcGxlbWVudGF0aW9ucy9uZXR3b3JrIG9wZXJhdG9yIHRvIGR1cGxpY2F0ZSB0 aGUgInByZWZpeCBzdWItVExWIiBbMV0gb24NCj4gYm90aCBhZHZlcnRpc2VtZW50cyAoSVAgYmFz ZWQgYW5kIFNSLU1QTFMgYmFzZWQpLg0KPiA+DQo+ID4gVGhhdCB3b3VsZCBzdGlsbCByZXF1aXJl cyBhIHByb3RvY29sIGV4dGVuc2lvbi9TVEQgdHJhY2sgUkZDIGFzIFJGQyA4NjY3DQo+IGRvZXMg bm90IGFsbG93IGZvciB0aGlzLiBUaGF0IHdvdWxkIHN0aWxsIHJlcXVpcmUgY2hhbmdlIHRvIGlt cGxlbWVudGF0aW9ucyBhcw0KPiBvbmx5IHRoZSBzaWduYWxsaW5nIGlzIGRpZmZlcmVudCB3aGls ZSB0aGUgZmVhdHVyZS9iZWhhdmlvciBpcyB0aGUgc2FtZSAoaS5lLiBubw0KPiBtYWdpYykuDQo+ ID4NCj4gPiBSZWdhcmRzLA0KPiA+IC0tQnJ1bm8NCj4gPg0KPiA+IFsxXSBha2EgIlN1Yi1UTFZz IGZvciBUTFZzIDEzNSwgMjM1LCAyMzYsIGFuZCAyMzcgKEV4dGVuZGVkIElQIHJlYWNoYWJpbGl0 eSwNCj4gTVQgSVAuIFJlYWNoLCBJUHY2IElQLiBSZWFjaCwgYW5kIE1UIElQdjYgSVAuIFJlYWNo IFRMVnMpIg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogTHNyIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24g Qm9uaWNhDQo+ID4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyOSwgMjAyMCAzOjM4IFBNDQo+ ID4+IFRvOiBsc3JAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogW0xzcl0gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYm9uaWNhLWxzci1pcC0NCj4gZmxleGFsZ28tDQo+ID4+ IDAwLnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBQbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50DQo+ID4+ DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KPiA+Pg0KPiA+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPiA+Pj4gU2VudDogVHVlc2RheSwg U2VwdGVtYmVyIDI5LCAyMDIwIDk6MzYgQU0NCj4gPj4+IFRvOiBQYXJhZyBLYW5lcml5YSA8cGth bmVyaWFAanVuaXBlci5uZXQ+OyBTaHJhZGRoYSBIZWdkZQ0KPiA+Pj4gPHNocmFkZGhhQGp1bmlw ZXIubmV0PjsgUm9uIEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD47IFJhamVzaCBNDQo+ID4+ PiA8bXJhamVzaEBqdW5pcGVyLm5ldD47IFdpbGxpYW0gQnJpdHRvIEEgSiA8YndpbGxpYW1AanVu aXBlci5uZXQ+DQo+ID4+PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDAudHh0DQo+ID4+Pg0KPiA+Pj4gW0V4dGVybmFs IEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9uaWNhLWxzci1pcC1mbGV4YWxnby0wMC50eHQNCj4g Pj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9uIEJvbmljYSBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGDQo+ID4+PiByZXBvc2l0b3J5Lg0KPiA+Pj4NCj4gPj4+IE5hbWU6ICAg ICAgICAgICBkcmFmdC1ib25pY2EtbHNyLWlwLWZsZXhhbGdvDQo+ID4+PiBSZXZpc2lvbjogICAg ICAgMDANCj4gPj4+IFRpdGxlOiAgICAgICAgICBJR1AgRmxleGlibGUgQWxnb3JpdGhtcyAoRmxl eGFsZ28pIEluIElQIE5ldHdvcmtzDQo+ID4+PiBEb2N1bWVudCBkYXRlOiAgMjAyMC0wOS0yOQ0K PiA+Pj4gR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+Pj4gUGFnZXM6 ICAgICAgICAgIDE0DQo+ID4+PiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLmNv bS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LQ0KPiA+PiBib25pY2EtDQo+ID4+ PiBsc3ItaXAtZmxleGFsZ28tMDAudHh0X187ISFORXQ2eU1hTy1nayFYN1BWRFAtDQo+ID4+PiBG blVBMG9DY1pNdzNRZGU2aW4wQzcyaHVfOWhPWjUza1BzcElhclI4Zk5EeVU5VmNrODBaYmpvaWok DQo+ID4+PiBTdGF0dXM6DQo+ID4+PiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtDQo+ID4+IGJvbmljYS1sc3ItDQo+ID4+ PiBpcC1mbGV4YWxnby9fXzshIU5FdDZ5TWFPLWdrIVg3UFZEUC0NCj4gPj4+IEZuVUEwb0NjWk13 M1FkZTZpbjBDNzJodV85aE9aNTNrUHNwSWFyUjhmTkR5VTlWY2s4eDdlNVpxSSQNCj4gPj4+IEh0 bWxpemVkOg0KPiA+Pj4NCj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtDQo+ID4+PiBib25pY2EtbHNyLWlwLWZs ZXhhbGdvX187ISFORXQ2eU1hTy1nayFYN1BWRFAtDQo+ID4+Pg0KPiBGblVBMG9DY1pNdzNRZGU2 aW4wQzcyaHVfOWhPWjUza1BzcElhclI4Zk5EeVU5VmNrODJ3XzZDeVUkDQo+ID4+PiBIdG1saXpl ZDoNCj4gPj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC0NCj4gPj4+IGJvbmljYS1sc3ItaXAtZmxleGFsZ28tMDBfXzshIU5FdDZ5 TWFPLWdrIVg3UFZEUC0NCj4gPj4+IEZuVUEwb0NjWk13M1FkZTZpbjBDNzJodV85aE9aNTNrUHNw SWFyUjhmTkR5VTlWY2s4MV9RckpfcCQNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQWJzdHJhY3Q6DQo+ ID4+PiAgICAgQW4gSUdQIEZsZXhpYmxlIEFsZ29yaXRobSBjb21wdXRlcyBhIGNvbnN0cmFpbnQt YmFzZWQgcGF0aCBhbmQgbWFwcw0KPiA+Pj4gICAgIHRoYXQgcGF0aCB0byBhbiBpZGVudGlmaWVy LiAgQXMgY3VycmVudGx5IGRlZmluZWQsIEZsZXhhbGdvIGNhbiBvbmx5DQo+ID4+PiAgICAgbWFw IHRoZSBwYXRocyB0aGF0IGl0IGNvbXB1dGVzIHRvIFNlZ21lbnQgUm91dGluZyAoU1IpIGlkZW50 aWZpZXJzLg0KPiA+Pj4gICAgIFRoZXJlZm9yZSwgRmxleGFsZ28gY2Fubm90IGJlIGRlcGxveWVk IGluIHRoZSBhYnNlbmNlIG9mIFNSLg0KPiA+Pj4NCj4gPj4+ICAgICBUaGlzIGRvY3VtZW50IGV4 dGVuZHMgRmxleGFsZ28sIHNvIHRoYXQgaXQgY2FuIG1hcCB0aGUgcGF0aHMgdGhhdCBpdA0KPiA+ Pj4gICAgIGNvbXB1dGVzIHRvIElQIGFkZHJlc3Nlcy4gIFRoaXMgYWxsb3dzIEZsZXhhbGdvIHRv IGJlIGRlcGxveWVkIGluIGFueQ0KPiA+Pj4gICAgIElQIG5ldHdvcmssIGV2ZW4gaW4gdGhlIGFi c2VuY2Ugb2YgU1IuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YN Cj4gPj4gc3VibWlzc2lvbg0KPiA+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPj4+DQo+ID4+PiBUaGUgSUVU RiBTZWNyZXRhcmlhdA0KPiA+Pj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4gTHNyIG1haWxpbmcgbGlzdA0KPiA+PiBMc3JAaWV0Zi5v cmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3INCj4gPg0K PiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBfX19fXw0KPiA+DQo+ID4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+IGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+ID4gcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlDQo+IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4g PiBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMNCj4gZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLA0KPiA+IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91DQo+IGZhbHNpZmllLiBNZXJjaS4NCj4g Pg0KPiA+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkDQo+IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7DQo+ID4gdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUNCj4g dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4N Cj4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+IFRoYW5rIHlvdS4NCj4gPg0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g THNyIG1haWxpbmcgbGlzdA0KPiA+IExzckBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo+ID4NCj4gPg0KDQoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu Cgo= From nobody Tue Oct 20 03:56:04 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0105E3A1162; Tue, 20 Oct 2020 03:55:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <160319135894.6601.15604950319457142858@ietfa.amsl.com> Date: Tue, 20 Oct 2020 03:55:58 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-prefix-originator-07.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 10:55:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : OSPF Prefix Originator Extensions Authors : Aijun Wang Acee Lindem Jie Dong Peter Psenak Ketan Talaulikar Filename : draft-ietf-lsr-ospf-prefix-originator-07.txt Pages : 9 Date : 2020-10-20 Abstract: This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospf-prefix-originator-07 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-prefix-originator-07 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 Oct 20 04:01:21 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208973A116A; Tue, 20 Oct 2020 04:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=C2lrfcqX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sAJlfY/S 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 sYatORQkGD1j; Tue, 20 Oct 2020 04:01:16 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA2D3A1166; Tue, 20 Oct 2020 04:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5912; q=dns/txt; s=iport; t=1603191676; x=1604401276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O3wFjHVbOkBz/iSHOnldS+CKOUP5mYGzCNGUZohbL2w=; b=C2lrfcqXsjFmkOtkU28fysnEf8y7djYHwBlMpijunEI9Cc1de7OREqgm dbA4MIsIFYYPq+4CD0VOldku3eE3PH2PPFnV1F4hPZOP/L8hb+li0XTdL JEcSsZpV5J0xZ2xV6meJ0PzJomaS4tncbdTvqAkuxtt2UXhKY5e7kbo3T E=; IronPort-PHdr: =?us-ascii?q?9a23=3AehJZqR2v96aYAdTNsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dmjFjRRZ6d7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkNVH97mfBvVuHLhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOBQDJwo5f/4sNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BUlEHcFkvLAqEM4NJA41SihCOaoFCgREDVQsBAQENAQE?= =?us-ascii?q?jCgIEAQGESgIXgW4CJTgTAgMBAQsBAQUBAQECAQYEbYVhDIVyAQEBAQIBEhE?= =?us-ascii?q?RDAEBKQ4BBAcEAgEIDgMEAQEBAgImAgICHxEVCAgCBAENBQgSCIMFgksDDiA?= =?us-ascii?q?BDqQwAoE5iGh2gTKDBAEBBYE3AoNyDQuCEAMGgQ4qgnKDcIEGhVAbgUE/gRF?= =?us-ascii?q?Dgk0+ghpCAQEDgToBAQYcgxUzgiyQDASDBgE9o1xUCoJqiQSMY4IjgwyDFoo?= =?us-ascii?q?NlDeTOYF8iHiCbZJTAgQCBAUCDgEBBYFrI4FXcBU7gmlQFwINjh8MF4NOhRS?= =?us-ascii?q?FQnQ4AgYBCQEBAwl8jDsBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.77,396,1596499200"; d="scan'208";a="567307627" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Oct 2020 11:01:06 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 09KB16jj009760 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2020 11:01:06 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Oct 2020 06:01:05 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 20 Oct 2020 07:01:05 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 20 Oct 2020 06:01:05 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QbRoJvq0neo05ELeH3z3llRIq7Er/J1gFl1j8KKjXpjvhm46SmGNdbMx/9L1i05ugeUmChSJSEEZdtp1nE3UKnpyTpdJMFq3BxL71d5fVyThhM6OuJO8fCs1WztBaegBOud70gwdOMOoC49rIkCsMZfBcf+cML8Bv7b9UZUHumFIyA/deqqxBxsR6MyX1P/27Op0ATVolARQ9br5uL/Ky7HM7Fobg0EAIgL8eEwI5W1YUf0wxjCyLG3m995tAnDwtQyRYKU5COC8wWE/SYOL3ZHmaBws6vIAJ6D2f77eyndV7OBAXN9G3kin5kcIMUDtEEcWQ2FwyKatIWmkovbCxA== 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=O3wFjHVbOkBz/iSHOnldS+CKOUP5mYGzCNGUZohbL2w=; b=AsAPNDKxjw6sfmEMMPrLBy+gmsDfvXxxYVuDUHLBaDY2NnPNo3FdAt4YasJYspoDa2DGWqGbVfk8NxbHeh6KUAlNTzcu53m7Knh+jtbm61gDdNdXxXHOXO5SvnK9DbW4TTvLc4+cKI7/+ZSAq6zZder+3epQF7NbBZ+yH+8jCtJMpw3n7XDyldcG8pGHB3sfbRLL6TdqTEg7ztAu9BNXlz6/Jf89dmomVbEQoDp3Bo8JFKdEQegV/wSlwR8DFYFUHQmks/Qzu+Tu1cMUOL9ospETJFa7nIq5b1BhjQghiNzZ/BX16D/2XBgYJpWROpf7egHXE5HewK3STO6ABP815w== 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=O3wFjHVbOkBz/iSHOnldS+CKOUP5mYGzCNGUZohbL2w=; b=sAJlfY/SY9HDYaW/GOTdUTNSwBz2X7cVPT0S0+wrAANluLyEkbD0QXARBuh8ilh9TpXNaBaSZLj7KFk6NC3blmw1K/ckcap53ueP3thNYPPhcyRrDf5bvV+dCna9uT/jXcjbdDPceAvXBF691mAiFIJMj+RzxPd01nfRr+WI5Tw= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1325.namprd11.prod.outlook.com (2603:10b6:300:1d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Tue, 20 Oct 2020 11:01:00 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3477.028; Tue, 20 Oct 2020 11:01:00 +0000 From: "Ketan Talaulikar (ketant)" To: Christian Hopps , Aijun Wang CC: "Les Ginsberg (ginsberg)" , John E Drake , "lsr-chairs@ietf.org" , "lsr@ietf.org" , Jeff Tantsura , "draft-ietf-lsr-ospf-prefix-originator@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 Thread-Index: AQHWorqoC1KYinwtxka4W6+KBPi+NqmY3FwAgAAhZgCAADD9AIAASXsAgABDC4CAADFWAIAFQlGAgAEsGpA= Date: Tue, 20 Oct 2020 11:00:59 +0000 Message-ID: References: <3E930E88-9404-4874-888B-881D022DFFEC@tsinghua.org.cn> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c3625f56-2db1-4d23-3167-08d874e76dc5 x-ms-traffictypediagnostic: MWHPR11MB1325: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Eotp6i/I9WELchy0kWXw8sJkE9kqjlb+kglvtv0zyzZKC0cyAo7Y7UAI4gCzjiDit0hHMBOYBNLfZrxnC7rmEWK69wlm0VF7AdFs6DRB7LPsfg6AJaw7XpG/8W8foEIcXmd62ugzxVyzE5/0E7yty8XL1Tr14O1l9ajA1hnLZmpc38AceSKoWaIWYUtYOsp2k94bSDcWcBre8X+LZgaOCbRonj1k6e7ZGvU7qoK6YgOaHQXn9l5shInrcyOWjrBWfLq4YKSN6ENPuvVJ22/sLGMzlLZHaj9sXUsBcXsAvYHqj9ZUDX62/hSUKVsyZH0chIpE1NFAqyjJn4GAvpDnu6f5XnP6ay0jPj+NokmZdLXOkRmK+QwjJOCXt1zdtKVEF1Ge51dZhIxhPKKd6WWBaQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39860400002)(346002)(136003)(396003)(366004)(26005)(8676002)(55016002)(66446008)(53546011)(6506007)(7696005)(9686003)(71200400001)(86362001)(33656002)(66476007)(66556008)(110136005)(83380400001)(54906003)(186003)(76116006)(4326008)(66946007)(52536014)(966005)(5660300002)(8936002)(478600001)(2906002)(64756008)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Fg3+ipw2HZnQaWhdfr7tUlZFYb6b16zojPoZQy4GGb7bZ3QT/vQSnkfMoc3aIsZ/ctvpUAFXKqikq0mIxydTnUE5YzNbuf7UjptDVyXE9qiDXY35r4ZQEJi5fAliXesSejTcq/crKbNTJEGl7OmB1gW5guf6JQplSklbLsomkTSHeZP+vZ2y5nhl1KqdYb+f3AG1Vs0hqogqHU++zNEtr/vSW0extJ78uAtyATdxTzyjdXu1LRLRLbI4lMsD4Vd2sLwpH3M4WoU5jjYUFIf6Oh9v8G4rIuzIvdsAHd8gyq6n4QwgrJIK48hD+WZg0bVLmeX17ZZtu1smChuIbXSp1H436V7zqtsWXJvgSate6GP23X8IBaFWlyZyOJ/J9h6+hp9OVji7T7dj2VoN3zqDLk9BwEZWGXo/X0aLKl1ZEWs6fxbVzbTJknh48wGq4gESPnHZ8JFGCEERiBgmF/ba9wX130NQLKgfc14p1dx7gydMx2uW6EZaWRVa+cfQnU2VnNRdriJjRQeKqgk1qrd/lUXZihJvQzQO102towz6pCZXXBFlT5l83RWOKBGKzMRvbskKuRSHugeRylQUwz6f3fjXW/8QnhzlV+e1leG5AzGt9qffvSwmwUaj24BwXjddLWvhphXGZvVQIecRV+pM6w== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3625f56-2db1-4d23-3167-08d874e76dc5 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 11:00:59.9493 (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: 3MpAyXN1e6G07Ve04bLi2cWRIoyfwjcuXxCsT0dYluZlGI5rwpwAUhAf9aYQFHnjIjyG/bMy1+1nx1IHwCEglw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1325 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 11:01:20 -0000 SGkgQ2hyaXMvQWxsLA0KDQpXZSd2ZSBqdXN0IHBvc3RlZCB0aGUgdjA3IG9mIHRoZSBkcmFmdCB3 aXRoIHRoZSBjb250ZW50aW91cyBhcHBlbmRpeCBzZWN0aW9ucyByZW1vdmVkIGFuZCBhbHNvIGFk ZHJlc3Npbmcgc29tZSBjb21tZW50cyByZWNlaXZlZCBvbiB0aGUgbGlzdC4NCg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3It MDcgDQoNClRoYW5rcywNCktldGFuIChvbiBiZWhhbGYgb24gY28tYXV0aG9ycykNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExzciA8bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBDaHJpc3RpYW4gSG9wcHMNClNlbnQ6IDE5IE9jdG9iZXIgMjAyMCAyMjozNw0K VG86IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1YS5vcmcuY24+DQpDYzogTGVzIEdpbnNi ZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbT47IEpvaG4gRSBEcmFrZSA8amRyYWtl QGp1bmlwZXIubmV0PjsgQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz47IGxzci1j aGFpcnNAaWV0Zi5vcmc7IGxzckBpZXRmLm9yZzsgSmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0 ZkBnbWFpbC5jb20+OyBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yQGlldGYu b3JnOyBsc3ItYWRzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0xzcl0gV0cgTGFzdCBDYWxsIGRy YWZ0LWlldGYtbHNyLW9zcGYtcHJlZml4LW9yaWdpbmF0b3ItMDYNCg0KDQoNCj4gT24gT2N0IDE2 LCAyMDIwLCBhdCA0OjQ3IEFNLCBBaWp1biBXYW5nIDx3YW5nYWlqdW5AdHNpbmdodWEub3JnLmNu PiB3cm90ZToNCj4gDQo+IEhpLCBMZXMgYW5kIGV4cGVydHMgaW4gTFNSOg0KPiANCj4gSSBhbSBv cGVuIHRvIHRoZSByZW1vdmFsIG9mIHRoZSB0aGlzIGFwcGVuZGl4IHRvIGZvcndhcmQgdGhpcyBk cmFmdC4NCg0KVGhhdCdzIGdvb2QgbmV3cywgdGhhbmsgeW91IEFpanVuLg0KDQpTcGVha2luZyBm b3IgdGhlIGNoYWlycywNCg0KV2UgYmVsaWV2ZSB3ZSBoYXZlIHJlYWNoZWQgV0cgY29uc2Vuc3Vz IChzZWVtcyBiZXR0ZXIgdGhhbiBqdXN0IHJvdWdoIGV2ZW4gd2l0aCBzb21lIGF1dGhvcnMgYXNr aW5nIGZvciB0aGUgY2hhbmdlKSBhdCB0aGlzIHBvaW50IG9uIHRoZSByZW1vdmFsIG9mIHRoZSBk aXNwdXRlZCB1c2UtY2FzZSBhcHBlbmRpY2VzLg0KDQpDb3VsZCB5b3UgcGxlYXNlIHJlcHVibGlz aCB0aGUgZG9jdW1lbnQgdy9vIHRoZSBkaXNwdXRlZCBzZWN0aW9ucz8NCg0KVGhhbmtzLA0KQ2hy aXMuDQoNCj4gQnV0IGFzIHN0YXRlZCBpbiBwcmV2aW91cyBtYWlsLCBwcm92aWRpbmcgdGhpcyBj YW4gYXNzaXN0IHRoZSB1c2VyL3JlYWRlciBvZiB0aGUgZHJhZnQuIFdlIG9mdGVuIGVuY291bnRl ciB0aGUgcXVlc3Rpb25zIGluIHRoZSBtYWlsIGxpc3QgdGhhdCB3aGF0IHRoZSB1c2FnZSBvZiBw cm90b2NvbC9iaXQgZGVmaW5pdGlvbiBpbiBzb21lIGRyYWZ0cy4NCj4gDQo+IEFjdHVhbGx5LCB3 ZSBkaWQgbm90IGV4cGFuZCB0aGUgZGlzY3Vzc2lvbiBvZiB0aGlzIHBhcnQgaW4gdGhpcyBkcmFm dC4gVGhlIGRlc2NyaXB0aW9uIG9mIHRoaXMgcGFydCBpcyB2ZXJ5IGNvbmNpc2UuDQo+IA0KPiBJ ZiB5b3UgaW5zaXN0IHRoaXMsIEkgY2FuIHVwZGF0ZSB0aGUgZHJhZnQgaW4gcmVjZW50IGRheXMs IHRvZ2V0aGVyIHdpdGggb3RoZXIgY29tbWVudHMgb24gdGhpcyBkcmFmdC4NCj4gDQo+IE90aGVy IGNvbW1lbnRzIGFyZSB3ZWxjb21lIGFsc28hDQo+IA0KPiBBaWp1biBXYW5nDQo+IENoaW5hIFRl bGVjb20NCj4gDQo+PiBPbiBPY3QgMTYsIDIwMjAsIGF0IDEzOjUxLCBMZXMgR2luc2JlcmcgKGdp bnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4g77u/QWlqdW4gLQ0K Pj4gDQo+PiBUaGUgcG9pbnQgSSBhbSBtYWtpbmcgaXMgdmVyeSBmb2N1c2VkLg0KPj4gDQo+PiBU aGlzIGRyYWZ0IGlzIGRlZmluaW5nIGEgcHJvdG9jb2wgZXh0ZW5zaW9uLiBBcyBzdWNoIGl0IGlz IG5lY2Vzc2FyeSB0aGF0IHRoaXMgYmUgU3RhbmRhcmRzIHRyYWNrIGFzIGFkaGVyaW5nIHRvIHRo ZSBub3JtYXRpdmUgc3RhdGVtZW50cyBpbiB0aGUgZHJhZnQgYXJlIG5lY2Vzc2FyeSBmb3IgaW50 ZXJvcGVyYWJpbGl0eS4NCj4+IA0KPj4gV2hhdCBpcyBkaXNjdXNzZWQgaW4gdGhlIEFwcGVuZGl4 IGlzIGEgdXNlIGNhc2UuIEl0IGlzIG5vdCBub3JtYXRpdmUgYW5kIHRoZXJlIGFyZSBzdHJvbmcg b3BpbmlvbnMgb24gYm90aCBzaWRlcyBhcyB0byB3aGV0aGVyIHRoaXMgaXMgYW4gYXBwcm9wcmlh dGUgdXNlIGNhc2Ugb3Igbm90Lg0KPj4gSW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkcmFmdCwgSSBo YXZlIG5vIGludGVyZXN0IGluIHRyeWluZyB0byByZXNvbHZlIG91ciBkaWZmZXJlbmNlIG9mIG9w aW5pb24gb24gdGhpcyB1c2UgY2FzZS4gSSBzaW1wbHkgd2FudCB0aGUgcHJvdG9jb2wgZXh0ZW5z aW9uIHRvIG1vdmUgZm9yd2FyZCBzbyB0aGF0IHdlIGhhdmUgYW5vdGhlciB0b29sIGF2YWlsYWJs ZS4NCj4+IA0KPj4gSWYgeW91IHdhbnQgdG8gd3JpdGUgYSBkcmFmdCBvbiB0aGUgdXNlIGNhc2Ug ZGlzY3Vzc2VkIGluIHRoZSBBcHBlbmRpeCBwbGVhc2UgZmVlbCBmcmVlIHRvIGRvIHNvLiBUaGF0 IGRyYWZ0IG1heSB2ZXJ5IHdlbGwgbm90IGJlIG5vcm1hdGl2ZSAtIEluZm9ybWF0aW9uYWwgb3Ig QkNQIG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlIC0gYmVjYXVzZSBpdCB3aWxsIGJlIGRpc2N1c3Np bmcgYSBkZXBsb3ltZW50IHNjZW5hcmlvIGFuZCBhIHByb3Bvc2FsIHRvIHVzZSBkZWZpbmVkIHBy b3RvY29sIGV4dGVuc2lvbnMgYXMgb25lIHdheSB0byBzb2x2ZSBwcm9ibGVtcyBpbiB0aGF0IGRl cGxveW1lbnQgc2NlbmFyaW8uIFN1Y2ggYSBkcmFmdCBtaWdodCBhbHNvIGJlIG1vcmUgYXBwcm9w cmlhdGUgaW4gYW5vdGhlciBXRyAoZS5nLiwgVEVBUykuIFRoZSBtZXJpdHMgb2YgdXNpbmcgcHJl Zml4IGFkdmVydGlzZW1lbnRzIHRvIGJ1aWxkIGEgdG9wb2xvZ3kgY291bGQgdGhlbiBiZSBkaXNj dXNzZWQgb24gaXRzIG93bi4NCj4+IA0KPj4gUGxlYXNlIGRvIG5vdCB0cnkgdG8gYXZvaWQgaGF2 aW5nIGEgZnVsbCBkaXNjdXNzaW9uIG9mIHRoZSBtZXJpdHMgb2YgdXNpbmcgcHJlZml4IGFkdmVy dGlzZW1lbnRzIHRvIGRlcml2ZSB0b3BvbG9neSBieSBhZGRpbmcgaXQgdG8gYSBkcmFmdCB0aGF0 IGlzIChhbmQgc2hvdWxkIGJlKSBmb2N1c2VkIG9uIHNpbXBsZSBwcm90b2NvbCBleHRlbnNpb25z Lg0KPj4gDQo+PiBUaGFueC4NCj4+IA0KPj4gIExlcw0KPj4gDQo+PiANCj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IEFpanVuIFdhbmcgPHdhbmdhaWp1bkB0c2luZ2h1 YS5vcmcuY24+DQo+Pj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTUsIDIwMjAgNjo1MSBQTQ0K Pj4+IFRvOiAnSmVmZiBUYW50c3VyYScgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPjsgJ0pvaG4g RSBEcmFrZScNCj4+PiA8amRyYWtlQGp1bmlwZXIubmV0Pg0KPj4+IENjOiAnQ2hyaXN0aWFuIEhv cHBzJyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBsc3ItY2hhaXJzQGlldGYub3JnOyBMZXMgDQo+Pj4g R2luc2JlcmcNCj4+PiAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb20+OyBsc3JAaWV0Zi5v cmc7IGxzci1hZHNAaWV0Zi5vcmc7IA0KPj4+IGRyYWZ0LWlldGYtIGxzci1vc3BmLXByZWZpeC1v cmlnaW5hdG9yQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUkU6IFtMc3JdIFdHIExhc3QgQ2FsbCAN Cj4+PiBkcmFmdC1pZXRmLWxzci1vc3BmLXByZWZpeC1vcmlnaW5hdG9yLTA2DQo+Pj4gDQo+Pj4g SGksIExlcywgSm9obiBhbmQgSmVmZjoNCj4+PiANCj4+PiBMZXQncyByZXBseSB5b3UgYWxsIHRv Z2V0aGVyLg0KPj4+IEluIG15IFBPViwgVGhlIHN0YW5kYXJkIGRvY3VtZW50IHNob3VsZCBub3Qg ZGVmaW5lIHNvbGVseSB0aGUgDQo+Pj4gcHJvdG9jb2wgZXh0ZW5zaW9uLCBidXQgdGhlaXIgdXNh Z2VzIGluIHRoZSBuZXR3b3JrIGRlcGxveW1lbnQuIEFzIEkgDQo+Pj4ga25vd24sIGFsbW9zdCBh bGwgdGhlIElFVEYgZG9jdW1lbnRzIGZvbGxvd2luZyB0aGlzIHN0eWxlLg0KPj4+IEFuZCwgYmVm b3JlIGFkb3B0aW5nIG9uZSB3b3JrLCB3ZSBoYXZlIG9mdGVuIGludGVuc2UgZGlzY3Vzc2lvbiBm b3IgDQo+Pj4gd2hhdCdzIHRoZWlyIHVzYWdlcy4NCj4+PiBTdWNoIGRpc2N1c3Npb24gaW4gdGhl IG1haWwgbGlzdCBhbmQgc3RhdGVtZW50cyBpbiB0aGUgZG9jDQo+IA0KDQo= From nobody Tue Oct 20 04:04:07 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F003A1176 for ; Tue, 20 Oct 2020 04:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.848 X-Spam-Level: X-Spam-Status: No, score=-9.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Roto_jy-8qb for ; Tue, 20 Oct 2020 04:04:04 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE793A117B for ; Tue, 20 Oct 2020 04:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9838; q=dns/txt; s=iport; t=1603191843; x=1604401443; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Ci9T38OV3dfTe6ofxaoyISNOPYNHLIM8L0FP8a2dJ5s=; b=f/5F67zGjTa6607nPVTAfun0YtE3J18gAmGnns6QCfp3Nk2bJj06Hg+e StsY9XzugsPMkRZVaYNkvWlPoPxUT2EYOd1kakMoRg3yT3EaWQtMw980H kCsT1vj7GYv07Qr4Kssp4Y7c2rF6qidSYDFoxjPJ50DX79aGvZG08wQ7N 0=; X-IPAS-Result: =?us-ascii?q?A0AXBAAjw45f/xbLJq1gHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DGlUBIBIshD2JBYdsCCaaPIFpCwEBAQ8YCwwEAQGESgKCBiY4EwIDAQEBA?= =?us-ascii?q?wIDAQEBAQUBAQECAQYEbYVhDIVyAQEBAQIBAQEhFTYJDgQLEQQBAQECAiMDA?= =?us-ascii?q?gInHwkIBgEMBgIBAYMiAYJcIA+uWnaBMoRSQUSDToFCgQ4qjVOBQT+BEScMg?= =?us-ascii?q?V9+PoJcAQECAQGBJgESAU2Ca4JfBJAQCoptgRmKR5EZgnSDFoVukWQFBwMfg?= =?us-ascii?q?xaBKohjhSCMZIIzkzmKdJVogWsjZ3AzGggbFRohgmkJRxkNjisXg06FFIVEP?= =?us-ascii?q?wMwAjYCBgoBAQMJjkgBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,396,1596499200"; d="scan'208";a="28060483" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Oct 2020 11:03:59 +0000 Received: from [10.147.24.30] ([10.147.24.30]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 09KB3wFi025133; Tue, 20 Oct 2020 11:03:59 GMT To: bruno.decraene@orange.com, Ron Bonica , "lsr@ietf.org" References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <5770_1603126349_5F8DC44D_5770_187_4_53C29892C857584299CBF5D05346208A48FC0918@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <0f958743-3709-83cc-6e7f-8bb5d5746bc5@cisco.com> <15498_1603187037_5F8EB15D_15498_303_1_53C29892C857584299CBF5D05346208A48FC2194@OPEXCAUBM43.corporate.adroot.infra.ftgroup> From: Peter Psenak Message-ID: <4df4a0a5-171f-2781-27a7-5fc99c9c90d4@cisco.com> Date: Tue, 20 Oct 2020 13:03:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <15498_1603187037_5F8EB15D_15498_303_1_53C29892C857584299CBF5D05346208A48FC2194@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.147.24.30, [10.147.24.30] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 11:04:07 -0000 Bruno, please see inline: On 20/10/2020 11:43, bruno.decraene@orange.com wrote: > Peter, > >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> >> Bruno, >> >> On 19/10/2020 18:52, bruno.decraene@orange.com wrote: >>> Ron, all, >>> >>> >From a use case standpoint, I have a use case for having both SR-MPLS and >> IP flexalgo in the same network. >>> >>> >From a protocol standpoint, I think that the functionality could be equally >> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit >> null) to instruct the LER/LSR to not use a label in the forwarding plane. (while >> still advertising a label in the control plane because we have to). >> >> does not work, > > I could provide more explanations, but reading your email, it seems to me that you understood the proposal. > So it seems to me that the opinion that you really meant is: it works but it would be an nasty hack. > > Regarding "nasty hack" it could be interesting to have a normative definition. This could prove useful in some other contexts. > BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the label in the NLRI... max-metric does not solve the problem, as you would need a prefix metric for non 0 algo anyway. > > > Coming back to technical comments, note that creating yet another TLV to carry IP prefix also brings questions that the draft does not answer or even raise. > - What about the sub-TLVs? Are they shared with the existing registry for prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier (we would have two algo fields, two ways to signal SIDs...) yes, these are details that needs to be addressed, but should not be a problem. Look at locator TLV in SRv6, very similar concept here. > - for IPv6, the content and meaning of "ISIS MT IPv6 Flexalgo Prefix Reachability TLV" is essentially the same than the "SRv6 Locator TLV". > - Only the naming and the ordering of the fields are different. > - Why do we need two TLVs to advertise the same thing (essentially a Routing Algo)? Duplication means more spec, more code, more features to implement, more error and bugs. (and it did not took long: the draft defines the MTID field as 8 bits while RFC 5120 defines it a 12 bits. well, locator is a construct that is specific to SRv6. Sure you can advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs and achieve the same thing - I have already mentioned that in one of my responses, but that is again ugly. > - What is the functional different between FlexAlgo for SRv6 and FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the IPv6 FIB in the router. they are functionally the same. I believe that having a clean encoding is preferable in a long run. One can not advertise a prefix as SRv6 locator as well as IP flex-algo prefix (that would be an error), so duplication of data is not an issues. And having a dedicated TLV for each is better from both deployment and implementation perspective. thanks, Peter > > Thanks, > Bruno > >> as it does not allow you to associate the prefix with >> Flex-algo without advertising the reachability in algo 0. Making the >> prefix reachability in default algo conditional based on the presence of >> the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack. >> >> Not to mention that advertising a Prefix SID in pure IP network would be >> ugly. >> >> thanks, >> Peter >> >> >> >>> I feel that this would be less change in the protocol (no new tlv), a good fit >> for network requiring both MPLS and IP flex algo, and would not require >> implementations/network operator to duplicate the "prefix sub-TLV" [1] on >> both advertisements (IP based and SR-MPLS based). >>> >>> That would still requires a protocol extension/STD track RFC as RFC 8667 >> does not allow for this. That would still require change to implementations as >> only the signalling is different while the feature/behavior is the same (i.e. no >> magic). >>> >>> Regards, >>> --Bruno >>> >>> [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, >> MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)" >>> >>> >>>> -----Original Message----- >>>> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Ron Bonica >>>> Sent: Tuesday, September 29, 2020 3:38 PM >>>> To: lsr@ietf.org >>>> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip- >> flexalgo- >>>> 00.txt >>>> >>>> >>>> Please review and comment >>>> >>>> Ron >>>> >>>> >>>> >>>> Juniper Business Use Only >>>> >>>>> -----Original Message----- >>>>> From: internet-drafts@ietf.org >>>>> Sent: Tuesday, September 29, 2020 9:36 AM >>>>> To: Parag Kaneriya ; Shraddha Hegde >>>>> ; Ron Bonica ; Rajesh M >>>>> ; William Britto A J >>>>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt >>>>> >>>>> [External Email. Be cautious of content] >>>>> >>>>> >>>>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt >>>>> has been successfully submitted by Ron Bonica and posted to the IETF >>>>> repository. >>>>> >>>>> Name: draft-bonica-lsr-ip-flexalgo >>>>> Revision: 00 >>>>> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks >>>>> Document date: 2020-09-29 >>>>> Group: Individual Submission >>>>> Pages: 14 >>>>> URL: https://urldefense.com/v3/__https://www.ietf.org/id/draft- >>>> bonica- >>>>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- >>>>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ >>>>> Status: >>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- >>>> bonica-lsr- >>>>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- >>>>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ >>>>> Htmlized: >>>>> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- >>>>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- >>>>> >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ >>>>> Htmlized: >>>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft- >>>>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- >>>>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ >>>>> >>>>> >>>>> Abstract: >>>>> An IGP Flexible Algorithm computes a constraint-based path and maps >>>>> that path to an identifier. As currently defined, Flexalgo can only >>>>> map the paths that it computes to Segment Routing (SR) identifiers. >>>>> Therefore, Flexalgo cannot be deployed in the absence of SR. >>>>> >>>>> This document extends Flexalgo, so that it can map the paths that it >>>>> computes to IP addresses. This allows Flexalgo to be deployed in any >>>>> IP network, even in the absence of SR. >>>>> >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> The IETF Secretariat >>>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> >> __________________________________________________________ >> __________________________________________________________ >> _____ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce >> message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete >> this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > > From nobody Tue Oct 20 05:17:40 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791A83A005E for ; Tue, 20 Oct 2020 05:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 53oYZtz4PEsq for ; Tue, 20 Oct 2020 05:17:35 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id DB3833A003F for ; Tue, 20 Oct 2020 05:17:32 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.92:5682.1336753422 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-111.193.138.173?logid-01d86bc29fcf4f3db484f94c7d2376f7 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 68FFF28008E; Tue, 20 Oct 2020 20:17:19 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.92]) by App0021 with ESMTP id 01d86bc29fcf4f3db484f94c7d2376f7 for huaimo.chen@futurewei.com; Tue Oct 20 20:17:26 2020 X-Transaction-ID: 01d86bc29fcf4f3db484f94c7d2376f7 X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.92 X-MEDUSA-Status: 0 Sender: xiechf@chinatelecom.cn Date: Tue, 20 Oct 2020 20:17:25 +0800 From: "Xie Chongfeng" To: huaimo.chen , lsr X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 166[cn] Mime-Version: 1.0 Message-ID: <202010202017253015704@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart802630242534_=----" Archived-At: Subject: Re: [Lsr] draft-xie-lsr-isis-sr-vtn-mt-02 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 12:17:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart802630242534_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 DQpIaSBIdWFpbW8sDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4gUGxlYXNl IHNlZSBzb21lIHJlcGxpZXMgaW5saW5lOg0KIA0KDQpGcm9tOiBMc3IgW21haWx0bzpsc3ItYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEh1YWltbyBDaGVuDQpTZW50OiBNb25kYXksIE9j dG9iZXIgMTksIDIwMjAgMTE6MDkgUE0NClRvOiBsc3JAaWV0Zi5vcmcNClN1YmplY3Q6IFtMc3Jd IGRyYWZ0LXhpZS1sc3ItaXNpcy1zci12dG4tbXQtMDINCiANCkhpIEF1dGhvcnMsDQogDQogICAg SSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMvcXVlc3Rpb25zOg0KIA0KSW4gYSBuZXR3b3Jr LCBjYW4gd2UgdXNlIG90aGVyIG1ldGhvZHMgdG8gZGVmaW5lIFZUTnMgd2hpbGUgTVRzIGFyZSB1 c2VkIGFzIFZUTnM/IA0KIA0KW0Nob25nZmVuZ10gQXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1l bnQsIGluIHNvbWUgbmV0d29yayBzY2VuYXJpb3MsIGVhY2ggVlROIGNhbiBoYXZlIGFuIGluZGVw ZW5kZW50IHRvcG9sb2d5IGFuZCBhIHNldCBvZiBkZWRpY2F0ZWQgbmV0d29yayByZXNvdXJjZXMu IEluIGEgbmV0d29yayB3aGljaCBtZWV0cyB0aGlzIHNjZW5hcmlvLCB1c2luZyBNVHMgdG8gaWRl bnRpZnkgVlROcyBpcyBhIHByYWN0aWNhbCBhcHByb2FjaC4gT3RoZXIgYXBwcm9hY2hlcyBtYXkg YWxzbyBiZSBwb3NzaWJsZSwgd2hpbGUgdGhleSBhcmUgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50LiBVc2luZyBtb3JlIHRoYW4gb25lIGFwcHJvYWNoIGluIGEgbmV0d29yayBpcyBu b3QgbmVjZXNzYXJ5IHRodXMgbm90IHJlY29tbWVuZGVkLg0KIA0KSWYgc28sIG90aGVyIG1ldGhv ZHMgbWF5IGJlIHVzZWQgdG8gZGVmaW5lIFZUTnMgaW4gYWRkaXRpb24gdG8gdXNpbmcgTVRzIGFz IFZUTnMgaW4gdGhlIHNhbWUgbmV0d29yay4gVGhlIGRyYWZ0IHNheXMgdGhhdCBNVC1JRCBjb3Vs ZCBiZSB1c2VkIGFzIFZUTi1JRC4gSW4gdGhpcyBjYXNlLCBhIGJsb2NrIG9mIFZUTi1JRHMgbXVz dCBiZSBhbGxvY2F0ZWQvcmVzZXJ2ZWQgc3BlY2lhbGx5IGZvciB1c2luZyBNVC1JRHMgYXMgVlRO LUlEcy4gSXQgc2VlbXMgYmV0dGVyIHRvIHN0YXRlIHNvbWV0aGluZyBhYm91dCB0aGlzIGluIHRo ZSBkcmFmdC4NCiANCltDaG9uZ2ZlbmddIEkgYXNzdW1lIHRoaXMgcXVlc3Rpb24gaXMgYmFzZWQg b24gdGhlIKGwdHJ1ZaGxIGFuc3dlciB0byB0aGUgY29tbWVudCBhYm92ZS4gU2luY2UgaXQgaXMg Y29uc2lkZXJlZCB0byBvbmx5IHVzZSBvbmUgYXBwcm9hY2ggaW4gYSBuZXR3b3JrLCBhbmQgdGhp cyBkb2N1bWVudCBhY3R1YWxseSBkb2VzIG5vdCBpbnRyb2R1Y2UgobBWVE4tSUShsSB0byBJUy1J UywgSU1PIHJlc2VydmluZyBhIGJsb2NrIG9mIFZUTi1JRCBzZWVtcyBub3QgcmVsZXZhbnQgdG8g dGhpcyBkb2N1bWVudC4NCiAgICAgDQpBbiBJUy1JUyBNVCBoYXMgdGhlIGF0dHJpYnV0ZXMgb2Yg YSBWVE4sIGluY2x1ZGluZyB0aGUgc3BlY2lmaWMgdG9wb2xvZ3kgYW5kIHJlc291cmNlLiBBbiBJ Uy1JUyBNVCBjYW4gYmUgdXNlZCBhcyBhIFZUTiBhbmQgTVQtSUQgY2FuIGJlIHVzZWQgYXMgYSBW VE4gSUQuIElzIGl0IHBvc3NpYmxlIGZvciBhbiBJUy1JUyBNVCB0byBiZSB1c2VkL3NoYXJlZCBi eSB0d28gb3IgbW9yZSBWVE5zPyBJZiBzbywgaXQgc2VlbXMgYmV0dGVyIHRvIGhhdmUgc29tZSBk ZXRhaWxzIGFib3V0IGhvdyB0aGUgbXVsdGlwbGUgVlROcyB1c2Uvc2hhcmUgdGhlIHJlc291cmNl IGluIHRoZSBzYW1lIG9uZSBNVC4gDQogDQpbQ2hvbmdmZW5nXSBUaGUgcHJlc3VtcHRpb24gb2Yg dXNpbmcgTVQtSUQgdG8gaWRlbnRpZnkgVlROcyBpcyB0aGF0IGRpZmZlcmVudCBWVE5zIGFyZSBp ZGVudGlmaWVkIGJ5IGRpZmZlcmVudCBNVC1JRHMsIHRodXMgc2hhcmluZyBvZiBvbmUgTVQgYmV0 d2VlbiBkaWZmZXJlbnQgVlROcyBpcyBub3QgYWxsb3dlZCBpbiB0aGlzIGRvY3VtZW50LiBGb3Ig c3VjaCBzaGFyaW5nIG1lY2hhbmlzbSB5b3UgbWF5IHJlZmVyIHRvIG90aGVyIGRvY3VtZW50cyBp biB0aGUgV0cuIA0KIA0KSW4gc2VjdGlvbiA1ICJTY2FsYWJpbGl0eSBDb25zaWRlcmF0aW9ucyIs IHRoZSBkcmFmdCBzYXlzIHRoYXQgd2hpbGUgbXVsdGlwbGUgVlROcyBzaGFyZSB0aGUgc2FtZSB0 b3BvbG9neSBhdHRyaWJ1dGUsIHRoZSBzYW1lIHRvcG9sb2d5IGlzIGlkZW50aWZpZWQgYnkgbXVs dGlwbGUgZGlmZmVyZW50IE1ULUlEcy4gVGhpcyBzZWVtcyBnaXZpbmcgYSB3YXkgdG8gbGV0IHR3 byBvciBtb3JlIFZUTnMgdG8gdXNlL3NoYXJlIG9uZSBNVCBpZiBJUy1JUyBNVCBhbGxvd3MgbXVs dGlwbGUgTVQtSURzIHRvIGJlIHVzZWQgZm9yIHRoZSBzYW1lIG9uZSBNVC4gSXQgc2VlbXMgYmV0 dGVyIHRvIG1vdmUgdGhlIHJlbGF0ZWQgdGV4dCBmcm9tIHNlY3Rpb24gNSB0byBzb21lIG9mIHRo ZSBwcmV2aW91cyBzZWN0aW9ucy4NCiANCltDaG9uZ2ZlbmddIFRoZSBzY2FsYWJpbGl0eSBjb25z aWRlcmF0aW9ucyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgcG90ZW50aWFsIGxpbWl0YXRpb25zIG9m IHRoZSBNVCBiYXNlZCBhcHByb2FjaCBpbiBzY2FsYWJpbGl0eS4gU2luY2UgZWFjaCBWVE4gaXMg aWRlbnRpZmllZCBieSBhIHVuaXF1ZSBNVC1JRCwgaW5kZXBlbmRlbnQgcGF0aCBjb21wdXRhdGlv biB3b3VsZCBiZSBuZWVkZWQgZm9yIGVhY2ggVlROLCBldmVuIGlmIG11bHRpcGxlIFZUTnMgaGFz IHRoZSBzYW1lIHRvcG9sb2d5IGF0dHJpYnV0ZSAodGhleSBhcmUgc3RpbGwgaWRlbnRpZmllZCBi eSBkaWZmZXJlbnQgTVQtSURzKS4gRm9yIGV4YW1wbGUsIE1ULXggYW5kIE1ULXkgYXJlIHVzZWQg dG8gaWRlbnRpZnkgdHdvIFZUTnMsIHRoZSB0b3BvbG9neSBvZiB0aGVtIG1heSBiZSB0aGUgc2Ft ZSwgYnV0IHRoZSBwYXRoIGNvbXB1dGF0aW9uIHN0aWxsIG5lZWRzIHRvIGJlIGRvbmUgZm9yIE1U LVggYW5kIE1ULVkgc2VwYXJhdGVseS4gU2hhcmluZyB0aGUgY29tcHV0YXRpb24gb3ZlcmhlYWQg YW1vbmcgbXVsdGlwbGUgVlROcyBpcyBkaXNjdXNzZWQgaW4gb3RoZXIgZG9jdW1lbnQsIHdoaWNo IHJlcXVpcmVzIHNvbWUgcHJvdG9jb2wgZXh0ZW5zaW9ucyBhbmQgaXMgb3V0IG9mIHRoZSBzY29w ZSBvZiB0aGlzIGRvY3VtZW50Lg0KIA0KSG9wZSB0aGlzIGhlbHBzIHRvIGNsYXJpZnkgeW91ciBx dWVzdGlvbnMuIFRoYW5rcy4gDQogDQpCZXN0IFJlZ2FyZHMsDQpIdWFpbW8NCg== ------=_001_NextPart802630242534_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable

This is simple BIS u= pdate to RFC 5316 is required to support IS-IS Inter-AS TE in IPv6 only netw= orks. The authors have asked for WG adoption.

 

This begins a two we= ek LSR Working Group Adoption Poll for =E2=80=9CISIS Extensions in Support o= f Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering=E2=80=9D -= draft-chen-lsr-isis-rfc5316bis-02. The poll will end at 12:00 AM UTC on November 7th, 2020. Please indicate your s= upport of objection on this list prior to the end of the adoption poll.=

 

Thanks,

Acee

 

_______________________________________________
Lsr ma= iling list
Lsr@ietf.org
https://www.ietf.org= /mailman/listinfo/lsr
= --Apple-Mail-C135F7B6-442A-439D-AE0D-C140495EF0C8-- From nobody Sat Oct 24 10:19:08 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4EE3A0EF2 for ; Sat, 24 Oct 2020 10:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=previdi-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op_yPmIjRy2C for ; Sat, 24 Oct 2020 10:19:03 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 D92323A0EF1 for ; Sat, 24 Oct 2020 10:19:02 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id l15so6291874wmi.3 for ; Sat, 24 Oct 2020 10:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=previdi-net.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fJoLCQ8X27Pu5Mc6ZDPbC0k8SShr9w+zXigJX0wBTFc=; b=U4/uw89HxWoifqMmTFf5I5Z8qADwMSPDz8wr1EP6cBFyDKmMduZyCIxV+eZ3/WoKF9 e+KV0gW32jS+aUr5UxcOy09HyCaTwRUtCU3/ukxG6GqTi+EhY91QzHHBb27NfO1pqrWq U2W6tw7tYQuH51K21SsEcrSB9CKXYjohbLU/+pfwkmd34d3P9oI7bzEUKnJb8aC2YpyY udOo+ArZp6OblmN/z3Oko2aumnpryZ3SUhniJYfVJwCvYQI+Kg92gdnicp9JJKqGZpDw aqrj9+TJyE06kb6+NKlU9ZOB8lOoOoDP4rIJnXYK3iSXwolKvYv2Xqn5cmVC+mEm8u9v jM4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fJoLCQ8X27Pu5Mc6ZDPbC0k8SShr9w+zXigJX0wBTFc=; b=fiyOeHn3uW9dm1pNVAiMuM5ruz0YlQCwMYoPb4FD9ziHVLO3LOywovfuQZOht7FcpI PDRX8vVluTUyULEDh30c4jdiPzroDVKSXXpwZNQFL4QQ/F/hDR2t4UqI9d0zlo/N4jTx dEs1qVKVU+skhTt2aMA2qr2cQqoJty8RPylK0lU82X8VZvUjhz8Ar0neCDhmfz+OYYQA v+Pq016KGX+EoGF4UTi1/GgA5JYd+iMZh3y4fYh97R8iO461/phMhXI86cvD8Zu+EIm6 ShexIGIxNL1qvwxmeDdPEHqkicGfURiBVKrGXf0QoUNIS8QO4iZOJdOXQZEPiYtmKJNO Hemg== X-Gm-Message-State: AOAM530jTFrSfSB3fh2CSV914KO4JyOCI/osb5WmP3ripTQR9MrsQg3v qmGIxY2MCJ5coL9EHSEEzOpwLg== X-Google-Smtp-Source: ABdhPJypjdraeV58/jXCddCYl2QW84Nawq2fvDTvPH+fkAmhDWSlGbE9E78OBr8nACm+XK61ko1I+g== X-Received: by 2002:a1c:7d0f:: with SMTP id y15mr7652181wmc.84.1603559940607; Sat, 24 Oct 2020 10:19:00 -0700 (PDT) Received: from pc.home (host-79-56-104-60.retail.telecomitalia.it. [79.56.104.60]) by smtp.gmail.com with ESMTPSA id v189sm10996982wmg.14.2020.10.24.10.18.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 24 Oct 2020 10:18:58 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: stefano previdi In-Reply-To: <74E40EE9-BAA9-4712-928E-C4ACE65728DC@cisco.com> Date: Sat, 24 Oct 2020 19:19:01 +0200 Cc: "lsr@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6559FE67-3F54-4090-8B5D-C5B8427A5132@previdi.net> References: <74E40EE9-BAA9-4712-928E-C4ACE65728DC@cisco.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 17:19:05 -0000 Hi, as co-author, I support the adoption of = draft-chen-lsr-isis-rfc5316bis-02. Thanks. s. > On Oct 23, 2020, at 4:42 PM, Acee Lindem (acee) = wrote: >=20 > This is simple BIS update to RFC 5316 is required to support IS-IS = Inter-AS TE in IPv6 only networks. The authors have asked for WG = adoption. > =20 > This begins a two week LSR Working Group Adoption Poll for =E2=80=9CISIS= Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS = Traffic Engineering=E2=80=9D - draft-chen-lsr-isis-rfc5316bis-02. The = poll will end at 12:00 AM UTC on November 7th, 2020. Please indicate = your support of objection on this list prior to the end of the adoption = poll. > =20 > Thanks, > Acee > =20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Sat Oct 24 11:16:39 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ABE3A0FD7 for ; Sat, 24 Oct 2020 11:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 M6VTvIGexp90 for ; Sat, 24 Oct 2020 11:16:36 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 EB2833A0FD4 for ; Sat, 24 Oct 2020 11:16:35 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id r1so2668978vsi.12 for ; Sat, 24 Oct 2020 11:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sGc82OmemzzQXqXgEUMrSQIzwttXZWlEtcj1U88s2jw=; b=iVxUXwBwWiP05SwWEZHHRHsTHhnSLAl8Q15605bfZp34I2+MU0VBgX1AxdXWM2VsC/ HDXfsJmfKFPYXGRDnhty4mO8qvTkxp6m0y4rc2UP7ATW2YWvixRsmEqdLRiO60fSbpF2 1pJjibh92y1Ih452G3iLRCegYf6m7AKy1AK6oNBpbsO09Q20BfRszszxNYKRy21D15mN PYkETV185YMkZt+O5FlvQrNHFO6c6iecu6aujGWksp0/teWlRS4HYm4uhWrBebnDgI5x L79lswoGOoPYQkBjE70jJ/ZD7JMTYpty6QhhAG8bmglJHNmu+xNeZakgmc0kWu+Fmhot jN6g== 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=sGc82OmemzzQXqXgEUMrSQIzwttXZWlEtcj1U88s2jw=; b=Gm9vSZw9BNLgaWdlTJjdIqt60nCkomZGXgTpdydKRpoGOo/282tGp82XmKqCWx4wGF heWwz5qV8TqS2iJF+aiCrYaL51o2DrohctWVa5VLlojdXDZb9rulbfHzDkwxOQwpD1xM Iy/dqtT9igaA+4VNk+pQ4eNgB0tnL2Y+p4cN2jYp+eXG2VjHIDw+u74PmaP/TihEqRdW eM2CJSnVrpoq3V+930iGGWwrrP/LaCnraskaY+IldhkuvZ558CFK8d6jY8Ke1WfIeZXZ WeoplaRWC2YpnzSbbBK6tScpeYh7BZAtvFr+5D4YpM3c0KRu0o95NuSbfnm5NHvYQwbQ r9Cg== X-Gm-Message-State: AOAM532JFEkMxSBHUGfv4TAcmXdJQr05TFYfWw/QjcopEbdJz5hh0KYw VqVnk0QozwCYSj7Z+liOt58z4h+Cn25oDlPaNejRUahX/aL8Ig== X-Google-Smtp-Source: ABdhPJxJF+tY6KNvKa2LKngjUJUYx1sOWAygaK6D50hGVPMCqeZVcloHUR+AGDCqgGym63TwiFKxjiL/unCLFm6bWSw= X-Received: by 2002:a67:6f06:: with SMTP id k6mr5186585vsc.20.1603563394769; Sat, 24 Oct 2020 11:16:34 -0700 (PDT) MIME-Version: 1.0 References: <74E40EE9-BAA9-4712-928E-C4ACE65728DC@cisco.com> <6559FE67-3F54-4090-8B5D-C5B8427A5132@previdi.net> In-Reply-To: <6559FE67-3F54-4090-8B5D-C5B8427A5132@previdi.net> From: Gyan Mishra Date: Sat, 24 Oct 2020 14:10:12 -0400 Message-ID: To: stefano previdi Cc: "Acee Lindem (acee)" , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="00000000000085283105b26eb2ba" Archived-At: Subject: Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 18:16:38 -0000 --00000000000085283105b26eb2ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support WG Adoption. Thanks Gyan On Sat, Oct 24, 2020 at 1:19 PM stefano previdi wrote= : > Hi, > > as co-author, I support the adoption of draft-chen-lsr-isis-rfc5316bis-02= . > > Thanks. > s. > > > > On Oct 23, 2020, at 4:42 PM, Acee Lindem (acee) 40cisco.com@dmarc.ietf.org> wrote: > > > > This is simple BIS update to RFC 5316 is required to support IS-IS > Inter-AS TE in IPv6 only networks. The authors have asked for WG adoption= . > > > > This begins a two week LSR Working Group Adoption Poll for =E2=80=9CISI= S > Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS > Traffic Engineering=E2=80=9D - draft-chen-lsr-isis-rfc5316bis-02. The pol= l will end > at 12:00 AM UTC on November 7th, 2020. Please indicate your support of > objection on this list prior to the end of the adoption poll. > > > > Thanks, > > Acee > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000085283105b26eb2ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I support WG Adoption.

T= hanks

Gyan

On Sat, Oct 24, 2020 at 1:19 PM st= efano previdi <stefano@previdi.ne= t> wrote:
Hi,

as co-author, I support the adoption of draft-chen-lsr-isis-rfc5316bis-02.<= br>
Thanks.
s.


> On Oct 23, 2020, at 4:42 PM, Acee Lindem (acee) <acee=3D40cisco.com@dmarc.ietf= .org> wrote:
>
> This is simple BIS update to RFC 5316 is required to support IS-IS Int= er-AS TE in IPv6 only networks. The authors have asked for WG adoption.
>=C2=A0
> This begins a two week LSR Working Group Adoption Poll for =E2=80=9CIS= IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Tra= ffic Engineering=E2=80=9D - draft-chen-lsr-isis-rfc5316bis-02. The poll wil= l end at 12:00 AM UTC on November 7th, 2020. Please indicate your support o= f objection on this list prior to the end of the adoption poll.
>=C2=A0
> Thanks,
> Acee
>=C2=A0
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


--

Gyan Mishra

Network Solutions A= rchitect=C2= =A0

M 301 502-1347
13101 Columbia= Pike=C2=A0
Silver Spring, MD


<= /div>
--00000000000085283105b26eb2ba-- From nobody Sat Oct 24 12:16:40 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27F83A1083 for ; Sat, 24 Oct 2020 12:16:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VdWkaken; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tJGXdVFz 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 vOgs_5bP6Y0l for ; Sat, 24 Oct 2020 12:16:37 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6F63A107F for ; Sat, 24 Oct 2020 12:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6745; q=dns/txt; s=iport; t=1603566997; x=1604776597; h=from:to:subject:date:message-id:mime-version; bh=51or0T8g664t02fto3NR5l3z4hHj9tsl/fr+Fk6ldH4=; b=VdWkaken/OJ1S14mOwPuuL80tIp/3xH088lm1fH/bvRJpeSLFg2ZJcrW o1pwvjlSjJxhl/YJpxb4WhZYkCBVbgRP4TuLgcejU58APGVxroVQe24Y4 Itt7Tn9DsLl6RDjzYrZt1p9LluCUysUzuP13VvYdiG1jlcQe1WO7IlOPZ M=; IronPort-PHdr: =?us-ascii?q?9a23=3As13eBxbjDQvLInVHkgyIWTX/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QWVD4ne4uhPzevbr66mXnYPst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8XG35CQZXB?= =?us-ascii?q?TyKQQzIf76Scbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0nx?= =?us-ascii?q?DIuXBPPe9RwDBl?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtCgCsfJRf/5JdJa1gg3svUQdwWS8?= =?us-ascii?q?sCoQyg0kDjUaUC4RvglMDVQsBAQENAQEtAgQBAYRKGYFyAiU4EwIDAQELAQE?= =?us-ascii?q?FAQEBAgEGBG2FYQyFcgEDAxILBh0BATgRAQgRAwECJAcCBDAdCgQBEiKDBAG?= =?us-ascii?q?Bfk0DLgGlTAKBO4hodoEygwQBAQWFGRiCEAmBOIJyg3CGVxuCAIEQASccgk0?= =?us-ascii?q?+glwEgX0GgnEzgiyTVocUnSAKgmqaeQMfgxeKDZQ6hgGNPIF9njsCBAIEBQI?= =?us-ascii?q?OAQEFgWsjgVdwFTsqAYI+UBcCDY5WgzqKVnQCNgIGAQkBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,413,1596499200"; d="scan'208,217";a="607237365" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Oct 2020 19:16:36 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 09OJGaxW008754 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 24 Oct 2020 19:16:36 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 24 Oct 2020 14:16:35 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 24 Oct 2020 14:16:35 -0500 Received: from NAM11-BN8-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.1497.2 via Frontend Transport; Sat, 24 Oct 2020 15:16:34 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UHQgANZ4AOhYnTO9nfx5gPYzlRT2dRojEuZdD03WmbCajAsx9up07R9SxX9svgn1IW9TZ13cjZz9Ct3X+O1LiAZ5qSepcZwkg5bhhzuFkIb4il3htVb1HudPsaQAJfzK6Nnp6RYPEyEO5AeKsv9TOIOkRSx/HcyGOqjEn7NPWKte8nvA9LhEeW7C5Zrw8OtfkCl/2D37Kd/eeh0S6OEZNuwAU45wLedMfHW3OFmqavpT4anipsdeSVQjRI5vJnKg6b955RJzF/QhXZh0gXBWfnP1Wa5zUg1qqYlbryasdxmZE59Md+ipCZgVDhWShcfy6rVBbkwElUABXzUL1kd2mw== 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=51or0T8g664t02fto3NR5l3z4hHj9tsl/fr+Fk6ldH4=; b=GB/opjjM00fdOJ0NBsLBaiwZ/7ljzeJdE9DEILYU3fWjF4lS6nJB9oO8CZsCzuwxHFnLd8adFwPti/hi7Dcw5Kq8qoo503w+VmbS/znU+l+P79ol7nkY6Xk9rytjAUR2yv2e9HeC3wAYuEP+O2aOp96kqRvvbVwfU2/QtGMaXWLL/riheGJ5CE0e26v4orejrOsm0K74FUgzQc2mG75PE3+XJkT8D4KTOmK6g7zltcWfo7da0vHeJG4A5fYZVLorQNirDFJJMuIJA7xi/SsEk3uz7+Rty6ZkvPDk6ogj7gtptySwG3n6AVbnLZerm+idGvIQltuAoZb0kV1DyJoA1A== 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=51or0T8g664t02fto3NR5l3z4hHj9tsl/fr+Fk6ldH4=; b=tJGXdVFzbOxjKSaHm76Jemn5sO5LceKm3bTd0Ubp56sHBflk+WRXg+cOt0lZuOt2zLz/7m1aBPJVbcMnRqLKmVaDcm586QAmyYqv069nYr2TyQFj++zNLVlshHrGCl/V98RyLLmAI7ydGDpi11AcJ+exgruJW3hKCCpSJlyLtrg= Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3797.namprd11.prod.outlook.com (2603:10b6:a03:fe::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Sat, 24 Oct 2020 19:16:33 +0000 Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::1ddc:cdb4:32cc:f078%3]) with mapi id 15.20.3477.028; Sat, 24 Oct 2020 19:16:33 +0000 From: "Acee Lindem (acee)" To: "Acee Lindem (acee)" , "lsr@ietf.org" Thread-Topic: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02 Thread-Index: AQHWqjovO1YtU2NLCUOhWA/LMtUxAw== Date: Sat, 24 Oct 2020 19:16:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.133.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f0fe549-9307-4218-bb78-08d878515214 x-ms-traffictypediagnostic: BYAPR11MB3797: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yqn8IT2hQdBUur8bCI7Zkg0fHj6q9q4aoWPmcBtBdMGN4FXCwihS+GcFPrsyi04zBgfHVYNagCCV1RMjennTtmVYiiPB32xJ4K8FIxOxGiiu5U7EAYECh9AMeyn7Zt1ZDa3Qk1BpCckKFqqzLaTLv0RBF74YIFcZzm46gvZKAsqH1XsnW/ElD5sm4WmN2sQYDLctNC53zV/LIxBsj7ZKd7TZZvoKeNRcB+XXlHoFvh88imS81VuS8JZWnmB2m3hO5v4x3nMrjo+Bge0EqEmUJcaMtg6X38QN69WFYkrVPp3kNEElOdh32JY0UsglAKeZdmeDapZvqv+XeE5Eg0fDiw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(39860400002)(346002)(376002)(366004)(5660300002)(6486002)(6512007)(53546011)(186003)(26005)(4744005)(6506007)(71200400001)(76116006)(66476007)(83380400001)(66446008)(2616005)(64756008)(36756003)(478600001)(8676002)(316002)(2906002)(86362001)(66556008)(33656002)(8936002)(66946007)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EryICkCyOA4Gs6rUxpkN6Il7xG9ypPcfGQOMWpMVSWzom6Ltd0Rztleh837ffp4p1e4mM3vZuI62091aKZz7TUNaEW4F2KsL0cX6VszP5i+J24I4G12M0JbJfjFJl2gUNZZMs7DGMytxVS6CoRoVikzuYYShoZAlWxlJMTcQ1EQNXr3SMicRB5iAntEDgq4J8jeqC9kn9Q4ibbHStpiXkz3wJNn7I5hAHtF1kYUSoz1SXXZkn2piy6EYd92psUd9ilZN4ANKJbiJMbCWmRxmiBu94np/t134Ro9PSHgcHaL0RjTy846U04evUzneSE3312HaCAON9AkN/32xl/qPckQe6X8UJSCMWF6S527kyOPRQMSG3lKSHzkPL+lJKEti6wdn9Ve4ep3NLxp9PWqvJuA9O5FYpt/tbiied8XTePbPT3i3p4Isnl3OBBCUduzLJ/OVYGEINMRzxrSlkiVCnUhT8jT9dNUryQvBgSVoNGYXuG9UTMV6o9PJR3rKgWK7mOcrEr8fRdJzKMis+3h7Tg1nrzad6KNOEPTAZrqHG7/TjtOz3Aoxb2au7iBPi085T7Yq0sBVOhjH+iELsDmk6f08x/G8sP0qH0LdZRVr3aQiwIJY1UJlol+/5QaX9+8DeT6sPdpjy/XxbeNJubLV4g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AAA6570E9CA247EBA278F0607E737DF9ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f0fe549-9307-4218-bb78-08d878515214 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2020 19:16:33.6870 (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: iVq1kSCL9iayZy6QcQYkRFPRfgcnz3jTy5OwYNObF/aqTWxABBtyggz6Y3u3/Xnc X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3797 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 19:16:39 -0000 --_000_AAA6570E9CA247EBA278F0607E737DF9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlYWtpbmcgYXMgYSBXRyBtZW1iZXI6DQoNCkkgc3VwcG9ydCBXRyBhZG9wdGlvbiBvZiB0aGlz IGRyYWZ0Lg0KDQpUaGFua3MsDQpBY2VlDQoNCkZyb206IExzciA8bHNyLWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZT00MGNpc2NvLmNvbUBk bWFyYy5pZXRmLm9yZz4NCkRhdGU6IEZyaWRheSwgT2N0b2JlciAyMywgMjAyMCBhdCAxMDo0MyBB TQ0KVG86ICJsc3JAaWV0Zi5vcmciIDxsc3JAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTHNyXSBXRyBB ZG9wdGlvbiBDYWxsIGZvciAiSVNJUyBFeHRlbnNpb25zIGluIFN1cHBvcnQgb2YgSW50ZXItQVMg TVBMUyBhbmQgR01QTFMgVEUiIC0gZHJhZnQtY2hlbi1sc3ItaXNpcy1yZmM1MzE2YmlzLTAyDQoN ClRoaXMgaXMgc2ltcGxlIEJJUyB1cGRhdGUgdG8gUkZDIDUzMTYgaXMgcmVxdWlyZWQgdG8gc3Vw cG9ydCBJUy1JUyBJbnRlci1BUyBURSBpbiBJUHY2IG9ubHkgbmV0d29ya3MuIFRoZSBhdXRob3Jz IGhhdmUgYXNrZWQgZm9yIFdHIGFkb3B0aW9uLg0KDQpUaGlzIGJlZ2lucyBhIHR3byB3ZWVrIExT UiBXb3JraW5nIEdyb3VwIEFkb3B0aW9uIFBvbGwgZm9yIOKAnElTSVMgRXh0ZW5zaW9ucyBpbiBT dXBwb3J0IG9mIEludGVyLUF1dG9ub21vdXMgU3lzdGVtIChBUykgTVBMUyBhbmQgR01QTFMgVHJh ZmZpYyBFbmdpbmVlcmluZ+KAnSAtIGRyYWZ0LWNoZW4tbHNyLWlzaXMtcmZjNTMxNmJpcy0wMi4g VGhlIHBvbGwgd2lsbCBlbmQgYXQgMTI6MDAgQU0gVVRDIG9uIE5vdmVtYmVyIDd0aCwgMjAyMC4g UGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBvZiBvYmplY3Rpb24gb24gdGhpcyBsaXN0IHBy aW9yIHRvIHRoZSBlbmQgb2YgdGhlIGFkb3B0aW9uIHBvbGwuDQoNClRoYW5rcywNCkFjZWUNCg0K --_000_AAA6570E9CA247EBA278F0607E737DF9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5TcGVha2luZyBhcyBhIFdHIG1lbWJlcjo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgc3VwcG9ydCBXRyBhZG9wdGlvbiBvZiB0aGlzIGRy YWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5BY2VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkxzciAmbHQ7bHNy LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtBY2VlIExpbmRlbSAoYWNl ZSkmcXVvdDsgJmx0O2FjZWU9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPkZyaWRheSwgT2N0b2JlciAyMywgMjAyMCBhdCAxMDo0MyBBTTxicj4NCjxiPlRv OiA8L2I+JnF1b3Q7bHNyQGlldGYub3JnJnF1b3Q7ICZsdDtsc3JAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPltMc3JdIFdHIEFkb3B0aW9uIENhbGwgZm9yICZxdW90O0lTSVMgRXh0 ZW5zaW9ucyBpbiBTdXBwb3J0IG9mIEludGVyLUFTIE1QTFMgYW5kIEdNUExTIFRFJnF1b3Q7IC0g ZHJhZnQtY2hlbi1sc3ItaXNpcy1yZmM1MzE2YmlzLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBpcyBzaW1wbGUgQklTIHVw ZGF0ZSB0byBSRkMgNTMxNiBpcyByZXF1aXJlZCB0byBzdXBwb3J0IElTLUlTIEludGVyLUFTIFRF IGluIElQdjYgb25seSBuZXR3b3Jrcy4gVGhlIGF1dGhvcnMgaGF2ZSBhc2tlZCBmb3IgV0cgYWRv cHRpb24uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBiZWdpbnMg YSB0d28gd2VlayBMU1IgV29ya2luZyBHcm91cCBBZG9wdGlvbiBQb2xsIGZvciDigJxJU0lTIEV4 dGVuc2lvbnMgaW4gU3VwcG9ydCBvZiBJbnRlci1BdXRvbm9tb3VzIFN5c3RlbSAoQVMpIE1QTFMg YW5kIEdNUExTIFRyYWZmaWMgRW5naW5lZXJpbmfigJ0gLSBkcmFmdC1jaGVuLWxzci1pc2lzLXJm YzUzMTZiaXMtMDIuDQogVGhlIHBvbGwgd2lsbCBlbmQgYXQgMTI6MDAgQU0gVVRDIG9uIE5vdmVt YmVyIDc8c3VwPnRoPC9zdXA+LCAyMDIwLiBQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IG9m IG9iamVjdGlvbiBvbiB0aGlzIGxpc3QgcHJpb3IgdG8gdGhlIGVuZCBvZiB0aGUgYWRvcHRpb24g cG9sbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWNlZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AAA6570E9CA247EBA278F0607E737DF9ciscocom_-- From nobody Sat Oct 24 17:04:51 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14ED3A117C for ; Sat, 24 Oct 2020 17:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 RG9iLYPNpSte for ; Sat, 24 Oct 2020 17:04:46 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1A86D3A117B for ; Sat, 24 Oct 2020 17:04:44 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.218:63674.1278304163 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-113.68.88.126?logid-0e9d74219b5a41efa1d4296a0889b01a (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 2F3162800C2; Sun, 25 Oct 2020 08:04:30 +0800 (CST) X-189-SAVE-TO-SEND: 44093218@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id 0e9d74219b5a41efa1d4296a0889b01a for w0197526@chinatelecom.cn; Sun Oct 25 08:04:34 2020 X-Transaction-ID: 0e9d74219b5a41efa1d4296a0889b01a X-filter-score: filter<0> X-Real-From: chenhuan6@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Sender: chenhuan6@chinatelecom.cn Date: Sun, 25 Oct 2020 08:04:37 +0800 From: "chenhuan6@chinatelecom.cn" To: =?UTF-8?B?5pyx5rC45bqGQGNoaW5hdGVsZWNvbQ==?= , "lsr@ietf.org" References: <159981543873.27279.16517423794827557547@ietfa.amsl.com>, <000201d68bf0$842e5850$8c8b08f0$@chinatelecom.cn> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.18.95[cn] Mime-Version: 1.0 Message-ID: <2020102508033633047934@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart313851811627_=----" Archived-At: Subject: Re: [Lsr] =?utf-8?b?5Zue5aSNOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-zhu-lsr-isis-sr-vtn-flexalgo-01=2Etxt?= X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 00:04:50 -0000 This is a multi-part message in MIME format. ------=_001_NextPart313851811627_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgYXV0aG9ycywNCiANCknigJl2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50LiAgVGhlIGRyYWZ0 IHByb3ZpZGVzIGEgdXNlZnVsIG1lY2hhbmlzbSB0byBlbmFibGUgVlROcyBiYXNlZCBvbiBtaW5v ciBleHRlbnNpb25zIHRvIEZsZXgtQWxnbyBhbmQgTDIgYnVuZGxlLg0KIA0KT25lIGNvbW1lbnQg aXM6IGluIG9uZSBuZXR3b3JrLCBjYW4gc29tZSBGbGV4LUFsZ29zIGJlIHVzZWQgZm9yIGl0cyB0 cmFkaXRpb25hbCB1c2FnZSwgYW5kIHNvbWUgb3RoZXIgRmxleC1BbGdvcyBiZSB1c2VkIGZvciBW VE5zIGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50Pw0KIA0KQlIuDQoNCkh1YU5hbg0KIA0K 5Y+R5Lu25Lq677yaIHpodXlxOEBjaGluYXRlbGVjb20uY24NCuWPkemAgeaXtumXtO+8miAyMDIw LTA5LTE2IDE0OjEzDQrmlLbku7bkurrvvJogbHNyQGlldGYub3JnDQrkuLvpopjvvJogW0xzcl0g 5Zue5aSNOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpodS1sc3ItaXNpcy1z ci12dG4tZmxleGFsZ28tMDEudHh0DQpIaSBXRywNCiANCldlIGp1c3Qgc3VibWl0dGVkIGEgbmV3 IHJldmlzaW9uIG9mIGRyYWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFsZ28uIFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGEgbWVjaGFuaXNtIHRvIHVzZSBGbGV4LUFsZ28gdG9nZXRoZXIgd2l0 aCBzbWFsbCBleHRlbnNpb25zIHRvIElTLUlTIEwyIGJ1bmRsZSB0byBkaXN0cmlidXRlIHRoZSB0 b3BvbG9neSBhbmQgcmVzb3VyY2UgYXR0cmlidXRlIG9mIFNSIGJhc2VkIFZUTi4gWW91ciByZXZp ZXcgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCkIuUi4NClpodSBZb25ncWluZw0KIA0K LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCuWPkemAgeaXtumXtDogMjAyMOW5tDnmnIgx MeaXpSAxNzoxMQ0K5pS25Lu25Lq6OiBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5j b20+OyBZb25ncWluZyBaaHUgPHpodXlxOEBjaGluYXRlbGVjb20uY24+OyBIdXpoaWJvIDxodXpo aWJvQGh1YXdlaS5jb20+DQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtemh1LWxzci1pc2lzLXNyLXZ0bi1mbGV4YWxnby0wMS50eHQNCiANCiANCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC16aHUtbHNyLWlzaXMtc3ItdnRuLWZsZXhhbGdvLTAxLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWUgRG9uZyBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQogDQpOYW1lOiAgICAgICAgICAgZHJhZnQtemh1LWxzci1pc2lz LXNyLXZ0bi1mbGV4YWxnbw0KUmV2aXNpb246ICAgICAgIDAxDQpUaXRsZTogICAgICAgICAgVXNp bmcgRmxleC1BbGdvIGZvciBTZWdtZW50IFJvdXRpbmcgYmFzZWQgVlRODQpEb2N1bWVudCBkYXRl OiAgMjAyMC0wOS0xMQ0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFn ZXM6ICAgICAgICAgIDgNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC16aHUtbHNyLWlzaXMtc3ItdnRuLWZsZXhhbGdvLTAxLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpodS1sc3ItaXNpcy1zci12 dG4tZmxleGFsZ28vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC16aHUtbHNyLWlzaXMtc3ItdnRuLWZsZXhhbGdvDQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpodS1sc3ItaXNpcy1zci12 dG4tZmxleGFsZ28tMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtemh1LWxzci1pc2lzLXNyLXZ0bi1mbGV4YWxnby0wMQ0KIA0KQWJzdHJh Y3Q6DQogICBBcyBkZWZpbmVkIGluIEktRC5pZXRmLXRlYXMtZW5oYW5jZWQtdnBuLCBlbmhhbmNl ZCBWUE4gKFZQTispIGFpbXMgdG8NCiAgIHByb3ZpZGUgZW5oYW5jZWQgVlBOIHNlcnZpY2UgdG8g c3VwcG9ydCB0aGUgbmVlZHMgb2YgZW5oYW5jZWQNCiAgIGlzb2xhdGlvbiBhbmQgc3RyaW5nZW50 IHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cy4gIFZQTisgcmVxdWlyZXMNCiAgIGludGVncmF0aW9u IGJldHdlZW4gdGhlIG92ZXJsYXkgVlBOIGFuZCB0aGUgdW5kZXJsYXkgbmV0d29yay4gIEENCiAg IFZpcnR1YWwgVHJhbnNwb3J0IE5ldHdvcmsgKFZUTikgaXMgYSB2aXJ0dWFsIG5ldHdvcmsgd2hp Y2ggY29uc2lzdHMNCiAgIG9mIGEgc3Vic2V0IG9mIG5ldHdvcmsgdG9wb2xvZ3kgYW5kIG5ldHdv cmsgcmVzb3VyY2VzIGFsbG9jYXRlZCBmcm9tDQogICB0aGUgdW5kZXJsYXkgbmV0d29yay4gIEEg VlROIGNvdWxkIGJlIHVzZWQgYXMgdGhlIHVuZGVybGF5IGZvciBvbmUgb3INCiAgIGEgZ3JvdXAg b2YgVlBOKyBzZXJ2aWNlcy4NCiANCiAgIEktRC5kb25nLWxzci1zci1lbmhhbmNlZC12cG4gZGVm aW5lcyB0aGUgSUdQIG1lY2hhbmlzbXMgd2l0aA0KICAgbmVjZXNzYXJ5IGV4dGVuc2lvbnMgdG8g YnVpbGQgYSBzZXQgb2YgU2VnbWVudCBSb3V0aW5nIChTUikgYmFzZWQNCiAgIFZUTnMuICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhIHNpbXBsaWZpZWQgbWVjaGFuaXNtIHRvIGJ1aWxkIHRoZSBT Ug0KICAgYmFzZWQgVlROcyB1c2luZyBTUiBGbGV4LUFsZ28gdG9nZXRoZXIgd2l0aCBtaW5vciBl eHRlbnNpb25zIHRvIElHUA0KICAgTDIgYnVuZGxlLg0KIA0KIA0KIA0KIA0KIA0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KIA0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCiANCiANCiAN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMc3IgbWFp bGluZyBsaXN0DQpMc3JAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbHNyDQo= ------=_001_NextPart313851811627_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
=

Hi authors,

 

I=E2=80=99ve reviewed= this document.  The draft provides a useful mechanism to enable VTNs= based on minor extensions to Flex-Algo and L2 bundle.

 

One= comment is: in one network, can some Flex-Algos be used for its tradition= al usage, and some other Flex-Algos be used for VTNs as described in this = document?

 

<= p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; text-align: justi= fy; font-size: 14px; font-family: Calibri, sans-serif; line-height: normal= ;">BR.


HuaNan

=0A
 
=E5=8F=91=E4=BB=B6=E4=BA= =BA=EF=BC=9A zhuyq8@chi= natelecom.cn
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC= =9A 2020-09-16 14:13
=E6=94=B6=E4=BB=B6=E4=BA= =BA=EF=BC=9A lsr@ietf.org
=E4=B8=BB=E9=A2=98=EF=BC=9A [Lsr] =E5=9B=9E=E5=A4=8D: N= ew Version Notification for draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
Hi WG,
=0A
 
=0A
We just sub= mitted a new revision of draft-zhu-lsr-isis-sr-vtn-flexalgo. This document= specifies a mechanism to use Flex-Algo together with small extensions to = IS-IS L2 bundle to distribute the topology and resource attribute of SR ba= sed VTN. Your review and comments are appreciated.
=0A
B.R.
= =0A
Zhu Yongqing
=0A
 
=0A
-----=E9=82=AE=E4=BB= =B6=E5=8E=9F=E4=BB=B6-----
=0A
=E5=8F=91=E4=BB=B6=E4=BA=BA: inter= net-drafts@ietf.org <internet-drafts@ietf.org>
=0A
=E5=8F= =91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B49=E6=9C=8811=E6=97=A5 17:11=0A
=E6=94=B6=E4=BB=B6=E4=BA=BA: Dongjie (Jimmy) <jie.dong@huaw= ei.com>; Yongqing Zhu <zhuyq8@chinatelecom.cn>; Huzhibo <huzhi= bo@huawei.com>
=0A
=E4=B8=BB=E9=A2=98: New Version Notificatio= n for draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
=0A
 
= =0A
 
=0A
A new version of I-D, draft-zhu-lsr-isis-sr-vt= n-flexalgo-01.txt
=0A
has been successfully submitted by Jie Dong= and posted to the IETF repository.
=0A
 
=0A
Name:=            draft-zhu-lsr= -isis-sr-vtn-flexalgo
=0A
Revision:     =   01
=0A
Title:       &nb= sp;  Using Flex-Algo for Segment Routing based VTN
=0A
Docum= ent date:  2020-09-11
=0A
Group:    &nbs= p;     Individual Submission
=0A
Pages: =          8
=0A
URL: =            https://www.i= etf.org/id/draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
=0A
Status:&= nbsp;        https://datatracker.ietf.o= rg/doc/draft-zhu-lsr-isis-sr-vtn-flexalgo/
=0A
Htmlized: &nb= sp;     https://datatracker.ietf.org/doc/html/draft-zh= u-lsr-isis-sr-vtn-flexalgo
=0A
Htmlized:    &= nbsp;  https://tools.ietf.org/html/draft-zhu-lsr-isis-sr-vtn-flexalgo= -01
=0A
Diff:        &nbs= p;  https://www.ietf.org/rfcdiff?url2=3Ddraft-zhu-lsr-isis-sr-vtn-fle= xalgo-01
=0A
 
=0A
Abstract:
=0A
 &nb= sp; As defined in I-D.ietf-teas-enhanced-vpn, enhanced VPN (VPN+) aims to<= /div>=0A
   provide enhanced VPN service to support the need= s of enhanced
=0A
   isolation and stringent performanc= e requirements.  VPN+ requires
=0A
   integration = between the overlay VPN and the underlay network.  A
=0A
&nb= sp;  Virtual Transport Network (VTN) is a virtual network which consi= sts
=0A
   of a subset of network topology and network = resources allocated from
=0A
   the underlay network.&n= bsp; A VTN could be used as the underlay for one or
=0A
 &nb= sp; a group of VPN+ services.
=0A
 
=0A
  = ; I-D.dong-lsr-sr-enhanced-vpn defines the IGP mechanisms with
=0A   necessary extensions to build a set of Segment Routing (SR)= based
=0A
   VTNs.  This document describes a sim= plified mechanism to build the SR
=0A
   based VTNs usi= ng SR Flex-Algo together with minor extensions to IGP
=0A
 &= nbsp; L2 bundle.
=0A
 
=0A
 
=0A
&nbs= p;
=0A
 
=0A
 
=0A
Please note that i= t may take a couple of minutes from the time of submission until the htmli= zed version and diff are available at tools.ietf.org.
=0A
 <= /div>=0A
The IETF Secretariat
=0A
 
=0A
 <= /div>=0A
 
=0A
_________________________________________= ______
=0A
Lsr mailing list
=0A
Lsr@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/lsr
=0A
=0A= ------=_001_NextPart313851811627_=------ From nobody Sun Oct 25 06:22:10 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666CE3A08A9 for ; Sun, 25 Oct 2020 06:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 OlXj7YG531-Y for ; Sun, 25 Oct 2020 06:22:06 -0700 (PDT) Received: from sendg.mailex.chinaunicom.cn (sendg.mailex.chinaunicom.cn [210.53.66.230]) by ietfa.amsl.com (Postfix) with ESMTP id 648883A0888 for ; Sun, 25 Oct 2020 06:22:05 -0700 (PDT) X-AuditID: 0a000f34-27dff70000002278-0b-5f957bfb6039 Received: from M10-HQ-MLCEN04.cnc.intra (Unknown_Domain [10.249.212.34]) by sendg.mailex.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id EE.23.08824.BFB759F5; Sun, 25 Oct 2020 21:22:03 +0800 (HKT) Received: from M10-HQ-ML03.hq.cnc.intra (10.249.213.73) by M10-HQ-MLCEN04.cnc.intra (10.249.212.34) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 25 Oct 2020 21:22:03 +0800 Received: from M10-HQ-ML02.hq.cnc.intra (10.249.213.72) by M10-HQ-ML03.hq.cnc.intra (10.249.213.73) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 25 Oct 2020 21:21:59 +0800 Received: from M10-HQ-ML02.hq.cnc.intra ([fe80::1fb:119c:ef1:d250]) by M10-HQ-ML02.hq.cnc.intra ([fe80::1fb:119c:ef1:d250%20]) with mapi id 15.00.1497.006; Sun, 25 Oct 2020 21:21:59 +0800 From: =?utf-8?B?UmFuIFBhbmco6IGU6YCa6ZuG5Zui5Lit5Zu96IGU6YCa56CU56m26ZmiLQ==?= =?utf-8?B?5pys6YOoKQ==?= To: Xie Chongfeng , lsr Thread-Topic: [Lsr] Fw: New Version Notification for draft-xie-lsr-isis-sr-vtn-mt-02.txt Thread-Index: AQHWqs5yXuILbpKweEW3xsZu3AiP2g== Date: Sun, 25 Oct 2020 13:21:59 +0000 Message-ID: <3ec18770721647dc8bc84ab846f52052@M10-HQ-ML02.hq.cnc.intra> References: <2020101417321319345959@chinatelecom.cn> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [222.129.131.54] Content-Type: multipart/alternative; boundary="_000_3ec18770721647dc8bc84ab846f52052M10HQML02hqcncintra_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsXC9fOKku7v6qnxBteOKVuceLKC1eLzWzUH Jo97t4I9liz5yRTAFMVlk5Kak1mWWqRvl8CVsfzPZ6aCdYsZK1beucXWwNgwn7GLkZNDQsBE YsaMQyxdjFwcQgLnGSVO/pvNCuHsYJTYNfkaI5yzfHYjVGY/o8TFSefAetgEmhglTnxfzwQy TETATqLz22NWEFtYIFJi0bP1zBDxKInFjSvZIWw9ieNHV4HVswioSpw49h6ohoODV8Bdomut KEhYCOimL8d2gLUyCshKTHt0H6ycWUBcYu60WawQdwtILNlznhnCFpV4+fgfVNxAYuvSfSwQ tpLEwpt7GUHGMwtkS1y/agYS5hUQlDg58wkLxCpliebj01knMIrNQrJhFkLHLCQdEGFNifW7 9CGqFSWmdD9kh7A1JFrnzGVHFl/AyL6KUTLY193C2MJA199ILzkjMy+xNC8zOT9XLzlvEyMo Hhn4TXYw3rv1Qe8QIxMH4yFGCQ5mJRHeOTJT44V4UxIrq1KL8uOLSnNSiw8xSnOwKInzpnOs ihMSSE8sSc1OTS1ILYLJMnFwSjUwBU4UuLq+cz/j3EnBT/LcO57db1u8gfUo06YLbk8sJPzY Bc61vuU7YWy4tWGLyuJJ/zdx3le+e3TZJ+fddRMvJuRIVm1/aXb6Wxpn3lEWwRlRMnE8Ntoi Nooe7Ol8NnvWuc547X/lxP0569sNZrjd/Xx1e5Lsh2aXo/UTWaf9UJrU63bH6Hj+I6N1J9UZ 3nX7L6vaX1Xk88XW9Zyl6YdNy19d2Gpg2cF4dZGhcod73v/Ihz7fE6eyJIbeMV01Oc+pll9+ 65QbuTOYHv1vPrxjYq5t0PzzHZzdmi8W7bv63jTnXmibW2E9s9X2e1vjn1zUe1Iu7Zr902FS 5N/1xyezxvL0XigPEHDcelV83Z8vX5VYijMSDbWYi4oTAWcddkM2AwAA Archived-At: Subject: Re: [Lsr] Fw: New Version Notification for draft-xie-lsr-isis-sr-vtn-mt-02.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 13:22:09 -0000 --_000_3ec18770721647dc8bc84ab846f52052M10HQML02hqcncintra_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQXV0aG9ycywNCiAgICBJIGFncmVlIHRoYXQgSUdQIE11bHRpLXRvcG9sb2d5IGNhbiBiZSB1 c2VkIHRvIHByb3ZpZGUgdGhlIHJlcXVpcmVkIGZ1bmN0aW9uYWxpdHkgdG8gYnVpbGQgY3VzdG9t aXplZCBWVE5zIHRvIG1lZXQgZGlmZmVyZW50IHNlcnZpY2UgcmVxdWlyZW1lbnRzLiBBbiBpbmZv cm1hdGlvbiBkb2N1bWVudCBsaWtlIHRoaXMgaXMgdXNlZnVsLg0KICAgIEkgaGF2ZSBvbmUgY29t bWVudO+8mg0KICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBtZWNoYW5pc20gdG8gYWR2 ZXJ0aXNlIGJhbmR3aWR0aCBhdHRyaWJ1dGUgZm9yIGVhY2ggVlROLCBjYW4gb3RoZXIgdHlwZXMg b2YgbGluayBhdHRyaWJ1dGVzIGJlIGN1c3RvbWl6ZWQgZm9yIGRpZmZlcmVudCBWVE5zPyBUaGFu a3MuDQoNCkJlc3QgcmVnYXJkcywNClBhbmcgUmFuDQoNCkZyb206IFhpZSBDaG9uZ2Zlbmc8bWFp bHRvOnhpZWNoZkBjaGluYXRlbGVjb20uY24+DQpEYXRlOiAyMDIwLTEwLTE0IDE3OjMyDQpUbzog bHNyPG1haWx0bzpsc3JAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTHNyXSBGdzogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAyLnR4dA0KDQpI aSwgV0csDQoNCg0KDQpXZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LXhp ZS1sc3ItaXNpcy1zci12dG4tbXQgdG8gcmVzb2x2ZSB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZHVy aW5nIGFuZCBhZnRlciBsYXN0IElFVEYgbWVldGluZy4gVGhlIGNoYW5nZXMgYXJlOg0KDQoNCg0K MS4gQmFzZWQgb24gdGhlIHN1Z2dlc3Rpb25zIG9uIElFVEYgbWVldGluZywgdGhlIGRvY3VtZW50 IHR5cGUgaXMgY2hhbmdlZCB0byBpbmZvcm1hdGlvbmFsLg0KDQogMi4gQWRkIHNvbWUgZGVzY3Jp cHRpb25zIGFib3V0IHRoZSBvcGVyYXRpb25zIGluIGZvcndhcmRpbmcgcGxhbmUuDQoNCiAzLiBB ZGQgcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtc3ByaW5nLXJlc291cmNlLWF3YXJlLXNlZ21lbnRz LCB3aGljaCBpbnRyb2R1Y2VzIHRoZSBtZWNoYW5pc20gdG8gYXNzb2NpYXRlIFNSIFNJRHMgd2l0 aCBkaWZmZXJlbnQgc3Vic2V0IG9mIHJlc291cmNlcy4NCg0KIDQuIFNvbWUgZWRpdG9yaWFsIGNo YW5nZXMuDQoNCg0KDQpEdXJpbmcgdGhlIHByZXNlbnRhdGlvbiBvbiBsYXN0IElFVEYgbWVldGlu ZywgYXV0aG9ycyBhc2tlZCBXRyB0byBjb25zaWRlciB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1 bWVudC4gU2luY2UgdGhpcyB2ZXJzaW9uIHJlc29sdmVzIGFsbCB0aGUgY29tbWVudHMgc28gZmFy IGFuZCB0aGUgY29udGVudCBpcyBnZXR0aW5nIHN0YWJsZSwgYXV0aG9ycyB3b3VsZCBsaWtlIHRv IHNvbGljaXQgV0cgYWRvcHRpb24gcG9sbCBvbiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KUmV2aWV3 IGFuZCBjb21tZW50cyBhcmUgYWx3YXlzIHdlbGNvbWUuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoN Cg0KQ2hvbmdmZW5nDQoNCg0KDQoNCkZyb206IGludGVybmV0LWRyYWZ0czxtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPg0KRGF0ZTogMjAyMC0xMC0xMyAxNDo1OQ0KVG86IEppZSBEb25n PG1haWx0bzpqaWUuZG9uZ0BodWF3ZWkuY29tPjsgQ2hlbmhhbyBNYTxtYWlsdG86bWFjaGhAY2hp bmF0ZWxlY29tLmNuPjsgWmhlbmJpbiBMaTxtYWlsdG86bGl6aGVuYmluQGh1YXdlaS5jb20+OyBD aG9uZ2ZlbmcgWGllPG1haWx0bzp4aWVjaGZAY2hpbmF0ZWxlY29tLmNuPg0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAy LnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteGllLWxzci1pc2lzLXNyLXZ0bi1t dC0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmllIERvbmcgYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogZHJhZnQteGllLWxzci1p c2lzLXNyLXZ0bi1tdA0KUmV2aXNpb246IDAyDQpUaXRsZTogVXNpbmcgSVMtSVMgTXVsdGktVG9w b2xvZ3kgKE1UKSBmb3IgU2VnbWVudCBSb3V0aW5nIGJhc2VkIFZpcnR1YWwgVHJhbnNwb3J0IE5l dHdvcmsNCkRvY3VtZW50IGRhdGU6IDIwMjAtMTAtMTMNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NClBhZ2VzOiA4DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJj aGl2ZS9pZC9kcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAyLnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpZS1sc3ItaXNpcy1z ci12dG4tbXQvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10DQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXhpZS1sc3ItaXNpcy1zci12dG4tbXQtMDIN CkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt eGllLWxzci1pc2lzLXNyLXZ0bi1tdC0wMg0KDQpBYnN0cmFjdDoNCiAgIEVuaGFuY2VkIFZQTiAo VlBOKykgYXMgZGVmaW5lZCBpbiBJLUQuaWV0Zi10ZWFzLWVuaGFuY2VkLXZwbiBhaW1zIHRvDQog ICBwcm92aWRlIGVuaGFuY2VkIFZQTiBzZXJ2aWNlIHRvIHN1cHBvcnQgc29tZSBhcHBsaWNhdGlv bidzIG5lZWRzIG9mDQogICBlbmhhbmNlZCBpc29sYXRpb24gYW5kIHN0cmluZ2VudCBwZXJmb3Jt YW5jZSByZXF1aXJlbWVudHMuICBWUE4rDQogICByZXF1aXJlcyBpbnRlZ3JhdGlvbiBiZXR3ZWVu IHRoZSBvdmVybGF5IFZQTiBhbmQgdGhlIHVuZGVybGF5DQogICBuZXR3b3JrLiAgQSBWaXJ0dWFs IFRyYW5zcG9ydCBOZXR3b3JrIChWVE4pIGlzIGEgdmlydHVhbCBuZXR3b3JrDQogICB3aGljaCBj b25zaXN0cyBvZiBhIHN1YnNldCBvZiB0aGUgbmV0d29yayB0b3BvbG9neSBhbmQgbmV0d29yaw0K ICAgcmVzb3VyY2VzIGFsbG9jYXRlZCBmcm9tIHRoZSB1bmRlcmxheSBuZXR3b3JrLiAgQSBWVE4g Y291bGQgYmUgdXNlZA0KICAgYXMgdGhlIHVuZGVybGF5IGZvciBvbmUgb3IgYSBncm91cCBvZiBW UE4rIHNlcnZpY2VzLg0KDQogICBJLUQuZG9uZy1sc3Itc3ItZW5oYW5jZWQtdnBuIGRlZmluZXMg dGhlIElHUCBleHRlbnNpb25zIHRvIGJ1aWxkIGENCiAgIHNldCBvZiBTZWdtZW50IFJvdXRpbmcg KFNSKSBiYXNlZCBWVE5zLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYQ0KICAgc2ltcGxpZmll ZCBtZWNoYW5pc20gdG8gYnVpbGQgdGhlIFNSIGJhc2VkIFZUTnMgdXNpbmcgSVMtSVMgTXVsdGkt DQogICBUb3BvbG9neSB0b2dldGhlciB3aXRoIG90aGVyIHdlbGwtZGVmaW5lZCBJUy1JUyBleHRl bnNpb25zLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K5aaC5p6c5oKo6ZSZ6K+v5o6l5pS25LqG6K+l6YKu5Lu2 77yM6K+36YCa6L+H55S15a2Q6YKu5Lu256uL5Y2z6YCa55+l5oiR5Lus44CC6K+35Zue5aSN6YKu 5Lu25YiwIGhxcy1zcG1jQGNoaW5hdW5pY29tLmNu77yM5Y2z5Y+v5Lul6YCA6K6i5q2k6YKu5Lu2 44CC5oiR5Lus5bCG56uL5Y2z5bCG5oKo55qE5L+h5oGv5LuO5oiR5Lus55qE5Y+R6YCB55uu5b2V 5Lit5Yig6Zmk44CCIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwuIFBsZWFzZSByZXBseSB0byBocXMt c3BtY0BjaGluYXVuaWNvbS5jbiAseW91IGNhbiB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbWFpbC4g V2Ugd2lsbCBpbW1lZGlhdGVseSByZW1vdmUgeW91ciBpbmZvcm1hdGlvbiBmcm9tIHNlbmQgY2F0 YWxvZ3VlIG9mIG91ci4NCg== --_000_3ec18770721647dc8bc84ab846f52052M10HQML02hqcncintra_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLWxlZnQ6IDAuNWVtOyB9cCB7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyB9ZGl2LkZveERpdjIwMjAxMDI1MjA1NjIxMjY1OTYyIHsgfWJvZHkgeyBmb250LXNpemU6IDE0 cHg7IGZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5E7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGxpbmUt aGVpZ2h0OiAxLjU7IH08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBvcnBoYW5zOiAyOyB3aGl0ZS1zcGFj ZTogcHJlLXdyYXA7IHdpZG93czogMjsiPg0KSGkgQXV0aG9ycyw8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsgd2hpdGUtc3BhY2U6 IHByZS13cmFwOyB3aWRvd3M6IDI7Ij4NCjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS41OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDog bm9ybWFsOyB0ZXh0LWFsaWduOiBqdXN0aWZ5OyI+SSBhZ3JlZSB0aGF0IElHUCBNdWx0aS10b3Bv bG9neSBjYW4gYmUgdXNlZCB0byBwcm92aWRlIHRoZSByZXF1aXJlZCBmdW5jdGlvbmFsaXR5IHRv IGJ1aWxkIGN1c3RvbWl6ZWQgVlROcyB0byBtZWV0IGRpZmZlcmVudCBzZXJ2aWNlIHJlcXVpcmVt ZW50cy4gQW4gaW5mb3JtYXRpb24NCiBkb2N1bWVudCBsaWtlIHRoaXMgaXMgdXNlZnVsLjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgdGV4dC1hbGln bjoganVzdGlmeTsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPg0KPHNwYW4gc3R5bGU9ImxpbmUtaGVp Z2h0OiAxLjU7Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJib3gtc2l6 aW5nOiBib3JkZXItYm94OyBvdmVyZmxvdzogYXV0bzsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3 b3JkLXdyYXA6IG5vcm1hbDsgd29yZC1icmVhazogbm9ybWFsOyBmb250LXZhcmlhbnQtbGlnYXR1 cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHdpZG93czogMjsiPkkgaGF2ZSBvbmUgY29tbWVudO+8 mjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgdGV4 dC1hbGlnbjoganVzdGlmeTsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPg0KPHNwYW4gc3R5bGU9Imxp bmUtaGVpZ2h0OiAxLjU7Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7PC9zcGFuPlRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSBtZWNoYW5pc20gdG8gYWR2ZXJ0aXNlIGJhbmR3aWR0aCBhdHRyaWJ1dGUg Zm9yIGVhY2ggVlROLCBjYW4gb3RoZXIgdHlwZXMgb2YgbGluayBhdHRyaWJ1dGVzIGJlIGN1c3Rv bWl6ZWQgZm9yIGRpZmZlcmVudCBWVE5zPyBUaGFua3MuPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IHRleHQtYWxpZ246IGp1c3RpZnk7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7Ij4NCiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJl czogbm9ybWFsOyBvcnBoYW5zOiAyOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdpZG93czogMjsi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsiPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDE7 Ij5CZXN0IHJlZ2FyZHMsPC9zcGFuPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i d2lkb3dzOiAxOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7Ij48 c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsiPlBhbmcgUmFuPC9zcGFuPjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1Ub3A6IDBweDsgbWFyZ2luLUJvdHRvbTogMHB4OyBt YXJnaW4tTGVmdDogMC41ZW07IG1hcmdpbi1SaWdodDogaW5oZXJpdCI+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdiBzdHlsZT0iUEFERElORy1SSUdI VDogOHB4OyBQQURESU5HLUxFRlQ6IDhweDsgRk9OVC1TSVpFOiAxMnB4O0ZPTlQtRkFNSUxZOnRh aG9tYTtDT0xPUjojMDAwMDAwOyBCQUNLR1JPVU5EOiAjZWZlZmVmOyBQQURESU5HLUJPVFRPTTog OHB4OyBQQURESU5HLVRPUDogOHB4Ij4NCjxkaXY+PGI+RnJvbTo8L2I+Jm5ic3A7PGEgaHJlZj0i bWFpbHRvOnhpZWNoZkBjaGluYXRlbGVjb20uY24iPlhpZSBDaG9uZ2Zlbmc8L2E+PC9kaXY+DQo8 ZGl2PjxiPkRhdGU6PC9iPiZuYnNwOzIwMjAtMTAtMTQmbmJzcDsxNzozMjwvZGl2Pg0KPGRpdj48 Yj5Ubzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmxzckBpZXRmLm9yZyI+bHNyPC9hPjwvZGl2 Pg0KPGRpdj48Yj5TdWJqZWN0OjwvYj4mbmJzcDtbTHNyXSBGdzogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAyLnR4dDwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJGb3hEaXYyMDIwMTAyNTIwNTYyMTI2NTk2 MiI+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4+PC9zcGFuPjwvZm9u dD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQt c2l6ZTogMTZweDsiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPkhpLCBXRyw8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxNnB4OyI+PHNwYW4g bGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwcHggMGNt OyBmb250LXNpemU6IDE2cHg7Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5XZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LXhpZS1s c3ItaXNpcy1zci12dG4tbXQgdG8gcmVzb2x2ZSB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5n IGFuZCBhZnRlciBsYXN0IElFVEYgbWVldGluZy4gVGhlIGNoYW5nZXMNCiBhcmU6PG86cD48L286 cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW46IDBweCAwY207IGZvbnQtc2l6ZTogMTZweDsiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxNnB4OyI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbGluZS1oZWlnaHQ6 IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogd2luZG93OyI+MS4gQmFzZWQgb24gdGhlIHN1Z2dlc3Rp b25zIG9uIElFVEYgbWVldGluZywgdGhlIGRvY3VtZW50IHR5cGUgaXMgY2hhbmdlZCB0byBpbmZv cm1hdGlvbmFsLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luOiAwcHggMGNtOyBmb250LXNpemU6IDE2cHg7Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IGxpbmUtaGVpZ2h0OiAxLjU7IGJhY2tncm91 bmQtY29sb3I6IHdpbmRvdzsiPjIuIEFkZCBzb21lIGRlc2NyaXB0aW9ucyBhYm91dCB0aGUgb3Bl cmF0aW9ucw0KIGluIGZvcndhcmRpbmcgcGxhbmUuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTZweDsiPjxzcGFu IGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbGluZS1o ZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogd2luZG93OyI+My4gQWRkIHJlZmVyZW5jZSB0 byBkcmFmdC1pZXRmLXNwcmluZy1yZXNvdXJjZS1hd2FyZS1zZWdtZW50cywNCiB3aGljaCBpbnRy b2R1Y2VzIHRoZSBtZWNoYW5pc20gdG8gYXNzb2NpYXRlIFNSIFNJRHMgd2l0aCBkaWZmZXJlbnQg c3Vic2V0IG9mIHJlc291cmNlcy48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxNnB4OyI+PHNwYW4gbGFuZz0iRU4t VVMiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBsaW5lLWhlaWdodDogMS41 OyBiYWNrZ3JvdW5kLWNvbG9yOiB3aW5kb3c7Ij40LiBTb21lIGVkaXRvcmlhbCBjaGFuZ2VzLjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwcHggMGNt OyBmb250LXNpemU6IDE2cHg7Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTZweDsiPjxzcGFuIGxhbmc9 IkVOLVVTIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkR1cmluZyB0aGUgcHJlc2VudGF0 aW9uIG9uIGxhc3QgSUVURiBtZWV0aW5nLCBhdXRob3JzIGFza2VkIFdHIHRvIGNvbnNpZGVyIHRo ZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBTaW5jZSB0aGlzIHZlcnNpb24gcmVzb2x2ZXMg YWxsIHRoZSBjb21tZW50cw0KIHNvIGZhciBhbmQgdGhlIGNvbnRlbnQgaXMgZ2V0dGluZyBzdGFi bGUsIGF1dGhvcnMgd291bGQgbGlrZSB0byBzb2xpY2l0IFdHIGFkb3B0aW9uIHBvbGwgb24gdGhp cyBkb2N1bWVudC48bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxNnB4OyI+PHNwYW4g bGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwcHggMGNt OyBmb250LXNpemU6IDE2cHg7Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5SZXZpZXcgYW5kIGNvbW1lbnRzIGFyZSBhbHdheXMgd2VsY29tZS48bzpwPjwv bzpwPjwvZm9udD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxNnB4OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250 IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDE2cHg7 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5CZXN0IHJl Z2FyZHMsPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTZweDsiPjxzcGFuIGxhbmc9 IkVOLVVTIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjwvZm9udD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9u dC1zaXplOiAxNnB4OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+Q2hvbmdmZW5nJm5ic3A7PC9mb250Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDE2cHg7Ij48c3BhbiBs YW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMC41ZW07Ij4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2IHN0eWxlPSJQQURESU5HLVJJR0hUOiA4 cHg7IFBBRERJTkctTEVGVDogOHB4OyBGT05ULVNJWkU6IDEycHg7Rk9OVC1GQU1JTFk6dGFob21h O0NPTE9SOiMwMDAwMDA7IEJBQ0tHUk9VTkQ6ICNlZmVmZWY7IFBBRERJTkctQk9UVE9NOiA4cHg7 IFBBRERJTkctVE9QOiA4cHgiPg0KPGRpdj48Yj5Gcm9tOjwvYj4mbmJzcDs8YSBocmVmPSJtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHM8L2E+PC9kaXY+DQo8 ZGl2PjxiPkRhdGU6PC9iPiZuYnNwOzIwMjAtMTAtMTMmbmJzcDsxNDo1OTwvZGl2Pg0KPGRpdj48 Yj5Ubzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20iPkppZSBE b25nPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1hY2hoQGNoaW5hdGVsZWNvbS5jbiI+DQpDaGVuaGFv IE1hPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmxpemhlbmJpbkBodWF3ZWkuY29tIj5aaGVuYmluIExp PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnhpZWNoZkBjaGluYXRlbGVjb20uY24iPg0KQ2hvbmdmZW5n IFhpZTwvYT48L2Rpdj4NCjxkaXY+PGI+U3ViamVjdDo8L2I+Jm5ic3A7TmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAyLnR4dDwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQteGllLWxzci1pc2lzLXNyLXZ0bi1tdC0wMi50eHQ8L2Rpdj4NCjxk aXY+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWUgRG9uZyBhbmQgcG9zdGVk IHRvIHRoZTwvZGl2Pg0KPGRpdj5JRVRGIHJlcG9zaXRvcnkuPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5OYW1lOiBkcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10PC9kaXY+DQo8ZGl2 PlJldmlzaW9uOiAwMjwvZGl2Pg0KPGRpdj5UaXRsZTogVXNpbmcgSVMtSVMgTXVsdGktVG9wb2xv Z3kgKE1UKSBmb3IgU2VnbWVudCBSb3V0aW5nIGJhc2VkIFZpcnR1YWwgVHJhbnNwb3J0IE5ldHdv cms8L2Rpdj4NCjxkaXY+RG9jdW1lbnQgZGF0ZTogMjAyMC0xMC0xMzwvZGl2Pg0KPGRpdj5Hcm91 cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uPC9kaXY+DQo8ZGl2PlBhZ2VzOiA4PC9kaXY+DQo8ZGl2 PlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC14aWUt bHNyLWlzaXMtc3ItdnRuLW10LTAyLnR4dDwvZGl2Pg0KPGRpdj5TdGF0dXM6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXhpZS1sc3ItaXNpcy1zci12dG4tbXQvPC9kaXY+DQo8ZGl2Pkh0 bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXhpZS1sc3ItaXNpcy1zci12dG4tbXQ8L2Rp dj4NCjxkaXY+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAy PC9kaXY+DQo8ZGl2PkRpZmY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAyPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj5BYnN0cmFjdDo8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IEVuaGFuY2VkIFZQTiAoVlBO JiM0MzspIGFzIGRlZmluZWQgaW4gSS1ELmlldGYtdGVhcy1lbmhhbmNlZC12cG4gYWltcyB0bzwv ZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgcHJvdmlkZSBlbmhhbmNlZCBWUE4gc2VydmljZSB0byBz dXBwb3J0IHNvbWUgYXBwbGljYXRpb24ncyBuZWVkcyBvZjwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJz cDsgZW5oYW5jZWQgaXNvbGF0aW9uIGFuZCBzdHJpbmdlbnQgcGVyZm9ybWFuY2UgcmVxdWlyZW1l bnRzLiZuYnNwOyBWUE4mIzQzOzwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgcmVxdWlyZXMgaW50 ZWdyYXRpb24gYmV0d2VlbiB0aGUgb3ZlcmxheSBWUE4gYW5kIHRoZSB1bmRlcmxheTwvZGl2Pg0K PGRpdj4mbmJzcDsmbmJzcDsgbmV0d29yay4mbmJzcDsgQSBWaXJ0dWFsIFRyYW5zcG9ydCBOZXR3 b3JrIChWVE4pIGlzIGEgdmlydHVhbCBuZXR3b3JrPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyB3 aGljaCBjb25zaXN0cyBvZiBhIHN1YnNldCBvZiB0aGUgbmV0d29yayB0b3BvbG9neSBhbmQgbmV0 d29yazwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgcmVzb3VyY2VzIGFsbG9jYXRlZCBmcm9tIHRo ZSB1bmRlcmxheSBuZXR3b3JrLiZuYnNwOyBBIFZUTiBjb3VsZCBiZSB1c2VkPC9kaXY+DQo8ZGl2 PiZuYnNwOyZuYnNwOyBhcyB0aGUgdW5kZXJsYXkgZm9yIG9uZSBvciBhIGdyb3VwIG9mIFZQTiYj NDM7IHNlcnZpY2VzLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7 IEktRC5kb25nLWxzci1zci1lbmhhbmNlZC12cG4gZGVmaW5lcyB0aGUgSUdQIGV4dGVuc2lvbnMg dG8gYnVpbGQgYTwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgc2V0IG9mIFNlZ21lbnQgUm91dGlu ZyAoU1IpIGJhc2VkIFZUTnMuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGE8L2Rpdj4N CjxkaXY+Jm5ic3A7Jm5ic3A7IHNpbXBsaWZpZWQgbWVjaGFuaXNtIHRvIGJ1aWxkIHRoZSBTUiBi YXNlZCBWVE5zIHVzaW5nIElTLUlTIE11bHRpLTwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsgVG9w b2xvZ3kgdG9nZXRoZXIgd2l0aCBvdGhlciB3ZWxsLWRlZmluZWQgSVMtSVMgZXh0ZW5zaW9ucy48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+ UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbjwvZGl2Pg0KPGRpdj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+VGhlIElFVEYgU2VjcmV0YXJpYXQ8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCuWmguaenOaCqOmUmeiv r+aOpeaUtuS6huivpemCruS7tu+8jOivt+mAmui/h+eUteWtkOmCruS7tueri+WNs+mAmuefpeaI keS7rOOAguivt+WbnuWkjemCruS7tuWIsCZuYnNwO2hxcy1zcG1jQGNoaW5hdW5pY29tLmNu77yM 5Y2z5Y+v5Lul6YCA6K6i5q2k6YKu5Lu244CC5oiR5Lus5bCG56uL5Y2z5bCG5oKo55qE5L+h5oGv 5LuO5oiR5Lus55qE5Y+R6YCB55uu5b2V5Lit5Yig6Zmk44CCIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1h aWwuIFBsZWFzZSByZXBseSB0byZuYnNwO2hxcy1zcG1jQGNoaW5hdW5pY29tLmNuJm5ic3A7LHlv dSBjYW4gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIG1haWwuIFdlIHdpbGwgaW1tZWRpYXRlbHkNCiBy ZW1vdmUgeW91ciBpbmZvcm1hdGlvbiBmcm9tIHNlbmQgY2F0YWxvZ3VlIG9mIG91ci4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_3ec18770721647dc8bc84ab846f52052M10HQML02hqcncintra_-- From nobody Sun Oct 25 19:00:43 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F713A17B7; Sun, 25 Oct 2020 19:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 cgEVjXszlgKR; Sun, 25 Oct 2020 19:00:40 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80033A17B5; Sun, 25 Oct 2020 19:00:39 -0700 (PDT) Received: from lhreml735-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0C8AD176C5289B19B742; Mon, 26 Oct 2020 02:00:38 +0000 (GMT) Received: from lhreml735-chm.china.huawei.com (10.201.108.86) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 26 Oct 2020 02:00:37 +0000 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 26 Oct 2020 02:00:37 +0000 Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.184]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Mon, 26 Oct 2020 10:00:35 +0800 From: Mach Chen To: "Acee Lindem (acee)" , "draft-chen-lsr-isis-rfc5316bis@ietf.org" CC: "lsr@ietf.org" Thread-Topic: IPR Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02 Thread-Index: AQHWqUvLjl4YZ7qwwEqtkCf1BsISJampI9OQ Date: Mon, 26 Oct 2020 02:00:34 +0000 Message-ID: References: <1D4D7055-3AA3-40D0-AE2E-B62439EF229F@cisco.com> In-Reply-To: <1D4D7055-3AA3-40D0-AE2E-B62439EF229F@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.140] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F2A7EAdggeml510mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] IPR Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 02:00:42 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F2A7EAdggeml510mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWNlZSwNCg0KSSBrbmV3IHRoYXQgdGhlcmUgd2FzIGFuIElQUiBkaXNjbG9zdXJlIG9uIFJG QyA1MzE2LCBzaW5jZSB0aGlzIGlzIHRoZSBiaXMgdmVyc2lvbiBvZiB0aGF0IFJGQywgdGhlIElQ UiBkaXNjbG9zdXJlIHNob3VsZCBhcHBseSB0byB0aGlzIGRyYWZ0IGFzIHdlbGwuIEV4Y2VwdCBm b3IgdGhhdCwgSSBhbSBub3QgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIElQUiB0aGF0IGFwcGxp ZXMgdG8gdGhpcyBkb2N1bWVudC4NCg0KQmVzdCByZWdhcmRzLA0KTWFjaA0KDQpGcm9tOiBMc3Ig W21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFjZWUgTGluZGVtIChh Y2VlKQ0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDIzLCAyMDIwIDEwOjUwIFBNDQpUbzogZHJhZnQt Y2hlbi1sc3ItaXNpcy1yZmM1MzE2YmlzQGlldGYub3JnDQpDYzogbHNyQGlldGYub3JnDQpTdWJq ZWN0OiBbTHNyXSBJUFIgQ2FsbCBmb3IgIklTSVMgRXh0ZW5zaW9ucyBpbiBTdXBwb3J0IG9mIElu dGVyLUFTIE1QTFMgYW5kIEdNUExTIFRFIiAtIGRyYWZ0LWNoZW4tbHNyLWlzaXMtcmZjNTMxNmJp cy0wMg0KDQpIaSBNYWNoLCBMZXMsIFN0ZWZhbm8sIFhpYW9kb25nLA0KDQpBcmUgeW91IGF3YXJl IG9mIGFueSBJUFIgYXNzb2NpYXRlZCB3aXRoIHRoZSBzdWJqZWN0IGRyYWZ0Lg0KDQpJZiBzbywg aGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy dWxlcw0KKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cykuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1 dG9yIHBsZWFzZSByZXNwb25kDQp0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBv ciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkNCnJlbGV2YW50IElQUi4gVGhlIHJlc3BvbnNlIG5l ZWRzIHRvIGJlIHNlbnQgdG8gdGhlIExTUiBXRyBtYWlsaW5nDQpsaXN0LiBUaGUgZG9jdW1lbnQg d2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhDQpyZXNwb25zZSBoYXMg YmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCg0KSWYgeW91 IGFyZSBvbiB0aGUgTFNSIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1 dGhvciBvcg0KY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5 IGlmIHlvdSBhcmUgYXdhcmUgb2YNCmFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Ns b3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoYW5rcywNCkFjZWUNCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F2A7EAdggeml510mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiMxRjQ5N0QiPkhpIEFjZWUsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0 OTdEIj5JIGtuZXcgdGhhdCB0aGVyZSB3YXMgYW4gSVBSIGRpc2Nsb3N1cmUgb24gUkZDIDUzMTYs IHNpbmNlIHRoaXMgaXMgdGhlIGJpcyB2ZXJzaW9uIG9mIHRoYXQgUkZDLCB0aGUgSVBSIGRpc2Ns b3N1cmUgc2hvdWxkIGFwcGx5IHRvIHRoaXMgZHJhZnQgYXMgd2VsbC4gRXhjZXB0IGZvciB0aGF0 LCBJIGFtIG5vdCBhd2FyZQ0KIG9mIGFueSB1bmRpc2Nsb3NlZCBJUFIgdGhhdCBhcHBsaWVzIHRv IHRoaXMgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5C ZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Qi Pk1hY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiBMc3IgW21haWx0bzpsc3It Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWNlZSBMaW5kZW0gKGFjZWUp PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAyMywgMjAyMCAxMDo1MCBQTTxicj4N CjxiPlRvOjwvYj4gZHJhZnQtY2hlbi1sc3ItaXNpcy1yZmM1MzE2YmlzQGlldGYub3JnPGJyPg0K PGI+Q2M6PC9iPiBsc3JAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0xzcl0gSVBSIENh bGwgZm9yICZxdW90O0lTSVMgRXh0ZW5zaW9ucyBpbiBTdXBwb3J0IG9mIEludGVyLUFTIE1QTFMg YW5kIEdNUExTIFRFJnF1b3Q7IC0gZHJhZnQtY2hlbi1sc3ItaXNpcy1yZmM1MzE2YmlzLTAyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkhpIE1hY2gsIExlcywgU3RlZmFubywgWGlhb2RvbmcsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QXJlIHlvdSBh d2FyZSBvZiBhbnkgSVBSIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3ViamVjdCBkcmFmdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdp dGggSUVURiBJUFIgcnVsZXMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPihz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmli dXRvciBwbGVhc2UgcmVzcG9uZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+dG8gdGhp cyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5yZWxldmFudCBJUFIuIFRoZSByZXNwb25z ZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBMU1IgV0cgbWFpbGluZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+bGlzdC4gVGhlIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhl IG5leHQgc3RhZ2UgdW50aWwgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+cmVzcG9u c2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPklmIHlvdSBhcmUgb24gdGhlIExTUiBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90 IGxpc3RlZCBhcyBhbiBhdXRob3Igb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmNv bnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJl IGF3YXJlIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5hbnkgSVBSIHRoYXQgaGFz IG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5UaGFua3MsPGJyPg0KQWNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F2A7EAdggeml510mbschi_-- From nobody Sun Oct 25 19:02:29 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCEC3A17BA for ; Sun, 25 Oct 2020 19:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 kABBtRAiHj9T for ; Sun, 25 Oct 2020 19:02:26 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7743A17B7 for ; Sun, 25 Oct 2020 19:02:25 -0700 (PDT) Received: from lhreml742-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8F527D13CFB1042F5FA9 for ; Mon, 26 Oct 2020 02:02:24 +0000 (GMT) Received: from lhreml742-chm.china.huawei.com (10.201.108.192) by lhreml742-chm.china.huawei.com (10.201.108.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 26 Oct 2020 02:02:24 +0000 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml742-chm.china.huawei.com (10.201.108.192) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 26 Oct 2020 02:02:24 +0000 Received: from DGGEML510-MBS.china.huawei.com ([169.254.3.184]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Mon, 26 Oct 2020 10:02:20 +0800 From: Mach Chen To: "Acee Lindem (acee)" , "lsr@ietf.org" Thread-Topic: WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02 Thread-Index: AQHWqUrCm7zTIYibGU6r52S4U0zRW6mpJTHA Date: Mon, 26 Oct 2020 02:02:19 +0000 Message-ID: References: <74E40EE9-BAA9-4712-928E-C4ACE65728DC@cisco.com> In-Reply-To: <74E40EE9-BAA9-4712-928E-C4ACE65728DC@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.140] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F2B7FEdggeml510mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] WG Adoption Call for "ISIS Extensions in Support of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 02:02:28 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F2B7FEdggeml510mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgb25lIG9mIGNvLWF1dGhvcnMgb2YgdGhlIGRyYWZ0LCBJIHN1cHBvcnQgdGhlIGFkb3B0aW9u Lg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCkZyb206IExzciBbbWFpbHRvOmxzci1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0gKGFjZWUpDQpTZW50OiBGcmlkYXks IE9jdG9iZXIgMjMsIDIwMjAgMTA6NDMgUE0NClRvOiBsc3JAaWV0Zi5vcmcNClN1YmplY3Q6IFtM c3JdIFdHIEFkb3B0aW9uIENhbGwgZm9yICJJU0lTIEV4dGVuc2lvbnMgaW4gU3VwcG9ydCBvZiBJ bnRlci1BUyBNUExTIGFuZCBHTVBMUyBURSIgLSBkcmFmdC1jaGVuLWxzci1pc2lzLXJmYzUzMTZi aXMtMDINCg0KVGhpcyBpcyBzaW1wbGUgQklTIHVwZGF0ZSB0byBSRkMgNTMxNiBpcyByZXF1aXJl ZCB0byBzdXBwb3J0IElTLUlTIEludGVyLUFTIFRFIGluIElQdjYgb25seSBuZXR3b3Jrcy4gVGhl IGF1dGhvcnMgaGF2ZSBhc2tlZCBmb3IgV0cgYWRvcHRpb24uDQoNClRoaXMgYmVnaW5zIGEgdHdv IHdlZWsgTFNSIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24gUG9sbCBmb3Ig4oCcSVNJUyBFeHRlbnNp b25zIGluIFN1cHBvcnQgb2YgSW50ZXItQXV0b25vbW91cyBTeXN0ZW0gKEFTKSBNUExTIGFuZCBH TVBMUyBUcmFmZmljIEVuZ2luZWVyaW5n4oCdIC0gZHJhZnQtY2hlbi1sc3ItaXNpcy1yZmM1MzE2 YmlzLTAyLiBUaGUgcG9sbCB3aWxsIGVuZCBhdCAxMjowMCBBTSBVVEMgb24gTm92ZW1iZXIgN3Ro LCAyMDIwLiBQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IG9mIG9iamVjdGlvbiBvbiB0aGlz IGxpc3QgcHJpb3IgdG8gdGhlIGVuZCBvZiB0aGUgYWRvcHRpb24gcG9sbC4NCg0KVGhhbmtzLA0K QWNlZQ0KDQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F2B7FEdggeml510mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiMxRjQ5N0QiPkFzIG9uZSBvZiBjby1hdXRob3JzIG9mIHRoZSBkcmFmdCwgSSBzdXBwb3J0 IHRoZSBhZG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkJl c3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+ TWFjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IExzciBbbWFpbHRvOmxzci1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BY2VlIExpbmRlbSAoYWNlZSk8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDIzLCAyMDIwIDEwOjQzIFBNPGJyPg0K PGI+VG86PC9iPiBsc3JAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0xzcl0gV0cgQWRv cHRpb24gQ2FsbCBmb3IgJnF1b3Q7SVNJUyBFeHRlbnNpb25zIGluIFN1cHBvcnQgb2YgSW50ZXIt QVMgTVBMUyBhbmQgR01QTFMgVEUmcXVvdDsgLSBkcmFmdC1jaGVuLWxzci1pc2lzLXJmYzUzMTZi aXMtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+VGhpcyBpcyBzaW1wbGUgQklTIHVwZGF0ZSB0byBSRkMgNTMxNiBpcyByZXF1aXJl ZCB0byBzdXBwb3J0IElTLUlTIEludGVyLUFTIFRFIGluIElQdjYgb25seSBuZXR3b3Jrcy4gVGhl IGF1dGhvcnMgaGF2ZSBhc2tlZCBmb3IgV0cgYWRvcHRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBi ZWdpbnMgYSB0d28gd2VlayBMU1IgV29ya2luZyBHcm91cCBBZG9wdGlvbiBQb2xsIGZvciDigJxJ U0lTIEV4dGVuc2lvbnMgaW4gU3VwcG9ydCBvZiBJbnRlci1BdXRvbm9tb3VzIFN5c3RlbSAoQVMp IE1QTFMgYW5kIEdNUExTIFRyYWZmaWMgRW5naW5lZXJpbmfigJ0gLSBkcmFmdC1jaGVuLWxzci1p c2lzLXJmYzUzMTZiaXMtMDIuDQogVGhlIHBvbGwgd2lsbCBlbmQgYXQgMTI6MDAgQU0gVVRDIG9u IE5vdmVtYmVyIDc8c3VwPnRoPC9zdXA+LCAyMDIwLiBQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBw b3J0IG9mIG9iamVjdGlvbiBvbiB0aGlzIGxpc3QgcHJpb3IgdG8gdGhlIGVuZCBvZiB0aGUgYWRv cHRpb24gcG9sbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+QWNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297F2B7FEdggeml510mbschi_-- From nobody Sun Oct 25 20:21:31 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160DC3A1846 for ; Sun, 25 Oct 2020 20:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 JPEcC5Mu39o2 for ; Sun, 25 Oct 2020 20:21:27 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3DC3A1844 for ; Sun, 25 Oct 2020 20:21:27 -0700 (PDT) Received: from lhreml745-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DA00D13F92FC7EBAF525 for ; Mon, 26 Oct 2020 03:21:23 +0000 (GMT) Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by lhreml745-chm.china.huawei.com (10.201.108.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Mon, 26 Oct 2020 03:21:23 +0000 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 26 Oct 2020 11:21:20 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.1913.007; Mon, 26 Oct 2020 11:21:21 +0800 From: "Dongjie (Jimmy)" To: "chenhuan6@chinatelecom.cn" , =?utf-8?B?5pyx5rC45bqGQGNoaW5hdGVsZWNvbQ==?= , "lsr@ietf.org" Thread-Topic: =?utf-8?B?W0xzcl0gIOWbnuWkjTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk?= =?utf-8?Q?raft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt?= Thread-Index: AQHWqmKL0fIqxuQ8pUSHI3+oGEPQfampDdtA Date: Mon, 26 Oct 2020 03:21:21 +0000 Message-ID: References: <159981543873.27279.16517423794827557547@ietfa.amsl.com>, <000201d68bf0$842e5850$8c8b08f0$@chinatelecom.cn> <2020102508033633047934@chinatelecom.cn> In-Reply-To: <2020102508033633047934@chinatelecom.cn> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.143] Content-Type: multipart/alternative; boundary="_000_db12b0f300d94bb280ef7487d38af4eehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] =?utf-8?b?5Zue5aSNOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-zhu-lsr-isis-sr-vtn-flexalgo-01=2Etxt?= X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 03:21:29 -0000 --_000_db12b0f300d94bb280ef7487d38af4eehuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSHVhbmFuLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4N Cg0KTXkgdW5kZXJzdGFuZGluZyBpcyBhcyBGbGV4LUFsZ28gaXMgZGVmaW5lZCBieSBvcGVyYXRv ciwgZGlmZmVyZW50IEZsZXgtQWxnb3MgY2FuIGJlIGRlZmluZWQgZm9yIGRpZmZlcmVudCBwdXJw b3NlIGFuZCB3aXRoIGRpZmZlcmVudCBjb25zdHJhaW50cy4gVGh1cyBpdCBpcyBwb3NzaWJsZSB0 byB1c2UgZGlmZmVyZW50IEZsZXgtQWxnb3MgZm9yIGJvdGggdGhlIG5vcm1hbCBjYXNlIGFuZCB0 aGUgVlROIGNhc2UgaW4gdGhlIHNhbWUgbmV0d29yay4NCg0KSG9wZSB0aGlzIGhlbHBzLg0KDQpC ZXN0IHJlZ2FyZHMsDQpKaWUNCg0KRnJvbTogTHNyIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBjaGVuaHVhbjZAY2hpbmF0ZWxlY29tLmNuDQpTZW50OiBTdW5kYXks IE9jdG9iZXIgMjUsIDIwMjAgODowNSBBTQ0KVG86IOacseawuOW6hkBjaGluYXRlbGVjb20gPHpo dXlxOEBjaGluYXRlbGVjb20uY24+OyBsc3JAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTHNyXSDl m57lpI06IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemh1LWxzci1pc2lzLXNy LXZ0bi1mbGV4YWxnby0wMS50eHQNCg0KSGkgYXV0aG9ycywNCg0KSeKAmXZlIHJldmlld2VkIHRo aXMgZG9jdW1lbnQuICBUaGUgZHJhZnQgcHJvdmlkZXMgYSB1c2VmdWwgbWVjaGFuaXNtIHRvIGVu YWJsZSBWVE5zIGJhc2VkIG9uIG1pbm9yIGV4dGVuc2lvbnMgdG8gRmxleC1BbGdvIGFuZCBMMiBi dW5kbGUuDQoNCk9uZSBjb21tZW50IGlzOiBpbiBvbmUgbmV0d29yaywgY2FuIHNvbWUgRmxleC1B bGdvcyBiZSB1c2VkIGZvciBpdHMgdHJhZGl0aW9uYWwgdXNhZ2UsIGFuZCBzb21lIG90aGVyIEZs ZXgtQWxnb3MgYmUgdXNlZCBmb3IgVlROcyBhcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudD8N Cg0KQlIuDQoNCkh1YU5hbg0KDQrlj5Hku7bkurrvvJogemh1eXE4QGNoaW5hdGVsZWNvbS5jbjxt YWlsdG86emh1eXE4QGNoaW5hdGVsZWNvbS5jbj4NCuWPkemAgeaXtumXtO+8miAyMDIwLTA5LTE2 IDE0OjEzDQrmlLbku7bkurrvvJogbHNyQGlldGYub3JnPG1haWx0bzpsc3JAaWV0Zi5vcmc+DQrk uLvpopjvvJogW0xzcl0g5Zue5aSNOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFsZ28tMDEudHh0DQpIaSBXRywNCg0KV2UganVzdCBz dWJtaXR0ZWQgYSBuZXcgcmV2aXNpb24gb2YgZHJhZnQtemh1LWxzci1pc2lzLXNyLXZ0bi1mbGV4 YWxnby4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBtZWNoYW5pc20gdG8gdXNlIEZsZXgtQWxn byB0b2dldGhlciB3aXRoIHNtYWxsIGV4dGVuc2lvbnMgdG8gSVMtSVMgTDIgYnVuZGxlIHRvIGRp c3RyaWJ1dGUgdGhlIHRvcG9sb2d5IGFuZCByZXNvdXJjZSBhdHRyaWJ1dGUgb2YgU1IgYmFzZWQg VlROLiBZb3VyIHJldmlldyBhbmQgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KQi5SLg0KWmh1 IFlvbmdxaW5nDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IDxpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+DQrlj5Hp gIHml7bpl7Q6IDIwMjDlubQ55pyIMTHml6UgMTc6MTENCuaUtuS7tuS6ujogRG9uZ2ppZSAoSmlt bXkpIDxqaWUuZG9uZ0BodWF3ZWkuY29tPG1haWx0bzpqaWUuZG9uZ0BodWF3ZWkuY29tPj47IFlv bmdxaW5nIFpodSA8emh1eXE4QGNoaW5hdGVsZWNvbS5jbjxtYWlsdG86emh1eXE4QGNoaW5hdGVs ZWNvbS5jbj4+OyBIdXpoaWJvIDxodXpoaWJvQGh1YXdlaS5jb208bWFpbHRvOmh1emhpYm9AaHVh d2VpLmNvbT4+DQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemh1 LWxzci1pc2lzLXNyLXZ0bi1mbGV4YWxnby0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtemh1LWxzci1pc2lzLXNyLXZ0bi1mbGV4YWxnby0wMS50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmllIERvbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtemh1LWxzci1pc2lzLXNyLXZ0bi1m bGV4YWxnbw0KUmV2aXNpb246ICAgICAgIDAxDQpUaXRsZTogICAgICAgICAgVXNpbmcgRmxleC1B bGdvIGZvciBTZWdtZW50IFJvdXRpbmcgYmFzZWQgVlRODQpEb2N1bWVudCBkYXRlOiAgMjAyMC0w OS0xMQ0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAg ICAgIDgNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC16aHUt bHNyLWlzaXMtc3ItdnRuLWZsZXhhbGdvLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFs Z28vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC16aHUtbHNyLWlzaXMtc3ItdnRuLWZsZXhhbGdvDQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFs Z28tMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtemh1LWxzci1pc2lzLXNyLXZ0bi1mbGV4YWxnby0wMQ0KDQpBYnN0cmFjdDoNCiAgIEFz IGRlZmluZWQgaW4gSS1ELmlldGYtdGVhcy1lbmhhbmNlZC12cG4sIGVuaGFuY2VkIFZQTiAoVlBO KykgYWltcyB0bw0KICAgcHJvdmlkZSBlbmhhbmNlZCBWUE4gc2VydmljZSB0byBzdXBwb3J0IHRo ZSBuZWVkcyBvZiBlbmhhbmNlZA0KICAgaXNvbGF0aW9uIGFuZCBzdHJpbmdlbnQgcGVyZm9ybWFu Y2UgcmVxdWlyZW1lbnRzLiAgVlBOKyByZXF1aXJlcw0KICAgaW50ZWdyYXRpb24gYmV0d2VlbiB0 aGUgb3ZlcmxheSBWUE4gYW5kIHRoZSB1bmRlcmxheSBuZXR3b3JrLiAgQQ0KICAgVmlydHVhbCBU cmFuc3BvcnQgTmV0d29yayAoVlROKSBpcyBhIHZpcnR1YWwgbmV0d29yayB3aGljaCBjb25zaXN0 cw0KICAgb2YgYSBzdWJzZXQgb2YgbmV0d29yayB0b3BvbG9neSBhbmQgbmV0d29yayByZXNvdXJj ZXMgYWxsb2NhdGVkIGZyb20NCiAgIHRoZSB1bmRlcmxheSBuZXR3b3JrLiAgQSBWVE4gY291bGQg YmUgdXNlZCBhcyB0aGUgdW5kZXJsYXkgZm9yIG9uZSBvcg0KICAgYSBncm91cCBvZiBWUE4rIHNl cnZpY2VzLg0KDQogICBJLUQuZG9uZy1sc3Itc3ItZW5oYW5jZWQtdnBuIGRlZmluZXMgdGhlIElH UCBtZWNoYW5pc21zIHdpdGgNCiAgIG5lY2Vzc2FyeSBleHRlbnNpb25zIHRvIGJ1aWxkIGEgc2V0 IG9mIFNlZ21lbnQgUm91dGluZyAoU1IpIGJhc2VkDQogICBWVE5zLiAgVGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgYSBzaW1wbGlmaWVkIG1lY2hhbmlzbSB0byBidWlsZCB0aGUgU1INCiAgIGJhc2Vk IFZUTnMgdXNpbmcgU1IgRmxleC1BbGdvIHRvZ2V0aGVyIHdpdGggbWlub3IgZXh0ZW5zaW9ucyB0 byBJR1ANCiAgIEwyIGJ1bmRsZS4NCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTHNyIG1haWxpbmcgbGlzdA0KTHNyQGlldGYu b3JnPG1haWx0bzpMc3JAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2xzcg0K --_000_db12b0f300d94bb280ef7487d38af4eehuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5Ouetiee6vzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA562J57q/IjsNCglwYW5vc2UtMToyIDEgNiAwIDMg MSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEh1YW5hbiwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgYSBs b3QgZm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NeSB1bmRlcnN0 YW5kaW5nIGlzIGFzIEZsZXgtQWxnbyBpcyBkZWZpbmVkIGJ5IG9wZXJhdG9yLCBkaWZmZXJlbnQg RmxleC1BbGdvcyBjYW4gYmUgZGVmaW5lZCBmb3IgZGlmZmVyZW50IHB1cnBvc2UgYW5kIHdpdGgg ZGlmZmVyZW50IGNvbnN0cmFpbnRzLg0KIFRodXMgaXQgaXMgcG9zc2libGUgdG8gdXNlIGRpZmZl cmVudCBGbGV4LUFsZ29zIGZvciBib3RoIHRoZSBub3JtYWwgY2FzZSBhbmQgdGhlIFZUTiBjYXNl IGluIHRoZSBzYW1lIG5ldHdvcmsuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG9wZSB0aGlzIGhlbHBzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KaWU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMc3IgW21h aWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Y2hlbmh1YW42 QGNoaW5hdGVsZWNvbS5jbjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE9jdG9iZXIgMjUsIDIw MjAgODowNSBBTTxicj4NCjxiPlRvOjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij7mnLHmsLjluoY8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QGNo aW5hdGVsZWNvbSAmbHQ7emh1eXE4QGNoaW5hdGVsZWNvbS5jbiZndDs7IGxzckBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0xzcl0gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij7lm57lpI08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxl eGFsZ28tMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5IaSBhdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5 OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5J4oCZdmUgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudC4gJm5ic3A7VGhlIGRyYWZ0IHByb3ZpZGVzIGEgdXNlZnVsIG1lY2hhbmlzbSB0 byBlbmFibGUgVlROcyBiYXNlZCBvbg0KIG1pbm9yIGV4dGVuc2lvbnMgdG8gRmxleC1BbGdvIGFu ZCBMMiBidW5kbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPk9uZSBjb21tZW50IGlzOiBpbiBvbmUgbmV0d29yaywgY2FuIHNv bWUgRmxleC1BbGdvcyBiZSB1c2VkIGZvciBpdHMgdHJhZGl0aW9uYWwgdXNhZ2UsIGFuZA0KIHNv bWUgb3RoZXIgRmxleC1BbGdvcyBiZSB1c2VkIGZvciBWVE5zIGFzIGRlc2NyaWJlZCBpbiB0aGlz IGRvY3VtZW50PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5CUi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVv Z3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFs aWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SHVhTmFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6Ni4wcHQ7bWFyZ2luLXJpZ2h0 OmluaGVyaXQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDojRUZFRkVGIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 Ouetiee6vztjb2xvcjpibGFjayI+5Y+R5Lu25Lq677yaPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnpodXlxOEBj aGluYXRlbGVjb20uY24iPnpodXlxOEBjaGluYXRlbGVjb20uY248L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTrnrYnnur87Y29sb3I6YmxhY2siPuWPkemAgeaXtumXtO+8mjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzIwMjAtMDktMTYmbmJzcDsxNDox MzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj7mlLbku7bkurrvvJo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVm PSJtYWlsdG86bHNyQGlldGYub3JnIj5sc3JAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6I0VGRUZFRiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTrn rYnnur87Y29sb3I6YmxhY2siPuS4u+mimO+8mjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwO1tMc3JdDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPuWbnuWkjTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFsZ28tMDEudHh0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj5IaSBXRyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/ O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj5XZSBqdXN0IHN1Ym1pdHRl ZCBhIG5ldyByZXZpc2lvbiBvZiBkcmFmdC16aHUtbHNyLWlzaXMtc3ItdnRuLWZsZXhhbGdvLiBU aGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG1lY2hhbmlzbSB0byB1c2UgRmxleC1BbGdvIHRvZ2V0 aGVyIHdpdGggc21hbGwgZXh0ZW5zaW9ucyB0byBJUy1JUw0KIEwyIGJ1bmRsZSB0byBkaXN0cmli dXRlIHRoZSB0b3BvbG9neSBhbmQgcmVzb3VyY2UgYXR0cmlidXRlIG9mIFNSIGJhc2VkIFZUTi4g WW91ciByZXZpZXcgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJs YWNrIj5CLlIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Zv bnQtZmFtaWx5Ouetiee6vztjb2xvcjpibGFjayI+Wmh1IFlvbmdxaW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0 O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjpibGFjayI+LS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj7pgq7ku7bl jp/ku7Y8c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj7lj5Hku7bkuro8c3Bh biBsYW5nPSJFTi1VUyI+Og0KPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2Nv bG9yOmJsYWNrIj7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+OiAyMDIwPC9zcGFuPuW5 tDxzcGFuIGxhbmc9IkVOLVVTIj45PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xMTwvc3Bh bj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDE3OjExPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjpibGFjayI+5pS25Lu25Lq6PHNw YW4gbGFuZz0iRU4tVVMiPjogRG9uZ2ppZSAoSmltbXkpICZsdDs8YSBocmVmPSJtYWlsdG86amll LmRvbmdAaHVhd2VpLmNvbSI+amllLmRvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7OyBZb25ncWluZyBa aHUgJmx0OzxhIGhyZWY9Im1haWx0bzp6aHV5cThAY2hpbmF0ZWxlY29tLmNuIj56aHV5cThAY2hp bmF0ZWxlY29tLmNuPC9hPiZndDs7DQogSHV6aGlibyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1emhp Ym9AaHVhd2VpLmNvbSI+aHV6aGlib0BodWF3ZWkuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj7k uLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFsZ28tMDEudHh0PG86cD48L286cD48L3NwYW4+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6 YmxhY2siPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aHUtbHNyLWlzaXMtc3ItdnRuLWZs ZXhhbGdvLTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgSmllIERvbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrn rYnnur87Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPk5hbWU6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRy YWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFsZ288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj5SZXZp c2lvbjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDE8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9y OmJsYWNrIj5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVXNpbmcgRmxleC1BbGdvIGZvciBTZWdtZW50IFJvdXRpbmcgYmFzZWQgVlRO PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 Ouetiee6vztjb2xvcjpibGFjayI+RG9jdW1lbnQgZGF0ZTombmJzcDsgMjAyMC0wOS0xMTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnn ur87Y29sb3I6YmxhY2siPkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJs YWNrIj5QYWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFsZ28t MDEudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC16aHUtbHNyLWlzaXMtc3ItdnRu LWZsZXhhbGdvLTAxLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj5TdGF0dXM6Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aHUtbHNyLWlzaXMtc3ItdnRuLWZsZXhh bGdvLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemh1LWxzci1pc2lz LXNyLXZ0bi1mbGV4YWxnby88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjpibGFjayI+SHRtbGl6ZWQ6Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFsZ28i Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC16aHUtbHNyLWlz aXMtc3ItdnRuLWZsZXhhbGdvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPkh0bWxpemVkOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXpodS1sc3ItaXNpcy1zci12dG4tZmxleGFsZ28tMDEiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aHUtbHNyLWlzaXMtc3ItdnRuLWZsZXhhbGdv LTAxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPkRpZmY6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemh1LWxzci1pc2lzLXNyLXZ0bi1mbGV4YWxn by0wMSI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemh1LWxzci1p c2lzLXNyLXZ0bi1mbGV4YWxnby0wMTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J 57q/O2NvbG9yOmJsYWNrIj5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgQXMgZGVmaW5lZCBpbiBJLUQuaWV0Zi10ZWFzLWVuaGFuY2VkLXZwbiwgZW5oYW5jZWQgVlBO IChWUE4mIzQzOykgYWltcyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwcm92 aWRlIGVuaGFuY2VkIFZQTiBzZXJ2aWNlIHRvIHN1cHBvcnQgdGhlIG5lZWRzIG9mIGVuaGFuY2Vk PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 Ouetiee6vztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGlzb2xhdGlvbiBhbmQgc3RyaW5nZW50 IHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cy4mbmJzcDsgVlBOJiM0MzsgcmVxdWlyZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/ O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW50ZWdyYXRpb24gYmV0d2VlbiB0aGUgb3Zlcmxh eSBWUE4gYW5kIHRoZSB1bmRlcmxheSBuZXR3b3JrLiZuYnNwOyBBPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IFZpcnR1YWwgVHJhbnNwb3J0IE5ldHdvcmsgKFZUTikgaXMgYSB2aXJ0 dWFsIG5ldHdvcmsgd2hpY2ggY29uc2lzdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgb2YgYSBzdWJzZXQgb2YgbmV0d29yayB0b3BvbG9neSBhbmQgbmV0d29yayByZXNvdXJjZXMg YWxsb2NhdGVkIGZyb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhlIHVuZGVy bGF5IG5ldHdvcmsuJm5ic3A7IEEgVlROIGNvdWxkIGJlIHVzZWQgYXMgdGhlIHVuZGVybGF5IGZv ciBvbmUgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgYSBncm91cCBvZiBWUE4m IzQzOyBzZXJ2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgSS1ELmRvbmctbHNyLXNyLWVuaGFuY2VkLXZwbiBkZWZpbmVzIHRo ZSBJR1AgbWVjaGFuaXNtcyB3aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG5l Y2Vzc2FyeSBleHRlbnNpb25zIHRvIGJ1aWxkIGEgc2V0IG9mIFNlZ21lbnQgUm91dGluZyAoU1Ip IGJhc2VkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5Ouetiee6vztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFZUTnMuJm5ic3A7IFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2ltcGxpZmllZCBtZWNoYW5pc20gdG8gYnVpbGQgdGhlIFNS PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 Ouetiee6vztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGJhc2VkIFZUTnMgdXNpbmcgU1IgRmxl eC1BbGdvIHRvZ2V0aGVyIHdpdGggbWlub3IgZXh0ZW5zaW9ucyB0byBJR1A8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsgTDIgYnVuZGxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTrnrYnnur87Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrn rYnnur87Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnn ur87Y29sb3I6YmxhY2siPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2Nv bG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj5UaGUgSUVURiBTZWNyZXRhcmlh dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTrnrYnnur87Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTrn rYnnur87Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vztjb2xvcjpibGFjayI+ THNyIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjVwdDtmb250LWZhbWlseTrnrYnnur87Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpMc3JA aWV0Zi5vcmciPkxzckBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6562J57q/O2NvbG9yOmJsYWNrIj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xzciI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3I8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_db12b0f300d94bb280ef7487d38af4eehuaweicom_-- From nobody Mon Oct 26 16:17:47 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D9D3A10A0 for ; Mon, 26 Oct 2020 16:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 79b-pWcuXk5W for ; Mon, 26 Oct 2020 16:17:42 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABB93A109E for ; Mon, 26 Oct 2020 16:17:41 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.92:4260.8420300 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-114.250.163.233?logid-d07724733b244f19aec0bb8e799ef2c1 (unknown [172.18.0.92]) by chinatelecom.cn (HERMES) with SMTP id 928BE28008B; Tue, 27 Oct 2020 07:17:36 +0800 (CST) X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn Received: from ([172.18.0.92]) by App0021 with ESMTP id d07724733b244f19aec0bb8e799ef2c1 for lsr@ietf.org; Tue Oct 27 07:17:38 2020 X-Transaction-ID: d07724733b244f19aec0bb8e799ef2c1 X-filter-score: filter<0> X-Real-From: xiechf@chinatelecom.cn X-Receive-IP: 172.18.0.92 X-MEDUSA-Status: 0 Sender: xiechf@chinatelecom.cn Date: Tue, 27 Oct 2020 07:17:33 +0800 From: "xiechf@chinatelecom.cn" To: lsr , pangran References: <30999b5122ff4fb3b08a480a2c8794be@huawei.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.18.95[cn] Mime-Version: 1.0 Message-ID: <202010270717331726154@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart023677138203_=----" Archived-At: Subject: Re: [Lsr] Fw: New Version Notification for draft-xie-lsr-isis-sr-vtn-mt-02.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 23:17:46 -0000 This is a multi-part message in MIME format. ------=_001_NextPart023677138203_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIFJhbiwNCiANClRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLg0KIA0KQmFz ZWQgb24gTVQgbWVjaGFuaXNtLCBkaWZmZXJlbnQgbGluayBhdHRyaWJ1dGVzIGNvdWxkIGJlIGFk dmVydGlzZWQgZm9yIGRpZmZlcmVudCB0b3BvbG9naWVzLiBJbiBjdXJyZW50IGRvY3VtZW50LCB0 aGUgYWR2ZXJ0aXNlbWVudCBvZiBwZXItVlROIGJhbmR3aWR0aCB1c2luZyB0b3BvbG9neS1zcGVj aWZpYyBtYXhpbXVtIGxpbmsgYmFuZHdpZHRoIGF0dHJpYnV0ZSBpcyBkZXNjcmliZWQgYXMgYSBt YWpvciBjYXNlLCB3aGlsZSBpdCBhbHNvIGFsbG93cyBvdGhlciBsaW5rIGF0dHJpYnV0ZXMgdG8g YmUgZGVmaW5lZCBhbmQgYWR2ZXJ0aXNlZCBpbiBhIHBlci1WVE4gbWFubmVyLiBUaGlzIGlzIGN1 cnJlbnRseSBjb25zaWRlcmVkIGZvciBmdXJ0aGVyIHN0dWR5LCBtb3JlIGRlc2NyaXB0aW9uIG1h eSBiZSBhZGRlZCB3aGVuIHRoZSB1c2UgY2FzZSBvZiBvdGhlciBhdHRyaWJ1dGVzIGJlY29tZXMg Y2xlYXIuDQogDQpCZXN0IHJlZ2FyZHMsDQpDaG9uZ2ZlbmcNCiANCkZyb206IExzciBbbWFpbHRv Omxzci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFuIFBhbmco6IGU6YCa6ZuG5Zui 5Lit5Zu96IGU6YCa56CU56m26ZmiLeacrOmDqCkNClNlbnQ6IFN1bmRheSwgT2N0b2JlciAyNSwg MjAyMCA5OjIyIFBNDQpUbzogWGllIENob25nZmVuZyA8eGllY2hmQGNoaW5hdGVsZWNvbS5jbj47 IGxzciA8bHNyQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtMc3JdIEZ3OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXhpZS1sc3ItaXNpcy1zci12dG4tbXQtMDIudHh0DQogDQpI aSBBdXRob3JzLA0KICAgIEkgYWdyZWUgdGhhdCBJR1AgTXVsdGktdG9wb2xvZ3kgY2FuIGJlIHVz ZWQgdG8gcHJvdmlkZSB0aGUgcmVxdWlyZWQgZnVuY3Rpb25hbGl0eSB0byBidWlsZCBjdXN0b21p emVkIFZUTnMgdG8gbWVldCBkaWZmZXJlbnQgc2VydmljZSByZXF1aXJlbWVudHMuIEFuIGluZm9y bWF0aW9uIGRvY3VtZW50IGxpa2UgdGhpcyBpcyB1c2VmdWwuDQogICAgSSBoYXZlIG9uZSBjb21t ZW5077yaDQogICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG1lY2hhbmlzbSB0byBhZHZl cnRpc2UgYmFuZHdpZHRoIGF0dHJpYnV0ZSBmb3IgZWFjaCBWVE4sIGNhbiBvdGhlciB0eXBlcyBv ZiBsaW5rIGF0dHJpYnV0ZXMgYmUgY3VzdG9taXplZCBmb3IgZGlmZmVyZW50IFZUTnM/IFRoYW5r cy4NCiANCkJlc3QgcmVnYXJkcywNClBhbmcgUmFuDQogDQpGcm9tOiBYaWUgQ2hvbmdmZW5nDQpE YXRlOiAyMDIwLTEwLTE0IDE3OjMyDQpUbzogbHNyDQpTdWJqZWN0OiBbTHNyXSBGdzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAyLnR4 dA0KSGksIFdHLA0KIA0KV2UganVzdCBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC14 aWUtbHNyLWlzaXMtc3ItdnRuLW10IHRvIHJlc29sdmUgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGR1 cmluZyBhbmQgYWZ0ZXIgbGFzdCBJRVRGIG1lZXRpbmcuIFRoZSBjaGFuZ2VzIGFyZToNCiANCjEu IEJhc2VkIG9uIHRoZSBzdWdnZXN0aW9ucyBvbiBJRVRGIG1lZXRpbmcsIHRoZSBkb2N1bWVudCB0 eXBlIGlzIGNoYW5nZWQgdG8gaW5mb3JtYXRpb25hbC4NCiAyLiBBZGQgc29tZSBkZXNjcmlwdGlv bnMgYWJvdXQgdGhlIG9wZXJhdGlvbnMgaW4gZm9yd2FyZGluZyBwbGFuZS4NCiAzLiBBZGQgcmVm ZXJlbmNlIHRvIGRyYWZ0LWlldGYtc3ByaW5nLXJlc291cmNlLWF3YXJlLXNlZ21lbnRzLCB3aGlj aCBpbnRyb2R1Y2VzIHRoZSBtZWNoYW5pc20gdG8gYXNzb2NpYXRlIFNSIFNJRHMgd2l0aCBkaWZm ZXJlbnQgc3Vic2V0IG9mIHJlc291cmNlcy4NCiA0LiBTb21lIGVkaXRvcmlhbCBjaGFuZ2VzLg0K IA0KRHVyaW5nIHRoZSBwcmVzZW50YXRpb24gb24gbGFzdCBJRVRGIG1lZXRpbmcsIGF1dGhvcnMg YXNrZWQgV0cgdG8gY29uc2lkZXIgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFNpbmNl IHRoaXMgdmVyc2lvbiByZXNvbHZlcyBhbGwgdGhlIGNvbW1lbnRzIHNvIGZhciBhbmQgdGhlIGNv bnRlbnQgaXMgZ2V0dGluZyBzdGFibGUsIGF1dGhvcnMgd291bGQgbGlrZSB0byBzb2xpY2l0IFdH IGFkb3B0aW9uIHBvbGwgb24gdGhpcyBkb2N1bWVudC4NCiANClJldmlldyBhbmQgY29tbWVudHMg YXJlIGFsd2F5cyB3ZWxjb21lLg0KIA0KQmVzdCByZWdhcmRzLA0KIA0KQ2hvbmdmZW5nIA0KIA0K IA0KRnJvbTogaW50ZXJuZXQtZHJhZnRzDQpEYXRlOiAyMDIwLTEwLTEzIDE0OjU5DQpUbzogSmll IERvbmc7IENoZW5oYW8gTWE7IFpoZW5iaW4gTGk7IENob25nZmVuZyBYaWUNClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteGllLWxzci1pc2lzLXNyLXZ0bi1tdC0w Mi50eHQNCiANCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRu LW10LTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWUgRG9uZyBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KIA0KTmFtZTogZHJhZnQteGllLWxz ci1pc2lzLXNyLXZ0bi1tdA0KUmV2aXNpb246IDAyDQpUaXRsZTogVXNpbmcgSVMtSVMgTXVsdGkt VG9wb2xvZ3kgKE1UKSBmb3IgU2VnbWVudCBSb3V0aW5nIGJhc2VkIFZpcnR1YWwgVHJhbnNwb3J0 IE5ldHdvcmsNCkRvY3VtZW50IGRhdGU6IDIwMjAtMTAtMTMNCkdyb3VwOiBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOiA4DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv YXJjaGl2ZS9pZC9kcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10LTAyLnR4dA0KU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXhpZS1sc3ItaXNp cy1zci12dG4tbXQvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC14aWUtbHNyLWlzaXMtc3ItdnRuLW10DQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXhpZS1sc3ItaXNpcy1zci12dG4tbXQt MDINCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQteGllLWxzci1pc2lzLXNyLXZ0bi1tdC0wMg0KIA0KQWJzdHJhY3Q6DQogICBFbmhhbmNlZCBW UE4gKFZQTispIGFzIGRlZmluZWQgaW4gSS1ELmlldGYtdGVhcy1lbmhhbmNlZC12cG4gYWltcyB0 bw0KICAgcHJvdmlkZSBlbmhhbmNlZCBWUE4gc2VydmljZSB0byBzdXBwb3J0IHNvbWUgYXBwbGlj YXRpb24ncyBuZWVkcyBvZg0KICAgZW5oYW5jZWQgaXNvbGF0aW9uIGFuZCBzdHJpbmdlbnQgcGVy Zm9ybWFuY2UgcmVxdWlyZW1lbnRzLiAgVlBOKw0KICAgcmVxdWlyZXMgaW50ZWdyYXRpb24gYmV0 d2VlbiB0aGUgb3ZlcmxheSBWUE4gYW5kIHRoZSB1bmRlcmxheQ0KICAgbmV0d29yay4gIEEgVmly dHVhbCBUcmFuc3BvcnQgTmV0d29yayAoVlROKSBpcyBhIHZpcnR1YWwgbmV0d29yaw0KICAgd2hp Y2ggY29uc2lzdHMgb2YgYSBzdWJzZXQgb2YgdGhlIG5ldHdvcmsgdG9wb2xvZ3kgYW5kIG5ldHdv cmsNCiAgIHJlc291cmNlcyBhbGxvY2F0ZWQgZnJvbSB0aGUgdW5kZXJsYXkgbmV0d29yay4gIEEg VlROIGNvdWxkIGJlIHVzZWQNCiAgIGFzIHRoZSB1bmRlcmxheSBmb3Igb25lIG9yIGEgZ3JvdXAg b2YgVlBOKyBzZXJ2aWNlcy4NCiANCiAgIEktRC5kb25nLWxzci1zci1lbmhhbmNlZC12cG4gZGVm aW5lcyB0aGUgSUdQIGV4dGVuc2lvbnMgdG8gYnVpbGQgYQ0KICAgc2V0IG9mIFNlZ21lbnQgUm91 dGluZyAoU1IpIGJhc2VkIFZUTnMuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhDQogICBzaW1w bGlmaWVkIG1lY2hhbmlzbSB0byBidWlsZCB0aGUgU1IgYmFzZWQgVlROcyB1c2luZyBJUy1JUyBN dWx0aS0NCiAgIFRvcG9sb2d5IHRvZ2V0aGVyIHdpdGggb3RoZXIgd2VsbC1kZWZpbmVkIElTLUlT IGV4dGVuc2lvbnMuDQogDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogDQogDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KIA0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCiANCiAN CiANCuWmguaenOaCqOmUmeivr+aOpeaUtuS6huivpemCruS7tu+8jOivt+mAmui/h+eUteWtkOmC ruS7tueri+WNs+mAmuefpeaIkeS7rOOAguivt+WbnuWkjemCruS7tuWIsCBocXMtc3BtY0BjaGlu YXVuaWNvbS5jbu+8jOWNs+WPr+S7pemAgOiuouatpOmCruS7tuOAguaIkeS7rOWwhueri+WNs+Ww huaCqOeahOS/oeaBr+S7juaIkeS7rOeahOWPkemAgeebruW9leS4reWIoOmZpOOAgiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRp YXRlbHkgYnkgZS1tYWlsLiBQbGVhc2UgcmVwbHkgdG8gaHFzLXNwbWNAY2hpbmF1bmljb20uY24g LHlvdSBjYW4gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIG1haWwuIFdlIHdpbGwgaW1tZWRpYXRlbHkg cmVtb3ZlIHlvdXIgaW5mb3JtYXRpb24gZnJvbSBzZW5kIGNhdGFsb2d1ZSBvZiBvdXIuIA0K ------=_001_NextPart023677138203_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I support the adopt= ion of this draft. It=92s a simple and useful extension.<= /p>

 

Thanks,<= /span>

Yingzhen=

 

From: Lsr <lsr-bounces@ietf.org>
Date: Sunday, October 25, 2020 at 7:03 PM
To: Acee Lindem (acee) <acee=3D40cisco.com@dmarc.ietf.org>, ls= r@ietf.org <lsr@ietf.org>
Subject: Re: [Lsr] WG Adoption Call for "ISIS Extensions in Sup= port of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-0= 2

As on= e of co-authors of the draft, I support the adoption.

 = ;

Best = regards,

Mach<= /span>

 = ;

From:= Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, October 23, 2020 10:43 PM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Call for "ISIS Extensions in Support= of Inter-AS MPLS and GMPLS TE" - draft-chen-lsr-isis-rfc5316bis-02

 

This is simple BIS = update to RFC 5316 is required to support IS-IS Inter-AS TE in IPv6 only ne= tworks. The authors have asked for WG adoption.

 <= /o:p>

This begins a two w= eek LSR Working Group Adoption Poll for =93ISIS Extensions in Support of In= ter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering=94 - draft-ch= en-lsr-isis-rfc5316bis-02. The poll will end at 12:00 AM UTC on November 7th, 2020. Please indicate your= support of objection on this list prior to the end of the adoption poll.

 <= /o:p>

Thanks,=

Acee

 <= /o:p>

--_000_BY5PR13MB3048CC56352393F40B51760AE1140BY5PR13MB3048namp_-- From nobody Thu Oct 29 21:13:24 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D813A0DB2; Thu, 29 Oct 2020 21:13:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <160403119768.28882.5601948399724333713@ietfa.amsl.com> Date: Thu, 29 Oct 2020 21:13:17 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-l2bundles-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 04:13:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : Advertising L2 Bundle Member Link Attributes in OSPF Authors : Ketan Talaulikar Peter Psenak Filename : draft-ietf-lsr-ospf-l2bundles-00.txt Pages : 10 Date : 2020-10-29 Abstract: There are deployments where the Layer 3 interface on which OSPF operates is a Layer 2 interface bundle. Existing OSPF advertisements only support advertising link attributes of the Layer 3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle link attribute information about the bundle members is required. This document introduces the ability for OSPF to advertise the link attributes of layer 2 (L2) Bundle members. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospf-l2bundles-00 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-00 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 Oct 29 21:14:57 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB433A0DB2; Thu, 29 Oct 2020 21:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=kCA4eI7m; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MXW03kZL 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 tYp1GoX6VWGW; Thu, 29 Oct 2020 21:14:54 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858DF3A09AC; Thu, 29 Oct 2020 21:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1044; q=dns/txt; s=iport; t=1604031294; x=1605240894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JSA2C+sNY900/6nRXYmyPFGWypINyfJw6BGpZs94/Ac=; b=kCA4eI7m1JmPTKghKQrXLE/7qtTtOeSQ8XxDxlovM11ZJONvI9iFeKWr Sk4NRCgP5gwRUZ6LXaX2sNI3PDDKLGRtc2DqYjN0r6BGj03b/KDmVIXZ7 NiuZLzWxLEktBos9kd2J8UEGId0foP8gihTqQiBNWuap2sQzNeF6cczOS k=; IronPort-PHdr: =?us-ascii?q?9a23=3AkDdpvBJNWY1yG+cJ0dmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKs/h1/ORZ3ArfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBteGMHmf0aUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMCQD5kZtf/4gNJK1iHgEBCxIMQIM?= =?us-ascii?q?hUQdwWS8uCod8A41KmHuCUwNUCwEBAQ0BASMKAgQBAYRKAoIHAiU4EwIDAQE?= =?us-ascii?q?LAQEFAQEBAgEGBHGFYQyFcgEBAQMBEgsdBgEBNwEEBwQCAQgOAwQBAQEeEDI?= =?us-ascii?q?dCAIEAQ0FCBqDBYJLAw4gAQ6iZQKBO4hodIE0gwQBAQWBNwIOQYMYGIIQAwa?= =?us-ascii?q?BOIJyikgbgUE/gVSCTT6CXAEBAwGBXYNIgiynAZEcCoJsiQiSHIMXihCUPpI?= =?us-ascii?q?7DH2Bfoh5lUYCBAIEBQIOAQEFgWsjgVdwFTuCaVAXAg2OH4NxhRSFRHQ4AgY?= =?us-ascii?q?KAQEDCXyMOwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,432,1596499200"; d="scan'208";a="596914211" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Oct 2020 04:14:53 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 09U4ErIq010475 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Oct 2020 04:14:53 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 29 Oct 2020 23:14:53 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 29 Oct 2020 23:14:53 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 29 Oct 2020 23:14:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wc/sb1Qu9ebAXgiPsD5NfADahtHP2VQNqfXVXFqHQyfEZip7FxOu/cMsi4lS9zGKB6eRpKHa7Trfv7vCYc3KG9a5ZnClnb3diSYnxH/T0JnUXWNBTFIbpCFjxyCmzIE82DdO9flISlefkc0NNSGaLIEuq8nwWkDKXMFsUtuxHawjj8RgVZ5Enlxv6MYEsfYvtvMf7u8cKCFXRQCyNcIvnLpqDfqo//8PUtRtZ1cpwdkVDwQEkUDIkLuqGyeC2Y+Vt2zGXZPNV51/n+CQ0bWGQmKbFWMzUYFNcpfyrZjQoSwPyumUcv9sCZsi/jBraLtQ4/JnxGn7FheIhX3Iys6x8w== 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=ZpE5iYMuBNh0Sp6w48+RgCKWq+/qxAJGCo2Y4tmsXuk=; b=NaUrs/tL5LTdML1sOAjeP/QRgzHGcqMgyUOUWelSZ4YxJ7qvrY967jAmwBq6B+2KSeJtxnZpIo/8vTcdF69ncRSE7vEoB9Uoi5Prc+wN4SVB1Bf263gaorEhsXjtcfBlrvsrBa+jrwk5XxVLj4U/7WcUTQGt/mL/wsORkYmHU8FxXDwzF9cqQivBA71ntXWyGc+EnWdQBEPwhrqml+lhTulYvLcSIsWRbQrNhMDwHqpNeb3ABDEhkfIkoz7cvlFDnguedfY8Zdq2CZkU27H2oiRdjONsPvqzTvOBS5FBfuYt9oxYL88a0BUFQdTPTLXQ2XeEMOxhK0BZA9ZjAKMUtg== 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=ZpE5iYMuBNh0Sp6w48+RgCKWq+/qxAJGCo2Y4tmsXuk=; b=MXW03kZLjU+BfKP2gm9LHsBK2/O14uePe9Smpz+QltFiClXhF2WW6vDE8yoCrAlxlnb/QdHCh+rz0X5qAXN6iGO4Nggw3WOg2UOTSfAi4qE4gHQ1LTpAQbQmoznTS50Y9ksnM8PWcjwAVPrc6BtxGQjoPi5pRmuCUGLzgwvT2Vw= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1615.namprd11.prod.outlook.com (2603:10b6:301:c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.28; Fri, 30 Oct 2020 04:14:51 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::d4d5:97f0:17b5:2f77%5]) with mapi id 15.20.3477.035; Fri, 30 Oct 2020 04:14:51 +0000 From: "Ketan Talaulikar (ketant)" To: Christian Hopps , "lsr@ietf.org" CC: "lsr-chairs@ietf.org" , "draft-ketant-lsr-ospf-l2bundles.all@ietf.org" Thread-Topic: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 Thread-Index: AQHWmLQdTktsY4Cyrk21SHl6G08Z+KmvEKkAgACkD5A= Date: Fri, 30 Oct 2020 04:14:51 +0000 Message-ID: References: <2B6DB16A-204C-46C2-A162-2C6E3B3BB96F@chopps.org> <90E57370-1B7B-4EB1-AB5D-3BD8ACD0F7AF@chopps.org> In-Reply-To: <90E57370-1B7B-4EB1-AB5D-3BD8ACD0F7AF@chopps.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [72.163.220.13] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 247f9284-1d59-49d1-5e8d-08d87c8a5957 x-ms-traffictypediagnostic: MWHPR11MB1615: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zFwUIGXRJ2KZnYgp/qqK4RGYvUcqMyJkX+60hpiX776QgR2d0ieqO0DCsBSb3iakgtek3eqBhpboTBbjgQ3FtDbvjMJgys9cBEXsAQdRvm40kSuU12AKRbuaTo8MR129g4qXswiXqPas6wlOKfP75VfGiaR5r6FPam1tNWL7nw+D9IgpXL9/4/v3gCx5xyIsjnzOSLlQ6BEb9G13k0LBPNldMl96/GSMSn9vFqI5lr/VSSUGYQWxkblRQyGpuqsGOREqT1rqbw0ta3Nlx6FLQFpPY23lEYFXk2477nJFgTweff0+lcDj+lghg0oSOw5oducRIcYZ80Dvhu73zrP1DJo620Qaz2LhbPZ/PT3ssRVNOcjJS0OPaLfWO/gwM5wZJVmYPswek5hNUUZI50udEw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(346002)(136003)(376002)(366004)(396003)(52536014)(5660300002)(33656002)(7696005)(86362001)(2906002)(8936002)(26005)(110136005)(316002)(8676002)(478600001)(966005)(54906003)(4326008)(186003)(66476007)(66446008)(64756008)(76116006)(6506007)(53546011)(55016002)(83380400001)(66946007)(71200400001)(9686003)(66556008)(4744005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: swRoG0zI6KbActWq3FH9aBiuGysYL0lZXbWCuvNs4v5V//MmXy3PQ+Bb6BVT00/W+R1s702YoakzJr52Es0ZE15JpNsbIxQmqzQY46wdZpsQqWM7dRR94iVD/lroOj+eusL56BAnM4ANxWnL1AV0LjdbWQiqQQDkQzgoy3lHBjaVff7BGvxi+6r10Nwva0Qa/OYTNd3pNH24nnXg+Pdjb12/ukErZAmFNE5nffMdvIXTyjWYTz1oH8bkNNMQWLNWebgnGoNayh4tmsRgZEhj9DycuRfZz5waTze6Yd4ehZKMlCcF9HzA6dNd0+9YdbDgOEBHcQlLfsB6VPI4VCKtCi4zvLkonDTtJ+TA98mi88RVsKK9V5/g9RFQ6JJZy2Si+JwdrxZHRPCjNzZkbcBts+JEXO8i1Nz3NuYhTGhnKymfA7KkJCWfiqO0ZZO/eLte+XetknyYko/Fl58UrrdtnCgThANaebkcHNzbgM8hEdgB50WlC3N6Q5zezfxx6mx3DR9N0B4gx0fFmctFTgW27/AaRyVVix8rsGq8oCOkNPCzJKnbBcqS1NBkmix00iEOmAAPaEzfOkGPU7gFiMszqYcbUQ4kObtEaWmbOK/u5Hm64w+fO07ivtO98j/vP2dgdqW+qB4p9rJFG3eaDFfUcg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 247f9284-1d59-49d1-5e8d-08d87c8a5957 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2020 04:14:51.8074 (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: EXSqgfZ5pvz0n13MBOSOsTXWusX4qqSb3BhiK0FH4ot7h37Qsm8/KtKDUcNISr7i1iMyRhnfXLnNco9K/9Ct4w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1615 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 04:14:57 -0000 Hi Chris, Thanks for the update and we've just posted https://tools.ietf.org/html/dra= ft-ietf-lsr-ospf-l2bundles-00 Thanks, Ketan -----Original Message----- From: Christian Hopps =20 Sent: 29 October 2020 23:57 To: lsr@ietf.org Cc: Christian Hopps ; lsr-chairs@ietf.org; draft-ketant-= lsr-ospf-l2bundles.all@ietf.org Subject: Re: [Lsr] WG adoption call for draft-ketant-lsr-ospf-l2bundles-01 The document is adopted. Authors, please resubmit as draft-ietf-lsr-ospf-l2bundles-00 Thanks, Chris. > On Oct 2, 2020, at 8:03 AM, Christian Hopps wrote: >=20 > Signed PGP part > This begins a 2 week WG adoption call for the following draft: >=20 > https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-l2bundles/ >=20 > Please indicate your support or objection by October 16, 2020. >=20 > Authors, please respond to the list indicating whether you are aware of a= ny IPR that applies to this draft. >=20 > Thanks, > Chris and Acee. >=20 >=20 From nobody Fri Oct 30 05:36:41 2020 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2053A0E43 for ; Fri, 30 Oct 2020 05:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 tfU-y_tXXm6N for ; Fri, 30 Oct 2020 05:31:06 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2135.outbound.protection.outlook.com [40.107.21.135]) (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 185883A0E3C for ; Fri, 30 Oct 2020 05:31:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KJx4BSBi8T9ssAzbQ8T7hVLpXhyBln2RBIwx7uzFlxtquyRY2Aw5LHaBoTufygdC9PzvWfvl/jkshSwmjRFRs0HhkQRS/7bsj2txybxdhU5hkG8iZE3uEU0a2/K2XlWwhwZvZ1CMnFFRijo4F2+4ZHcJeHeQZv+EPBKTN+W7CFwIcv8zstiR0M8OWWxSyL6kiWegGl+vGTpPUuMiE9hO8kAaVJRI3zKDZMXlPYmmDy1tTCQb34k8HDglQYVXOr2qiLc+UvmAi+9qAisk++T/bYFsEueivfmA4mzH8wRJjun9LH4ZGFhSOJtlsfXTv3cR6h4Aljh+421IrXCtVfGZew== 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=sFtoPynLM60uOKdriI21b49TlawlkV4k4nlKY7sjiYo=; b=TkJlMVLh92ouaqauqBepJacoI1TEXyf8Vom60OUSRPk7nG/PbsHhdjM8b5Etg0boPY4ch79xOPoftcw3paBpL5Hke8GbV+4S96/nSAkTVNpVdH7lxT/jGDomaRgZpXPH577r7CVVTDdbDDuNlapCEcE3wqxHARdKZHUR2bel5FJd4TOhEHO2xc4xX6z6u6tosX0lwnJR1QE81NWzTzbtbmVjEZRJ0fCb+Z8cerwjul2mao3CAlASx4k4vhr93HiBLZZX7Icq6E9ml+P5WZDbwSMrTGMhvjP/DV5fAO7u5xJVN2MdwTGFXBOU0sy2R9Az7/HtciCvamuONSWLb9h0IQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sFtoPynLM60uOKdriI21b49TlawlkV4k4nlKY7sjiYo=; b=WjUNOqOqHJkRUHLVg6tAa/jzrZPHGbORDWVEhfowkayU0KB4512W5g4RDfT6Wt6iw9qndUFjyFQtm6eAwA1NDP3+uG3feEIJ772wWArQYWzl5pTTIh56NhiFw7NhxwW+j6JRsq5bSdpukYjzg5I4lkdYIpQGfhU4SeK9egv+sw0= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB5044.eurprd07.prod.outlook.com (2603:10a6:20b:5d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.14; Fri, 30 Oct 2020 12:31:03 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804%7]) with mapi id 15.20.3499.028; Fri, 30 Oct 2020 12:31:03 +0000 From: tom petch To: "lsr@ietf.org" Thread-Topic: IESG approves mpls-base-yang Thread-Index: AQHWrray2lGUAgH3/EiO5pjIPLxL8w== Date: Fri, 30 Oct 2020 12:31:03 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74a52458-6d56-4dcb-539c-08d87ccfaa9a x-ms-traffictypediagnostic: AM6PR07MB5044: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2331; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f3w5tvXYrsUo19GAvd2TUc5mDW8RJl6QVGh/anEbjVe3oaeMS4YENhVSjmD/OE/BJmANukzymeGeWnY7Vt7M1c9tJIVmVa1wiSXUYFFGSHKSByLMhOZ7zM7FCrZKKWGnuXokmYTPZi41QXpuaVwB3gZdjIrBBDoXvjLlTaREcBdd6Ibb7c79hiepa5KQ1KorV/CVX28QgvXKEu3uMee6dX+SK1cis5YvE/cWXczPi3sjkbNcUl/aS6bKjfVEmhmMWMluaHyBasqez9k+cC5YgyRhllek8DzxC4wF8+fgCeisa4ebqOI8Ll5z+YBPc8v4cBgdr1toAFzPzN8G1P5u0Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(136003)(39860400002)(346002)(376002)(8676002)(8936002)(5660300002)(2906002)(91956017)(66446008)(66946007)(64756008)(6916009)(33656002)(478600001)(558084003)(52536014)(6506007)(76116006)(66556008)(66476007)(9686003)(86362001)(7696005)(26005)(55016002)(316002)(186003)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: /k70cQ+6XVT7pAMSlOuV6SnSYSlVfJ0kQgL0+9Lid55Sn5nvhqV1EHcKOhmk056O1LV4pZv76fJxjCUDOLjRhIVSz/5IMGGlCm5bjvUdH9TKiXEjcp8BjUn8au/jkYYVcq/EubO3m0KjBCj7cSMEVEu0ln6/w+w5h4A5qWaf8XOJl+xoACgJTEEEEccuZCMam50KJK/0LYazay8fRjSyL23vPhGuS35Wg3LfCJhqCFGsuMxZzvg64baITTZe2GNdXTuoKo0USozstIV3aPvt39ngvgT+Id+mKms4Yv+4tDfNoj0LMGAfP7aa2I6dAIT+ptfZUuX+WLhxWKw4P1VZal4m5Q3sJv8MibQajkIMyVHxn/iH1NlSX0wk5YR8aB4fUeiZxq1XDIqqIgNsPGj8c+pxYekBDhXVkIUWwTa+CfYgmVUAxtNgcnHdMrDodRFT/Rj7VYxInrpTzaFHXtTXuLtY+laQnhIOGQkS0uyPlW6olSvDW1hWLHDL0GV4WauXb5WwNvA3AidQ42At3fnFdUIBApytsUFwU91M3D5llKVYJilq/4Fi71eOEEEUoldE2Phb6Ki//31FL9lLA7C4vQD07apuFOT39r/8FB+vZVSog4kgxPf0wHR6lepDqh5cBxicc46NwjPGrDGx5As2GQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74a52458-6d56-4dcb-539c-08d87ccfaa9a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2020 12:31:03.4782 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uXKwGjWUkKeCosmca4JPp+IaDgcoZ5VtZNJ3D1j8D8+g7Z3cCLU+ntrYNUAPHAcY5uEzdeSiH+S6sr3QG+RYPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5044 Archived-At: X-Mailman-Approved-At: Fri, 30 Oct 2020 05:36:40 -0700 Subject: [Lsr] IESG approves mpls-base-yang X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 12:31:09 -0000 Who cares?=0A= =0A= Well it is a MISSREF for bfd-yang which is a MISSREF for ospf-yang inter a= lia so may be those dusty old I-D will come to life and see if they are sti= ll valid or not (some are not:-(. =0A= =0A= Tom Petch= From nobody Sat Oct 31 20:59:25 2020 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8AD3A07DE; Sat, 31 Oct 2020 20:59:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <160420316253.32554.5970532574415053444@ietfa.amsl.com> Date: Sat, 31 Oct 2020 20:59:22 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-lsr-ospf-yang-augmentation-v1-03.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 03:59:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : OSPF YANG Model Augmentations for Additional Features - Version 1 Authors : Acee Lindem Yingzhen Qu Filename : draft-ietf-lsr-ospf-yang-augmentation-v1-03.txt Pages : 29 Date : 2020-10-31 Abstract: This document defines YANG data modules augmenting the IETF OSPF YANG model to provide support for Traffic Engineering Extensions to OSPF Version 3 as defined in RF 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379 and OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-ospf-yang-augmentation-v1-03 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-yang-augmentation-v1-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-yang-augmentation-v1-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/