Hi Med, Just one further tweak under QinQ:
leaf translate { type empty; description "Translate one or two outer tags. PCP bits are preserved."; } Do you need to change this to: leaf translate { type uint8 { range "1|2"; } description "Translate one or two outer tags. PCP bits are preserved."; } To indicate whether it is one or two outer tags that are being translated? E.g., trans-1-2 would be translate 1 with both tag-1/tag-1-type and tag-2/tag-2-type pushed tags. Trans-2-2 would be translate 2 + tag-1/tag-1-type and tag-2/tag-2-type. Trans-2-1 would be translate 2 + tag-1/tag-1-type. Perhaps in the descriptions for tag-1/tag-2 indicate that tag-1-type etc must be specified (or maybe add must statements to enforce this)? Alternatively could add defaults so that tag-1-type defaults to S-VLAN and tag-2-type defaults to C-VLAN? Otherwise, I think that all other changes look good. Regards, Rob > -----Original Message----- > From: mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > Sent: 28 April 2022 13:41 > To: Rob Wilton (rwilton) <rwil...@cisco.com> > Cc: opsawg@ietf.org > Subject: RE: OFFLIST TR: New Version Notification for draft-ietf-opsawg- > l2nm-13.txt > > Re-, > > All good comments. Many thanks. > > The new version -14 tries to address these comments, in particular: > * use ieee802-dot1q-types > * add explicit nodes to indicate the tag types of the manipulated tagged > * add the various clarification > > The changes can be tracked at: https://www.ietf.org/rfcdiff?url2=draft-ietf- > opsawg-l2nm-14 > > Please let me know if any further change is needed. > > Cheers, > Med > > > -----Message d'origine----- > > De : Rob Wilton (rwilton) <rwil...@cisco.com> > > Envoyé : mercredi 27 avril 2022 16:03 > > À : BOUCADAIR Mohamed INNOV/NET > <mohamed.boucad...@orange.com> > > Cc : opsawg@ietf.org > > Objet : RE: OFFLIST TR: New Version Notification for draft-ietf- > > opsawg-l2nm-13.txt > > > > Hi Med, > > > > I've replied back separately on the 2b comments. > > > > I've also includes some further comments on the VLAN tag > > manipulations here: > > > > - The description for leaf push (for both dot1q and qinq) might be > > better as "push one or two tags defined by the tag-1 and tag-2 > > leaves". > > - For tag-1 and tag-2 it might be helpful to be explicit which of > > those tags is outermost when written in the Ethernet/802.1Q frame > > header. > > - For the vlan ids, should they be restricted to 1..4094 (or you > > could reuse the vlanid type from here > > https://github.com/YangModels/yang/blob/main/standard/ieee/publish > > ed/802.1/ieee802-dot1q-types.yang). > > - The model doesn’t indicate whether the outer/inner tags that are > > pushed are C-VLAN or S-VLAN tags. In the case where two tags are > > pushed I would assume that it would be an outer S-VLAN followed by > > a inner C-VLAN, but it is somewhat ambiguous is only a single tag > > is being pushed. I think that it would be helpful for the model > > to specify the behaviour here. > > - Should the model say anything about the PCP bits if a tag is > > pushed (i.e., are then just left as 0 unless explicitly set by a > > QoS policy). Also what is the behaviour on a translate, are the > > PCP bits in the header preserved? > > - For QinQ, is only a single outer tag allowed to be translated, > > if so the description should be "translate the outer tag", > > alternatively, the type could be changed to uint16 to allow the > > number of tags to be translated to be specified. > > > > I've also checked the diffs between -12 and -13 and then look good > > to me, except that I had one further comment on the CoS: > > > > case other { > > description > > "Other bandwidth types."; > > uses bandwidth-parameters; > > } > > > > Is it possible to have a more descriptive name/description instead > > of "other"? E.g., cos-unaware? Even if you keep the existing > > name, expanding the description slightly might be helpful. > > > > Thanks, > > Rob > > > > > > > -----Original Message----- > > > From: mohamed.boucad...@orange.com > > > <mohamed.boucad...@orange.com> > > > Sent: 14 April 2022 12:09 > > > To: Rob Wilton (rwilton) <rwil...@cisco.com> > > > Subject: OFFLIST TR: New Version Notification for > > > draft-ietf-opsawg-l2nm- 13.txt > > > > > > Hi Rob, > > > > > > Please let me know if any further changes is needed. Thank you > > again > > > for the review. > > > > > > Cheers, > > > Med > > > > > > -----Message d'origine----- > > > De : internet-dra...@ietf.org <internet-dra...@ietf.org> > > Envoyé : > > > jeudi 14 avril 2022 11:56 À : Luis Angel Munoz > > > <luis-angel.mu...@vodafone.com>; Luis Munoz <luis- > > > angel.mu...@vodafone.com>; BOUCADAIR Mohamed INNOV/NET > > > <mohamed.boucad...@orange.com>; Oscar Gonzalez de Dios > > > <oscar.gonzalezded...@telefonica.com>; Oscar de Dios > > > <oscar.gonzalezded...@telefonica.com>; Samier Barguil > > > <samier.barguilgiraldo....@telefonica.com>; samier barguil > > > <samier.barguilgiraldo....@telefonica.com> > > > Objet : New Version Notification for draft-ietf-opsawg-l2nm- > > 13.txt > > > > > > > > > A new version of I-D, draft-ietf-opsawg-l2nm-13.txt has been > > > successfully submitted by Mohamed Boucadair and posted to the > > IETF repository. > > > > > > Name: draft-ietf-opsawg-l2nm > > > Revision: 13 > > > Title: A YANG Network Data Model for Layer 2 VPNs > > > Document date: 2022-04-14 > > > Group: opsawg > > > Pages: 158 > > > URL: https://www.ietf.org/archive/id/draft-ietf- > > opsawg-l2nm-13.txt > > > Status: https://datatracker.ietf.org/doc/draft-ietf- > > opsawg-l2nm/ > > > Htmlized: https://datatracker.ietf.org/doc/html/draft- > > ietf-opsawg-l2nm > > > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf- > > opsawg-l2nm-13 > > > > > > 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 IETF Secretariat > > > > > > > > > > > > > __________________________________________________________ > ______ > > > > _________________________________________________________ > > > > > > 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. > > > __________________________________________________________ > __________________________________________________________ > _____ > > 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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg