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

[Aijun Wang <[e-mail]>]

HI, Dhruv:

I update the draft according to your comments, as illustrated below inline.
If we can make the conclusion, I will update and submit the draft according to our consensus. Or else, would you like to give additional suggestions?
Please see 【WAJ-3】

Best Regards.

Aijun Wang
China Telecom

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 代表 Dhruv Dhody
发送时间: 2020年6月1日 13:12
收件人: Aijun Wang <[e-mail]>
抄送: Lou Berger <[e-mail]>; TEAS WG <[e-mail]>
主题: Re: [Teas] WG Last Call: draft-ietf-teas-pce-native-ip-06

Hi Aijun,

Thanks for your reply, please see inline...

On Mon, Jun 1, 2020 at 6:51 AM Aijun Wang <[e-mail]> 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:

While the question is for the chairs, but IMHO the experimental track is the correct for this work and my review was based on that.

> 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.

While these *might* be true, there are a lot of unknowns (some of them highlighted in my review) that need to be worked through. Doing this as an experiment to gain knowledge and expertise in the use of PCEP and BGP in this way is the right way forward. When I asked to define the scope of the experiment, it was not to question the experimental track for this I-D.
【WAJ-3】: OK, let it stay at experimental track then. 

> 3. It needs to standardize the process and PCEP protocol extension to 
> assure the interoperability.
>

This is in the scope of PCE I-D and not this one.

> Welcome also the comments from other experts.
>
> Please see the detail responses below inline.
>
>
My replies are inline. I have trimmed to those comments that need further discussion.

>
> Best Regards.
>
> Aijun Wang
> China Telecom
>
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表 Dhruv 
> Dhody

<snip>

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

See 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.

How about this change then -


OLD:
   [RFC8735] describes the scenarios and simulation results for traffic
   engineering in native IP network.  To meet the requirements of
   various scenarios, the solution for traffic engineering in native IP
   network should have the following criteria:
NEW:
   [RFC8735] describes the scenarios and simulation results for traffic
   engineering in the native IP network to provide End-to-End (E2E) performance
   assurance and QoS using PCE based central control, referred to as
   Centralized Control Dynamic Routing (CCDR). Based on the various scenarios
   and analysis as per [RFC8735], the solution for traffic engineering in
   native IP network should have the following criteria:
END

【WAJ-3】: OK, Updated in next version.
>
>    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.
>

Since this is native IP, MPLS in dataplane (even though it is simpler) is a no-go! Maybe you can put Native IP as the very first criteria and then this would make more sense.
【WAJ-3】Combine another requirements with the this and form the first new requirement as " Support native IPv4 and IPv6 traffic in the same solution, no complex signaling procedures among network nodes like MPLS-TE and MPLS data plane."

>    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.
>

This is handled only at the controller (and the network nodes might not be aware of any of this), think of how you could highlight that.
Ignore if you think if it is implicit.
【WAJ-3】Change to "Achieve End to End traffic assurance, determined QoS behavior". This is the requirement for the solution, and candidate solution may have controller or not.

>     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.
>

Ah, say that instead :)
【WAJ-3】How about " Adjust the optimal path dynamically upon the change of network status. No physical links resources planning in advance."

> 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. "
>

Ok, I added some text in the comment (3), that should help too.

<snip>

> (5) Section 4,
> - 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.
>

If you want to use PF11 to PF21, say explicitly that this example is for bi-directional assurance. If not, just say traffic to PF21.


【WAJ-3】Make the following change (add the description "bi-direction" before the word "traffic")
OLD:
After the above actions, the traffic between the PF11 and PF21, and the traffic between PF12 and PF22 will go through different physical links between R1 and R2, each set of traffic pass through different dedicated physical links.

NEW:
After the above actions, the bi-direction traffic between the PF11 and PF21, and the bi-direction traffic between PF12 and PF22 will go through different physical links between R1 and R2, each set of traffic pass through different dedicated physical links.

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

The "almost impossible" in the original statement isn't true right?
Just reword it.
【WAJ-3】How about add "efficiently" and make the final sentence as " It is almost impossible to provide an End-to-End (E2E) path efficiently with latency, jitter, packet loss constraints to meet the above requirements in large scale IP-based network via the distributed routing protocol..."

<snip>

> (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."
>

Could not parse, do you mean -

   A PCE needs to assure the calculation of the E2E path based on the status
   of the network and the service requirements in real-time.
【WAJ-3】Update the document according to your suggestions.

> 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?
>

IMHO the best way to state the security analysis would be to describe how the procedure in this I-D could be exploited & list the possible attack vectors. Then state that the PCEP speakers need to use RFC8253 to make sure this doesn't happen.
【WAJ-3】：How about the following descriptions:
The setup of BGP session, prefix advertisement and explicit peer route establishment are all controlled by the PCE. To prevent the bogus PCE to send harmful messages to the network nodes, the network devices should authenticate the validity of PCE and keep secures communication channel between them. Mechanism described in RFC 8253 should be used to avoid such situation.

> (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?
>

I think this I-D need to be explicit about the use of stateful PCE and PCECC. This might be added even in the introduction to set the stage correctly. It should also talk about the state of paths (explicit peer
route) and state that the existing mechanisms could be reused.
【WAJ-3】-07 version has mentioned RFC 4655 and RFC 8283. Is that enough?


> - 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."
>

Are you assuming a single PCE for multiple domains? What happens in the case of multiple PCE?
Also, not sure what happens to the explicit peer route based on the above statement that you added?
【WAJ-3】a single PCE or PCE pool to cover these domains that under the control of one administrator. The messages to the network devices from PCE is sent separately. 


> - Impact of dynamic BGP session created based on CCDR.
> 【WAJ】No extra impact. Similar that you build multiple BGP sessions via 
> configuration.

There is a difference between sessions created by configuration v/s sessions created dynamically. Such as ephemeral nature, handling of misconfigurations, default values, number of such dynamic sessions etc.
【WAJ-3】：section 6 of the version 07 has state the ephemeral status of these sessions. Can such consideration be expanded in the PCEP extension draft?

> - 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

I guess you need to state that it is the job of the administrator to ensure that.
【WAJ-3】How about add "route preference" description and change this sentence to "The explicit route created by PCE has the higher priority (lower route preference) 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.
>

This should be cleared on the expiration of state timeout interval based on the local policy, otherwise, service would have an immediate impact on the PCEP session flap. Reword it to say that state cleanup could be based on the existing Stateful PCE and PCECC mechanism.
【WAJ-3】How about "All above dynamically created states (BGP sessions, Prefix advertised prefix, Explicit route) will be cleared on the expiration of state timeout interval which is based on the existing Stateful PCE(RFC8231) and PCECC(RFC8283) mechanism."

I would suggest adding the 'other considerations' section and adding explicit text for these
- you could state that some of them would be handled by extension I-D,
- you can state some procedures remain the same,
- you can say no impact at all
- just say something :)

【WAJ-3】：After above update, can "deployment consideration" cover all of them? Or else, we add another sub section under the "deployment consideration"?

<snip>

Thanks!
Dhruv

_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas