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