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

From: "Aijun Wang" <[email-masked]>
Date: Mon, 1 Jun 2020 09:21:07 +0800

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

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 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
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 31 May 2020 21:58:23 -0400

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

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 1 Jun 2020 10:41:39 +0530

Hi Aijun,

Thanks for your reply, please see inline...

> "Experimental" to "Standard". The reasons for this change are the

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.

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

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

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

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

> 发件人: [email-masked] [mailto:[email-masked]] 代表 Dhruv

<snip>

> for the response from the chair. The reasons for this are stated at above.

See above.

> 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

> 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】This is the ultimate aim the technology selection and design aim of

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.

> and not the static planning.

Ah, say that instead :)

> protocols to forward such traffic. "

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

<snip>

> assurance. Actually, the two directions can be deployed separately, same as

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.

> different groups in advance. We think it will lead to the inefficiently

The "almost impossible" in the original statement isn't true right?
Just reword it.

<snip>

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

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

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

> 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】No extra impact. Similar that you build multiple BGP sessions via

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.

> configured

I guess you need to state that it is the job of the administrator to
ensure that.

> All above dynamically created states (BGP sessions, Prefix

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.

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

<snip>

Thanks!
Dhruv