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. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg