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
>
> > E.g., trans-1-2 would be translate 1 with both tag-1/tag-1-type
> > and tag-2/tag-2-type pushed tags. Trans-2-2 would be translate 2
> > + tag-1/tag-1-type and tag-2/tag-2-type. Trans-2-1 would be
> > translate 2 + tag-1/tag-1-type.
> >
> > Perhaps in the descriptions for tag-1/tag-2 indicate that tag-1-
> > type etc must be specified (or maybe add must statements to
> > enforce this)? Alternatively could add defaults so that tag-1-
> > type defaults to S-VLAN and tag-2-type defaults to C-VLAN?
> >
>
> [Med] I like using defaults. Thanks.
>
> > Otherwise, I think that all other changes look good.
> >
> > Regards,
> > Rob
> >
> >
> > > -----Original Message-----
> > > From: mohamed.boucad...@orange.com
> > > <mohamed.boucad...@orange.com>
> > > Sent: 28 April 2022 13:41
> > > 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-,
> > >
> > > All good comments. Many thanks.
> > >
> > > The new version -14 tries to address these comments, in
> > particular:
> > > * use ieee802-dot1q-types
> > > * add explicit nodes to indicate the tag types of the
> > manipulated
> > > tagged
> > > * add the various clarification
> > >
> > > The changes can be tracked at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-
> > > opsawg-l2nm-14
> > >
> > > Please let me know if any further change is needed.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Rob Wilton (rwilton) <rwil...@cisco.com> Envoyé :
> > mercredi 27
> > > > avril 2022 16:03 À : 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,
> > > >
> > > > I've replied back separately on the 2b comments.
> > > >
> > > > I've also includes some further comments on the VLAN tag
> > > > manipulations here:
> > > >
> > > > - The description for leaf push (for both dot1q and qinq)
> > might be
> > > > better as "push one or two tags defined by the tag-1 and tag-2
> > > > leaves".
> > > > - For tag-1 and tag-2 it might be helpful to be explicit which
> > of
> > > > those tags is outermost when written in the Ethernet/802.1Q
> > frame
> > > > header.
> > > > - For the vlan ids, should they be restricted to 1..4094 (or
> > you
> > > > could reuse the vlanid type from here
> > > >
> > https://github.com/YangModels/yang/blob/main/standard/ieee/publish
> > > > ed/802.1/ieee802-dot1q-types.yang).
> > > > - The model doesn’t indicate whether the outer/inner tags that
> > are
> > > > pushed are C-VLAN or S-VLAN tags. In the case where two tags
> > are
> > > > pushed I would assume that it would be an outer S-VLAN
> > followed by a
> > > > inner C-VLAN, but it is somewhat ambiguous is only a single
> > tag is
> > > > being pushed. I think that it would be helpful for the model
> > to
> > > > specify the behaviour here.
> > > > - Should the model say anything about the PCP bits if a tag is
> > > > pushed (i.e., are then just left as 0 unless explicitly set by
> > a QoS
> > > > policy). Also what is the behaviour on a translate, are the
> > PCP
> > > > bits in the header preserved?
> > > > - For QinQ, is only a single outer tag allowed to be
> > translated, if
> > > > so the description should be "translate the outer tag",
> > > > alternatively, the type could be changed to uint16 to allow
> > the
> > > > number of tags to be translated to be specified.
> > > >
> > > > I've also checked the diffs between -12 and -13 and then look
> > good
> > > > to me, except that I had one further comment on the CoS:
> > > >
> > > > case other {
> > > > description
> > > > "Other bandwidth types.";
> > > > uses bandwidth-parameters;
> > > > }
> > > >
> > > > Is it possible to have a more descriptive name/description
> > instead
> > > > of "other"? E.g., cos-unaware? Even if you keep the existing
> > name,
> > > > expanding the description slightly might be helpful.
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: mohamed.boucad...@orange.com
> > <mohamed.boucad...@orange.com>
> > > > > Sent: 14 April 2022 12:09
> > > > > To: Rob Wilton (rwilton) <rwil...@cisco.com>
> > > > > Subject: OFFLIST TR: New Version Notification for
> > > > > draft-ietf-opsawg-l2nm- 13.txt
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > Please let me know if any further changes is needed. Thank
> > you
> > > > again
> > > > > for the review.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > -----Message d'origine-----
> > > > > De : internet-dra...@ietf.org <internet-dra...@ietf.org>
> > > > Envoyé :
> > > > > jeudi 14 avril 2022 11:56 À : Luis Angel Munoz
> > > > > <luis-angel.mu...@vodafone.com>; Luis Munoz <luis-
> > > > > angel.mu...@vodafone.com>; BOUCADAIR Mohamed INNOV/NET
> > > > > <mohamed.boucad...@orange.com>; Oscar Gonzalez de Dios
> > > > > <oscar.gonzalezded...@telefonica.com>; Oscar de Dios
> > > > > <oscar.gonzalezded...@telefonica.com>; Samier Barguil
> > > > > <samier.barguilgiraldo....@telefonica.com>; samier barguil
> > > > > <samier.barguilgiraldo....@telefonica.com>
> > > > > Objet : New Version Notification for draft-ietf-opsawg-l2nm-
> > > > 13.txt
> > > > >
> > > > >
> > > > > A new version of I-D, draft-ietf-opsawg-l2nm-13.txt has been
> > > > > successfully submitted by Mohamed Boucadair and posted to
> > the
> > > > IETF repository.
> > > > >
> > > > > Name: draft-ietf-opsawg-l2nm
> > > > > Revision: 13
> > > > > Title: A YANG Network Data Model for Layer 2 VPNs
> > > > > Document date: 2022-04-14
> > > > > Group: opsawg
> > > > > Pages: 158
> > > > > URL: https://www.ietf.org/archive/id/draft-ietf-
> > > > opsawg-l2nm-13.txt
> > > > > Status: https://datatracker.ietf.org/doc/draft-ietf-
> > > > opsawg-l2nm/
> > > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-
> > > > ietf-opsawg-l2nm
> > > > > Diff: https://www.ietf.org/rfcdiff?url2=draft-
> > ietf-
> > > > opsawg-l2nm-13
> > > > >
> > > > > Abstract:
> > > > > This document defines an L2VPN Network YANG Model (L2NM)
> > > > which can
> > > > > be
> > > > > used to manage the provisioning of Layer 2 Virtual
> > Private
> > > > Network
> > > > > services within a network (e.g., service provider
> > network).
> > > > The L2NM
> > > > > complements the Layer 2 Service Model (L2SM) by providing
> > a
> > > > network-
> > > > > centric view of the service that is internal to a service
> > > > provider.
> > > > > The L2NM is particularly meant to be used by a network
> > > > controller to
> > > > > derive the configuration information that will be sent to
> > > > relevant
> > > > > network devices.
> > > > >
> > > > > Also, this document defines a YANG module to manage
> > Ethernet
> > > > segments
> > > > > and the initial versions of two IANA-maintained modules
> > that
> > > > defines
> > > > > a set of identities of BGP Layer 2 encapsulation types
> > and
> > > > pseudowire
> > > > > types.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The IETF Secretariat
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> __________________________________________________________
> > > ______
> > > > >
> > >
> _________________________________________________________
> > > > >
> > > > > 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
