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
