Re: [CCAMP] A YANG model to link Termination Point to Interface was :Re: Breaking out generic models from draft-ietf-ccamp-mw-topo-yang

[Italo Busi <[e-mail]>]

Hi Tom,

Please find in line my thoughts on both mails of you

Italo

> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: lunedì 28 novembre 2022 11:49
> To: Jonas Ahlberg <jonas.ahlberg=[e-mail]>; 'CCAMP'
> <[e-mail]>
> Subject: [CCAMP] A YANG model to link Termination Point to Interface was :Re:
> Breaking out generic models from draft-ietf-ccamp-mw-topo-yang
> 
> The augmentation is to
> "/nw:networks/nw:network/nw:node/nt:termination-point/tet:te"
> Why?  Why not
> "/nw:networks/nw:network/nw:node/nt:termination-point/"
> I do not see the te connection; to me it looks useful to any model with a
> termination point and not related to te..  If there is a case for /te/ then I would
> think that the model belongs in TEAS.  If not, well I2RS is no more so perhaps
> OPSAWG where it could get a wider review.
> 

[Italo Busi] I agree with you that it would be better to augment just the network topology and move the information within the termination-point container. For the home WG, please find my comments below to your first mail.

> Second, I wonder about the relationship of TP and IF.  Modelling networks
> used to be simple, nodes and edges.  Then, 1980s, the ends of the edges got
> separated from the node which I probably understand.  Recently there was an
> I-D on SAP, not the OSI SAP, not the mobile phone SAP; the I-D was clear that a
> SAP was not a link nor a tunnel termination point but less clear, to me, what it
> was.   I struggled to see what structure it was proposing, as, judging from the
> reviews, did many reviewers. It did map the SAP in YANG to an interface type
> and catered for sub-interfaces and attachment interfaces.
> 

[Italo Busi] My understanding is that there are scenarios where both the topology model and the interface model (as defined in RFC8343) are reported together. In this case, a given interface on a device can be reported both as a TP within the topology model as well as an interface within the interface model. The mode is aimed at reporting the relationship between them since they represent different views of the same entity. This might be something to clarify in the introduction of the new I-D.

> I note that here the leaf in the model is named ...interface-path which seems
> odd to me.
> 

[Italo Busi] What about calling it "interface-ref"?

> What I am fishing for here is what is the structure of a node nowadays.  It is
> the sort of thing that the ITU-T is good at, the IETF less so, and while mapping
> a termination point to an interface seems reasonable, I am conscious that such
> modelling, in other spheres, turns out to be problematic at a later date
> because the underlying concepts are not quite right, mixing apples and
> oranges
> 

 [Italo Busi] Well, not all the TPs can be associated with interfaces and vice-versa. The relationship is optional so it can be used only for the TPs that are associated with an interface. This might be something to clarify in the introduction of the new I-D.

> Tom Petch.
> 
> ________________________________________
> From: CCAMP <[e-mail]> on behalf of tom petch
> <[e-mail]>
> Sent: 24 November 2022 17:12
> Subject: Re: [CCAMP] Breaking out generic models from draft-ietf-ccamp-mw-
> topo-yang
> 
> From: CCAMP <[e-mail]> on behalf of Jonas Ahlberg
> <jonas.ahlberg=[e-mail]>
> Sent: 23 November 2022 07:49
> 
> Hi all,
> 
> In the current version of draft-ietf-ccamp-mw-topo-yang there are a total of
> three models.
> https://datatracker.ietf.org/doc/draft-ietf-ccamp-mw-topo-yang/
> 
>   *   ietf-microwave-topology.yang
> 
> A model which augments te-topology with microwave specific extensions
> 
>   *   ietf-bandwidth-availability-topology.yang
> 
> This is a module for defining a bandwidth availability matrix,
> 
> for links in a topology. It is intended to be used in conjunction with an instance
> of ietf-network-topology and its augmentations
> 
>   *   ietf-tp-interface-reference-topology.yang
> 
> This is a module for defining a reference from a termination point in a te-
> topology to a list element in interfaces as defined in RFC 8343
> 
> The last two are generic and can not only be used for a microwave topology
> but for any transport technology/topology. Therefore we plan to break out
> those two models from the microwave specific draft and instead put them in a
> new draft which in a better way reflects that they are generic.
> 
> <tp>
> Bad idea:-(  A three way split is a no-brainer to me.
> 
> The network model has been augmented recently with 'node' gaining useful
> information such as node type, MAC usage, IPv4 routes, IPv6 routes and so on.
> This you would be unlikely to divine from the title of the I-D (which contains
> the augmentation) or indeed from reading the I-D; which I did and it passed
> me by.  Only by reverse engineering the YANG might you see these possibly
> useful, generic additions for network models (unless, that is, you are the
> author).  Were these additions in an I-D with a relevant title then perhaps the
> wheel will not be reinvented at some later date.
> 
> So, three I-D with relevant titles.  Yes, two are small and it would be nice for
> there to be more substance to them but more could get added in a revision.
> 

[Italo Busi] I am not sure I understand your view. Are you proposing to split the work into three I-Ds?

> Which WG is suitable for the two new ones?  TEAS? OPSAWG?  Tucked away in
> CCAMP they might not be noticed.
> 

[Italo Busi]

This is a good question. I have no strong opinion about the home WG.

The network topology model (RFC8345) has been developed by the I2RS WG which, if I am not mistaken, is now closed. The interface model (RFC8343) has been developed by the Netmod WG.

I do not think that the bandwidth availability would be in the scope of OPSAWG. Maybe of TEAS. The question would be whether bandwidth availability is generic only for the technologies in the scope of CCAMP WG or applies also to other technologies.

Having said that, there are other cases where generic models have been developed in CCAMP WG (e.g., RFC8632) so I do not see any strong need to change the home WG for these drafts

[/Italo Busi]

> Tom Petch.
> 
> We would like to get your feedback on this proposed change.
> 
> Regards
> Jonas Ahlberg
> on behalf of the microwave team
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>