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

From: Jorge E. López de Vergara Méndez <[email-masked]>
Date: Mon, 6 Mar 2017 16:18:44 +0100

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: 	[email-masked]
Para: 	Oscar de Dios <[email-masked]>, Oscar 
Gonzalez de Dios <[email-masked]>, Gabriele 
Galimberti <[email-masked]>, Jorge E. Lopez de Vergara 
<[email-masked]>, Universidad de Madrid 
<[email-masked]>, Daniel King <[email-masked]>, 
Daniel Perdices <[email-masked]>, Young Lee 
<[email-masked]>, Victor Lopezalvarez 
<[email-masked]>, Victor Lopez 
<[email-masked]>

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
Status:         https://datatracker.ietf.org/doc/draft-vergara-ccamp-flexigrid-yang/
Htmlized:       https://tools.ietf.org/html/draft-vergara-ccamp-flexigrid-yang-04
Diff:           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 tools.ietf.org.

The IETF Secretariat

---

From: Dieter Beller <[email-masked]>
Date: Tue, 7 Mar 2017 16:51:49 +0100

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 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 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:

[email-masked]

Para:

Oscar de Dios <[email-masked]>,
Oscar Gonzalez de Dios <[email-masked]>,
Gabriele Galimberti <[email-masked]>,
Jorge E. Lopez de Vergara <[email-masked]>,
Universidad de Madrid <[email-masked]>,
Daniel King <[email-masked]>,
Daniel Perdices <[email-masked]>,
Young Lee <[email-masked]>,
Victor Lopezalvarez <[email-masked]>,
Victor Lopez <[email-masked]>

Abstract:

The IETF Secretariat

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Zhenghaomian <[email-masked]>
Date: Mon, 20 Mar 2017 01:37:34 +0000

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:[email-masked]] 代表 Dieter Beller
发送时间: 2017年3月7日 23:52
收件人: Jorge E. López de Vergara Méndez; [email-masked]
主题: 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 ITU-T Recommendation G.698.2<http://www.itu.int/itu-t/recommendations/rec.aspx?rec=10396> 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 OpenConfig terminal-device YANG model<https://github.com/openconfig/public/tree/master/release/models/optical-transport> defines a single
operational-mode attribute for the optical-channel as defined below:

    leaf operational-mode {
      type uint16;
      description

   +--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.
________________________________

flexi-grid-transponder

      +--rw config

      |  +--rw FEC-type?               FEC

      +--ro state

         +--ro available-FEC*          FEC

         +--ro FEC-type?               FEC

      +--rw config

      |  +--rw FEC-type?               FEC

      +--ro state

         +--ro available-FEC*          FEC

         +--ro FEC-type?               FEC

            +--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:

  *   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.

    Best regards,

    -Jorge

-------- Mensaje reenviado --------
Asunto:

New Version Notification for draft-vergara-ccamp-flexigrid-yang-04.txt

Fecha:

De:

[email-masked]<mailto:[email-masked]>

Para:

Oscar de Dios <[email-masked]><mailto:[email-masked]>, Oscar Gonzalez de Dios <[email-masked]><mailto:[email-masked]>, Gabriele Galimberti <[email-masked]><mailto:[email-masked]>, Jorge E. Lopez de Vergara <[email-masked]><mailto:[email-masked]>, Universidad de Madrid <[email-masked]><mailto:[email-masked]>, Daniel King <[email-masked]><mailto:[email-masked]>, Daniel Perdices <[email-masked]><mailto:[email-masked]>, Young Lee <[email-masked]><mailto:[email-masked]>, Victor Lopezalvarez <[email-masked]><mailto:[email-masked]>, Victor Lopez <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision: 04

Pages:           32

Abstract:

The IETF Secretariat

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Jorge E. López de Vergara Méndez" <[email-masked]>
Date: Tue, 21 Mar 2017 08:04:54 +0100

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 <[email-masked]> escribió:
> 
> discussion many times in the past). Please note that ITU-T Recommendation G.698.2 defines application codes and OpenConfig
> b.t.w. incomplete and does not guarantee interoperability). The OpenConfig terminal-device YANG model defines a single
> "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. 
> Reference types are taken from TE topology model, so transponder-ref becomes tunnel-tp-id. Also node-ref is te-node-id.
> Oscar de Dios <[email-masked]>, Oscar Gonzalez de Dios <[email-masked]>, Gabriele Galimberti <[email-masked]>, Jorge E. Lopez de Vergara <[email-masked]>, Universidad de Madrid <[email-masked]>, Daniel King <[email-masked]>, Daniel Perdices <[email-masked]>, Young Lee <[email-masked]>, Victor Lopezalvarez <[email-masked]>, Victor Lopez <[email-masked]>
>  
>

---

From: Dieter Beller <[email-masked]>
Date: Tue, 21 Mar 2017 10:03:08 +0100

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 <[email-masked]>
escribió:

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.

Best wishes,

Haomian

发件人: CCAMP [mailto:[email-masked]]
代表
Dieter Beller

发送时间: 2017年3月7日 23:52

收件人: Jorge E. López
de Vergara Méndez; [email-masked]

主题: 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 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 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?             ->

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.

flexi-grid-transponder

+--rw config

|  +--rw FEC-type?               FEC

+--ro state

+--ro available-FEC*          FEC

+--ro FEC-type?               FEC

+--rw config

|  +--rw FEC-type?               FEC

+--ro state

+--ro available-FEC*          FEC

+--ro FEC-type?               FEC

+--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.

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

Best regards,

-Jorge

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

Asunto:

New
Version Notification for

Fecha:

Mon, 06
Mar 2017 01:03:50 -0800

De:

[email-masked]

Para:

Oscar de
Dios <[email-masked]>, Oscar Gonzalez de Dios
<[email-masked]>, Gabriele Galimberti
<[email-masked]>, Jorge E. Lopez de Vergara
<[email-masked]>, Universidad de Madrid
<[email-masked]>, Daniel King
<[email-masked]>, Daniel Perdices
<[email-masked]>, Young Lee
<[email-masked]>, Victor Lopezalvarez
<[email-masked]>, Victor Lopez
<[email-masked]>

IETF repository.

Revision: 04

Pages:           32

Abstract:

The IETF Secretariat

CCAMP mailing list

[email-masked]