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

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 11 December 2018 18:01 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A66130EE0 for <teas@ietfa.amsl.com>; Tue, 11 Dec 2018 10:01:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6BRK49VX6Z3 for <teas@ietfa.amsl.com>; Tue, 11 Dec 2018 10:01:37 -0800 (PST)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4222C130EDF for <teas@ietf.org>; Tue, 11 Dec 2018 10:01:37 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id wBBI1Rcd005255; Tue, 11 Dec 2018 18:01:28 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 68F3422046; Tue, 11 Dec 2018 18:01:27 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 5272F22044; Tue, 11 Dec 2018 18:01:27 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.114.148.47]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id wBBI1Hfd013202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Dec 2018 18:01:17 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Belotti, Sergio \(Nokia - IT/Vimercate\)'" <sergio.belotti@nokia.com>, "'Olivier Dugeon'" <olivier.dugeon@orange.com>
Cc: "'Igor Bryskin'" <Igor.Bryskin@huawei.com>, <ylee@huawei.com>, <teas@ietf.org>, "'Italo Busi'" <Italo.Busi@huawei.com>
References: <154022406162.6304.4708808854863399271@ietfa.amsl.com> <f810c738-ef38-fafe-3e90-1749b159fb9f@orange.com> <DB6PR0701MB27277506AD5E479F721DD17E91F00@DB6PR0701MB2727.eurprd07.prod.outlook.com> <939c6a39-d6a6-d6e8-93cf-c59222dc2728@orange.com> <AM0PR07MB5921D8A13FDA5E7AAB3F355B91A60@AM0PR07MB5921.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB5921D8A13FDA5E7AAB3F355B91A60@AM0PR07MB5921.eurprd07.prod.outlook.com>
Date: Tue, 11 Dec 2018 18:01:17 -0000
Organization: Old Dog Consulting
Message-ID: <02c201d4917b$841c0220$8c540660$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C3_01D4917B.8420BD10"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGsWxUHH+3V1T4Wr53wt0oTLEmFyQKq3jhZAqt83XUA5fI3pQFw26UKpYzUpDA=
Content-Language: en-gb
X-Originating-IP: 87.114.148.47
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24280.001
X-TM-AS-Result: No--29.984-10.0-31-10
X-imss-scan-details: No--29.984-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24280.001
X-TMASE-Result: 10--29.983600-10.000000
X-TMASE-MatchedRID: yebcs53SkkDxIbpQ8BhdbGA/V00XWjDtOUgDgpLqlbdaW2Ktn+I8/g1W ta/onYSHZx63mNPO8Gmu7ANNh78ovJehWb8K3L/NlGudLLtRO1sF15s6prCIuyJ8zskw0dbrnmm Rpf1EKur6/4xOBWRh0FpHkXU+sMtGWSate9FdO+BoMLOoNHsM9hkcO8L67kh/IFBEE5CFomKEY2 +qvfbJSRWsQf7KRd5jUF0ntXDKP2s2DwEvDh8ot9jGRkLinPFI9pLnYtQ99xI8guXXRtiXIDwlp IAvEVtWvqsR+q7PVnBm1pRPUGBkcoEMZLAgXsFvAP2Bflpd3h/JmceGHYIlwVVsUKXEEA3GQcKq 2vPsGZxV3dkWNiydkt77p4k0g263eICFp23MlY1HQFjzAbvJEN9InWSoxyrB9YBezwhBfW4h+X1 pRTZqT+8x8efkibs5oZMLNbeEGTcvRbVu13x7njPDkSOzeDWWcBvG+bJI5KBBTdeoy0R9D6h9Lm FxjhKcM08/wHcspcFLy+D9PuEGD51K+QcNb9syTQh9A4m9EtGpDNSxck0u4RKAWnKBwBf/woCoN +eZDjacAKaqQ6jBJWf7K3IVw3MEfPmUQQG69pzHt9VUPuskRu8lj2kHOCDUbcPp/oilssgLwMMj FaCpKhp1xRGlR2oRtHT+fvhz5tMV3uC0FK9+rxD3+0w1DhqKBGvINcfHqhdCannV/b7f2ez87ob UpzSDMSeq2sKeo9ZqqC5Q73GIBRE8uHp1Y4G8ZlRzaO1xpJ3Sde/CNbaZJdiwHF9v2E/xfGYL8J 6c6A2rMat91aU1TLk/KAmD8ynmwwTYGyiIokyeAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg6XlY8h5Lp1jeU5Cv0L/BJZ4fuwx9y9acYuq7Wpf8Z5Gr0uZZ1Iuw6E=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-abohI_WDkKdc6JoyeK04wM2b4Q>
Subject: Re: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-03.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2018 18:01:42 -0000

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

 

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 <teas-bounces@ietf.org>; On Behalf Of Belotti, Sergio (Nokia - IT/Vimercate)
Sent: 11 December 2018 17:34
To: Olivier Dugeon <olivier.dugeon@orange.com>;; internet-drafts@ietf.org; i-d-announce@ietf.org
Cc: Igor Bryskin <Igor.Bryskin@huawei.com>;; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>;; ylee@huawei.com; teas@ietf.org; Italo Busi <Italo.Busi@huawei.com>;
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

 <mailto:sergio.belotti@nokia.com> sergio.belotti@nokia.com

 

 

 

 

From: Olivier Dugeon <olivier.dugeon@orange.com <mailto:olivier.dugeon@orange.com> > 
Sent: Wednesday, November 28, 2018 5:16 PM
To: Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com <mailto:sergio.belotti@nokia.com> >; internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> ; i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> 
Cc: teas@ietf.org <mailto:teas@ietf.org> ; Italo Busi <Italo.Busi@huawei.com <mailto:Italo.Busi@huawei.com> >
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  <mailto:teas-bounces@ietf.org> <teas-bounces@ietf.org>; On Behalf Of Olivier Dugeon
Sent: Wednesday, October 24, 2018 4:46 PM
To: teas@ietf.org <mailto:teas@ietf.org> ; internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> ; i-d-announce@ietf.org <mailto:i-d-announce@ietf.org> 
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, internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>  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
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas
 

 
 
_______________________________________________
Teas mailing list
Teas@ietf.org <mailto:Teas@ietf.org> 
https://www.ietf.org/mailman/listinfo/teas