From nobody Wed Jan 20 20:03:53 2021 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F773A1724; Wed, 20 Jan 2021 20:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9JyXaHQgRD1; Wed, 20 Jan 2021 20:03:44 -0800 (PST) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id 81F103A1721; Wed, 20 Jan 2021 20:03:39 -0800 (PST) HMM_SOURCE_IP: 172.18.0.218:42254.766028543 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.75?logid-82e134170d3f49c29ff1c5429bac7232 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id E69152800D7; Thu, 21 Jan 2021 12:03:33 +0800 (CST) X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn Received: from ([172.18.0.218]) by App0025 with ESMTP id 82e134170d3f49c29ff1c5429bac7232 for aretana.ietf@gmail.com; Thu Jan 21 12:03:37 2021 X-Transaction-ID: 82e134170d3f49c29ff1c5429bac7232 X-filter-score: filter<0> X-Real-From: wangaj3@chinatelecom.cn X-Receive-IP: 172.18.0.218 X-MEDUSA-Status: 0 Sender: wangaj3@chinatelecom.cn From: "Aijun Wang" To: "'Alvaro Retana'" , "'The IESG'" Cc: , , , "'Lou Berger'" References: <161109892227.30874.13864469740243759762@ietfa.amsl.com> In-Reply-To: <161109892227.30874.13864469740243759762@ietfa.amsl.com> Date: Thu, 21 Jan 2021 12:03:31 +0800 Message-ID: <001901d6efaa$650f7940$2f2e6bc0$@chinatelecom.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKYmxev4dursDqOX3nBv4OMsHHCyqiuAOiA Content-Language: zh-cn Archived-At: Subject: Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 04:03:47 -0000 Hi, Alvaro: Thanks for your review and comments. I have updated the draft accordingly and will upload the new version = together with comments from other experts. Thanks again for your efforts. Some discussions are detail inline below. Wish to get your consent. Best Regards Aijun Wang China Telecom -----Original Message----- From: noreply@ietf.org =20 Sent: Wednesday, January 20, 2021 7:29 AM To: The IESG Cc: draft-ietf-teas-pce-native-ip@ietf.org; teas-chairs@ietf.org; = teas@ietf.org; Lou Berger Subject: Alvaro Retana's No Objection on = draft-ietf-teas-pce-native-ip-15: (with COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-teas-pce-native-ip-15: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some significant issues with this document. While none of these = raise to the level of a DISCUSS, they result in what I consider an = incomplete document, and I would want them to be addressed before = publication -- specifically points 1-5. (1) In general, the solution presented seems to assume that there will = be an independent E2E physical path per priority group/set of prefixes. = As the number of groups/sets increases, the probability of finding = node-disjoint paths across a network diminishes significantly. Link-disjoint paths = can also have issues. I would like to see a discussion about the required = disjointness, and considerations for reusing links/nodes. [WAJ] Yes, the group/set of prefixes may have some joint nodes/links on = their optimal paths, but this will not lead to some issues, because PCE = can ensure such path fulfill the QoS requirements of the application, = based on the existing traffic of previous assigned group/set of = prefixes. That is to say, the E2E path will be calculated independently based on = the network real situation, but the path(nodes/links) may/will be shared = by these prefixes set. =20 The last but one paragraph in section 3 has some discussion for such = scenarios as: "If, for example, there is bi-directional priority = traffic from another address pair (for example prefix PF13/PF23), and = the total volume of priority traffic does not exceed the capacity of the = previously provisioned physical links, one need only advertise the newly = added source/destination prefixes via the BGP session 2. The = bi-directional traffic between PF13/PF23 will go through the same = assigned dedicated physical links as the traffic between PF12/PF22." Is = that enough, or add more descriptions in section 7.1? (2) =C2=A76: "Different BGP sessions are used mainly for the = clarification of the network prefixes, which can be differentiated via = the different BGP nexthop." I would be interested to understand why simply advertising a different = NEXT_HOP, while maintaining a single BGP session was discarded as part = of the solution. As you mention in this sentence, the real = differentiator is the next hop -- if the advertised prefixes are always = different then changing the NEXT_HOP should also be a valid solution. = Given that this document defines the architecture, and that the PCEP = extensions will be based on it, it would be ideal if alternate = implementations (minimally different in this case) were not precluded. [Disclaimer: I haven't looked at = I-D.ietf-pce-pcep-extension-native-ip in detail, but it looks like using a single BGP session is not = supported. :-(] [WAJ] We have also discussed the solution that using only one BGP = session but change the NEXT_HOP offline, and actually there is one = expired = draft(https://datatracker.ietf.org/doc/html/draft-huang-teas-bgp-communit= y-pce-00) to propose this. The reason that we does not follow this = direction are the followings: A: Using different sessions is more management and understandable. B: The traffic will always be assured bidirectional, using BGP session = can easily match the source/destination pair. (3) =C2=A77.1: "the on-path router needs only to keep the specific = policy routes for the BGP next-hop of the differentiate prefixes, not = the specific routes to the prefixes themselves. ... For example, if we = want to differentiate 1000 prefixes from the normal traffic, CCDR needs = only one explicit peer route in every on-path router." You may need to = expand on this concept. As far as I can tell, the traffic is natively = transported through the network, with a destination IP address = corresponding to one of the differentiated prefixes, not the BGP next = hop. IOW, routes to the prefixes are still needed (as explained in = =C2=A73/=C2=A74), but the steering is achieved through the individual = "explicit peer routes". Am I missing something? [WAJ] Yes, there is routes to prefixes in the RIB and FIB, but such = routes are derived from the recursive process of "BGP nexthop of the = prefixes(information from BGP)" and "the route the BGP nexhop" = (information from IGP or "explicit peer routes" )=20 (4) =C2=A77.2: "If one node on the optimal path fails, the priority = traffic will fall over to the best-effort forwarding path." This = statement is only true/possible if the prefixes associated with the = priority traffic are also advertised through the BGP sessions associated = with the best-effort path...or if there is an alternate path to the = corresponding next-hop. Neither of these options is explained in = =C2=A73-5. [WAJ] There is an alternate path to the corresponding next-hop. = Actually, such path will be learned via IGP. The "explicit peer route" = from PCE has higher preference than the IGP path. If acceptable, I can add the above description into the section 7.2 (5) This document provides a description of the architecture, and as = mentioned in =C2=A76: "Details...are out of scope of this draft and will = be described in a separate document = [I-D.ietf-pce-pcep-extension-native-ip]." However, the description = depends on the extensions/behavior from = I-D.ietf-pce-pcep-extension-native-ip in a couple of places: =C2=A75: o PCE sends the route information to the routers (R1,R2,R4,R7 in Figure 3) on the forwarding path via PCEP [I-D.ietf-pce-pcep-extension-native-ip], to build the path to the BGP next-hop of the advertised prefixes. [WAJ] How about change the sentence to " PCE sends the route information = to the routers (R1,R2,R4,R7 in Figure 3) on the forwarding path via = PCEP, for example, as that described in = "I-D.ietf-pce-pcep-extension-native-ip", to build the path to the BGP = next-hop of the advertised prefixes" =C2=A77.3: Not every router within the network needs to support the PCEP extension defined in [I-D.ietf-pce-pcep-extension-native-ip] simultaneously. [WAJ] How about change the sentence to " Not every router within the = network needs to support the PCEP extension, for example, as that = defined in [I-D.ietf-pce-pcep-extension-native-ip] simultaneously." These references make I-D.ietf-pce-pcep-extension-native-ip a normative = reference because it is necessary to implement the architecture. Please = write these two paragraphs in a solution-neutral way (using = I-D.ietf-pce-pcep-extension-native-ip as an example is ok). (6) =C2=A75: "PCE sends the prefixes information to the PCC for = advertising different prefixes via the specified BGP session." = Specifically, I think you mean the RR. s/PCC/RR [WAJ] Here the PCE should send the prefixes information directly to the = PCC, not RR. RR is just used to by PCC, to advertised such prefixes to = other BGP peer(also PCC)=20 (7) =C2=A77.1: "Unlike the solution from BGP = Flowspec[I-D.ietf-idr-rfc5575bis]..." This is the only place where flowspec is mentioned. Referencing a = different potential solution without a proper comparison (either in this = document or rfc8736, where it is not even mentioned) is out of place. = Please focus on the considerations related to this solution, and not the = potential downsides of others. [WAJ] OK, I will delete the first sentence of this paragraph. It will = begin with "The on-path router needs only to keep ..." (8) =C2=A78: "See [RFC7454] for BGP security consideration." rfc7454 is = not the best reference for BGP-specific security considerations, please = use rfc4271/rfc4272 instead (or in addition). [WAJ] Changed to refer RFC4271 and RFC4272 (9) =C2=A78: Note that even if the PCE/PCC connection is secured, a = rogue PCE may still harm the network: it may set up more BGP sessions = than required (resulting in more control traffic, routes, etc.), it may = direct the BGP speakers to advertise the wrong routes (more, less, = etc.), it may instantiate incorrect explicit routes... While this is = not a new risk, it should me mentioned in the context of the described = architecture. [WAJ] OK, will add the above description in section 8, and add one more = description at the end of the description as "The authentication of PCE = on the PCCs should also be considered." (10) [nits] =C2=A72: s/Other terms are defined in this document/Other terms are used = in this document [WAJ] Done =C2=A73: s/in simple topology/in a simple topology [WAJ] Done =C2=A73: s/topology is comprises/topology comprises [WAJ] Has changed to "The topology is composed of four devices", as = proposed also by Erik Kline =C2=A74: s/for example, the iBGP within one AS/for example, using iBGP = within one AS [WAJ] Has changed sentences to "When the priority traffic spans a large = scale network, such as that illustrated in Figure 2, the multiple BGP = sessions cannot be established hop by hop within one AS. For such a = scenario, we propose... ...". as also comments from Murray Kucherawy. 5: s/as that described in/as described in [WAJ] Done