Hi Med, Indeed. I've requested IETF LC.
Thank you, the other authors, and WG for their work on this model. And apologies for the slightly slow interactions during the AD review. I do believe that this work is an important piece in an overall network management architecture solution. Regards, Rob > -----Original Message----- > From: mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > Sent: 29 April 2022 14:00 > 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-, > > Thanks Rob for checking. > > A new version that implements the remaining changes is now online. > > I think that we are now ready for the IETF LC. > > Cheers, > Med > > > -----Message d'origine----- > > De : Rob Wilton (rwilton) <rwil...@cisco.com> > > Envoyé : vendredi 29 avril 2022 14:29 > > À : 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, > > > > > - translate 2 with tag-2 leaf is > > > provided: the outer tag is > > popped > > > while the inner tag is > > translated."; > > > > I think that using tag-1 leaf would be more consistent with other > > models and the CLis that I am familiar with - but possibly that is > > vendor bias. I.e., I would think that generally that tag-2 can > > only be configured if tag-1 is also configured. > > > > E.g., I think that this would be: > > > > - translate 2 with tag-1 leaf is > > provided: the outer tag is > > popped > > while the inner tag is > > translated to the value in tag-1"; > > > > But I'm okay to leave this to you - since the behaviour is well > > specified either way. > > > > Thanks, > > Rob > > > > > > > -----Original Message----- > > > From: mohamed.boucad...@orange.com > > > <mohamed.boucad...@orange.com> > > > Sent: 29 April 2022 11:23 > > > 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-, > > > > > > > I'm not that keen to binding the behaviour to the type of the > > tag, I > > > > think that what I suggested previously of indicating the > > number of > > > > tags being translated would end up being simpler and easier to > > > > understand, and besides I think that sometimes implementations > > want > > > > to change both the tag type and value. > > > > > > Noted. > > > > > > What about the following: > > > > > > leaf translate { > > > type uint8 { > > > range "1|2"; > > > } > > > description > > > "Translate one or two outer tags. > > PCP > > > bits are preserved. > > > > > > The following operations are > > > supported: > > > > > > - translate 1 with tag-1 leaf is > > > provided: only the outermost > > tag is > > > translated. > > > > > > - translate 2 with both tag-1 and > > > tag-2 leaves are provided: both > > > inner and outer tags are > > translated. > > > > > > - translate 2 with tag-2 leaf is > > > provided: the outer tag is > > popped > > > while the inner tag is > > translated."; > > > } > > > } > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Rob Wilton (rwilton) <rwil...@cisco.com> Envoyé : > > vendredi 29 > > > > avril 2022 11:51 À : 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, > > > > > > > > > -----Original Message----- > > > > > From: mohamed.boucad...@orange.com > > <mohamed.boucad...@orange.com> > > > > > Sent: 29 April 2022 10:45 > > > > > 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 > > > > > > > > > > Hi Rob, > > > > > > > > > > What we had in mind is as follows: > > > > > > > > > > The following operations are > > > > > supported: (1) Translate both the > > > > > inner and outer tags. This operation > > > > > requires providing both tag-1 and > > > > > tag-2 leaves. (2) Translate only the > > > > > outer tag. This operation requires > > > > > providing one tag with the same type > > > > > as the outer tag. (3) Translate the > > > > > inner tag while popping the outer tag. > > > > > This operation requires providing one > > > > > tag having the same type as the inner > > > > > tag."; > > > > > > > > > > I can update the description with this text. > > > > > > > > I'm not that keen to binding the behaviour to the type of the > > tag, I > > > > think that what I suggested previously of indicating the > > number of > > > > tags being translated would end up being simpler and easier to > > > > understand, and besides I think that sometimes implementations > > want > > > > to change both the tag type and value. > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Rob Wilton (rwilton) <rwil...@cisco.com> Envoyé : > > > > vendredi 29 > > > > > > avril 2022 11:18 À : 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, > > > > > > > > > > > > Please see inline ... > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mohamed.boucad...@orange.com > > > > <mohamed.boucad...@orange.com> > > > > > > > Sent: 28 April 2022 15:53 > > > > > > > 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-, > > > > > > > > > > > > > > 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? > > > > > > > > > > > > Ah, okay. > > > > > > > > > > > > The distinction I was trying to draw was how many tags are > > > > being > > > > > > logically removed and how many are being logically, with > > the > > > > > > assumption that if a tag is being both removed and added > > then > > > > in > > > > > > essence it is translated and the PCP bits are preserved. > > > > E.g., you > > > > > > could just model a translate using push 1 or 2 new tags > > and > > > > pop 1 or > > > > > > 2 tags, which IIRC, is how I model it in the VLAN sub- > > > > interface > > > > > > YANG draft. > > > > > > > > > > > > With regards to your model above: > > > > > > > > > > > > When you have only one tag (e.g., under dot1q) then you > > allow > > > > that > > > > > > single tag to be rewritten (translated) to one or two new > > > > tags. > > > > > > > > > > > > In the QinQ case, do you ever want to allow that same > > > > behaviour? > > > > > > I.e., allow only the outer tag to be rewritten > > (translated) > > > > with two > > > > > > tags (i.e., which would presumably end up with at least 3 > > tags > > > > on > > > > > > the packet). Or the reverse behaviour where you match 2 > > tags > > > > and > > > > > > want to replace both tags with a single new tag? > > > > > > > > > > > > Hence, it is unclear to me what translate operations you > > > > actually > > > > > > support for QinQ, and also whether you want to add more > > > > flexibility > > > > > > that what you currently have. But either way, I think > > that we > > > > need > > > > > > to elaborate the description to ensure that > > > > semantics/behaviour is > > > > > > really specific. > > > > > > > > > > > > Thanks, > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________________ > > > > > > > > > __________________________________________________________ > > > > > _____ > > > > > > > > > > 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. > > > __________________________________________________________ > __________________________________________________________ > _____ > > 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