Subject: Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt

From: <[email-masked]>
Date: Wed, 13 Feb 2019 19:09:27 +0100

Hello Adrian, all,

Sorry for the long silence, answers below.

Le 11/12/2018 à 19:01, Adrian Farrel a écrit :
>
> Hi,
>
>  
>
> This seems very reasonable to me, and I think there are three points to remember:
>
>  
>
>  1. There is an important difference between a functional architecture and an implementation/deployment. So, just as we had all the way back in 4655, functional components may actually be realised inside different implementation components or as distinct components. This is illustrated for ACTN in the slides that Sergio attached.
>
I agree with the functional point of view of MSCD, but, we must take into account the way peering agreements are negotiated. Just look at how BGP is working. Peering agreements are done on a bilateral way and BGP exchanges are performed only and only if you exchange some data with your peer. Taking a simple example where two providers A & B are connected through respectively a transit T1 and T2 which are connected each together and there is no direct connectivity between A & B. This is a classic Tiers2-3/Tiers1 relation. A establishes a BGP peering with T1 and B do the same with T2. T1 & T2 have already a BGP peering agreement. But, at any moment A and B will peer directly nor A peer with T2 and B peer with T1. Now, if I would apply your ACTN principle, we could envisage several scenarios:

  * Transit T1 act as the parent and could request some paths to A and T2, but can't do that with B. Indeed, B has no relation with T1 and so, no reason to setup an ACTN relation with T1. It is like if you would connect the BGP route reflector (RR) of B with the RR of T1.
  * Transit T2 act as the parent and could request some path to B and T1, but for the same reasons, can't do that with A.
  * It is even worse if A or B act as the parent.

So, there is no solution even if, from the functional point of view is completely feasible. We could also simplify the scenario with only one transit. But, again, this impose that never A or B will act as parent letting transit T impose its own policy. Not sure that business will agree.

Now, if we compare the signalling with a BRPC one:

  * ACTN: A request some e2e path to T, which in turn compute its part, request part to A and B and then send answer to A. Total 3 requests and 3 answers. Potential parallelism 2, so we could reduce to 2 requests and 2 answers
  * BRPC: A request to T which request to B which reply to T which reply to A. Total 2 requests and 2 answers

Match null. But BRPC preserve each operator to apply their own policy.

> 1.
>
>
>  2. The ACTN architecture is recursive, so that a collection of domains may lie under the control of one MSDC, and another collection of domains under another MSDC, and both MSDCs may be underneath a parent MSDC.
>
This is true only and only if domain are direct neighbours. I'm pretty sure that operators will not agree to establish ACTN peering with an another operator with whom he has no direct peering.
>
> 1.
>  2. The issue of multi-operator control or resources has been a significant challenge for a long, long time (who recalls Orchestream?). It may be that one day we arrive at a solution where two operators are willing to use software for dynamic control of each other’s network, but until then we are likely to rely on a “protocol” that involves emails, purchase orders, and phone calls. From a **functional** point of view this is no different from the architecture pictures that drawn today, but you might consider that a parent MSDC is functionally split between the two operators with decisions heavily influenced by policy, and with the component actually implemented in human resources.
>
I remember Orchestream and even older one. But just look at what TMF and MEF are standardizing: They both adopt the distributed mechanism (or speaking with old terminology 'cascading model') not the centralized view (a.k.a. the 'hub model').

If many inter-domain attempts will not success, it is not from a technical problems, but more because operational constraints between operators impose policy rules that prevent many possibilities e.g. end-to-end tunnel established with RSVP-TE is not possible because operational entities would not deploy RSVP-TE between BGP router mostly for security reasons. So, IMHO, if the draft will not take into account a distributed scenario to setup end-to-end path,this is the best way to ensure that the draft will not be used.

Regards

Olivier

PS. Sorry for the numbering of your points in your original mail that has been crunched by my mailer
>
> 1.
>
>  
>
> Best,
>
> Adrian
>
> --
>
> Fairy tales from North Wales brought to you for Christmas
>
> https://www.feedaread.com/profiles/8604/
>
> Available from your favourite online bookseller.
>
> Or contact me to receive a signed copy by mail.
>
>  
>
> *From:*Teas <[email-masked]> *On Behalf Of *Belotti, Sergio (Nokia - IT/Vimercate)
> *Sent:* 11 December 2018 17:34
> *To:* Olivier Dugeon <[email-masked]>; [email-masked]; [email-masked]
> *Cc:* Igor Bryskin <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; [email-masked]; [email-masked]; Italo Busi <[email-masked]>
> *Subject:* Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt
>
>  
>
> Hi Olivier,
>
> Thanks for your reply.
>
> The issue you’re putting on the table is more an architectural problem than specific for path computation.
>
> You’re right that in multi-operator context you cannot be sure to have an “orchestrator” top entity able to make collection of information with respect different operator.
>
> So a first question would be, independently of path computation, if we , in TEAS, are planning to address also multi-operator scenario. Considering ACTN architecture , there are no definition of “horizontal” interface between domain controllers but it is always implied to have an higher controller (MDSC) to coordinate relationship among different domain controllers (e.g.PNC).
>
> On the other hand, as correctly pointed out by Igor, the flat approach is not so similar to the hierarchical approach since it is sequential in nature while with hierarchical steps can be provided in parallel, avoiding the burden to wait the completeness of the previous VSPT step before starting the new “per-domain” path computation.
>
> Following the suggested approach from Igor we have drawn some slides to explain how , even with hierarchical architecture we could  obtain what you have  in mind e.g. for multi-domain in multi-operator environment.
>
> The basic point is nothing prevent , in ACTN architecture, to collapse in a domain controller also higher controller functionality, and the PNC aggregating the 2 functionality of domain and higher controller, can be triggered by a PCC of its own domain of by client application and then can instruct simultaneously the other domain controller to ask for “per domain path computation” and then , one obtained computed path from different PNCs, it can act a “higher controller” and based on abstracted topology obtained as Igor suggested, can select e2e paths.
>
> Do you think this approach can address your request, without changing architecture ?
>
>  
>
> Thanks
>
> Regards
>
>  
>
> Italo, Young, Sergio
>
>  
>
>  
>
>  
>
> Sergio Belotti
>
> Senior System Engineer and Standardization Architect
>
> IP/Optical Networks, Optics BU
>
> Nokia
>
> M: +39-335761776
>
> Via Energy Park, 20871 Vimercate (MB) , Italy
>
> [email-masked] <mailto:[email-masked]>
>
>  
>
>  
>
>  
>
>  
>
> *From:*Olivier Dugeon <[email-masked] <mailto:[email-masked]>>
> *Sent:* Wednesday, November 28, 2018 5:16 PM
> *To:* Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; Italo Busi <[email-masked] <mailto:[email-masked]>>
> *Subject:* Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt
>
>  
>
> Hello Sergio,
>
> Apologize for the long delay.
>
> For me, "flat" approach, I prefer the wording 'distributed', versus 'hierarchical' approach are quite similar. They only differ by the fact that there is one parent asking to different child about the per-domain path computation, while in the others, the per-domain path computation is done on a per domain basis.
>
> In the case of distributed approach, there is two possibilities to trigger the end-to-end path computation:
>
>  - An external top controller e.g. NMS, Orchestrator
>
>  - A PCC
>
> In both cases, the request reach the local PCE i.e. the PCE of the domain where the top controller or PCC are connected to. In fact, as there is no central PCE i.e. the parent PCE, the first PCE which is solicited and that trigger the distributed path computation is the PCE of the source domain i.e. the domain where the IP source address of the end point object is located. Normally, once check that the source end point belongs to its domain, the PCE determine which is the next peer PCE that it must contact to start the BRPC process. Once the destination domain is reached, the last PCE i.e. in the destination domain, starts to compute its part of the end-to-end path and send back the ERO. As it could be compute several path, the return paths are named VSPT (Virtual Source Path Tree). The previous PCE when it received the ERO from the latest PCE start merging its own path computation with the received one and sends the result to its predecessor. At the end, the computed paths
> are received by the first PCE which merge them with its local path and select the best result.
>
> What it is not mention in RFC5441, is the way the AS path i.e. which AS, this which PCE will be involve in the end-to-end path computation. But, if I remember right, it is the same in RFC6805. PCE could simply follow the BGP path or perform some local policy or some computation to determine the next peer PCE. But, this is independent of the the yang model except if we would provide the AS path. The best way to do this is to encode in IRO the AS path. We do that in our implementation.
>
> So, from a yang model perspective, I think that what is missing in your model it is just an indication to precise if the end-to-end path is computed in a hierarchical or distributed way. Adding VSPT flag (like it is defined in RFC5441) could be a preliminary approach. And in a second time, is the possiblity to specify the AS path. IMHO, it is not too many entries to add in the current version of the model.
>
> As already mention in previous mail, it is important to address this scenario as the hierarchical scenario is not always possible in particular when the domains are controlled by different operators.
>
> Regards
>
> Olivier
>
>  
>
> Le 26/10/2018 à 18:29, Belotti, Sergio (Nokia - IT/Vimercate) a écrit :
>
>     Hi Olivier,
>
>     Thanks for your interest in the draft and for your question.
>
>     draft-ietf-teas-path-computation is providing a Yang model request to permit a client-controller to ask server-controller for path computation , in particularly when client has not complete knowledge of the domain topology for which he has to calculate path.
>
>     The typical case is multi-domain , and I would say RFC 5441 is approaching the problem to create a path in a multi-domain environment from a different angle with respect what our draft is doing.
>
>     RFC5441 is a "flat" scenario and controllers have peer to peer relationship.
>
>     Our case is a typical hierarchical scenario as mentioned in the introduction. We assume information exchange  is top-down and bottom-up no horizontal information is exchanged . I would say we are trying to solve multi domain issue in a scenario close to what RFC 6805 is doing for PCE prospective.
>
>     Anyway if you envisage SDN scenarios  in which YANG models are used for peer to peer communication among controllers we are interested to further investigate them and evaluate whether the existing models can be adapted to the scope.
>
>     One aspect we would like to better understand in these scenarios is how the end-to-end path computation is triggered and coordinated.
>
>     In the hierarchical scenario, the end-to-end path computation is triggered by some requests (e.g., LxSM) from the top-level controller which, from the abstract topology view it gets from the lower-level controllers, understands what are the ingress and egress points of the end-to-end path, compute the path in terms of which domains it has to cross (using path computation RPC when needed) and coordinate the end-to-end path setup (requesting each domain to setup its path segment).
>
>     In a flat scenario, it is not clear how the overall process is started: which is the controller that coordinates the end-to-end path setup and how the customer knows which controller is going to request the service (e.g., LxSM) to trigger the whole process?
>
>     If you'll be in Bangkok for IETF meeting we would be happy to discuss with you face to face.
>
>     Thanks
>
>      
>
>     Italo and Sergio
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: Teas <[email-masked]> <mailto:[email-masked]> On Behalf Of Olivier Dugeon
>
>     Sent: Wednesday, October 24, 2018 4:46 PM
>
>     To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>
>     Subject: Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt
>
>      
>
>     Dear authors,
>
>      
>
>     Regarding the different use cases expose in your draft, I'm wondering if you have take into account distributed path computation as per RFC5441 ? In particular, when several Network Controller are involved (figures 1, 4 and 5), you add  respectively a Packet/Optical Coordinator, a Multi-Domain Controller and a Cloud Network Orchestrator. However, when the different networks are own by different operators, or business unit within the same operator, it is not always feasible to add this centralized controller. In this case, TE information must be exchange directly between lower controller e.g. between TE Domain Controller, DC Controller and TE Network Controller, Packet and Optical Network Controller.
>
>      
>
>     So, I would understand if the yang model described in your draft allows such direct exchange or if it must be modified to take into such scenario ?
>
>      
>
>     Regards
>
>      
>
>     Olivier
>
>      
>
>     Le 22/10/2018 à 18:01, [email-masked] <mailto:[email-masked]> a écrit :
>
>         A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>         This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.
>
>          
>
>                 Title           : Yang model for requesting Path Computation
>
>                 Authors         : Italo Busi
>
>                                   Sergio Belotti
>
>                                   Victor Lopez
>
>                                   Oscar Gonzalez de Dios
>
>                                   Anurag Sharma
>
>                                   Yan Shi
>
>                                   Ricard Vilalta
>
>                                   Karthik Sethuraman
>
>                                   Michael Scharf
>
>                                   Daniele Ceccarelli
>
>            Filename        : draft-ietf-teas-yang-path-computation-03.txt
>
>            Pages           : 61
>
>            Date            : 2018-10-22
>
>          
>
>         Abstract:
>
>            There are scenarios, typically in a hierarchical SDN context, where
>
>            the topology information provided by a TE network provider may not
>
>            be sufficient for its client to perform end-to-end path computation.
>
>            In these cases the client would need to request the provider to
>
>            calculate some (partial) feasible paths.
>
>          
>
>            This document defines a YANG data model for a stateless RPC to
>
>            request path computation. This model complements the stateful
>
>            solution defined in [TE-TUNNEL].
>
>          
>
>            Moreover this document describes some use cases where a path
>
>            computation request, via YANG-based protocols (e.g., NETCONF or
>
>            RESTCONF), can be needed.
>
>          
>
>          
>
>         The IETF datatracker status page for this draft is:
>
>         https://datatracker.ietf.org/doc/draft-ietf-teas-yang-path-computation
>
>         /
>
>          
>
>         There are also htmlized versions available at:
>
>         https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-03
>
>         https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-comput
>
>         ation-03
>
>          
>
>         A diff from the previous version is available at:
>
>         https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-yang-path-computatio
>
>         n-03
>
>          
>
>          
>
>         Please note that it may take a couple of minutes from the time of
>
>         submission until the htmlized version and diff are available at tools.ietf.org.
>
>          
>
>         Internet-Drafts are also available by anonymous FTP at:
>
>         ftp://ftp.ietf.org/internet-drafts/
>
>          
>
>         _______________________________________________
>
>         Teas mailing list
>
>         [email-masked] <mailto:[email-masked]>
>
>         https://www.ietf.org/mailman/listinfo/teas
>
>          
>
>      
>
>      
>
>     _______________________________________________
>
>     Teas mailing list
>
>     [email-masked] <mailto:[email-masked]>
>
>     https://www.ietf.org/mailman/listinfo/teas
>
>  
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Thu, 14 Feb 2019 19:11:47 +0100

Hello Igor,

After spending some times to analyse your proposal, I'm not sure where is the simplication regarding BRPC. See below my comments

Regards

Olivier

Le 28/11/2018 à 19:32, Igor Bryskin a écrit :
>
> Hi Oliver,
>
>  
>
> The process you described seems quite lengthy and complex.  What exacerbates things further is the fact that the described distributed path computation is sequential in nature because each step of VSPT computation depends on the previous one.
>
I disagree with that. Each PCE computes its own VSPT based on source / destination and border node that connect the domain to its neighbours. It is the same as the point 2 in your proposal.Then, merge process is done backward once answer receives. But, each PCE is free to start the path computation once it received the request forward. It is not mention in the BRPC to wait the answer to start the computation. Only the merge process need the answer. Thus, it is no so 'sequential' as you mention. It is possible to anticipate the path computation, doing some parallel computation which start with a small delay i.e. this delay is equal to the propagation of the PCReq to the next PCE + the time to process this message.

> I’d like to have your opinion on the alternative approach:
>
>  
>
> 1)      The domains that could be involved in the eventual end-to-end path(s) (including all domains) are identified;
>
It is the same with BRPC. It not mention in the RFC5441 how the AS Path is determine. It is out of the scope of the RFC. Note that in hierarchical way, you need to also determine this AS Path and again, it is not mention in the RFC and draft how to do it. A simply mechanism is to follow BGP path. In our current implementation we perform a CSPF on the abstracted topology.
>
> 2)      T he PCEs of the domains are simultaneously instructed to compute or use pre-computed  abstract topologies in the form of stateful paths connecting:
>
> Source/destination node to all border nodes in case of source/destination domains;
>
> Each border node to every other  border node in case of transit domains;
>
It exactly what PCE do when they receive the PCReq message in the BRPC chain.
>
> 3)      Merge via inter-domain links the provided in 2) abstract topologies into a single topology homogenously describing the multi-domain network;
>
Same as standard BRPC, except that this is done backward hop by hop (I mean PCE by PCE). And because each PCE must prune or if you prefer keep only the best paths, the number of possible solutions will not explode. I'm not sure if it the case in your proposal.
>
> 4)      Use said merged topology to select one or more end-to-end paths connecting the path computation request source to destination;
>
This is done during the backward merge process in BRPC by keeping only the best solution. So, at the end, the first PCE (i.e. the initiator of the request) got the best solution. Thus, compared to BRPC your proposal add one more step as step 3) and 4) are done simultaneously in BRPC.
>
> 5)      Release the abstract topologies or preserve them (e.g. provided by transit domains) for future similar path computations
>
Again, this is a matter of choice of the PCE developer to keep previous path computation in cache in case of.
>
>  
>
> Note the parallelism of the approach and the ability to yield multiple paths, including diverse paths crossing different domain sequences, which would be very hard to achieve with the BRPC approach IMHO.
>
I don't see the difference here. With BRPC, you could achieved the same path computation with a similar complexity.

