On 13/05/2022 13:36, mohamed.boucadair@xxxxxxxxxx wrote:
Tom,
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : tom petch <daedulus@xxxxxxxxxxxxx>
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
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
