Re: [Teas] WG Last Call: draft-ietf-teas-pce-native-ip-06

[Aijun Wang <[e-mail]>]

Hi, Dhruv:
Thanks for your comments.
We will update the draft in next week to reflect/resolve your comments. The details responses will come along at the same time.

Any other comments are all welcome.

Aijun Wang
China Telecom

> On May 29, 2020, at 20:47, Dhruv Dhody <[e-mail]> wrote:
> 
> Hi WG, Authors,
> 
> As an experimental framework based on RFC 8735, I am fine with
> publication of this document. But I do have comments and thoughts on
> what is missing in this I-D. Request authors and shepherd to consider
> them before we ship this out of the WG.
> 
> (1) I find the term "Dual/Multi-" used throughout in this document to
> be bit weird. Well 'multi-' includes 'dual-' :)
> 
> (2) We need to add some text that describes the experimental nature of
> this work. Something in line with
> 
>   The procedures described in this document are experimental.  The
>   experiment is intended to enable research for the usage of PCE in
>   native IP scenarios.  For this purpose, this document describe the
>   CCDR framework and the PCEP extension is specified in
>   [I-D.ietf-pce-pcep-extension-native-ip].
> 
> (3) Section 1
> 
> We should be clear on where are these requirements coming from. Can we
> say that they are based on the scenarios listed in RFC 8735(?), so it
> does not read out of place. More importantly, the list is a mix of
> technology choices, deployment limitations, and abstract philosophy;
> calling them requirement may be a stretch. Further,
> 
>   o  No complex Multiprotocol Label Switching (MPLS) signaling
>      procedures.
> 
>    Why signaling alone? Isn't data-plane as native IP, one of the key
>    requirements?
> 
>   o  End to End traffic assurance, determined Quality of Service (QoS)
>      behavior.
> 
>    Should we specify that this in the control plane?
> 
>    o  Flexible deployment and automation control.
> 
>    IMHO too generic (and marketing).
> 
> Also, please describe CCDR in the Introduction. Jumping directly into
> example in section 4 is not right.
> 
> (4) If you don't use RFC 2119 keywords, then remove section 2.
> 
> (5) Section 4,
> 
> - you should be explicit that IP11, IP12 are IP prefix.
> - you need to describe the term "explicit peer routes"? How is it
>  different from a static route?
> - I think we should say that section 4 is only for illustrative
>  purpose
> - I am not sure why the description is in terms of address pairs
>  (IP11, IP21) and (IP12, IP22) - what happens if one sends traffic
>  from IP11 to IP22? I guess the forwarding would be based on
>  destination IP22 and the traffic would be sent to the link
>  associated with it? Doesn't it make more sense to describe things in
>  terms of IP prefix?
> 
> (6) Section 6, you have -
> 
>   It is almost impossible to provide an End-to-End (E2E) path with
>   latency, jitter, packet loss constraints to meet the above
>   requirements in large scale IP-based network via the distributed
>   routing protocol...
> 
> Well flex-algo to some extent could do this. So maybe reword this...
> Also, consider avoiding using term flow and focus on just prefix.
> 
> (7) Section 7, Add some text on -
> 
> - the loopback address used for the multi-BGP session. Do they exist
>  at edge routers/RR already and PCE selects them?
> - how does PCE learn the prefix and QoS requirement
> 
> (8) Section 9.2,
> 
>   If one node on the optimal path is failed, the priority traffic will
>   fall over to the best-effort forwarding path.  One can even design
>   several assurance paths to load balance/hot-standby the priority
>   traffic to meet the path failure situation, as done in MPLS Fast
>   Reroute (FRR).
> 
> Not sure how MPLS FRR is applicable here (perhaps IP FRR for static
> routes)?
> 
> (9) Section 10,
> 
>   The PCE should have the capability to calculate the loop-free E2E
>   path upon the status of network condition and the service
>   requirements in real time.
> 
> This is true for any PCE, don't think it belongs in Security
> consideration. This section needs to be improved as one can use PCEP
> to create bogus BGP sessions and we need to consider what would be
> impact on that. Further what would be the impact of incorrect prefix,
> can this be used to misdirect traffic.
> 
> (10) Other considerations - Few things that are missing -
> 
> - PCE and PCEP considerations - Stateful nature of PCE, path state at
>  the PCE, synchronization of the state etc
> - Multi-domain case - as that is listed as a key benefit of CCDR.
> - Impact of dynamic BGP session created based on CCDR.
> - Impact of "explicit peer routes" and their interaction with other
>  routes.
> - Document does not mention removal and modification at all
> - Comparison to other techniques is distributed in various section,
>  maybe collect them in appendix
> 
> 
> (11) Nits
> - I suggest following the abbreviation guideline as per
>  https://www.rfc-editor.org/materials/abbrev.expansion.txt; I see
>  some well-known terms (BGP, PCE) expanded. Look for (*) in the link.
> - Remove "Draft" in section 1 - "Draft [RFC8735] describes..."
> - Section 1, s/differentiation/different/
> - Not a good idea to have Lo0, Lo1 on both R1 and R2 - perhaps Lo11,
>  Lo12 and Lo21, Lo22?
> - Add reference for BGP stuff like RR
> 
> Thanks!
> Dhruv
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas