Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n Part)

[tom petch <[e-mail]>]

<tp>
Top posting on point 8.

I have commented at IETF Last Call that I think that the references to 'default' in the YANG descriptions in several places is misleading.  There is no default, there is no YANG default statement and YANG users will know what default means, except that here it does not.

Unless you are proposing that users add deviations with default statements, which is not how I read the text, then what I see you suggest is that at different levels (and I note that you, like me, are confused about what I refer to as levels), different values are recommended.  This is common practice with many specifications but they are not called defaults and I think it wrong  to use the term here.  Recommended value would seem what is called for.

Tom Petch

From: OPSAWG <[e-mail]> on behalf of Rob Wilton (rwilton) <rwilton=[e-mail]>
Sent: 27 April 2022 13:38

Hi Med,

Catching up with email, sorry for the delay, please see further comments inline ...

> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: 05 April 2022 11:40
> To: Rob Wilton (rwilton) <[e-mail]>; draft-ietf-opsawg-
> [e-mail]
> Cc: [e-mail]
> Subject: RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
>
> Hi Rob,
>
> Focusing on the first part of your review, except point (9).
>
> The changes can be tracked at: https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/337f65012f55e71df4105481bc28fe53ac8bb302, while the
> full changes made so far can be tracked at: https://tinyurl.com/l2nm-latest
>
> Please see inline for more context.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Rob Wilton (rwilton) <[e-mail]>
> > Envoyé : jeudi 17 mars 2022 21:53
> > À : [e-mail]
> > Cc : [e-mail]
> > Objet : AD review of draft-ietf-opsawg-l2nm-12
> >
> > Hi,
> >
> > Apologies for the delay, but I have now managed my AD review of draft-
> > ietf-opsawg-l2nm-12.  (Also attached in case my email is truncated ...)
> >

> >
> > (8) Hierarchical groupings and defaults
> >
> > I want to check what the model/plan is regarding hierarchical config
> > (e.g., grouping parameters-profile) and default values.  It looks like
> > some of the leaves in the provide have default values, which I believe
> > will be ambiguous when it comes to hierarchical config.  I.e., normally
> > I would never expect that a leaf with a default value defined would fall
> > back to the hierarchical policy because logically the leaf always has a
> > value if it is in scope.  One solution to this problem (that is a bit
> > more verbose), would be to take the defaults out of the leaves in the
> > grouping, and then add them back in using "refine" them using refine
> > statements when the global parameters-profile is used.  Another choice
> > would be to not express these using the YANG "default" keyword at all,
> > and instead describe the defaults in the description.
> >
> > Generally, defining defaults where we can is probably useful, but we
> > need to be careful with any hierarchical config/policies.
>
> [Med] Good point. However, for the particular case of parameters-profile,
> the intent is that all these parameters are factorized at the service level.
> Values that have to be overridden at lower levels, will be explicitly called and
> then take precedence.

At a YANG language level, I'm not convinced this works.

To take an example, if you look at mac-policies:

               |     +--rw mac-policies
               |     |  +--rw mac-addr-limit
               |     |  |  +--rw limit-number?    uint16
               |     |  |  +--rw time-interval?   uint32
               |     |  |  +--rw action?          identityref
               |     |  +--rw mac-loop-prevention
               |     |     +--rw window?            uint32
               |     |     +--rw frequency?         uint32
               |     |     +--rw retry-timer?       uint32
               |     |     +--rw protection-type?   identityref

Then the leaf mac-policies/mac-addr-limit/limit-number is always in scope and has a default value assigned.

So, even if the global policy "foo" sets limit-number to 200, and this "foo" policy is activated for a given VPN Node then even if limit-number isn't explicitly set under active-global-parameters-profiles the default value for limit-number is in scope and hence would always override the value in the global scope.

I think that the best solution here is to not have any defaults in any the leaves under the parameters-profile grouping.  Where that grouping is used to define the top level global parameters then you can make use of refine statements under the "uses parameters-profile" to add default values back in only at the top level.  The alternative choice is to take the "default" statements out, and put the default behaviour in the description instead, making it clear that the defaults only apply at the top level profiles.

>
> >
> >
> > (9) Various comment related to handling VLAN tag rewrites:
> >
> ...
> >
> >
> > (10)
> >                          leaf speed {
> >                            type uint32;
> >                            units "mbps";
> >                            default "10";
> >                            description
> >                              "LACP speed.";
> >                          }
> >
> > 10 Mbps seems like a slow default LACP speed.  Does this need a default
> > at all, Ethernet interfaces would generally negotiate to the fastest
> > supported speed.  The same comment applies to the port speed.
> >
>
> [Med] The default was inherited from the service model (L2SM, RFC8466).

Okay.  I'm not sure the last time I saw an interface running at 10 Mbps. :-)


>
> >
> > (11)
> > I did wonder whether it is okay to include the BGP and PW types as part
> > of this draft?  Personally, since they will be controlled by IANA
> > anyway, and this is where they are being used I think that is okay,
>
> [Med] Idem. I don' see any issue there.
>
>  but
> > I was wondering whether IDR/BESS had been consulted on this at all, it
> > might be worth checking with them that they are okay.
> >
> [Med] IDR, BESS, and PALS were solicited during the WGLC, but not
> specifically on this part. Adrian contacted the Chairs of PALS WG about an
> issue on the PW types specifically.

Okay.

Thanks,
Rob