On 13/05/2022 13:03, mohamed.boucadair@xxxxxxxxxx wrote:
Hi Tom,
Thank you for the comments.
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : tom petch <daedulus@xxxxxxxxxxxxx>
Envoyé : vendredi 13 mai 2022 11:23
I find some lack of clarity with regard of the BGP Layer 2
Encapsulation Types module.
I see no description of the module in the body of the document,
only the module itself and the IANA Considerations (S.10.2).
[Med] Hmm ... we do already have the following in Section 5:
Also, the L2NM uses the IANA-maintained modules "iana-bgp-l2-encaps"
(Section 8.1) and "iana-pseudowire-types" (Section 8.2) to identify a
Layer 2 encapsulation type.
and then in Section 7, you can read things such as:
Remote CEs that are entitled to connect to the same VPN should fit
with the CE range ('ce-range') as discussed in Section 2.2.3 of
[RFC6624]. 'pw-encapsulation-type' is used to control the PW
encapsulation type (Section 3 of [RFC6624]). The value of the 'pw-
encapsulation-type' are taken from the IANA-maintained "iana-bgp-
l2-encaps" module (Section 8.1).
Is there anything else you think we should say?
Yes. I think that the Introduction should say that this memo defines
four YANG modules, before going into so much detail of just one of them.
You have got five paragraphs on l2vpn before the others get a look in
and, for me, that misses the big picture; some readers may only care
about the encapsulation module.
And one point from below, Experimental Use values are in the current
registry which is why I think that they should be in the YANG.
Tom Petch
S.10.2 says ' add this note to both modules'. I only see one
module.
[Med] This was fixed as per the genart review. Thanks for catching this as well.
It gives the name of the registry but not what Group it is part of
i.e.
'Border Gateway Protocol(BGP) Parameters'. Admittedly this is one
of the better chosen Group names but it is always good practice
IMO to specify Group name and Registry name when referencing IANA
entries.
[Med] The note will be placed under the BGP parameters registry. I don't think adding "under BGP parameters...registry" to the note is useful.
It also says that the name of the 'identity' is the lower case of
the encapsulation name provided in the description. This is not
what happens here, in the module, in many if not most cases. The
identity name is based on the Description in the IANA Registry but
heavily abbreviated. Who will decide on an acceptable
abbreviation, meaningful, unique, for future additions?
[Med] I think this one was clarified as part of Dale's genart review. Please check the diff shared in that thread.
'Unassigned or reserved values..' worth spelling out that those
are the values in the BGP Layer 2 Encapsulation Types registry.
[Med] Yes.
And what about the Experimental Use values? They are not in the
IANA module but why not?
[Med] If such values appear in the re
'unique revision date' well yes but the current date would seem
more useful.
[Med] This wording was agreed with Rob as there was a case where IANA accidentally created two entries with the same revision date when adding two types.
Section 8.1 describes the module as 'YANG data types defined by
IANA'
which seems odd. The underlying data types are defined by the IDR
WG; perhaps 'maintained by'.
[Med] Indeed. Changed to:
"This module contains a collection of IANA-maintained YANG
data types that are used for referring to BGP Layer 2
encapsulation types. ..
I note that Section 8.2 which contains the other IANA module,
IANA-pseudowire-types, has a section title of 'IANA Encapsulation
Types'
which seems odd in the absence of any explanation.
[Med] Good catch. Changed to "IANA-Maintained Module for Pseudowire Types"
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
