Hi, Much thanks Tom as always for your careful reviews- I’m forwarding to ccamp for YANG fans to also review.
Thanks! Deborah Sent from my iPhone > On Sep 25, 2020, at 6:31 AM, tom petch <[email protected]> wrote: > > From: Qin Wu <[email protected]> > Sent: 24 September 2020 13:17 > > -----邮件原件----- > 发件人: tom petch [mailto:[email protected]] > 发送时间: 2020年9月24日 16:45 > > From: Qin Wu <[email protected]> > Sent: 24 September 2020 03:22 > > Hi, Tom: > Layer2, Layer 3, TE are all base modules which other modules can extend from. > I am not sure we have Layer 1 base module, WSON and flexi-grid, if my > understanding is correct, are TE technology specific and WSON and flexi-grid > module can be seem as extension to TE module or a module derived from TE > module Therefore we could follow OSPF example defined in the L3 topology > module or L3 TE module defined in draft-ietf-teas-yang-l3-te-topo-08. > > <tp> > Qin > > I think that you are missing the point. > RFC8345 sets up a registry, a namespace, and gives rules about how it should > be used. The use of a YANG presence container is clearly specified. > What I find unclear in RFC8345 is the intent about tree structure it > describes, what is the criterion for placing e.g. network type 802.3 > alongside or below one of the existing network type. > How the different network type YANG modules relate with respect to YANG > import and augment is a different and irrelevant question IMHO. > My thinking is that CCAMP have got it wrong and that their network types > should be alongside existing types, that there is nothing in RFC8345 to > suggest that they should be subordinate to anything else. > Since they are presence containers I see nothing in YANG that would make a > tree structure anything other than more complicated with a longer path to > reference them bringing no benefit. > > Tom Petch > > " > module: ietf-l3-te-topology > augment /nw:networks/nw:network/nw:network-types > /l3t:l3-unicast-topology: > +--rw l3-te! > " > " > module example-ospf-topology > augment "/nw:networks/nw:network/nw:network-types/l3t:l3-unicast-topology" > +--rw ospf! > " > I might be wrong if a generic layer 1 can be defined without adding > dependency to TE technology. But at least layer 1 type or layer 0 type are > common building block that can be reused. > > In addition, base model, in my opinion doesn't need to limit to layer 1, > layer 2, layer 3, service layer, TE layer this angle, we may classify network > topology from other angle, e.g., classify network topology into UNI topology > and NNI topology, One relevant model is UNI topology model that is proposed > in the opsawg > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01__;!!BhdT!wQLS277tNN5EbdnoKAs80xGvflFB086ONF3XdrinRL0vW_o7YO8EpxJPPIt5cg$ > > such models are also base model which other modules can derive from. > > For network type, if we can define it as identity, it may be another design > option. > But comparing with presence container design, I think the only difference is > one is explicit way, the other is implicit way. > > <tp> > Qin > My starting point is RFC8345 which for me creates this 'registry' of network > type and lays down the ground rules. It says that a presence container must > be defined. Why not identity, as with routing protocols, I do not know. It > suggests a tree structure and is generally keen on a layered network as in > layer 1, layer 2, layer 3, application-related layers and so on which is fine > until you get to sub-IP. > > But, network layering has nothing to do with YANG modules, with imports, > cross-references, dependencies and so on so the fact that the wson module > augments te-topo seems an irrelevance where the tree structure of layers is > concerned. There are lots of augments to te-topo and they could be any layer. > > [Qin]: we can have ietf-l3-te-topology module augment to layer 3, but we > don't have l3 specific module augment to te module, see > draft-ietf-teas-yang-l3-te-topo-08. > I will not see ietf-te-topology-packet as l3 specific module augment to te > module. But may be a little bit fuzzy. > For ccamp modules which are classified into layer 0,layer1 and married with > te technology, I feel nature they augment from te module, but not other layer > module. That's my impression. But I might be wrong. > > RFC8345 says a lot but I do not understand what it is saying when it comes to > adding a network type beyond what it says about presence container. What is > the point of the tree structure therein? > [Qin]: The question is whether there are any layer0, layer 2 modules without > marriage with TE technology? > > Is it something we want or need to embody in YANG so that we can do something > fancy as we can elsewhere with base identity and derivations therefrom as > with routing protocols? > > I do not know so my inclination is to say that the structure should be flat > until we have a good reason otherwise lest we find ourselves tied up in knots > at a later data. I think it would be quite wrong to build a tree structure > of network type based on YANG import which is what I suspect CCAMP are doing. > > Tom Petch > > -Qin > -----邮件原件----- > 发件人: i2rs [mailto:[email protected]] 代表 tom petch > 发送时间: 2020年9月23日 17:16 > 收件人: Sue Hares <[email protected]> > 抄送: '[email protected]' <[email protected]> > 主题: [i2rs] 'network type' placement and RFC8345 > > RFC8345 requires that a new network type be given a presence container and > suggests a tree structure with layer 1, layer 2, layer 3 and service as top > level nodes with OSPF as an example of a node subordinate to layer 3. > te-topology , RFC8795, places its presence container at the top level > alongside these four. > Question; where should a network type such as WSON or flexi-grid be placed? > wson-yang, in IETF Last Call, places it under te-topology which is possible > but it seems to me more like a layer 1 or layer 0. But then network types do > not seem to form a tree, rather a mesh so a tree structure seems wrong. And > wherever layer 1 is defined it is not in a module imported by wson-yang > although it might be added to layer0-types (!) which wson-yang does import. I > would see it as wrong to define layer 1 in wson forcing others to import wson. > > Thoughts? > > I have posted this to Lou and TEAS but as it is a question that cuts across > multiple WG I suspect that I will get multiple contradictory answers or > none:-) > > Tom Petch > _______________________________________________ > i2rs mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i2rs__;!!BhdT!wQLS277tNN5EbdnoKAs80xGvflFB086ONF3XdrinRL0vW_o7YO8EpxJqHjc71w$ > > _______________________________________________ > i2rs mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i2rs__;!!BhdT!wQLS277tNN5EbdnoKAs80xGvflFB086ONF3XdrinRL0vW_o7YO8EpxJqHjc71w$ > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
