[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