In our implementation (done in OpenDayLight / BGPCEP), the BRPC algorithm is less than 500 lines of java. And from a performance point of view, we could compute and end-to-end path in less than 500ms with 3 PCE, and less than 1s with 6 PCE. So, I don't think it is too much complicate and doesn't required heavy intensive computation.

>  
>
> Thanks,
>
> Igor
>
>  
>
> *From:*Teas [mailto:[email-masked]] *On Behalf Of *Olivier Dugeon
> *Sent:* Wednesday, November 28, 2018 11:16 AM
> *To:* Belotti, Sergio (Nokia - IT/Vimercate); [email-masked]; [email-masked]
> *Cc:* [email-masked]; Italo Busi

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 14 Feb 2019 20:37:07 +0000

Hi Oliver,

Thanks for your response. Please, see my comments in-line.

Igor

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 14, 2019 1:12 PM
To: Igor Bryskin; Belotti, Sergio (Nokia - IT/Vimercate); [email-masked]; [email-masked]
Cc: [email-masked]; Italo Busi
Subject: Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt

Hello Igor,

Regards

Olivier

I disagree with that. Each PCE computes its own VSPT based on source / destination and border node that connect the domain to its neighbours. It is the same as the point 2 in your proposal.

IB>> Unless a PCE has an access into a topology containing path computation source/destination node, the source/destination are of no relevance for the parallel path computations. To work in parallel the transit PCEs must only compute paths between border nodes of respective domains. Being oblivious of source/destination of e2e computations is also important for re-using intra-domain path computation results in multiple e2e path computations.

Then, merge process is done backward once answer receives. But, each PCE is free to start the path computation once it received the request forward. It is not mention in the BRPC to wait the answer to start the computation. Only the merge process need the answer. Thus, it is no so 'sequential' as you mention. It is possible to anticipate the path computation, doing some parallel computation which start with a small delay i.e. this delay is equal to the propagation of the PCReq to the next PCE + the time to process this message.

IB>> In my proposal there is no need for any coordination between PCEs - backward or forward, recursive or not, hop-by-hop, etc. The PCEs are completely oblivious of each other.  However the path/topology merging process does require topology/path re-calibration. If one topology has link TE metrics, for example, multiples of 10, while another – multiples of 1000, the path costs will be incomparable without cost normalization.
Also note that my proposal suggests computing and merging abstract topologies, rather than border-to-border intra-domain paths. This is different because:

1)     topology computation could be individually constrained by standard models. For example, certain resources could be prohibited from use for some topologies despite of availability of the underlying resources;

2)     Computed topologies could be stateful and be automatically and incrementally updated to reflect the topology changes, so that multiple e2e path computations over any time interval could be performed
Note that the merged topology could be exposed itself to the client via a standard model, so that the client could use its own path computation to select/optimize paths, which is not possible with the BRPC approach;

IB>> As mentioned above, my proposal requires nothing from the PCEs beyond simple path computations within a single topology. It also requires no coordination between the PCEs – each of them is to present an abstract topology interconnecting domain border nodes at its own pace. Therefore the method scales well and works equally well with three and with twenty PCEs/domains.
The client may choose to receive:

a)      computed multi-domain paths, or

b)     a topology to compute paths for itself.

Thanks,
Igor

From: Teas [mailto:[email-masked]] On Behalf Of Olivier Dugeon
Sent: Wednesday, November 28, 2018 11:16 AM
To: Belotti, Sergio (Nokia - IT/Vimercate); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Italo Busi
Subject: Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt

Hello Sergio,

 - A PCC

In both cases, the request reach the local PCE i.e. the PCE of the domain where the top controller or PCC are connected to. In fact, as there is no central PCE i.e. the parent PCE, the first PCE which is solicited and that trigger the distributed path computation is the PCE of the source domain i.e. the domain where the IP source address of the end point object is located. Normally, once check that the source end point belongs to its domain, the PCE determine which is the next peer PCE that it must contact to start the BRPC process. Once the destination domain is reached, the last PCE i.e. in the destination domain, starts to compute its part of the end-to-end path and send back the ERO. As it could be compute several path, the return paths are named VSPT (Virtual Source Path Tree). The previous PCE when it received the ERO from the latest PCE start merging its own path computation with the received one and sends the result to its predecessor. At the end, the computed paths are received by the first PCE which merge them with its local path and select the best result.

Regards

Olivier

Hi Olivier,

Thanks

Italo and Sergio

-----Original Message-----

From: Teas <[email-masked]><mailto:[email-masked]> On Behalf Of Olivier Dugeon

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Dear authors,

Regards

Olivier

Le 22/10/2018 à 18:01, [email-masked]<mailto:[email-masked]> a écrit :

        Authors         : Italo Busi

                          Sergio Belotti

                          Victor Lopez

                          Oscar Gonzalez de Dios

                          Anurag Sharma

                          Yan Shi

                          Ricard Vilalta

                          Karthik Sethuraman

                          Michael Scharf

                          Daniele Ceccarelli

     Pages           : 61

     Date            : 2018-10-22

Abstract:

/

ation-03

n-03

Teas mailing list

[email-masked]<mailto:[email-masked]>

Teas mailing list

[email-masked]<mailto:[email-masked]>

Thank you.