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