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

[Tarek Saad <[e-mail]>]

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)" <[e-mail] on behalf of [e-mail]> 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: [e-mail]; TEAS WG Chairs <[e-mail]>
    Cc: Italo Busi <[e-mail]>
    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 <[e-mail]> 
    Sent: Thursday, October 31, 2019 2:21 PM
    To: [e-mail]
    Cc: Daniele Ceccarelli <[e-mail]>; Oscar González de Dios <[e-mail]>; Michael Scharf <[e-mail]>; [e-mail]; Yan Shi <[e-mail]>; Ricard Vilalta <[e-mail]>; Belotti, Sergio (Nokia - IT/Vimercate) <[e-mail]>; Victor Lopez <[e-mail]>; Italo Busi <[e-mail]>; Anurag Sharma <[e-mail]>; Karthik Sethuraman <[e-mail]>
    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 <[e-mail]>
    
      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 <[e-mail]>
        Sergio Belotti <[e-mail]>
        Victor Lopez <[e-mail]>
        Oscar Gonzalez de Dios <[e-mail]>
        Anurag Sharma <[e-mail]>
        Yan Shi <[e-mail]>
        Ricard Vilalta <[e-mail]>
        Karthik Sethuraman <[e-mail]>
        Michael Scharf <[e-mail]>
        Daniele Ceccarelli <[e-mail]>
    
    
      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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/teas