PCE-Based Traffic Engineering (TE) in Native IP Networks
draft-ietf-teas-pce-native-ip-17

[[ nits ]]

[ section 3 ]

* s/The topology is comprises/The topology comprises/

  or

  s/The topology is comprises/The topology is composed of/

  I think.

[ section 7.1 ]

* s/of the differentiate prefixes/of the different prefixes/?

Just some nits here, adding to what Erik found:

Section 3:

"The topology is comprises four devices ..." should be "The topology is comprised of four devices ..." or "The topology comprises four devices ..."

In the third bullet: "For example, PF11/PF21 via ..." -- I suggest putting "send" before "PF11/PF21".

"... achieving the needed QoS assurance ..." -- suggest changing "achieving" to "satisfying" (since you used "achieve" already in that sentence)

Section 4:

I can't quite parse the first sentence, specifically the end of it.

Section 5:

"... is as the follows:" -- remove "the"

Section 8:

"... BGP security consideration." -- s/consideration/considerations/

"There will no additional ..." -- add "be" before "no", or change "will" to "are"

Thanks to Donald Eastlake for the SECDIR review

** Section 8.  Since PCE is used to setup the BGP sessions, etc., the references to the Security Considerations of PCE specs should be reiterated as applying – minimally RFC5440 and RFC8231.  

** To restate Alvaro Retana's comment #9, RFC8231 already notes that malicious PCE and PCCs are possible (see above comment).  In this context, the new variant relevant to this architecture would be in form of (malicious) BGP configurations.  It's worth highlighting.

Thank you for the work put into this document. I love the oxymoron approach with "The solution combines the use of distributed routing protocols and a centralized controller" ;-)

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Am I right when inferring that for each TE path there is a need to add one loopback interface/address on every edge router + 1 BGP session ? How will it scale ? Should there be a mention somewhere of this limitation (if confirmed) ? I saw nothing in section 7.1 (scalability).


-- Abstract --
"it ... identifies needed extensions for the Path Computation Element Communication Protocol (PCEP)", at first sight, it seems that it is an incomplete document or a problem statement until reading the last sentence of the introduction. May I suggest to change the sentence in the abstract in a more assertive way ?

-- Section 3 --
Suggest to define the lo11 & others as the loopback interfaces in the first bullet in the list.

I am far from being an expert in BGP and routing but isn't the link selection still done *only* on the destination prefix ? I fail to see how the source prefix is used in the forwarding decision (except for the return traffic). I.e., there is no traffic isolation as PF11 can sent traffic to PF22 using the link 'reserved' for PF12 to PF22.

-- Section 4 --
Suggest to add 'RR' in the R3 box.

== NITS ==

several s/large scale/large-scale/ ?

The usual way for acronyms is "Path Computation Client (PCC)" rather than "PCC (Path Computation Client)"

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

Even if this is no longer characterized as "experimental" I agree with
the rtgdir reviewer that it would be interesting to eventually see a report of the
results of the not-experiment, when known.

Section 4

   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, for example, the iBGP within one AS.

nit: what is "the iBGP within one AS" an example of?  If it's "a large
scale network" that priority traffic spans, this clause should probably
be relocated.

Section 5

   For Prefix Set No.1, we can select the shortest distance path to
   carry the traffic; for Prefix Set No.2, we can select the path that
   has end to end under loaded links; for Prefix Set No.3, we can let

nit: hyphenate "under-loaded links".

Section 6

   o  Advertised prefixes and their associated BGP session.

Is conveying BGP session information via PCEP going to introduce an
additional layer of statefullness to the system?  Or will the PCEP be
able to determine and configure everything in a single pass as it
currently does?

Section 7.1

I agree with Alvaro that the comparison to flowspec is not serving a
useful purpose in its present form.

Section 8

Increasing the number of BGP sessions (and router loopback addresses,
routes, etc.) seems like it would incrementally add to the baseline load
on such systems, and thus the risk that transient spikes in load could
lead to denial of service.

Section 11.1

It's not entirely clear to me that, at least based on where we currently
reference it, RFC 4655 needs to be characterized as normative.

I also don't think that RFC 8735 needs to be normative; we seem to
replicate the key list of requirements and not rely on the reference for
them.

Section 11.2

On the other hand, if the extensionns from
draft-ietf-pce-pcep-extension-native-ip are truly necessary for the
system to work (per §6), then it needs to be characterized as normative.

I think this whole idea is based on the fact that you can actually have multiple different prefix the traffic based on the network treatment it should have. I think that has very limited applicability unless we are talking a deployment where one target tunnels between in ingress and egress that does traffic classification based on other aspects. Can this assumption about that the IP traffic needs to use different IP addresses with different prefix to get any differential treatment be expanded in the discussion?

I am a bit confused that a design objective (sec 1) is “ No changes in a router's forwarding behavior”. Isn’t that what this whole draft is about?

Hi,

It might be helpful if this document had a short section covering operational considerations for monitoring and managing TE traffic when being deployed in this way.

Regards,
Rob