[Digitalmap-yang] Modelling complex links - RFC8345 versus RFC8795

[Olga Havel <[e-mail]>]

Dear all,

I want to share this communication between Italo, Nigel and me  about modeling of complex links. We started communication outside of the group, but we all think it should be moved to the group. Any comments / feedback is appreciated.

Please start reading from the original Italo’s email from 20 Feb. I am attaching Italo’s original attachment as it was lost with replies.

Best Regards,
Olga

From: Italo Busi
Sent: Monday 4 March 2024 14:13
To: Olga Havel <[e-mail]>; Davis, Nigel <[e-mail]>; Benoit Claise <[e-mail]>
Cc: [e-mail]
Subject: RE: Modelling complex links

Ok for me: faster than waiting me to summarize the questions for the mailing list 😊

Italo



From: Davis, Nigel [mailto:[e-mail]]
Sent: Friday 1 March 2024 15:49
To: Olga Havel <[e-mail]>; Italo Busi <[e-mail]>; Benoit Claise <[e-mail]>
Cc: [e-mail]
Subject: RE: Modelling complex links

I am keen to have this on the mailing list (so yes, do cc) although you may want to change the name to include the draft name or RFC8345 enhancements or something like that.

N

From: Olga Havel <[e-mail]<mailto:[e-mail]>>
Sent: venerdì 1 marzo 2024 16:23
To: Davis, Nigel <[e-mail]<mailto:[e-mail]>>; Italo Busi <[e-mail]<mailto:[e-mail]>>; Benoit Claise <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Modelling complex links

Hi all,

Do you mind if I cc this to the mailing group?

Best Regards,
Olga

From: Davis, Nigel [mailto:[e-mail]]
Sent: Friday 1 March 2024 13:27
To: Italo Busi <[e-mail]<mailto:[e-mail]>>; Olga Havel <[e-mail]<mailto:[e-mail]>>; Benoit Claise <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Modelling complex links

Hi all,

Apologies for my late engagement in this discussion. I will work through the various point from earliest to latest:

  *   On the attached slides to the original… your proposal aligns with my thinking although I would go further and suggest that the approach we us in TAPI might be more appropriate as it offers several optimizations that significantly improve the efficiency and clarity. We can discuss this when face to face. As you say, we should also discuss on the mailing list (especially as activity there will help emphasize the relevance).

     *   The TAPI work is on node rule groups and I can provide more detail as we discuss

  *   On “decision to model links only as unidirectional was a conscious decision” I recognized this in the draft and worked through the rationale pointing out where it seemed flawed (as Olga notes in her reply). In summary, it does not appear the right choice, hence the enhancement proposed.
  *   On Olga’s point “must be there for all use cases”… this is key. There are many cases that benefit from a bidirectional and multi-point treatment, hence the intention to ensure that that capability is available in RFC8345 (along with the existing point to point capability, ensuring backward compatibility)
  *   On Olga’s point “the core topology model should be as simple as possible”… interestingly, if the original RFC8345 model had been multi-point, it would have actually been simpler. We should ensure we cover the inherent complexity of the space as efficiently as possible. There are some considerations that are fundamental, such as the list of ports and their directionality. There are further considerations that seem fundamental for all but the most basic applications, such as point role and potentially Link spec (which I can talk on). It may be right to augment the core model with a number of separate definitions to bring in these more sophisticated capabilities. This would allow a “layered” approach (not to be confused with transport layering etc. 😊) where a basic application that just needs nodes and links can use the core, but one that is doing planning can use a richer set of augments.
  *   On Olga’s point “Ideally, they would not add more topological entities,”… I think we should not add more topological entities. This does however leave me with the question on the TAPI equivalents and the ONF Core equivalents. In TAPI, we chose to separate two distinct aspects of the system (potential to enable forwarding and constrained enabled forwarding)

     *   The aspect that that deals with potential for forwarding (which is built from the node, nep and link) and the aspect that deals with the constrained enabled forwarding (which is built from the connection and the cep, where the connection usually represents the constrained enabled forwarding in the node, but can represent the constrained enabled forwarding of the link too – I can explain more on this (we did some work in TMF in TR215 that helps with the arguments that I could try to get liaised))
     *   RFC8345 seems to lean towards the model of potential, but the model of enabled forwarding seems to be scattered across IETF drafts where they do not derive from RFC8345 although they are topological… I may be wrong. I am thinking of:

        *   RFC9182 (VPN network – has data node, but does not derive from node of RFC8345)
        *   RFC8343 (interface – which whilst a device model has points that do not derive from TP)
        *   Etc.

Whilst I recognize that there is history here, it causes a lot of unnecessary variety)

     *   We should have a single model as a basis of all topological considerations (which are all node, point, arc models (although it can also be argued that they are essentially all component-system models really… again TMF TR215 and ONF TR-512 work through a lot of this)

  *   On Olga’s “clear requirements from the Operators that they want some topology layers to only have bidirectional links”… This is clear… and as the service provided by the underlay is bidirectional so must the topological entity resulting be (and same for multi-point)
  *   On Olga’s “modelling [multi-point] links using the virtual nodes,  it looks to me as more complex and it adds more instances”… absolutely!
  *   On the discussion between Olga and Italo on RFC8345 and RFC8795… In my opinion:

     *   We cannot force everything to build on RFC8795 (as it is already unwieldy and really ought to be broken down in to multiple separate documents each solving specific problems with self-contained and purposeful augment sets
     *   We should mine RFC8795 for solutions that are already there, but these should be offered as augments to RFC8345, again perhaps in separate documents each containing a self-contained and purposeful set of augments

        *   One of these could deal with all aspects of bandwidth/capacity another with delay/timing/latency etc. perhaps
        *   None would be directly in RFC8345
        *   All would be appropriately general and complete to allow use in any application where that aspect was needed, i.e., not lots of different YANG models covering the same details
        *   There is an interesting twist here where there are settings, measures, thresholds, threshold settings, watermarks, pms, alarms etc. associated with each aspect and these should be constructed uniformly regardless of the specific area considered (another dimension of challenge that it is time we got on top of)

     *   On Italo’s specific point “different YANG models to represent the underlay/overlay relationship between TE and non-TE networks”… no, it should simply be the RFC8345 relationship. It is not clear to me where the challenge is here.
     *   On Olga’s point “that supporting all requirements would make it complex and cannot be backward compatible”… It must be backward compatible. It must not be complex

        *   This is why parallel augmentation seems to be the right approach (RFC8345 does not itself carry the depth)
        *   If you want RFC8345 as is then do not use any of the new augments and ignore the multi-point opportunity, simply using the existing source/destination approach
        *   All new drafts should use the new multi-point and parallel augmentations available
        *   Existing drafts could consider migrating as they develop
        *   Existing RFCs may be gradually migrated recognizing their need for backward compatibility too
        *   The new augment sets would draw from existing drafts so as to not create yet more variety
        *

     *   On RFC8795, whilst I understand it is there and it is “mature” I wonder how much it is really deployed and used based upon Oscar’s statements.
     *   On Italo’s comment “virtual node, if you put all the requirements together you can see that the model pattern for the ‘enhanced’ link model will become almost the same as the model pattern for the node”… This is exactly where we got to in TMF TR512 and we considered a hypergraph treatment of everything. And then we took that further to recognize that they are all component-system pattern structures. This is too challenging to use considering the current state of play in the industry, but worth a brief discussion.
     *   On Olga’s “not-allowed/allowed connectivity”, we did some work in ONF Core on this which I could share where we recognized a recursion of constraints that could be applied to any particular solution which started with the device constraints (forced by hardware/software capability) and then applied operator policy to further narrow what was available etc.). This is available in TR-512.7 on the specification model (which is an area that we really do need to get into as it covers the connectability concern and the overall device capabilities etc.
     *   On Olga’s point “TE modelled Tunnels and TTPs as separate topological entities and not as links and TPs.”… As Italo notes in his response, this comes back to my comments above on the TAPI CEP (and discussions that Olga and I have had on the relationship between interface and RFC8345 TP). The TTP represents some of the CEP (“the point where the tunnel is terminated”) and some of the TAPI NEP (“and client/server adaptation can be performed”). We would need to untangle this as the RFC8345 TP could represent the NEP in the most natural of mappings to TAPI, but an RFC8345 TP could also represent a CEP… see the diagram below from TR-547..

[cid:image001.png@01DA6E46.727C5D50]

Regards,

Nigel

From: Italo Busi <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, February 22, 2024 10:09 PM
To: Olga Havel <[e-mail]<mailto:[e-mail]>>; Benoit Claise <[e-mail]<mailto:[e-mail]>>; Davis, Nigel <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [**EXTERNAL**] RE: Modelling complex links

Hi Olga,

The Tunnel model is used to manage the connectivity in the server layer which can be used either to support L2/L3 VPN services or to support links in the client layer network topology

The TTP represents the points where the tunnels terminate and client/server adaptation can be performed (capability): the actual configuration of the client/server adaptation is performed through the tunnel model

Italo

_____________________________________________
From: Olga Havel <[e-mail]<mailto:[e-mail]>>
Sent: mercoledì 21 febbraio 2024 17:23
To: Italo Busi <[e-mail]<mailto:[e-mail]>>; Benoit Claise <[e-mail]<mailto:[e-mail]>>; 'Davis, Nigel' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Modelling complex links


Hi Italo,

There is also the following statement from RFC8345:
“It is possible for links at one level of a hierarchy to map to
   multiple links at another level of the hierarchy.  For example, a VPN
   topology might model VPN tunnels as links.  Where a VPN tunnel maps
   to a path that is composed of a chain of several links, the link will
   contain a list of those supporting links.  Likewise, it is possible
   for a link at one level of a hierarchy to aggregate a bundle of links
   at another level of the hierarchy.”

We used this approach to model MPLS and SRv6 tunnels and paths. I know that TE modelled Tunnels and TTPs as separate topological entities and not as links and TPs. Do you know the history here?

Best regards,
Olga


_____________________________________________
From: Olga Havel
Sent: Wednesday 21 February 2024 15:48
To: Italo Busi <[e-mail]<mailto:[e-mail]>>; Benoit Claise <[e-mail]<mailto:[e-mail]>>; 'Davis, Nigel' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Modelling complex links


Hi Italo,

Thanks for the reply. Some comments inline. Should we move to the group?

Best Regards,
Olga

_____________________________________________
From: Italo Busi
Sent: Tuesday 20 February 2024 22:38
To: Olga Havel <[e-mail]<mailto:[e-mail]>>; Benoit Claise <[e-mail]<mailto:[e-mail]>>; 'Davis, Nigel' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Modelling complex links


Hi Olga,

I agree that RFC8345 has some gaps but IMHO most of these gaps have been already addressed by RFC8795
[OH] Are you suggesting that other technologies augment RFC8795 instead of RFC8345? Or to move part of RFC8795 to RFC8345? If the gaps are addressed in RFC8795 how can these gaps be addressed in technologies that are not augmenting RFC8795, like ISIS, OSPF, L2 Topo, L3 Topo, VPNs, etc. I would support strongly that when addressing how to extend RFC8345 for each of the gaps, the approach from RFC8795 if simple and generic enough should be considered as a candidate solution.

I understand your concerns with the name used for “TE Topology”, but:

  *   Do we need different YANG models to represent the bandwidth/capacity of the link depending on whether this information is used for path computation, capacity planning or digital map visualization?
[OH] We already have many YANG modules augmenting directly from RFC8345, around 60 of them. Please see the YANG catalog for the ietf-network and ietf-network-te. In regards to bandwidth/capacity, we did not propose to move them to the extended RFC8345 module (potentially RFC8345-bis)

<< OLE Object: Picture (Device Independent Bitmap) >>
<< OLE Object: Picture (Device Independent Bitmap) >>

  *   Do we need different YANG models to represent the latency of a link depending on whether this information is used for path computation or latency map?
[OH] I don’t think we suggested to add latency to the RFC8345.

  *   Do we need different YANG models to represent the shared risks of a link depending on whether this information is used for diversity constraints in path computation or for resiliency analysis?
[OH] Again, we were not identifying any properties needed in the core topological model, except semantics that identifies layers, roles in topology and relations inside the layer and between the layers. They can be defined in the augmentations

  *   Do we need different YANG models to represent the underlay/overlay relationship between TE and non-TE networks? What about the case where the underlay/overlay relationship is mixed with TE and non-TE networks?
[OH] Cant it be done in a simple generic way based on the core RFC8345 model? If not than more complex solution is needed. We tried to have a common approach  in our PoC.

Another concern is that if we develop different augmentations of RFC8345, how can we combine them in case of we have coexistence of TE and non-TE networks?
[OH] If we propose RFC8345 bis with the core topological concepts, it can be augmented.

I also understand your concern with RFC8795 looking like a huge and complex monolith.

However, if you consider all the requirements you cannot have a simple core topology model like RFC8345 without gaps. Looking at other topology models developed outside of IETF I do not see core topology model simpler than RFC8795 which can address all the requirements.
[OH] My opinion is if we want to have the core Digital Map model / API, it should be as simple as possible and focus on topological aspects of layered network, connectivity and services only. This should ideally not impact other modules. The goal is backward compatibility, it would just extend the RFC8345 to support some additional basic common requirements between TE and non-TE networks. The proposal to have a simple model is based on the experiences using those other industry models in multiple management products/solutions for many different technologies. But I do agree if we identify that supporting all requirements would make it complex and cannot be backward compatible, we should discuss alternative of using RFC8795.

To be honest, if I could come back to 5/7 years ago, it would push very hard to split RFC8795 into multiple modules, but, now, is the effort to deprecate RFC8795 and re-build everything from scratch, worth the value?
[OH] I agree that having multiple modules would have been ideal, one focusing on core topological enhancements and another focusing on traffic engineering. But at this point, we have to discuss if the existing RFC8345 o RFC8795 are the basis for Layered Digital Map. We already have many RFCs/drafts augmenting directly RFC8345. Maybe we can look at how would you split it today and if it can be backward compatible not to impact the current implementations?

We will also end up with use cases that can be addressed by re-using some but not the attributes from an existing model. Is this a justification to develop new YANG models? I see the risk to define one YANG model for each use case.
[OH] We already have inventory, te, sain, incidents, services, configuration, …. YANGs. The approach of having some core simple generic layered topology that links them all is what we wanted to propose.

Regarding your concern with the virtual node, if you put all the requirements together you can see that the model pattern for the ‘enhanced’ link model will become almost the same as the model pattern for the node:

  *   There is no always full connectivity between all the TPs attached to an ‘enhanced’ link so a concept like the connectivity matrix, as defined in RFC8795, needs to be defined for both nodes and ‘enhanced’ links to describe the allowed/not-allowed connectivity;
  *   Some of the path characteristics (e.g., latency, bandwidth, SRLG, …) may be different between different TP pairs and in some cases between the different directions so the overall structure will look like closer and closer to the detailed connectivity matrix definition in RFC8795 and duplicated between nodes and ‘enhanced’ links

[OH] Lets discuss it further, I started discussion with Nigel about potential connectivity and realized connectivity. There were also some discussions with the Operators if not-allowed/allowed connectivity should be at all part of the core topological model.

Italo

_____________________________________________
From: Olga Havel <[e-mail]<mailto:[e-mail]>>
Sent: martedì 20 febbraio 2024 19:37
To: Italo Busi <[e-mail]<mailto:[e-mail]>>; Benoit Claise <[e-mail]<mailto:[e-mail]>>; 'Davis, Nigel' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Modelling complex links


Hi Italo,

Thanks for the email and slides. I understand that the authors originally did not do bidirectional and multipoint intentionally. Nevertheless, we were doing analysis of RFC8345 only in relations to the Digital Map requirements we got from the Operators and based on our PoCs. We analyzed if the RFC8345 can be used to model network and service topologies & connectivity at different layers and support all requirements we collected.

After doing the initial PoC and submitting/presenting the original draft, we discussed with Nigel and he also agreed with these  limitations. Please refer also to https://datatracker.ietf.org/doc/draft-davis-opsawg-some-refinements-to-rfc8345/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-davis-opsawg-some-refinements-to-rfc8345/__;!!OSsGDw!JAad8MdIupzF_Mqi-Te51Sz6gFROKB1axtVDBhVMJJmEFyxUUFT7lSj6rCUkHoYQAUu4vz86ePdQjW2o$> for some of the arguments. We also discussed with some new operators and they agreed that these were the problems they identified when they planned to model topologies using the RFC8345.

In regards it RFC8795, I understand that it addresses some of the gaps, but as Digital Map must be there for all use cases, we started from RFC8345 and not from traffic engineering model.  This is the open question to discuss in the community, I am of the opinion that the core topology model should be as simple as possible (very similar to RFC8345), that it could  be used for L2 topology, L3 topology, IGP topology, BGP topology, tunnels with paths (MPLS and SRv6), services and layering and any relations between the entities, including overlay/underlay.  Different functions and technologies could extend as needed with more data. Ideally, they would not add more topological entities, they should create their network types and augmenting network/node/tp/link with properties.


Bidirectional:

  *   I understand that the bidirectional link can be represented via the pairs of unidirectional, but this is the API model and topology model therefore ideally should represent the topological view of the network. In the case where the links are really bidirectional I don’t see the reason to mandate creating multiple instances if not needed. Also, we got the clear requirements from the Operators that they want some topology layers to only have bidirectional links. Also, if we want to use the digital map for the core model for the digital twin, having more instances topological entities does not help.

Multipoint:

  *   In regards to modelling links using the virtual nodes,  it looks to me as more complex and it adds more instances.

Best regards,
Olga



_____________________________________________
From: Italo Busi
Sent: Tuesday 20 February 2024 17:11
To: Olga Havel <[e-mail]<mailto:[e-mail]>>; Benoit Claise <[e-mail]<mailto:[e-mail]>>; 'Davis, Nigel' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Modelling complex links


Hi Olga, Benoit, Nigel,

As mentioned in previous IETF meetings, I would suggest to look at the work already done in RFC8795 to address some of the gaps identified in RFC8345

The decision to model links only as unidirectional was a conscious decision in RFC8345 and not intended to be a limitation as described in section 4.4.5:

   The topology data model includes links that are point-to-point and
   unidirectional.  It does not directly support multipoint and
   bidirectional links.  Although this may appear as a limitation, the
   decision to do so keeps the data model simple and generic, and it
   allows it to be very easily subjected to applications that make use
   of graph algorithms.  Bidirectional connections can be represented
   through pairs of unidirectional links.  Multipoint networks can be
   represented through pseudonodes (similar to IS-IS, for example).  By
   introducing hierarchies of nodes with nodes at one level mapping onto
   a set of other nodes at another level and by introducing new links
   for nodes at that level, topologies with connections representing
   non-point-to-point communication patterns can be represented.

As I have discussed with Nigel in one of previous IETF meetings, if you look at all the properties of a link (e.g., delay), the N-square issue seems quite unavoidable but I agree that we can try to ‘compress’ the encoding to limit the N-square issue only to the differences wrt a common reference. This was also the design principle in RFC8795

Aihua and I have had an exercise to see how this description, together with the connectivity matrix definition in RFC8795, could be used to model p2mp links (e.g., for PON networks) as shown in the attached slides

We would appreciate if you can take a look and give us earlier feedbacks before we raise the comment on the mailing list

Thanks, Italo

<< File: p2mp-link-options-00.pptx >>