Re: [OPSAWG] I-D Action: draft-ietf-opsawg-l2nm-11.txt

[tom petch <[e-mail]>]

From: [e-mail] <[e-mail]>
Sent: 19 November 2021 08:48
Hi Tom,

Thank you for checking. Will fix as appropriate.

<tp>


Some additional editorial comments on -11

s.8.2
 Appendix C lists the initial values included in the
   "iana-bgp-l2-encaps" YANG module.
That is not what I see

s.8.4
    list y-1731 {
      description         "List for y-1731.";
but a list of what?

      leaf cos {
        type uint32;
any constraint on this rather large number?

        container global-parameters-profiles {
          list global-parameters-profile {
            uses route-distinguisher;
            uses vpn-route-targets;
            uses global-parameters-profile;
seems an oxymoron; either the list is global-parameters-profile or the
grouping is  but as the list is also RD and RT that seems a
contradiction.  Also while YANG can cope with the same identifier in
different namespaces, humans might not:-(

            leaf ne-id {
              description   "Indicates the node's IP address.";
 seems to contradict
       p.25   'ne-id':  Includes a unique identifier of the network
element where
                 the VPN node is deployed.

                    case l2tp {
..            leaf router-id {
              description
                "A 32-bit number in the dotted-quad format that is
                 used to uniquely identify a node within an
                 autonomous system (AS). ";
the concept of an AS seems alien in a VPN as is to some extent a node
rather the reference seems to be to PE.  RFC4667 has 'establishes the
unique identity of each PE' for router-id.


                          leaf push {
                            type empty;
                            description
                              "Standard tag Push.
                               The number of 802.1Q tags to push on the
                               front of the frame.";
I am puzzled how empty can be a number

                         leaf cvlan-id {
                           description
                             "VLAN identifier.";
                        leaf cvlan-id {
                          description
                            "Push/Translate vlan tags";
seems inconsistent

                      leaf flow-control {
                        type string;
                         description
                          "Indicates whtehr flow control is
??


s.11.1
              IEEE, "802.1ag - 2007 - IEEE Standard for Local and
The IEEE website tells me that this is superseded but I cannot see what
by

Tom Petch


> >>
> >>> > -----Message d'origine-----
> >>> > De : OPSAWG <[e-mail]> De la part de internet-
> >>> > [e-mail] Envoyé : mardi 16 novembre 2021 17:38 À :
> >>> >
> >>> >
> >>> > 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-11.txt
>














Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : tom petch <[e-mail]>
> Envoyé : jeudi 18 novembre 2021 11:54
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> [e-mail]; [e-mail]
> Objet : Re: I-D Action: draft-ietf-opsawg-l2nm-09.txt
>
> From: [e-mail] <[e-mail]>
> Sent: 08 November 2021 14:19
>
> Hi Tom,
>
> <tp>
> It looks like Figure 15 is out of line with the YANG in both -09 and -10
>
> Figure 15 has
>     leaf translate
>   leaf cvlan-id
>   leaf mode
> where in the YANG it would appear to be
>     leaf translate
>   leaf cvlan-id
>   leaf direction
>
> tom petch
>
>
>
> I confirm that Figure 12 is correct.
>
> What is authoritative is the YANG module. We provided the reader with
> instructions to generate the full tree:
>
>    The full tree diagram of the module can be generated using the
>    "pyang" tool [PYANG].
>
> It is much more easier to include the full tree and update it once when
> the module is touched but having a tree spanning dozens of pages is not
> usable. This is why we are using subtrees:
>
>    That tree is not included here because it is
>    too long (Section 3.3 of [RFC8340]).  Instead, subtrees are provided
>    for the reader's convenience.
>
> However, this approach has some cons as we need to check manually many
> many figures. We are doing our best to maintain up-to-date subtrees ...
> but bugs happen.
>
> Thank you for helping identifying some of those.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : tom petch <[e-mail]>
> > Envoyé : lundi 8 novembre 2021 13:51
>
>
> > From: [e-mail] <[e-mail]>
> > Sent: 08 November 2021 07:38
> > Hi Adrian, Tom, all,
> >
> > The comments raised by Tom are now addressed in -10.
> >
> > <tp A fresh comment on -09 which also applies to -10.
> > In Figure 12 I see
> >              |           +--rw saii?                      uint32
> >              |           +--rw remote-targets* [taii]
> >              |           |  +--rw taii         uint32
> >              |           |  +--rw peer-addr    inet:ip-address
> >  while in Figure 13 I see
> >              |           +--rw saii?                      uint32
> >              |           +--rw remote-target* [peer-addr taii]
> >              |           |  +--rw peer-addr    inet:ip-address
> >              |           |  +--rw taii         uint32
> >
> > i.e. a change of identifier for the list, a change in keys, a change
> > in leaf order.  The YANG suggests that Figure 13 is wrong.  More
> > fundamentally, YANG tree diagrams are an aid to understanding and
> > reviewing especially with a module as big as this.  If they cannot be
> > trusted, then what can?
> >
> > Tom Petch
> >
> >
> > Two comments on idnits:
> >
> > (1) obsolete reference:
> >
> >   -- Obsolete informational reference (is this intentional?): RFC 5143
> >      (Obsoleted by RFC 4842)
> >
> > This is on purpose as we are following what is in:
> > https://www.iana.org/assignments/pwe3-parameters/pwe3-
> > parameters.xhtml#pwe3-parameters-2.
> >
> > (2) long lines:
> >
> > idnits is clean when I run it prior to submission:
> >
> > ==
> >
> >   Checking nits according to https://www.ietf.org/id-info/checklist :
> >
> > ----------------------------------------------------------------------
> > --
> > ----
> >
> >      No issues found here.
> > ==
> >
> > However, the datatracker displays the following after submission:
> >
> > ==
> >   Checking nits according to https://www.ietf.org/id-info/checklist :
> >
> > ----------------------------------------------------------------------
> > --
> > ----
> >
> >   ** There are 132 instances of too long lines in the document, the
> > longest
> >      one being 3 characters in excess of 72.
> > ==
> >
> > Will see how to fix this.
> >
> > Cheers,
> > Med
> >
> >
> > > -----Message d'origine-----
> > > De : Adrian Farrel <[e-mail]> Envoyé : lundi 1 novembre
> > > 2021 13:57 À : 'tom petch' <[e-mail]>; BOUCADAIR Mohamed
> >
>  >
> > > Useful comments, thanks Tom.
> > >
> > > Authors, please run idnits and fix issues. Also address Tom's
> comments.
> > >
> > > I'll be doing my shepherd review this week. Hopefully you can post a
> > > new revision when the gates open next Monday.
> > >
> > > Cheers,
> > > Adrian
> > >
> > > -----Original Message-----
> > > From: tom petch <[e-mail]>
> > > Sent: 01 November 2021 12:48
>
>
> > > From: OPSAWG <[e-mail]> on behalf of
> > > [e-mail] <[e-mail]>
> > > Sent: 20 October 2021 09:49
> > > Hi all,
> > >
> > > After discussing with Adrian, we are publishing this version that
> > > addresses a recent comment from Julian. For more context, please
> > > refer to https://github.com/IETF-OPSAWG-WG/lxnm/issues/350.
> > >
> > > <tp>
> > > Some stray thoughts
> > >
> > > some lines are 90 characters long
> > >
> > > 802.1ah is referenced but not in I-D References 802.3ah ditto
> > > 802.1ag Amendment 5 looks like a separate document warranting a
> > > separate reference 802.1p is referenced implicitly 802.1Q likewise
> > >
> > > What is the difference between
> > > identity bgp-l2encaps-type
> > >   Base BGP L2 encapsulation type
> > >      and
> > > identity iana-pw-types
> > >  Base BGP L2 encapsulation type
> > >
> > > ccm-priority-type
> > > what is high what low?
> > >
> > > Local Maintenance End Point (MEP)
> > > This is not the expansion used by the ITU-T
> > >
> > > leaf split-horizon-filtering
> > > what does true mean?
> > >
> > > leaf ccm-interval
> > > no units
> > >
> > > leaf ccm-holdtime
> > > no units
> > >
> > > leaf duplicate-ip-detection-interval no units
> > >
> > > leaf duplicate-ip-detection-interval no units
> > >
> > >
> > > Tom Petch
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : I-D-Announce <[e-mail]> De la part de
> > > > internet- [e-mail] Envoyé : mercredi 20 octobre 2021 10:34 À
> :
> > > > [e-mail] Cc : [e-mail] Objet : I-D Action:


_________________________________________________________________________________________________________________________

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.