Re: [CCAMP] 答复: Fwd: New Version Notification for draft-vergara-ccamp-flexigrid-yang-04.txt

[Dieter Beller <[e-mail]>]

Hi Jorge, Haomian, all

I concur with the comment that augmenting the TE tunnel model should be considered for L0 services/connections as opposed to define a new
model.


Thanks,
Dieter

On 21.03.2017 08:04, "Jorge E. López de Vergara Méndez" wrote:

   Hi,

   Thank you for your comments. We are considering them for next version of the draft.

   Best regards,

   -Jorge

El 20 mar 2017, a las 2:37, Zhenghaomian <[e-mail]> escribió:

Hi, Jorge, Dieter and All,

 

I shared the same comment with Dieter, ccamp draft should focus on control plane, and it would be appreciated if YANG draft is consistent with existing GMPLS extension drafts for flexi-grid (RFC 7698, 7699, etc.).

 

I would like to raise another comment, about the augmentation relationship. It is noted that a separate module has been defined for the so-called media channel, which is assumed to be flexi-grid tunnel if I understand correctly. By reading the YANG model, my intuitive idea is that this module can be obtained by augmenting to TE tunnel model, rather than a purely new one. It would be easier for the tunnel representation, and get better connection with the current YANG models in IETF.

 

Any ideas on this? Thank you very much.

 

Best wishes,

Haomian

 

发件人: CCAMP [mailto:[e-mail]] 代表 Dieter Beller
发送时间: 2017年3月7日 23:52
收件人: Jorge E. López de Vergara Méndez; [e-mail]
主题: Re: [CCAMP] Fwd: New Version Notification for draft-vergara-ccamp-flexigrid-yang-04.txt

 

Hi Jorge, all,

I read the 04-revision of the draft and I have some major concerns regarding the modeling of optical transponders: the draft
defines models for the following two transponder types: flexi-grid-transponder and flexi-grid-sliceable-transponder.

By doing so, the draft tries to define a data plane standard, which is clearly outside the scope of CCAMP (we had this kind of
discussion many times in the past). Please note that http://www.itu.int/itu-t/recommendations/rec.aspx?rec=10396" rel="nofollow">ITU-T Recommendation G.698.2 defines application codes and OpenConfig
is following a similar approach as opposed to define an exhaustive list of transponder attributes (the attribute list in the draft is
b.t.w. incomplete and does not guarantee interoperability). The https://github.com/openconfig/public/tree/master/release/models/optical-transport" rel="nofollow">OpenConfig terminal-device YANG model defines a single
operational-mode attribute for the optical-channel as defined below:

    leaf operational-mode {
      type uint16;
      description
        "Vendor-specific mode identifier -- sets the operational
        mode for the channel.  The specified operational mode must
        exist in the list of supported operational modes supplied
        by the device";
    }



   +--rw optical-channel
      +--rw config
      |  +--rw frequency?             oc-opt-types:frequency-type
      |  +--rw target-output-power?   decimal64
      |  +--rw operational-mode?      uint16
      |  +--rw line-port?             -> /oc-platform:components/component/name


This is similar to the application code approach. Two transponders are considered  interoperable if they have at least one
operational-mode in common. I strongly suggest that we follow a similar approach in CCAMP.

---

Excerpts from draft-vergara-ccamp-flexigrid-yang-04.txt:

flexi-grid-transponder

   augment /nd:networks/nd:network/nd:node/tet:te/

   tet:tunnel-termination-point:

      +--rw transponder-type           flexi-grid-transponder-type

      +--rw config

      |  +--rw available-modulation*   modulation

      |  +--rw modulation-type?        modulation

      |  +--rw available-FEC*          FEC

      |  +--rw FEC-enabled?            boolean

      |  +--rw FEC-type?               FEC

      +--ro state

         +--ro available-modulation*   modulation

         +--ro modulation-type?        modulation

         +--ro available-FEC*          FEC

         +--ro FEC-enabled?            boolean

         +--ro FEC-type?               FEC

 

flexi-grid-sliceable-transponder

   augment /nd:networks/nd:network/nd:node/tet:te/

   tet:tunnel-termination-point:

      +--rw transponder-type           flexi-grid-transponder-type

      +--rw config

      |  +--rw available-modulation*   modulation

      |  +--rw modulation-type?        modulation

      |  +--rw available-FEC*          FEC

      |  +--rw FEC-enabled?            boolean

      |  +--rw FEC-type?               FEC

      |  +--rw transponder-list* [carrier-id]

      |     +--rw carrier-id           uint32

      +--ro state

         +--ro available-modulation*   modulation

         +--ro modulation-type?        modulation

         +--ro available-FEC*          FEC

         +--ro FEC-enabled?            boolean

         +--ro FEC-type?               FEC

         +--ro transponder-list* [carrier-id]

            +--ro carrier-id           uint32

Thanks,
Dieter

On 06.03.2017 16:18, Jorge E. López de Vergara Méndez wrote:

    Dear all,

    Please find below a new draft of the Flexigrid YANG model. In this new version some changes have been made, according to previous received feedback:

• Now both models are updated to YANG 1.1.

• State containers in the tree structure are now read-only.

• "Transponder" does not augment "node" anymore. Flexi-grid-node is the only structure playing this role in the model. Therefore, node-type was eliminated.

• "Transponder" augments "tunnel-termination-point". Since this structure does not have state or config subdivision, we have added config and state containers. Transponder-type is included to indicate whether it is a transponder or a sliceable transponder. 

• Few corrections to be coherent with TE topology model.

• Reference types are taken from TE topology model, so transponder-ref becomes tunnel-tp-id. Also node-ref is te-node-id.

• Minor corrections in some descriptions.

• Updated references and authors.

    If you have any comment, please do not hesitate to send them to me.

    Best regards,

    -Jorge

-------- Mensaje reenviado --------

Asunto:	New Version Notification for draft-vergara-ccamp-flexigrid-yang-04.txt
Fecha:	Mon, 06 Mar 2017 01:03:50 -0800
De:	[e-mail]
Para:	Oscar de Dios <[e-mail]>, Oscar Gonzalez de Dios <[e-mail]>, Gabriele Galimberti <[e-mail]>, Jorge E. Lopez de Vergara <[e-mail]>, Universidad de Madrid <[e-mail]>, Daniel King <[e-mail]>, Daniel Perdices <[e-mail]>, Young Lee <[e-mail]>, Victor Lopezalvarez <[e-mail]>, Victor Lopez <[e-mail]>

 

A new version of I-D, draft-vergara-ccamp-flexigrid-yang-04.txt

has been successfully submitted by Jorge E. Lopez de Vergara and posted to the

IETF repository.

Name:            draft-vergara-ccamp-flexigrid-yang

Revision: 04

Title:           YANG data model for Flexi-Grid Optical Networks

Document date:   2017-03-06

Group:           Individual Submission

Pages:           32

URL:            https://www.ietf.org/internet-drafts/draft-vergara-ccamp-flexigrid-yang-04.txt" rel="nofollow">https://www.ietf.org/internet-drafts/draft-vergara-ccamp-flexigrid-yang-04.txt

Status:         https://datatracker.ietf.org/doc/draft-vergara-ccamp-flexigrid-yang/" rel="nofollow">https://datatracker.ietf.org/doc/draft-vergara-ccamp-flexigrid-yang/

Htmlized:       https://tools.ietf.org/html/draft-vergara-ccamp-flexigrid-yang-04" rel="nofollow">https://tools.ietf.org/html/draft-vergara-ccamp-flexigrid-yang-04

Diff:           https://www.ietf.org/rfcdiff?url2=draft-vergara-ccamp-flexigrid-yang-04" rel="nofollow">https://www.ietf.org/rfcdiff?url2=draft-vergara-ccamp-flexigrid-yang-04

Abstract:

   This document defines a YANG model for managing flexi-grid optical

   Networks. The model described in this document is composed of two

   submodels: one to define a flexi-grid traffic engineering database,

   and other one to describe the flexi-grid paths or media channels.

   It is grounded on other defined YANG abstract models.

Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at http://tools.ietf.org" rel="nofollow">tools.ietf.org.

The IETF Secretariat

_______________________________________________

CCAMP mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp