Re: [Teas] Manual Post Requested for draft-ietf-teas-yang-path-computation

"Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com> Sat, 02 November 2019 18:01 UTC

Return-Path: <sergio.belotti@nokia.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 E15111208CA for <teas@ietfa.amsl.com>; Sat, 2 Nov 2019 11:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 1iPLqiRugHxP for <teas@ietfa.amsl.com>; Sat, 2 Nov 2019 11:01:24 -0700 (PDT)
Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120124.outbound.protection.outlook.com [40.107.12.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECF81200F8 for <teas@ietf.org>; Sat, 2 Nov 2019 11:00:40 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z9wXh1kuecaFTV+KpiCBQ6q95n6ht29qzByrLFaS1ziSv8SE6GuH1BmyqOP6R1jZNDxbgwGNLKiIqVPKql4q42bOcUNnsfz1IKQ97rFonB/cCjYihebmsMy6vEjG05qgxlxPFKgTR3pQtfzu89oCYuAUyw3bbs6J+rGF/nBBWtP1KjdLxzPRglsgxZH954JAgRz9fRvtjZlWhz8U0a6tjCIQe5xS6vh0joMtXw4nJ1hXFy3NO6BoNBuL1n42Qd7tJbWvMZ4YDX923skLnWIbTTkO7+7nzALBGFrjbEe4kExdZA10eGRa6qLXvktj5SEPD6b676462Ao6kwru44siTQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=csXMHF6X+VY0/qzbhsNByCgR0n48nMgQP8sR3YB0Fg8=; b=cd3VlieorVxf1GY3ZaLoa3rT/v2AfaQSOL7opTD745z39CiFXsohGOfIqdKFFsDq6Gky5iWCrzycAM+W2LpKv5wwooZvWtN0jha2ThWyzmF8KcsSs41Mc8eWzOjd9zlFv9YTqYuzV4pF5Bh7DJsQDGKI8zcqNSoRNW60/2WGwe3e8EWzencvrt04IEd6ul/8h8PWJKaYUGQ55HLRnNLRApK1kQVip8uUm8Ou0iC54lTpkmnv74uHI1XFhPS6Gz0cl5v/8RoqvK+159oGDPsDtJBSEVl30q/Omt7LE65QtY1lhVeaKqQ0Q25ialdS8AYfDFcXT/VY1NYeOyNNyPiBMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=csXMHF6X+VY0/qzbhsNByCgR0n48nMgQP8sR3YB0Fg8=; b=A1fHRvWw/Cr1i22yajPly+F5aoYzPmHx6D1UnI8LDl4gn5mfgZdLMDT/qfWGYjDuSlJMsVx8Dbg4LfeHktMSA1ZrIrezRjKiuZj3wUTwgGsrg572OZUIsaTbOJeduy10ORlK39MihP4I94IqRbCnbSWu8WZILSXQrXYtkaATUts=
Received: from PR1PR07MB5001.eurprd07.prod.outlook.com (20.177.208.215) by PR1PR07MB5052.eurprd07.prod.outlook.com (20.177.210.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.10; Sat, 2 Nov 2019 18:00:37 +0000
Received: from PR1PR07MB5001.eurprd07.prod.outlook.com ([fe80::4c2:4b66:a87:8718]) by PR1PR07MB5001.eurprd07.prod.outlook.com ([fe80::4c2:4b66:a87:8718%3]) with mapi id 15.20.2430.014; Sat, 2 Nov 2019 18:00:37 +0000
From: "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>
To: "teas@ietf.org" <teas@ietf.org>
CC: Italo Busi <Italo.Busi@huawei.com>, "Belotti, Sergio (Nokia - IT/Vimercate)" <sergio.belotti@nokia.com>
Thread-Topic: Manual Post Requested for draft-ietf-teas-yang-path-computation
Thread-Index: AQHVj+37ElTSyfvveUO3qSE47bAS8qd0wezAgAMi4oA=
Date: Sat, 2 Nov 2019 18:00:37 +0000
Message-ID: <PR1PR07MB5001A13DD6C5120D457889FE917D0@PR1PR07MB5001.eurprd07.prod.outlook.com>
References: <157252803341.30404.3987863688938121654.idtracker@ietfa.amsl.com> <PR1PR07MB50019D63FBB549DE4C0AD6EA91630@PR1PR07MB5001.eurprd07.prod.outlook.com>
In-Reply-To: <PR1PR07MB50019D63FBB549DE4C0AD6EA91630@PR1PR07MB5001.eurprd07.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sergio.belotti@nokia.com;
x-originating-ip: [87.15.142.146]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b5bdbb43-3e35-4cfe-1669-08d75fbe90b9
x-ms-traffictypediagnostic: PR1PR07MB5052:
x-ms-exchange-purlcount: 6
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <PR1PR07MB5052200931ED51CADED2E594917D0@PR1PR07MB5052.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0209425D0A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(396003)(346002)(39860400002)(189003)(199004)(53754006)(13464003)(6506007)(4326008)(305945005)(2501003)(66946007)(229853002)(74316002)(76176011)(26005)(54906003)(6246003)(25786009)(52536014)(561944003)(71190400001)(186003)(71200400001)(1730700003)(256004)(966005)(81156014)(8676002)(81166006)(9686003)(446003)(14444005)(107886003)(316002)(11346002)(66066001)(6916009)(14454004)(486006)(7696005)(4001150100001)(5660300002)(33656002)(53546011)(99286004)(476003)(7736002)(478600001)(8936002)(102836004)(66476007)(66556008)(3846002)(6116002)(64756008)(5640700003)(76116006)(66446008)(30864003)(2351001)(86362001)(6306002)(2906002)(55016002)(66574012)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:PR1PR07MB5052; H:PR1PR07MB5001.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: e97MqKgN4L1m/ecsImwOhGwBkYZAXQh57TzXB7JJ2J9uX7jSqgKk2977g2DN3WeOMfNKoB+SkwQyA7qzYFXBbO1tt+AAl2/E4bo3RpmWxp9Xgtu/FfdinryqXJH4zdyXNvZyEtmJtisZ5baqj+fIr80Ujpok6Ms0ilFBfSzRKxPqR8ydebjLOvEKyF5gKrF5kXns8Wfnj+f/7G7NOalS8cKLPOvG/sxPwkn5Q0mt92D/6MalnUlA4OuK1zgkhzNfZI94AU1dP3N5nYnqbCREhRMbbOgfGZ1ApZICy07WBpmvdUUf8gwxdu1GzQhn5bxN5g2Lp6n/r2e3xkymu6cbwMeFvZqxgAvtyKhkwqvkyM+Dg5PPFQcFY32IKj+wCaLomk7BUB6mjP+9StdOO2Nn1tFs5T7h3PIjPxxHbN0BsfsBAoY9yV0pab1C+gpDR117KAUCi6aSfpJCvUqF0i77LxdmkZbLpo6KgWNkX8zqDRs=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b5bdbb43-3e35-4cfe-1669-08d75fbe90b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2019 18:00:37.1049 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FhbS7AZ+SrQ9cyPPZXvnkeji5nRh5L8LQIrYzPqSU3WVF4ql8+uuhwkQV3h3ROu7GtmnM+59xtYdsk1phyxkaAHYaRLWIEeZseL3EUc76JA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR1PR07MB5052
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/62UH71sXrzzAEV6oJooPlY8tjhc>
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 18:01:28 -0000

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>om>; Oscar González de Dios <oscar.gonzalezdedios@telefonica.com>om>; Michael Scharf <michael.scharf@gmail.com>om>; teas-chairs@ietf.org; Yan Shi <shiyan49@chinaunicom.cn>cn>; Ricard Vilalta <ricard.vilalta@cttc.es>es>; Belotti, Sergio (Nokia - IT/Vimercate) <sergio.belotti@nokia.com>om>; Victor Lopez <victor.lopezalvarez@telefonica.com>om>; Italo Busi <italo.busi@huawei.com>om>; Anurag Sharma <ansha@google.com>om>; 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.