Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

[Italo Busi]

Qin, Joe,

A couple of comments of mine in line

Thanks, Italo

From: Qin Wu 
Sent: domenica 18 febbraio 2024 03:13
To: Joe Clarke (jclarke) ; Henk Birkholz 
; OPSAWG ; n...@ietf.org
Subject: Re: [OPSAWG]  WG Adoption Call for 
draft-feng-opsawg-incident-management-04

Hi, Joe:
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke)
发送时间: 2024年2月16日 21:15
收件人: Henk Birkholz 
mailto:henk.birkholz@ietf.contact>>; OPSAWG 
mailto:opsawg@ietf.org>>
主题: Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

=== As a contributor ===

I struggle to see why the IETF should be working on this.  Clearly there are 
other SDOs that work in the area of incident management.  This draft refers to 
a [IMHO tenuous] reference to a TM Forum API spec (which I cannot read as I am 
not a member), but ITIL has similar definitions of incidents and problems.  
There does not seem to be any liaison or indication of a close relationship 
with these other SDOs to help drive consistent use of terminology and help 
their members achieve desired goals.

[Qin Wu]
Thanks Joe for valuable input and comments, see my clarification in the 
presentation in IETF 116 
(https://datatracker.ietf.org/meeting/116/materials/slides-116-opsawg-incident-management-for-network-service-00.pdf),
 which I clarify the relationship
with TMF API spec, as you can see what draft-feng proposes to do is to define 
YANG model for incident lifecycle management, complementary to TMF API profile 
which focus on requirements, function, component capability. Talking with TMF 
API profile authors in TMF, they are happy to have this work land on IETF since 
IETF has more YANG model work expertise.

Secondly, the definition of network incidents and problems in TMF API spec is 
sourced from ITIL. ITIL is an internationally recognized and widespread 
de-facto standard for IT services management, not **developed by any other 
SDOs**, the idea of the definition of network incident and problem in TMF API 
spec is to introduce incident concept originally applied to IT field to 
**operator's network field**, which require support not only from domain 
controllers but also OSS. The typical scenario not only applied to optical 
scenario but also applied to IP network scenario.
Therefore in my opinion, alignment with TMF specification by quoting TMF 
network incident definition is sufficient, note that TMF specification has 
already been published by TMF. if you think necessary, I can consult with TMF 
specification authors for clarification.

[Italo Busi] IMHO, after this document is adopted as WG item, we can send a LS 
to TMF to get their feedbacks to make it sure the work is fully complementary 
to their work

Even in this first pass, I see what I feel is a mix of terminology.  You have 
an enumeration on leaf type where “fault” reads as the type of incident being a 
fault.  To me, this is the type of problem (i.e., the cause of the incident).  
The incident type might be an SLA violation.

[Qin Wu] I believe this is naming confusion issue, according to network 
incident definition, the incident type can be unexpected interruption of the 
network service, or degradation of the network service, in the current design, 
we use fault and potential risk, if this is not clear, we can use better term 
as you suggested. Thanks.
Also as you can see, Nigel and Adrian have started a new draft on incident 
management terminology based on action point taken in IETF 118 side meeting on 
incident management, which can also help produce better terminology for this 
work.

[Italo Busi] This looks like an issue which can be addressed through normal WG 
process after adoption.

I do not feel this work should be adopted by the IETF in its current form.

[Qin Wu] I am thinking change the title into "A YANG Data Model for Network 
Incident management", which will focus on network level model, in the same 
level as L3NM, L2NM and Attachment Circuit.
[Italo Busi] Sounds reasonable to me
Joe

From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
behalf of Henk Birkholz 
mailto:henk.birkholz@ietf.contact>>
Date: Thursday, February 8, 2024 at 10:44
To: OPSAWG mailto:opsawg@ietf.org>>
Subject: [OPSAWG]  WG Adoption Call for 
draft-feng-opsawg-incident-management-04
Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-feng-opsawg-incident-management-04.html

ending on Thursday, February 22nd.

As a reminder, this I-D specifies a YANG Module for Incident Management.
Incidents in this context are scoped to unexpected yet quantifiable
adverse effects detected in a network service. The majority of the
document provides background and motivation for the structure of the
YANG Module that is in support of reporting, diagnosing, and mitigating
the detected adverse effects.

The chairs acknowledge some positive feedback on the list and a positive
poll result at IETF118. W

Re: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-management-04

[Italo Busi]

I support the adoption of this document

Italo

> -Original Message-
> From: Henk Birkholz 
> Sent: giovedì 8 febbraio 2024 16:44
> To: OPSAWG 
> Subject: [OPSAWG]  WG Adoption Call for draft-feng-opsawg-incident-
> management-04
> 
> Dear OPSAWG members,
> 
> this email starts a call for Working Group Adoption of
> 
> > https://www.ietf.org/archive/id/draft-feng-opsawg-incident-management-
> > 04.html
> 
> ending on Thursday, February 22nd.
> 
> As a reminder, this I-D specifies a YANG Module for Incident Management.
> Incidents in this context are scoped to unexpected yet quantifiable adverse
> effects detected in a network service. The majority of the document provides
> background and motivation for the structure of the YANG Module that is in
> support of reporting, diagnosing, and mitigating the detected adverse effects.
> 
> The chairs acknowledge some positive feedback on the list and a positive
> poll result at IETF118. We would like to gather feedback from the WG if
> there is interest to further contribute and review.
> 
> Please reply with your support and especially any substantive comments you
> may have.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 

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

Re: [OPSAWG] Is out-of-band OAM relevant? (Was: IOAM, iOAM, and oOAM abbreviations)

[Italo Busi]

Hi Sasha,

IMHO, LSP ping and BFD are examples of in-band OAM which may have either an 
in-band or an out-of-band return path (upstream OAM from the terminology below)

An example of out-of-band OAM can be the RSVP-TE notification messages. There 
are other examples of out-of-band OAM mechanisms in the WDM network but I am 
not sure whether they are or not in the scope of this thread.

In a nutshell:

  *   I think it is useful to distinguish between in-band and out-of-band OAM 
in the definition
  *   The definition for upstream OAM is incomplete since there are examples 
where the upstream OAM can be sent in-band

My 2 cents

Italo

From: Alexander Vainshtein 
Sent: domenica 17 dicembre 2023 07:33
To: adr...@olddog.co.uk; xiong.q...@zte.com.cn; gregimir...@gmail.com
Cc: m...@ietf.org; i...@ietf.org; i...@ietf.org; pascal.thub...@gmail.com; 
opsawg@ietf.org; det...@ietf.org
Subject: Re: [OPSAWG] Is out-of-band OAM relevant? (Was: IOAM, iOAM, and oOAM 
abbreviations)

Hi all,
My previous message inadvertently have been sent before completion.

Please see the completed text now.

Regards,
Sasha

Get Outlook for Android


From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Sent: Sunday, December 17, 2023 8:29:11 AM
To: adr...@olddog.co.uk 
mailto:adr...@olddog.co.uk>>; 
xiong.q...@zte.com.cn 
mailto:xiong.q...@zte.com.cn>>; 
gregimir...@gmail.com 
mailto:gregimir...@gmail.com>>
Cc: m...@ietf.org mailto:m...@ietf.org>>; 
i...@ietf.org mailto:i...@ietf.org>>; 
i...@ietf.org mailto:i...@ietf.org>>; 
pascal.thub...@gmail.com 
mailto:pascal.thub...@gmail.com>>; 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>; 
det...@ietf.org 
mailto:det...@ietf.org>>
Subject: Is out-of-band OAM relevant? (Was: IOAM, iOAM, and oOAM abbreviations)

Hi all,
For me this thread triggered a presumably naive question reflected in the 
changed subject line:

Why is out-of-band OAM useful or relevant?

I have looked the definition of out-if-band OAM in Section 2.6.3 of the RAW 
Architecture draft, and it says:



Out-of-band OAM is an active OAM whose path is not topologically congruent to 
the Track, or its test packets receive a QoS and/or PAREO treatment that is 
different from that of the packets of the data flows that are injected in the 
Track, or both.


There is only one reference to this definition in Section 2.6.5 "Upstream OAM" 
of the draft that says:



An upstream OAM packet is an Out-of-Band OAM packet that traverses the Track 
from egress to ingress on the reverse direction, to capture and report OAM 
measurements upstream. The collection may capture all information along the 
whole Track, or it may only learn select data across all, or only a particular 
DetNet Path, or Segment of a Track.


Of course, this is quite useful and quite common (Ping, LSP Ping and Seamless 
BFD are three examples that come first to my mind.

But I seriously doubt this common mechanism deserves a special term, and an 
abbreviation for this term looks quite unnecessary.

Regards,
Sasha

Get Outlook for Android


From: mpls mailto:mpls-boun...@ietf.org>> on behalf of 
Adrian Farrel mailto:adr...@olddog.co.uk>>
Sent: Saturday, December 16, 2023 12:18:32 PM
To: xiong.q...@zte.com.cn 
mailto:xiong.q...@zte.com.cn>>; 
gregimir...@gmail.com 
mailto:gregimir...@gmail.com>>
Cc: m...@ietf.org mailto:m...@ietf.org>>; 
i...@ietf.org mailto:i...@ietf.org>>; 
i...@ietf.org mailto:i...@ietf.org>>; 
pascal.thub...@gmail.com 
mailto:pascal.thub...@gmail.com>>; 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>; 
det...@ietf.org 
mailto:det...@ietf.org>>
Subject: [EXTERNAL] Re: [mpls] [Detnet] IOAM, iOAM, and oOAM abbreviations



I suppose that I don’t object to the definition of new abbreviations if people 
are keen.

Personally, I don’t get the value of “inb-OAM” compared with “in-band OAM”. 
It’s not like it can be said faster (one additional syllable to say it) and it 
only saves four characters in typing.
“oob-OAM” is also marginal. Same number of syllables to say (I don’t think 
anyone pronounces “oob” as a single syllable), and a little more saving in 
typing.

Are the abbreviations worth it for the loss of clarity resulting from not using 
real words?

Cheers,
Adrian

From: mpls mailto:mpls-boun...@ietf.org>> On Behalf Of 
xiong.q...@zte.com.cn
Sent: 14 December 2023 02:56
To: gregimir...@gmail.com
Cc: m...@ietf.org; 

Re: [OPSAWG] [mpls] IOAM, iOAM, and oOAM abbreviations

[Italo Busi]

Loa, Greg,

I am not sure we really need abbreviations for in-band and out-of-band OAM 
since we have lived without these abbreviations for quite a long time. However, 
it does not harm to define those acronyms

While OOB is quite commonly used as an abbreviation for out-of-band, I do not 
recall to have ever seen an abbreviation for in-band ☹

My suggestion would be to use IB for in-band to have a consistent rule with the 
OOB acronym (i.e. ib-OAM and oob-OAM)

My 2 cents

Italo

From: Greg Mirsky 
Sent: mercoledì 13 dicembre 2023 04:13
To: DetNet WG ; mpls ; 6man WG ; 
IETF IPPM WG ; opsawg ; Pascal Thubert 
; Loa Andersson 
Subject: [mpls] IOAM, iOAM, and oOAM abbreviations

Dear All,
Loa and I have discussed these abbreviations to help us find a solution that 
avoids the confusion we found when we came across them. Firstly, what they 
stand for:

  *   IOAM - In-situ OAM (RFC 9197)
  *   iOAM - in-band OAM (RAW 
architecture)
  *   oOAM - out-of-band OAM (RAW 
architecture)
We discussed the issue with Pascal and came to slightly different abbreviations 
for the last two:

  *   inb-OAM
  *   oob-OAM
We also discord these abbreviations with the RFC Editor. Resulting from that, 
RFC Editor agreed to add IOAM to the RFC Editor Abbreviation 
List. The other two 
abbreviations cannot be added at this time. If that is needed, we can ask the 
RFC Editor to add them once the respective RFC is published.
We are seeking your feedback on the following:

  *   Do you see the benefit of introducing two new abbreviations for in-band 
OAM and out-of-band OAM?
  *   Which set of abbreviations (iOAM/oOAM vs. inb-OAM/oob-OAM) do you prefer 
for being used in IETF?
  *   Or would you propose another set of abbreviations?
Regards,
Loa and Greg

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

Re: [OPSAWG] [Inventory-yang] [CCAMP] [inventory-yang] poll for network inventory base model

[Italo Busi]

Daniele & Qiufang,

I would like to request a slot to discuss the technical issues that need to be 
addressed to evolve draft-ietf-ccamp-network-inventory-yang-02 to become the 
network inventory base model, including how the overall network inventory model 
can be modularized

If there is enough available time on the agenda, I would prefer to take a 20 
min slot, otherwise I can live with the 10min slot duration 

Thanks, Italo

From: Inventory-yang  On Behalf Of Daniele 
Ceccarelli
Sent: venerdì 15 settembre 2023 10:45
To: maqiufang (A) 
Cc: inventory-y...@ietf.org; ivy-cha...@ietf.org; opsawg ; 
cc...@ietf.org
Subject: Re: [Inventory-yang] [CCAMP] [inventory-yang] poll for network 
inventory base model

Hi working group,

Thanks a lot for all the useful comments on the different drafts.
There seems to be a split of preferences between option 1 and option 3. Given 
that the interinm meeting is soon (next week), we suggest to use it to further 
discuss suggestions and concerns from the working group and defer the decision 
by 1 week (Sep 22nd) immediately after the interim meeting.

In order to have a fruitful discussion at the interim meeting please consider 
the following inputs:


  *   Italo made a very good proposal on the split between HW only and HW+SW 
use cases. Is this something we want to pursue? Do you think it makes sense to 
start focusing on e.g. HW and then add SW on top of it?
  *   When asking to adopt one draft or the other we were asking (as per IETF 
process) which you consider to be a good starting point for the working group 
to work on, not something that is ready for publication. This means that 
whatever draft we decide to adopt, we can significantly update it to properly 
cover all the different aspects of invently. With this regard Alex did a very 
good analysis in his mail. Maybe we don't need to make an hard choice between 
the draft but take the best of each. For example: we can take 30% of one draft 
and 20% of the other and build a new one as per option 3, if on the other side 
we decide to take 80% from one draft, then it makes more sense to start from it 
and build on top of that.
  *   Another good point touched by Alex is the "equipment-room". We are 
supposed to cover also sites and location of the inventory. Are these things 
connected? it seems so. If the WG prefers not to address this in the core model 
and add it on top, that fine, otherwise we would suggest to have sites and 
location added (whetehr in che core model or added on top can be discussed).
Again we have a good proposal from Alex on the way forward, which is:


"For example, one could start with draft-ietf-ccamp-network-inventory-yang, 
modifying it to remove the network-hardware-inventory container and splitting 
the remaining module in two (for equipment-room and network-elements, both of 
which will now be top-level containers).  Remaining modifications can be made 
from there.  I guess this makes me a proponent of option 3, but with the caveat 
that this would not need to restart from scratch - really an option 4 that says 
merge (for overall structure and common parts, which in this case is possible) 
and split the remaining difference."
We don't really care whether this is called option 1, 3 or 4 but seems to be 
the most meaningful one...which is: use ccamp draft as a starting point, 
implementing the modifications suggested by Alex and then incorporate the 
material from the opsawg draft.

Given this deferral of the polling decision, if anyone else wants to ask for a 
10 mins slot at the interim, please do so now. We will put together the agenda 
on Monday.

Thanks you everyone
Daniele & Qiufang


On Mon, Aug 28, 2023 at 8:22 AM maqiufang (A) 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi Working Group,

It’s now time to start considering how to move forward with the inventory base 
model. We have two different documents that could be used as a starting point 
for our work or, in case the working group believes none of them is “good 
enough”, we can start a brand new ID.
In case the latter option is chosen, Daniele and I will write a -00 version 
including just the table of content and what we’d like to be covered in each 
section. The document will then be handed over to a pool of authors which will 
bring it till the WG adoption.

Hence, we will have a 3 weeks polling starting today. We decided to make it a 
bit longer than usual because this time the working group is requested to 
review two drafts instead of one.

This mail starts a 3 weeks polling, terminating on September 15th,  where we 
would like the working group to express your preference among:


  1.  Adopt  draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it to 
become the network inventory base model
  2.  Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and evolve 
it to become the network inventory base model
  3.  Start a brand new document from scratch as described above

In the week after the 

Re: [OPSAWG] [inventory-yang] poll for network inventory base model

[Italo Busi]

My preference is option 1 to adopt draft-ietf-ccamp-network-inventory-yang-02 
in IVY and evolve it to become the network inventory base model

I understand this draft does not cover all the items in the WG charter but IMHO 
there is no need  to  cover  all  the  IVY WG charter  items  into  a  single  
draft  nor  into  a  single  YANG model. Experience usually shows that modular 
and incremental (step-by-step) approaches work better with complex scenarios as 
those we are trying to address in the IVY WG

In this case, considering only HW and SW inventory requirements, I have noted 
that two different set of UCs have been discussed:

  *   UCs  where  only  HW  inventory  is  required;
  *   UCs where both  HW  and  SW  inventory  is  required

A modular approach defining a  base  model  that  covers  the  common  
requirements  (i.e.,  HW inventory)  and  one  or more  augmentation  models  
that  covers  optional  additional  requirements  (e.g.,  SW inventory)  would 
better address these different set of UCs

Moreover, requirements  and  solutions  for  HW inventory  are  more  mature  
(based  on existing standards, like RFC8348  and  TMF, and proven by many years 
of real network deployments)  than  emerging  requirements  and  solutions  for 
 virtualization,  SW and  licenses  inventory

The proposed model split would allow both HW and SW inventory to progress in 
parallel and to reach RFC publication as quickly as possible

IMHO, evolving draft-ietf-ccamp-network-inventory-yang-02 to become the network 
inventory base model would imply also providing the required technical changes 
to support other model augmentations that cover additional requirements (e.g., 
SW inventory). The technical details for these changes can be discussed in the 
interim WG meeting or even offline before/after the interim meeting

Italo

From: Inventory-yang  On Behalf Of maqiufang 
(A)
Sent: lunedì 28 agosto 2023 08:22
To: inventory-y...@ietf.org
Cc: ivy-cha...@ietf.org; opsawg ; cc...@ietf.org
Subject: [Inventory-yang] [inventory-yang] poll for network inventory base model

Hi Working Group,

It's now time to start considering how to move forward with the inventory base 
model. We have two different documents that could be used as a starting point 
for our work or, in case the working group believes none of them is "good 
enough", we can start a brand new ID.
In case the latter option is chosen, Daniele and I will write a -00 version 
including just the table of content and what we'd like to be covered in each 
section. The document will then be handed over to a pool of authors which will 
bring it till the WG adoption.

Hence, we will have a 3 weeks polling starting today. We decided to make it a 
bit longer than usual because this time the working group is requested to 
review two drafts instead of one.

This mail starts a 3 weeks polling, terminating on September 15th,  where we 
would like the working group to express your preference among:


  1.  Adopt  draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it to 
become the network inventory base model
  2.  Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and evolve 
it to become the network inventory base model
  3.  Start a brand new document from scratch as described above

In the week after the closure of the polling (between September 18 and 25) we 
will have an IVY interim meeting to discuss the issues/concerns raised during 
the polling ( A separate mail will be sent).

Thank you,

Qiufang and Daniele

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

Re: [OPSAWG] New Version Notification for draft-wzwb-opsawg-network-inventory-management-01.txt

[Italo Busi]

Hi Bo,

Regarding re-using RFC8345 for the mapping between physical (inventory) and 
abstract (network topology) resources, I can see your point for the navigation 
between the physical NEs (within the inventory) and the abstract nodes (within 
network topologies). However, I am not sure you can get more than this.

You still need specific attributes to navigate between the physical ports 
(components within the inventory) and the abstract termination points (within 
network topologies).

Moreover, I have noted that the model augments the network-topology model 
defined in RFC8345. However, according to RFC8345, the inventory model was 
intended to augment only the network model and not the network-topology model. 
This makes sense to me also because the physical links terminates on the 
physical ports (components within the inventory) and not on termination points.

See for example the discussion in 
https://github.com/italobusi/ietf-network-inventory/issues/33

My 2 cents

Thanks, Italo

> -Original Message-
> From: Inventory-yang  On Behalf Of Wubo
> (lana)
> Sent: giovedì 16 febbraio 2023 11:01
> To: opsawg@ietf.org; inventory-y...@ietf.org
> Subject: Re: [Inventory-yang] New Version Notification for draft-wzwb-
> opsawg-network-inventory-management-01.txt
> 
> Dear Opsawg, inventory colleges,
> 
> Based on the review comments from Marisol and authors of draft-ietf-ccamp-
> network-inventory-yang, we update the network inventory draft.
> 
> Compared with the network hardware inventory in CCAMP, this model has
> following consideration:
> 1) Augment RFC 8345, so that the logical L2 or L3 or TE network topology can
> have mapping association with underlying physical infrastructure inventory.
> Therefore, a new " network-inventory" network type has been defined.
> 2) More device and device component types are supported, such as device
> software component, virtual network devices and network endpoint devices.
> 
> Regarding licenses (or entitlements in draft-palmero-opsawg-dmlmo-09),
> some licenses may affect the functions of physical components or software
> components, though having removed from the current model, but we feel
> further discussion is needed.
> 
> Thanks,
> Bo
> 
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Friday, February 10, 2023 7:04 PM
> To: Wubo (lana) ; Cheng Zhou
> ; Mohamed Boucadair
> ; Qin Wu ; Qin
> Wu 
> Subject: New Version Notification for draft-wzwb-opsawg-network-inventory-
> management-01.txt
> 
> 
> A new version of I-D, draft-wzwb-opsawg-network-inventory-management-
> 01.txt
> has been successfully submitted by Bo Wu and posted to the IETF repository.
> 
> Name: draft-wzwb-opsawg-network-inventory-management
> Revision: 01
> Title:An Inventory Management Model for Enterprise Networks
> Document date:2023-02-10
> Group:Individual Submission
> Pages:28
> URL:https://www.ietf.org/archive/id/draft-wzwb-opsawg-network-
> inventory-management-01.txt
> Status: https://datatracker.ietf.org/doc/draft-wzwb-opsawg-network-
> inventory-management/
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-wzwb-opsawg-
> network-inventory-management
> Diff:   https://author-tools.ietf.org/iddiff?url2=draft-wzwb-opsawg-
> network-inventory-management-01
> 
> Abstract:
>This document defines a YANG model for network inventory management,
>which provides consistent representation and reporting of network
>nodes (including endpoints) inventory and enable a network
>orchestrator in the enterprise network to maintain a centralized view
>of all the endpoint types across multiple domains of the underlying
>network to implement a coherent control strategy.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> --
> Inventory-yang mailing list
> inventory-y...@ietf.org
> https://www.ietf.org/mailman/listinfo/inventory-yang

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

Re: [OPSAWG] IPR CALL: draft-ietf-opsawg-vpn-common

[Italo Busi]

Hi OPSAWG,

no, I am not aware of any IPR that applies to this draft

Italo

> -Original Message-
> From: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
> Sent: lunedì 22 marzo 2021 14:33
> To: opsawg@ietf.org
> Subject: [OPSAWG] IPR CALL: draft-ietf-opsawg-vpn-common
> 
> Authors, contributors, and WG members, as we are in WGLC for this
> document, we want to solicit knowledge of any IPR that may pertain to the
> draft-ietf-opsawg-vpn-common work.
> 
> Please state either, "no, I am not aware of any IPR that applies to this 
> draft" or,
> "yes, I am aware of IPR that applies this draft".
> 
> If there is IPR, it must be disclosed in compliance with IETF IPR rules 
> (i.e., RFCs
> 3669, 5378, and 8179).  Please indicate if this has been done.
> 
> If you have any additional details, please share those as well.
> 
> If you are an author or contributor, you must reply to indicate IPR status.
> 
> Joe
> 
> 

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

Re: [OPSAWG] TE Topology profile (FW: I-D Action: draft-busi-teas-te-topology-profiles-01.txt)

[Italo Busi]

Daniele,

Many thanks for your comments: you have actually got the main motivation that 
has triggered this work

I am fine with your proposed new title

Any other opinions/suggestions from the WGs?

Thanks, Italo

> -Original Message-
> From: Daniele Ceccarelli [mailto:daniele.ceccare...@ericsson.com]
> Sent: martedì 23 febbraio 2021 15:51
> To: Italo Busi ; TEAS WG ; CCAMP
> ; opsawg 
> Subject: RE: TE Topology profile (FW: I-D Action: draft-busi-teas-te-topology-
> profiles-01.txt)
> 
> Hi Italo, authors,
> 
> I thinks this draft is extremely useful.
> 
> There are at least two reasons that come to my mind:
> 
> 1. Many times i heard concerns about the complexity of the TE topology
> model. It's true, it's a complex model, but it's possible to create profiles 
> out of
> it and make it as simple as it is needed in a particular use case.
> 2. Another common objection is due to the fact that people are reluctant to
> use the TE topology for non TE use cases. We needed to have written
> somewhere that the TE topology, in addition to dealing with TE aspects, is 
> also
> covering some network topology aspects there were left outside the scope of
> RFC8345.
> 
> Probably one solution would have been to rename the TE topology into
> "augmented topology" and specify that 90% of those augmentations where
> related to TE (to show that it was not 100% TE)...but this draft could work 
> just
> fine.
> 
> Maybe just a minor comment on the title, it could try to cover both of the
> bullets above and be changed into something like: " Profiles for TE Topology
> Data Model and applicability to non TE use cases" . It can be improved...
> 
> Thanks
> Daniele
> 
> 
> -Original Message-
> From: CCAMP  On Behalf Of Italo Busi
> Sent: den 22 februari 2021 12:29
> To: TEAS WG ; CCAMP ; opsawg
> 
> Subject: [CCAMP] TE Topology profile (FW: I-D Action: draft-busi-teas-te-
> topology-profiles-01.txt)
> 
> Dear TEAS, CCAMP, OPSAWG,
> 
> We would like to draw you attention to the following draft that we think it
> may be relevant for some on-going work on your WGs to address network
> scenarios being that are not classified as "Traffic Engineering" using a 
> sub-set
> (profile) of the Traffic Engineering (TE) Topology YANG data model, defined in
> [RFC8795].
> 
> We would appreciate any feedbacks on this document.
> 
> The draft has been submitted to the TEAS WG which has been responsible for
> the development of RFC8795 so we would appreciate if you can send your
> comments at least to the TEAS WG mailing list.
> 
> Italo (on behalf of co-authors)
> 
> > -Original Message-
> > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> > Sent: sabato 20 febbraio 2021 00:21
> > To: i-d-annou...@ietf.org
> > Subject: I-D Action: draft-busi-teas-te-topology-profiles-01.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> >
> >
> > Title   : Profiles for Traffic Engineering (TE) Topology 
> > Data Model
> > Authors : Italo Busi
> >   Xufeng Liu
> >   Igor Bryskin
> >   Vishnu Pavan Beeram
> >   Tarek Saad
> >   Oscar Gonzalez de Dios
> > Filename: draft-busi-teas-te-topology-profiles-01.txt
> > Pages   : 16
> > Date: 2021-02-19
> >
> > Abstract:
> >This document describes how profiles of the Traffic Engineering (TE)
> >Topology Model, defined in RFC8795, can be used to address
> >applications beyond "Traffic Engineering".
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-busi-teas-te-topology-profiles/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-busi-teas-te-topology-profiles-01
> > https://datatracker.ietf.org/doc/html/draft-busi-teas-te-topology-prof
> > iles-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-busi-teas-te-topology-profiles
> > -01
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at 
> > tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> 
> ___
> CCAMP mailing list
> cc...@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

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

[OPSAWG] TE Topology profile (FW: I-D Action: draft-busi-teas-te-topology-profiles-01.txt)

[Italo Busi]

Dear TEAS, CCAMP, OPSAWG,

We would like to draw you attention to the following draft that we think it may 
be relevant for some on-going work on your WGs to address network scenarios 
being that are not classified as "Traffic Engineering" using a sub-set 
(profile) of the Traffic Engineering (TE) Topology YANG data model, defined in 
[RFC8795].

We would appreciate any feedbacks on this document.

The draft has been submitted to the TEAS WG which has been responsible for the 
development of RFC8795 so we would appreciate if you can send your comments at 
least to the TEAS WG mailing list.

Italo (on behalf of co-authors)

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: sabato 20 febbraio 2021 00:21
> To: i-d-annou...@ietf.org
> Subject: I-D Action: draft-busi-teas-te-topology-profiles-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title   : Profiles for Traffic Engineering (TE) Topology Data 
> Model
> Authors : Italo Busi
>   Xufeng Liu
>   Igor Bryskin
>   Vishnu Pavan Beeram
>   Tarek Saad
>   Oscar Gonzalez de Dios
>   Filename: draft-busi-teas-te-topology-profiles-01.txt
>   Pages   : 16
>   Date: 2021-02-19
> 
> Abstract:
>This document describes how profiles of the Traffic Engineering (TE)
>Topology Model, defined in RFC8795, can be used to address
>applications beyond "Traffic Engineering".
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-busi-teas-te-topology-profiles/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-busi-teas-te-topology-profiles-01
> https://datatracker.ietf.org/doc/html/draft-busi-teas-te-topology-profiles-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-busi-teas-te-topology-profiles-01
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 

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

Re: [OPSAWG] svc-common (RE: CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common

[Italo Busi]

Hi Med,

When I look at the L2SM/L2NM, I can see some groupings/identities/types which 
are not really specific for L2VPN but have a broader applicability to other 
solutions/implementations of Ethernet services.

I therefore see some benefits in extending the potential scope of this module 
even if we can keep the scope of its initial revision limited/focused to what 
it is needed.

My 2 cents

Thanks, Italo

> -Original Message-
> From: mohamed.boucad...@orange.com
> [mailto:mohamed.boucad...@orange.com]
> Sent: giovedì 3 settembre 2020 09:02
> To: Italo Busi ; opsawg 
> Subject: svc-common (RE: [OPSAWG] CALL FOR ADOPTION: draft-bgbw-
> opsawg-vpn-common
> 
> Hi Italo,
> 
> I'm afraid that "svc-common" is too generic and does not reflect what we are
> planning to do in this draft: L2/L3 VPNs. I suggest we maintain the initial 
> scope
> and name.
> 
> Thank you.
> 
> Cheers,
> Med
> 
> > -Message d'origine-----
> > De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Italo Busi
> > Envoyé : lundi 24 août 2020 11:57 À : Joe Clarke (jclarke)
> > ; opsawg  Objet : Re: [OPSAWG]
> > CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common
> >
> > I support the adoption of this draft as WG document
> >
> > I think the scope of the draft/model can also be extended to be
> > applicable to any service-type module and not being limited to only
> > L2VPN and L3VPN. For example we can call it svc-common rather than
> > vpn-common.
> >
> > Regarding the approach, my preference is to include in the common
> > module all the types/groupings which are common.
> >
> > In order not to delay the progress of L3NM, it is possible to follow
> > the same approach that has been followed in CCAMP WG with layer0-
> > types: once L3NM is ready for WG LC, it is possible to move forward
> > for WG LC only the common types/groupings which are needed by L3NM (as
> > first revision of the common YANG module) and to move the
> > types/groupings needed by other on-going work (e.g., L2NM) into a new
> > draft which is intended to become a second revision of the common YANG
> > module.
> >
> > My 2 cents
> >
> > Italo
> >
> 
> 
> 
> _
> 
> 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.

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

Re: [OPSAWG] CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common

[Italo Busi]

Hi Tom,

I agree that revisions of this YANG model should follow the rules in section 11 
of RFC7950.

I am proposing to select a name for the module which reflects it potential 
wider scope even if the first revision of the module has a limited scope. In 
this way, there is no need to change the module name to reflect a broader scope 
of future revisions.

Thanks, Italo

> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: lunedì 24 agosto 2020 13:37
> To: Italo Busi ; Joe Clarke (jclarke)
> ; opsawg 
> Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-
> common
> 
> From: OPSAWG  on behalf of Italo Busi
> 
> Sent: 24 August 2020 10:56
> 
> I support the adoption of this draft as WG document
> 
> I think the scope of the draft/model can also be extended to be applicable to
> any service-type module and not being limited to only L2VPN and L3VPN. For
> example we can call it svc-common rather than vpn-common.
> 
> Regarding the approach, my preference is to include in the common module
> all the types/groupings which are common.
> 
> In order not to delay the progress of L3NM, it is possible to follow the same
> approach that has been followed in CCAMP WG with layer0-types: once L3NM
> is ready for WG LC, it is possible to move forward for WG LC only the common
> types/groupings which are needed by L3NM (as first revision of the common
> YANG module) and to move the types/groupings needed by other on-going
> work (e.g., L2NM) into a new draft which is intended to become a second
> revision of the common YANG module.
> 
> 
> Italo
> 
> A point to be aware of is that there are rules about what you can and cannot
> do when revising a YANG module.  RFC7950 s.11 has a long list thereof of
> which those relating to enum and type have come up in the past.  If you want
> to do something that is not permitted, then you have to change the module
> name, which would seem to defeat the purpose of this particular exercise so it
> is important to get it right first time..
> 
> Tom Petch
> 
> 
> 
> My 2 cents
> 
> Italo
> 
> > -Original Message-
> > From: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
> > Sent: giovedì 13 agosto 2020 14:49
> > To: opsawg 
> > Subject: [OPSAWG] CALL FOR ADOPTION: draft-bgbw-opsawg-vpn-common
> >
> > Hello, WG members.  On the IETF 108 virtual meeting, Oscar presented
> > the status of the L3NM, L2NM, and the VPN common work.  While this VPN
> > common YANG module started as an individual document (per the chairs'
> > request), the L2NM and L3NM modules need to choose a direction for how
> > to handle common typedefs and groupings between them.
> >
> > On the virtual meeting we did a hum which indicated "Pianissimo" support.
> > Again, the hum system had some interesting rules, so this is not
> > conclusive, but seems to favor that this common module work should
> > exist as its own, standalone document that both L2NM and L3NM will
> > consume.  In this manner, one would not need to import either L2NM or
> > L3NM to make use of/extend these common attributes.
> >
> > To that end, the chairs would like a call for adoption of
> > draft-bgbw-opsawg- vpn-common.  Additionally, comments on the approach
> > and the choice of common attributes are welcome, especially from those
> > that were unable to attend the IETF 108 virtual meeting.
> >
> > This serves as a two week call for adoption ending on August 27, 2020.
> >
> > Thanks.
> >
> > Joe
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

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

Re: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm

[Italo Busi]

I support WG adoption of this document

I think the relationship between this model and the model in 
draft-ietf-ccamp-client-signal-yang could be clarified by progressing this work 
as a WG document

Italo

> -Original Message-
> From: Joe Clarke (jclarke) [mailto:jcla...@cisco.com]
> Sent: martedì 16 giugno 2020 16:18
> To: opsawg 
> Subject: [OPSAWG] CALL FOR ADOPTION: draft-barguil-opsawg-l2sm-l2nm
> 
> Hello, opsawg.  I hope everyone is doing well.
> 
> This starts a two-week poll for adoption of the L2 network module document.
> There does seem to be interest in this work, and it is progressing nicely in
> GitHub with side meetings.  There appears to be questions on what will be
> broken out into commonality between this module and the L3NM (work which
> is also underway).  So while we anticipate changes to this draft, the chairs
> think it’s reached a point where we’d like to see if the WG wants to formally
> adopt the work.
> 
> Please reply on-list with your comments on the draft and whether or not you
> support its WG adoption.  We will conclude this call on June 30, 2020.
> 
> Thanks.
> 
> Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

[Italo Busi]

Tom, 

The difficulties with layer0-types were due to the complexity of the technology 
we were trying to model.

Having a common layer0-types has actually helped a lot since only one module 
(the layer0-types) had to go through "several revolutions" instead of the six 
modules which depends on it.

There were also some technical issues in one draft which were discovered by 
people working on other draft only after the code was moved to the 
layer0-types. This helped at least to discover the issues earlier in the 
process.

Italo

> -Original Message-
> From: tom petch [mailto:ie...@btconnect.com]
> Sent: venerdì 29 maggio 2020 12:48
> To: Italo Busi ; adr...@olddog.co.uk; 'Joe Clarke
> (jclarke)' ; 'Oscar González de Dios'
> 
> Cc: 'opsawg' 
> Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> 
> From: Italo Busi 
> Sent: 29 May 2020 08:56
> 
> I support developing a separate module for the common types/groupings/...
> 
> This approach has worked quite well within TEAS and CCAMP WG.
> 
> I agree that there are some risks with this work: my suggestion is just be 
> aware
> of the risks and be careful to avoid them.
> 
> Working in parallel on L3NM, L2NM and the common modules would really
> help identifying what is really common and what it is not.
> 
> The suggestion we have got in CCAMP WG was not to send to IESG the
> common module alone but to send it with at least one of the modules
> importing it.
> 
> I would suggest to follow the same approach in OPSWG if a separate module
> for the common types/groupings/... is developed.
> 
> 
> I asked what the four documents were since AFAICT two are published RFC,
> and that has been confirmed.  So what is going to happen to those RFC?
> 
> And as you will know from CCAMP, layer0 types has undergone several
> revolutions before getting to its current state.  These common identity etc 
> are
> hard to get right in the IETF.
> 
> Tom Petch
> 
> Italo
> 
> > -Original Message-
> > From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> > Sent: giovedì 28 maggio 2020 19:15
> > To: 'tom petch' ; 'Joe Clarke (jclarke)'
> > ; 'Oscar González de Dios'
> > 
> > Cc: 'opsawg' 
> > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> >
> > OK, thanks, that's clear.
> >
> > I *think* (I was on the call where this was discussed) that it was
> > exactly the worry about importing a whole module that led to the
> > suggestion of having a separate module just for common types. As I
> > understand it, there was a desire to have a common type used in
> > several modules, but some implementers felt that this would lead them
> > to have to import the whole module (not just the type).
> >
> > The idea of a separate module certainly has some risks associated: not
> > capturing the right things; including too much "stuff"; forcing
> > commonality where none exists.
> >
> > There is, as you suggest, an alternative that each module goes its own
> > way and there is no sharing. I *think* we received a strong steer that
> > sharing is a good idea.
> >
> > Best,
> > Adrian
> >
> > -Original Message-
> > From: tom petch 
> > Sent: 28 May 2020 17:26
> > To: 'Joe Clarke (jclarke)' ;
> > 'Oscar González de Dios' ;
> > adr...@olddog.co.uk
> > Cc: 'opsawg' 
> > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> >
> > From: Adrian Farrel 
> > Sent: 28 May 2020 14:29
> >
> > Hey Tom,
> >
> > Is there a typo in your email? You said...
> >
> > > So carving out the current types (etc) will likely lead to a bad
> > > outcome; it is a question of looking carefully across the range of
> > > documents to see what is, or is likely to be common.
> >
> > I wondered whether you intended a "not" in there somewhere.
> >
> > 
> > Adrian,
> > no, no 'not' was intended.  The danger is taking e.g. the 50 or so
> > pages of identity, typedef, grouping in L2NM and assuming that they
> > form a good starting point or, worse still, making a logical OR of the
> > four documents under consideration and to create a monster document
> > and assuming that that is a good basis.
> >
> > Critical assessment is what is needed IMHO.  Sometimes it is better to
> > create your own version of vpn-id or ODUC than import a hundred pages
> > of someone else's in order to get them.
> >
> > Tom Petch
> >
> > If you wrote what you intended, could you explain a little further
> > what the danger is?
> >
> > 

Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

[Italo Busi]

Hi all,

I support developing a separate module for the common types/groupings/...

This approach has worked quite well within TEAS and CCAMP WG.

I agree that there are some risks with this work: my suggestion is just be 
aware of the risks and be careful to avoid them.

Working in parallel on L3NM, L2NM and the common modules would really help 
identifying what is really common and what it is not.

The suggestion we have got in CCAMP WG was not to send to IESG the common 
module alone but to send it with at least one of the modules importing it.

I would suggest to follow the same approach in OPSWG if a separate module for 
the common types/groupings/... is developed.

Italo

> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: giovedì 28 maggio 2020 19:15
> To: 'tom petch' ; 'Joe Clarke (jclarke)'
> ; 'Oscar González de Dios'
> 
> Cc: 'opsawg' 
> Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> 
> OK, thanks, that's clear.
> 
> I *think* (I was on the call where this was discussed) that it was exactly the
> worry about importing a whole module that led to the suggestion of having a
> separate module just for common types. As I understand it, there was a desire
> to have a common type used in several modules, but some implementers felt
> that this would lead them to have to import the whole module (not just the
> type).
> 
> The idea of a separate module certainly has some risks associated: not
> capturing the right things; including too much "stuff"; forcing commonality
> where none exists.
> 
> There is, as you suggest, an alternative that each module goes its own way and
> there is no sharing. I *think* we received a strong steer that sharing is a 
> good
> idea.
> 
> Best,
> Adrian
> 
> -Original Message-
> From: tom petch 
> Sent: 28 May 2020 17:26
> To: 'Joe Clarke (jclarke)' ; 'Oscar
> González de Dios' ;
> adr...@olddog.co.uk
> Cc: 'opsawg' 
> Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> 
> From: Adrian Farrel 
> Sent: 28 May 2020 14:29
> 
> Hey Tom,
> 
> Is there a typo in your email? You said...
> 
> > So carving out the current types (etc) will likely lead to a bad
> > outcome; it is a question of looking carefully across the range of
> > documents to see what is, or is likely to be common.
> 
> I wondered whether you intended a "not" in there somewhere.
> 
> 
> Adrian,
> no, no 'not' was intended.  The danger is taking e.g. the 50 or so pages of
> identity, typedef, grouping in L2NM and assuming that they form a good
> starting point or, worse still, making a logical OR of the four documents 
> under
> consideration and to create a monster document and assuming that that is a
> good basis.
> 
> Critical assessment is what is needed IMHO.  Sometimes it is better to create
> your own version of vpn-id or ODUC than import a hundred pages of someone
> else's in order to get them.
> 
> Tom Petch
> 
> If you wrote what you intended, could you explain a little further what the
> danger is?
> 
> Best,
> Adrian
> 
> -Original Message-
> From: OPSAWG  On Behalf Of tom petch
> Sent: 26 May 2020 17:05
> To: Joe Clarke (jclarke) ; Oscar González
> de Dios 
> Cc: opsawg 
> Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> 
> From: OPSAWG  on behalf of Joe Clarke (jclarke)
> 
> Sent: 21 May 2020 15:43
> 
> 
> 
> 2. L3NM
> Revision of the three main issues:
> Implementation Report by Cisco. It has two main issues
> (https://github.com/IETF-OPSAWG-WG/l3nm/issues/110)
> - Common module to have all the L3NM specific requirements. Type-like
> module.
> [Anton]: It makes implementation simpler. Does not generate unnecessary
> dependencies
> [Adrian]: It depends on if we need module for specific types, to avoid
> unnecessary imports. Also don't you only need to import types, not the entire
> module?
> [Qin]: With L3SM we did not take an augmentation approach. If there are
> common types defined in both models, then we may need to find the common
> components. We should decouple of L3SM.
> [Sriram]: Prefer to have a separate type-file for the specific parameters.
> [Oscar]: Define a common type-file for the service models.
> [Qin]: Is it possible to manage it as an independent draft?
> 
> [Oscar in github issues]: After the discussions, it seems reasonable to have a
> separate Yang module to contain the types. The suggestion is to write the
> module to cover the four service models (client service models, l3sm, l2sm and
> Network service models, l2nm, l3nm). It seems reasonable to include this
> module in l3nm draft instead of creating a new one to avoid dependencies.
> Samier, Dan and Anton to collaborate for a first version of the split
> 
> As chair, I want to call this out since it sounds like the authors made a 
> decision
> here, and I want to make sure the whole WG has a chance to weigh in.  In
> reading these minutes and issue #110, I can see the value of a types module to
> avoid what may be confusing 

Re: [OPSAWG] Invitation to participate in the L3NM/L2NM regular design calls

[Italo Busi]

Hi Oscar,

Thanks a lot for opening the discussion.

I would like to join these calls.

Thanks, Italo

From: Oscar González de Dios [mailto:oscar.gonzalezded...@telefonica.com]
Sent: mercoledì 20 maggio 2020 16:06
To: opsawg 
Subject: [OPSAWG] Invitation to participate in the L3NM/L2NM regular design 
calls

Dear OPSAWG colleagues,

Authors and contributors of L3NM (working group document) and 
L2NM (still individual draft) meet regularly to discuss the open issues and 
progress. I'd like to open the participation to OPSAWG colleagues. In addition, 
as L3NM is a working group document, we'll post regularly the minutes with the 
discussions, and will keep documented also the issues and solutions to them in 
the opsawg git L3NM issue tracker.

For those colleagues that are willing to participate, current 
time slot is Thursdays 15:00 - 16:00 CEST. Let me know if you want to 
participate to receive the periodic invitation. Also, if the time slot is not 
convenient due to time difference, we can arrange changes to accommodate new 
participants (now most participants connect from Europe time zone)

Oscar





Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg