Network Management Operations (nmop) WG Agenda - June 04, 2024 Interim Meeting

• When: June 04, 2024
• Co-Chairs: Benoît Claise & Mohamed Boucadair
• Minutes: Thomas Graf

Compact Agenda

| Slot | Topic | Presenter |
| :-: :-: :-
| 14:00 - 14:05 | Agenda Bashing & Introduction | Chairs |
| 14:05 - 14:55 | NMOP Part | Olga/Oscar/Nigel |
| 14:55 - 15:45 | TEAS Part | Italo |
| 15:45 - 15:00 | Next Steps & Wrap-up | All |

Welcome & Introduction (Chairs, 5mn)

No agenda bashing.

The Chairs reported that:

• They informed the Routing ADs about this work.
• They also contacted the authors of RFC8345 to let them know about
  the ongoing digital map effort, invite them to join the work, and
  indicate whether they are interested to contribute if working on a
  bis is decided by the WG.

NMOP Part (Olga & Oscar) (50 mn)

Summary of next steps for Digital Map for IETF120

Progress on the analysis of RFC8345 Augmentations and presentation of some conclusions

Plan for drafts for IETF120

• draft-ogondio-nmop-isis-topology, draft-ogondio-nmop-ospf-topology,
• draft-havel-nmop-digital-map
• RFC8345 bis

Note: https://datatracker.ietf.org/doc/draft-ogondio-nmop-ospf-topology/
posted.

RFC8345 Gaps for Digital Map Modelling

Nigel Davis: About topologies and topological structures. We need to be
careful. There are two topology levels. Topology of potential. Where RFc
8345 is focusing on with links and termination points. Then there is
topology of use. Where a specific flow is enabled. So you have a
constrained enabled flow. That is also topological. I certainly have
seen situation where the same entity is being used for both potential
and enabled flow and other situations where it is kept separate. The TE
solution asumes a destinction between the entities of enabled flow and
potential flow. That where the challenge comes in. All topologies are
represented in RFC 8345.

Olga Havel: Did I understand correctly that your understandig of RFF
8345 is that it is only about potential topologies?

Nigel Davis: No, RFC 8345 is in this regard ambiguous.

Olga Havel: You mean that topologies are planned, historical?

Nigel Davis: The only thing I can think of is the usage of the link
entity in other SDO's. Where the usage of link is only about potential.
Therefore if you use the term link you lead the audience to potential.

Olga Havel: This goes back 20 years where this was simpified in
different standars and now we more and more distinguish between
potential and enabled. You are absolute right, there are two approaches.

Nigel Davis: Lets take this offline at IETF 120.

Olga Havel: Agree, by reading different standards. When reading RFC 8345
I didn't not recognize a distinction between the two. I asumed it
proposes a generic approach.

Nigel Davis: I think it is just ambigious.

Benoit Claise: Reminds to better discuss it on the mailing list.

Olga shared the excel spreadsheet at
https://github.com/ietf-wg-nmop/Misc/tree/main/Digital-Map-Analysis

and asks for contribution.

Italo Busi: You speak about specific application for TE. Do you have an
idea what are the boundaries of TE and what is broader then TE? About an
interesting use case with SRLG for a what if analysis in a connection
less network. Do you think this is a TE application or not?

Olga Havel: With "what if" there are different aspects. Maybe also in
terms of TE. But also Symtoms and Assurance.

Italo Busi: Agree. But I am refering to wherever SRLG attributes would
be useable in "what-if". I am asking wherever there is a boundary to TE
or not.

Olga Havel: Your comment is about wherever this specific attribute is
wider than TE or not?

Italo Busi: Correct.

Olga Havel: I took it from the draft. But of course that does not
restrict to use the antribute elsewhere.

Italo Busi: I think some clarifications are needed.

Benoit Claise: Regarding contributions to the Excel spreadsheet. What
would be good is to add a column name "validated by the author".

Vishnu Beeram (chat): In hindsight, a better name for the data model in
RFC8795 would have been TE aware topology data model (would have avoided
a fair bit of confusion)

Italo Busi (chat): I agree: the naming and scope in RFC8795 are a bit
confusing. We need to clarify this in TEAS WG

draft-davis-opsawg-some-refinements-to-rfc8345

Italo Busi (chat): I think that backward compatibility requires more
detailed considerations: for the sake of saving meeting time, let's
discuss on the list

Mohamed Boudacair: One request. You have shown a list of candidate
refinements. Can you bring them onto the mailing list?

Nigel Davis: Certainly.

Share plan for hackathon

Suggestions for IETF120 about the DM API/YANG scope that can be used for agreeing the approach and guidelines

TEAS Working Group Part (50 mn)

Applicability of TE Topology Data Model to Digital Map (Italo Busi) 30 mins

• Reference Document: RFC 8795
• Main Topics
  • Overview of the various features of the data model
  • Discussion on how the data model can cater to the Digital Map
    requirements
  • Discussion of backwards compatible enhancements (where
    necessary)

Olga Havel: I think I did not specify that TP is not addressed in RFC
8345. RFC 8345 is very generic.

Italo Busi: Yes, it is not clear how multi layer is being addressed in
RFC 8345.

Nigel Davis: The client layer link is a RFC 8345 link correct?

Italo Busi: Yes, if you manage the tunnel.

Olga Havel: My understand was that TP is generic and can be applied to
LTP, TTP, CTP or GTP. What was the reason not to reuse the TP definition
and the suporting relationships described in RFC 8345 for layered
networks?

Italo Busi: I don't recall. As far as I remember RFC 8345 uses the term
TP for terminating links.

Mohamed Boucadair (chat): @Italo: What would be helpful is to share the
rationale for some design choices in the TE model, especially the
various termination points. This will also help understand if navigating
among levels, with or without tunnels in place.

Vishnu Beeram (chat): @Med - the rationale for most of the design
choices made for the TE topology data model should be covered in RFC8795
(it would be useful to start a thread on the TEAS list for questions on
the specific design choices of interest); with regards to termination
points, the need for distinction between LTP and TTP should be obvious
from the descriptions in the document -- we can discuss this more in
detail on the list.

Robert Wilton (chat): There is a also a downside to being able to model
the same thing two different ways. If we allow this then it would be
useful to have clear guidance.

Nigel Davis: That was my previous point. If you take link as in ITUT
link. You end up using link as forwarding relationship. Which applies to
both potential or enabled flow. Thats the challenge we dealing with. We
need to decide on a generalized termination concept.

Italo Busi: You always can model differently.

Olga Havel: We did a PoC with layered networks using L2, L3, IS-IS,
OSPF, TE, MPLS LDP and SRv6 tunnels with RFC 8345. You are saying this
is only for TE? LDP would need to be modeled with RFC 8345 or would you
also be able to model with RFC 8795.

Italo Busi: In the primary, secondary and underlay path I don't think it
requires TE modeling.

Nigel Davis: If I understood correctly from Olga's question, it can be
used generically on all layers.

Italo Busi: I have a slightly different opinion. Underlay can be managed
because LDP creates the tunnel automatically.

Nigel Davis: You can still view it.

Olga Havel: You need to manage it for assurance.

Olga/Nigel: The process of deploying a protocol which automatically
creates tunnels versus a configured tunnel is different. Needs to
reflected in the modelling accordingly.

Italo Busi: From the level of topology navigation I agree. From the
level of path management I disagree. Because the path management
lifecycle is different.

Nigel Davis: The same module could be used with different lifecycles.

Olga/Nigel: From a map perspective we don't need to differentiate.

Italo Busi: Correct. Thats a very good point. We need to take into
account in the use case analysis.

Nigel Davis/Italo Busy/Olga Havel: Conversation about links being
represented uni- or bi-directional. Having different implications.
Depending on layer, useability and scalability.

Nigel Davis: Wants to propose to support for bi-directional links
besides of uni-directional links.

Italo Busi: Need to be careful about implications. Makes examples from
optical domain (slide 12).

Italo Busi: We had a PoC for multi domains in China and one PoC for
micro-wave. Will send to the list those two public events

Profiles for TE Topology Data Model (Italo Busi) 20 mins

• Reference Document: draft-ietf-teas-te-topology-profiles

Benoit Claise: Are there any hackathon implementations of this draft?
Italo Busi: Several partial implementations covering some aspects of the
model
Olga Havel: But no code to be looked at correct?
Italo Busi: Correct

Next Steps (All, 15 min)

Mohamed Boudacair summarized the action points as next step:

1. Olga Havel: Consolidate the use cases. Olga already prepared the
   documents with Digital Map requirements and the core use cases.
   Extract and share on the TEAS and NMOPS mailing lists.
2. Italo Busi: Do the assessment for those use cases against RFC 8795:
   Which ones are implementable using the TE model and which one not.
   Describe the issues.
3. Nigel Davis: Refinement candidates. Please share them separately on
   the mailing lists to enable discussion. For some we need an
   agreement. We might discard some of them depending on feedback.
4. Oscar: For the adoption call on IS-IS and OSPF, please clarify
   wherever we need extensions on RFC 8345 or not.

Vishnu Beeram (chat): Good start. Lets continue on the list
Nigel Davis (chat): Shall I post to TE Tunnel discussion on TEAS or on
NMOP mailing lists?
Mohamed Boucadair (chat): We need to synchronize on both mailing lists
Oscar de Dios (chat): Face to face meeting with a whiteboard would be
extremely helpful, specially talking about topologies.