Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-l2nm-05.txt

From: [email-masked]
Date: Thu, 09 Sep 2021 23:58:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group WG of the IETF.

        Title           : A Layer 2 VPN Network YANG Model
        Authors         : Samier Barguil
                          Oscar Gonzalez de Dios
                          Mohamed Boucadair
                          Luis Angel Munoz
	Filename        : draft-ietf-opsawg-l2nm-05.txt
	Pages           : 149
	Date            : 2021-09-09

Abstract:
   This document defines an L2VPN Network YANG Model (L2NM) that can be
   used to manage the provisioning of Layer 2 Virtual Private Network
   (VPN) 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
   providers.  As such, the L2NM is meant to be used by a network
   controller to derive the configuration information that will be sent
   to relevant network devices.

   Also, the document defines the initial versions of two IANA-
   maintained modules that defines a set of identities of BGP Layer 2
   encapsulation types and pseudowire types.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l2nm/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l2nm-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l2nm-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Fri, 10 Sep 2021 07:01:35 +0000

Hi Chairs, all, 

This version integrates the comments received from Joe and Julian (as indicated in another message sent to the list).

Chairs, can you please issue a WGLC for this version? Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de internet-
> [email-masked]
> Envoyé : vendredi 10 septembre 2021 08:58
> À : [email-masked]
> Cc : [email-masked]
> Objet : [OPSAWG] I-D Action: draft-ietf-opsawg-l2nm-05.txt
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

_________________________________________________________________________________________________________________________

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.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 10 Sep 2021 13:16:19 +0000

I completely missed the follow-up, which I'm now reading.  Thanks for
addressing some of these comments.  I like the boolean approach to the
PW MTU.

I didn't see Oscar's follow-up on some of the other points, though.  I
assume that's still pending?

Joe

---

From: Oscar González de Dios <[email-masked]>
Date: Fri, 10 Sep 2021 13:18:50 +0000

Hi Joe,

        I reviewed Med proposal and was good with it. No further points from my side for the l2nm.

        Oscar

-----Mensaje original-----
De: Joe Clarke (jclarke) <[email-masked]>
Enviado el: viernes, 10 de septiembre de 2021 15:16
Para: [email-masked]; [email-masked]
CC: [email-masked]; [email-masked]
Asunto: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-l2nm-05.txt

I completely missed the follow-up, which I'm now reading.  Thanks for addressing some of these comments.  I like the boolean approach to the PW MTU.

I didn't see Oscar's follow-up on some of the other points, though.  I assume that's still pending?

Joe

On 9/10/21 03:02, [email-masked] wrote:
>> [email-masked] Envoyé : vendredi 10 septembre 2021 08:58 À :
>> [email-masked] Cc : [email-masked] Objet : [OPSAWG] I-D
>> Action: draft-ietf-opsawg-l2nm-05.txt
>>
>>

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 10 Sep 2021 13:36:00 +0000

I meant responses to some of my comments.  I didn't see
references/definitions added for LAG and LACP (or ARP or ND).

You still have "Active" and "Backup" in Figure 36 for precedence type
where I think it should be Primary and Backup.  Plus, in Section 6.7,
you refer to Primary and Secondary.  When you have a Primary, Secondary
as the other mode makes sense (or Active and Backup).  And I still think
that perhaps an enumeration is better here as I'm not clear what other
modes you'd have.

Finally, I don't see the "color" thing addressed.  I was hoping for some
canonical schooling here to help understand the reasoning.  There may
not be anything referential, but then why use "colors" at all versus a
categorization string?

Joe

---

From: <[email-masked]>
Date: Fri, 10 Sep 2021 14:39:33 +0000

Hi Joe, 

Please see inline. 

Cheers,
Med

