From nobody Thu Apr 9 19:16:27 2020 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE313A1952; Thu, 9 Apr 2020 19:16:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Joel Halpern via Datatracker To: Cc: anima@ietf.org, last-call@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158648497631.26678.9121665060210659827@ietfa.amsl.com> Reply-To: Joel Halpern Date: Thu, 09 Apr 2020 19:16:16 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 02:16:17 -0000 Reviewer: Joel Halpern Review result: Not Ready Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-anima-autonomic-control-plane-24.txt Reviewer: Joel Halpern Review Date: 9-April-2020 IETF LC End Date: N/A Intended Status: Proposed Standard Summary: I have two major concern about this document that I think should be resolved before publication. The are also a number of minor items that warrant attention. Comments: While quite long, the draft is significantly improved from earlier versions. It does provide significant explanation of its design choices, which is helpful and appreciated. Sometimes this seems to end up more as marketing or promotion instead of explanation, but this is mostly harmless. In particular, I would like to thank the authors and editors for the addition of section 9.3 and its careful discussion of the many issues there. Major Issues: Section 6.10.3.1 on the use of Zone-IDs seems, from the material in A.10.1, to be dependent upon either configuration (which ACP is supposed to avoid) or completely unspecified magic. Having an addressing and routing scheme standardized that is impossible to use seems at variance with appropriate practice. It would be fine to say that provision is made for non-zero Zone-IDs in the hope that future work can find ways to scale further using this. But pretending it is well-defined, but not actually defining it, seems unacceptable. Section 6.12.5.1 on loopback interface is factually wrong. It conflates one particular form of loopback interface with the definition of loopback interfaces. This also leads to the error in the definition section (see minor comment below). (Loopback Interfaces were used long before RFC 4291, and on routers were often used for external communication. This was itself a repurposing of the original loopback interface, 127.0.0.1, which was indeed for internal use.) Minor Issues: It seems distinctly unfortunate that the definition for Data Plane in section 2 explicitly states that this definition is different from that used in other work, including other routing work. This seems a recipe for both confusion and mis-communication among technologists. In the definition of in-band management in section 2, please remove the commentary text on putative fragility. (I actually agree it has some fragility. The discussion does not belong here. This is a definition.) The promotional material may be warranted, if jarring, in other parts of the documents. Not in the definitions please. The definition of a loopback interface in section 2 is wrong. It claims that loopbacks transmit no external traffic. They send and receive lots of external traffic. They merely do so by forwarding the traffic internally to other interfaces. The traffic is external. The particular step of the transmission, if implemented naively, is internal. If we are going to define ACP as a virtual out of band network, I would suggest separating the terms into two definitions. One for true out of band networks (distinct physical links, switches, and ports), and then a definition for virtual out of band network which describes the ACP approximation which creates independence from configuration, but not independence from the physical links. Section 5, bullet 2, talks about a policy as to which peers ACP communication should be established. It would be helpful if this gave a reference or indication as to where such policies would come from. Given the emphasis on zero touch, I presume they are not configured on the node? (This issues was in my review of -13.) Bullet 4 of section 6.1.3 on checking certificates against the CRL / OCSP would seem to be better reworded. I believe the intended requirements i that IF there is ACP connectivity to the CRL / OCSP source, then it should be verified. But that absence of such connectivity should not prevent association formation. (As, if I have read it wright, otherwise we could deadlock the startup process.) In the example in section 6.5 on Channel selection, in steps 7:C1 and 11:C2, Node 1 concludes that it is Bob. However, in steps 12 and 13, the text refers to Node1 (Alice). This seems inconsistent. Section 6.7.1 makes an assertion about the lack of need for MTI of security mechanisms. The earlier explanation was well done and seems sound. This shorter one seems wrong, since without MTI there is no good way to know what ones neighbors may implement. I suggest simply removing this text and replacing it with a backwards reference to the earlier description. (The rest of the section is useful and clear.) In 6.10.3, ACP Zone Addressing Sub-Scheme, the text claims that when zone IDs of 0 are used, the addresses are identifiers, and when non-zero IDs aere used, they are locators. Since in either case the addresses are used for packet forwarding, and the addressing information is propagated in the routing protocol (RPL), this seems to be a misuse of the locator / identifier distinction. And a misuse for no purpose as the distinction is not relevant to the document. (This odd use of "identifier continues in section 6.10.3.1. Identifier is not a synonym of "flat". Just say "flat".) The assertion about looping packets in the later portion of 6.11.1.1 is over-stated. There are other routing protocols that avoid looping-till-ttl without changing the data plane header. I suggest removing the gratuitous comparison with other routing protocols. 6.12.5.1 refers to the ACP addresses as node addresses. Technically, the IPv6 architecture requires that all addresses are associated with interfaces rather than nodes. I would prefer that this draft not needlessly claim to violate that. Section 7.2 (L2 DULL GRASP) seems to be doing something quite useful. I think I see how it would work. The need for some configuration on some switches seems inevitable and acceptable. I think there is one corner case that should be avoided, as it seems likely to create significant complexity for little or no benefit. It seems to me that a switch that is capable of participating in the ACP should either participate in the ACP on all its physical ports, or should not participate in the ACP at all. I would not be surprised if that was the WG intent. But I could not find the text that says this. (Apologies if it is there and I missed it.) Section 9 starts by saying it is informational. But the first paragraph says that some of the content is "necessary" for correct operation. Thus, it seems that some of the content is normative? (I am not sure, but I think the "necessary" material relates to what is needed to be a registrar?) Nits: The second and third paragraphs of section 6.11.1.1 on RPL start with duplicated text, and then go on to say different (complementary) things. There is no need for the repetition. The rank factor in 6.11.1.6 of 100 megabits as the boundary seems a fairly arbitrary choice. It may be that an arbitrary choice was needed. Could something be said? In particular, if someone looks at this 5 years from now, it may seem quite confusing. From nobody Thu Apr 9 21:30:43 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31FD3A1B2F; Thu, 9 Apr 2020 21:30:31 -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 pzRu3lkQEOOV; Thu, 9 Apr 2020 21:30:29 -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 99E553A1B2E; Thu, 9 Apr 2020 21:30:26 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id e16so60200pjp.1; Thu, 09 Apr 2020 21:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SH40sFpHO7nJTkqGNDXQGn2dFy0CYiIQ7CDA3SFTng8=; b=NPezdn8SYl4b11D1hASXUZpRA0/JAEHCpNQTjwc6ydCUzUdC9SB7Z2ZxYxvPfB6/uL ImLAgQdqUvn+FF5ItVsAVURhFjA9n5OqtJHuRyDiG/JNW/nJz1+dG0igWelkwDmfpz7e uVYzezQBhwohINQwzdTMF0lxvNiMMnq4f//44AWr3Ce2olAztgApcza+MBHkCUaCjrXa JU//kU/taH4c14QVuqvfcEYOh4/wzbRehu9ZHWApYbCPSs5OeZQY751lfcJBosNiPQrv mU5ePGBd11BfJpUi2J3xIdM/GyKhzwArVDf9xKDuLIRAHY/rTfORcXqwv3ubVqziaDfL vVqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SH40sFpHO7nJTkqGNDXQGn2dFy0CYiIQ7CDA3SFTng8=; b=ioqvZjNO+AiYMaP1Rsl6uEbPbtQJF2hxue35PeOiEy0bR2vz+lFtFa5vtOTDzx3vwI Tl/KokfDaBE6qlLPcKvst1kdQmmLIdHctYuYKJtjalwj6GBm2s4rotvBDLTiMCCgQB7H sMpsTk3Nrz0BYJC8oDrxvspufGhTg15JkSbKGn+xGhuOvea1dNptvzXQsuibsdwJQ7YQ IMW3Oaa1NDsx4jaLEcAd+TdUn3zzL6S0v8nwjIBcpEiV1Cv6iYqmpH3FXU9G5yA6ZipZ CQPTi7WBYi0Uyvf/B3X8m2JGTT0p8vqTY7ezp6T6wIYlbKRBx/XeydXJjDLaUeFX86Hy rkuQ== X-Gm-Message-State: AGi0PuZMxevAM7yICUXJEq9bqm+Oam4NEJ7KLIClTTIuwdnCPPEFxnX8 m9I+rKsWtsDCiZVZ3a3IlKE+iy0m X-Google-Smtp-Source: APiQypJJ38YtbNr1JRtLB9qPtuYa0FiUYZaJA5cMmnBK2x5nupa2QlWFaAmZPs7JKrrFpGMBin5nsg== X-Received: by 2002:a17:902:9305:: with SMTP id bc5mr2999860plb.127.1586493025441; Thu, 09 Apr 2020 21:30:25 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id w27sm609729pfq.211.2020.04.09.21.30.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2020 21:30:24 -0700 (PDT) To: Joel Halpern , rtg-dir@ietf.org Cc: last-call@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, anima@ietf.org References: <158648497631.26678.9121665060210659827@ietfa.amsl.com> From: Brian E Carpenter Message-ID: <1280ef73-a21c-63d9-3de9-2c4f7e68e10a@gmail.com> Date: Fri, 10 Apr 2020 16:30:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <158648497631.26678.9121665060210659827@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [RTG-DIR] [Anima] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 04:30:32 -0000 Hi Joel, What a great review. I have comments on both your major comments, and an important comment near the bottom of your minor comments. On 10-Apr-20 14:16, Joel Halpern via Datatracker wrote: > Reviewer: Joel Halpern > Review result: Not Ready ...> Summary: > I have two major concern about this document that I think should be > resolved before publication. The are also a number of minor items that > warrant attention. > > Comments: > > While quite long, the draft is significantly improved from earlier versions. > It does provide significant explanation of its design choices, which is helpful > and appreciated. Sometimes this seems to end up more as marketing or promotion > instead of explanation, but this is mostly harmless. > > In particular, I would like to thank the authors and editors for the addition > of section 9.3 and its careful discussion of the many issues there. > > Major Issues: > > Section 6.10.3.1 on the use of Zone-IDs seems, from the material in A.10.1, > to be dependent upon either configuration (which ACP is supposed to avoid) > or completely unspecified magic. Having an addressing and routing scheme > standardized that is impossible to use seems at variance with appropriate > practice. It would be fine to say that provision is made for non-zero > Zone-IDs in the hope that future work can find ways to scale further using > this. But pretending it is well-defined, but not actually defining it, > seems unacceptable. Interesting. I've always read this text (and the Appendix text) to mean that Zone-IDs are indeed reserved for future work, but that a few of their basic properties are defined. Are you suggesting to delete all that, or to add a clear statement that they are currently not fully defined and should not be implemented? > Section 6.12.5.1 on loopback interface is factually wrong. It conflates > one particular form of loopback interface with the definition of loopback > interfaces. This also leads to the error in the definition section (see > minor comment below). (Loopback Interfaces were used long before RFC 4291, > and on routers were often used for external communication. This was itself > a repurposing of the original loopback interface, 127.0.0.1, which was > indeed for internal use.) This text is probably my fault, since back in 2015 I was bugging the authors about VRF terminology and loopback in particular. I searched for and failed to find a generic definition of "loopback" and I also wrote this: >>> Routing people and Linux hackers use "loopback interface" as a term of art. I >>> still think you are wrong, and the restriction you want to impose is that only >>> *secure virtual* interfaces of autonomic nodes carry a routable address. >>> Attaching the addresses to a loopback interface is an implementation >>> mechanism. and in 2017 I wrote this (sorry, but I can't provide a TL;DR version): >>> I'm still not 100% happy with that but 'loopback' is a term of art >>> in our business. According to RFC 4291, the loopback interface is >>> >>>>> a virtual interface (typically called the "loopback >>>>> interface") to an imaginary link that goes nowhere. >>> >>> so basically it is indeed where you can hang an address that does >>> not belong to any specific physical or virtual interface. I find it >>> slightly troubling that this important concept is, as far as I can >>> tell, not defined very well anywhere. I had to break out my copy >>> of Stevens's "TCP/IP Illustrated" to get some clarity. >>> >>> So I don't think ACP nodes are different, actually. This is just >>> an undocumented common practice, as are VRFs. >>> >>> The earliest reference I've found to "loopback interface" is in >>> RFC 1812, which simply assumes that the reader knows what it means. >>> There's some reasonably helpful discussion in RFC 4007, and RFC 6724 >>> says: >>> >>>>> Implementations that wish to support the use of global source >>>>> addresses assigned to a loopback interface MUST behave as if the >>>>> loopback interface originates and forwards the packet. >>> >>> RFC 7404 shows the extent to which hanging an address on the loopback >>> interface is common practice in router operations. (There's also a >>> brief mention of this in RFC 7010, which I had completely forgotten >>> despite being a co-author.) Frankly I'm still a bit unhappy about using the term "loopback interface" because it doesn't seem to me to be relevant to describing external behaviour of a node, and it is very much an implementation artefact that seems to mean slightly different things to different people. > > Minor Issues: > > It seems distinctly unfortunate that the definition for Data Plane in > section 2 explicitly states that this definition is different from that used > in other work, including other routing work. This seems a recipe for both > confusion and mis-communication among technologists. > > In the definition of in-band management in section 2, please remove the > commentary text on putative fragility. (I actually agree it has some > fragility. The discussion does not belong here. This is a definition.) > The promotional material may be warranted, if jarring, in other parts of the > documents. Not in the definitions please. > > The definition of a loopback interface in section 2 is wrong. It claims > that loopbacks transmit no external traffic. They send and receive lots > of external traffic. They merely do so by forwarding the traffic > internally to other interfaces. The traffic is external. The particular > step of the transmission, if implemented naively, is internal. > > If we are going to define ACP as a virtual out of band network, I would > suggest separating the terms into two definitions. One for true out of > band networks (distinct physical links, switches, and ports), and then a > definition for virtual out of band network which describes the ACP > approximation which creates independence from configuration, but not > independence from the physical links. > > Section 5, bullet 2, talks about a policy as to which peers ACP > communication should be established. It would be helpful if this gave a > reference or indication as to where such policies would come from. Given > the emphasis on zero touch, I presume they are not configured on the node? > (This issues was in my review of -13.) > > Bullet 4 of section 6.1.3 on checking certificates against the CRL / OCSP > would seem to be better reworded. I believe the intended requirements i > that IF there is ACP connectivity to the CRL / OCSP source, then it should > be verified. But that absence of such connectivity should not prevent > association formation. (As, if I have read it wright, otherwise we could > deadlock the startup process.) > > In the example in section 6.5 on Channel selection, in steps 7:C1 and > 11:C2, Node 1 concludes that it is Bob. However, in steps 12 and 13, the > text refers to Node1 (Alice). This seems inconsistent. > > Section 6.7.1 makes an assertion about the lack of need for MTI of security > mechanisms. The earlier explanation was well done and seems sound. This > shorter one seems wrong, since without MTI there is no good way to know > what ones neighbors may implement. I suggest simply removing this text and > replacing it with a backwards reference to the earlier description. (The > rest of the section is useful and clear.) > > In 6.10.3, ACP Zone Addressing Sub-Scheme, the text claims that when zone > IDs of 0 are used, the addresses are identifiers, and when non-zero IDs > aere used, they are locators. Since in either case the addresses are used > for packet forwarding, and the addressing information is propagated in the > routing protocol (RPL), this seems to be a misuse of the locator / > identifier distinction. And a misuse for no purpose as the distinction is > not relevant to the document. (This odd use of "identifier continues in > section 6.10.3.1. Identifier is not a synonym of "flat". Just say "flat".) > > The assertion about looping packets in the later portion of 6.11.1.1 is > over-stated. There are other routing protocols that avoid looping-till-ttl > without changing the data plane header. I suggest removing the gratuitous > comparison with other routing protocols. > > 6.12.5.1 refers to the ACP addresses as node addresses. Technically, the > IPv6 architecture requires that all addresses are associated with > interfaces rather than nodes. I would prefer that this draft not > needlessly claim to violate that. > > Section 7.2 (L2 DULL GRASP) seems to be doing something quite useful. I > think I see how it would work. The need for some configuration on some > switches seems inevitable and acceptable. I think there is one corner > case that should be avoided, as it seems likely to create significant > complexity for little or no benefit. It seems to me that a switch that is > capable of participating in the ACP should either participate in the ACP on > all its physical ports, or should not participate in the ACP at all. I > would not be surprised if that was the WG intent. But I could not find the > text that says this. (Apologies if it is there and I missed it.) No. A node which is at the edge of the ACP will by definition have at least one interface that is in the ACP, and at least one interface that is not in the ACP. I can't see any way to avoid that. What you say definitely applies to L2 links: they must be either inside or outside. (But even that gets complicated if running the ACP over a VLAN. Then the statement becomes: each VLAN must be either inside or outside.) Hmm. There's a draft on this topic in the RFC queue, and I am quite sure that ANIMA needs to start new work on the domain membership and boundary issue. Regards, Brian > > Section 9 starts by saying it is informational. But the first paragraph > says that some of the content is "necessary" for correct operation. Thus, > it seems that some of the content is normative? (I am not sure, but I > think the "necessary" material relates to what is needed to be a registrar?) > > Nits: > The second and third paragraphs of section 6.11.1.1 on RPL start with > duplicated text, and then go on to say different (complementary) things. > There is no need for the repetition. > > The rank factor in 6.11.1.6 of 100 megabits as the boundary seems a fairly > arbitrary choice. It may be that an arbitrary choice was needed. Could > something be said? In particular, if someone looks at this 5 years from > now, it may seem quite confusing. > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Apr 9 21:50:25 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FEF3A1B62; Thu, 9 Apr 2020 21:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 PnvfwXkf_S1r; Thu, 9 Apr 2020 21:50:13 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BC23A1B61; Thu, 9 Apr 2020 21:50:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 48z5D51sKpz1ny1n; Thu, 9 Apr 2020 21:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1586494213; bh=Oqyln29nyL8TzCmcA2qw4LWV0ozoOsuTswOIfWyZvGo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Jb+6/Gzqse66aTGcYtA3Ep0iISpyk8jyq3DdNfQzBfCkuf/8NWHiLuMmJVaQvPWbZ 4Lika2IXkJDdRtiSgWspvkrMwD9+/ys4uNlv7UzBUfcCi2kI6W6eVoUJNcMnlHeeOu 0aQ68j1L4Fj+oSQayFHQ6krCzqVS+tBbtA2jchbo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 48z5D43ZQYz1ny1f; Thu, 9 Apr 2020 21:50:12 -0700 (PDT) To: Brian E Carpenter , rtg-dir@ietf.org Cc: last-call@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org, anima@ietf.org References: <158648497631.26678.9121665060210659827@ietfa.amsl.com> <1280ef73-a21c-63d9-3de9-2c4f7e68e10a@gmail.com> From: "Joel M. Halpern" Message-ID: <709d4f5a-69a7-463e-07f3-b11cc3a9e70b@joelhalpern.com> Date: Fri, 10 Apr 2020 00:50:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <1280ef73-a21c-63d9-3de9-2c4f7e68e10a@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [RTG-DIR] [Anima] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 04:50:16 -0000 Thanks Brian. Given the amount of text below, I am going to top-post. On the Zone IDs, personally, I would remove all of the text about non-zero ZoneIDs, and replace it with a simple statement that it is expected to be used for future work on aggregatable addressing to improve scaling. On Loopback, I understand your frustration with the lack of a good definition. Given that IPv6 addressing architecture constraints, you need some sort of interface. In practice, the way loopbacks are used seems to match the need. So I do not object to the usage. just to the definition. It would also be acceptable to simply craft a different term and clearly define it if the usage is sufficiently different from existing practice. On the final minor comment, it was specifically about the section on L2 devices. Maybe something special is needed for the special case of a shared network that is also a border network. But that seems very rare. And getting the L2 switch to do the right packet forwarding for the hybrid case seems an invitation to trouble. Yours, Joel On 4/10/2020 12:30 AM, Brian E Carpenter wrote: > Hi Joel, > > What a great review. I have comments on both your major comments, and an > important comment near the bottom of your minor comments. > > On 10-Apr-20 14:16, Joel Halpern via Datatracker wrote: >> Reviewer: Joel Halpern >> Review result: Not Ready > ...> Summary: >> I have two major concern about this document that I think should be >> resolved before publication. The are also a number of minor items that >> warrant attention. >> >> Comments: >> >> While quite long, the draft is significantly improved from earlier versions. >> It does provide significant explanation of its design choices, which is helpful >> and appreciated. Sometimes this seems to end up more as marketing or promotion >> instead of explanation, but this is mostly harmless. >> >> In particular, I would like to thank the authors and editors for the addition >> of section 9.3 and its careful discussion of the many issues there. >> >> Major Issues: >> >> Section 6.10.3.1 on the use of Zone-IDs seems, from the material in A.10.1, >> to be dependent upon either configuration (which ACP is supposed to avoid) >> or completely unspecified magic. Having an addressing and routing scheme >> standardized that is impossible to use seems at variance with appropriate >> practice. It would be fine to say that provision is made for non-zero >> Zone-IDs in the hope that future work can find ways to scale further using >> this. But pretending it is well-defined, but not actually defining it, >> seems unacceptable. > > Interesting. I've always read this text (and the Appendix text) to mean > that Zone-IDs are indeed reserved for future work, but that a few of > their basic properties are defined. Are you suggesting to delete all > that, or to add a clear statement that they are currently not fully > defined and should not be implemented? > >> Section 6.12.5.1 on loopback interface is factually wrong. It conflates >> one particular form of loopback interface with the definition of loopback >> interfaces. This also leads to the error in the definition section (see >> minor comment below). (Loopback Interfaces were used long before RFC 4291, >> and on routers were often used for external communication. This was itself >> a repurposing of the original loopback interface, 127.0.0.1, which was >> indeed for internal use.) > > This text is probably my fault, since back in 2015 I was bugging the authors > about VRF terminology and loopback in particular. I searched for and > failed to find a generic definition of "loopback" and I also wrote this: > >>>> Routing people and Linux hackers use "loopback interface" as a term of art. I >>>> still think you are wrong, and the restriction you want to impose is that only >>>> *secure virtual* interfaces of autonomic nodes carry a routable address. >>>> Attaching the addresses to a loopback interface is an implementation >>>> mechanism. > > and in 2017 I wrote this (sorry, but I can't provide a TL;DR version): > >>>> I'm still not 100% happy with that but 'loopback' is a term of art >>>> in our business. According to RFC 4291, the loopback interface is >>>> >>>>>> a virtual interface (typically called the "loopback >>>>>> interface") to an imaginary link that goes nowhere. >>>> >>>> so basically it is indeed where you can hang an address that does >>>> not belong to any specific physical or virtual interface. I find it >>>> slightly troubling that this important concept is, as far as I can >>>> tell, not defined very well anywhere. I had to break out my copy >>>> of Stevens's "TCP/IP Illustrated" to get some clarity. >>>> >>>> So I don't think ACP nodes are different, actually. This is just >>>> an undocumented common practice, as are VRFs. >>>> >>>> The earliest reference I've found to "loopback interface" is in >>>> RFC 1812, which simply assumes that the reader knows what it means. >>>> There's some reasonably helpful discussion in RFC 4007, and RFC 6724 >>>> says: >>>> >>>>>> Implementations that wish to support the use of global source >>>>>> addresses assigned to a loopback interface MUST behave as if the >>>>>> loopback interface originates and forwards the packet. >>>> >>>> RFC 7404 shows the extent to which hanging an address on the loopback >>>> interface is common practice in router operations. (There's also a >>>> brief mention of this in RFC 7010, which I had completely forgotten >>>> despite being a co-author.) > > Frankly I'm still a bit unhappy about using the term "loopback interface" > because it doesn't seem to me to be relevant to describing external > behaviour of a node, and it is very much an implementation artefact > that seems to mean slightly different things to different people. > >> >> Minor Issues: >> >> It seems distinctly unfortunate that the definition for Data Plane in >> section 2 explicitly states that this definition is different from that used >> in other work, including other routing work. This seems a recipe for both >> confusion and mis-communication among technologists. >> >> In the definition of in-band management in section 2, please remove the >> commentary text on putative fragility. (I actually agree it has some >> fragility. The discussion does not belong here. This is a definition.) >> The promotional material may be warranted, if jarring, in other parts of the >> documents. Not in the definitions please. >> >> The definition of a loopback interface in section 2 is wrong. It claims >> that loopbacks transmit no external traffic. They send and receive lots >> of external traffic. They merely do so by forwarding the traffic >> internally to other interfaces. The traffic is external. The particular >> step of the transmission, if implemented naively, is internal. >> >> If we are going to define ACP as a virtual out of band network, I would >> suggest separating the terms into two definitions. One for true out of >> band networks (distinct physical links, switches, and ports), and then a >> definition for virtual out of band network which describes the ACP >> approximation which creates independence from configuration, but not >> independence from the physical links. >> >> Section 5, bullet 2, talks about a policy as to which peers ACP >> communication should be established. It would be helpful if this gave a >> reference or indication as to where such policies would come from. Given >> the emphasis on zero touch, I presume they are not configured on the node? >> (This issues was in my review of -13.) >> >> Bullet 4 of section 6.1.3 on checking certificates against the CRL / OCSP >> would seem to be better reworded. I believe the intended requirements i >> that IF there is ACP connectivity to the CRL / OCSP source, then it should >> be verified. But that absence of such connectivity should not prevent >> association formation. (As, if I have read it wright, otherwise we could >> deadlock the startup process.) >> >> In the example in section 6.5 on Channel selection, in steps 7:C1 and >> 11:C2, Node 1 concludes that it is Bob. However, in steps 12 and 13, the >> text refers to Node1 (Alice). This seems inconsistent. >> >> Section 6.7.1 makes an assertion about the lack of need for MTI of security >> mechanisms. The earlier explanation was well done and seems sound. This >> shorter one seems wrong, since without MTI there is no good way to know >> what ones neighbors may implement. I suggest simply removing this text and >> replacing it with a backwards reference to the earlier description. (The >> rest of the section is useful and clear.) >> >> In 6.10.3, ACP Zone Addressing Sub-Scheme, the text claims that when zone >> IDs of 0 are used, the addresses are identifiers, and when non-zero IDs >> aere used, they are locators. Since in either case the addresses are used >> for packet forwarding, and the addressing information is propagated in the >> routing protocol (RPL), this seems to be a misuse of the locator / >> identifier distinction. And a misuse for no purpose as the distinction is >> not relevant to the document. (This odd use of "identifier continues in >> section 6.10.3.1. Identifier is not a synonym of "flat". Just say "flat".) >> >> The assertion about looping packets in the later portion of 6.11.1.1 is >> over-stated. There are other routing protocols that avoid looping-till-ttl >> without changing the data plane header. I suggest removing the gratuitous >> comparison with other routing protocols. >> >> 6.12.5.1 refers to the ACP addresses as node addresses. Technically, the >> IPv6 architecture requires that all addresses are associated with >> interfaces rather than nodes. I would prefer that this draft not >> needlessly claim to violate that. >> >> Section 7.2 (L2 DULL GRASP) seems to be doing something quite useful. I >> think I see how it would work. The need for some configuration on some >> switches seems inevitable and acceptable. I think there is one corner >> case that should be avoided, as it seems likely to create significant >> complexity for little or no benefit. It seems to me that a switch that is >> capable of participating in the ACP should either participate in the ACP on >> all its physical ports, or should not participate in the ACP at all. I >> would not be surprised if that was the WG intent. But I could not find the >> text that says this. (Apologies if it is there and I missed it.) > > No. A node which is at the edge of the ACP will by definition have at > least one interface that is in the ACP, and at least one interface that > is not in the ACP. I can't see any way to avoid that. > > What you say definitely applies to L2 links: they must be either inside > or outside. (But even that gets complicated if running the ACP over a VLAN. > Then the statement becomes: each VLAN must be either inside or outside.) > > Hmm. There's a draft on this topic in the RFC queue, and I am quite > sure that ANIMA needs to start new work on the domain membership and > boundary issue. > > Regards, > Brian > >> >> Section 9 starts by saying it is informational. But the first paragraph >> says that some of the content is "necessary" for correct operation. Thus, >> it seems that some of the content is normative? (I am not sure, but I >> think the "necessary" material relates to what is needed to be a registrar?) >> >> Nits: >> The second and third paragraphs of section 6.11.1.1 on RPL start with >> duplicated text, and then go on to say different (complementary) things. >> There is no need for the repetition. >> >> The rank factor in 6.11.1.6 of 100 megabits as the boundary seems a fairly >> arbitrary choice. It may be that an arbitrary choice was needed. Could >> something be said? In particular, if someone looks at this 5 years from >> now, it may seem quite confusing. >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> From nobody Fri Apr 10 14:27:20 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471E53A0DBD; Fri, 10 Apr 2020 14:27:12 -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 wKiyFBbcIUET; Fri, 10 Apr 2020 14:27:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3CC3A0DBA; Fri, 10 Apr 2020 14:27:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BB29B3897D; Fri, 10 Apr 2020 17:25:22 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8D896E30; Fri, 10 Apr 2020 17:27:00 -0400 (EDT) From: Michael Richardson To: "Joel M. Halpern" , Brian E Carpenter , rtg-dir@ietf.org, last-call@ietf.org, anima@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org In-Reply-To: <709d4f5a-69a7-463e-07f3-b11cc3a9e70b@joelhalpern.com> References: <158648497631.26678.9121665060210659827@ietfa.amsl.com> <1280ef73-a21c-63d9-3de9-2c4f7e68e10a@gmail.com> <709d4f5a-69a7-463e-07f3-b11cc3a9e70b@joelhalpern.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [RTG-DIR] [Anima] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 21:27:12 -0000 --=-=-= Content-Type: text/plain Joel M. Halpern wrote: > On Loopback, I understand your frustration with the lack of a good > definition. Given that IPv6 addressing architecture constraints, you need > some sort of interface. In practice, the way loopbacks are used seems to > match the need. So I do not object to the usage. just to the definition. > It would also be acceptable to simply craft a different term and clearly > define it if the usage is sufficiently different from existing > practice. Reading this thread, I was hoping you might be able to help us with a better definition then :-) We are doing exactly what OSPF and BGP does operationally on every platform that I have every worked on. We are just doing it with RPL. To me, it's *SO* obvious that it goes without saying, so now we are asked to say it, and we get into trouble because nobody before us bothered to say it. > On the final minor comment, it was specifically about the section on L2 > devices. Maybe something special is needed for the special case of a shared > network that is also a border network. But that seems very rare. And getting > the L2 switch to do the right packet forwarding for the hybrid case seems an > invitation to trouble. I'm not happy about any of the L2 text; I would have left it out completely. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6Q5KQACgkQgItw+93Q 3WV6WggAkQ67xL4PMAnmoVCacqSmTK4i3dMxrE5S18OudocacUyZRTovDMv99jx0 NZqMNB/67XF2cQNopqRee9vARgfyr1Qt8LnwGgcG9L72hXV7997QKwX7f7Jmzj6N guaDeIy2V+eZ2y1pxdMLek7wh9EV90kUayyKf/Gn3KXs9cccmgjdnBrPIWE+5PQ+ JtFOdV7FxI7DsVCIBMRNh3qiWOZZO09FlUJ3fF0XAgUmPSf39OoGIHBd9SeXPV+u 7G2RSdlmY9eWmzipJJoH4uk3A/12IUllgWWzvmewwrheBktdTi5H/FE83NyudjT/ GVqI+Mt7a9J7zypO0m4Psc7NBQyJdA== =oiTM -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 10 14:35:17 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2453A0DE5; Fri, 10 Apr 2020 14:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 n2RUyQzOGK0M; Fri, 10 Apr 2020 14:35:09 -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 D10403A0DE3; Fri, 10 Apr 2020 14:35:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 48zWWd4cQ5z1p1sB; Fri, 10 Apr 2020 14:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1586554509; bh=xkIDquolfEgpaJ+Jw8RV8p9GqJIe7xZYza07lvKgX2Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ZEHWy6uWqODtfsti6XiwGhrBmmXz/nKUxE2xAs3NLj0lHnN3QR6wr/c1BC3KUuJQU dQCkSEyL/tM8R9RUyw+3sRov+rS9AKsupVeNFS5WBUY9Jtm9gUF9Q6m2LEsyK8hHRh EPG9aSpm+3V7BmsrDaJljcS5CB0bQf+eFlHE7LK4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 48zWWc4FtJz1nt6j; Fri, 10 Apr 2020 14:35:08 -0700 (PDT) To: Michael Richardson , Brian E Carpenter , rtg-dir@ietf.org, last-call@ietf.org, anima@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org References: <158648497631.26678.9121665060210659827@ietfa.amsl.com> <1280ef73-a21c-63d9-3de9-2c4f7e68e10a@gmail.com> <709d4f5a-69a7-463e-07f3-b11cc3a9e70b@joelhalpern.com> <4750.1586554020@localhost> From: "Joel M. Halpern" Message-ID: <4908ff49-6db8-955b-faf3-26c840abefc6@joelhalpern.com> Date: Fri, 10 Apr 2020 17:35:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <4750.1586554020@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [RTG-DIR] [Anima] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 21:35:11 -0000 I am happy to propose some starting text (I am sure it will need further tuning) as a short definition of a Loopback Interface: Loopback Interface: A logical or virtual representation of connectivity for IP communication. It is distinct from any physical interface on the device. It is typically used to abstract a point of communication from any physical connectivity. If we want to elaborate, we could not that this provides an interface to anchor IPv6 addresses in accordance with the IPv6 addressing architecture. As for the L2 material, if the WG wants to remove it, I would be fine with that. It is clearly supplementary. I am just trying to avoid confusion if we choose to describe it. Yours, Joel On 4/10/2020 5:27 PM, Michael Richardson wrote: > > Joel M. Halpern wrote: > > On Loopback, I understand your frustration with the lack of a good > > definition. Given that IPv6 addressing architecture constraints, you need > > some sort of interface. In practice, the way loopbacks are used seems to > > match the need. So I do not object to the usage. just to the definition. > > It would also be acceptable to simply craft a different term and clearly > > define it if the usage is sufficiently different from existing > > practice. > > Reading this thread, I was hoping you might be able to help us with a better > definition then :-) > > We are doing exactly what OSPF and BGP does operationally on every platform > that I have every worked on. We are just doing it with RPL. > > To me, it's *SO* obvious that it goes without saying, so now we are asked to > say it, and we get into trouble because nobody before us bothered to say it. > > > On the final minor comment, it was specifically about the section on L2 > > devices. Maybe something special is needed for the special case of a shared > > network that is also a border network. But that seems very rare. And getting > > the L2 switch to do the right packet forwarding for the hybrid case seems an > > invitation to trouble. > > I'm not happy about any of the L2 text; I would have left it out completely. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Fri Apr 10 16:03:38 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805893A10B1; Fri, 10 Apr 2020 16:03:28 -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 vgb6BeXJIlK3; Fri, 10 Apr 2020 16:03:27 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 1476A3A10AB; Fri, 10 Apr 2020 16:03:27 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id x3so1378270pfp.7; Fri, 10 Apr 2020 16:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=PT3pGQJvlhqEk/KexV+JKgj68mW1V6s2Iv94UjG5EKM=; b=rKPJ4/dSjCNdk3Oz+ichFUEw4cVvaEgsz6cfkrczNiHITCna3mjVGJ2ef0J4bRDnpx EJWMI6tS6AqgDCMK0JerLIOOMG1LURW4lPlLTE8r5lxWThF8cY0voZJhvD03RJTpoPUg 3YUfmtIAd4SjmSL1ZjtGVDCoYkbOuvbSbCJDPhjJZDrAa69wXvY9Cnw7LuBBddOIWrpI o/keBXN1AJxy4zOdFdUyXAE6inbvi7VD3z0yMf02wilooduxUfVabUaEufVzJdMagbBr nliLgm4G6k5RxR4tORxQduWtRK/U/Ew3d/lEVU60btvInx4VPdjDAbavBUoNiEo7ZAPu 1uEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PT3pGQJvlhqEk/KexV+JKgj68mW1V6s2Iv94UjG5EKM=; b=WOrldln97UJKB50MKJALyNNnBI8jqtVN9IrDpPjMS7ciHBuQCPraAcqDGVuz0PQtkK iYZWHkadeAQa7AceZB9xssVzxl69/eU34NfNoWuohxksBKVqnAMm9uo4kmXrVbVeVzc/ m9f2/TWofgKsHiwdcPF5SgsAmqRDIo8XpvA2E8+wLosPVv6yakfTuqtSA+p3eCkKTYbY 6Z6f3NIl6HK/N82vo8e0gxTcI5eXs6bh6TDYtHRYoxcjakUhThQ5bTHhSTKOOd3D/zTk TjY7I/egd0FdSU2I8vKUptwahZAnr+clUYqF/YmeLwmqRo3OZN1TlOmMYvC9sQD643Mw PuFw== X-Gm-Message-State: AGi0PuYeqOam2oXkgJX3Nc8jywNoP4eaYCjx8nO9jMRVcovdX7kUsuiq plEO2L1xvU8BZPOgWMP6h/1OkJoj X-Google-Smtp-Source: APiQypIc1ijovYQ6Wh1QhV22G+P1TeWMFKInOsJDr8G9ANObUo6Gc0GEM+R/sLPmcyvs5U9NLS0iRQ== X-Received: by 2002:aa7:9104:: with SMTP id 4mr7374303pfh.168.1586559806335; Fri, 10 Apr 2020 16:03:26 -0700 (PDT) Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id mm18sm2679554pjb.39.2020.04.10.16.03.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2020 16:03:25 -0700 (PDT) To: "Joel M. Halpern" , Michael Richardson , rtg-dir@ietf.org, last-call@ietf.org, anima@ietf.org, draft-ietf-anima-autonomic-control-plane.all@ietf.org References: <158648497631.26678.9121665060210659827@ietfa.amsl.com> <1280ef73-a21c-63d9-3de9-2c4f7e68e10a@gmail.com> <709d4f5a-69a7-463e-07f3-b11cc3a9e70b@joelhalpern.com> <4750.1586554020@localhost> <4908ff49-6db8-955b-faf3-26c840abefc6@joelhalpern.com> From: Brian E Carpenter Message-ID: <9b359742-a3ae-351f-9c4e-48f66628f321@gmail.com> Date: Sat, 11 Apr 2020 11:03:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <4908ff49-6db8-955b-faf3-26c840abefc6@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [RTG-DIR] [Anima] Rtgdir last call review of draft-ietf-anima-autonomic-control-plane-24 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 23:03:29 -0000 On 11-Apr-20 09:35, Joel M. Halpern wrote: > I am happy to propose some starting text (I am sure it will need further > tuning) as a short definition of a Loopback Interface: > Loopback Interface: A logical or virtual representation of > connectivity for IP communication. It is distinct from any > physical interface on the device. It is typically used to > abstract a point of communication from any physical connectivity. That would work for me. > If we want to elaborate, we could not that this provides an interface to > anchor IPv6 addresses in accordance with the IPv6 addressing architecture. Right. That's the only thing that's different from the IPv4 case. Brian > As for the L2 material, if the WG wants to remove it, I would be fine > with that. It is clearly supplementary. I am just trying to avoid > confusion if we choose to describe it. > > Yours, > Joel > > > On 4/10/2020 5:27 PM, Michael Richardson wrote: >> >> Joel M. Halpern wrote: >> > On Loopback, I understand your frustration with the lack of a good >> > definition. Given that IPv6 addressing architecture constraints, you need >> > some sort of interface. In practice, the way loopbacks are used seems to >> > match the need. So I do not object to the usage. just to the definition. >> > It would also be acceptable to simply craft a different term and clearly >> > define it if the usage is sufficiently different from existing >> > practice. >> >> Reading this thread, I was hoping you might be able to help us with a better >> definition then :-) >> >> We are doing exactly what OSPF and BGP does operationally on every platform >> that I have every worked on. We are just doing it with RPL. >> >> To me, it's *SO* obvious that it goes without saying, so now we are asked to >> say it, and we get into trouble because nobody before us bothered to say it. >> >> > On the final minor comment, it was specifically about the section on L2 >> > devices. Maybe something special is needed for the special case of a shared >> > network that is also a border network. But that seems very rare. And getting >> > the L2 switch to do the right packet forwarding for the hybrid case seems an >> > invitation to trouble. >> >> I'm not happy about any of the L2 text; I would have left it out completely. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > From nobody Wed Apr 15 09:37:29 2020 Return-Path: X-Original-To: rtg-dir@ietf.org Delivered-To: rtg-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C53113A0CDA; Wed, 15 Apr 2020 09:36:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles via Datatracker To: Cc: idr@ietf.org, last-call@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158696856575.24074.9062191460091207808@ietfa.amsl.com> Reply-To: Ines Robles Date: Wed, 15 Apr 2020 09:36:05 -0700 Archived-At: Subject: [RTG-DIR] Rtgdir telechat review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 16:36:06 -0000 Reviewer: Ines Robles Review result: Has Nits Review type: rtgdir - Telechat review Requested version for review: 20 Deadline: 2020-04-15 Reviewer: Ines Robles Summary: This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. It also specifies BGP Extended Community encoding formats. This document obsoletes both RFC5575 and RFC7674. I found the document clear and complete. Some minor nits are detailed below. Major issues: Not found Minor issues: Not found Nits: 1- In the Introduction, it would be nice to mention how this draft obsoletes RFC7674 and point to appendix B when referring obsoleting RFC5575. For example, This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575], whose differences can be found in Appendix B. This document obsoletes also "Clarification of the Flowspec Redirect Extended Community"[RFC7674] due to this document includes..... - please expand iBGP --> Internal BGP (iBGP) 2- Section 4.2.1.1 in "a - AND bit:..." 2.1 - "the previous term" refers to a component? 2.2 -nit: "...unset and and MUST..." => "...unset and MUST..." 3-nit Section 5: "...this draft specifies..." if it becomes RFC it would be nice to read "..this document specifies.." Thanks for this document, Ines. From nobody Fri Apr 17 00:39:00 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C513A0FA6; Fri, 17 Apr 2020 00:38:54 -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 McgVUi0I6NyR; Fri, 17 Apr 2020 00:38:49 -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 ABD933A0FA3; Fri, 17 Apr 2020 00:38:49 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3FD819EA79965F75B384; Fri, 17 Apr 2020 08:38:47 +0100 (IST) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 17 Apr 2020 08:38:46 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.249]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Fri, 17 Apr 2020 15:38:42 +0800 From: Mach Chen To: "" CC: "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" , 'IDR List' Thread-Topic: RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt Thread-Index: AdYUgufIha3uMI7HSMyOkGGdwgKyaQ== Date: Fri, 17 Apr 2020 07:38:41 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:38:54 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRp bmctbXNkLTE2LnR4dA0KUmV2aWV3ZXI6IE1hY2ggQ2hlbg0KUmV2aWV3IERhdGU6IEFwcmlsIDE3 LCAyMDIwIA0KSUVURiBMQyBFbmQgRGF0ZTogDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBU cmFjaw0KDQpTdW1tYXJ5Og0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBk b2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlv bi4NCg0KQ29tbWVudHM6DQpUaGlzIGRvY3VtZW50IGlzIGNsZWFybHkgd3JpdHRlbiBhbmQgZWFz eSB0byB1bmRlcnN0YW5kLg0KDQpNYWpvciBJc3N1ZXM6DQpObyBtYWpvciBpc3N1ZXMgZm91bmQu DQoNCk1pbm9yIElzc3VlczoNClRoZSBOb2RlIE1TRCBUTFYgYW5kIExpbmsgTVNEIFRMViBhcmUg ZGVzaWduZWQgdG8gYmUgYWJsZSB0byBjYXJyeSBtdWx0aXBsZSBNU0RzLiBJIGd1ZXNzIHRoaXMg aXMgZGVzaWduZWQgZm9yIGZ1dHVyZSBleHRlbnNpYmlsaXR5LCB3aGVyZSBhIE5vZGUgbWF5IGhh dmUgbXVsdGlwbGUgdHlwZXMgb2YgTVNELCByaWdodD8gQnV0IGZvciBlYWNoIHR5cGUsIGlzIGl0 IGFsbG93ZWQgdG8gY2FycnkgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIE1TRC1UeXBlL01TRC1WYWx1 ZSBwYWlyIG9yIG9ubHkgb25lIGluc3RhbmNlPyBGb3Igd2hpY2hldmVyIGNhc2UsIHRoZXJlIG5l ZWQgc29tZSB0ZXh0IHRvIGRlc2NyaWJlIHRoZSBydWxlIGFib3V0IHRoZSBzZW5kaW5nIGFuZCBy ZWNlaXZpbmcgcHJvY2VkdXJlcy4gRm9yIGV4YW1wbGUsIHdoZW4gbXVsdGlwbGUgaW5zdGFuY2Vz IGFsbG93ZWQsIGhvdyBkb2VzIGEgbm9kZSBkZWNpZGUgd2hpY2ggaW5zdGFuY2UgdGFrZXMgZWZm ZWN0OyBpZiBvbmx5IG9uZSBpbnN0YW5jZSBhbGxvd2VkIGFuZCBtdWx0aXBsZSBpbnN0YW5jZXMg cmVjZWl2ZWQsIGhvdyB0byBoYW5kbGUgdGhpcywgZGlzY2FyZCB0aGUgd2hvbGUgVExWLCBvciBv bmx5IHRoZSBmaXJzdCBpbnN0YW5jZSB0YWtlcyBlZmZlY3QgYW5kIHRoZSByZXN0IGlnbm9yZWQu ICANCg0KTml0czoNCjEuIA0KU2VjdGlvbiAxLA0Kcy9sZWFybi9sZWFybnMNCg0KMi4NClNlY3Rp b24gMyBhbmQgU2VjdGlvbiA0Og0KVGhlIFRMViBmb3JtYXQgb2YgTm9kZS9MaW5rIE1TRCBpcyBk ZWZpbmVkIGFzIGZvbGxvd3M6DQogICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAg ICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgfCAgICAgICAgICAgICAgVHlwZSAgICAgICAgICAgICB8ICAgICAgICAgICAgIExl bmd0aCAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICBNU0QtVHlwZSAgIHwg IE1TRC1WYWx1ZSAgICB8ICBNU0QtVHlwZS4uLiAgfCAgTVNELVZhbHVlLi4uIHwNCiAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCg0KU2luY2UgdGhlIE1TRC1UeXBlL01TRC1WYWx1ZSBwYWlycyBhcmUgdmFyaWFibGUg aW4gbGVuZ3RoLCB0aGUgYWJvdmUgZGVmaW5pdGlvbiBkb2VzIG5vdCByZWZsZWN0IHRoaXMsIHN1 Z2dlc3QgdG8gY2hhbmdlIHRoZSBmaWd1cmUgYXMgYmVsb3c6DQogICAgICAwICAgICAgICAgICAg ICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDENCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgVHlwZSAgICAgICAgICAg ICB8ICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg Ly8gICAgTVNELVR5cGUgICB8ICBNU0QtVmFsdWUgICAgfCAgTVNELVR5cGUuLi4gIHwgIE1TRC1W YWx1ZS4uLiAvLw0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCg== From nobody Fri Apr 17 00:49:47 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F003A0FC9; Fri, 17 Apr 2020 00:49:39 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4JLap4Wcnvu; Fri, 17 Apr 2020 00:49:37 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (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 70B413A0FC4; Fri, 17 Apr 2020 00:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=yV3ICeLj5vrJjWVG9pVTOfuoc9FaeYpkNk1I9+E7wSY=; b=qnFw0PAeUs1f6ntRTJYWMHwe9L +d68/4LxSbYcLtuAAdqUgQuEnMNxMFJ3/j+N6C3j6mxHSLQNRzbhqPeW2VXlbMNWORcekScOF4Oqm eThRUnVvxTXdLuVeqApZJm0zvBB/2HjBJW5wpHnUu7NkoBBAFdymRqbIR9FCVdpe/SDAdwwwg1H02 jg8mBF/hqpiml+IjOHYqwsJWZ9CIfZADfKX8zZTV46WTLITQC7MkPCSsnWMuwbdaBE+3Q0rmAj0Y6 8svVnV4yf55qhzG1bbBIzr18tcJKYTi7GjYecrQLMvnw9ODe4/c+4OXd+kfJ481uExvbo2YXLiMID qrZ2tNIA==; Received: from 213-225-13-127.nat.highway.a1.net ([213.225.13.127] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPLkk-0001tJ-5C; Fri, 17 Apr 2020 09:49:35 +0200 From: Christoph Loibl Message-Id: <84E0C985-EC91-47B3-B0C2-62819F017C2F@tix.at> Content-Type: multipart/alternative; boundary="Apple-Mail=_DBBB7276-1033-4180-8DA1-0706505170CA" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 17 Apr 2020 09:49:32 +0200 In-Reply-To: <158696856575.24074.9062191460091207808@ietfa.amsl.com> Cc: rtg-dir@ietf.org, idr@ietf.org, last-call@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org To: Ines Robles References: <158696856575.24074.9062191460091207808@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Fri, 17 Apr 2020 09:49:34 +0200 Archived-At: Subject: Re: [RTG-DIR] [BULK] Rtgdir telechat review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:49:40 -0000 --Apple-Mail=_DBBB7276-1033-4180-8DA1-0706505170CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ines, Thanks for your review. According to your review I made the following = changes to the document which is available now as revision -22: > On 15.04.2020, at 18:36, Ines Robles via Datatracker = wrote: >=20 > Reviewer: Ines Robles > Review result: Has Nits >=20 > Review type: rtgdir - Telechat review > Requested version for review: 20 > Deadline: 2020-04-15 > Reviewer: Ines Robles >=20 ... > Nits: >=20 > 1- In the Introduction, it would be nice to mention how this draft = obsoletes > RFC7674 and point to appendix B when referring obsoleting RFC5575. >=20 > For example, This document obsoletes "Dissemination of Flow = Specification > Rules" [RFC5575], whose differences can be found in Appendix B. This = document > obsoletes also "Clarification of the Flowspec Redirect Extended > Community"[RFC7674] due to this document includes..... >=20 > - please expand iBGP --> Internal BGP (iBGP) >=20 <--=20 Tracked via issue #165: = https://github.com/stoffi92/rfc5575bis/issues/165 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/e8e779a38e35bd53111bf3787b50= 16503431a173 Introduction modified as suggested: ``` This document obsoletes "Dissemination of Flow Specification Rules" [RFC5575], the differences can be found in Appendix B. This document also obsoletes "Clarification of the Flowspec Redirect Extended Community" [RFC7674] since it incorporates the encoding of the BGP Flow Specification Redirect Extended Community in Section 7.4. ``` iBGP - changed as suggested. --> > 2- Section 4.2.1.1 >=20 > in "a - AND bit:..." > 2.1 - "the previous term" refers to a component? > 2.2 -nit: "...unset and and MUST..." =3D> "...unset and MUST..." >=20 <--=20 Tracked via issue #166: = https://github.com/stoffi92/rfc5575bis/issues/166 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/5a5b90085b5375828e8b758e6ee1= a11bc2a59994 ad 2.1.: Actually it is the result of the previous {op, value} pair = (within a component). Usually components (defined in the next section) = are a list of muliple {op, value} pairs. The new changed text makes it a = little clearer: ``` a - AND bit: If unset, the result of the previous {op, value} pair is logically ORed with the current one. If set, the operation is a logical AND. =20 ``` --> > 3-nit Section 5: "...this draft specifies..." if it becomes RFC it = would be > nice to read "..this document specifies.." <--=20 Tracked via issue #167: = https://github.com/stoffi92/rfc5575bis/issues/167 Commit mention: = https://github.com/stoffi92/rfc5575bis/commit/6762310b2f3035b12a82e3bf15f7= 78a15ad969fa Solved as suggested --> Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at --Apple-Mail=_DBBB7276-1033-4180-8DA1-0706505170CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Ines,

Thanks for your review. According to your review I made the = following changes to the document which is available now as revision = -22:


On 15.04.2020, at 18:36, Ines Robles via Datatracker <noreply@ietf.org> = wrote:

Reviewer: Ines Robles
Review result: Has = Nits

Review type: rtgdir - Telechat = review
Requested version for review: 20
Deadline: 2020-04-15
Reviewer: Ines Robles

...

 Nits:

1- In the = Introduction, it would be nice to mention how this draft obsoletes
RFC7674 and point to appendix B when referring obsoleting = RFC5575.

For example, This document = obsoletes "Dissemination of Flow Specification
Rules" = [RFC5575], whose differences can be found in Appendix B. This = document
obsoletes also "Clarification of the Flowspec = Redirect Extended
Community"[RFC7674] due to this document = includes.....

- please expand iBGP --> = Internal BGP  (iBGP)


<-- 
Tracked via issue #165: = https://github.com/stoffi92/rfc5575bis/issues/165
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/e8e779a38e35bd531= 11bf3787b5016503431a173

Introduction = modified as suggested:
```
   This = document obsoletes "Dissemination of Flow Specification Rules"
   [RFC5575], the differences can be found in = Appendix B.  This document
   also = obsoletes
   "Clarification of the Flowspec = Redirect Extended Community" [RFC7674]
   since = it incorporates the encoding of the BGP Flow Specification
   Redirect Extended Community in Section 7.4.
```

iBGP - changed as = suggested.

-->

2- Section 4.2.1.1

in "a -  AND bit:..."
2.1 - = "the previous term" refers to a component?
2.2 -nit: = "...unset and and MUST..." =3D> "...unset and MUST..."


<-- 
Tracked via issue #166: = https://github.com/stoffi92/rfc5575bis/issues/166
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/5a5b90085b5375828= e8b758e6ee1a11bc2a59994

ad 2.1.: = Actually it is the result of the previous {op, value} pair (within a = component). Usually components (defined in the next section) are a list = of muliple {op, value} pairs. The new changed text makes it a little = clearer:

```
   a - =  AND bit: If unset, the result of the previous {op, value} pair
      is logically ORed with the current one. =  If set, the operation is
      a = logical AND.  
```
-->

3-nit Section 5: "...this = draft specifies..." if it becomes RFC it would be
nice to = read "..this document specifies.."

<-- 
Tracked via issue #167: https://github.com/stoffi92/rfc5575bis/issues/167
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/6762310b2f3035b12= a82e3bf15f778a15ad969fa

Solved as = suggested
-->

Cheers

Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | = PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at


= --Apple-Mail=_DBBB7276-1033-4180-8DA1-0706505170CA-- From nobody Fri Apr 17 01:08:16 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7A03A0FFE; Fri, 17 Apr 2020 01:08:07 -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=googlemail.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 wDP5MZ0JreaM; Fri, 17 Apr 2020 01:08:05 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 6B4453A101A; Fri, 17 Apr 2020 01:07:52 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id c23so354540vkc.0; Fri, 17 Apr 2020 01:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=26wMrjmiS/AHCVcBLqU5eSjUVBprvNjKeRY5Wd2TWFo=; b=VJD9uLAcLbYqYnEG+3YNdE1FwflwnFByrfXxxUo2365PwVpYRrvglugBZwusdNUoyX HUGW1AJ7zD4oD62WmVI1ypwzHS4DOOhdfsqPtYXY9HnF3W662MTYPX7GVAAh5pnKYdle A7zjF0cMJQzv/UrTQxLBP5BaBPikRw3jFCQS13uGOJdcaTw3JOBHN83Yheycx2HGPBkS GbxSZ2CncZOBRheDGfpZua9lO9o1mA18zslf+NfsPTTG6VO6dYHtFJ3jtJUDJGfY28Wg tf9L7UBGGuRU4lsAs0emIOL2dC1MhYT6lkJY1hkqwoy6uDiJ/0VzN6tbMYGzCMMgvYHj BE3w== 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=26wMrjmiS/AHCVcBLqU5eSjUVBprvNjKeRY5Wd2TWFo=; b=L6t6E3m3r4K4qs/jmb1Fil+Z0oyO+e+OChigjuwiJbjw3/Kw+b6jnNQk/9+hBub6nA KuXFCKa0xOpqidKhMnl6NNnQlj34fHg3/DSu0LmVvRRT+8KbQlK3Pp6WytFWGY2FV8zl cT+pYcSdKqmwYtko7oIGzqfR+3iI5lRC5n+n5cBcHGZ7I5TIUZ4zFNqtMzBGv3E7MUCf Il0fdbUfsZcCZlCe20B+04N9SJy+jgAFFm7Jkmmy2J2s5OOA064zoqhqmg1uvflMWAO3 ryYTzDk2tsMs7vmmORfpu8wldLmsYVAk+DyvNCSVeS7eaBLbdecD2GrFvs3qDYamDdB+ wk5g== X-Gm-Message-State: AGi0PuYmPkDzxneOzGtxl+SJ9kjpGjsuwlCykQSiYyhP95q+EK106zv3 HIArfL8GWRlETJIrn5pVG1H7w7OmUcnFHzI+VDiOXFsK X-Google-Smtp-Source: APiQypLHvpjr247fkOHJ9h73lArsnDGOhTk+vXDu2Vp+8ZgnnO21tX8H+hObEx958n9HJ1ZCl/6+0Ptzt8S2BvSfksI= X-Received: by 2002:a1f:2a87:: with SMTP id q129mr1485976vkq.90.1587110871307; Fri, 17 Apr 2020 01:07:51 -0700 (PDT) MIME-Version: 1.0 References: <158696856575.24074.9062191460091207808@ietfa.amsl.com> <84E0C985-EC91-47B3-B0C2-62819F017C2F@tix.at> In-Reply-To: <84E0C985-EC91-47B3-B0C2-62819F017C2F@tix.at> From: Ines Robles Date: Fri, 17 Apr 2020 11:07:15 +0300 Message-ID: To: Christoph Loibl Cc: rtg-dir@ietf.org, idr@ietf.org, last-call@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000b4182505a3780bd1" Archived-At: Subject: Re: [RTG-DIR] [BULK] Rtgdir telechat review of draft-ietf-idr-rfc5575bis-20 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 08:08:08 -0000 --000000000000b4182505a3780bd1 Content-Type: text/plain; charset="UTF-8" Thank you very much Christoph for addressing my comments. Have a nice day, Ines. On Fri, Apr 17, 2020 at 10:49 AM Christoph Loibl wrote: > Hi Ines, > > Thanks for your review. According to your review I made the following > changes to the document which is available now as revision -22: > > > On 15.04.2020, at 18:36, Ines Robles via Datatracker > wrote: > > Reviewer: Ines Robles > Review result: Has Nits > > Review type: rtgdir - Telechat review > Requested version for review: 20 > Deadline: 2020-04-15 > Reviewer: Ines Robles > > ... > > Nits: > > 1- In the Introduction, it would be nice to mention how this draft > obsoletes > RFC7674 and point to appendix B when referring obsoleting RFC5575. > > For example, This document obsoletes "Dissemination of Flow Specification > Rules" [RFC5575], whose differences can be found in Appendix B. This > document > obsoletes also "Clarification of the Flowspec Redirect Extended > Community"[RFC7674] due to this document includes..... > > - please expand iBGP --> Internal BGP (iBGP) > > > <-- > Tracked via issue #165: https://github.com/stoffi92/rfc5575bis/issues/165 > Commit mention: > https://github.com/stoffi92/rfc5575bis/commit/e8e779a38e35bd53111bf3787b5016503431a173 > > Introduction modified as suggested: > ``` > This document obsoletes "Dissemination of Flow Specification Rules" > [RFC5575], the differences can be found in Appendix B. This document > also obsoletes > "Clarification of the Flowspec Redirect Extended Community" [RFC7674] > since it incorporates the encoding of the BGP Flow Specification > Redirect Extended Community in Section 7.4. > ``` > > iBGP - changed as suggested. > > --> > > 2- Section 4.2.1.1 > > in "a - AND bit:..." > 2.1 - "the previous term" refers to a component? > 2.2 -nit: "...unset and and MUST..." => "...unset and MUST..." > > > <-- > Tracked via issue #166: https://github.com/stoffi92/rfc5575bis/issues/166 > Commit mention: > https://github.com/stoffi92/rfc5575bis/commit/5a5b90085b5375828e8b758e6ee1a11bc2a59994 > > ad 2.1.: Actually it is the result of the previous {op, value} pair > (within a component). Usually components (defined in the next section) are > a list of muliple {op, value} pairs. The new changed text makes it a little > clearer: > > ``` > a - AND bit: If unset, the result of the previous {op, value} pair > is logically ORed with the current one. If set, the operation is > a logical AND. > ``` > --> > > 3-nit Section 5: "...this draft specifies..." if it becomes RFC it would be > nice to read "..this document specifies.." > > > <-- > Tracked via issue #167: https://github.com/stoffi92/rfc5575bis/issues/167 > Commit mention: > https://github.com/stoffi92/rfc5575bis/commit/6762310b2f3035b12a82e3bf15f778a15ad969fa > > Solved as suggested > --> > > Cheers > > Christoph > > -- > Christoph Loibl > c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > > --000000000000b4182505a3780bd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much Christoph for addressing my comments.<= div>
Have a nice day,

Ines.

On = Fri, Apr 17, 2020 at 10:49 AM Christoph Loibl <c@tix.at> wrote:
Hi Ines,

Thanks for your review. According to your review I made th= e following changes to the document which is available now as revision -22:=


On 15.04.2020, at 18:36, Ines Roble= s via Datatracker <noreply@ietf.org> wrote:

Reviewer: Ines RoblesReview result: Has Nits

Review type: rtgdir - Telechat review
R= equested version for review: 20
Deadline: 2020-04-15
Reviewer: Ines R= obles

...

=C2=A0Nits:

1- In the Introduction, it would be nic= e to mention how this draft obsoletes
RFC7674 and point to appendix B wh= en referring obsoleting RFC5575.

For example, This document obsolete= s "Dissemination of Flow Specification
Rules" [RFC5575], whose= differences can be found in Appendix B. This document
obsoletes also &q= uot;Clarification of the Flowspec Redirect Extended
Community"[RFC7= 674] due to this document includes.....

- please expand iBGP --> Internal BGP = =C2=A0(iBGP)


<--=C2= =A0
Tracked via issue #165: https://github.com/stoffi92/rfc5575bis/= issues/165
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/e8e779a38e35bd53111bf3787b50= 16503431a173

Introduction modified as suggested:
```
=C2= =A0 =C2=A0This document obsoletes "Dissemination of Flow Specification= Rules"
=C2=A0 =C2=A0[RFC5575], the differences can be found in App= endix B.=C2=A0 This document
=C2=A0 =C2=A0also obsoletes
=C2=A0 =C2= =A0"Clarification of the Flowspec Redirect Extended Community" [R= FC7674]
=C2=A0 =C2=A0since it incorporates the encoding of the BGP Flow = Specification
=C2=A0 =C2=A0Redirect Extended Community in Section 7.4.```

iBGP - changed as suggested.

-->

<= /div>
2- Section 4.2.1.1

in "= ;a - =C2=A0AND bit:..."
2.1 - "the previous term" refers = to a component?
2.2 -nit: "...unset and and MUST..." =3D> &= quot;...unset and MUST..."


<--=C2=A0
Tracked via issue #166: https://github.com/st= offi92/rfc5575bis/issues/166
Commit mention: https://github.com/stoffi92/rfc5575bis/commit/5a5b90085b= 5375828e8b758e6ee1a11bc2a59994

ad 2.1.: Actually it is the resul= t of the previous {op, value} pair (within a component). Usually components= (defined in the next section) are a list of muliple {op, value} pairs. The= new changed text makes it a little clearer:

```
=C2=A0 =C2=A0a -= =C2=A0AND bit: If unset, the result of the previous {op, value} pair
= =C2=A0 =C2=A0 =C2=A0 is logically ORed with the current one.=C2=A0 If set, = the operation is
=C2=A0 =C2=A0 =C2=A0 a logical AND. =C2=A0
```
--= >

3-nit Sect= ion 5: "...this draft specifies..." if it becomes RFC it would be=
nice to read "..this document specifies.."

<--=C2=A0
Tracked via issue #167: https= ://github.com/stoffi92/rfc5575bis/issues/167
Commit mention: https://github.com/stoffi92/rfc5575bis/c= ommit/6762310b2f3035b12a82e3bf15f778a15ad969fa

Solved as suggest= ed
-->

Cheers

Christo= ph

--=C2=A0
Christoph Loibl
c@tix.at=C2=A0| CL8-RIPE | PGP= -Key-ID:=C2=A00x4B2C0055 |=C2=A0http://www.nextlayer.at


=
--000000000000b4182505a3780bd1-- From nobody Fri Apr 17 14:09:01 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F863A060A; Fri, 17 Apr 2020 14:08:43 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SnbYdt9r-MC; Fri, 17 Apr 2020 14:08:38 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 397A33A05A4; Fri, 17 Apr 2020 14:08:37 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id k13so3392673wrw.7; Fri, 17 Apr 2020 14:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=AInDLumEJ9y9QQtm9TXTH7Bw0lLekZp1HhrVq+V7Y/c=; b=pqr/FmlLHFi6kiDnXW3XOAJeqidDBWCpgZVkDRA/5XPv+jqrFJVnw4zxiCJv3tqJFz B0KL34JQJ/wY08T7OKAHuwkbkGdCe4wgwCaDrtMo/AxcWrpMyzKe48AG3byMWkWGtH+i I6IpKy5eUuY2PzaLmylg/DULvW7re8RViE+4OohyToxFvEQP7aNDxgZHaY3GG6DkgbAi nPzWSz7A0VC0kSfRwP0Ph6eph8DPQX/WWNzDvZcz/MNwjkNOtB+Ifhmn5cS8V9irB9rU eE8NF1M/bbdtQaHCdrYWYJinBg0FbexrhA2w5c1twJ/B1vqdz7IosHlWj967B1Sh/zdk 3ftw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=AInDLumEJ9y9QQtm9TXTH7Bw0lLekZp1HhrVq+V7Y/c=; b=G5l3Igp2rivf+zeXBFdFZ5csHPapq0Ols4jQCycrkXgK648VkhAeo4KIjoihTbyW3w 89SarDUZmGkvD2PWZ7qFvVFUKvxkjnGrNddE6JfoJwJPPyu6HyMKCEAy+iINJ09FMVvq d4aUyaiuSNPBKd8F/ufPVt95J3A2rzYY8c9csyiafdjj8m+o6mpc+vgaLAC/TLi/L2cu 234jGU1CMJlFPcM8IK9Nug2C0a/wRXfIf3+1IW/OwnJL8v8B7nVmeB2zkMzVhZQkLe6V 1yYNHb1ikliDVMP5nNMIGyUt4hZTOkzSUykwfpQM89D2OFXNASWLzpvmC3v5TdaNKtZ3 /Sbw== X-Gm-Message-State: AGi0PubY2T1BHeLxFAfGKdg7Yd1DZVQDsN4Dn/KxUq31+/3jySL0MdZz t0AcEEC/ng221kJ9QYSvPmTC+GKeQZGQ3WuOKywCsCjT X-Google-Smtp-Source: APiQypI+5varLGUWVnL8mi3qqJL0x+wQ0KHAVl/yF80w6HVSZWbPw2ZlaggFdre+6IcDOeBGupaM8kgljSUhyEUEobk= X-Received: by 2002:a5d:65c4:: with SMTP id e4mr5416059wrw.147.1587157714495; Fri, 17 Apr 2020 14:08:34 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 17 Apr 2020 14:08:33 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 17 Apr 2020 14:08:33 -0700 Message-ID: To: "" , Mach Chen Cc: "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" , IDR List , "rtg-dir@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c6706205a382f366" Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 21:08:44 -0000 --000000000000c6706205a382f366 Content-Type: text/plain; charset="UTF-8" Mach: Hi! How are you? Thanks for the review!! Keep in mind that BGP-LS simply transports the information from the IGPs, so the ability to carry multiple instances/multiple values depends on the specification of the MSD itself, and any rules in the corresponding IGP RFCs. IOW, specifying that behavior for BGP-LS in this document is not needed. Take care! Alvaro. On April 17, 2020 at 3:38:55 AM, Mach Chen (mach.chen@huawei.com) wrote: Minor Issues: The Node MSD TLV and Link MSD TLV are designed to be able to carry multiple MSDs. I guess this is designed for future extensibility, where a Node may have multiple types of MSD, right? But for each type, is it allowed to carry multiple instances of MSD-Type/MSD-Value pair or only one instance? For whichever case, there need some text to describe the rule about the sending and receiving procedures. For example, when multiple instances allowed, how does a node decide which instance takes effect; if only one instance allowed and multiple instances received, how to handle this, discard the whole TLV, or only the first instance takes effect and the rest ignored. --000000000000c6706205a382f366 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Mach:

Hi!=C2=A0 How are you?

Thanks for the review!!

Keep in mind that BGP-LS simply transports the infor= mation from the IGPs, so the ability to carry multiple instances/multiple v= alues depends on the specification of the MSD itself, and any rules in the = corresponding IGP RFCs.=C2=A0 IOW, specifying that behavior for BGP-LS in t= his document is not needed.


Take care!

Alvaro= .

On April 17, 2020 at 3:38:55 AM, Mach C= hen (mach.chen@huawei.com) wrot= e:

Minor Issues:=C2=A0
The Node MSD TLV and Link MSD TLV are designed t= o be able to carry multiple MSDs. I guess this is designed for future exten= sibility, where a Node may have multiple types of MSD, right? But for each = type, is it allowed to carry multiple instances of MSD-Type/MSD-Value pair = or only one instance? For whichever case, there need some text to describe = the rule about the sending and receiving procedures. For example, when mult= iple instances allowed, how does a node decide which instance takes effect;= if only one instance allowed and multiple instances received, how to handl= e this, discard the whole TLV, or only the first instance takes effect and = the rest ignored.=C2=A0=C2=A0
=
--000000000000c6706205a382f366-- From nobody Fri Apr 17 14:28:17 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5139B3A080C; Fri, 17 Apr 2020 14:28:15 -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 czU8krgFss-T; Fri, 17 Apr 2020 14:28:12 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 AC8653A07F8; Fri, 17 Apr 2020 14:28:08 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id nu11so1588105pjb.1; Fri, 17 Apr 2020 14:28:08 -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=S55/8gnM7KvcJqQsFxraRZVD73qlFB2adwVR/ZCZ3ts=; b=uASg3bPZsBgrZmJQXwK7T/LGrybYjboDE0YliP3uB3T8yLAd1GJ4CIgeKgObkTxg39 TEC9QbaUOcQFmWcDx3EnemsPr8CkXb7uA8wfWXoejel2qxuc0qGnUk23HV68Hq1ADhU1 igV+rrehUH2Y8EOR4wUcf5rK7qfV4quDkgpX7ggCZDsfAw4/3EvwezxzPmwJm2d/oq5L kbrIwADVqwYq0aYBdtZ/lXLGPvrW6m9z0mUfJ7fXHJUeUqlKKtU9/QuoDWq0SjRVtTAP 9KGb2ub2fXwb6pYmKVuXBDTVoDhm0SLQw9WQCeNpKjhJ2WIMnwH7asSe1i4tdR85LN9J Zi6A== 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=S55/8gnM7KvcJqQsFxraRZVD73qlFB2adwVR/ZCZ3ts=; b=sgrVNXKYVQs/MhHBofmVtRwyGDgc2Mr40BX17pDFFCqGC8c4LyzEFpz9u29jOMyM9i FxgcfKTxX3d8u0nsPTRoioiCIOJC1lxIQFlf+c+7cDvCpEE4INogDQ1i73jEOoRImus6 EI0SaMNL5EouLzL1AkZBNTW5jJEeCnvy6JAKmpUJ9A3mrlk4RKtwETw6i4u07bZ0hnk1 bTJ1vhqcpUpt9zlRsqJsSuCF+uHOeY/QBqt3z/4BWtQYYNM4jIHS4SYkFM0N0GIKslPC fupCYFyHsvMfGlB33BGmBru0cypLZ9kZNTXuehbLD/XqMspxM56JzvjazxHs8FuYi4CB 6NSA== X-Gm-Message-State: AGi0PubLde7kNj26CppBbFfL/aurg7aAADdJnYmFxHtn7uRPyzibHv6H U09v9KmeHck3bGN8d6HClcLdjp7Z X-Google-Smtp-Source: APiQypLx4gw+q/zFA5ZvcZb6pKtQppaOoBOm6lxysw6iTeuj7AegN86FH/YNks62tXjyw5eqDRoQMg== X-Received: by 2002:a17:902:9a8a:: with SMTP id w10mr5641562plp.259.1587158887466; Fri, 17 Apr 2020 14:28:07 -0700 (PDT) Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id w13sm5406076pfn.192.2020.04.17.14.28.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Apr 2020 14:28:06 -0700 (PDT) Date: Fri, 17 Apr 2020 14:27:57 -0700 From: Jeff Tantsura To: "=?utf-8?Q??=" , Mach Chen Cc: "=?utf-8?Q?rtg-dir=40ietf.org?=" , "=?utf-8?Q?draft-ietf-idr-bgp-ls-segment-routing-msd.all=40ietf.org?=" , IDR List Message-ID: <64d95dfc-acd3-422f-ae0e-869e0b92bb72@Spark> In-Reply-To: References: X-Readdle-Message-ID: 64d95dfc-acd3-422f-ae0e-869e0b92bb72@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5e9a1f65_7a6d8d3c_e7ef" Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 21:28:16 -0000 --5e9a1f65_7a6d8d3c_e7ef Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Mach/Alvaro, Many thanks for your review. Please see inline Have a great weekend and stay safe=21 Cheers, Jeff On Apr 17, 2020, 12:38 AM -0700, Mach Chen , wrot= e: > 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 IET=46 last call and IESG review, and sometim= es on special request. The purpose of the review is to provide assistance= to the Routing ADs. =46or more information about the Routing Directorate= , please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r > > Although these comments are primarily for the use of the Routing ADs, i= t would be helpful if you could consider them along with any other IET=46= Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. > > Document: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt > Reviewer: Mach Chen > Review Date: April 17, 2020 > IET=46 LC End Date: > Intended Status: Standards Track > > Summary: > I have some minor concerns about this document that I think should be r= esolved before publication. > > Comments: > This document is clearly written and easy to understand. > > Major Issues: > No major issues found. > > Minor Issues: > The Node MSD TLV and Link MSD TLV are designed to be able to carry mult= iple MSDs. I guess this is designed for future extensibility, where a Nod= e may have multiple types of MSD, right=3F But for each type, is it allow= ed to carry multiple instances of MSD-Type/MSD-Value pair or only one ins= tance=3F =46or whichever case, there need some text to describe the rule = about the sending and receiving procedures. =46or example, when multiple = instances allowed, how does a node decide which instance takes effect; if= only one instance allowed and multiple instances received, how to handle= this, discard the whole TLV, or only the first instance takes effect and= the rest ignored. > > Nits: > 1. > Section 1, > s/learn/learns =5Bjeff=5D ack > > 2. > Section 3 and Section 4: > The TLV format of Node/Link MSD is defined as follows: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =7C Type =7C Length =7C > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =7C MSD-Type =7C MSD-Value =7C MSD-Type... =7C MSD-Value... =7C > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Since the MSD-Type/MSD-Value pairs are variable in length, the above de= finition does not reflect this, suggest to change the figure as below: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =7C Type =7C Length =7C > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > // MSD-Type =7C MSD-Value =7C MSD-Type... =7C MSD-Value... // > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =5Bjeff=5D As Alvaro already explained in his email, BGP-LS is simply the= transport here,=C2=A0https://tools.ietf.org/html/rfc8491=23section-2 sho= ws the format exactly as you suggested, thanks for that=21 I=E2=80=99m with Alvaro - this need not to be done in this document, sinc= e it is already done in the IGP R=46C. > > Best regards, > Mach > --5e9a1f65_7a6d8d3c_e7ef Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Mach/Alvaro,

Many thanks for your review.

Please see inline


Have a great weekend and stay safe=21

Cheers,
Jeff
On Apr 17, 2020, 12:38 AM -0700, Ma= ch Chen <mach.chen=40huawei.com>, wrote:
He= llo,

I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related dr= afts as they pass through IET=46 last call and IESG review, and sometimes= on special request. The purpose of the review is to provide assistance t= o the Routing ADs. =46or more information about the Routing Directorate, = please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<= br />
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 IET=46 L= ast Call comments that you receive, and strive to resolve them through di= scussion or by updating the draft.

Document: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt
Reviewer: Mach Chen
Review Date: April 17, 2020
IET=46 LC End Date:
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be res= olved before publication.

Comments:
This document is clearly written and easy to understand.

Major Issues:
No major issues found.

Minor Issues:
The Node MSD TLV and Link MSD TLV are designed to be able to carry multip= le MSDs. I guess this is designed for future extensibility, where a Node = may have multiple types of MSD, right=3F But for each type, is it allowed= to carry multiple instances of MSD-Type/MSD-Value pair or only one insta= nce=3F =46or whichever case, there need some text to describe the rule ab= out the sending and receiving procedures. =46or example, when multiple in= stances allowed, how does a node decide which instance takes effect; if o= nly one instance allowed and multiple instances received, how to handle t= his, discard the whole TLV, or only the first instance takes effect and t= he rest ignored.

Nits:
1.
Section 1,
s/learn/learns&=23160;
=5Bjeff=5D ack
2.
Section 3 and Section 4:
The TLV format of Node/Link MSD is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=7C Type =7C Length =7C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=7C MSD-Type =7C MSD-Value =7C MSD-Type... =7C MSD-Value... =7C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Since the MSD-Type/MSD-Value pairs are variable in length, the above defi= nition does not reflect this, suggest to change the figure as below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=7C Type =7C Length =7C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MSD-Type =7C MSD-Value =7C MSD-Type... =7C MSD-Value... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&=23160;=

=5Bjeff=5D As Alvaro already explained in his email= , BGP-LS is simply the transport here,&=23160;https://tools.ietf.org/html= /rfc8491=23section-2 shows the format exactly as you suggested, thanks fo= r that=21&=23160;
I=E2=80=99m with Alvaro - this need not to be done = in this document, since it is already done in the IGP R=46C.&=23160;
Best regards,
Mach

--5e9a1f65_7a6d8d3c_e7ef-- From nobody Fri Apr 17 20:30:40 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9D3A0E96; Fri, 17 Apr 2020 20:30:21 -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 iBMLjrgsvIn3; Fri, 17 Apr 2020 20:30:13 -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 914D13A0E8D; Fri, 17 Apr 2020 20:30:12 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4711F62EAC16074CE84A; Sat, 18 Apr 2020 04:30:10 +0100 (IST) Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 18 Apr 2020 04:30:09 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.249]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Sat, 18 Apr 2020 11:30:03 +0800 From: Mach Chen To: Alvaro Retana , "" CC: "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" , IDR List , "rtg-dir@ietf.org" Thread-Topic: RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt Thread-Index: AdYUgufIha3uMI7HSMyOkGGdwgKyaQANmQuAABrRsaA= Date: Sat, 18 Apr 2020 03:30:02 +0000 Message-ID: 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.203.48] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE80dggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 03:30:22 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE80dggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpUZWNobmljYWxseSwgYWNjb3JkaW5nIHRvIFRhYmxlIDIgb2YgUkZDIDc3 NTIsIHRoZSBzb3VyY2Ugb2YgQkdQLUxTIGluZm9ybWF0aW9uIGNhbiBiZSBmcm9tIElHUCwgRGly ZWN0IG9yIFN0YXRpYyBjb25maWd1cmF0aW9uLiBBbmQgdGhlIHJ1bGVzIGluIHF1ZXN0aW9uIGFy ZSBub3Qgc3BlY2lmaWVkIGluIHRoZSBJR1AgUkZDcywgSSBwZXJzb25hbGx5IHRoaW5rIHRoZXkg YXJlIGVzc2VudGlhbC4gSXTigJlzIHBpdHkgdGhhdCB3ZSBkaWQgbm90IGNhdGNoIGl0IHdoZW4g cHJvZ3Jlc3NpbmcgdGhvc2UgUkZDcy4gSSBkbyBhZ3JlZSB0aGlzIGRvY3VtZW50IG1heSBub3Qg YmUgdGhlIHBlcmZlY3QgcGxhY2UgdG8gc3BlY2lmeSAgdGhvc2UgcnVsZXMsIGJ1dCB3aXRoIHRo ZSBjdXJyZW50IHNpdHVhdGlvbiwgdG8gd3JpdGUgZG93biBzb21ldGhpbmcgaGVyZSBpcyBiZXR0 ZXIgdGhhbiBkbyBub3RoaW5nLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCkZyb206IEFsdmFy byBSZXRhbmEgW21haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tXQ0KU2VudDogU2F0dXJkYXks IEFwcmlsIDE4LCAyMDIwIDU6MDkgQU0NClRvOiA8cnRnLWFkc0BpZXRmLm9yZz4gPHJ0Zy1hZHNA aWV0Zi5vcmc+OyBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPg0KQ2M6IGRyYWZ0LWll dGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctbXNkLmFsbEBpZXRmLm9yZzsgSURSIExpc3Qg PGlkckBpZXRmLm9yZz47IHJ0Zy1kaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBSdGdEaXIgcmV2 aWV3OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC0xNi50eHQNCg0K TWFjaDoNCg0KSGkhICBIb3cgYXJlIHlvdT8NCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3ISENCg0K S2VlcCBpbiBtaW5kIHRoYXQgQkdQLUxTIHNpbXBseSB0cmFuc3BvcnRzIHRoZSBpbmZvcm1hdGlv biBmcm9tIHRoZSBJR1BzLCBzbyB0aGUgYWJpbGl0eSB0byBjYXJyeSBtdWx0aXBsZSBpbnN0YW5j ZXMvbXVsdGlwbGUgdmFsdWVzIGRlcGVuZHMgb24gdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlIE1T RCBpdHNlbGYsIGFuZCBhbnkgcnVsZXMgaW4gdGhlIGNvcnJlc3BvbmRpbmcgSUdQIFJGQ3MuICBJ T1csIHNwZWNpZnlpbmcgdGhhdCBiZWhhdmlvciBmb3IgQkdQLUxTIGluIHRoaXMgZG9jdW1lbnQg aXMgbm90IG5lZWRlZC4NCg0KDQpUYWtlIGNhcmUhDQoNCkFsdmFyby4NCg0KDQpPbiBBcHJpbCAx NywgMjAyMCBhdCAzOjM4OjU1IEFNLCBNYWNoIENoZW4gKG1hY2guY2hlbkBodWF3ZWkuY29tPG1h aWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4pIHdyb3RlOg0KTWlub3IgSXNzdWVzOg0KVGhlIE5v ZGUgTVNEIFRMViBhbmQgTGluayBNU0QgVExWIGFyZSBkZXNpZ25lZCB0byBiZSBhYmxlIHRvIGNh cnJ5IG11bHRpcGxlIE1TRHMuIEkgZ3Vlc3MgdGhpcyBpcyBkZXNpZ25lZCBmb3IgZnV0dXJlIGV4 dGVuc2liaWxpdHksIHdoZXJlIGEgTm9kZSBtYXkgaGF2ZSBtdWx0aXBsZSB0eXBlcyBvZiBNU0Qs IHJpZ2h0PyBCdXQgZm9yIGVhY2ggdHlwZSwgaXMgaXQgYWxsb3dlZCB0byBjYXJyeSBtdWx0aXBs ZSBpbnN0YW5jZXMgb2YgTVNELVR5cGUvTVNELVZhbHVlIHBhaXIgb3Igb25seSBvbmUgaW5zdGFu Y2U/IEZvciB3aGljaGV2ZXIgY2FzZSwgdGhlcmUgbmVlZCBzb21lIHRleHQgdG8gZGVzY3JpYmUg dGhlIHJ1bGUgYWJvdXQgdGhlIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBwcm9jZWR1cmVzLiBGb3Ig ZXhhbXBsZSwgd2hlbiBtdWx0aXBsZSBpbnN0YW5jZXMgYWxsb3dlZCwgaG93IGRvZXMgYSBub2Rl IGRlY2lkZSB3aGljaCBpbnN0YW5jZSB0YWtlcyBlZmZlY3Q7IGlmIG9ubHkgb25lIGluc3RhbmNl IGFsbG93ZWQgYW5kIG11bHRpcGxlIGluc3RhbmNlcyByZWNlaXZlZCwgaG93IHRvIGhhbmRsZSB0 aGlzLCBkaXNjYXJkIHRoZSB3aG9sZSBUTFYsIG9yIG9ubHkgdGhlIGZpcnN0IGluc3RhbmNlIHRh a2VzIGVmZmVjdCBhbmQgdGhlIHJlc3QgaWdub3JlZC4NCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE80dggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHls ZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5hcHBsZS1j b252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhp IEFsdmFybyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGVjaG5pY2FsbHksIGFjY29yZGluZyB0byBUYWJsZSAyIG9m IFJGQyA3NzUyLCB0aGUgc291cmNlIG9mIEJHUC1MUyBpbmZvcm1hdGlvbiBjYW4gYmUgZnJvbSBJ R1AsIERpcmVjdCBvciBTdGF0aWMgY29uZmlndXJhdGlvbi4gQW5kIHRoZSBydWxlcyBpbg0KIHF1 ZXN0aW9uIGFyZSBub3Qgc3BlY2lmaWVkIGluIHRoZSBJR1AgUkZDcywgSSBwZXJzb25hbGx5IHRo aW5rIHRoZXkgYXJlIGVzc2VudGlhbC4gSXTigJlzIHBpdHkgdGhhdCB3ZSBkaWQgbm90IGNhdGNo IGl0IHdoZW4gcHJvZ3Jlc3NpbmcgdGhvc2UgUkZDcy4gSSBkbyBhZ3JlZSB0aGlzIGRvY3VtZW50 IG1heSBub3QgYmUgdGhlIHBlcmZlY3QgcGxhY2UgdG8gc3BlY2lmeSAmbmJzcDt0aG9zZSBydWxl cywgYnV0IHdpdGggdGhlIGN1cnJlbnQgc2l0dWF0aW9uLA0KIHRvIHdyaXRlIGRvd24gc29tZXRo aW5nIGhlcmUgaXMgYmV0dGVyIHRoYW4gZG8gbm90aGluZy4gPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1hY2g8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbHZhcm8gUmV0YW5hIFttYWlsdG86 YXJldGFuYS5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXBy aWwgMTgsIDIwMjAgNTowOSBBTTxicj4NCjxiPlRvOjwvYj4gJmx0O3J0Zy1hZHNAaWV0Zi5vcmcm Z3Q7ICZsdDtydGctYWRzQGlldGYub3JnJmd0OzsgTWFjaCBDaGVuICZsdDttYWNoLmNoZW5AaHVh d2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50 LXJvdXRpbmctbXNkLmFsbEBpZXRmLm9yZzsgSURSIExpc3QgJmx0O2lkckBpZXRmLm9yZyZndDs7 IHJ0Zy1kaXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJ0Z0RpciByZXZpZXc6 IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctbXNkLTE2LnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWFjaDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+SGkhJm5ic3A7IEhvdyBhcmUgeW91PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5U aGFua3MgZm9yIHRoZSByZXZpZXchITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LZWVwIGluIG1pbmQgdGhh dCBCR1AtTFMgc2ltcGx5IHRyYW5zcG9ydHMgdGhlIGluZm9ybWF0aW9uIGZyb20gdGhlIElHUHMs IHNvIHRoZSBhYmlsaXR5IHRvIGNhcnJ5IG11bHRpcGxlIGluc3RhbmNlcy9tdWx0aXBsZSB2YWx1 ZXMgZGVwZW5kcyBvbiB0aGUgc3BlY2lmaWNhdGlvbg0KIG9mIHRoZSBNU0QgaXRzZWxmLCBhbmQg YW55IHJ1bGVzIGluIHRoZSBjb3JyZXNwb25kaW5nIElHUCBSRkNzLiZuYnNwOyBJT1csIHNwZWNp ZnlpbmcgdGhhdCBiZWhhdmlvciBmb3IgQkdQLUxTIGluIHRoaXMgZG9jdW1lbnQgaXMgbm90IG5l ZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5UYWtlIGNhcmUhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFsdmFyby48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImFp cm1haWxvbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBBcHJpbCAxNywgMjAy MCBhdCAzOjM4OjU1IEFNLCBNYWNoIENoZW4gKDxhIGhyZWY9Im1haWx0bzptYWNoLmNoZW5AaHVh d2VpLmNvbSI+bWFjaC5jaGVuQGh1YXdlaS5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+TWlub3IgSXNzdWVzOjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQo8c3BhbiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+VGhlIE5vZGUgTVNEIFRMViBhbmQgTGluayBNU0QgVExWIGFy ZSBkZXNpZ25lZCB0byBiZSBhYmxlIHRvIGNhcnJ5IG11bHRpcGxlIE1TRHMuIEkgZ3Vlc3MgdGhp cyBpcyBkZXNpZ25lZCBmb3IgZnV0dXJlIGV4dGVuc2liaWxpdHksIHdoZXJlIGEgTm9kZSBtYXkg aGF2ZSBtdWx0aXBsZSB0eXBlcyBvZiBNU0QsIHJpZ2h0PyBCdXQgZm9yIGVhY2ggdHlwZSwgaXMg aXQgYWxsb3dlZCB0byBjYXJyeQ0KIG11bHRpcGxlIGluc3RhbmNlcyBvZiBNU0QtVHlwZS9NU0Qt VmFsdWUgcGFpciBvciBvbmx5IG9uZSBpbnN0YW5jZT8gRm9yIHdoaWNoZXZlciBjYXNlLCB0aGVy ZSBuZWVkIHNvbWUgdGV4dCB0byBkZXNjcmliZSB0aGUgcnVsZSBhYm91dCB0aGUgc2VuZGluZyBh bmQgcmVjZWl2aW5nIHByb2NlZHVyZXMuIEZvciBleGFtcGxlLCB3aGVuIG11bHRpcGxlIGluc3Rh bmNlcyBhbGxvd2VkLCBob3cgZG9lcyBhIG5vZGUgZGVjaWRlIHdoaWNoIGluc3RhbmNlDQogdGFr ZXMgZWZmZWN0OyBpZiBvbmx5IG9uZSBpbnN0YW5jZSBhbGxvd2VkIGFuZCBtdWx0aXBsZSBpbnN0 YW5jZXMgcmVjZWl2ZWQsIGhvdyB0byBoYW5kbGUgdGhpcywgZGlzY2FyZCB0aGUgd2hvbGUgVExW LCBvciBvbmx5IHRoZSBmaXJzdCBpbnN0YW5jZSB0YWtlcyBlZmZlY3QgYW5kIHRoZSByZXN0IGln bm9yZWQuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE80dggeml510mbxchi_-- From nobody Fri Apr 17 20:44:42 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAE33A0ED0; Fri, 17 Apr 2020 20:44:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 eUi62k_DHZex; Fri, 17 Apr 2020 20:44:38 -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 141F03A0ECF; Fri, 17 Apr 2020 20:44:38 -0700 (PDT) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6CF7B7E1C8A57C8CCC42; Sat, 18 Apr 2020 04:44:35 +0100 (IST) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 18 Apr 2020 04:44:34 +0100 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.249]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0487.000; Sat, 18 Apr 2020 11:44:29 +0800 From: Mach Chen To: Jeff Tantsura , "" CC: "rtg-dir@ietf.org" , "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" , IDR List Thread-Topic: RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt Thread-Index: AdYUgufIha3uMI7HSMyOkGGdwgKyaQAORn6AAB1va+A= Date: Sat, 18 Apr 2020 03:44:27 +0000 Message-ID: References: <64d95dfc-acd3-422f-ae0e-869e0b92bb72@Spark> In-Reply-To: <64d95dfc-acd3-422f-ae0e-869e0b92bb72@Spark> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.48] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE9Fdggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 03:44:41 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE9Fdggeml510mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmVmZiwNCg0KUGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmXigKYNCg0KRnJvbTogSmVm ZiBUYW50c3VyYSBbbWFpbHRvOmplZmZ0YW50LmlldGZAZ21haWwuY29tXQ0KU2VudDogU2F0dXJk YXksIEFwcmlsIDE4LCAyMDIwIDU6MjggQU0NClRvOiA8cnRnLWFkc0BpZXRmLm9yZz4gPHJ0Zy1h ZHNAaWV0Zi5vcmc+OyBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPg0KQ2M6IHJ0Zy1k aXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRpbmctbXNkLmFs bEBpZXRmLm9yZzsgSURSIExpc3QgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBSdGdEaXIg cmV2aWV3OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC0xNi50eHQN Cg0KSGkgTWFjaC9BbHZhcm8sDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldy4NCg0KUGxl YXNlIHNlZSBpbmxpbmUNCg0KDQpIYXZlIGEgZ3JlYXQgd2Vla2VuZCBhbmQgc3RheSBzYWZlIQ0K DQpDaGVlcnMsDQpKZWZmDQpPbiBBcHIgMTcsIDIwMjAsIDEyOjM4IEFNIC0wNzAwLCBNYWNoIENo ZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+LCB3 cm90ZToNCg0KSGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERp cmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0 ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBh cyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBz b21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlz IHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9y bWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91 Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGlu ZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxv bmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2 ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVw ZGF0aW5nIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdt ZW50LXJvdXRpbmctbXNkLTE2LnR4dA0KUmV2aWV3ZXI6IE1hY2ggQ2hlbg0KUmV2aWV3IERhdGU6 IEFwcmlsIDE3LCAyMDIwDQpJRVRGIExDIEVuZCBEYXRlOg0KSW50ZW5kZWQgU3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sNCg0KU3VtbWFyeToNCkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0 IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVi bGljYXRpb24uDQoNCkNvbW1lbnRzOg0KVGhpcyBkb2N1bWVudCBpcyBjbGVhcmx5IHdyaXR0ZW4g YW5kIGVhc3kgdG8gdW5kZXJzdGFuZC4NCg0KTWFqb3IgSXNzdWVzOg0KTm8gbWFqb3IgaXNzdWVz IGZvdW5kLg0KDQpNaW5vciBJc3N1ZXM6DQpUaGUgTm9kZSBNU0QgVExWIGFuZCBMaW5rIE1TRCBU TFYgYXJlIGRlc2lnbmVkIHRvIGJlIGFibGUgdG8gY2FycnkgbXVsdGlwbGUgTVNEcy4gSSBndWVz cyB0aGlzIGlzIGRlc2lnbmVkIGZvciBmdXR1cmUgZXh0ZW5zaWJpbGl0eSwgd2hlcmUgYSBOb2Rl IG1heSBoYXZlIG11bHRpcGxlIHR5cGVzIG9mIE1TRCwgcmlnaHQ/IEJ1dCBmb3IgZWFjaCB0eXBl LCBpcyBpdCBhbGxvd2VkIHRvIGNhcnJ5IG11bHRpcGxlIGluc3RhbmNlcyBvZiBNU0QtVHlwZS9N U0QtVmFsdWUgcGFpciBvciBvbmx5IG9uZSBpbnN0YW5jZT8gRm9yIHdoaWNoZXZlciBjYXNlLCB0 aGVyZSBuZWVkIHNvbWUgdGV4dCB0byBkZXNjcmliZSB0aGUgcnVsZSBhYm91dCB0aGUgc2VuZGlu ZyBhbmQgcmVjZWl2aW5nIHByb2NlZHVyZXMuIEZvciBleGFtcGxlLCB3aGVuIG11bHRpcGxlIGlu c3RhbmNlcyBhbGxvd2VkLCBob3cgZG9lcyBhIG5vZGUgZGVjaWRlIHdoaWNoIGluc3RhbmNlIHRh a2VzIGVmZmVjdDsgaWYgb25seSBvbmUgaW5zdGFuY2UgYWxsb3dlZCBhbmQgbXVsdGlwbGUgaW5z dGFuY2VzIHJlY2VpdmVkLCBob3cgdG8gaGFuZGxlIHRoaXMsIGRpc2NhcmQgdGhlIHdob2xlIFRM Viwgb3Igb25seSB0aGUgZmlyc3QgaW5zdGFuY2UgdGFrZXMgZWZmZWN0IGFuZCB0aGUgcmVzdCBp Z25vcmVkLg0KDQpOaXRzOg0KMS4NClNlY3Rpb24gMSwNCnMvbGVhcm4vbGVhcm5zDQpbamVmZl0g YWNrDQoNCjIuDQpTZWN0aW9uIDMgYW5kIFNlY3Rpb24gNDoNClRoZSBUTFYgZm9ybWF0IG9mIE5v ZGUvTGluayBNU0QgaXMgZGVmaW5lZCBhcyBmb2xsb3dzOg0KMCAxIDIgMw0KMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQorLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KfCBUeXBlIHwgTGVuZ3RoIHwNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8IE1TRC1UeXBlIHwgTVNELVZhbHVl IHwgTVNELVR5cGUuLi4gfCBNU0QtVmFsdWUuLi4gfA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KU2luY2UgdGhlIE1T RC1UeXBlL01TRC1WYWx1ZSBwYWlycyBhcmUgdmFyaWFibGUgaW4gbGVuZ3RoLCB0aGUgYWJvdmUg ZGVmaW5pdGlvbiBkb2VzIG5vdCByZWZsZWN0IHRoaXMsIHN1Z2dlc3QgdG8gY2hhbmdlIHRoZSBm aWd1cmUgYXMgYmVsb3c6DQowIDEgMiAzDQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCistKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8IFR5cGUgfCBMZW5n dGggfA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCi8vIE1TRC1UeXBlIHwgTVNELVZhbHVlIHwgTVNELVR5cGUuLi4gfCBN U0QtVmFsdWUuLi4gLy8NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCltqZWZmXSBBcyBBbHZhcm8gYWxyZWFkeSBleHBs YWluZWQgaW4gaGlzIGVtYWlsLCBCR1AtTFMgaXMgc2ltcGx5IHRoZSB0cmFuc3BvcnQgaGVyZSwg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0OTEjc2VjdGlvbi0yIHNob3dzIHRoZSBm b3JtYXQgZXhhY3RseSBhcyB5b3Ugc3VnZ2VzdGVkLCB0aGFua3MgZm9yIHRoYXQhDQpJ4oCZbSB3 aXRoIEFsdmFybyAtIHRoaXMgbmVlZCBub3QgdG8gYmUgZG9uZSBpbiB0aGlzIGRvY3VtZW50LCBz aW5jZSBpdCBpcyBhbHJlYWR5IGRvbmUgaW4gdGhlIElHUCBSRkMuDQoNCltNYWNoXSBJIG1heSBi ZSBhIGxpdHRsZSBiaXQgcGlja3kgaGVyZeKYuiAgQWNjb3JkaW5nIHRvIEZpZ3VyZSAxIGFuZCBG aWd1cmUgMiwgdGhleSBzaG93cyB0aGF0IHZhbHVlIGZpZWxkIGlzIGZpeGVkIChmb3VyIG9jdGV0 cykgaW4gbGVuZ3RoLCBidXQgYWN0dWFsbHkgdGhlIGxlbmd0aCBpcyB2YXJpYWJsZSBhcyBkZXNp Z25lZC4gSU1ITywgdGhlIGZvcm1hdCBvZiBJR1AgVExWIHdpbGwgbm90IGJlIGV4YWN0bHkgbWFw cGVkIHRvIHRoZSBmb3JtYXQgQkdQIFRMViBmb3JtYXQsIEJHUC1MUyBoYXMgaXRzIG93biBkZWZp bml0aW9ucy4gSXTigJlzIGJldHRlciB0aGF0IHRoaXMgZG9jdW1lbnQga2VlcHMgdGhlIGRlZmlu aXRpb24gc2FuZSBieSBpdHNlbGYuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KDQpCZXN0IHJl Z2FyZHMsDQpNYWNoDQo= --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE9Fdggeml510mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5 IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7 DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0x OjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2T O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0 IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgSmVmZiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+UGxlYXNlIHNlZSBteSByZXNwb25zZSBpbmxpbmXigKY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBKZWZmIFRhbnRzdXJhIFttYWlsdG86 amVmZnRhbnQuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEFw cmlsIDE4LCAyMDIwIDU6MjggQU08YnI+DQo8Yj5Ubzo8L2I+ICZsdDtydGctYWRzQGlldGYub3Jn Jmd0OyAmbHQ7cnRnLWFkc0BpZXRmLm9yZyZndDs7IE1hY2ggQ2hlbiAmbHQ7bWFjaC5jaGVuQGh1 YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBydGctZGlyQGlldGYub3JnOyBkcmFmdC1pZXRm LWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC5hbGxAaWV0Zi5vcmc7IElEUiBMaXN0ICZs dDtpZHJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBSdGdEaXIgcmV2aWV3 OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC0xNi50eHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgbmFtZT0i bWVzc2FnZUJvZHlTZWN0aW9uIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+SGkgTWFjaC9BbHZhcm8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5NYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2Ugc2VlIGlubGlu ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhhdmUgYSBncmVhdCB3ZWVrZW5kIGFuZCBzdGF5IHNhZmUh PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgbmFtZT0ibWVzc2Fn ZVNpZ25hdHVyZVNlY3Rpb24iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hlZXJzLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkplZmY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IG5hbWU9Im1lc3Nh Z2VSZXBseVNlY3Rpb24iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIEFwciAxNywgMjAyMCwgMTI6MzggQU0gLTA3MDAsIE1hY2ggQ2hlbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tIj5tYWNoLmNoZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7 LCB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzFBQkM5QyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDguMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjMuNzVwdDtt YXJnaW4tcmlnaHQ6My43NXB0O21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyw8YnI+DQo8YnI+DQpJIGhhdmUgYmVlbiBz ZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFm dC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9y IHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNh bGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhl IHB1cnBvc2Ugb2YgdGhlDQogcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUg Um91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVj dG9yYXRlLCBwbGVhc2Ugc2VlDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0RpciI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0 Z0RpcjwvYT48YnI+DQo8YnI+DQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5 b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2Fs bCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0 aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Ljxicj4NCjxicj4NCkRv Y3VtZW50OiBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLW1zZC0xNi50eHQ8 YnI+DQpSZXZpZXdlcjogTWFjaCBDaGVuPGJyPg0KUmV2aWV3IERhdGU6IEFwcmlsIDE3LCAyMDIw PGJyPg0KSUVURiBMQyBFbmQgRGF0ZTo8YnI+DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBU cmFjazxicj4NCjxicj4NClN1bW1hcnk6PGJyPg0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMg YWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9y ZSBwdWJsaWNhdGlvbi48YnI+DQo8YnI+DQpDb21tZW50czo8YnI+DQpUaGlzIGRvY3VtZW50IGlz IGNsZWFybHkgd3JpdHRlbiBhbmQgZWFzeSB0byB1bmRlcnN0YW5kLjxicj4NCjxicj4NCk1ham9y IElzc3Vlczo8YnI+DQpObyBtYWpvciBpc3N1ZXMgZm91bmQuPGJyPg0KPGJyPg0KTWlub3IgSXNz dWVzOjxicj4NClRoZSBOb2RlIE1TRCBUTFYgYW5kIExpbmsgTVNEIFRMViBhcmUgZGVzaWduZWQg dG8gYmUgYWJsZSB0byBjYXJyeSBtdWx0aXBsZSBNU0RzLiBJIGd1ZXNzIHRoaXMgaXMgZGVzaWdu ZWQgZm9yIGZ1dHVyZSBleHRlbnNpYmlsaXR5LCB3aGVyZSBhIE5vZGUgbWF5IGhhdmUgbXVsdGlw bGUgdHlwZXMgb2YgTVNELCByaWdodD8gQnV0IGZvciBlYWNoIHR5cGUsIGlzIGl0IGFsbG93ZWQg dG8gY2FycnkgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIE1TRC1UeXBlL01TRC1WYWx1ZQ0KIHBhaXIg b3Igb25seSBvbmUgaW5zdGFuY2U/IEZvciB3aGljaGV2ZXIgY2FzZSwgdGhlcmUgbmVlZCBzb21l IHRleHQgdG8gZGVzY3JpYmUgdGhlIHJ1bGUgYWJvdXQgdGhlIHNlbmRpbmcgYW5kIHJlY2Vpdmlu ZyBwcm9jZWR1cmVzLiBGb3IgZXhhbXBsZSwgd2hlbiBtdWx0aXBsZSBpbnN0YW5jZXMgYWxsb3dl ZCwgaG93IGRvZXMgYSBub2RlIGRlY2lkZSB3aGljaCBpbnN0YW5jZSB0YWtlcyBlZmZlY3Q7IGlm IG9ubHkgb25lIGluc3RhbmNlIGFsbG93ZWQNCiBhbmQgbXVsdGlwbGUgaW5zdGFuY2VzIHJlY2Vp dmVkLCBob3cgdG8gaGFuZGxlIHRoaXMsIGRpc2NhcmQgdGhlIHdob2xlIFRMViwgb3Igb25seSB0 aGUgZmlyc3QgaW5zdGFuY2UgdGFrZXMgZWZmZWN0IGFuZCB0aGUgcmVzdCBpZ25vcmVkLjxicj4N Cjxicj4NCk5pdHM6PGJyPg0KMS48YnI+DQpTZWN0aW9uIDEsPGJyPg0Kcy9sZWFybi9sZWFybnMm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPltqZWZmXSBhY2s8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjMUFCQzlDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gOC4wcHQ7bWFyZ2lu LWxlZnQ6My43NXB0O21hcmdpbi10b3A6My43NXB0O21hcmdpbi1yaWdodDozLjc1cHQ7bWFyZ2lu LWJvdHRvbTozLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxicj4NCjIuPGJyPg0KU2VjdGlvbiAzIGFuZCBTZWN0aW9uIDQ6PGJyPg0KVGhlIFRMViBmb3Jt YXQgb2YgTm9kZS9MaW5rIE1TRCBpcyBkZWZpbmVkIGFzIGZvbGxvd3M6PGJyPg0KMCAxIDIgMzxi cj4NCjAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMTxicj4NCiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PGJyPg0KfCBUeXBlIHwg TGVuZ3RoIHw8YnI+DQomIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxicj4NCnwgTVNELVR5cGUg fCBNU0QtVmFsdWUgfCBNU0QtVHlwZS4uLiB8IE1TRC1WYWx1ZS4uLiB8PGJyPg0KJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0Mzs8YnI+DQo8YnI+DQpTaW5jZSB0aGUgTVNELVR5cGUvTVNELVZhbHVl IHBhaXJzIGFyZSB2YXJpYWJsZSBpbiBsZW5ndGgsIHRoZSBhYm92ZSBkZWZpbml0aW9uIGRvZXMg bm90IHJlZmxlY3QgdGhpcywgc3VnZ2VzdCB0byBjaGFuZ2UgdGhlIGZpZ3VyZSBhcyBiZWxvdzo8 YnI+DQowIDEgMiAzPGJyPg0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPGJyPg0KJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8 YnI+DQp8IFR5cGUgfCBMZW5ndGggfDxicj4NCiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PGJy Pg0KLy8gTVNELVR5cGUgfCBNU0QtVmFsdWUgfCBNU0QtVHlwZS4uLiB8IE1TRC1WYWx1ZS4uLiAv Lzxicj4NCiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+W2plZmZdIEFzIEFsdmFybyBh bHJlYWR5IGV4cGxhaW5lZCBpbiBoaXMgZW1haWwsIEJHUC1MUyBpcyBzaW1wbHkgdGhlIHRyYW5z cG9ydCBoZXJlLCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4 NDkxI3NlY3Rpb24tMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0OTEjc2VjdGlv bi0yPC9hPiBzaG93cyB0aGUgZm9ybWF0IGV4YWN0bHkNCiBhcyB5b3Ugc3VnZ2VzdGVkLCB0aGFu a3MgZm9yIHRoYXQhJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPknigJltIHdpdGggQWx2YXJv IC0gdGhpcyBuZWVkIG5vdCB0byBiZSBkb25lIGluIHRoaXMgZG9jdW1lbnQsIHNpbmNlIGl0IGlz IGFscmVhZHkgZG9uZSBpbiB0aGUgSUdQIFJGQy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W01hY2hdIEkg bWF5IGJlIGEgbGl0dGxlIGJpdCBwaWNreSBoZXJlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3 RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOw0KIEFjY29yZGluZyB0byBGaWd1cmUgMSBhbmQgRmlndXJlIDIsIHRoZXkgc2hvd3MgdGhh dCB2YWx1ZSBmaWVsZCBpcyBmaXhlZCAoZm91ciBvY3RldHMpIGluIGxlbmd0aCwgYnV0IGFjdHVh bGx5IHRoZSBsZW5ndGggaXMgdmFyaWFibGUgYXMgZGVzaWduZWQuIElNSE8sIHRoZSBmb3JtYXQg b2YgSUdQIFRMViB3aWxsIG5vdCBiZSBleGFjdGx5IG1hcHBlZCB0byB0aGUgZm9ybWF0IEJHUCBU TFYgZm9ybWF0LCBCR1AtTFMgaGFzIGl0cyBvd24gZGVmaW5pdGlvbnMuDQogSXTigJlzIGJldHRl ciB0aGF0IHRoaXMgZG9jdW1lbnQga2VlcHMgdGhlIGRlZmluaXRpb24gc2FuZSBieSBpdHNlbGYu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pk1hY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICMxQUJDOUMgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA4LjBwdDttYXJnaW4t bGVmdDozLjc1cHQ7bWFyZ2luLXRvcDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjMuNzVwdDttYXJnaW4t Ym90dG9tOjMuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpCZXN0IHJlZ2FyZHMsPGJyPg0KTWFj aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE297AACE9Fdggeml510mbxchi_-- From nobody Mon Apr 20 06:11:07 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDE83A0C9D; Mon, 20 Apr 2020 06:10:55 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if5TFDIYabmp; Mon, 20 Apr 2020 06:10:54 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 309183A0CCE; Mon, 20 Apr 2020 06:10:54 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id x4so10959933wmj.1; Mon, 20 Apr 2020 06:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=dtTEsrStO99B7spoCuIiRkyQsgNv+oQHN+DD953zAaA=; b=OdkWxn7xEsuUohYG6nfBEqOlLt6OGxRSnzp7MQCVRnpGs3rH09yW+gqGpAxM5VEEQW IuFVLOSEXjYMTpex3JFSKEbPFhQ25DcIl/mk8OsyNEoRpbVB4DBeHlDsWmzCr39W+EJ5 WyRVNxpVG4JljrL6siDTJPso4Sk49jK6RgcknEVxMhvTtPX/yFVXACwuJ4lioGMO050R ziPFj8OdMJZfESd64QDACTa74Q1Mpegfzleal9ybkx0wGms/coxWuq8zfbBN1mBUoGA0 93cGrfxk7XAQymtLT5M3DudBVmvytfAp8PJB5Ub4+sRRv4kWcyMTZ7ywD3S/SOcnjUfH h7yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=dtTEsrStO99B7spoCuIiRkyQsgNv+oQHN+DD953zAaA=; b=tk9evWpDEmtoKW2M3N36qwF84BZgOmjMmIoTR8liY2DASLzDDuq8HOp8Pq6Fkvz+MP MOd1nLlFvT/AdzoMO208/PFdbjd1avFDuIXao1UCyhyg/Ut6geE40un4xC9L6j3BbwRo wuAxv+ExaDKMAc+aPvW2LUUMWajwrqP55cJTybVs4Xg/+2Apj2qQ/9bKE0AxLvBK2CEU MTKm9fqVBXaKfgnzPMc2iWVWPoPW52rQJVo06IS/Hr+S6fkfVidNNuoH0qZkajCFM+r1 cMc6aDi09a/7ToJBgv9nrmQ6sqwelrEBbeSbKY34BBIJEtDOXkekVO5ek73rBkvWLF3W XoDg== X-Gm-Message-State: AGi0Pua27uv1PNM3SGR1dHZmIPKfNp2CNtKCqIbr3ZlWVJ9ZuP9+yhql Wp7TsUji0Op2CyyUDhiZCVtJiGhDd5zStLakj2waoiQY X-Google-Smtp-Source: APiQypKdytlQGtlixYCpoC/yjAE2k4NU7Ibyb1VgYnFyuqMTx6gf4RmjKIfqliEJA/a0y04EALWwY/bQ0bIZceafjUQ= X-Received: by 2002:a05:600c:28e:: with SMTP id 14mr8083641wmk.79.1587388252270; Mon, 20 Apr 2020 06:10:52 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 20 Apr 2020 06:10:51 -0700 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Mon, 20 Apr 2020 06:10:50 -0700 Message-ID: To: "" , Mach Chen Cc: "rtg-dir@ietf.org" , IDR List , "draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e5b2a305a3b8a0a1" Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-ls-segment-routing-msd-16.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 13:11:05 -0000 --000000000000e5b2a305a3b8a0a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mach: Hi! You have a good point, the information can come from other sources. Besides Direct or Static, BGP is another defined source. So far, all the BGP-LS RFCs that have been published assume an IGP origin. Note that this document originally talked about carrying data originated by BGP =E2=80=94 but it would have been the first published document to do so= =E2=80=A6and defining the general operation of a BGP source didn=E2=80=99t seem to best = fit in an extension document. So it was agreed to document that in its own document [1]. Your point about processing of BGP-LS, in general, at the consumer is also a good one=E2=80=A6and one that caused a lot go discussion related to draft-ietf-idr-bgp-ls-segment-routing-ext (IIRC). The result being rfc7752bis. Thanks! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/idr/uiTEbxlhsfGX_A5D7RQRrrRuA-M/ On April 17, 2020 at 11:30:11 PM, Mach Chen (mach.chen@huawei.com) wrote: Technically, according to Table 2 of RFC 7752, the source of BGP-LS information can be from IGP, Direct or Static configuration. And the rules in question are not specified in the IGP RFCs, I personally think they are essential. It=E2=80=99s pity that we did not catch it when progressing thos= e RFCs. I do agree this document may not be the perfect place to specify those rules, but with the current situation, to write down something here is better than do nothing. --000000000000e5b2a305a3b8a0a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Mach:

Hi!

Y= ou have a good point, the information can come from other sources.=C2=A0 Be= sides Direct or Static, BGP is another defined source.

So far, all the BGP-LS RFCs that have b= een published assume an IGP origin.=C2=A0 Note that this document originall= y talked about carrying data originated by BGP =E2=80=94 but it would have = been the first published document to do so=E2=80=A6and defining the general= operation of a BGP source didn=E2=80=99t seem to best fit in an extension = document.=C2=A0 So it was agreed to document that in its own document [1].<= /div>

Your point about pr= ocessing of BGP-LS, in general, at the consumer is also a good one=E2=80=A6= and one that caused a lot go discussion related to=C2=A0draft-ietf-idr-bgp-= ls-segment-routing-ext (IIRC).=C2=A0 The result being rfc7752bis.


Thanks!

Alvaro.


[= 1]=C2=A0https://mailarchive.ietf.org/arch/msg/idr/uiTEbxlhsfGX_A5D7= RQRrrRuA-M/=C2=A0

On April 17, 2020 at 11:30= :11 PM, Mach Chen (mach.chen@huawei= .com) wrote:

Technically, = according to Table 2 of RFC 7752, the source of BGP-LS information can be f= rom IGP, Direct or Static configuration. And the rules in question are not = specified in the IGP RFCs, I personally think they are essential. It=E2=80= =99s pity that we did not catch it when progressing those RFCs. I do agree = this document may not be the perfect place to specify =C2=A0those rules, bu= t with the current situation, to write down something here is better than d= o nothing.=C2=A0


--000000000000e5b2a305a3b8a0a1-- From nobody Tue Apr 21 01:59:10 2020 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786393A0993; Tue, 21 Apr 2020 01:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.7 X-Spam-Level: X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VTGS34ws; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ovXWwBrG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65-XEGJO5SVt; Tue, 21 Apr 2020 01:58:52 -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 B3D1D3A09AE; Tue, 21 Apr 2020 01:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1462; q=dns/txt; s=iport; t=1587459532; x=1588669132; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=mUUElAdvdJh+D5ylDiuHPd77Vc/uTt9K6bdBVLX95HU=; b=VTGS34ws0WFYUsyBAXME6EM+WdEWRMu2r7HEwffNlAMt8OZ+szap4XcK cZO1t4hD6VfIyA7/aO7K24QYN6bXsnaXmWLbRQaGlxCpSbG7rg+4+DyWd X4htjBIQ8R9RqD8xTlYf5RrcAZT7ucprhEwfuWq/KMPVH4nvElsiwYtIZ I=; IronPort-PHdr: =?us-ascii?q?9a23=3A05t/IBB79zo+FQCETCXDUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIeD7aSc5EexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAQBhtJ5e/51dJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWoEAQELAYFTUQVsWCAECyqEHoNGA4pngl+YJYFCgRADVAoBAQE?= =?us-ascii?q?MAQElCAIEAQGERAIXgXkkNwYOAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBARU?= =?us-ascii?q?REQwBATcBCwYBGQMBAgMCHwcCBDAVCAoEAQ0FIoMEAYJLAy4BDqVtAoE5iGJ?= =?us-ascii?q?1gTKDAAEBBYFGQYM7GIIOAwaBDioBgmKJVhqBQT+BOByDC4JnAgMBgScFARE?= =?us-ascii?q?CAYMyMoItjh6DD4kFl1kKgkSICo9nFgeCVohPkTKPcIk/ky8CBAIEBQIOAQE?= =?us-ascii?q?FgWgjZnBwFWUBgj5QGA2RWDiDO4UUhUF0gSmNKV8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,409,1580774400"; d="scan'208";a="748530184" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2020 08:58:51 +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 03L8wpYF017825 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Apr 2020 08:58:51 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 21 Apr 2020 03:58:51 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 21 Apr 2020 03:58:51 -0500 Received: from NAM12-BN8-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; Tue, 21 Apr 2020 04:58:50 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZwTTBlIt8++g3Hu2eg+dx6i+dv+9am6BBSkfNZtsGnD9uKcwNoxX/ogo4jGcDnM6UB3U4zvSqVKjnq+eu2EuVNfxphR/4srGB3EAVIH2j81O7KbJKy9xB2UDOIQWYAr+SNKG8jEkqdVK9Ge99OidSJk0Cx/PFO9p9XHQoabiLMBTJeMjdEGNHWh1+O3gFBpZaKmWCMIAYL1n2L/ExfAsLk94e+Um428DiLsOZKOWqz/sUdRlaL5vG5jdcRpiWhzm429Hmkci8vZUUgI2QShy5EaBLApRio2LiWih+wv4O2as601G3idNV5fUJvCJiXHTyN5ee6+OkLEuNPk1D4R99g== 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=mUUElAdvdJh+D5ylDiuHPd77Vc/uTt9K6bdBVLX95HU=; b=A5iKu12b4RJmLU6RTyPhT+jEc05SZcbLNsLfCdKc1OTq++FnoYLLLHQkKGee7/QoLDQdQliD4Sa5cpG3uPMssFlddD5OcR6gBnkHeYDjeycycc3afzC0EYz8ArkFMCL+vHXlpjdJw6z9IAgX/c7Q1xNoDVZM72uFvMUm0JWoqDMtbQem7l6m6vMg77JUF0IRWj/F+gC2qzENCrsM7hxGSG5b/I/E+rY6gBhl/DsbKeSq0nf2PT+Opo3j0N+XcsPt5awcooKWpNglkBzZLbEGYFqNhhGl7UArHYmvVMYnc9d+RPsCyv7UeBW3c8pWJ8UxYwfbPuXNsWY/NdKr7wZ4YA== 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=mUUElAdvdJh+D5ylDiuHPd77Vc/uTt9K6bdBVLX95HU=; b=ovXWwBrGKYObnpv2sVxLjPkFssmV7JPXl5flQcTTMShRi8C1uj8VqCN9tazud+PDGJdGVPZSq4/SzxT8CMCMuc1n6p74maQSx2mCGtCy9YrlQ9ULOzqu/Bqo8vPt19aV/TsLmIvftievrtuGlPE0+XNs9h3k/2oIm4twlbUFrnY= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1914.namprd11.prod.outlook.com (2603:10b6:3:112::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Tue, 21 Apr 2020 08:58:49 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c%9]) with mapi id 15.20.2921.027; Tue, 21 Apr 2020 08:58:49 +0000 From: "Eric Vyncke (evyncke)" To: "rtg-dir@ietf.org" , "draft-ietf-anima-autonomic-control-plane.all@ietf.org" CC: "jmh@joelhalpern.com" , "jiangsheng@huawei.com" , "anima@ietf.org" Thread-Topic: Addressing RTG-DIR review (was Re: Last Call Expired: ) Thread-Index: AQHWF7sS7zHeq8+f80u1nYCc1Shp4g== Date: Tue, 21 Apr 2020 08:58:48 +0000 Message-ID: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:b9d9:3465:e20b:cd40] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23c71a52-2ee6-4d6a-cb07-08d7e5d234fc x-ms-traffictypediagnostic: DM5PR11MB1914: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 038002787A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(6506007)(91956017)(76116006)(4744005)(53546011)(8676002)(6486002)(5660300002)(81156014)(6512007)(54906003)(36756003)(2616005)(66446008)(110136005)(64756008)(66556008)(66946007)(66476007)(4326008)(86362001)(71200400001)(478600001)(8936002)(33656002)(316002)(186003)(2906002)(966005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 18TApjw8n7mc8OBwZvgbvkStCTW4X8fIFRE/7k5Eh8IPgkS5+wZfKhh0TyCpxk1vKq+NT5u9gyl9zS6RTruc8WstcU8D1FTrJt4PeOZbXfOukcqXfujZTG9lI2leiieQYbBfCjF7YyvwufWeijh9gFs9sGB1ulyo0OhiGsseHodlRFCtULBlM/NAuDOXI0FsOgXsJ3VJLYdwZYeblzUC2WlQz0yJ4r335h0DpXJ62Enx5yplpBXsWZVndO18Vpa3qVVAc74jhEA6k06UnkfpwJnNwxt5s6Pojoo0T+LKYGzR/0IDG9uMdQR9hncrbpBqlFO3hNT9ujYG0IMfv4gGNV9W0r6zwOWLYOiWWiEYz7dPVJhyxpOe6xfm6BUa5eWt+9Ze7/YlyNwA/ar+SYUfM6RV9WzscKYgbqmeGcUH/E1m3JotECNcSOCahtLE9aFq9VbiKfrAXzCRJBaxugFbBDq9UAd0kVTWwz7JTEZSCSi5W3rcU25ngzRp28jpQXTRj9Q1m/mzT8K/w8RanCMPSw== x-ms-exchange-antispam-messagedata: UaaIPm95iyjJ3mFPlOV6Y9fdnIx+PlYmZkGi9Yi4HeuJ1XxYCKMt76brtEm7zOA0uB8i9rZLKFM4gxC7ATm0PohUM1UFBGaKySQEHodUrpBW0EkwfDhNYdTmULFekfFGaaNR8B+Amk29VQrE6UPcbf5P7P9rzC7W95Xsstd7+hVejbtEKGvUvtu1uAvdK5T8ymvhYcjCiZIxD8SX5euYig== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6A744E3AA4CDDB41910FEA42BAC4C6EA@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 23c71a52-2ee6-4d6a-cb07-08d7e5d234fc X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 08:58:48.9240 (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: LnxqsYGAZ+mW/s1f2cU84KKOvhkUhhQ29bFOEP3OlO/OqkAI0opiHwbNTwcJA8nyqgYqlNe8GIuVAL6LxYkwIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1914 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: [RTG-DIR] Addressing RTG-DIR review (was Re: Last Call Expired: ) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 08:59:06 -0000 RGVhciBhdXRob3JzLA0KDQpQbGVhc2UgdXBsb2FkIGEgcmV2aXNlZC1JRCB0byBhZGRyZXNzIEpv ZWwgSGFscGVybidzIFJURy1ESVIgcmV2aWV3IGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyBlYXJs eSBBcHJpbC4gQXMgc29vbiBhcyB0aGUgcmV2aXNlZC1JRCBpcyB1cGxvYWRlZCwgdGhlbiBJIGFt IGNvbnRpbnVpbmcgdGhlIHB1YmxpY2F0aW9uIHByb2Nlc3MgX18NCg0KUmVnYXJkcyBhbmQgdGhh bmsgeW91IEpvZWwgZm9yIHRoZSByZXZpZXcNCg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBEcmFmdFRyYWNrZXIgTWFpbCBTeXN0ZW0gPGllc2ctc2VjcmV0 YXJ5QGlldGYub3JnPg0KRGF0ZTogVHVlc2RheSwgMjEgQXByaWwgMjAyMCBhdCAwOToyMw0KVG86 ICJkcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lQGlldGYub3JnIiA8ZHJh ZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFuZUBpZXRmLm9yZz4sICJqaWFuZ3No ZW5nQGh1YXdlaS5jb20iIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+LCBFcmljIFZ5bmNrZSA8ZXZ5 bmNrZUBjaXNjby5jb20+LCBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPg0KQ2M6 ICJpZXNnLXNlY3JldGFyeUBpZXRmLm9yZyIgPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPg0KU3Vi amVjdDogTGFzdCBDYWxsIEV4cGlyZWQ6IDxkcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250 cm9sLXBsYW5lLTI0LnR4dD4NCg0KDQogICAgUGxlYXNlIERPIE5PVCByZXBseSB0byB0aGlzIGVt YWlsLg0KDQogICAgSS1EOiA8ZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC1wbGFu ZS0yNC50eHQ+DQogICAgRGF0YXRyYWNrZXIgVVJMOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLw0KDQogICAg SUVURiBMYXN0IENhbGwgaGFzIGVuZGVkLCBhbmQgdGhlIHN0YXRlIGhhcyBiZWVuIGNoYW5nZWQg dG8NCiAgICBXYWl0aW5nIGZvciBBRCBHby1BaGVhZC4NCg0KDQoNCg==