[OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-srv6-srh-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : Export of Segment Routing over IPv6 Information in IP 
Flow Information Export (IPFIX)
Authors : Thomas Graf
  Benoit Claise
  Pierre Francois
  Filename: draft-ietf-opsawg-ipfix-srv6-srh-05.txt
  Pages   : 28
  Date: 2022-12-15

Abstract:
   This document introduces new IP Flow Information Export (IPFIX)
   Information Elements to identify a set of Segment Routing over IPv6
   (SRv6) related information such as data contained in a Segment
   Routing Header (SRH), the SRv6 control plane, and the SRv6 endpoint
   behavior that traffic is being forwarded with.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-05

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-05


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] 🔔 WG LC: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)

[Joe Clarke (jclarke)]

Closing this WG LC out.  A great deal of support has been expressed for this 
work, and the chairs appreciate the attention to not only IANA but working 
implementations.

This draft will move forward to the IESG.  However, we NEED a shepherd.  I 
personally don’t feel comfortable shepherding this (nor do I really have the 
bandwidth at the moment).  Is there someone – perhaps someone that expressed 
their support – that would be willing to shepherd?

Joe

From: Joe Clarke (jclarke) 
Date: Wednesday, November 30, 2022 at 08:53
To: opsawg@ietf.org 
Subject: 🔔 WG LC: Export of Segment Routing over IPv6 Information in IP Flow 
Information Export (IPFIX)
Hello, WG.  As discussed at IETF 115, we want to conduct a WG LC for 
draft-ietf-opsawg-ipfix-srv6-srh.  The authors believe this work is stable and 
moreover used the 115 hackathon to develop a interoperable implementations 
(linked in Data Tracker) .  Additionally, IANA has already weighed in on this 
work and agree with the considerations approach.

Therefore, we are calling for a two week LC.  We will conclude on December 14.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/

Please review the current -04 draft, post your comments and/or your thoughts on 
the current text.

Thanks.

Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [netmod] How many "digital twins" every single network should have? Who would map between "twins"?

[Qin Wu]

Hi, Tom:
Model driven technology has laid foundation for operators and service provides 
to build their Digital twin platform, one more concrete reference can be 
RFC8969, which not only looks into top down service fulfillment, but also
Bottom up service assurance or performance monitoring, in my understanding 
digital twin is more related to telemetry, service assurance, network 
visibility, the reason I quote IRTF work is to provide an example on what 
digital twin will look like.

In IETF, we already see a lot of digital twin like model that has been 
standardized, e.g., RFC8345, RFC8346, RFC8795, etc, hope this clarifies.

-Qin
-邮件原件-
发件人: tom petch [mailto:ie...@btconnect.com] 
发送时间: 2022年12月15日 20:30
收件人: Qin Wu ; Vasilenko Eduard 
; Jan Lindblad 
抄送: opsawg@ietf.org; net...@ietf.org; Paolo Volpato ; 
Xipengxiao 
主题: Re: [netmod] How many "digital twins" every single network should have? Who 
would map between "twins"?

From: netmod  on behalf of Qin Wu 

Sent: 15 December 2022 08:07

Hi, Eduard:
Thank for bring this issue up, I think digital twins is more related to network 
topology model, network monitoring model rather than LxSM service delivery 
model or LxNM network model


I was going to ask for an explanation of a digital twin and then saw that it is 
a research topic of the IRSG about which consensus has not been achieved.  As 
such, I think it wrong for us to try and introduce it to YANG at this point in 
time

Tom Petch


First, As described in RFC8969 or RFC8309, LxSM service delivery model or LxNM 
network model focuses on service level abstraction and resource level 
abstraction respectively,  we expect Service level abstraction Can be 
decomposed into network/resource level abstraction, and resource level 
abstraction to be translated into a bunches of device level models, but we 
don’t expect translation across level can be standardized in the same way.
Service mapping process, configuration translation process should play the key 
roles, this provide flexibility and meet requirements of various difference use 
cases.
Another reason is not to choose use augmentation of LxSM model is mapping 
service parameter into configuration parameters is not always 1 to 1 mapping, 
in many cases,it is N to M mapping, domain specific level controller needs to 
allocate additional resource level parameters. Therefore I feel augmentation is 
more suitable device level, but not suggested to be used in top down service 
mapping.
But To reduce the mapping,cost, What we consider in LxNM model design is to try 
to reuse many data type that are also applied to LxSM. Please refer to RFC9181

Secondly, I disagree LxNM is designed for single vendor scenarios, the reason 
to introduce network level model, is to address multi-vendor interoperability 
issue since different vendor control can be deployed in various different 
domain, sometime it is IP domain, sometime it is optical domain.

Third, for service mapping, there are some other work to be developed in TEAS 
working group, e.g., 
https://datatracker.ietf.org/doc/draft-ietf-teas-te-service-mapping-yang/
https://datatracker.ietf.org/doc/draft-dhody-teas-ietf-network-slice-mapping/
They solve different jigsaw composing or decomposing. So you don’t need too 
much worry about the issue you raised.

Regarding How many "digital twins" every single network, I think you should 
more look into how to network topology model developed by IETF, e.g., Network 
Topology model
L3 Topology Model
L2 Topology model
DC Fabric Model
TE Topology model
L3 TE topology model., etc
To build digital twin model, I believe these topology related model are a good 
basis, in addition, you should get KPI data, Log Data, flow statistics data, 
Alarm data, other inventory related data, correlate them with topology data to 
build digital twin network, In IRTF NMRG, we have digital twin network 
architecture, try to build a whole picture, tackle key challenges to build 
digital twin network 
https://datatracker.ietf.org/doc/draft-irtf-nmrg-network-digital-twin-arch/
also there are many other digital twin related work in NMRG, which can be a 
good input to this architecture.
Hope this helps.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Vasilenko Eduard
发送时间: 2022年12月8日 2:42
收件人: Jan Lindblad 
抄送: opsawg@ietf.org; net...@ietf.org; Paolo Volpato ; 
Xipengxiao 
主题: Re: [netmod] How many "digital twins" every single network should have? Who 
would map between "twins"?

Hi Jan,
Thanks for you your answer.
Reading more I have found more evidence that the “digital network twin” should 
be single/unified for a network of any size:
- I did mention below OpenConfig that had merged configuration and operational 
data models many years ago,
- RFC8342 is asking for the same☺,
- RFC8969 is going a step further and asking to have the cross-layer 
convergence to the unified YANG model.
It looks obvious – all relationships are better to have in the single 
consistent YANG data storage.
It 

Re: [OPSAWG] [netmod] How many "digital twins" every single network should have? Who would map between "twins"?

[tom petch]

From: netmod  on behalf of Qin Wu 

Sent: 15 December 2022 08:07

Hi, Eduard:
Thank for bring this issue up, I think digital twins is more related to network 
topology model, network monitoring model rather than LxSM service delivery 
model or LxNM network model


I was going to ask for an explanation of a digital twin and then saw that it is 
a research topic of the IRSG about which consensus has not been achieved.  As 
such, I think it wrong for us to try and introduce it to YANG at this point in 
time

Tom Petch


First, As described in RFC8969 or RFC8309, LxSM service delivery model or LxNM 
network model focuses on service level abstraction and resource level 
abstraction respectively,  we expect Service level abstraction
Can be decomposed into network/resource level abstraction, and resource level 
abstraction to be translated into a bunches of device level models, but we 
don’t expect translation across level can be standardized in the same way.
Service mapping process, configuration translation process should play the key 
roles, this provide flexibility and meet requirements of various difference use 
cases.
Another reason is not to choose use augmentation of LxSM model is mapping 
service parameter into configuration parameters is not always 1 to 1 mapping, 
in many cases,it is N to M mapping, domain specific level controller needs to 
allocate additional resource level parameters. Therefore I feel augmentation is 
more suitable device level, but not suggested to be used in top down service 
mapping.
But To reduce the mapping,cost, What we consider in LxNM model design is to try 
to reuse many data type that are also applied to LxSM. Please refer to RFC9181

Secondly, I disagree LxNM is designed for single vendor scenarios, the reason 
to introduce network level model, is to address multi-vendor interoperability 
issue since different vendor control can be deployed in various different 
domain, sometime it is
IP domain, sometime it is optical domain.

Third, for service mapping, there are some other work to be developed in TEAS 
working group, e.g.,
https://datatracker.ietf.org/doc/draft-ietf-teas-te-service-mapping-yang/
https://datatracker.ietf.org/doc/draft-dhody-teas-ietf-network-slice-mapping/
They solve different jigsaw composing or decomposing. So you don’t need too 
much worry about the issue you raised.

Regarding How many "digital twins" every single network, I think you should 
more look into how to network topology model developed by IETF, e.g.,
Network Topology model
L3 Topology Model
L2 Topology model
DC Fabric Model
TE Topology model
L3 TE topology model., etc
To build digital twin model, I believe these topology related model are a good 
basis, in addition, you should get KPI data, Log Data, flow statistics data,
Alarm data, other inventory related data, correlate them with topology data to 
build digital twin network,
In IRTF NMRG, we have digital twin network architecture, try to build a whole 
picture, tackle key challenges to build digital twin network
https://datatracker.ietf.org/doc/draft-irtf-nmrg-network-digital-twin-arch/
also there are many other digital twin related work in NMRG, which can be a 
good input to this architecture.
Hope this helps.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Vasilenko Eduard
发送时间: 2022年12月8日 2:42
收件人: Jan Lindblad 
抄送: opsawg@ietf.org; net...@ietf.org; Paolo Volpato ; 
Xipengxiao 
主题: Re: [netmod] How many "digital twins" every single network should have? Who 
would map between "twins"?

Hi Jan,
Thanks for you your answer.
Reading more I have found more evidence that the “digital network twin” should 
be single/unified for a network of any size:
- I did mention below OpenConfig that had merged configuration and operational 
data models many years ago,
- RFC8342 is asking for the same☺,
- RFC8969 is going a step further and asking to have the cross-layer 
convergence to the unified YANG model.
It looks obvious – all relationships are better to have in the single 
consistent YANG data storage.
It is slowly happening in the IETF (examples above).

Yet RFC9182 has many disclaimers like:
“the L3NM is not defined as an augment to the L3SM, because a specific 
structure is required to meet network-oriented L3 needs”
“initial design was interpreted as if the deployment of the L3NM depends on the 
L3SM, while this is not the case”.
I see a couple of reasons for it:
- to minimize the disruption for many available implementations,
- to trade off unification and interoperability for functionality and 
flexibility.

After L3NM was disconnected from L3SM, many mapping between these models should 
be done in a proprietary way by coders.
Imagine that one product could map an event “A” in the L3NM to be related to 
the configuration XpathA in the L3SM,
But the different product would map an event “A” to be related to the 
configuration XpathB in the L3SM.
Then they would act inconsistently.
The other example could be when provisioning something in

Re: [OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-service-assurance-yang-10: (with DISCUSS and COMMENT)

[tom petch]

Bad practice for an uninvolved person to jump into an IESG discussion so 
dropping the IESG...

Picking up on Éric Vyncke's comment about hurting his 'SQL eyes', I am 
surprised it is only his eyes.  It hurts me too!  The use of one integer in an 
integer range to mean something semantically different is an abomination in 
data modelling.  Decades ago it was common practice because of deficiencies in 
modelling languages but YANG has no such deficiency and can specify a union, 
e.g. a boolean to say valid or invalid and a numeric to specify the value or a 
string to give more nuance to the validity or ...
This is what I see common practice in IETF YANG modules so the approach here 
may jar with implementors.

If you have IESG consensus on an approach, then I do not suggest changing it at 
this late stage but  since there are hurting SQL eyes I will look more 
aggressively for this in future and will quote this comment in my support.

Tom Petch 


From: OPSAWG  on behalf of Eric Vyncke (evyncke) 

Sent: 15 December 2022 07:12
To: Jean Quilbeuf; The IESG
Cc: draft-ietf-opsawg-service-assurance-y...@ietf.org; opsawg-cha...@ietf.org; 
opsawg@ietf.org; m...@sandelman.ca; tpa...@apple.com; mva...@cesnet.cz
Subject: Re: [OPSAWG]  Éric Vyncke's Discuss on 
draft-ietf-opsawg-service-assurance-yang-10: (with DISCUSS and COMMENT)

Bonjour Jean,

Thanks for your detailed reply. I agree with all the points in the email 
*including* the ones about the blocking DISCUSS, i.e., I will clear my DISCUSS 
ballot once a revised I-D is posted.

For additional discussion, look for EV> below.

Bien à toi

-éric


On 15/12/2022, 01:54, "iesg on behalf of Jean Quilbeuf" mailto:iesg-boun...@ietf.org> on behalf of 
jean.quilbeuf=40huawei@dmarc.ietf.org > 
wrote:


Hi Eric,
Thanks for your comment.


No new draft revision yet, but you’ll find below answers to discuss and 
comment, including modification that we plan to do.


Michal Vaško did the early YANG doctor review. Since there are modifications 
planned to the YANG module in this mail, I added him in Cc.


Best,
Jean
> -Original Message-
> From: Éric Vyncke via Datatracker [mailto:nore...@ietf.org 
> ]
> Sent: Tuesday 13 December 2022 08:13
> To: The IESG mailto:i...@ietf.org>>
> Cc: draft-ietf-opsawg-service-assurance-y...@ietf.org 
> ; opsawg-
> cha...@ietf.org ; opsawg@ietf.org 
> ; m...@sandelman.ca ; 
> m...@sandelman.ca ;
> tpa...@apple.com 
> Subject: Éric Vyncke's Discuss on draft-ietf-opsawg-service-assurance-yang-
> 10: (with DISCUSS and COMMENT)
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-opsawg-service-assurance-yang-10: Discuss
>
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot- 
> 
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/ 
> 
>
>
>
> --
> DISCUSS:
> --
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-service-assurance-
> yang-10
> CC @evyncke
>
> Thank you for the work put into this document. A very interesting piece of
> work
> and a well-written piece of text (even if I am balloting DISCUSS). The
> examples
> are also helping.
>
> Please find below some DISCUSS points (+ suggestions), some non-blocking
> COMMENT points (but replies would be appreciated even if only for my own
> education).
>
> Special thanks to Michael Richardson for the shepherd's detailed write-up
> including the WG consensus *but* it lacks the justification of the intended
> status. It would have been nice to list the implementations (even if I know
> one).
>
> Please note that Tommy Pauly is the Internet directorate reviewer (at my
> request) and you may want to consider this int-dir reviews as well when
> Tommy
> will complete the review (no need to wait for it though):
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance- 
> 
> yang/reviewrequest/16806/
>
> Also, thanks to the WG chairs and the responsible AD to bundle this I-D and
> its
> companion to the same IESG telechat: it hel

Re: [OPSAWG] Paul Wouters' No Objection on draft-ietf-opsawg-service-assurance-yang-10: (with COMMENT)

[Benoit Claise]

Hi Paul,

Thanks for your review.

On 12/15/2022 1:01 AM, Paul Wouters via Datatracker wrote:

Paul Wouters has entered the following ballot position for
draft-ietf-opsawg-service-assurance-yang-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/



--
COMMENT:
--

I have not much to add to my esteemed collegue's Éric::Vyncke/128 review, two
nits:

   | +--rw under-maintenance!
   | |  +--rw contactstring

This could use a freeform field or duration field to hold information about
expected maintenance time, as that would be the main question anyone could have
for the contact person :)

Yes.
OLD:

In that case, a "contact" MUST be provided to indicate who or which
   software is responsible for the maintenance.


NEW:
In that case, a "contact" freeform fileld MUST be provided to indicate who or 
which
   software is responsible for the maintenance. This field might even contain 
the expected maintenance time.

OLD:
leaf contact {
  type string;
  mandatory true;
  description
"A string used to model an administratively assigned name of
 the resource that is performing maintenance.

 It is suggested that this name contain one or more of the
 following: IP address, management station name,
 network manager's name, location, or phone number. In some
 cases the agent itself will be the owner of an entry. In
 these cases, this string shall be set to a string starting
 with 'monitor'.";
}

NEW:
leaf contact {
  type string;
  mandatory true;
  description
"A string used to model an administratively assigned name of
 the resource that is performing maintenance.

 It is suggested that this freeform field, which could be a URI,
 contains one or more of the
 following: IP address, management station name,
 network manager's name, location, or phone number.
 It might even contain the expected maintenance time.
 In some cases the agent itself will be the owner of an entry. In
 these cases, this string shall be set to a string starting
 with 'monitor'.";
}




   description
 "This module extends the ietf-service-assurance-device module to
  add specific support for devices of ACME Corporation. ";

I would somehow put in the Example word in there to avoid anyone thinking that
this is a real definition. I know it is stated before, but implementers just
scanning code might miss it :)

Sure.
NEW:

  description
"This example module extends the ietf-service-assurance-device module to
 add specific support for devices of ACME Corporation. ";


Thanks and regards, Benoit






___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-service-assurance-yang-10: (with DISCUSS and COMMENT)

[Eric Vyncke (evyncke)]

Thank you Michal

-éric

From: "mva...@cesnet.cz" 
Date: Thursday, 15 December 2022 at 08:42
To: Jean Quilbeuf , Eric Vyncke , 
The IESG , 
Cc: "draft-ietf-opsawg-service-assurance-y...@ietf.org" 
, "opsawg-cha...@ietf.org" 
, "opsawg@ietf.org" , 
"m...@sandelman.ca" , "tpa...@apple.com" 
Subject: Re: Éric Vyncke's Discuss on 
draft-ietf-opsawg-service-assurance-yang-10: (with DISCUSS and COMMENT)


Hi,

I have looked at the changes and they seem fine, I could not find any major 
problems except for the file revisions not matching the YANG revisions, for all 
the modules, so please remember to fix that when you do the next update.

file 
"ietf-service-assura...@2022-04-07.yang"

...

  revision 2022-08-10 {

description

  "Initial version.";

reference

  "RFC : YANG Modules for Service Assurance";

  }



Also, I have found some restrictions in descriptions of some nodes that can be 
expressed in YANG (were already in draft v6 but I have missed it then), but it 
is up to you to decide whether that makes sense or not. In general, it is 
always better because validating tools are then able to check the constraint 
automatically. The affected nodes are:

leaf assurance-graph-last-change (depends on last-change)

leaf health-score-weight (depends on health-score or rather the other way 
around)

leaf stop-date-time (depends on start-date-time)

Regarding the comments and proposed changes, I have nothing to add, all my 
potential comments have already been mentioned.

Regards,
Michal
On 15. 12. 2022 1:54, Jean Quilbeuf wrote:

Hi Eric,

Thanks for your comment.



No new draft revision yet, but you’ll find below answers to discuss and 
comment, including modification that we plan to do.



Michal Vaško  did the early YANG doctor review. Since there are modifications 
planned to the YANG module in this mail, I added him in Cc.



Best,

Jean

-Original Message-

From: Éric Vyncke via Datatracker [mailto:nore...@ietf.org]

Sent: Tuesday 13 December 2022 08:13

To: The IESG 

Cc: 
draft-ietf-opsawg-service-assurance-y...@ietf.org;
 opsawg-

cha...@ietf.org; 
opsawg@ietf.org; 
m...@sandelman.ca; 
m...@sandelman.ca;

tpa...@apple.com

