Hi Med,
Indeed. I've requested IETF LC.
Thank you, the other authors, and WG for their work on this model. And
apologies for the slightly slow interactions during the AD review. I do
believe that this work is an important piece in an overall network management
architecture solution.
Regards,
Rob
> -----Original Message-----
> From: mohamed.boucad...@orange.com
> <mohamed.boucad...@orange.com>
> Sent: 29 April 2022 14:00
> 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-,
>
> 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
