Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
Top posting on point 8. I have commented at IETF Last Call that I think that the references to 'default' in the YANG descriptions in several places is misleading. There is no default, there is no YANG default statement and YANG users will know what default means, except that here it does not. Unless you are proposing that users add deviations with default statements, which is not how I read the text, then what I see you suggest is that at different levels (and I note that you, like me, are confused about what I refer to as levels), different values are recommended. This is common practice with many specifications but they are not called defaults and I think it wrong to use the term here. Recommended value would seem what is called for. Tom Petch From: OPSAWG on behalf of Rob Wilton (rwilton) Sent: 27 April 2022 13:38 Hi Med, Catching up with email, sorry for the delay, please see further comments inline ... > -Original Message- > From: mohamed.boucad...@orange.com > > Sent: 05 April 2022 11:40 > To: Rob Wilton (rwilton) ; draft-ietf-opsawg- > l2nm@ietf.org > Cc: opsawg@ietf.org > Subject: RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part) > > Hi Rob, > > Focusing on the first part of your review, except point (9). > > The changes can be tracked at: https://github.com/IETF-OPSAWG- > WG/lxnm/commit/337f65012f55e71df4105481bc28fe53ac8bb302, while the > full changes made so far can be tracked at: https://tinyurl.com/l2nm-latest > > Please see inline for more context. > > Cheers, > Med > > > -Message d'origine- > > De : Rob Wilton (rwilton) > > Envoyé : jeudi 17 mars 2022 21:53 > > À : draft-ietf-opsawg-l2nm@ietf.org > > Cc : opsawg@ietf.org > > Objet : AD review of draft-ietf-opsawg-l2nm-12 > > > > Hi, > > > > Apologies for the delay, but I have now managed my AD review of draft- > > ietf-opsawg-l2nm-12. (Also attached in case my email is truncated ...) > > > > > > (8) Hierarchical groupings and defaults > > > > I want to check what the model/plan is regarding hierarchical config > > (e.g., grouping parameters-profile) and default values. It looks like > > some of the leaves in the provide have default values, which I believe > > will be ambiguous when it comes to hierarchical config. I.e., normally > > I would never expect that a leaf with a default value defined would fall > > back to the hierarchical policy because logically the leaf always has a > > value if it is in scope. One solution to this problem (that is a bit > > more verbose), would be to take the defaults out of the leaves in the > > grouping, and then add them back in using "refine" them using refine > > statements when the global parameters-profile is used. Another choice > > would be to not express these using the YANG "default" keyword at all, > > and instead describe the defaults in the description. > > > > Generally, defining defaults where we can is probably useful, but we > > need to be careful with any hierarchical config/policies. > > [Med] Good point. However, for the particular case of parameters-profile, > the intent is that all these parameters are factorized at the service level. > Values that have to be overridden at lower levels, will be explicitly called > and > then take precedence. At a YANG language level, I'm not convinced this works. To take an example, if you look at mac-policies: | +--rw mac-policies | | +--rw mac-addr-limit | | | +--rw limit-number?uint16 | | | +--rw time-interval? uint32 | | | +--rw action? identityref | | +--rw mac-loop-prevention | | +--rw window?uint32 | | +--rw frequency? uint32 | | +--rw retry-timer? uint32 | | +--rw protection-type? identityref Then the leaf mac-policies/mac-addr-limit/limit-number is always in scope and has a default value assigned. So, even if the global policy "foo" sets limit-number to 200, and this "foo" policy is activated for a given VPN Node then even if limit-number isn't explicitly set under active-global-parameters-profiles the default value for limit-number is in scope and hence would always override the value in the global scope. I think that the best solution here is to not have any defaults in any the leaves under the parameters-profile grouping. Where that grouping is used to define the top level global parameters then you can make use of refine statements under the "uses parameters-profile" to add default values back in only at the top level. The alternative choice is to take the "default" statements out, and put the default behaviour in the description instead, making it clear that the defaults only apply at the top level profiles. > > > > > > > (9) Various comment related to handling VLAN tag rewrites: > > > ... > > > > > > (10) > >
Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
Hi Med,
Thanks, just ack'ing that I agree with your proposed fixes, and sorry for
getting the terminology mixed up.
Thanks,
Rob
> -Original Message-
> From: mohamed.boucad...@orange.com
>
> Sent: 28 April 2022 12:27
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> l2nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
>
> Hi Rob,
>
> Thank you for the follow-up.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Rob Wilton (rwilton)
> > Envoyé : mercredi 27 avril 2022 14:38
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > draft-ietf-opsawg-l2nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
> >
> > Hi Med,
> >
> > Catching up with email, sorry for the delay, please see further
> > comments inline ...
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > >
> > > Sent: 05 April 2022 11:40
> > > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > > l2nm@ietf.org
> > > Cc: opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
> > >
> > > Hi Rob,
> > >
> > > Focusing on the first part of your review, except point (9).
> > >
> > > The changes can be tracked at: https://github.com/IETF-OPSAWG-
> > > WG/lxnm/commit/337f65012f55e71df4105481bc28fe53ac8bb302, while
> > the
> > > full changes made so far can be tracked at:
> > > https://tinyurl.com/l2nm-latest
> > >
> > > Please see inline for more context.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton) Envoyé : jeudi
> > 17 mars
> > > > 2022 21:53 À : draft-ietf-opsawg-l2nm@ietf.org
> > > > Cc : opsawg@ietf.org
> > > > Objet : AD review of draft-ietf-opsawg-l2nm-12
> > > >
> > > > Hi,
> > > >
> > > > Apologies for the delay, but I have now managed my AD review
> > of
> > > > draft- ietf-opsawg-l2nm-12. (Also attached in case my email
> > is
> > > > truncated ...)
> > > >
> > > > I would like to thank the authors, WG for their work on this
> > > > document, and the shepherd for his review. I found the
> > document to
> > > > be well written and pretty straightforward to follow and
> > understand.
> > > > I also believe that this document is a useful addition to the
> > YANG
> > > > and Network Management Ecosystem, to thank you for that.
> > > >
> > > > Anyway, here my comments. I think that they mostly pretty
> > minor,
> > > > but perhaps a few that my need a bit more thought. Hopefully
> > they
> > > > will help improve the doc.
> > > >
> > > > ---
> > > >
> > > > Moderate comments:
> > > >
> > > > (1)
> > > >The VPN network access is comprised of:
> > > >
> > > >'id': Includes an identifier of the VPN network access.
> > > >
> > > >'description': Includes a textual description of the VPN
> > > > network
> > > > access.
> > > >
> > > >'interface-id': Indicates the interface on which the VPN
> > > > network
> > > > access is bound.
> > > >
> > > >'global-parameters-profile': Provides a pointer to an
> > active
> > > > 'global-parameters-profile' at the VPN node level.
> > > > Referencing an
> > > > active 'global-parameters-profile' implies that all
> > associated
> > > > data nodes will be inherited by the VPN network
> > access.
> > > > However,
> > > > some of the inherited data nodes (e.g., ACL policies)
> > can be
> > > > overridden at the VPN network access level. In such
> > case,
> > > > adjusted values take precedence over inherited ones.
> > > >
> > > > It wasn't entirely clear to me how this works with the global
> > > > parameters defined at the VPN network access level and the VPN
> > node
> > > > level work. Is this meant to be a 3 tier hierarchy, or is it
> > always
> > > > only 2 tiers? Are you allowed to reference different global
> > > > profiles both at the VPN network access level and the VPN node
> > > > level? Possibly, some slightly expanded description here may
> > be helpful (and/or in the YANG module).
> > > >
> > > >
> > >
> > > [Med] Isn't this covered by this text:
> > >
> > >The 'global-parameters-profile' defines reusable parameters
> > for the
> > >same L2VPN service instance ('vpn-service'). Global
> > parameters
> > >profile are defined at the VPN service level and then called
> > at the
> > >VPN node and VPN network access levels. Each VPN instance
> > profile is
> > >identified by 'profile-id'. Some of the data nodes can be
> > adjusted
> > >at the VPN node or VPN network access levels. These adjusted
> > values
> > >take precedence over the global ones. The subtree of
> > 'global-
> > >parameters-profile' is depicted in Figure 7.
> >
> > I think that have figured this out. My understanding is:
> > 1) 1 or m
Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
Hi Rob,
Thank you for the follow-up.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Rob Wilton (rwilton)
> Envoyé : mercredi 27 avril 2022 14:38
> À : BOUCADAIR Mohamed INNOV/NET ;
> draft-ietf-opsawg-l2nm@ietf.org
> Cc : opsawg@ietf.org
> Objet : RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
>
> Hi Med,
>
> Catching up with email, sorry for the delay, please see further
> comments inline ...
>
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> >
> > Sent: 05 April 2022 11:40
> > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > l2nm@ietf.org
> > Cc: opsawg@ietf.org
> > Subject: RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
> >
> > Hi Rob,
> >
> > Focusing on the first part of your review, except point (9).
> >
> > The changes can be tracked at: https://github.com/IETF-OPSAWG-
> > WG/lxnm/commit/337f65012f55e71df4105481bc28fe53ac8bb302, while
> the
> > full changes made so far can be tracked at:
> > https://tinyurl.com/l2nm-latest
> >
> > Please see inline for more context.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Rob Wilton (rwilton) Envoyé : jeudi
> 17 mars
> > > 2022 21:53 À : draft-ietf-opsawg-l2nm@ietf.org
> > > Cc : opsawg@ietf.org
> > > Objet : AD review of draft-ietf-opsawg-l2nm-12
> > >
> > > Hi,
> > >
> > > Apologies for the delay, but I have now managed my AD review
> of
> > > draft- ietf-opsawg-l2nm-12. (Also attached in case my email
> is
> > > truncated ...)
> > >
> > > I would like to thank the authors, WG for their work on this
> > > document, and the shepherd for his review. I found the
> document to
> > > be well written and pretty straightforward to follow and
> understand.
> > > I also believe that this document is a useful addition to the
> YANG
> > > and Network Management Ecosystem, to thank you for that.
> > >
> > > Anyway, here my comments. I think that they mostly pretty
> minor,
> > > but perhaps a few that my need a bit more thought. Hopefully
> they
> > > will help improve the doc.
> > >
> > > ---
> > >
> > > Moderate comments:
> > >
> > > (1)
> > > The VPN network access is comprised of:
> > >
> > > 'id': Includes an identifier of the VPN network access.
> > >
> > > 'description': Includes a textual description of the VPN
> > > network
> > > access.
> > >
> > > 'interface-id': Indicates the interface on which the VPN
> > > network
> > > access is bound.
> > >
> > > 'global-parameters-profile': Provides a pointer to an
> active
> > > 'global-parameters-profile' at the VPN node level.
> > > Referencing an
> > > active 'global-parameters-profile' implies that all
> associated
> > > data nodes will be inherited by the VPN network
> access.
> > > However,
> > > some of the inherited data nodes (e.g., ACL policies)
> can be
> > > overridden at the VPN network access level. In such
> case,
> > > adjusted values take precedence over inherited ones.
> > >
> > > It wasn't entirely clear to me how this works with the global
> > > parameters defined at the VPN network access level and the VPN
> node
> > > level work. Is this meant to be a 3 tier hierarchy, or is it
> always
> > > only 2 tiers? Are you allowed to reference different global
> > > profiles both at the VPN network access level and the VPN node
> > > level? Possibly, some slightly expanded description here may
> be helpful (and/or in the YANG module).
> > >
> > >
> >
> > [Med] Isn't this covered by this text:
> >
> >The 'global-parameters-profile' defines reusable parameters
> for the
> >same L2VPN service instance ('vpn-service'). Global
> parameters
> >profile are defined at the VPN service level and then called
> at the
> >VPN node and VPN network access levels. Each VPN instance
> profile is
> >identified by 'profile-id'. Some of the data nodes can be
> adjusted
> >at the VPN node or VPN network access levels. These adjusted
> values
> >take precedence over the global ones. The subtree of
> 'global-
> >parameters-profile' is depicted in Figure 7.
>
> I think that have figured this out. My understanding is:
> 1) 1 or more profiles can be defined globally with particular
> parameters.
[Med] These are defined for a specific service, not reused between services.
> 2) Each VPN service can activate a subset of those global
> profiles, overriding parameters if they wish (need to check
> defaults).
[Med] Yes but with s/VPN service/vpn-node.
> 3) Each vpn-node may reference one of the active "global-
> parameters-profiles".
[Med] Yes but with s/vpn-node/vpn-network-access.
>
> Is this correct?
>
> I will note that the model doesn't allow a single global profile
> to create two slightly different vpn-node profiles based on the
> same global profile (since the names match at all levels).
> Possibly this is a good thing to avoid any possible co
Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
Hi Med,
Catching up with email, sorry for the delay, please see further comments inline
...
> -Original Message-
> From: mohamed.boucad...@orange.com
>
> Sent: 05 April 2022 11:40
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> l2nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
>
> Hi Rob,
>
> Focusing on the first part of your review, except point (9).
>
> The changes can be tracked at: https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/337f65012f55e71df4105481bc28fe53ac8bb302, while the
> full changes made so far can be tracked at: https://tinyurl.com/l2nm-latest
>
> Please see inline for more context.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Rob Wilton (rwilton)
> > Envoyé : jeudi 17 mars 2022 21:53
> > À : draft-ietf-opsawg-l2nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : AD review of draft-ietf-opsawg-l2nm-12
> >
> > Hi,
> >
> > Apologies for the delay, but I have now managed my AD review of draft-
> > ietf-opsawg-l2nm-12. (Also attached in case my email is truncated ...)
> >
> > I would like to thank the authors, WG for their work on this document,
> > and the shepherd for his review. I found the document to be well
> > written and pretty straightforward to follow and understand. I also
> > believe that this document is a useful addition to the YANG and Network
> > Management Ecosystem, to thank you for that.
> >
> > Anyway, here my comments. I think that they mostly pretty minor, but
> > perhaps a few that my need a bit more thought. Hopefully they will help
> > improve the doc.
> >
> > ---
> >
> > Moderate comments:
> >
> > (1)
> >The VPN network access is comprised of:
> >
> >'id': Includes an identifier of the VPN network access.
> >
> >'description': Includes a textual description of the VPN
> > network
> > access.
> >
> >'interface-id': Indicates the interface on which the VPN
> > network
> > access is bound.
> >
> >'global-parameters-profile': Provides a pointer to an active
> > 'global-parameters-profile' at the VPN node level.
> > Referencing an
> > active 'global-parameters-profile' implies that all
> > associated
> > data nodes will be inherited by the VPN network access.
> > However,
> > some of the inherited data nodes (e.g., ACL policies) can
> > be
> > overridden at the VPN network access level. In such case,
> > adjusted values take precedence over inherited ones.
> >
> > It wasn't entirely clear to me how this works with the global parameters
> > defined at the VPN network access level and the VPN node level work. Is
> > this meant to be a 3 tier hierarchy, or is it always only 2 tiers? Are
> > you allowed to reference different global profiles both at the VPN
> > network access level and the VPN node level? Possibly, some slightly
> > expanded description here may be helpful (and/or in the YANG module).
> >
> >
>
> [Med] Isn't this covered by this text:
>
>The 'global-parameters-profile' defines reusable parameters for the
>same L2VPN service instance ('vpn-service'). Global parameters
>profile are defined at the VPN service level and then called at the
>VPN node and VPN network access levels. Each VPN instance profile is
>identified by 'profile-id'. Some of the data nodes can be adjusted
>at the VPN node or VPN network access levels. These adjusted values
>take precedence over the global ones. The subtree of 'global-
>parameters-profile' is depicted in Figure 7.
I think that have figured this out. My understanding is:
1) 1 or more profiles can be defined globally with particular parameters.
2) Each VPN service can activate a subset of those global profiles, overriding
parameters if they wish (need to check defaults).
3) Each vpn-node may reference one of the active "global-parameters-profiles".
Is this correct?
I will note that the model doesn't allow a single global profile to create two
slightly different vpn-node profiles based on the same global profile (since
the names match at all levels). Possibly this is a good thing to avoid any
possible confusion, but I wanted to ensure that you had noted it.
I still think that clarifying some of this text might be helpful in a couple of
ways:
(i) In 7.4, possibly tweak the text something like:
OLD
The 'global-parameters-profile' defines reusable parameters for the
same L2VPN service instance ('vpn-service'). Global parameters
profile are defined at the VPN service level and then called at the
VPN node and VPN network access levels. Each VPN instance profile is
identified by 'profile-id'. Some of the data nodes can be adjusted
at the VPN node or VPN network access levels. These adjusted values
take precedence over the global values. The subtree of 'global-
PROPOSED:
The 'global-parameters-profile' de
Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
Hi Rob,
The draft is now updated to address you point (9) on tag operations. The
changes can be tracked using the same diff: https://tinyurl.com/l2nm-latest
The candidate version takes into account all your comments.
Cheers,
Med
> -Message d'origine-
> De : OPSAWG De la part de
> mohamed.boucad...@orange.com
> Envoyé : mardi 5 avril 2022 12:40
> À : Rob Wilton (rwilton) ; draft-ietf-opsawg-
> l2nm@ietf.org
> Cc : opsawg@ietf.org
> Objet : Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n
> Part)
>
> Hi Rob,
>
> Focusing on the first part of your review, except point (9).
>
> The changes can be tracked at: https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/337f65012f55e71df4105481bc28fe53ac8bb302, while the
> full changes made so far can be tracked at:
> https://tinyurl.com/l2nm-latest
>
> Please see inline for more context.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Rob Wilton (rwilton) Envoyé : jeudi 17
> mars
> > 2022 21:53 À : draft-ietf-opsawg-l2nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : AD review of draft-ietf-opsawg-l2nm-12
> >
> > Hi,
> >
> > Apologies for the delay, but I have now managed my AD review of
> draft-
> > ietf-opsawg-l2nm-12. (Also attached in case my email is
> truncated
> > ...)
> >
> > I would like to thank the authors, WG for their work on this
> document,
> > and the shepherd for his review. I found the document to be
> well
> > written and pretty straightforward to follow and understand. I
> also
> > believe that this document is a useful addition to the YANG and
> > Network Management Ecosystem, to thank you for that.
> >
> > Anyway, here my comments. I think that they mostly pretty
> minor, but
> > perhaps a few that my need a bit more thought. Hopefully they
> will
> > help improve the doc.
> >
> > ---
> >
> > Moderate comments:
> >
> > (1)
> >The VPN network access is comprised of:
> >
> >'id': Includes an identifier of the VPN network access.
> >
> >'description': Includes a textual description of the VPN
> network
> > access.
> >
> >'interface-id': Indicates the interface on which the VPN
> network
> > access is bound.
> >
> >'global-parameters-profile': Provides a pointer to an
> active
> > 'global-parameters-profile' at the VPN node level.
> > Referencing an
> > active 'global-parameters-profile' implies that all
> associated
> > data nodes will be inherited by the VPN network
> access.
> > However,
> > some of the inherited data nodes (e.g., ACL policies)
> can be
> > overridden at the VPN network access level. In such
> case,
> > adjusted values take precedence over inherited ones.
> >
> > It wasn't entirely clear to me how this works with the global
> > parameters defined at the VPN network access level and the VPN
> node
> > level work. Is this meant to be a 3 tier hierarchy, or is it
> always
> > only 2 tiers? Are you allowed to reference different global
> profiles
> > both at the VPN network access level and the VPN node level?
> > Possibly, some slightly expanded description here may be helpful
> (and/or in the YANG module).
> >
> >
>
> [Med] Isn't this covered by this text:
>
>The 'global-parameters-profile' defines reusable parameters for
> the
>same L2VPN service instance ('vpn-service'). Global parameters
>profile are defined at the VPN service level and then called at
> the
>VPN node and VPN network access levels. Each VPN instance
> profile is
>identified by 'profile-id'. Some of the data nodes can be
> adjusted
>at the VPN node or VPN network access levels. These adjusted
> values
>take precedence over the global ones. The subtree of 'global-
>parameters-profile' is depicted in Figure 7.
>
>
> > (2) | +--rw encapsulation
> > | | +--rw encap-type?
> identityref
> > | | +--rw dot1q
> > | | | +--rw tag-type? identityref
> > | | | +--rw cvlan-id? uint16
> >
> > Did you consider adding support for ranges or sets of VLAN Ids
> (e.g.,
> > a list of non-overlapping ranges) (both for the single a
Re: [OPSAWG] AD review of draft-ietf-opsawg-l2nm-12 (2n Part)
Hi Rob,
Focusing on the first part of your review, except point (9).
The changes can be tracked at:
https://github.com/IETF-OPSAWG-WG/lxnm/commit/337f65012f55e71df4105481bc28fe53ac8bb302,
while the full changes made so far can be tracked at:
https://tinyurl.com/l2nm-latest
Please see inline for more context.
Cheers,
Med
> -Message d'origine-
> De : Rob Wilton (rwilton)
> Envoyé : jeudi 17 mars 2022 21:53
> À : draft-ietf-opsawg-l2nm@ietf.org
> Cc : opsawg@ietf.org
> Objet : AD review of draft-ietf-opsawg-l2nm-12
>
> Hi,
>
> Apologies for the delay, but I have now managed my AD review of draft-
> ietf-opsawg-l2nm-12. (Also attached in case my email is truncated ...)
>
> I would like to thank the authors, WG for their work on this document,
> and the shepherd for his review. I found the document to be well
> written and pretty straightforward to follow and understand. I also
> believe that this document is a useful addition to the YANG and Network
> Management Ecosystem, to thank you for that.
>
> Anyway, here my comments. I think that they mostly pretty minor, but
> perhaps a few that my need a bit more thought. Hopefully they will help
> improve the doc.
>
> ---
>
> Moderate comments:
>
> (1)
> The VPN network access is comprised of:
>
> 'id': Includes an identifier of the VPN network access.
>
> 'description': Includes a textual description of the VPN
> network
> access.
>
> 'interface-id': Indicates the interface on which the VPN
> network
> access is bound.
>
> 'global-parameters-profile': Provides a pointer to an active
> 'global-parameters-profile' at the VPN node level.
> Referencing an
> active 'global-parameters-profile' implies that all
> associated
> data nodes will be inherited by the VPN network access.
> However,
> some of the inherited data nodes (e.g., ACL policies) can
> be
> overridden at the VPN network access level. In such case,
> adjusted values take precedence over inherited ones.
>
> It wasn't entirely clear to me how this works with the global parameters
> defined at the VPN network access level and the VPN node level work. Is
> this meant to be a 3 tier hierarchy, or is it always only 2 tiers? Are
> you allowed to reference different global profiles both at the VPN
> network access level and the VPN node level? Possibly, some slightly
> expanded description here may be helpful (and/or in the YANG module).
>
>
[Med] Isn't this covered by this text:
The 'global-parameters-profile' defines reusable parameters for the
same L2VPN service instance ('vpn-service'). Global parameters
profile are defined at the VPN service level and then called at the
VPN node and VPN network access levels. Each VPN instance profile is
identified by 'profile-id'. Some of the data nodes can be adjusted
at the VPN node or VPN network access levels. These adjusted values
take precedence over the global ones. The subtree of 'global-
parameters-profile' is depicted in Figure 7.
> (2) | +--rw encapsulation
> | | +--rw encap-type?identityref
> | | +--rw dot1q
> | | | +--rw tag-type? identityref
> | | | +--rw cvlan-id? uint16
>
> Did you consider adding support for ranges or sets of VLAN Ids (e.g., a
> list of non-overlapping ranges) (both for the single and double tagged
> cases)?
>
[Med] We didn't. We went for the same structure as we have in RFC9182.
>
> (3) | +--rw lag-interface
>
> I'm slightly surprised that you don't have parameters for the physical
> interfaces, and I can understand your justification for this, but then
> you do have configuration for LAG, including configuration for the
> underlying member interfaces. This feels slightly inconsistent to me at
> the level that the configuration is being provided. Understanding the
> rationale a bit more here might be helpful, and I think that we should
> double check that this should definitely be in this model.
>
[Med] We spent many cycles on this one (see the full list of related issues at
https://github.com/IETF-OPSAWG-WG/lxnm/issues?q=lag). There was an agreement
that LAG-related details are generic and can be defined outside the L2NM.
However, we included some of this information because we need LACP
configuration for the ESI auto-assignment mode based on LACP configuration
(https://github.com/IETF-OPSAWG-WG/lxnm/issues/219).
>
> (4)+--rw svc-pe-to-ce-bandwidth
> | {vpn-common:inbound-bw}?
> | +--rw pe-to-ce-bandwidth* [bw-type]
>
> Can you specify different bandwidths for multiple CoS fields? It looks
> l
