Re: [OPSAWG] Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG Network Data Model for Layer 2 VPNs) to Proposed Standard

Hi Tom, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tom petch <daedulus@btconnect.com>
> Envoyé : mercredi 18 mai 2022 10:40
> À : last-call@ietf.org
> Cc : adrian@olddog.co.uk; opsawg@ietf.org; opsawg-chairs@ietf.org;
> draft-ietf-opsawg-l2nm@ietf.org
> Objet : Re: Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG
> Network Data Model for Layer 2 VPNs) to Proposed Standard
> 
> 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
> 
> Two more YANG quirks, belatedly.

[Med] Comments are still welcome as we still have two weeks before the IESG telechat. 

> 
> s.7.6 has
>                         |        +--:(evpn-bgp)
>                         |           +--rw df-preference?
> uint16
>                         |           +--rw vpws-service-instance
> while s.7.6.2 has
>                 |        +--:(evpn-bgp)
>                 |           +--rw vpws-service-instance
> df-preference is present in the YANG module so I think that the
> approach in s.7.6 is preferable to that of s.7.6.2.

[Med] 7.6.2 does not aim to provide the full structure as it only zooms into "EVPN-VPWS Service Instance" part that wasn't expanded in 7.6:

                       |        +--:(evpn-bgp)
                       |           +--rw df-preference?     uint16
                       |           +--rw vpws-service-instance
                       |              ...       <============

I updated 7.6.2 to re-list "df-preference", though. 

> 
> 
> s.7.5.2 has
>    +--rw (signaling-option)?              choice
>        |     +--:(bgp)                            case
>        |     |  ...                                choice bgp-type
>        |     +--:(ldp-or-l2tp)                    case
> 
> so I expect to see
>   choice signaling-option   which I do on page 87
>   case bgp                  also on page 87
>   ....
>   case ldp-or-l2tp          nowhere to be seen.

[Med] ACK. We do basically have the following choices: 

       7.5.2.  Signaling Options . . . . . . . . . . . . . . . . . .  27
         7.5.2.1.  BGP . . . . . . . . . . . . . . . . . . . . . . .  29
         7.5.2.2.  LDP . . . . . . . . . . . . . . . . . . . . . . .  30
         7.5.2.3.  L2TP  . . . . . . . . . . . . . . . . . . . . . .  31

As discussed during the AD review, ldp-or-l2tp are bundled because they share a set of common attributes. This is why we do have this part repeated in both 7.5.2.2 and 7.5.2.3:

            |     +--:(ldp-or-l2tp)
            |        +--rw ldp-or-l2tp
            |           +--rw agi?
            |           |       rt-types:route-distinguisher
            |           +--rw saii?                      uint32
            |           +--rw remote-targets* [taii]
            |           |  +--rw taii         uint32
            |           |  +--rw peer-addr    inet:ip-address
            |           +--rw (ldp-or-l2tp)?

If we don't bundle them, we will have to use distinct names to refer to the same parameter to comply with rfc7950#section-4.2.7, which is unfortunate:

   YANG allows the data model to segregate incompatible nodes into
   distinct choices using the "choice" and "case" statements.  The
   "choice" statement contains a set of "case" statements that define
   sets of schema nodes that cannot appear together.  Each "case" may                                                    
   contain multiple nodes, but each node may appear in only one "case"
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
   under a "choice".
   ^^^^^^^^^^^^^^^^

I updated the draft to call this out: 

NEW:
   Note that LDP and L2TP choices are bundled ("ldp-or-l2tp") because
   they share a set of common parameters that are further detailed in
   Sections 7.5.2.2 and 7.5.2.3.

> In fact, there is no case, rather there is a container with that
> identifier on page 93.  This is valid  YANG - a container can
> stand in
> for a case - but with six pages of YANG in-between, this is hard
> to
> follow.  I would suggest /container/case/ or if there is a reason
> for
> not using case, then add a comment to that effect in the YANG
> module
> prior to the container statement.
> 
> Tom Petch
> 
> >
> > 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@ietf.org mailing lists by 2022-05-13. Exceptionally,
> comments may
> > be sent to iesg@ietf.org 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@ietf.org
> > 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.