Subject: Éric Vyncke's Discuss on draft-ietf-opsawg-service-assurance-yang-

10: (with DISCUSS and COMMENT)



Éric Vyncke has entered the following ballot position for

draft-ietf-opsawg-service-assurance-yang-10: Discuss



When responding, please keep the subject line intact and reply to all email

addresses included in the To and CC lines. (Feel free to cut this introductory

paragraph, however.)





Please refer to

https://www.ietf.org/about/groups/iesg/statements/handling-ballot-

positions/

for more information about how to handle DISCUSS and COMMENT

positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/







--

DISCUSS:

--





# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-service-assurance-

yang-10

CC @evyncke



Thank you for the work put into this document. A very interesting piece of

work

and a well-written piece of text (even if I am balloting DISCUSS). The

examples

are also helping.



Please find below some DISCUSS points (+ suggestions), some non-blocking

COMMENT points (but replies would be appreciated even if only for my own

education).



Special thanks to Michael Richardson for the shepherd's detailed write-up

including the WG consensus *but* it lacks the justification of the intended

status. It would have been nice to list the implementations (even if I know

one).



Please note that Tommy Pauly is the Internet directorate reviewer (at my

request) and you may want to consider this int-dir reviews as well when

Tommy

will complete the review (no need to wait for it though):

https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-

yang/reviewrequest/16806/



Also, thanks to the WG chairs and the responsible AD to bundle this I-D and

its

companion to the same IESG telechat: it helps a lot!



I hope that this review helps to improve the document,



Regards,



-éric



## DISCUSS



As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a

DISCUSS ballot is a request to have a discussion on the following topics:



### BCP14 template



As noted by

https://author-

tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-

opsawg-service-assurance-yang-10.txt

and Lars, the BCP14 template is not correct even if it is required for a

proposed standard (it mentions BCP13 ;-) ).

[OPSAWG] Murray Kucherawy's Discuss on draft-ietf-opsawg-service-assurance-yang-10: (with DISCUSS and COMMENT)

[Murray Kucherawy via Datatracker]

Murray Kucherawy has entered the following ballot position for
draft-ietf-opsawg-service-assurance-yang-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/



--
DISCUSS:
--

We can probably sort this out during the IESG telechat, but I want to be sure
it's flagged.

A number of the shepherd writeup questions were hastily answered and the
information we need is largely missing.  For instance:

--
> What type of RFC publication is being requested on the IETF stream (Best
> Current Practice, Proposed Standard, Internet Standard,
> Informational, Experimental or Historic)? Why is this the proper type
> of RFC? Do all Datatracker state attributes correctly reflect this intent?

yes.
--

There are three questions here, and only the last of them can be answered
"yes".  The second one is the most interesting one.

--
> Several IETF Areas have assembled lists of common issues that their
> reviewers encounter. For which areas have such issues been identified
> and addressed? For which does this still need to happen in subsequent
> reviews?

no.
--

I don't understand.

--
> Have reasonable efforts been made to remind all authors of the intellectual
> property rights (IPR) disclosure obligations described in BCP 79? To
> the best of your knowledge, have all required disclosures been filed? If
> not, explain why. If yes, summarize any relevant discussion, including links
> to publicly-available messages when applicable.

yes.
--

So something's been filed, or reasonable reminders were sent?  The datatracker
appears to imply this must mean the latter, but it would be great to be clear.


--
COMMENT:
--

I support Eric's DISCUSS position.  In particular, please fix the BCP 14
boilerplate.  BCP 13 is MIME registration procedures.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [netmod] How many "digital twins" every single network should have? Who would map between "twins"?

[Qin Wu]

Hi, Eduard:
Thank for bring this issue up, I think digital twins is more related to network 
topology model, network monitoring model rather than LxSM service delivery 
model or LxNM network model

First, As described in RFC8969 or RFC8309, LxSM service delivery model or LxNM 
network model focuses on service level abstraction and resource level 
abstraction respectively,  we expect Service level abstraction
Can be decomposed into network/resource level abstraction, and resource level 
abstraction to be translated into a bunches of device level models, but we 
don’t expect translation across level can be standardized in the same way.
Service mapping process, configuration translation process should play the key 
roles, this provide flexibility and meet requirements of various difference use 
cases.
Another reason is not to choose use augmentation of LxSM model is mapping 
service parameter into configuration parameters is not always 1 to 1 mapping, 
in many cases,it is N to M mapping, domain specific level controller needs to 
allocate additional resource level parameters. Therefore I feel augmentation is 
more suitable device level, but not suggested to be used in top down service 
mapping.
But To reduce the mapping,cost, What we consider in LxNM model design is to try 
to reuse many data type that are also applied to LxSM. Please refer to RFC9181

Secondly, I disagree LxNM is designed for single vendor scenarios, the reason 
to introduce network level model, is to address multi-vendor interoperability 
issue since different vendor control can be deployed in various different 
domain, sometime it is
IP domain, sometime it is optical domain.

Third, for service mapping, there are some other work to be developed in TEAS 
working group, e.g.,
https://datatracker.ietf.org/doc/draft-ietf-teas-te-service-mapping-yang/
https://datatracker.ietf.org/doc/draft-dhody-teas-ietf-network-slice-mapping/
They solve different jigsaw composing or decomposing. So you don’t need too 
much worry about the issue you raised.

Regarding How many "digital twins" every single network, I think you should 
more look into how to network topology model developed by IETF, e.g.,
Network Topology model
L3 Topology Model
L2 Topology model
DC Fabric Model
TE Topology model
L3 TE topology model., etc
To build digital twin model, I believe these topology related model are a good 
basis, in addition, you should get KPI data, Log Data, flow statistics data,
Alarm data, other inventory related data, correlate them with topology data to 
build digital twin network,
In IRTF NMRG, we have digital twin network architecture, try to build a whole 
picture, tackle key challenges to build digital twin network
https://datatracker.ietf.org/doc/draft-irtf-nmrg-network-digital-twin-arch/
also there are many other digital twin related work in NMRG, which can be a 
good input to this architecture.
Hope this helps.

-Qin
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Vasilenko Eduard
发送时间: 2022年12月8日 2:42
收件人: Jan Lindblad 
抄送: opsawg@ietf.org; net...@ietf.org; Paolo Volpato ; 
Xipengxiao 
主题: Re: [netmod] How many "digital twins" every single network should have? Who 
would map between "twins"?

Hi Jan,
Thanks for you your answer.
Reading more I have found more evidence that the “digital network twin” should 
be single/unified for a network of any size:
- I did mention below OpenConfig that had merged configuration and operational 
data models many years ago,
- RFC8342 is asking for the same☺,
- RFC8969 is going a step further and asking to have the cross-layer 
convergence to the unified YANG model.
It looks obvious – all relationships are better to have in the single 
consistent YANG data storage.
It is slowly happening in the IETF (examples above).

Yet RFC9182 has many disclaimers like:
“the L3NM is not defined as an augment to the L3SM, because a specific 
structure is required to meet network-oriented L3 needs”
“initial design was interpreted as if the deployment of the L3NM depends on the 
L3SM, while this is not the case”.
I see a couple of reasons for it:
- to minimize the disruption for many available implementations,
- to trade off unification and interoperability for functionality and 
flexibility.

After L3NM was disconnected from L3SM, many mapping between these models should 
be done in a proprietary way by coders.
Imagine that one product could map an event “A” in the L3NM to be related to 
the configuration XpathA in the L3SM,
But the different product would map an event “A” to be related to the 
configuration XpathB in the L3SM.
Then they would act inconsistently.
The other example could be when provisioning something in L3SM would be mapped 
to different Xpath in L3NM by different products.
It is again a problem if L3NMs from different vendors should support the same 
VPN.

If humans (with really the best knowledge and intelligence in respective IETF 
WGs) were not capable of automatically mapping L3SM to L3NM,
Then no hope that the algor