Hi Rob, Adrian,
As you may note in -14, the following reference:
[IEEE802.1Qcp-2018]
IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks--Amendment 30: YANG
Data Model", September 2018,
<https://ieeexplore.ieee.org/document/8467507>.
is listed as informative. The rationale was to align with what i2rs did (they
discussed this specific point in the context of RFC 8944).
Please advise if you think that we should change that. Thanks.
Cheers,
Med
> -----Message d'origine-----
> De : BOUCADAIR Mohamed INNOV/NET
> Envoyé : jeudi 28 avril 2022 16:53
> À : 'Rob Wilton (rwilton)' <[email protected]>
> Cc : [email protected]
> Objet : 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) <[email protected]> Envoyé : jeudi 28
> avril
> > 2022 16:23 À : 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,
> >
> > 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?
>
> > 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: [email protected]
> > > <[email protected]>
> > > Sent: 28 April 2022 13:41
> > > To: Rob Wilton (rwilton) <[email protected]>
> > > Cc: [email protected]
> > > 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) <[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
> > > > >
_________________________________________________________________________________________________________________________
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
