[{"author": "Beno\u00eet Claise", "text": "

Hello everybody. Welcome to NMOP. The meeting minutes are collected here: https://notes.ietf.org/notes-ietf-interim-2024-nmop-04-nmop

", "time": "2024-10-01T13:02:24Z"}, {"author": "Italo Busi", "text": "

yes, relationship between Digital Map use cases and other topology-related use cases (including TE topology use cases)

", "time": "2024-10-01T13:10:54Z"}, {"author": "Mohamed Boucadair", "text": "

@Italo: may be add the point to https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/issues

", "time": "2024-10-01T13:11:16Z"}, {"author": "Dan Voyer", "text": "

it would be nice to actually have an IETF accepted document on topology. At Bell, we go with underlay/overlay and service layer

", "time": "2024-10-01T13:17:08Z"}, {"author": "Robert Wilton", "text": "

I think that I find this definition of Topology to be slightly confusing as well.

", "time": "2024-10-01T13:18:08Z"}, {"author": "Robert Wilton", "text": "

It might also be helpful for Service topology to be a separate definition

", "time": "2024-10-01T13:18:25Z"}, {"author": "Mohamed Boucadair", "text": "

The initial intent was to have a formal definition for \"topology\" (because there is no authoritative RFC for this). This is why Adrian's comment that we need to also be careful to not bring \"how\" this was used in existing RFCs.

", "time": "2024-10-01T13:22:29Z"}, {"author": "Mohamed Boucadair", "text": "

s/bring/break

", "time": "2024-10-01T13:22:51Z"}, {"author": "Italo Busi", "text": "

My understanding is that you are trying to define the term \"topology\" in general and not only in the context of Digital Map

", "time": "2024-10-01T13:26:46Z"}, {"author": "Italo Busi", "text": "

but from this discussion I am not sure my understanding was correct

", "time": "2024-10-01T13:27:15Z"}, {"author": "Pierre Francois", "text": "

The proposed definition of the digital map is restricted to the topological properties of the network. I'm not sure your listed use cases for the digital map can work out with only topological properties.

", "time": "2024-10-01T13:31:31Z"}, {"author": "Pierre Francois", "text": "

Agreed.

", "time": "2024-10-01T13:33:16Z"}, {"author": "Adrian Farrel", "text": "

So I have been digging through the history. I find no definitive explanation of topology right back to the very early RFCs. They all just use the term like you should know what it means.
\nIt has the flavour of \"the links and nodes in the network together with the information about how they are connected.\"
\nLater RFCs introduce \"network topology\", \"virtual network topology\", \"routing topology\", \"TE topology\". These seem to be profiles of the \"topology\" as assumed, with some additional qualifying information (metrics, qualities, etc.).

", "time": "2024-10-01T13:33:26Z"}, {"author": "Robert Wilton", "text": "

Adrian, if we have managed without a definition for such a long term, then maybe we don't need to define it now?

", "time": "2024-10-01T13:34:24Z"}, {"author": "Beno\u00eet Claise", "text": "

@Pierre. From the Digitial Map definition: \"Digital Map: Basis for the Digital Twin that provides a virtual
\n instance of the topological information of the network\" and we defined topology to be not only physical but also services (as an example). Hence the key definition of \"topology\"

", "time": "2024-10-01T13:34:34Z"}, {"author": "Daniele Ceccarelli", "text": "

isn't network topology good enough? what is the difference between topolgoy and network topology?

", "time": "2024-10-01T13:34:46Z"}, {"author": "Adrian Farrel", "text": "

@Daniele Who knows? Lacking the definitions, it is hard to answer :-)

", "time": "2024-10-01T13:35:54Z"}, {"author": "Mohamed Boucadair", "text": "

+1 Adrian ;-)

", "time": "2024-10-01T13:36:04Z"}, {"author": "Thomas Graf", "text": "

@Rob, I think we need now one. Even if we define it now. It defines the scope of the document and model.

", "time": "2024-10-01T13:36:11Z"}, {"author": "Adrian Farrel", "text": "

I think the key is to scope the definition to what the DT is doing

", "time": "2024-10-01T13:36:33Z"}, {"author": "Dan Voyer", "text": "

@Adrian, thanks for that summary. I'm also in that camp - many \"network topology\" specialized with the layer you are looking at.

", "time": "2024-10-01T13:36:48Z"}, {"author": "Thomas Graf", "text": "

@Adrian +1

", "time": "2024-10-01T13:37:18Z"}, {"author": "Adrian Farrel", "text": "

We don't need to force a definition on the historic pile of RFCs. We do need to explain what we mean in DT when we say \"topology\"

", "time": "2024-10-01T13:37:24Z"}, {"author": "Pierre Francois", "text": "

I use \"topology\" to mean different things depending on which working group I'm in. There is at least one definition of topology per wg at the ietf :) Let's clarify what it means when needed in a doc, maybe, but trying to get to a definition is maybe pointless

", "time": "2024-10-01T13:37:38Z"}, {"author": "Sherif Mostafa", "text": "

When looking at services and potentially mapping Applications as top part to network as down part, I'd be in favour with keeping as as \"Topology\"

", "time": "2024-10-01T13:38:02Z"}, {"author": "Sherif Mostafa", "text": "

and may be \"out of scope\" section to be explicit on what's not supported

", "time": "2024-10-01T13:39:31Z"}, {"author": "Pierre Francois", "text": "

You have to know, Italo, no way around it.

", "time": "2024-10-01T13:58:08Z"}, {"author": "Pierre Francois", "text": "

(for the application you are mentioning)

", "time": "2024-10-01T13:59:02Z"}, {"author": "Beno\u00eet Claise", "text": "

+1 to Thomas, about considering a group for ECMP.

", "time": "2024-10-01T14:01:19Z"}, {"author": "Dan Voyer", "text": "

we should add/do the same when we start doing \"latency-routing\" with the new fashion TE like flex-algo

", "time": "2024-10-01T14:02:15Z"}, {"author": "Pierre Francois", "text": "

yeah. Similarly, Dan, you will have to do the steering part of your SRv6 policy yang model draft at one point :)

", "time": "2024-10-01T14:03:22Z"}, {"author": "Dan Voyer", "text": "

yeah, I'm part of the problem basically ..

", "time": "2024-10-01T14:04:21Z"}, {"author": "Pierre Francois", "text": "

:innocent:

", "time": "2024-10-01T14:04:41Z"}, {"author": "Sherif Mostafa", "text": "

Just to note that there's in Weighted loadbalancing as well.

", "time": "2024-10-01T14:04:56Z"}, {"author": "Adrian Farrel", "text": "

Write that down! \"Not everything in the world is about YANG\" B. Claise

", "time": "2024-10-01T14:14:04Z"}, {"author": "Pierre Francois", "text": "

The rest is about IPFIX.

", "time": "2024-10-01T14:15:34Z"}, {"author": "Beno\u00eet Claise", "text": "

Adrian & Pierre: you two just won a pint in Guinness in Dublin. Thanks for a good laugh

", "time": "2024-10-01T14:16:42Z"}, {"author": "Beno\u00eet Claise", "text": "

pint of Guinness

", "time": "2024-10-01T14:16:55Z"}, {"author": "Brad Peters", "text": "

all good for active data however active paths are carried on physoical cables across geographical distance and the focus at present does not appear to support layer 0/1 that do not support YANG

", "time": "2024-10-01T14:18:31Z"}, {"author": "Brad Peters", "text": "

so a cut of a fibre will result in many active port alarms at l2/3 but without the cable details they cannot be correlated to a cable

", "time": "2024-10-01T14:20:56Z"}, {"author": "Thomas Graf", "text": "

@Brad, inventory data can be added so we know which logical link in the topology belong to which physical link. In multipathing scenarios, IPFIX would explain the outcome of the hashing. What we don't know is the intent, how it supposed to be hashed.

", "time": "2024-10-01T14:21:26Z"}, {"author": "Brad Peters", "text": "

@Thomas understand the ecmp/hashing but the focus on YANG implies that layer 0/1 connectivity is not included. is. the actual cable details that the fibres are within so you can tell the correlation between devices when cable is cut and you get los alarms

", "time": "2024-10-01T14:23:56Z"}, {"author": "Brad Peters", "text": "

passive network rather than active

", "time": "2024-10-01T14:24:19Z"}, {"author": "Brad Peters", "text": "

yomany place the details on port descriptions

", "time": "2024-10-01T14:24:41Z"}, {"author": "Brad Peters", "text": "

and augment alarms with the port descript and correlate alarms including that detail

", "time": "2024-10-01T14:25:55Z"}, {"author": "Thomas Graf", "text": "

@Brad, optical transport can also be modeled in YANG. I would expect that optical transport it's just another layer.

", "time": "2024-10-01T14:26:18Z"}, {"author": "Dan Voyer", "text": "

more like multiple optical transport layers

", "time": "2024-10-01T14:26:45Z"}, {"author": "Oscar de Dios", "text": "

Layer 0/1 can be perfectly described in yang. Of course , the source is not \u201cauto-discovered\u201d. The source of information will come from the operator fiber plant inventory.

", "time": "2024-10-01T14:26:55Z"}, {"author": "Brad Peters", "text": "

@Thomas yes but that is still not providing linkage between the passive part that is the fibre within a cable

", "time": "2024-10-01T14:26:56Z"}, {"author": "Sherif Mostafa", "text": "

for passive network, from my experience this data is stored in external places (fiber db). This data has the device, port on each side. This should be modelled I think in YANG.

", "time": "2024-10-01T14:27:08Z"}, {"author": "Thomas Graf", "text": "

Example: https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-otn-topo-yang

", "time": "2024-10-01T14:27:19Z"}, {"author": "Brad Peters", "text": "

@oscar correct

", "time": "2024-10-01T14:27:22Z"}, {"author": "Sherif Mostafa", "text": "

@Oscar +1

", "time": "2024-10-01T14:27:43Z"}, {"author": "Dan Voyer", "text": "

1- photonic,
\n2- OTN
\n3- xWDM

", "time": "2024-10-01T14:27:47Z"}, {"author": "Brad Peters", "text": "

@sheriff yes geospatial db however these are not typically easily accessible or have not great access capabilities to traverse the model

", "time": "2024-10-01T14:28:25Z"}, {"author": "Brad Peters", "text": "

@geospatial done for planning and recording the physical path of the cables many were not developped to be utilised as a mechanism to perform alarm correlations against and reduce alarm volume

", "time": "2024-10-01T14:29:49Z"}, {"author": "Thomas Graf", "text": "

@Olga, if I understand correctly, when Sherif mentions \"Identities\" it refers to \"Administrative Domain\" as you mentioned before correct?

", "time": "2024-10-01T14:41:31Z"}, {"author": "Italo Busi", "text": "

@Brad Peters, L0 and L1 topologies are modelled by YANG models developed by CCAMP WG as technology-specific augmentations of the TE topology YANG model (RFC8795). The multi-layer navigation between L0 and L1 topologies re-uses the technology-agnostic definitions in the TE topology (RFC8795). If NMOP defines another incompatible solution for multi-layer navigation, it will be very hard to navigate across multi-layer topologies when mixing TE and non-TE layers, especially in multi-vendor environments.
\nThe navigation from any layer topology to the supporting hardware components (e.g., fibers) is work in progress in IVY WG

", "time": "2024-10-01T14:41:58Z"}, {"author": "Thomas Graf", "text": "

I meant \"Entities\" instead of \"Identities\"

", "time": "2024-10-01T14:42:01Z"}, {"author": "Brad Peters", "text": "

@Italo yes i understand for active network only. If your using the model to determine alarm correlation and potential relationships between services then the active part is only a part of the service and your missing any ability to correlate between physical. so depends upon your use case and what your trying to achieve with it.

", "time": "2024-10-01T14:44:54Z"}, {"author": "Brad Peters", "text": "

so if i get a fibre cut then i can get a few hundred device alarms but no easy way to say they relate and they relate to one trouble ticket from an operation aspect. this of course alaso depends upon resilient paths etc through the model and being able to determine the paths

", "time": "2024-10-01T14:46:13Z"}, {"author": "Olga Havel", "text": "

Thomas, entities can be networks, nodes, tps or links

", "time": "2024-10-01T14:47:09Z"}, {"author": "Olga Havel", "text": "

so domains would be entities as well

", "time": "2024-10-01T14:47:26Z"}, {"author": "Brad Peters", "text": "

in the example, while i understand that the application is external, the map will need to understand the use cases and plan as to how to avoid supernode issues for traversals which can impact performance severly

", "time": "2024-10-01T14:47:56Z"}, {"author": "Italo Busi", "text": "

@Brad: IMHO, a network controller should be able to provide the root cause alarms only and the information about which service is affected. But this part is currently work planned to be done

", "time": "2024-10-01T14:48:28Z"}, {"author": "Brad Peters", "text": "

@Italo in regards to a fibre cut the root cause is a fibre cut and the controller will only show that there are ports with no signal any longer. Now you could do a x in y time correlation and make an assumption that the alarms are related and reduce it to 1 probably cause rather than root cause

", "time": "2024-10-01T14:50:37Z"}, {"author": "Italo Busi", "text": "

@Brad, I agree

", "time": "2024-10-01T15:01:10Z"}]