Hi Med, I think that this should be a normative reference, but I don’t think that should be a problem.
Regards, Rob > -----Original Message----- > From: mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > Sent: 29 April 2022 07:34 > To: Rob Wilton (rwilton) <rwil...@cisco.com>; adr...@olddog.co.uk > Cc: opsawg@ietf.org > Subject: RE: OFFLIST TR: New Version Notification for draft-ietf-opsawg- > l2nm-13.txt > > Hi Rob, Adrian, > > As you may note in -14, the following reference: > > [IEEE802.1Qcp-2018] > IEEE, "IEEE Standard for Local and metropolitan area > networks--Bridges and Bridged Networks--Amendment 30: YANG > Data Model", September 2018, > <https://ieeexplore.ieee.org/document/8467507>. > > is listed as informative. The rationale was to align with what i2rs did (they > discussed this specific point in the context of RFC 8944). > > Please advise if you think that we should change that. Thanks. > > Cheers, > Med > > > -----Message d'origine----- > > De : BOUCADAIR Mohamed INNOV/NET > > Envoyé : jeudi 28 avril 2022 16:53 > > À : 'Rob Wilton (rwilton)' <rwil...@cisco.com> > > Cc : opsawg@ietf.org > > Objet : RE: OFFLIST TR: New Version Notification for draft-ietf- > > opsawg-l2nm-13.txt > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Rob Wilton (rwilton) <rwil...@cisco.com> Envoyé : jeudi 28 > > avril > > > 2022 16:23 À : 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, > > > > > > 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? > > > > > > > [Med] The presence of tag-1/type and/are tag-2/type is redundant > > with indicating it in the range. No? > > > > > 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? > > > > > > > [Med] I like using defaults. Thanks. > > > > > 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 > > > > > > > > __________________________________________________________ > __________________________________________________________ > _____ > > 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
