Hi,
WGLC review of draft-ietf-opsawg-vpn-common
I was part of the design team calls that worked out it would be possible
to extract a common portion of the LxNM models and put them in a
separate common document.
As part of working group last call I've been through the draft and I
think it is ready for publication.
There are some minor points below.
Best,
Adrian
===
Section 1.
It would be nice to present the first paragraph in language that will
survive publication of the LxNM models. Something like...
The IETF has specified YANG data modules for VPN services, e.g., Layer
3 VPN Service Model (L3SM) [RFC8299] and Layer 2 VPN Service Model
(L2SM) [RFC8466]. Other relevant YANG models are the Layer 3 VPN
Network Model (L3NM) [I-D.ietf-opsawg-l3sm-l3nm] and the Layer 2 VPN
Network Model (L2NM) [I-D.ietf-opsawg-l2nm]. There are common data
nodes and structures that are present in all of these models or at
least a subset of them. An example of such data nodes is depicted in
Figure 1.
I wonder about splitting Section 1 into just the general descriprion and
motivation. Then put the examples into a later section. Or,
alternatively perhaps the examples aren't needed at all? That would also
solve the problem of using tree notation before explaining the notation
in Section 2.
The section has a couple of paragraphs of history (about how there used
to be repetition in early versions). It's kind of interesting, but maybe
not so important. from the first paragraph to the last two paragraphs in
the section.
This would leave the whole of the section as just three paragraphs,
reading something like...
The IETF has specified YANG data modules for VPN sevices, e.g., Layer
3 VPN Service Model (L3SM) [RFC8299] and Layer 2 VPN Service Model
(L2SM) [RFC8466]. Other relevant YANG models are the Layer 3 VPN
Network Model (L3NM) [I-D.ietf-opsawg-l3sm-l3nm] and the Layer 2 VPN
Network Model (L2NM) [I-D.ietf-opsawg-l2nm]. There are common data
nodes and structures that are present in all of these models or at
least a subset of them.
This document defines a common YANG module ("ietf-vpn-common" in
Section 4) that can be used by various VPN-related modules such as
L3NM [I-D.ietf-opsawg-l3sm-l3nm] and L2NM [I-D.ietf-opsawg-l2nm].
This prevents duplication of effort and documentation, and ensures
that there is consistency between the models.
The "ietf-vpn-common" module includes a set of identities, types, and
groupings that are meant to be reused by other VPN-related YANG
modules independently of their layer (e.g., Layer 2, Layer 3) and the
type of the module (e.g., network model, service model) including
possible future revisions of existing models (e.g., L3SM [RFC8299]
and L2SM [RFC8466]).
---
Section 3
OLD
Also, the module defines a set of identities, e.g.:
NEW
Also, the module defines a set of identities, including:
END
s/but allows to "glue" a/but allows "gluing" a/
OLD
For example, a service provider may provide an external
connectivity to a VPN customer (e.g., to a private or public
cloud, Internet). Such service may involve tweaking both
NEW
For example, a service provider may provide an external
connectivity service to a VPN customer (e.g., to a private or
public cloud, Internet). Such a service may involve tweaking
both
END
s/in other nodes than PEs/in nodes other than PEs/
s/a P node or event/a P node or even/
s/and BGP with labeled to/and BGP with labeled/
---
Section 4
This module uses types defined in [RFC6991], [RFC8294], and
[RFC8519].
I think you should list RFC 8341 as well.
---
Section 4
identity virtual-network {
base transport-instance-type;
description
"Identity for the virtual network.";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
and
identity ldp {
base protocol-type;
description
"Transport is based on LDP.";
reference
"RFC 5086: LDP Specification";
}
You need to work out a way to include RFC 8453 and RFC 5086 as
Informational references. Probably add to 'underlay-transport' in
Section 3.
---
Section 5
The "ietf-vpn-common" module defines a set of identities, types, and
groupings. These nodes are intended to be reused by other YANG
modules. The module does not expose by itself any data nodes which
are writable, contain read-only state, or RPCs. As such, there are
no additional security issues to be considered relating to the "ietf-
vpn-common" module.
Does this section also need to say:
Documents that define YANG modules that make use of the YANG module
defined in this document need to fully consider the implications of
read and write access to the objects they use.
-----Original Message-----
From: OPSAWG <opsawg-boun...@ietf.org> On Behalf Of Joe Clarke (jclarke)
Sent: 22 March 2021 13:32
To: opsawg@ietf.org
Subject: [OPSAWG] WG LC: L3NM and vpn-common documents
Hello, WG. One of the action items out of the 110 meeting was to put
the L3NM (https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-07)
and vpn-common
(https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-03) documents
through WG LC. The authors have said that these can work independently
from the L2NM document, which is still being revised.
This begins a two-week WG LC for these two documents. Please provide
your comments and concerns by April 5, 2021. Additionally, if anyone is
interested in acting as shepherd for either of these documents, please
let the chairs know.
Thanks.
Joe
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
