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) <[email protected]>
> Envoyé : mercredi 27 avril 2022 16:03
> À : 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,
> 
> 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: [email protected]
> > <[email protected]>
> > Sent: 14 April 2022 12:09
> > To: Rob Wilton (rwilton) <[email protected]>
> > 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 : [email protected] <[email protected]>
> Envoyé :
> > jeudi 14 avril 2022 11:56 À : Luis Angel Munoz
> > <[email protected]>; Luis Munoz <luis-
> > [email protected]>; BOUCADAIR Mohamed INNOV/NET
> > <[email protected]>; Oscar Gonzalez de Dios
> > <[email protected]>; Oscar de Dios
> > <[email protected]>; Samier Barguil
> > <[email protected]>; samier barguil
> > <[email protected]>
> > 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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to