Re: [OPSAWG] Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard l2vpn-ntw

[tom petch <[e-mail]>]

On 13/05/2022 13:36, [e-mail] wrote:
> Tom,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : tom petch <[e-mail]>
>> Envoyé : vendredi 13 mai 2022 13:03
>>
>> Some stray thoughts on YANG module 'ietf-l2vpn-ntw'
>>
>> - In a number of places, the module says 'The default value is ...
>> when used at the service level'.  I have two problems with this.
>> I see no 'default' specified in YANG - there could be but there is
>> not; this would appear to be a recommendation not a default.
>> Other YANG modules have the concept of e.g. global, link, node
>> parameters with the same grouping appearing in several places with
>> a suitable but different default specified in each place, but not
>> here.
>
> [Med] We used to have default statements, but we removed them as per a fair comment from during the AD review. Please refer to that thread with Rob.
>

Yes, but you should also have removed the mention of default in the 
description because there is no default (and most readers of a YANG 
module will think they know what a default is!).

>> Second, the statement is in a grouping, such as parameters-
>> profile.
>> This grouing appears in two 'uses', one under 'global-parameters-
>> profiles' and the other under 'active-global-parameters-profiles'.
>>
>> How do I marry the reference to 'service level' and whatever is
>> the alternative to 'service level' to a choice of 'active' or
>> whatever the alternative to 'active' is?

Again, I think that there is a lack of big picture.  I cannot see, in 
the introductory text, something about values specified at global v line 
v node level, or the equivalent thereof for service level and whatever 
the alternative(s) are. Something for s.7 perhaps.

>> - There are many references to non-IETF documents.  Unlike the
>> IETF, these references are mostly not unique without an
>> accompanying date, which most of the references in the YANG module
>> do not have.
>
> [Med] Dates are provided in the reference entries. We trust the RFC editor will do the right thing.
>
>>
>> - identity evpn-service-interface-type
>> this is an identity not a type so the use of type in the
>> identifier seems confusing.
>
> [Med] hmm... this is an identity for interface type.
>
>> - identity color-type
>> a reference would be useful - I recall an AD asking last year what
>> a color was.
>
> [Med] that was Joe C. who raised that comment. The agreement we had was to update the description but add the following note to the core text:
>
>      See also Section 5.10.2.1 of [RFC8466] for more
>      discussion of QoS classification including the use of color types.
>
>> - lacp-active refers to auto-speed negotiation while lacp-passive
>> is about duplex; seems inconsistent
>>
>> - having a set of referenced identities derived from pw-type and a
>> separate set of referenced identities derived from iana-pw-types
>> seems a potential source of confusion
>>
>
> [Med] The description is clear enough about the scope of the pw-type. Not sure if adding a prefix would be better.
>
>> -leaf interface-id
>>     type string
>> I wonder why this is not a reference to the YANG interface module.
>
> [Med] This is because this can be used to point to a port, bridge reference, etc.
>
>> - leaf speed
>>      default 10
>> seems a bit slow in this day and age; buying kit for the home last
>> year I could not get anything under 100 which my hub could not
>> cope with:-(
>
> [Med] I don't like that default value as well. Please refer to the AD review where we indicated that this set as such to be consistent with RFC8466.
>
>> - uses y-1731
>> I only see this used once.  Given that groupings used just once
>> make the module harder to follow, why is this a grouping?
>
> [Med] this grouping can be reused by other module. PM, for example.
>
>> - leaf cos-id
>> (802.1p) Is this a seperate reference from that to 802.1Q?
>
> [Med] This is inherited from RFC8466.
>
>>
>> - mac-policies
>> this has source and destination address and mask (with no
>> constraints on the mask).  What constitutes a match?
>>
>
> [Med] This was designed to mimic RFC8519. The match will be based on the parameters that will be provided. This is similar to this part from 8519:

Worth spelling out IMHO, not replicating RFC8519 but referencing it

Tom Petch
>
>          |        +--rw matches
>          |        |  +--rw (l2)?
>          |        |  |  +--:(eth)
>          |        |  |     +--rw eth {match-on-eth}?
>          |        |  |        +--rw destination-mac-address?
>          |        |  |        |       yang:mac-address
>          |        |  |        +--rw destination-mac-address-mask?
>          |        |  |        |       yang:mac-address
>          |        |  |        +--rw source-mac-address?
>          |        |  |        |       yang:mac-address
>          |        |  |        +--rw source-mac-address-mask?
>          |        |  |        |       yang:mac-address
>
>> Tom Petch
>>
>> On 29/04/2022 15:40, The IESG wrote:
>>>
>>> The IESG has received a request from the Operations and
>> Management
>>> Area Working Group WG (opsawg) to consider the following
>> document: -
>>> 'A YANG Network Data Model for Layer 2 VPNs'
>>>     <draft-ietf-opsawg-l2nm-15.txt> as Proposed Standard
>>>
>>> The IESG plans to make a decision in the next few weeks, and
>> solicits
>>> final comments on this action. Please send substantive comments
>> to the
>>> [e-mail] mailing lists by 2022-05-13. Exceptionally,
>>> comments may be sent to [e-mail] instead. In either case,
>> please
>>> retain the beginning of the Subject line to allow automated
>> sorting.
>>>
>>> Abstract
>>>
>>>
>>>      This document defines an L2VPN Network YANG Model (L2NM)
>> which can be
>>>      used to manage the provisioning of Layer 2 Virtual Private
>> Network
>>>      services within a network (e.g., service provider network).
>> The L2NM
>>>      complements the Layer 2 Service Model (L2SM) by providing a
>> network-
>>>      centric view of the service that is internal to a service
>> provider.
>>>      The L2NM is particularly meant to be used by a network
>> controller to
>>>      derive the configuration information that will be sent to
>> relevant
>>>      network devices.
>>>
>>>      Also, this document defines a YANG module to manage Ethernet
>> segments
>>>      and the initial versions of two IANA-maintained modules that
>> defines
>>>      a set of identities of BGP Layer 2 encapsulation types and
>> pseudowire
>>>      types.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/
>>>
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>> .
>>>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> .
>