Re: [i2rs] 'network type' placement and RFC8345
Tom, On 9/26/2020 7:06 AM, tom petch wrote: I have read and re-read RFC8345 and as I have said, I find it clear that a presence container must be defined but do not see the guidance as to what goes under what, apart from OSPF and layer 3. As other messages makes clear, there's a lot of history here. The assumption has always been that technologies controlled using TE mechanisms/models of the IETF (including those worked on in CCAMP) would be based on the generic TE models developed in TEAS. I think the documents developed in CCAMP make this hierarchy clear -- but perhaps I've been too close to those discussions. FWIW https://tools.ietf.org/html/rfc8795#section-6 is pretty clear on this. I suggest moving this discussion back to CCAMP or TEAS for follow up focused on the ccamp document or teas-produced RFC... Lou ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] 'network type' placement and RFC8345
From: Susan Hares Sent: 25 September 2020 23:11 Tom: This issue is one that I debated with the TEAS group since there are two options: with teas (length is required) and without teas (length is extra). Deborah suggested that CCAMP was the expert. The original authors wanted it to go to TEAS and CCAMP. TEAS felt CCAMP and WSON should go under the TE-Topology. Since TEAS has control over a great deal of these drafts, the TEAS won. This is not a clear logical reason but perhaps the TEAS people will provide you with their reasoning. The reason I backed off on forcing specific instruction into RFC8345 is that the debates were still in full discussion mode. I had hoped we would come back and add detail later. Sue Thanks for the explanation. I shall shut up on this topic (hoping that my pessimism about it constraining future developments proves pessimistic). For myself, I regret not paying more attention to I2RS when this was under development. I did not realise where this was leading - if I had, then I would have thought more about it and contribute more. Tom Petch Sue -Original Message- From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of tom petch Sent: Friday, September 25, 2020 11:58 AM To: Susan Hares; 'Qin Wu' Cc: i2rs@ietf.org Subject: Re: [i2rs] 'network type' placement and RFC8345 From: Susan Hares Sent: 25 September 2020 14:10 Tom: The tree structure in RFC8345 provides links between types at different layers (service layer, net-layer 3, Layer2, Layer 1). The choice of whether CCAMP is layer 1 or layer 1-2 is a choice of the IETF standardizing the group. Deborah is correct to send you to that group. Can you provide a little detail on why you thing "CCAMP got it wrong"? Sue What I was referring to was placing the definition of the network type for WSON, for flexi-grid, for otn-topo, for optical impairment under te-topology so that te-topology becomes a top level node in the tree of network node like layer 1 or layer 2. Were WSON under layer 1 or layer 1-2 I would not question it but it seems inconsistent to me to treat te-topology like layer 1 etc. To me, that is looking at the classification of network type in a different dimension to layers, perhaps on the basis of YANG imports. I have read and re-read RFC8345 and as I have said, I find it clear that a presence container must be defined but do not see the guidance as to what goes under what, apart from OSPF and layer 3. A minor consequence is that all the references in the YANG when statements have an extra element - that is 101 when statements in wson-yang. Longer term I think we might find a different usage for the tree structure of network type although I do not see anything in particular at the moment and having a cluster under te-toplogy might thwart that usage (or of course it could be spot on:-). I e-mailed TEAS as the owners of te-topology to see if they saw themselves as a top level node but have yet to get a reply. I e-mailed yourself and I2RS to see if anyone had any more to say about RFC8345, what the thinking was about the tree structure and how it might be used. If I got an answer, then my thinking was to raise it as part of IETF Last Call for wson-yang to see what others thought. If TEAS or I2RS had strong views then I would see CCAMP as being likely to fall in with them. Tom Petch Sue -Original Message- From: tom petch [mailto:ie...@btconnect.com] Sent: Friday, September 25, 2020 6:31 AM To: Qin Wu; Sue Hares Cc: 'i2rs@ietf.org' Subject: Re: [i2rs] 'network type' placement and RFC8345 From: Qin Wu Sent: 24 September 2020 13:17 -邮件原件- 发件人: tom petch [mailto:ie...@btconnect.com] 发送时间: 2020年9月24日 16:45 From: Qin Wu 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. 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 nothi
Re: [i2rs] 'network type' placement and RFC8345
Tom: This issue is one that I debated with the TEAS group since there are two options: with teas (length is required) and without teas (length is extra). Deborah suggested that CCAMP was the expert. The original authors wanted it to go to TEAS and CCAMP. TEAS felt CCAMP and WSON should go under the TE-Topology. Since TEAS has control over a great deal of these drafts, the TEAS won. This is not a clear logical reason but perhaps the TEAS people will provide you with their reasoning. The reason I backed off on forcing specific instruction into RFC8345 is that the debates were still in full discussion mode. I had hoped we would come back and add detail later. Sue -Original Message- From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of tom petch Sent: Friday, September 25, 2020 11:58 AM To: Susan Hares; 'Qin Wu' Cc: i2rs@ietf.org Subject: Re: [i2rs] 'network type' placement and RFC8345 From: Susan Hares Sent: 25 September 2020 14:10 Tom: The tree structure in RFC8345 provides links between types at different layers (service layer, net-layer 3, Layer2, Layer 1). The choice of whether CCAMP is layer 1 or layer 1-2 is a choice of the IETF standardizing the group. Deborah is correct to send you to that group. Can you provide a little detail on why you thing "CCAMP got it wrong"? Sue What I was referring to was placing the definition of the network type for WSON, for flexi-grid, for otn-topo, for optical impairment under te-topology so that te-topology becomes a top level node in the tree of network node like layer 1 or layer 2. Were WSON under layer 1 or layer 1-2 I would not question it but it seems inconsistent to me to treat te-topology like layer 1 etc. To me, that is looking at the classification of network type in a different dimension to layers, perhaps on the basis of YANG imports. I have read and re-read RFC8345 and as I have said, I find it clear that a presence container must be defined but do not see the guidance as to what goes under what, apart from OSPF and layer 3. A minor consequence is that all the references in the YANG when statements have an extra element - that is 101 when statements in wson-yang. Longer term I think we might find a different usage for the tree structure of network type although I do not see anything in particular at the moment and having a cluster under te-toplogy might thwart that usage (or of course it could be spot on:-). I e-mailed TEAS as the owners of te-topology to see if they saw themselves as a top level node but have yet to get a reply. I e-mailed yourself and I2RS to see if anyone had any more to say about RFC8345, what the thinking was about the tree structure and how it might be used. If I got an answer, then my thinking was to raise it as part of IETF Last Call for wson-yang to see what others thought. If TEAS or I2RS had strong views then I would see CCAMP as being likely to fall in with them. Tom Petch Sue -Original Message- From: tom petch [mailto:ie...@btconnect.com] Sent: Friday, September 25, 2020 6:31 AM To: Qin Wu; Sue Hares Cc: 'i2rs@ietf.org' Subject: Re: [i2rs] 'network type' placement and RFC8345 From: Qin Wu Sent: 24 September 2020 13:17 -邮件原件- 发件人: tom petch [mailto:ie...@btconnect.com] 发送时间: 2020年9月24日 16:45 From: Qin Wu 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. 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-unica
Re: [i2rs] 'network type' placement and RFC8345
Tom: The tree structure in RFC8345 provides links between types at different layers (service layer, net-layer 3, Layer2, Layer 1). The choice of whether CCAMP is layer 1 or layer 1-2 is a choice of the IETF standardizing the group. Deborah is correct to send you to that group. Can you provide a little detail on why you thing "CCAMP got it wrong"? Sue -Original Message- From: tom petch [mailto:ie...@btconnect.com] Sent: Friday, September 25, 2020 6:31 AM To: Qin Wu; Sue Hares Cc: 'i2rs@ietf.org' Subject: Re: [i2rs] 'network type' placement and RFC8345 From: Qin Wu Sent: 24 September 2020 13:17 -邮件原件- 发件人: tom petch [mailto:ie...@btconnect.com] 发送时间: 2020年9月24日 16:45 From: Qin Wu 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. 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://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01 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. 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
Re: [i2rs] 'network type' placement and RFC8345
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:i2rs-boun...@ietf.org] 代表 tom petch > 发送时间: 2020年9月23日 17:16 > 收件人: Sue Hares > 抄送: 'i2rs@ietf.org' > 主题: [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 > i2rs@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i2rs__;!!BhdT!wQLS277tNN5EbdnoKAs80xGvflFB086ONF3XdrinRL0vW_o7YO8EpxJqHjc71w$ > > ___ > i2rs mailing list > i2rs@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i2rs__;!!BhdT!wQLS277tNN5EbdnoKAs80xGvflFB086ONF3XdrinRL0vW_o7YO8EpxJqHjc71w$ > ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] 'network type' placement and RFC8345
From: Qin Wu Sent: 24 September 2020 13:17 -邮件原件- 发件人: tom petch [mailto:ie...@btconnect.com] 发送时间: 2020年9月24日 16:45 From: Qin Wu 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. 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://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01 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. 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:i2rs-boun...@ietf.org] 代表 tom petch 发送时间: 2020年9月23日 17:16 收件人: Sue Hares 抄送: 'i2rs@ietf.org' 主题: [i2rs] 'network type' placement and RFC8345 RFC8345 requires that a new network type be given a presence
Re: [i2rs] 'network type' placement and RFC8345
-邮件原件- 发件人: tom petch [mailto:ie...@btconnect.com] 发送时间: 2020年9月24日 16:45 收件人: Qin Wu ; Sue Hares 抄送: 'i2rs@ietf.org' 主题: Re: [i2rs] 'network type' placement and RFC8345 From: Qin Wu 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. " 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://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01 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. 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:i2rs-boun...@ietf.org] 代表 tom petch 发送时间: 2020年9月23日 17:16 收件人: Sue Hares 抄送: 'i2rs@ietf.org' 主题: [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 t
Re: [i2rs] 'network type' placement and RFC8345
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. " 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://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01 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. -Qin -邮件原件- 发件人: i2rs [mailto:i2rs-boun...@ietf.org] 代表 tom petch 发送时间: 2020年9月23日 17:16 收件人: Sue Hares 抄送: 'i2rs@ietf.org' 主题: [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 i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
[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 i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
