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

[Dhruv Dhody <[e-mail]>]

Hi Aijun,

Snipping to few comments that need discussion, see inline...

<snip>

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

Also, consider adding the text I proposed describing the experiment scope.

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

Ok, please do this change in all the instances.

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

Suggest adding this in Introduction -

   Stateful PCE [RFC8231] specifies a set of extensions to PCEP to
   enable stateful control of paths such as MPLS-TE LSPs between and
   across PCEP sessions in compliance with [RFC4657].  It includes
   mechanisms to affect state synchronization between PCCs and PCEs,
   delegation of control of LSPs to PCEs, and PCE control of timing and
   sequence of path computations within and across PCEP sessions.
   Furthermore, [RFC8281] specifies a mechanism to dynamically instantiate
   LSPs on a PCC based on the requests from a stateful PCE or a controller
   using stateful PCE.

   [RFC8283] introduces the architecture for PCE as a central controller
   as an extension of the architecture described in [RFC4655] and
   assumes the continued use of PCEP as the protocol used between PCE
   and PCC.  [RFC8283] further examines the motivations and
   applicability for PCEP as a Southbound Interface (SBI), and
   introduces the implications for the protocol.


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

Inter-domain in PCE also involves the use of per-domain PCE and case
in which per-domain PCE interact with say a parent-PCE. I feel that
you are assuming that a single PCE or a PCE pool is responsible for
all domains and thus there is no much difference between intra-domain
and inter-domain for you. You should state that clearly, something
like - "In the scope of this experiment for inter-domain case, a
single PCE or a pool of PCEs is responsible for multiple domains."

> > - 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."
>
How about this -

   By making sure that the explicit route created by PCE has the
   higher priority (lower route preference) than the route information
   created by any other protocols (including the route manually configured),
   the path selected by PCE is used at the node.


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

One section is fine!

Thanks!
Dhruv