Network Management Operations (nmop) WG Agenda - Interim on Digital Map

• When: 2024-10-01 13:00-15:00 UTC
• Co-Chairs: Benoît Claise & Mohamed Boucadair

Compact Agenda

| Slot | Topic | Presenters |
| :-: :-: :-
| 13:00 - 13:05 | Agenda Bashing & Introduction | Chairs |
| 13:05 - 14:25 | Digital Map Concept and Terminology | Olga |
| 13:25 - 14:25 | Review and Discussion of the Digital Map Requirements | Olga |
| 14:25 - 14:50 | Digital Map Assessment Plans | Sherif/Italo |
| 14:50 - 15:00 | Next Steps | Chairs |

Detailed Agenda

1. Introduction (Chairs, 5 min)

Chairs slides are available here.

2. Digital Map Concept and Terminology (Olga, 20 min)

Goal:

• Discuss issues related to the concept definition, applicability,
  etc.

The slides are available here.

Italo Busi: Please describe the relationship between the Digital Map and
other topology-related use cases (including TE topology use cases). It
appears to be overlapping in some areas.

Olga Havel: That is the plan, but not in today's session.

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

Mohamed Boucadair: Adrian raised a comment about the topology
terminology. Did he check it?

Adrian Farrel: Please assign me an action point.

Olga Havel: Looking forward to the outcome of your review.

• Review text in latest version for Topology and Topology Layer
• Look to see whether there is a better definition that can be
  referenced

Daniele Ceccarelli: Defining the topology layer is very useful since it
helps to define relationships between different pieces. The term
topology itself is ambigous. I suggest to detail the meaning to better
define the term.

Olga Havel: We tried to find the topology definition. We did not find at
IETF but at Wikipedia.

Daniele Ceccarelli: Did not notice what effort went already in. Still
worries that current definition of topology means not for everybody the
same. What about aggregated topology instead?

Benoit Claise (as contributor): I understood that Daniele's point is
that Digital Map is not always about topology. If could be links etc.
Since it is about the Digital Map layer. How about Digital Map topology
instead?

Daniele Ceccarelli: I was more not using topology as a term in general.
However, I don't object on the term Digital Map topology.

Olga Havel: Digital Map topology is a good input. But please point me to
a reference we can rely on. Any opinions and feedback from the NMOP
community?

Rob Wilton: I echo Danieles feedback. I understand what topology layer
is. Unclear to me is what topology itself means and how topology and
topology layer relates. Means topology itself on of the layers?

Olga Havel: We didn't do multi layer topology. We refer with Digital Map
to a single layer.

Rob Wilton: Then do topology layer. However, I worry we need to define
the term topology itself as well. Might get a push back from IESG if we
don't do.

Olga Havel: From previous discussions I think it is important to
distinct between physical, network or service topologies clearly.
Therefore I rather suggest we go for Digital Map topology.

Rob Wilton: Maybe use another adjective like abstract topology to
describe further maybe?

Daniele Ceccarelli: Let me doublecheck I think in RFC 8345 we already
used abstract as a term.

Dan Voyer: If we go with digital map topology, what do we want to
represent/to look at? As an experience from discussions with a MPLS
background. Let's start with what we need and the requirements.

Rob Wilton (chat): I think that I find this definition of Topology to be
slightly confusing as well. It might also be helpful for Service
topology to be a separate definition

Mohamed Boucadair (chat):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. s/bring/break

Thomas Graf: I suggest to keep network topology and layer. I would not
go digital map topology as it could have a different meaning for a
different group.

Italo Busi (chat): My understanding is that you are trying to define the
term "topology" in general and not only in the context of Digital Map.
But from this discussion I am not sure my understanding was correct.

Dan Voyer: We obviously lack of a clear definition of network topology.
Therefore, let's define the term topology first and then go into Digital
Map definition second.

Med Boucadair: let's move the topology terminology discussion on the
mailing list.

Pierre Francois (chat): 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.

Olga Havel: It is not the entire topology model. It provides the link to
different other models in context of topology.

Adrian Farrel (chat): 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.
It has the flavour of "the links and nodes in the network together with
the information about how they are connected."
Later 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.).

Rob Wilton (chat): Adrian, if we have managed without a definition for
such a long term, then maybe we don't need to define it now?
Benoit Claise: @Pierre. From the Digitial Map definition: "Digital Map:
Basis for the Digital Twin that provides a virtual
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"

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

Thomas Graf (chat): @Rob, I think we need now one. Even if we define it
now. It defines the scope of the document and model.

Adrian Farrel (chat): I think the key is to scope the definition to what
the DT is doing

Dan Voyer (chat): @Adrian, thanks for that summary. I'm also in that
camp - many "network topology" specialized with the layer you are
looking at.

Adrian Farrel (chat): 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"

Pierre Francois (chat): 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

Sherif Mostafa (chat): 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" and may be "out of scope" section to be
explicit on what's not supported

3. Review and Discussion of the Digital Map Requirements (Olga/all, 60 min)

Goal:

• Detailed presentation/discussion of each requirement (one slide, one
  requirement) with the goal to agree on a stable set of requirements
  (consolidate the requirements, agree on their meaning/purpose, avoid
  biased ones, etc.) so that assessment work can have a stable base
  for analysis.

The slides are available here.

Italo Busi: Network topology is an augmentation of the network.

Olga Havel: Correct. I was refering to all others augmenting.