> De : Joe Clarke (jclarke) [mailto:[email-masked]]
> Envoyé : vendredi 10 septembre 2021 15:36
> À : Oscar González de Dios <[email-masked]>;
> BOUCADAIR Mohamed INNOV/NET <[email-masked]>; opsawg-
> [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-l2nm-05.txt
> 

[[Med]] We do have refs cited in the main document, e.g., 

      'esi-type-1':  The ESI is auto-generated from the IEEE 802.1AX
         Link Aggregation Control Protocol (LACP) [IEEE802.1AX].

For the YANG module, we don't have a reference here because we are relying upon a lag feature, for which we already have the following (common): 

     feature lag-interface {
       description
         "Indicates the support for Link Aggregation Group (LAG)
          between VPN network accesses.";
       reference
         "IEEE Std. 802.1AX: Link Aggregation";
     }

> that perhaps an enumeration is better here as I'm not clear what other

[[Med]] I agree that some cleanup is needed. An enumeration is likely to be sufficient for this case, but we went with an identity to allow defining future values. 

> not be anything referential, but then why use "colors" at all versus a

[[Med]] Actually, we are echoing the same content as in RFC8466. 

> > De: Joe Clarke (jclarke) <[email-masked]> Enviado el: viernes, 10
> > de septiembre de 2021 15:16
> >> This version integrates the comments received from Joe and Julian (as
> indicated in another message sent to the list).
> >>
> >> _____________________________________________________________________
> >> ____________________________________________________
> >>
> >> 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.
> > Este mensaje y sus adjuntos se dirigen exclusivamente a su
> destinatario, puede contener información privilegiada o confidencial y
> es para uso exclusivo de la persona o entidad de destino. Si no es
> usted. el destinatario indicado, queda notificado de que la lectura,
> utilización, divulgación y/o copia sin autorización puede estar
> prohibida en virtud de la legislación vigente. Si ha recibido este
> mensaje por error, le rogamos que nos lo comunique inmediatamente por
> esta misma vía y proceda a su destrucción.
> >
> > The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution
> or copying of this communication is strictly prohibited. If you have
> received this transmission in error, do not read it. Please immediately
> reply to the sender that you have received this communication in error
> and then delete it.
> >
> > Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> > destinatário, pode conter informação privilegiada ou confidencial e é
> > para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> > senhoria o destinatário indicado, fica notificado de que a leitura,
> > utilização, divulgação e/ou cópia sem autorização pode estar proibida
> > em virtude da legislação vigente. Se recebeu esta mensagem por erro,
> > rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> > proceda a sua destruição
> >

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 10 Sep 2021 17:09:47 +0000

-----Message d'origine-----
>          "IEEE Std. 802.1AX: Link Aggregation";

Okay.  I should have checked vpn-common as a cross-reference for the
lag-interface container/if-feature.  But for the esi-type-1 identity, I
think citing the IEEE802.1AX reference there would be easy to do and
potentially useful.

> [[Med]] I agree that some cleanup is needed. An enumeration is likely to be sufficient for this case, but we went with an identity to allow defining future values.

No strong objection to that (better safe than sorry, probably), but I
will ask you to clean up the supporting text to use common terminology.

> [[Med]] Actually, we are echoing the same content as in RFC8466. 

Thanks.  While they define it there, I'm not happy with that usage
either as they seem to conflate color-id and color-type.  But at least
it's a bit clearer.  Perhaps as you did for OAM, can you point to
section 5.10.2[.1] for your qos-classification-policy subtree?

Joe

---

From: <[email-masked]>
Date: Mon, 13 Sep 2021 06:49:37 +0000

Hi Joe,

An updated version that fixes the points your raised (and some other nits) is available online. The full diff can be seen at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-l2nm-06 

Looking forward to seeing the WGLC issued for this version soon. Thanks. 

Cheers,
Med

> Envoyé : vendredi 10 septembre 2021 19:10
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Oscar
> González de Dios <[email-masked]>; opsawg-
> [email-masked]
> >> De : Joe Clarke (jclarke) [mailto:[email-masked]] Envoyé :
> >> vendredi 10 septembre 2021 15:36 À : Oscar González de Dios
> >> <[email-masked]>;
> >> [email-masked] Cc : [email-masked]; [email-masked]
> > For the YANG module, we don't have a reference here because we are
> relying upon a lag feature, for which we already have the following
> (common):
> >
> >      feature lag-interface {
> >        description
> >> you refer to Primary and Secondary.  When you have a Primary,
> >> Secondary as the other mode makes sense (or Active and Backup).  And
> >> I still think that perhaps an enumeration is better here as I'm not
> >> clear what other modes you'd have.
> > [[Med]] I agree that some cleanup is needed. An enumeration is likely
> to be sufficient for this case, but we went with an identity to allow
> defining future values.
> 
> >> Finally, I don't see the "color" thing addressed.  I was hoping for
> >> some canonical schooling here to help understand the reasoning.
> >> There may not be anything referential, but then why use "colors" at
> >> all versus a categorization string?

---

From: Oscar González de Dios <[email-masked]>
Date: Mon, 13 Sep 2021 07:17:11 +0000

Joe,

   Further clarifications inline on the color topic.

-----Mensaje original-----
De: [email-masked] <[email-masked]>
Enviado el: lunes, 13 de septiembre de 2021 8:50
Para: Joe Clarke (jclarke) <[email-masked]>; [email-masked]
CC: [email-masked]; [email-masked]
Asunto: RE: [OPSAWG] I-D Action: draft-ietf-opsawg-l2nm-05.txt

Hi Joe,

Cheers,
Med

> De : Joe Clarke (jclarke) [mailto:[email-masked]] Envoyé : vendredi
> 10 septembre 2021 19:10 À : BOUCADAIR Mohamed INNOV/NET
> <[email-masked]>; Oscar González de Dios
> <[email-masked]>; opsawg- [email-masked] Cc :
> [email-masked]; [email-masked] Objet : Re: [OPSAWG]
> I-D Action: draft-ietf-opsawg-l2nm-05.txt
>
> >> [email-masked] Cc : [email-masked];
> >> [email-masked] Objet : Re: [OPSAWG] I-D Action:
> >> draft-ietf-opsawg-l2nm-05.txt
> >>
> lag-interface container/if-feature.  But for the esi-type-1 identity,
> I think citing the IEEE802.1AX reference there would be easy to do and
> potentially useful.
>
> >
> >> You still have "Active" and "Backup" in Figure 36 for precedence
> >> type where I think it should be Primary and Backup. Plus, in
> >> Section 6.7, you refer to Primary and Secondary.  When you have a
> >> Primary, Secondary as the other mode makes sense (or Active and
> >> Backup).  And I still think that perhaps an enumeration is better
> >> here as I'm not clear what other modes you'd have.
[Oscar] On the "color" topic, let me retake you original comment and answer it first. It is true that the "color" word was used several times and might be misleading.
[Original comment from Joe]
>>Joe Concerning leaf group-color:
>>Okay, dumb question.  What does a string for color provide here?  While I've seen the concept of color used a lot in VPN examples, a free-form string that should be a color seems over-done here.  The >>group-id is another open string.  Why couldn't that also be a color?
>>I'd love to see some canonical reference that explains color use (if there is one).
[Oscar] As med pointed out, the group-color was borrowed from the customer service model (RFC 8466). The purpose of the group container is to identify several vpn-network-accesses that are associated together (e.g. are connected to the same CE and would need for example redundancy). Hence, after studying the need, with just the group-id seems enough to cover the purposes of identifying the group and does not provide additional information or clear expected behavior on the interface. We have removed it in from version -05.
The other use of the color, in the qos classification policy, is completely different and well documented in the service model (8FC 8466). The reference has been added in -06 version just posted for better understanding.

Oscar

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.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 13 Sep 2021 20:12:27 +0000

> The other use of the color, in the qos classification policy, is completely different and well documented in the service model (8FC 8466). The reference has been added in -06 version just posted fo…

Thanks, Oscar and Med.  I agree it is explained in 8466, but they say
color-id in the text whereas their YANG module use color-type.  Still, I
appreciate your reference.  Seems you took care of all my main points.

Joe

---

From: <[email-masked]>
Date: Tue, 14 Sep 2021 05:50:34 +0000

Hi Joe, all,

Fully agree. FWIW, I filled an errata for this (and also to clean the use of "cos" and "cos-id" under flow match): 
https://www.rfc-editor.org/errata/eid6683

Cheers,
Med

> Envoyé : lundi 13 septembre 2021 22:12
> > [Oscar] As med pointed out, the group-color was borrowed from the
> customer service model (RFC 8466). The purpose of the group container is
> to identify several vpn-network-accesses that are associated together
> (e.g. are connected to the same CE and would need for example
> redundancy). Hence, after studying the need, with just the group-id
> seems enough to cover the purposes of identifying the group and does not
> provide additional information or clear expected behavior on the
> interface. We have removed it in from version -05.
> > The other use of the color, in the qos classification policy, is
> completely different and well documented in the service model (8FC
> 8466). The reference has been added in -06 version just posted for
> better understanding.
>