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
