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

From: Oscar González de Dios <[email-masked]>
Date: Thu, 21 May 2020 14:27:23 +0000

Dear OPSAWG colleagues,

                Thanks for participating in the call today. Please find bellow the minutes:

L3NM and L2NM module discussions
* Date: 21-May-2020

Participants
- Oscar Gonzalez de Dios (Telefonica)
- Samier Barguil (Telefonica)
- Anton Snizar (Sedona)
- Daniel King (Old Dog Consulting)
- Adrian Farrel (Old Dog Consulting)
- Qin Wu (Huawei)
- Sergio Belotti ()
- Sriram Krishnamurthy (Nokia)
- Italo Busi (Huawei)

1. Agenda:
    - Revision of the L3NM Github issues (https://github.com/IETF-OPSAWG-WG/l3nm/issues)

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

- RD Auto-assigment implementation issue (https://github.com/IETF-OPSAWG-WG/l3nm/issues/114)
[Anton]: Do not see an implementation issue. The logic can be used as described in the yang.
[Qin]: Same as Anton. If alternative proposal is used, one additional parameter is needed
[Sriram]: Same as Anton
      [Oscar]: There seems to be a smaller preference for the original aproach. However, in order to be fully sure on the aproach, let's take it to the Yang doctor review.
[Oscar in github issues]: Oscar will sent it to the Yang Doctor Review.

Yang Doctor review Issues (https://github.com/IETF-OPSAWG-WG/l3nm/issues/111)
- Oscar will take care of editorial changes in the draft text.
- The review of the groupings will be done in a second round after the split.
- [Oscar in github issues]: Oscar will assign Med Boucadair the references issues.

- Protocol-Type: Better as a Indentity (https://github.com/IETF-OPSAWG-WG/l3nm/issues/115)
- [Samier]: Its better to have as an Idenity and include as part of the type-file.yang
- [Qin]: Idenity is extensible.
[Oscar in github issues]: Assigned to Samier

- Groupings review. It will be done after the review of the Types and modules.

Implementation status: There is text in RFC 7942 that provides guidance on text to include to show that the implementation status is not intended to be included in the final RFC

Tom Petch review Issues (https://github.com/IETF-OPSAWG-WG/l3nm/issues/112)
    - Oscar fixes the editorial issue of the IANA section.
- [Oscar in github issues]: Oscar will assign Med Boucadair and Qin the references issues in the Yang file. The review needs to be done in after the module split to avoid conflicts in the yang. Part of the reference work should have been fixed with the update of references for the Yang doctor's review
- [Daniel King]: Volunteers to look at where is the best place to locate the examples.

Best Regards,

                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

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 21 May 2020 14:43:45 +0000

2. L3NM

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 imports, but I want to know if anyone on the WG has a different opinion.

Joe

---

From: Oscar González de Dios <[email-masked]>
Date: Thu, 21 May 2020 15:11:30 +0000

Ok!

   We put the decission of creating the module with the types on hold. Looking forward for more feedback on the issue.

                Oscar

De: Joe Clarke (jclarke) <[email-masked]>
Enviado el: jueves, 21 de mayo de 2020 16:44
Para: Oscar González de Dios <[email-masked]>
CC: opsawg <[email-masked]>
Asunto: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

2. L3NM

Joe

---

From: tom petch <[email-masked]>
Date: Tue, 26 May 2020 16:04:35 +0000

From: OPSAWG <[email-masked]> on behalf of Joe Clarke (jclarke) <jclarke=[email-masked]>
Sent: 21 May 2020 15:43

2. L3NM

<tp>
Joe
The four documents are not spelled out but referred to in shorthand and while I think I know which are intended, that IMHO needs spelling out.
In principle, a common types is a no-brainer provided it is done early enough - before anything becomes an RFC! - and with limited enough scope.  NETMOD got it right but did have decades of SMI experience to go on, RTGWG got it right, with TEAS it is less clear while layer0-types has changed much over its short life - is it right now? May be.
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.  The higher up the stack you go the more likely items are to be common but equally the more likely it is that someone has been there already.
And if you look at existing types modules, it took a while for the penny to drop but they end up as separate I-D, better still with a different author to the importing I-D; a no brainer really.

Tom Petch

Joe

---

From: Oscar González de Dios <[email-masked]>
Date: Thu, 28 May 2020 09:52:07 +0000

Hi Tom,

>>The four documents are not spelled out but referred to in shorthand and while I think I know which are intended, that IMHO needs spelling out.

The involved modules which could potentially share a common Yang service types are:

- L3 VPN Customer Service YANG Model (L3SM) https://datatracker.ietf.org/doc/rfc8299/
- L2 VPN Customer Service YANG Model (L2SM)  https://datatracker.ietf.org/doc/rfc8466/
- L3 VPN Service Network Model (L3NM) https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-03
- L2 VPN Service Network Model (L2NM) https://tools.ietf.org/html/draft-barguil-opsawg-l2sm-l2nm-02

Best Regards,

Oscar

-----Mensaje original-----
De: tom petch <[email-masked]>
Enviado el: martes, 26 de mayo de 2020 18:05
Para: Joe Clarke (jclarke) <jclarke=[email-masked]>; Oscar González de Dios <[email-masked]>
CC: opsawg <[email-masked]>
Asunto: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

2. L3NM

<tp>
Joe

Tom Petch

Joe

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 May 2020 14:29:33 +0100

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.

If you wrote what you intended, could you explain a little further what the
danger is?

Best,
Adrian

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of tom petch
Sent: 26 May 2020 17:05
To: Joe Clarke (jclarke) <jclarke=[email-masked]>; Oscar
González de Dios <[email-masked]>
Cc: opsawg <[email-masked]>
Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

From: OPSAWG <[email-masked]> on behalf of Joe Clarke (jclarke)
<jclarke=[email-masked]>
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 imports, but I want to know if anyone
on the WG has a different opinion.

<tp>
Joe
The four documents are not spelled out but referred to in shorthand and
while I think I know which are intended, that IMHO needs spelling out.
In principle, a common types is a no-brainer provided it is done early
enough - before anything becomes an RFC! - and with limited enough scope.
NETMOD got it right but did have decades of SMI experience to go on, RTGWG
got it right, with TEAS it is less clear while layer0-types has changed much
over its short life - is it right now? May be.
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.  The higher up the stack you go the more
likely items are to be common but equally the more likely it is that someone
has been there already.
And if you look at existing types modules, it took a while for the penny to
drop but they end up as separate I-D, better still with a different author
to the importing I-D; a no brainer really.

Tom Petch

Joe

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: tom petch <[email-masked]>
Date: Thu, 28 May 2020 16:26:16 +0000

From: Adrian Farrel <[email-masked]>
Sent: 28 May 2020 14:29

Hey Tom,

<tp>
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

Best,
Adrian

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of tom petch
Sent: 26 May 2020 17:05
To: Joe Clarke (jclarke) <jclarke=[email-masked]>; Oscar

2. L3NM

<tp>
Joe

Tom Petch

Joe

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 May 2020 18:14:30 +0100

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 <[email-masked]> 
Sent: 28 May 2020 17:26
To: 'Joe Clarke (jclarke)' <jclarke=[email-masked]>; 'Oscar
González de Dios' <[email-masked]>; [email-masked]
Cc: 'opsawg' <[email-masked]>
Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

Hey Tom,

<tp>
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

Best,
Adrian

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of tom petch
Sent: 26 May 2020 17:05
To: Joe Clarke (jclarke) <jclarke=[email-masked]>; Oscar

2. L3NM

<tp>
Joe

Tom Petch

Joe

=

---

From: Italo Busi <[email-masked]>
Date: Fri, 29 May 2020 07:56:29 +0000

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

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: giovedì 28 maggio 2020 19:15
> To: 'tom petch' <[email-masked]>; 'Joe Clarke (jclarke)'
> <jclarke=[email-masked]>; 'Oscar González de Dios'
> <[email-masked]>
> 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).
> 
> 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
> 
> > outcome; it is a question of looking carefully across the range of
> > documents to see what is, or is likely to be common.
> 
> 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
> 
> To: Joe Clarke (jclarke) <jclarke=[email-masked]>; Oscar González
> de Dios <[email-masked]>
> unnecessary imports. Also don't you only need to import types, not the entire
> module?
> [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
> 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 imports, but I want to know if anyone on the WG
> has a different opinion.
> 
> <tp>
> Joe
> The four documents are not spelled out but referred to in shorthand and while
> I think I know which are intended, that IMHO needs spelling out.
> In principle, a common types is a no-brainer provided it is done early enough -
> before anything becomes an RFC! - and with limited enough scope.
> got it right, with TEAS it is less clear while layer0-types has changed much over
> its short life - is it right now? May be.
> 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.  The higher up the stack you go the more likely items
> are to be common but equally the more likely it is that someone has been
> there already.
> And if you look at existing types modules, it took a while for the penny to drop
> but they end up as separate I-D, better still with a different author to the
> importing I-D; a no brainer really.
> 
> Tom Petch
> 
> Joe
> 
>

---

From: tom petch <[email-masked]>
Date: Fri, 29 May 2020 10:47:31 +0000

From: Italo Busi <[email-masked]>
Sent: 29 May 2020 08:56

<tp>
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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 May 2020 12:27:33 +0100

> 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?

My proposal (but who am I to say what will actually happen) was:
- step one: nothing
   The new module is shaped as it would have been had it been created
   before those RFCs were made
- step two: putatively never happening
   If those RFCs are respun at any time, they could make use of the new
   module

Best,
Adrian

---

From: Italo Busi <[email-masked]>
Date: Fri, 29 May 2020 13:05:02 +0000

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

> From: tom petch [mailto:[email-masked]]
> Sent: venerdì 29 maggio 2020 12:48
> To: Italo Busi <[email-masked]>; [email-masked]; 'Joe Clarke
> (jclarke)' <jclarke=[email-masked]>; 'Oscar González de Dios'
> 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.
> 
> <tp>
> 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
> 
> > 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).
> >
> > 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
> >
> > To: 'Joe Clarke (jclarke)' <jclarke=[email-masked]>;
> > 'Oscar González de Dios' <[email-masked]>;
> > [email-masked]
> > 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.
> >
> > 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
> >
> > From: OPSAWG <[email-masked]> on behalf of Joe Clarke
> > (jclarke) <jclarke=[email-masked]>
> > Sent: 21 May 2020 15:43
> >
> >
> >
> > 2. L3NM
> > [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.
> > [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.
> > 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
> > imports, but I want to know if anyone on the WG has a different opinion.
> >
> > <tp>
> > Joe
> > The four documents are not spelled out but referred to in shorthand
> > and while I think I know which are intended, that IMHO needs spelling out.
> > NETMOD got it right but did have decades of SMI experience to go on,
> > RTGWG got it right, with TEAS it is less clear while layer0-types has
> > changed much over its short life - is it right now? May be.
> > documents to see what is, or is likely to be common.  The higher up
> > the stack you go the more likely items are to be common but equally
> > the more likely it is that someone has been there already.
> > And if you look at existing types modules, it took a while for the
> > penny to drop but they end up as separate I-D, better still with a
> > different author to the importing I-D; a no brainer really.
> >
> > Tom Petch
> >
> > Joe
> >
> >