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