Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-otn-topo-yang-03.txt

From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Date: Fri, 15 Jun 2018 10:36:51 +0000

Dear WG, 

This is an update to OTN topology after 8 month, as we are waiting for the maturity of basic TE topology model. Now the model is updated to be aligned with TE one. You are welcome to review and provide your comments. 

There are still some YANG errors because of the incorrect reference to OTN tunnel model and OTN types, which have not been updated yet. The other OTN tunnel model draft is under our processing and will be announced in the next week. All the OTN models can be found at the github: https://github.com/haomianzheng/IETF-ACTN-YANG-Model/tree/master/YANG/ccamp, and you are welcome to comments. 

Thank you. 

Best wishes,
Haomian

-----邮件原件-----
发件人: CCAMP [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2018年6月15日 17:14
收件人: [email-masked]
抄送: [email-masked]
主题: [CCAMP] I-D Action: draft-ietf-ccamp-otn-topo-yang-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane WG of the IETF.

        Title           : A YANG Data Model for Optical Transport Network Topology
        Authors         : Haomian Zheng
                          Aihua Guo
                          Italo Busi
                          Anurag Sharma
                          Xufeng Liu
                          Sergio Belotti
                          Yunbin Xu
                          Lei Wang
                          Oscar Gonzalez de Dios
	Filename        : draft-ietf-ccamp-otn-topo-yang-03.txt
	Pages           : 58
	Date            : 2018-06-15

Abstract:
   A transport network is a server-layer network designed to provide
   connectivity services for a client-layer network to carry the client
   traffic transparently across the server-layer network resources.  A
   transport network can be constructed from equipments utilizing any of
   a number of different transport technologies such as the evolving
   Optical Transport Networks (OTN) or packet transport as provided by
   the MPLS-Transport Profile (MPLS-TP).

   This document describes a YANG data model to describe the topologies
   of an Optical Transport Network (OTN).  It is independent of control
   plane protocols and captures topological and resource related
   information pertaining to OTN.  This model enables clients, which
   interact with a transport domain controller via a REST interface, for
   OTN topology related operations such as obtaining the relevant
   topology resource information.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ccamp-otn-topo-yang-03
https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-otn-topo-yang-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-otn-topo-yang-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: "t.petch" <[email-masked]>
Date: Sat, 16 Jun 2018 12:15:50 +0100

----- Original Message -----
From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology
Research Dept)" <[email-masked]>
Sent: Friday, June 15, 2018 11:36 AM

> Dear WG,
>
> This is an update to OTN topology after 8 month, as we are waiting for
the maturity of basic TE topology model. Now the model is updated to be
aligned with TE one. You are welcome to review and provide your
comments.

It's a tough read.

I might find section 3.2 easier to follow if it was written in
Assembler:-(  A tree is intended to make a module easier to grasp but I
think that this fails here.  As RFC8340 says
" As tree diagrams are intended to provide a simplified
   view of a module, diagrams longer than a page should generally be
   avoided.  "

Nor is the module itself much simpler e.g.

  augment "/nw:networks/nw:network/nw:node/tet:te/"
        + "tet:information-source-entry/tet:connectivity-matrices/"
        + "tet:optimizations/tet:algorithm/tet:metric/"
        + "tet:optimization-metric/"
        + "tet:explicit-route-exclude-objects/"
        + "tet:route-object-exclude-object/tet:type/"
        + "tet:label/tet:label-hop/tet:te-label/tet:technology" {
    when "../../../../../../../../../../../../../../../"
       + "nw:network-types/tet:te-topology/"
       + "otntopo:otn-topology" {

rinse and repeat, seventy times.

I do not have a solution, just think that YANG has got it wrong
somewhere:-(

Meanwhile, there are my usual red tape issues.
 - copyright
 - date on module
 - reference statements on import
 - I-D References for any references in the module

along with incomplete sections 5, 6, 7.

I think that the failure of the tree diagram is the one that needs
tackling, perhaps with assistance from the contributors to RFC8340.

Tom Petch

>
> There are still some YANG errors because of the incorrect reference to
OTN tunnel model and OTN types, which have not been updated yet. The
other OTN tunnel model draft is under our processing and will be
announced in the next week. All the OTN models can be found at the
github:
https://github.com/haomianzheng/IETF-ACTN-YANG-Model/tree/master/YANG/cc
amp, and you are welcome to comments.
> 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.

---

From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Date: Tue, 19 Jun 2018 01:22:32 +0000

Hi, Tom, 

Thank you for providing the information. I fully agree with you and would like to spend some effort on make the work easier to read. However, I need some guidance and toolkit (UML editing is not sufficient) to accomplish the work. 

I also received some similar problems from other YANG editors, maybe a side-meeting in Montreal would be helpful for us to deal with it. Your suggestion are highly welcomed, thanks. 

Best wishes,
Haomian

-----邮件原件-----
发件人: t.petch [mailto:[email-masked]] 
发送时间: 2018年6月16日 19:16
收件人: Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept) <[email-masked]>; [email-masked]
主题: Re: [CCAMP] I-D Action: draft-ietf-ccamp-otn-topo-yang-03.txt

----- Original Message -----
From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[email-masked]>
Sent: Friday, June 15, 2018 11:36 AM

> This is an update to OTN topology after 8 month, as we are waiting for
the maturity of basic TE topology model. Now the model is updated to be aligned with TE one. You are welcome to review and provide your comments.

It's a tough read.

I might find section 3.2 easier to follow if it was written in Assembler:-(  A tree is intended to make a module easier to grasp but I think that this fails here.  As RFC8340 says " As tree diagrams are intended to provide a simplified
   view of a module, diagrams longer than a page should generally be
   avoided.  "

I do not have a solution, just think that YANG has got it wrong somewhere:-(

I think that the failure of the tree diagram is the one that needs tackling, perhaps with assistance from the contributors to RFC8340.

Tom Petch

> There are still some YANG errors because of the incorrect reference to
OTN tunnel model and OTN types, which have not been updated yet. The other OTN tunnel model draft is under our processing and will be announced in the next week. All the OTN models can be found at the
github:
https://github.com/haomianzheng/IETF-ACTN-YANG-Model/tree/master/YANG/cc
amp, and you are welcome to comments.
> 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.

---

From: "t.petch" <[email-masked]>
Date: Tue, 19 Jun 2018 12:15:42 +0100

I am afraid that my knowledge of YANG is not up to seeing alternative
approaches (unless and until I see them used in other I-Ds:-).  Other
computer languages are much more elegant when it comes to slotting in
multiple adjustments in multiple places.  Here I struggle even to
reverse engineer the YANG to see what is intended.

I think that your hand is forced by draft-ietf-teas-yang-te-topo which I
had looked at, but had not grasped the consequences of, until I saw your
I-D even though I had looked at Appendix C, the example of augmentation,
in the former; and forced again by the rules in RFC8340.

Part of the problem is the depth of the data tree, up to 20 levels or
so, which makes any absolute form of 'augment' or 'when' lengthy,
fragile and error prone.  I see
    when "../../../../../../../../../../../../"
       + "nw:network-types/tet:te-topology/"
       + "otntopo:otn-topology" {
as well as
    when "../../../../../nw:network-types/tet:te-topology/"
       + "otntopo:otn-topology" {
similar but different; are both correct? hard to tell.  Collapsing the
tree to much fewer levels would make it so much easier to follow but is
obviously problematic.  'when' can sometimes be replaced by 'if-feature'
again a significant change even when it is practicable.

Likewise use of relative rather than absolute references in 'augment'
would make it much clearer to me but I am uncertain how feasible that
is.

And then it is possible to add your own extensions to YANG which
increases the scope somewhat:-)

You need one who shares my concern as to how easy (or not) this is to
review with a deep understanding of all that YANG can offer, perhaps one
of the architects of YANG.

Tom Petch

----- Original Message -----
From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology
Research Dept)" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 19, 2018 2:22 AM

> Hi, Tom,
>
> Thank you for providing the information. I fully agree with you and
would like to spend some effort on make the work easier to read.
However, I need some guidance and toolkit (UML editing is not
sufficient) to accomplish the work.
>
> I also received some similar problems from other YANG editors, maybe a
side-meeting in Montreal would be helpful for us to deal with it. Your
suggestion are highly welcomed, thanks.
> 收件人: Zhenghaomian (Zhenghaomian, Optical &Microwave Technology
Research Dept) <[email-masked]>; [email-masked]
> the maturity of basic TE topology model. Now the model is updated to
be aligned with TE one. You are welcome to review and provide your
comments.
Assembler:-(  A tree is intended to make a module easier to grasp but I
think that this fails here.  As RFC8340 says " As tree diagrams are
intended to provide a simplified
somewhere:-(
> > This draft is a work item of the Common Control and Measurement
Plane
> WG of the IETF.
> >    transport network can be constructed from equipments utilizing
any
> of
tools.ietf.org.