Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

From: Qin Wu <[email-masked]>
Date: Thu, 4 Jun 2020 06:27:48 +0000

Hi, Haomian:
The idea here is to factor out common pieces of L3NM and L2NM if my understanding is correct, these common pieces could be reused by other future modules, so I am not sure your assumption on 10 out of 100 is correct.
In any case, I would suggest to reuse types in the existing published types modules as much as possible, make sure we will not reinvent any new wheels that have been defined somewhere else.

-Qin
发件人: Zhenghaomian
发送时间: 2020年6月4日 14:16
收件人: Qin Wu <[email-masked]>; Joe Clarke (jclarke) <jclarke=[email-masked]>; SAMIER BARGUIL GIRALDO <[email-masked]>
抄送: [email-masked]
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

Hi, Joe, Qin,

The groupings in the types is understood to be used in multiple other modules. Considering about the potential ‘uses’ in other models, it may not be a matter for putting in a same type YANG or separate one.

A more challenging issue is to have a ‘right-fit’ types. If a types contain 100 typedef and identities, sometimes we will be in the dilemma whether we should import it as we may only use no more than 10 in it. In such case re-definition seems to be a waste but importation would be too much weight. It can be even worse if we start a new one, then redefine some of them and add more for extension.

Thoughts?

Best wishes,
Haomian

发件人: OPSAWG [mailto:[email-masked]] 代表 Qin Wu
发送时间: 2020年6月4日 12:09
收件人: Joe Clarke (jclarke) <jclarke=[email-masked]<mailto:jclarke=[email-masked]>>; SAMIER BARGUIL GIRALDO <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

发件人: OPSAWG [mailto:[email-masked]] 代表 Joe Clarke (jclarke)
发送时间: 2020年6月4日 0:16
收件人: SAMIER BARGUIL GIRALDO <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

The module is available in the following PULL REQUEST: https://github.com/IETF-OPSAWG-WG/l3nm/pull/118

I know other *types module have included groupings, but to add groupings in a types module seems wrong to me.  I would just expect typedefs and identities.

[Qin]: We lack a good usage guidance on which kind of groupings should be included in types module,
section 4.3 of RFC8407 said:
“
4.13<https://tools.ietf.org/html/rfc8407#section-4.13>.  Reusable Groupings

   A reusable grouping is a YANG grouping that can be imported by
   another module and is intended for use by other modules.
”
But it didn’t tell us whether the reusable grouping should be in the separate module or in the same type modules as identity and typedef.
Following some published type module examples,e.g.,RFC8294 and draft-ietf-teas-yang-te-types-13 in the RFC queue, it did add some of reusable grouping in the type modules, my impression is grouping that contain newly defined typedef and identities can be added into type modules, grouping in grouping, we need to be very carefully,
There are some guidance on reusable grouping in section 4.3 of RFC8407

---

From: Qin Wu <[email-masked]>
Date: Thu, 4 Jun 2020 07:40:25 +0000

And on that topic, your operational-type is used for both admin and oper status.  It seems to me that admin status would either be up or down (or maybe something like testing such as in the ietf-interfaces module).  The oper-status may be richer.

And in your grouping for service-status, you have a timestamp tied to admin that should indicate the _actual_ date and time of the service being up or down.  This won’t necessarily be the case for an admin status.

[Qin]: Agree with Joe, two points to add here:

1.       why tie timestamp with both admin and oper status, why not define additional leaf for timestamp within service-status container?

2.       since operational-type is used for both admin and oper status, I think operation-type could be extended to support additional function, such as testing.

In addition, I would two additional typedefs

typedef oper-status {

type operational-type;

description

"Defines a type representing the operational status of

a vpn service.";

}

typedef admin-status {

type operational-type;

description

"Defines a type representing the administrative status of

a vpn service.";
}

Joe

---

From: Qin Wu <[email-masked]>
Date: Thu, 4 Jun 2020 07:41:01 +0000

Good, thank for clarification.

-Qin
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2020年6月4日 15:31
收件人: Qin Wu <[email-masked]>; Joe Clarke (jclarke) <jclarke=[email-masked]>; SAMIER BARGUIL GIRALDO <[email-masked]>
抄送: [email-masked]
主题: RE: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

Hi Qin,

I cited ietf-packet-fields as an example if a common module with groupings. Apologies for the confusion.

As you know, we already import ietf-packet-fields and reuse it as much we can in the l3nm current version. We don’t plan to change that.

Cheers,
Med

De : Qin Wu [mailto:[email-masked]]
Envoyé : jeudi 4 juin 2020 09:24
À : BOUCADAIR Mohamed TGI/OLN; Joe Clarke (jclarke); SAMIER BARGUIL GIRALDO
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

Common features, yes, factoring out some reusable groupings from other documents, I am not sure 100% sure, there is some gray area, e.g., ietf-packet-fields has already been defined in RFC8519, it is separated document, when needed, why not just import and reuse it.
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
发送时间: 2020年6月4日 13:42
收件人: Qin Wu <[email-masked]<mailto:[email-masked]>>; Joe Clarke (jclarke) <jclarke=[email-masked]<mailto:jclarke=[email-masked]>>; SAMIER BARGUIL GIRALDO <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>
主题: RE: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)

Hi Qin, all,

The idea is to have a common module listing items that can be reused by other VPN modules than L3NM. This “common” module does not have to be called “common types”.

As such, it is OK to have reusable groupings (e.g., ietf-packet-fields in RFC8519) or even common features (e.g., ietf-softwire-common in RFC8676).

Cheers,
Med

De : OPSAWG [mailto:[email-masked]] De la part de Qin Wu
Envoyé : jeudi 4 juin 2020 06:09
À : Joe Clarke (jclarke); SAMIER BARGUIL GIRALDO
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [OPSAWG] Minutes of L3NM/L2NM module discussions (27th-May-2020)