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

From: Adrian Farrel <adrian@olddog.co.uk>
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.

<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

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

Best,
Adrian

-----Original Message-----
From: OPSAWG <opsawg-bounces@ietf.org> On Behalf Of tom petch
Sent: 26 May 2020 17:05
To: Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org>; Oscar
González de Dios <oscar.gonzalezdedios@telefonica.com>
Cc: opsawg <opsawg@ietf.org>
Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions

From: OPSAWG <opsawg-bounces@ietf.org> on behalf of Joe Clarke (jclarke)
<jclarke=40cisco.com@dmarc.ietf.org>
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg