Re: [Teas] Manual Post Requested for draft-ietf-teas-yang-path-computation
Tarek Saad <tsaad.net@gmail.com> Sat, 02 November 2019 19:34 UTC
Return-Path: <tsaad.net@gmail.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 00B5312006F for <teas@ietfa.amsl.com>; Sat, 2 Nov 2019 12:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Biis2qZYujIL for <teas@ietfa.amsl.com>; Sat, 2 Nov 2019 12:34:44 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC06412002E for <teas@ietf.org>; Sat, 2 Nov 2019 12:34:43 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id e6so11033662wrw.1 for <teas@ietf.org>; Sat, 02 Nov 2019 12:34:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=R9QIQI7ba1y3poWVgjd8vPDnyltOntXEfj0+PMHT9ak=; b=b5cv+9I916i6WFVK7fM8lkkJ5olMO1xGy2KfeJwTNuRT4Ys22hv0aQ9hdchIa8CWkA 7KK9OK74tVYRfXPMwqNKtMRPtlK+zZ5X2ETeG3CcR9wCxcpP13HBeKdyOZcChxDbew7+ OS2jHphwSu9PgO6dFhQQ89TvmlIGjnKGwua3NMV0dGXjj9dUZbiu+coj/mKqCv62VJrQ y9PvotyygukVCEwtsb9F64yQFq87bZaZPUsFdrXRdNhCZ3uw2d2W+qf9bB5z/cuCFprj UyaBSNeGODP8rx3riE9cC0c2NRGSdOd35ntNK6nxSSUTBWTynwQnGDclfmK0YazgpsGg dJaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=R9QIQI7ba1y3poWVgjd8vPDnyltOntXEfj0+PMHT9ak=; b=L/vQTWYUUFY2ttt4qF1zTnVV77EV7gyFY4ElFV1y0JL19GL1uS3h59cUdrvRnQM7Ej JCJCVw23lCZLdRtpWfGqzn1TMXHP8/cKyjegmZYdwPAskRQlpGXpf5MP36akWgtEFK2D QeYJzwh6KNHhCn/IUMUdw5erfslOyi1kYCYtKbf23enjSPGTGcv4yZEfqlm+4uVgu5wY F3JXEb4qrmpeF7FVfGRILrNHiqi8tVQNB791RoSotIA4B2YJC4C8nDjr38SPCIHDjVaY YbC+blV833og5weM+HOrrJUFNUOmgy+5giWTpziU5dchGtRoWm7Oq/SlJYYohKljx+mQ QfNw==
X-Gm-Message-State: APjAAAV3QDQm+kA6SPrCgjFX9fIMxlQhtqK+/Pct6SVJWxDJD0sqSK9H TYgzIjbwn+BB3RiD2hsR/IE=
X-Google-Smtp-Source: APXvYqzSxIUEtIDNSkDVl4kuGw8UKNBcdpLF6GEnRlkh8n7u4WimBW+l+lVUoGZKp3xEsdyYZ2/r0g==
X-Received: by 2002:adf:ed4e:: with SMTP id u14mr16892417wro.132.1572723282140; Sat, 02 Nov 2019 12:34:42 -0700 (PDT)
Received: from DM6PR19MB3689.namprd19.prod.outlook.com ([2603:1036:301:21db::5]) by smtp.gmail.com with ESMTPSA id k125sm3208462wmf.2.2019.11.02.12.34.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Nov 2019 12:34:41 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>, "teas@ietf.org" <teas@ietf.org>
CC: Italo Busi <Italo.Busi@huawei.com>
Thread-Topic: [Teas] Manual Post Requested for draft-ietf-teas-yang-path-computation
Thread-Index: AXIuOTkxuzzFvc59HZLiJjIXtGpmEzA2RDM1MDkwRDXDw3sLAw==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Sat, 02 Nov 2019 19:34:39 +0000
Message-ID: <DM6PR19MB3689ACAA9D3EE593F1BE41CDFC7D0@DM6PR19MB3689.namprd19.prod.outlook.com>
References: <157252803341.30404.3987863688938121654.idtracker@ietfa.amsl.com> <PR1PR07MB50019D63FBB549DE4C0AD6EA91630@PR1PR07MB5001.eurprd07.prod.outlook.com> <PR1PR07MB5001A13DD6C5120D457889FE917D0@PR1PR07MB5001.eurprd07.prod.outlook.com>
In-Reply-To: <PR1PR07MB5001A13DD6C5120D457889FE917D0@PR1PR07MB5001.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/M44pxwIQhqofes5GCV3_aJZBj_g>
Subject: Re: [Teas] Manual Post Requested for draft-ietf-teas-yang-path-computation
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: Sat, 02 Nov 2019 19:34:47 -0000
Hi Sergio, FYI, we have just posted a refresh for https://tools.ietf.org/html/draft-ietf-teas-yang-te-22 You may want to retry your submission. Regards, Tarek (on behalf of authors) On 11/2/19, 2:01 PM, "Teas on behalf of Belotti, Sergio (Nokia - IT/Vimercate)" <teas-bounces@ietf.org on behalf of sergio.belotti@nokia.com> wrote: Hi all, We have unfortunately a manual post issue that we cannot solve ourselves since compilation issue The compilation issue is caused by the expiration of: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21 as we reply to the mail received by IETF Secretariat. So here below you can find text and possible tree structure taken by updated draft . Thanks Italo/Sergio (on-behalf of co-authors/contributors) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 5.3. Path Associations Note - This section describes the models changes that are proposed and not yet defined in section 6. The YANG model allows including multiple path requests intended to be used within the same tunnel or within different tunnels. Multiple path requests that are intended to be used within the same tunnel needs to be associated, indicating also the role of the path being requested within the intended tunnel (e.g., primary or secondary path). The choice below is proposed to be added to the model to distinguish whether the requested path is intended to be associated with other requested paths within one tunnel, or not: +---- (tunnel-information)? | +----:(tunnel-association) | | ........... | +----:(tunnel-attributes) | | ........... The tunnel-attributes case will provide the set of attributes that are usually configured on per-tunnel basis rather than on per-path basis (e.g., tunnel-name, source/destination TTP, encoding and switching-type). The tunnel-association case provides the information needed to associate multiple path requests that are intended to be used within the same tunnel. For this purpose, it is proposed to define a tunnel-associations list: +---- tunnel-associations* [tunnel-association-id] | +---- tunnel-association-id? uint32 | +---- tunnel-name? string | ........... The path requests that are intended to be used within the same tunnel should reference the same tunnel-association-id. The tunnel-associations list allows also to configure the per-tunnel attributes common to all these path requests. This allow: o avoiding repeating the same set of per-tunnel parameters on all the requested path that are intended to belong to the same tunnel; o the server to understand what attributes (e.g., associations) are intended to be configured per-tunnel and what attributes (e.g., associations) are intended to be configured per-path, which could useful especially when the server also creates a te-tunnel instance within the operational DS to report the computed paths, as described in section 3.3.1. In order to indicate the role of the path being requested within the intended tunnel (e.g., primary or secondary path), the following choice is proposed to be added to the: +---- (path-role)? | +----:(candidate-primary-path) | | +---- candidate-primary-path empty | +----:(candidate-secondary-path) | | +---- candidate-secondary-path | | | ........... The candidate-secondary-path container references another requested path that is intended to be the primary path associated with this requested secondary path. The YANG model allows also including path requests intended to be used to modify existing tunnel (e.g., adding a protection path for an existing un-protected tunnel). In this case, the path request needs to be associated with existing path(s) within an existing tunnel. Moreover, also the per-tunnel attributes are already provided in the existing te-tunnel instance and do not need to be re-configured in the RPC. Therefore, the tunnel-association list will not be used, but the requested path(s) are proposed to be associated by referencing the existing te-tunnel: +----:(tunnel-association) | +---- (tunnel-exist)? | | +----:(tunnel-ref) | | | +---- tunnel-ref leafref | | +----:(tunnel-association-id) | | | +---- tunnel-association-id uint32 | ........... Open issue: need to evaluate whether this te-tunnel instance should be within the operational DS or within the intended DS, or maybe, on either one of the two DS Moreover, a requested secondary path can either be associated with another requested primary path or with an existing primary path, as described in the proposal below: +---- candidate-secondary-path | +---- (primary-path-exist)? | | +----:(primary-path-reference) | | | +---- primary-path-ref leafref | | +----:(primary-path-request) | | | +---- primary-path-request-id uint32 ........... Appendix B. New proposed YANG Tree overview This Appendix provides an overview of the YANG Tree that would results from the proposed changes described in section 5.3. module: ietf-te-path-computation augment /te:tunnels-rpc/te:input/te:tunnel-info: +---- path-request* [request-id] | +--- request-id uint32 | +---- (tunnel-information)? | | +----:(tunnel-association) | | | +---- (tunnel-exist)? | | | | +----:(tunnel-ref) | | | | | +---- tunnel-ref leafref | | | | +----:(tunnel-association-id) | | | | | +---- tunnel-association-id uint32 | | | +---- path-name? string | | | +---- (path-role)? | | | | +----:(candidate-primary-path) | | | | | +---- candidate-primary-path empty | | | | +----:(candidate-secondary-path) | | | | | +---- candidate-secondary-path | | | | | | +---- (primary-path-exist)? | | | | | | | +----:(primary-path-reference) | | | | | | | | +---- primary-path-ref leafref | | | | | | | +----:(primary-path-request) | | | | | | | | +---- primary-path-request-id uint32 | | +----:(tunnel-attributes) | | | +---- tunnel-name? string | | | | +---- (path-role)? | | | | +--:(primary) | | | | | +---- primary-path-name? string | | | | +--:(secondary) | | | | +---- secondary-path-name? string | | | +--- encoding? identityref | | | +--- switching-type? identityref | | | +--- source? inet:ip- address | | | +--- destination? inet:ip- address | | | +--- src-tp-id? binary | | | +--- dst-tp-id? binary | | | +--- bidirectional? boolean | | | +--- te-topology-identifier | | | | +--- provider-id? te-global-id | | | | +--- client-id? te-global-id | | | | +--- topology-id? te-topology-id | +---- explicit-route-objects-always | | ........... | +---- path-constraints | | +---- preference? uint8 | | ........... | +---- optimizations | | ........... | +---- path-in-segment! | | ........... | +---- path-out-segment! | | ........... | +---- requested-metrics* [metric-type] | | +---- metric-type identityref | +---- return-srlgs? boolean | +---- return-affinities? boolean | +---- requested-state! | +---- timer? uint16 | +---- transaction-id? string +---- tunnel-associations* [tunnel-association-id] | +---- tunnel-association-id? uint32 | +---- tunnel-name? string | +---- encoding? identityref | +---- switching-type? identityref | +---- source? inet:ip-address | +---- destination? inet:ip-address | +---- src-tp-id? binary | +---- dst-tp-id? binary | +---- bidirectional? boolean | +---- te-topology-identifier | | +---- provider-id? te-global-id | | +---- client-id? te-global-id | | +---- topology-id? te-topology-id | +---- preference? uint8 | +---- association-objects | | ........... | +---- protection-type? identityref | +---- restoration-type? identityref | +---- te-bandwidth | | ........... | +---- link-protection? identityref | +---- setup-priority? uint8 | +---- hold-priority? uint8 | +---- signaling-type? identityref +---- synchronization* [synchronization-id] ........... ........... -----Original Message----- From: Belotti, Sergio (Nokia - IT/Vimercate) Sent: Thursday, October 31, 2019 2:54 PM To: teas@ietf.org; TEAS WG Chairs <teas-chairs@ietf.org> Cc: Italo Busi <Italo.Busi@huawei.com> Subject: FW: Manual Post Requested for draft-ietf-teas-yang-path-computation Dear TEAS WG, We have just submitted an updated version of draft-ietf-teas-yang-path-computation. One of the issue we have tried to address is the support for requesting protected paths: https://github.com/rvilalta/ietf-te-path-computation/issues/49 We have taken into account feedback received in a previous IETF meeting (i.e., using two path requests with some association). Since the changes are quite substantive, we have not updated the YANG model yet but just described how we are planning/thinking the model should be updated in section 5.3 and provided some information about the expected tree changes in Appendix B. The proposed modification has also the benefit, in our view, to better highlight relationship between requested paths and related tunnel, and the mapping with specific attribute of the tunnel. We will present the proposal during Singapore meeting and would appreciate any initial feedbacks and comments at the meeting as well as on the list. Sergio (on-behalf of co-author/contributors) -----Original Message----- From: IETF I-D Submission Tool <idsubmission@ietf.org> Sent: Thursday, October 31, 2019 2:21 PM To: internet-drafts@ietf.org Cc: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>; Michael Scharf <michael.scharf@gmail.com>; teas-chairs@ietf.org; Yan Shi <shiyan49@chinaunicom.cn>; Ricard Vilalta <ricard.vilalta@cttc.es>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>; Victor Lopez <victor.lopezalvarez@telefonica.com>; Italo Busi <italo.busi@huawei.com>; Anurag Sharma <ansha@google.com>; Karthik Sethuraman <karthik.sethuraman@necam.com> Subject: Manual Post Requested for draft-ietf-teas-yang-path-computation Hi, Manual posting has been requested for the following Internet-Draft. Full idnits results are available at the end of this message. I-D Submission Tool URL: https://datatracker.ietf.org/submit/status/107455/ File name : draft-ietf-teas-yang-path-computation Revision : 07 Submission date : 2019-10-31 Group : Traffic Engineering Architecture and Signaling Title : Yang model for requesting Path Computation Document date : 2019-10-30 Pages : 78 File size : 149.9 KB Submitter : Italo Busi <italo.busi@huawei.com> 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. Authors: Italo Busi <italo.busi@huawei.com> Sergio Belotti <sergio.belotti@nokia.com> Victor Lopez <victor.lopezalvarez@telefonica.com> Oscar Gonzalez de Dios <oscar.gonzalezdedios@telefonica.com> Anurag Sharma <ansha@google.com> Yan Shi <shiyan49@chinaunicom.cn> Ricard Vilalta <ricard.vilalta@cttc.es> Karthik Sethuraman <karthik.sethuraman@necam.com> Michael Scharf <michael.scharf@gmail.com> Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Comment to the secretariat: Idnits result: idnits 2.16.02 /a/www/www6s/staging/draft-ietf-teas-yang-path-computation-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([TE-TUNNEL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1347 has weird spacing: '...tion-id uin...' == Line 1354 has weird spacing: '...ic-type ide...' == Line 1363 has weird spacing: '...-- name str...' == Line 1370 has weird spacing: '...ic-type ide...' == Line 1439 has weird spacing: '...o usage ide...' == (36 more instances...) Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7491 ** Downref: Normative reference to an Informational RFC: RFC 8453 ** Downref: Normative reference to an Informational RFC: RFC 8454 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 0 comments (--). Run idnits with the --verbose option for more detailed information about the items above. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas
- [Teas] FW: Manual Post Requested for draft-ietf-t… Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Teas] Manual Post Requested for draft-ietf-t… Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Teas] Manual Post Requested for draft-ietf-t… Tarek Saad