Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-pce-native-ip-15: (with COMMENT)

Aijun Wang <> Thu, 21 January 2021 04:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1F773A1724; Wed, 20 Jan 2021 20:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A9JyXaHQgRD1; Wed, 20 Jan 2021 20:03:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 81F103A1721; Wed, 20 Jan 2021 20:03:39 -0800 (PST)
Received: from clientip- (unknown []) by (HERMES) with SMTP id E69152800D7; Thu, 21 Jan 2021 12:03:33 +0800 (CST)
Received: from ([]) by App0025 with ESMTP id 82e134170d3f49c29ff1c5429bac7232 for; Thu Jan 21 12:03:37 2021
X-Transaction-ID: 82e134170d3f49c29ff1c5429bac7232
X-filter-score: filter<0>
X-MEDUSA-Status: 0
From: "Aijun Wang" <>
To: "'Alvaro Retana'" <>, "'The IESG'" <>
Cc: <>, <>, <>, "'Lou Berger'" <>
References: <>
In-Reply-To: <>
Date: Thu, 21 Jan 2021 12:03:31 +0800
Message-ID: <001901d6efaa$650f7940$2f2e6bc0$>
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-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: <> 
Sent: Wednesday, January 20, 2021 7:29 AM
To: The IESG <>
Cc:;;; 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
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


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.   

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) §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. :-(]
[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( 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) §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?
[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" ) 

(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.
[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 §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:

   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"

   Not every router within the network needs to support the PCEP
   extension defined in [I-D.ietf-pce-pcep-extension-native-ip]
[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) §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
[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) 

(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.
[WAJ] OK, I will delete the first sentence of this paragraph. It will begin with "The on-path router needs only to keep ..."

(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).
[WAJ] Changed to refer RFC4271 and RFC4272

(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.
[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]

§2: s/Other terms are defined in this document/Other terms are used in this document
[WAJ] Done

§3: s/in simple topology/in a simple topology
[WAJ] Done

§3: s/topology is comprises/topology comprises
[WAJ] Has changed to "The topology is composed of four devices", as proposed also by Erik Kline

§4: 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