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

Olivier Dugeon <olivier.dugeon@orange.com> Thu, 25 October 2018 07:57 UTC

Return-Path: <olivier.dugeon@orange.com>
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 C57CD130E18; Thu, 25 Oct 2018 00:57:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Vm2ih53wlKoG; Thu, 25 Oct 2018 00:57:51 -0700 (PDT)
Received: from p-mail-ext.rd.orange.com (p-mail-ext.rd.orange.com [161.106.1.9]) by ietfa.amsl.com (Postfix) with ESMTP id 38C9312D4F2; Thu, 25 Oct 2018 00:57:51 -0700 (PDT)
Received: from p-mail-ext.rd.orange.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 93B90561634; Thu, 25 Oct 2018 09:57:32 +0200 (CEST)
Received: from p-mail-int.rd.francetelecom.fr (p-mail-int.rd.francetelecom.fr [10.192.117.12]) by p-mail-ext.rd.orange.com (Postfix) with ESMTP id 8E0C95615FF; Thu, 25 Oct 2018 09:57:32 +0200 (CEST)
Received: from p-mail-int.rd.francetelecom.fr (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 440481812DF; Thu, 25 Oct 2018 09:57:34 +0200 (CEST)
Received: from FTRDCH01.rd.francetelecom.fr (ftrdch01.rd.francetelecom.fr [10.194.32.11]) by p-mail-int.rd.francetelecom.fr (Postfix) with ESMTP id 393BD18125C; Thu, 25 Oct 2018 09:57:34 +0200 (CEST)
Received: from [10.193.71.231] (10.193.71.231) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.408.0; Thu, 25 Oct 2018 09:57:33 +0200
To: Igor Bryskin <Igor.Bryskin@huawei.com>, "teas@ietf.org" <teas@ietf.org>, "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
References: <154022406162.6304.4708808854863399271@ietfa.amsl.com> <f810c738-ef38-fafe-3e90-1749b159fb9f@orange.com> <etPan.5bd0d60f.65ddab87.20db@localhost>
From: Olivier Dugeon <olivier.dugeon@orange.com>
Organization: Orange Labs
Message-ID: <4257991b-9233-128f-0bbc-ab7b1ce06c35@orange.com>
Date: Thu, 25 Oct 2018 09:57:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <etPan.5bd0d60f.65ddab87.20db@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Ic-HelitVchgnDELuW1p9EBJpR0>
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: Thu, 25 Oct 2018 07:57:57 -0000

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 :
> 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:*teas@ietf.org,internet-drafts@ietf.org,i-d-announce@ietf.org,
> *Date:*2018-10-24 10:46:34
> *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 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-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/
> >
> > _______________________________________________
> > Teas mailing list
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> >
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas