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

[[e-mail]]

Hi Tom, 

Thanks for the follow-up.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tom petch <[e-mail]>
> Envoyé : lundi 22 novembre 2021 11:25
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> [e-mail]; [e-mail]
> Objet : Re: I-D Action: draft-ietf-opsawg-l2nm-11.txt
> 
> From: [e-mail] <[e-mail]>
> Sent: 19 November 2021 12:51
> 
> Tom,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : tom petch <[e-mail]>
> > Envoyé : vendredi 19 novembre 2021 13:22
> >
> > From: [e-mail] <[e-mail]>
> > Sent: 19 November 2021 08:48
> > Hi Tom,
> >
> > <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
> 
> [Med] Can you please be more explicit? Thanks.
> 
> <tp>
> The title of Appendix C is 'Initial PW Types'; s.8.2 contradicts that.
> 

[Med] Ah, I see. We don't have this issue anymore in -12.

> > s.8.4
> >     list y-1731 {
> >       description         "List for y-1731.";
> > but a list of what?
> 
> [Med] Updated to "List of configured Y-1731 instances".
> 
> <tp>
> good
> 
> >       leaf cos {
> >         type uint32;
> > any constraint on this rather large number?
> 
> [Med] We don't have any. Please note that the value can be passed via L2SM
> (RFC8466) which has that range.
> 
> <tp>
> sigh
> 
> >         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:-(
> 
> [Med] Not sure to get the point. Do you prefer if we use a distinct name
> for the grouping?
> 
> <tp>
> Yes on two counts.

[Med] This is now fixed in -12. Thanks. 

  One is that the fact that YANG allows the same
> identifier to appear in multiple places with a different meaning does not
> make that a good idea.; YANG can cope, humans may not. Second, having X
> made up of RD and RT and ... X looks odd, wrong even, for all values of X.
> Either the container is X or the grouping is X, but not both.  If the
> container name is right, then the grouping name is wrong.   I note that
> the description of the grouping is container for per-service parameters.
> Well it is not a container but perhaps per service is more accurate than
> global.
> 
> >             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.
> 
> [Med] Right. This was fixed as part of Adrian's review. We have now:
> 
>                 "An identifier of the network element where
>                  the VPN node is deployed. This identifier
>                  uniquely identifies the network element within
>                  an administrative domain."
> <tp>
> good
> 
> >                     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.
> 
> [Med] As I remember, we were referring to RFC3931..which points to
> rfc2072#section-8.1. We are using AS in a more general context. Do you
> have any particular change that would like to see?
> 
> <tp>
> The reference clauses are to RFC4667

[Med] Yes, I know. What I meant is that we point to Section 4.2 of RFC4667. That section points to Section 5.4.3 of RFC3931, which in turn points to Section 8.1 of RFC2072 for router-id. This is why we are using rt-types:router-id as a type. 

 which references RFC4664 which
> reference RFC4026.  I do not see Autonomous System here, perhaps provide
> network is the nearest although that may not be quite right.

[Med] Will think about this further. Thanks.

> 
> >                           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
> 
> [Med] Good catch. The tag to push is indicate din the cvlan-id. Deleted
> the sentence.
> 
> >                          leaf cvlan-id {
> >                            description
> >                              "VLAN identifier.";
> >                         leaf cvlan-id {
> >                           description
> >                             "Push/Translate vlan tags"; seems
> > inconsistent
> 
> [Med] We need this id for push or translate operations. Changed to "Push
> (or Translate)"
> 
> <tp>
> Well, the leaf is cvlan-id which is a VLAN Identifier which is what
> appears in the other description so I think something similar should
> appear here.

[Med] I think the changes in -12 fix this.

> 
> >                       leaf flow-control {
> >                         type string;
> >                          description
> >                           "Indicates whtehr flow control is ??
> 
> [Med]
> 
> > 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
> 
> [Med] Same here.
> 
> Thank you
> 
> Tom Petch

_________________________________________________________________________________________________________________________

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.