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

["Joel M. Halpern" <[e-mail]>]

As an experimental RFC, I can't object to the content.  Finding out if 
this approach works well is understandable.
If it is proposed to make this a standard, without experimental 
deployment first, I would be very nervous.

Yours,
Joel

On 5/31/2020 9:21 PM, Aijun Wang wrote:
> Hi, Dhruv:
> 
> We have updated the draft according your comments, please view it again and
> wish to get your comments on the update.
> 
> For the document track, we want to ask chair to change it from
> "Experimental" to "Standard". The reasons for this change are the
> followings:
> 1. Central control component is necessary for various networks/technologies
> to accomplish the E2E QoS assurance, such as MPLS, SRv6. and Native IP
> network.
> 2. Native IP network deployment is the trending in near future, alongside
> the emerge of Cloud Overlay solution.
> 3. It needs to standardize the process and PCEP protocol extension to assure
> the interoperability.
> 
> Welcome also the comments from other experts.
> 
> Please see the detail responses below inline.
> 
> 
> 
> Best Regards.
> 
> Aijun Wang
> China Telecom
> 
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表 Dhruv
> Dhody
> 发送时间: 2020年5月29日 20:46
> 收件人: Lou Berger
> 抄送: TEAS WG
> 主题: Re: [Teas] WG Last Call: draft-ietf-teas-pce-native-ip-06
> 
> 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-' :)
> 【WAJ】Accepted.
> 
> (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].
> 【WAJ】We have asked the TEAS chair to change the track to "Standard". Wait
> for the response from the chair. The reasons for this are stated at above.
> 
> (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,
> 【WAJ】These requirements are proposed based on the scenarios described in
> RFC8735. When we want to adopt or develop some technologies, we should
> evaluation them in various aspects.
> 
>     o  No complex Multiprotocol Label Switching (MPLS) signaling
>        procedures.
> 
>      Why signaling alone? Isn't data-plane as native IP, one of the key
>      requirements?
> 【WAJ】For MPLS to achieve the Traffic Engineering aim, the complex part is
> the signaling, network node must preserve the machine state during
> signaling. The data plane itself is straightforward.
> 
>     o  End to End traffic assurance, determined Quality of Service (QoS)
>        behavior.
> 
>      Should we specify that this in the control plane?
> 【WAJ】This is the ultimate aim the technology selection and design aim of
> the control plane.
> 
>      o  Flexible deployment and automation control.
> 
>      IMHO too generic (and marketing).
> 【WAJ】Just want to express the solution should adjust the path dynamicly
> and not the static planning.
> 
> Also, please describe CCDR in the Introduction. Jumping directly into
> example in section 4 is not right.
> 【WAJ】:Add the following description to explain the CCDR: " It depends on
> the central control (PCE) element to compute the optimal path for selected
> traffic, and utilizes the dynamic routing behavior of traditional IGP/BGP
> protocols to forward such traffic. "
> 
> (4) If you don't use RFC 2119 keywords, then remove section 2.
> 【WAJ】Accepted.
> 
> (5) Section 4,
> 
> - you should be explicit that IP11, IP12 are IP prefix.
> 【WAJ】: Done, change also the name from IP to PF respectively.
> 
> - you need to describe the term "explicit peer routes"? How is it
>    different from a static route?
> 【WAJ】：Want to emphasize that the route is to BGP peer(the loopback
> address on border router), not to the final destination(PF11/PF12/PF21/PF22)
> 
> - I think we should say that section 4 is only for illustrative
>    Purpose
> 【WAJ】：The simple topology is just for showing the key points of the CCDR
> solution.
> 
> - 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?
> 【WAJ】：You are right. The forwarding is based on destination address. Use
> the pair just want to show normally the application requires bi-direction
> assurance. Actually, the two directions can be deployed separately, same as
> the MPLS LSP.
> 
> (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...
> 【WAJ】The deployment of Flex-algo requires the allocation of links into
> different groups in advance. We think it will lead to the inefficiently
> usage of physical links.
> 
> Also, consider avoiding using term flow and focus on just prefix.
> 【WAJ】Done, Changed the "flow" to "Prefix Set"
> 
> (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?
> 【WAJ】 Yes. The loopback address should be planned in advance and be
> distributed in the domain.
> Has added the sentence to describe this.
> 
> - how does PCE learn the prefix and QoS requirement
> 【WAJ】Via the Northbound interface of SDN Controller/PCE. Redraw the graph
> to reflect this.
> 
> (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)?
> 【WAJ】Delete the analogy to avoid possible misunderstanding.
> 
> (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.
> 【WAJ】Change the sentence as " A PCE assures calculations of E2E path upon
> the status of network condition and the service requirements in real time."
> 
> 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.
> 【WAJ】Currently, we assumed the interaction between PCE and the underlying
> devices is secured, via the PCEPS, as described in RFC8253. The PCE and
> their communication is authorized/authenticated. It seems impossible to
> encounter bogus bgp seesion and incorrect prefix?
> 
> (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
> 【WAJ】These depend on the existing mechanism. No special requirements.
> Would you like to provide some text or thoughts?
> 
> - Multi-domain case - as that is listed as a key benefit of CCDR.
> 【WAJ】Add sentence at the "Scalability" part: "For multiple domain
> deployment, the PCE need only control the edge router to build multiple eBGP
> sessions, all other procedures are the same that in one domain."
> 
> - Impact of dynamic BGP session created based on CCDR.
> 【WAJ】No extra impact. Similar that you build multiple BGP sessions via
> configuration.
> - Impact of "explicit peer routes" and their interaction with other
>    routes.
> 【WAJ】Add some sentence at section "PCEP extension for key parameter" as
> below:
> "The explicit route created by PCE has the higher priority than the route
> information created by other protocols, including the route manually
> configured All above dynamically created states (BGP sessions, Prefix
> advertised prefix, Explict route) will be cleared once the connection
> between the PCE and network devices is interrupted.
> These parts will be considered in more detail in protocol extension draft.
> 
> - Document does not mention removal and modification at all
> 【WAJ】：Depends on the existing LSP removal/modification mechanism. If
> necessary, will expand it in the protocol extension draft.
> 
> - Comparison to other techniques is distributed in various section,
>    maybe collect them in appendix
> 【WAJ】：try to focus on the "Deployment Consideration" part.
> 
> (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.
> 【WAJ】Has removed the well-known abbreviation expansion. If necessary,
> expand it later again.
> 
> - 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
> 【WAJ】Done
> 
> Thanks!
> Dhruv
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>