Italo Busi: The authors of RFC 8345 and RFC 8795 had at the beginning
intensive discussions what is the scope of each document. Both of them
are agnostic.

Olga Havel: You mean why the network, network topology and traffic
engineering topology is kept seperate?

Italo Busi: Yes, I suggest to doublecheck with the authors.

Olga Havel: For me it is quiet obvious. RFC 8345 ought to be simple
graph to show relationships.

Italo Busi: For me it is unclear how the relationships between the
different layers are achieved. Multi layer was defined as a requirement.

Olga Havel: This is defined. What is missing is multi domain and
partitioning capability. You should be able to model hirachically.

Italo Busi: If we don't know which traffic goes over which link, how can
a what-if analysis be performed? Example: What if the link fails.

Olga Havel: The analysis is not part of the digital map. It is part of
the application on top of the digital map.

Italo Busi: How do we know which application traffic is impacted on a
link failure?

Olga Havel: The application need to obtain the information from other
sources.

Benoit Claise: Italo, it seems that you have a specific use case in
mind. Not all use cases need to have the mapping to the specific
forwarding path. For example capacity management use case is more
general.

Italo Busi/Benoit Claise: Discussion on use cases. Wherever a specific
traffic flow goes over a specific link or not.
Thomas Graf: That is only achievable if we know how ECMP hashing is
being implemented, which is not part of the model. This is not
achievable since it is vendor propriety.

Thomas Graf: Consider to group multiple paths in multi pathing to one
group where ECMP loadbalancing hashing is unknown.

Italo Busi: Agree. This makes sense. I can support. We need then to
understand which links are in which group when we have parallel links in
a multipath setup.

Benoit Claise (chat): +1 to Thomas

Daniel Voyer (chat): We should add/do the same when we start doing
"latency-routing" with the new fashion TE like flex-algo

Daniel Voyer: What do you mean by domain?

Olga Havel: This is administratively defined. Could be access, campus or
data center domain for example.

Daniel Voyer: Maybe we should reference to other work where
administratively defined domains are defined.

Thomas Graf: I understood that it is administratively defined. Maybe
consider ODA (Open Digital Architecture) from TM forum. Decoupling
functions accross organisations.

Olga Havel: Correct. Like in ITU-T, there it is administrative domains.

Italo Busi: Instead of pluggable, shall we say it should interact with
other models instead to make it more generic?

Olga Havel: Agree. I will change the requirement accordingly.

Brad Peters (chat): All good for active data however active paths are
carried on physical cables across geographical distance and the focus at
present does not appear to support layer 0/1 that do not support YANG.
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

Thomas Graf (chat): @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.

Brad Peters (chat): @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

Brad Peters (chat): passive network rather than active you may place the
details on port descriptions and augment alarms with the
port description and correlate alarms including that detail.

Thomas Graf (chat): @Brad, optical transport can also be modeled in
YANG. I would expect that optical transport it's just another layer.

Dan Voyer (chat): more like multiple optical transport layers

Oscar Gonzalez (chat): Layer 0/1 can be perfectly described in yang. Of
course , the source is not “auto-discovered”. The source of information
will come from the operator fiber plant inventory.

Brad Peters (chat): @Thomas yes but that is still not providing linkage
between the passive part that is the fibre within a cable

Sherif Mostafa (chat): 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.

Thomas Graf (chat): Example:
https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-otn-topo-yang

Brad Peters (chat): @oscar correct

Sherif Mostafa: @Oscar +1

Dan Voyer:
1- photonic,
2- OTN
3- xWDM

Brad Peters: @sheriff yes geospatial db however these are not typically
easily accessible or have not great access capabilities to traverse the
model.
@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

Olga Havel: about REQ-RELATIONSHIP, maybe duplicate. Maybe we could
reorganize

Olga Havel: REQ-TEMPO-HISTO. A little confusing, we could improve

Italo: we must look at the gap and evaluate whether to add them as
requirements?

Olga Havel: yes

Italo Busi (chat): @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. The navigation from any layer
topology to the supporting hardware components (e.g., fibers) is work in
progress in IVY WG.

Brad Peters (chat): @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.
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

Brad Peters (chat): 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

Italo Busi (chat): @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

Brad Peters (chat): @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.

Italo Busi (chat): @Brad, I agree

4. Digital Map Assessment Plans & Ongoing Experiments Updates (25 min)

4.1 RFC 8345-based Approach: PoC Insights & Updates (Sherif) (15 min)

The slides are available here.

Thomas Graf (chat): @Olga, if I understand correctly, when Sherif
mentions "Entities" it refers to "Administrative Domain" as you
mentioned before correct?

Olga Havel (chat): Thomas, entities can be networks, nodes, tps or
links. So domains would be entities as well

4.2. RFC8795-based Approach: Assessment & Experiment Plan (Italo) (10 min)

The slides are available here.

5. Next Steps (all, 10 min)

List of main discussion points raised during the meeting can be foudn
here.

Med, summarizing the call:
Further Discussion Needed

1. Digital Map Terminology

   • Should this WG try to define the "topology" term only to be
     consumed for digital map?
   • Should this WG try to define the "topology" term for the IETF?
   • How “network topology” differs from “topology”?

2. Digital Map Requirements

   • Whether (if so how and to what extent) dynamic information is
     needed to be linked to the core digital map?
   • REQ-RELATIONSHIP is redundant

3. Hackathon plan to be coordinated for RFC8345 and RFC8795