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

From: Olivier Dugeon <[email-masked]>
Date: Wed, 28 Nov 2018 17:16:12 +0100

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 theper-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-endpath computation:

 - Anexternal 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 somelocal 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 yangmodel 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 thehierarchical 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]> On Behalf Of Olivier Dugeon
> Sent: Wednesday, October 24, 2018 4:46 PM
> To: [email-masked]; [email-masked]; [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] 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]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 28 Nov 2018 18:32:04 +0000

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

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;

3)      Merge via inter-domain links the provided in 2) abstract topologies into a single topology homogenously describing the multi-domain network;

4)      Use said merged topology to select one or more end-to-end paths connecting the path computation request source to destination;

5)      Release the abstract topologies or preserve them (e.g. provided by transit domains) for future similar path computations

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.

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
Subject: Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt

Hello Sergio,

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

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