[Teas] Alvaro Retana's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)
Alvaro Retana via Datatracker <noreply@ietf.org> Tue, 19 January 2021 23:28 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D143A18B3; Tue, 19 Jan 2021 15:28:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-teas-pce-native-ip@ietf.org, teas-chairs@ietf.org, teas@ietf.org, Lou Berger <lberger@labn.net>
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <161109892227.30874.13864469740243759762@ietfa.amsl.com>
Date: Tue, 19 Jan 2021 15:28:42 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/6N58_nYRGNbBQ2wow0ObYOyz1TY>
Subject: [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
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2021 23:28:48 -0000
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. (2) §6: "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. :-(] (3) §7.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 §3/§4), but the steering is achieved through the individual "explicit peer routes". Am I missing something? (4) §7.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 §3-5. (5) This document provides a description of the architecture, and as mentioned in §6: "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: §5: 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. §7.3: Not every router within the network needs to support the PCEP extension 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) §5: "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 (7) §7.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. (8) §8: "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). (9) §8: 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. (10) [nits] §2: s/Other terms are defined in this document/Other terms are used in this document §3: s/in simple topology/in a simple topology §3: s/topology is comprises/topology comprises §4: s/for example, the iBGP within one AS/for example, using iBGP within one AS 5: s/as that described in/as described in
- [Teas] Alvaro Retana's No Objection on draft-ietf… Alvaro Retana via Datatracker
- Re: [Teas] Alvaro Retana's No Objection on draft-… Aijun Wang
- Re: [Teas] Alvaro Retana's No Objection on draft-… Alvaro Retana
- Re: [Teas] Alvaro Retana's No Objection on draft-… Aijun Wang