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

["Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[e-mail]>]

Hi, Tom, 

After a review of historical versions of draft-ietf-teas-yang-te-topo, I summarized the issue together with your proposal as follow: 

1) If I understand your proposal on 'inside-out' correctly, the problem can be solved by changing the order of folders. However, the same leaves are augmented multiple times is because of there are multiple of 'te-bandwidth' and 'te-label' many where in the te-topo tree. Even if we put a 'link-bandwidth' augment, it won't simplify the shape of tree; 
2) Considering the te-bandwidth, it's a single-layer when rather than multi-layer when. Some of the te-label (e.g. in path-route-object) is a multi-layer when while some others are single-layer when (e.g. in connectivity-matrix). I don't think addressing the multi-layer when issue will solve this problem much, only a little simpler. 

BTW, the two issues above are in the draft-ietf-teas-yang-te-topo, and we can do nothing in draft-ietf-ccamp-otn-topo-yang. Neither we can do anything in other technology-specifc topology models such as draft-ietf-ccamp-wson-yang and draft-zheng-ccamp-client-topo-yang, both of which are augmenting the TE topology model. Personally I think the section 6 of draft-ietf-teas-yang-te-topo provide a very detailed guidance on how to augment the model with tech-specific features, and there won't be much problem if we follow this rules. These augmentations only seem to be complicated instead of real complexity, and this is exactly what we do for the OTN topology model today. 

I wish we can reach some consensus on how to proceed these model during the WG discussion, thank you. 

Best wishes,
Haomian

Best wishes,
Haomian

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

I still mull over the challenge that
draft-ietf-teas-yang-te-topo-18.txt- sadly now approved - gives us of a YANG 'augment' to a challenging depth coupled with a 'when' to a challenging depth rendering the whole very hard for me to comprehend let alone validate.

Sometimes augment is made conditional by if-feature (as opposed to when) and that I find so much easier to understand and I wonder if that is an option here.  A many layered 'when' is fragile in ther face of any changes to the data node structure so is usually a bad idea.

The problem with augment might be solved if the data tree was turned inside out.  Currently you augment e.g.
networks/network/:link/te/information-source-entry/
max-resv-link-bandwidth/te-bandwidth/technology
to create
networks/network/:link/te/information-source-entry/
max-resv-link-bandwidth/te-bandwidth/technology/otn-link-bandwidth

Turning it inside out, you would augment

networks/network/:link/te/information-source-entry/
max-resv-link-bandwidth/te-bandwidth/link-bandwidth

where link-bandwith is a grouping in the base model which only needs one augment to add something technology specific e.g. otn-data - which then caters for all appearances on link-bandwith; ditto te-label etc so that the number of augments is reduced by an order of magnitude or so.  Much simpler.

Tom Petch


----- Original Message -----
From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology Research Dept)" <[e-mail]>
To: "t.petch" <[e-mail]>; <[e-mail]>
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.
>
> Best wishes,
> Haomian
>
> -----邮件原件-----
> 发件人: t.petch [mailto:[e-mail]]
> 发送时间: 2018年6月16日 19:16
> 收件人: Zhenghaomian (Zhenghaomian, Optical &Microwave Technology
Research Dept) <[e-mail]>; [e-mail]
> 主题: Re: [CCAMP] I-D Action: draft-ietf-ccamp-otn-topo-yang-03.txt
>
> ----- Original Message -----
> From: "Zhenghaomian (Zhenghaomian, Optical &Microwave Technology
Research Dept)" <[e-mail]>
> 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.
> >
> > Thank you.
> >
> > Best wishes,
> > Haomian
> >
> > -----邮件原件-----
> > 发件人: CCAMP [mailto:[e-mail]] 代表
> [e-mail]
> > 发送时间: 2018年6月15日 17:14
> > 收件人: [e-mail]
> > 抄送: [e-mail]
> > 主题: [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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
> > _______________________________________________
> > CCAMP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
> >
>
>