Subject: Re: [OPSAWG] WG LC: [L3NM and] vpn-common documents

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Mar 2021 19:56:33 -0000

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 <[email-masked]> On Behalf Of Joe Clarke (jclarke)
Sent: 22 March 2021 13:32
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: <[email-masked]>
Date: Mon, 29 Mar 2021 05:34:23 +0000

Hi Adrian, 

Thanks for the comments. 

Youi can track the changes at https://tinyurl.com/vpn-common-latest.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de Adrian
> Farrel
> Envoyé : vendredi 26 mars 2021 20:57
> À : [email-masked]
> Cc : 'Joe Clarke (jclarke)' <jclarke=[email-masked]>
> Objet : Re: [OPSAWG] WG LC: [L3NM and] vpn-common documents
> 
> Hi,
> 
> 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.
> 
> 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.

[Med] I prefer to have a record of the background/context, but I understand your comment. I moved that text to an appendix and tweaked the intro among the lines you suggested. 

> s/but allows to "glue" a/but allows "gluing" a/

[Med] Fixed both. 

> 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/
> 

[Med] Fixed. Thanks. 

> I think you should list RFC 8341 as well.

[Med] Added this new sentence: " It also uses the extension defined in [RFC8341]."

>       "RFC 5086: LDP Specification";

[Med] This one was a typo, it should be 5036. Fixed. Thanks.

> Informational references. Probably add to 'underlay-transport' in

[Med] Cited 8453 next to "virtual network identifier" in Section 3.

>    read and write access to the objects they use.

[Med] Indeed, but I'm afraid this is redundant with the overall guideline https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines.   

> (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.
> 
> 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
> 

_________________________________________________________________________________________________________________________

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.