[Teas] Re: IETF120 Digital Map Side Meeting

[Vishnu Pavan Beeram <[e-mail]>]

@Med - Thanks for the clarification. It is premature to gauge WG preference
on this topic.



There seem to be two separate topology specific items that are being
tackled in the NMOP WG:

   - The first item is related to defining standard topology views. For
   example, one can produce multiple views of an L3 TE topology (from
   draft-ietf-teas-yang-l3-te-topo) using information-source filters like –
      - fetch all topological elements originated via ISIS L1
      - fetch all topological elements originated via ISIS L2
      - fetch all topological elements originated via OSPF
      - fetch all topological elements originated via ISIS and OSPF and so
      on..

The two IGP drafts that have been discussed in NMOP are attempts to define
standard topology types for filtered views of the topology. This seems to
be a reasonable request and we should discuss how to generalize this (there
are bound to be requests for more such "standard" topology views). This
item (imho) should be detached from the Digital Map discussion.

   - The second item that the NMOP WG is working on is the applicability of
   IETF topology models for catering to the Digital Map use-case. The
   requirements for the use-case suggest that there is a need for a topology
   model that can provide a multi-layer representation of the topology and has
   constructs that would help navigate from one layer to another. IMHO, the TE
   aware topology model from RFC8795 is built for this and its applicability
   for the Digital Map use-case should be thoroughly discussed before
   something new is put together. As noted in the side meeting, I believe the
   following action-items would be quite useful before the next meeting:


   - A draft that discusses “Applicability of RFC8795 Topology Data Model
   for Digital Map” (hopefully, someone would volunteer to do this).
   - Discussion (in netmod) on formalizing the use and construction of
   profiles of a data model.



Regards,

-Pavan

On Fri, Jul 26, 2024 at 2:59 AM <[e-mail]> wrote:

> Hi Olga, all,
>
>
>
> Thank you for leading this and for allowing for various groups with
> different perspectives to discuss and agree on common next steps.
>
>
>
> I have one comment about “NMOP preference” and “TEAS preference” mentions.
> I understand what you intended but procedurally speaking there is no such a
> thing.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Olga Havel <olga.havel=[e-mail]>
> *Envoyé :* jeudi 25 juillet 2024 22:55
> *À :* [e-mail]; [e-mail]
> *Objet :* [Teas] IETF120 Digital Map Side Meeting
>
>
>
> Dear NMOP and TEAS,
>
>
>
> Thanks for attending the Digital Map Side meeting at IETF120 in Vancouver.
> The slides are shared on NMOP github:
>
> Misc/side-meetings/ietf-120-sidemeeting-Digital-Map.pdf at main ·
> ietf-wg-nmop/Misc (github.com)
> <https://github.com/ietf-wg-nmop/Misc/blob/main/side-meetings/ietf-120-sidemeeting-Digital-Map.pdf>
>
>
>
> Thanks all for the lively discussion and even without reaching agreement I
> think it was very valuable discussion.
>
> For refresh, we were discussing between the following 2 approaches:
>
>    1. Use RFC8345 as a core topology model for the digital map, gaps to
>    be fixed in RFC8345 bis – NMOP preference
>    2. Use RFC8795 as a core model as it already addresses a subset of the
>    gaps identified – TEAS preference
>
>
>
> The slides communicate the reasons for 1, but in summary – simplicity +
> usability
>
>
>
> TEAS do agree about both points, their argument is that RFC8795 can be
> used with profiles in which case a profile could be created for the Digital
> Map Topology Model. Otherwise, the gaps addressed by TE would be done
> differently in the bis. Please note that 3 out of 7 gaps were done in TE, 2
> of them partially.
>
>
>
> My understanding is that even with profiles, the official API definition
> is still the standard YANG module from RFC8795. The profiles are currently
> the hack until supported by the YANG. Discovering of profiles and
> supporting profiles is not yet in YANG/Netconf/Restconf. Italo’s proposal
> is instead of focusing on RFC8345bis and procedural change to focus on
> adding the profiles programmatically in IETF. Nevertheless, we are still
> left with the problem is when you create a model that defines attributes
> that are defined also somewhere else.
>
>
>
> Please a reminder for all that the RFC8345 augmentation analysis can be
> found on
>
> Misc/Digital-Map-Analysis at main · ietf-wg-nmop/Misc (github.com)
> <https://github.com/ietf-wg-nmop/Misc/tree/main/Digital-Map-Analysis>
>
>
>
> We found only 13 out of 52 analyzed files using te, others just need
> ietf-network and ietf-topology. This is ¼ of the topology augmentations /
> imports.
>
> Please Italo and other in TEAS, could you review your drafts/RFCs in the
> spreadsheet and if we categorized them correctly. And please let us know if
> anything is missing.
>
>
>
> Conclusion:
>
> We have different opinions if ietf-network-topology (NMOP) or
> ietf-te-topology (TEAS) is the best basis for modelling the digital map.
>
>
>
> I presented the following proposal, feedback at the meeting was to agree
> the use case as soon as possible:
>
>    - 2 Hackathons at  IETF 121, agree the use case
>       - Pros / cons of both approaches after hackathons, where we can
>       compare API definitions and API request / response examples
>       - Collect opinions from operators and others
>
>
>
> Best Regards,
> Olga
>
>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Teas mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>