Tom,
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : tom petch <daedulus@xxxxxxxxxxxxx>
> Envoyé : vendredi 13 mai 2022 13:03
> À : last-call@xxxxxxxx
> Cc : adrian@xxxxxxxxxxxx; opsawg@xxxxxxxx; opsawg-chairs@xxxxxxxx;
> draft-ietf-opsawg-l2nm@xxxxxxxx
> Objet : Re: Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG
> Network Data Model for Layer 2 VPNs) to Proposed Standard l2vpn-
> ntw
>
> 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.
>
> 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?
>
> - 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:
| +--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
> > last-call@xxxxxxxx mailing lists by 2022-05-13. Exceptionally,
> > comments may be sent to iesg@xxxxxxxx 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
> > IETF-Announce@xxxxxxxx
> > 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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
