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

From: [email-masked]
Date: Mon, 22 Oct 2018 09:01:01 -0700

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-yang-path-computation-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/

---

From: Olivier Dugeon <[email-masked]>
Date: Wed, 24 Oct 2018 16:45:39 +0200

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 :
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: Igor Bryskin <[email-masked]>
Date: Wed, 24 Oct 2018 20:27:56 +0000

Hi Oliver,

I understand your concerns. They could be addressed  via TE Topology model family that could be used by controllers to exchange  real/abstract TE information.

Cheers,
Igor
From:Olivier Dugeon
To:[email-masked],[email-masked],[email-masked],
Date:2018-10-24 10:46:34
Subject:Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt

Dear authors,

Regards

Olivier

---

From: Olivier Dugeon <[email-masked]>
Date: Thu, 25 Oct 2018 09:57:35 +0200

Hi Igor,

Thanks for the tip. Can you add a small section in the draft to address this scenario ?

Regards

Olivier

Le 24/10/2018 à 22:27, Igor Bryskin a écrit :
> *From:*Olivier Dugeon
> *To:[email-masked],[email-masked],[email-masked],
> *Date:*2018-10-24 10:46:34
> *Subject:*Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt
>
> Dear authors,
>

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Fri, 26 Oct 2018 16:29:31 +0000

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,

Regards

Olivier

Le 22/10/2018 à 18:01, [email-masked] a écrit :
> 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.
>