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: [email protected]
> <[email protected]>
> Sent: 29 April 2022 11:23
> To: Rob Wilton (rwilton) <[email protected]>
> Cc: [email protected]
> 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) <[email protected]>
> > Envoyé : vendredi 29 avril 2022 11:51
> > À : BOUCADAIR Mohamed INNOV/NET
> <[email protected]>
> > Cc : [email protected]
> > Objet : RE: OFFLIST TR: New Version Notification for draft-ietf-
> > opsawg-l2nm-13.txt
> >
> > Hi Med,
> >
> > > -----Original Message-----
> > > From: [email protected]
> > > <[email protected]>
> > > Sent: 29 April 2022 10:45
> > > To: Rob Wilton (rwilton) <[email protected]>
> > > Cc: [email protected]
> > > 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) <[email protected]> Envoyé :
> > vendredi 29
> > > > avril 2022 11:18 À : BOUCADAIR Mohamed INNOV/NET
> > > <[email protected]>
> > > > Cc : [email protected]
> > > > Objet : RE: OFFLIST TR: New Version Notification for draft-
> > ietf-
> > > > opsawg-l2nm-13.txt
> > > >
> > > > Hi Med,
> > > >
> > > > Please see inline ...
> > > >
> > > > > -----Original Message-----
> > > > > From: [email protected]
> > <[email protected]>
> > > > > Sent: 28 April 2022 15:53
> > > > > To: Rob Wilton (rwilton) <[email protected]>
> > > > > Cc: [email protected]
> > > > > 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) <[email protected]> Envoyé :
> > jeudi
> > > > 28
> > > > > > avril 2022 16:23 À : BOUCADAIR Mohamed INNOV/NET
> > > > > <[email protected]>
> > > > > > Cc : [email protected]
> > > > > > 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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
