Re: [OPSAWG] AD review of draft-ietf-opsawg-vpn-common-08

[Rob Wilton (rwilton)]

Hi Med,

[Just to also close this thread/review.]

I think that you are good to go.

Thanks for accommodating my comments.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 13 July 2021 16:17
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-vpn-
> common@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-vpn-common-08
> 
> Re-,
> 
> I updated the file to take into account your feedback:
> 
> * Module: https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/fcc9f6c1e79d5074469fe454d95770fe9f1becdb (in addition
> to the changes already reported as part of the L3NM review).
> * I-D: https://tinyurl.com/vpn-common-latest
> 
> Unless you have further comments, I will contact the secretariat to publish
> this version. Thanks.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : mardi 13 juillet 2021 16:25
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > draft-ietf-opsawg-vpn-common@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-vpn-common-08
> >
> > Hi Med,
> >
> > Please see inline, just a couple of points to resolve ...
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 12 July 2021 18:35
> > > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > vpn-
> > > common@ietf.org
> > > Cc: opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-vpn-common-08
> > >
> > > Hi Rob,
> > >
> > > Many thanks for the review. A candidate updated version can be
> > seen at:
> > > https://tinyurl.com/vpn-common-latest
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com] Envoyé :
> > lundi
> > > > 12 juillet 2021 17:15 À : draft-ietf-opsawg-vpn-
> > common@ietf.org
> > > > Cc : opsawg@ietf.org
> > > > Objet : AD review of draft-ietf-opsawg-vpn-common-08
> > > >
> > > > Hi,
> > > >
> > > > This is my AD review of draft-ietf-opsawg-vpn-common-08.
> > > >
> > > > Thank you for this document.  Again, just minor
> > > > comments/suggestions.
> > > >
> > > >
> > > >
> > > > 1.
> > > > In section 3.  Description of the VPN Common YANG Module
> > > > "Encapsulation features  such as" -> "Encapsulation features.
> > Such
> > > > as"
> > > > "Routing features  such as" -> "Routing features.  Such as"
> > > >
> > >
> > > [Med] Fixed.
> >
> >
> > Okay.
> >
> > >
> > > > 2.
> > > > As a very minor comment.  Where you have lists (i.e.,
> > encapsulation
> > > > features, routing features, service type) and particularly
> > because
> > > > they have references, it may be slightly easier to read if the
> > list
> > > > was indented.  Also does it make sense for this list to just be
> > > > examples, or are they actually normative lists of service types
> > that
> > > > are supported?
> > >
> > > [Med] Sure. These are only examples. We cite them as we need to
> > list
> > > include in the main text any reference quoted in the module.
> >
> > Okay.
> >
> >
> > >
> > > >
> > > > E.g.,
> > > >'service-type':  Used to identify the VPN service type.
> > > >   Examples of supported service types are:
> > > >
> > > >   o L3VPN,
> > > >
> > > >   o Virtual Private LAN Service (VPLS) using BGP [RFC4761],
> > > >
> > > >   o VPLS using Label Distribution Protocol (LDP) [RFC4762],
> > > >
> > > >   o Virtual Private Wire Service (VPWS) [RFC8214],
> > > >
> > > >   o BGP MPLS-Based Ethernet VPN [RFC7432],
> > > >
> > > >   o Ethernet VPN (EVPN) [RFC8365], and
> > > >
> > > >   o Provider Backbone Bridging Combined with Ethernet
> > > > VPN (PBB-EVPN) [RFC7623].
> > > >
> > > >
> > > > In the Yang Module:
> > > >
> > > > 3. OPSA => OPSAWG
> > > > Please can you check if this needs to be fixed for the L3NM YANG
> > > > model as well.
> > >
> > > [Med] Fixed.
> >
> > Okay.
> >
> > >
> > > >
> > > > 4.
> > > >   feature qinany {
> > > > description
> > > >   "Indicates the support of the QinAny encapsulation.";
> > > >   }
> > > >
> > > > Is there a reference, or perhaps a more detailed description
> > that
> > > > you can use here?
> > > >
> > >
> > > [Med] This was also a comment raised in the WGLC, but we don't
> > have
> > > any acceptable authoritative reference to cite for it.
> >
> > Okay, then perhaps give a brief description of what QinAny means,
> > i.e., in this context I think that frames have a pair of VLAN Ids,
> > where the outer VLAN Id is fixed, but the inner VLAN Id can take any
> > valid VLAN Id value.
> 
> [Med] Added a note to the module.
> 
> >
> >
> > >
> > > > 5.
> > > > Very minor:
> > > > feature ipv4, feature ipv6, is it worth adding references to the
> > > > RFCs?  I appreciate that they are obvious, but since you have
> > > > references for everything else, it seems like it might be worth
> > > > 

Re: [OPSAWG] AD review of draft-ietf-opsawg-l3sm-l3nm-09

[Rob Wilton (rwilton)]

Hi Med,

I think that you are good to go.

Thanks for accommodating my comments.

Regards,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 13 July 2021 17:04
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-l3sm-
> l3nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> 
> Re-,
> 
> Please see inline.
> 
> Cheeers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : mardi 13 juillet 2021 17:55
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > draft-ietf-opsawg-l3sm-l3nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> >
> > Hi Med,
> >
> > Looking at the diff, I think that you have a typo for "oubound".
> 
> [Med] Will be fixed.
> 
> >
> > But just to check, the "inbound-rate-limit" and "inbound-bandwidth"
> > both act in the same direction, right?
> 
> [Med] Yes. The text says inbound-rate-limit is a % of inbound-bandwidth.
> 
> The text also indicates that the direction is from the perspective of the
> customer site. That definition is also inherited from the common module. We
> don't revert the directions to ease the mapping between L3SM and L3NM.
> 
> 
>   That was the consistency
> > that I was striving for.  Normally, when I think of a QoS policy as
> > acting on say a PE interface, I think that inbound/outbound would
> > have the reverse sense to have the input-bandwidth/outbound-
> > bandwidth is described.   I think that it would be good for these
> > directions to be consistency if possible, but at a minimum the
> > description needs to be very clear and using input vs inbound
> > perhaps makes more sense if they are acting in different directions.
> >
> > Thanks,
> > Rob
> >
> 
> 
> 
> _
> 
> 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

Re: [OPSAWG] AD review of draft-ietf-opsawg-l3sm-l3nm-09

[mohamed.boucadair]

Re-,

Please see inline. 

Cheeers,
Med

> -Message d'origine-
> De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> Envoyé : mardi 13 juillet 2021 17:55
> À : BOUCADAIR Mohamed INNOV/NET ;
> draft-ietf-opsawg-l3sm-l3nm@ietf.org
> Cc : opsawg@ietf.org
> Objet : RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> 
> Hi Med,
> 
> Looking at the diff, I think that you have a typo for "oubound".

[Med] Will be fixed. 

> 
> But just to check, the "inbound-rate-limit" and "inbound-bandwidth"
> both act in the same direction, right?

[Med] Yes. The text says inbound-rate-limit is a % of inbound-bandwidth.

The text also indicates that the direction is from the perspective of the 
customer site. That definition is also inherited from the common module. We 
don't revert the directions to ease the mapping between L3SM and L3NM. 


  That was the consistency
> that I was striving for.  Normally, when I think of a QoS policy as
> acting on say a PE interface, I think that inbound/outbound would
> have the reverse sense to have the input-bandwidth/outbound-
> bandwidth is described.   I think that it would be good for these
> directions to be consistency if possible, but at a minimum the
> description needs to be very clear and using input vs inbound
> perhaps makes more sense if they are acting in different directions.
> 
> Thanks,
> Rob
> 


_

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

Re: [OPSAWG] AD review of draft-ietf-opsawg-l3sm-l3nm-09

[Rob Wilton (rwilton)]

Hi Med,

Looking at the diff, I think that you have a typo for "oubound".

But just to check, the "inbound-rate-limit" and "inbound-bandwidth" both act in 
the same direction, right?  That was the consistency that I was striving for.  
Normally, when I think of a QoS policy as acting on say a PE interface, I think 
that inbound/outbound would have the reverse sense to have the 
input-bandwidth/outbound-bandwidth is described.   I think that it would be 
good for these directions to be consistency if possible, but at a minimum the 
description needs to be very clear and using input vs inbound perhaps makes 
more sense if they are acting in different directions.

Thanks,
Rob


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 13 July 2021 15:42
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-l3sm-
> l3nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> 
> Ho Rob,
> 
> I updated the files to take into account your feedback:
> 
> * Fix input/output in the common I-D (diff): https://github.com/IETF-
> OPSAWG-WG/lxnm/commit/ff456448a9398311457eb51c1d78adc8210fd8f8
> * L3NM (diff): https://github.com/IETF-OPSAWG-
> WG/lxnm/commit/ed48b938990e6e7e4be7e329d986592ebcdc0c37
> * I-D (diff): https://tinyurl.com/l3nm-latest
> 
> Please see inline for the context.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : mardi 13 juillet 2021 14:52
> > À : BOUCADAIR Mohamed INNOV/NET
> ;
> > draft-ietf-opsawg-l3sm-l3nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> >
> > Hi Med,
> >
> > Thanks for the quick reply.
> >
> > A few comments inline ...
> >
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: 12 July 2021 18:57
> > > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> > l3sm-
> > > l3nm@ietf.org
> > > Cc: opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> > >
> > > Re-,
> > >
> > > Many thanks for the review. A candidate version can be tracked at:
> > > https://tinyurl.com/l3nm-latest.
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com] Envoyé :
> > lundi
> > > > 12 juillet 2021 14:13 À : draft-ietf-opsawg-l3sm-
> > l3nm@ietf.org
> > > > Cc : opsawg@ietf.org
> > > > Objet : AD review of draft-ietf-opsawg-l3sm-l3nm-09
> > > >
> > > > Hi,
> > > >
> > > > Sorry for the delay in the review (it is a long draft).  The
> > review
> > > > of the common l2vpn module will follow later today.
> > > >
> > > > I believe that this work will be really helpful for SPs
> > modelling
> > > > their networks and hence I would like to thank the authors,
> > > > shepherd, and WG for the effort that they have put into this
> > > > document.
> > > >
> > > > Most of my comments on this draft are either minor, or editorial
> > in
> > > > nature.  I've listed the minor questions first, for which a
> > response
> > > > would be useful, and then the editorial/grammar suggestions are
> > at
> > > > the end, and in the attached copy of the draft (labelled with
> > #RW:).
> > > >
> > > >
> > > > 4.  L3NM Reference Architecture
> > > >
> > > >The terminology from [RFC8309] is introduced to show the
> > > > distinction
> > > >between the customer service model, the service delivery
> > model,
> > > > the
> > > >network configuration model, and the device configuration
> > model.
> > > > In
> > > >that context, the "Domain Orchestration" and "Config
> > Manager"
> > > > roles
> > > >may be performed by "Controllers".
> > > >
> > > > 1. Service delivery model doesn't seem to be included in figure
> > 1,
> > >
> > > [Med] This is supposed to be covered by "network model" in the
> > figure.
> > > Updated the figure with an explicit mention.
> >
> > Ok.
> >
> > >
> > > > and doesn't appear to be referenced further.  Does it need to be
> > > > mentioned at all?
> > > >
> > > >
> > > > 7.3.  VPN Services
> > > >
> > > >The 'vpn-service' is the data structure that abstracts a
> > VPN
> > > > service
> > > >in the service provider network.  Each 'vpn-service' is
> > uniquely
> > > >identified by an identifier: 'vpn-id'.  Such 'vpn-id' is
> > only
> > > >meaningful locally within the network controller.  The
> > subtree
> > > > of the
> > > >
> > > > 2. Why limit the vpn-id to the network controller?  Presumably,
> > an
> > > > implementation could allow these identifiers to be unique within
> > the
> > > > SP's management network (e.g., perhaps by using a network
> > controller
> > > > specific prefix)?
> > >
> > > [Med] Agree. Made this change: s/meaningful locally (e.g., within
> > the
> > > network controller)
> >
> > Ok.
> >
> > >
> > > >
> > > >
> > >

Re: [OPSAWG] A typo in draft-ietf-opsawg-l2nm-03.txt

[mohamed.boucadair]

Hi Moti,

Thank you for catching this.

Fixed at: 
https://github.com/IETF-OPSAWG-WG/lxnm/commit/ead6781ad73229cae267f6d805d9dcc19b8824a0

Cheers,
Med

De : OPSAWG [mailto:opsawg-boun...@ietf.org] De la part de Moti Morgenstern
Envoyé : mardi 13 juillet 2021 17:11
À : draft-ietf-opsawg-l...@ietf.org
Cc : opsawg@ietf.org
Objet : [OPSAWG] A typo in draft-ietf-opsawg-l2nm-03.txt

Hi,

I noticed that the enumerated values supposed to be under "identity 
evpn-service-type" actually use "base evpn-redundancy-mode".

Regards,
Moti Morgenstern
Packet Optical Networks - Systems Architecture
30 Hasivim Street | Petah Tikva, Israel
office: +972.3.9266258 | mobile: +972.50.705.6258
[ribboncommunications.com]



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

_

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

Re: [OPSAWG] AD review of draft-ietf-opsawg-vpn-common-08

[mohamed.boucadair]

Re-,

I updated the file to take into account your feedback:

* Module: 
https://github.com/IETF-OPSAWG-WG/lxnm/commit/fcc9f6c1e79d5074469fe454d95770fe9f1becdb
 (in addition to the changes already reported as part of the L3NM review).
* I-D: https://tinyurl.com/vpn-common-latest 

Unless you have further comments, I will contact the secretariat to publish 
this version. Thanks.  

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> Envoyé : mardi 13 juillet 2021 16:25
> À : BOUCADAIR Mohamed INNOV/NET ;
> draft-ietf-opsawg-vpn-common@ietf.org
> Cc : opsawg@ietf.org
> Objet : RE: AD review of draft-ietf-opsawg-vpn-common-08
> 
> Hi Med,
> 
> Please see inline, just a couple of points to resolve ...
> 
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> > 
> > Sent: 12 July 2021 18:35
> > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> vpn-
> > common@ietf.org
> > Cc: opsawg@ietf.org
> > Subject: RE: AD review of draft-ietf-opsawg-vpn-common-08
> >
> > Hi Rob,
> >
> > Many thanks for the review. A candidate updated version can be
> seen at:
> > https://tinyurl.com/vpn-common-latest
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com] Envoyé :
> lundi
> > > 12 juillet 2021 17:15 À : draft-ietf-opsawg-vpn-
> common@ietf.org
> > > Cc : opsawg@ietf.org
> > > Objet : AD review of draft-ietf-opsawg-vpn-common-08
> > >
> > > Hi,
> > >
> > > This is my AD review of draft-ietf-opsawg-vpn-common-08.
> > >
> > > Thank you for this document.  Again, just minor
> > > comments/suggestions.
> > >
> > >
> > >
> > > 1.
> > > In section 3.  Description of the VPN Common YANG Module
> > > "Encapsulation features  such as" -> "Encapsulation features.
> Such
> > > as"
> > > "Routing features  such as" -> "Routing features.  Such as"
> > >
> >
> > [Med] Fixed.
> 
> 
> Okay.
> 
> >
> > > 2.
> > > As a very minor comment.  Where you have lists (i.e.,
> encapsulation
> > > features, routing features, service type) and particularly
> because
> > > they have references, it may be slightly easier to read if the
> list
> > > was indented.  Also does it make sense for this list to just be
> > > examples, or are they actually normative lists of service types
> that
> > > are supported?
> >
> > [Med] Sure. These are only examples. We cite them as we need to
> list
> > include in the main text any reference quoted in the module.
> 
> Okay.
> 
> 
> >
> > >
> > > E.g.,
> > >'service-type':  Used to identify the VPN service type.
> > >   Examples of supported service types are:
> > >
> > > o L3VPN,
> > >
> > > o Virtual Private LAN Service (VPLS) using BGP [RFC4761],
> > >
> > > o VPLS using Label Distribution Protocol (LDP) [RFC4762],
> > >
> > > o Virtual Private Wire Service (VPWS) [RFC8214],
> > >
> > > o BGP MPLS-Based Ethernet VPN [RFC7432],
> > >
> > > o Ethernet VPN (EVPN) [RFC8365], and
> > >
> > > o Provider Backbone Bridging Combined with Ethernet
> > > VPN (PBB-EVPN) [RFC7623].
> > >
> > >
> > > In the Yang Module:
> > >
> > > 3. OPSA => OPSAWG
> > > Please can you check if this needs to be fixed for the L3NM YANG
> > > model as well.
> >
> > [Med] Fixed.
> 
> Okay.
> 
> >
> > >
> > > 4.
> > >   feature qinany {
> > > description
> > >   "Indicates the support of the QinAny encapsulation.";
> > >   }
> > >
> > > Is there a reference, or perhaps a more detailed description
> that
> > > you can use here?
> > >
> >
> > [Med] This was also a comment raised in the WGLC, but we don't
> have
> > any acceptable authoritative reference to cite for it.
> 
> Okay, then perhaps give a brief description of what QinAny means,
> i.e., in this context I think that frames have a pair of VLAN Ids,
> where the outer VLAN Id is fixed, but the inner VLAN Id can take any
> valid VLAN Id value.

[Med] Added a note to the module.

> 
> 
> >
> > > 5.
> > > Very minor:
> > > feature ipv4, feature ipv6, is it worth adding references to the
> > > RFCs?  I appreciate that they are obvious, but since you have
> > > references for everything else, it seems like it might be worth
> > > using adding them?
> >
> > [Med] OK
> 
> Okay.
> 
> >
> > >
> > > 6.
> > >   feature rtg-ospf-sham-link {
> > > description
> > >   "Indicates support of OSPF sham links.";
> > >
> > > Does this mean that feature rtg-ospf excldues this support?
> This
> > > feature seems very specific relative to the other features in
> this
> > > YANG module.
> >
> > [Med] Yes. We are barrowing this one for RFC8299, fyi.
> 
> Okay, makes sense.
> 
> 
> >
> > >
> > > 7.
> > > As mentioned in the other document, would "feature
> carrierscarrier"
> > > be better as "feature carriers-carrier"?
> >
> > [Med] No problem. Fixed.
> 
> Okay.
> 
> >
> > >
> > > 8.
> > > "Indicates the support of" => "Indicates support for"
> > > "Indicates support of" -> "I

[OPSAWG] A typo in draft-ietf-opsawg-l2nm-03.txt

[Moti Morgenstern]

Hi,

I noticed that the enumerated values supposed to be under "identity 
evpn-service-type" actually use "base evpn-redundancy-mode".

Regards,
Moti Morgenstern
Packet Optical Networks - Systems Architecture
30 Hasivim Street | Petah Tikva, Israel
office: +972.3.9266258 | mobile: +972.50.705.6258
[ribboncommunications.com]



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] AD review of draft-ietf-opsawg-l3sm-l3nm-09

[mohamed.boucadair]

Ho Rob,

I updated the files to take into account your feedback:

* Fix input/output in the common I-D (diff): 
https://github.com/IETF-OPSAWG-WG/lxnm/commit/ff456448a9398311457eb51c1d78adc8210fd8f8
 
* L3NM (diff): 
https://github.com/IETF-OPSAWG-WG/lxnm/commit/ed48b938990e6e7e4be7e329d986592ebcdc0c37
 
* I-D (diff): https://tinyurl.com/l3nm-latest 

Please see inline for the context. 

Cheers,
Med

> -Message d'origine-
> De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> Envoyé : mardi 13 juillet 2021 14:52
> À : BOUCADAIR Mohamed INNOV/NET ;
> draft-ietf-opsawg-l3sm-l3nm@ietf.org
> Cc : opsawg@ietf.org
> Objet : RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> 
> Hi Med,
> 
> Thanks for the quick reply.
> 
> A few comments inline ...
> 
> 
> > -Original Message-
> > From: mohamed.boucad...@orange.com
> > 
> > Sent: 12 July 2021 18:57
> > To: Rob Wilton (rwilton) ; draft-ietf-opsawg-
> l3sm-
> > l3nm@ietf.org
> > Cc: opsawg@ietf.org
> > Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> >
> > Re-,
> >
> > Many thanks for the review. A candidate version can be tracked at:
> > https://tinyurl.com/l3nm-latest.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -Message d'origine-
> > > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com] Envoyé :
> lundi
> > > 12 juillet 2021 14:13 À : draft-ietf-opsawg-l3sm-
> l3nm@ietf.org
> > > Cc : opsawg@ietf.org
> > > Objet : AD review of draft-ietf-opsawg-l3sm-l3nm-09
> > >
> > > Hi,
> > >
> > > Sorry for the delay in the review (it is a long draft).  The
> review
> > > of the common l2vpn module will follow later today.
> > >
> > > I believe that this work will be really helpful for SPs
> modelling
> > > their networks and hence I would like to thank the authors,
> > > shepherd, and WG for the effort that they have put into this
> > > document.
> > >
> > > Most of my comments on this draft are either minor, or editorial
> in
> > > nature.  I've listed the minor questions first, for which a
> response
> > > would be useful, and then the editorial/grammar suggestions are
> at
> > > the end, and in the attached copy of the draft (labelled with
> #RW:).
> > >
> > >
> > >   4.  L3NM Reference Architecture
> > >
> > >  The terminology from [RFC8309] is introduced to show the
> > > distinction
> > >  between the customer service model, the service delivery
> model,
> > > the
> > >  network configuration model, and the device configuration
> model.
> > > In
> > >  that context, the "Domain Orchestration" and "Config
> Manager"
> > > roles
> > >  may be performed by "Controllers".
> > >
> > > 1. Service delivery model doesn't seem to be included in figure
> 1,
> >
> > [Med] This is supposed to be covered by "network model" in the
> figure.
> > Updated the figure with an explicit mention.
> 
> Ok.
> 
> >
> > > and doesn't appear to be referenced further.  Does it need to be
> > > mentioned at all?
> > >
> > >
> > >   7.3.  VPN Services
> > >
> > >  The 'vpn-service' is the data structure that abstracts a
> VPN
> > > service
> > >  in the service provider network.  Each 'vpn-service' is
> uniquely
> > >  identified by an identifier: 'vpn-id'.  Such 'vpn-id' is
> only
> > >  meaningful locally within the network controller.  The
> subtree
> > > of the
> > >
> > > 2. Why limit the vpn-id to the network controller?  Presumably,
> an
> > > implementation could allow these identifiers to be unique within
> the
> > > SP's management network (e.g., perhaps by using a network
> controller
> > > specific prefix)?
> >
> > [Med] Agree. Made this change: s/meaningful locally (e.g., within
> the
> > network controller)
> 
> Ok.
> 
> >
> > >
> > >
> > >   7.4.  VPN Instance Profiles
> > >
> > > | |  |  +--rw vpn-policies
> > > | |  | +--rw import-policy?   string
> > > | |  | +--rw export-policy?   string
> > >
> > > 3. Is it right that import-policy and export-policy are plain
> > > strings?
> >
> > [Med] That usage is correct as we define vpn-id in the common
> draft as
> > a generic identifier. That is why we mention "service identifier"
> as an example.
> > We can make that more clearer in the common I-D.
> 
> Yes, making it clearer in the common I-D, will be helpful.
> 
> 
> >
> > >
> > >
> > >   7.6.  VPN Network Access
> > >
> > >   +--rw vpn-network-access* [id]
> > >  +--rw id vpn-
> > > common:vpn-id
> > >  +--rw port-id?   vpn-
> > > common:vpn-id
> > >
> > > 4. I'm surprised that port-id is of type vpn-common:vpn:id
> >
> > [Med]  We don't require any structure for the identification of
> the
> > port; hence the use of the string (vpn-common:vpn-id) type.
> 
> Okay, my point is that the model isn't just saying that it is a
> string (since it is using the type vpn-id) but is using a type with
> more m

Re: [OPSAWG] AD review of draft-ietf-opsawg-vpn-common-08

[Rob Wilton (rwilton)]

Hi Med,

Please see inline, just a couple of points to resolve ...

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 12 July 2021 18:35
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-vpn-
> common@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-vpn-common-08
> 
> Hi Rob,
> 
> Many thanks for the review. A candidate updated version can be seen at:
> https://tinyurl.com/vpn-common-latest
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : lundi 12 juillet 2021 17:15
> > À : draft-ietf-opsawg-vpn-common@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : AD review of draft-ietf-opsawg-vpn-common-08
> >
> > Hi,
> >
> > This is my AD review of draft-ietf-opsawg-vpn-common-08.
> >
> > Thank you for this document.  Again, just minor
> > comments/suggestions.
> >
> >
> >
> > 1.
> > In section 3.  Description of the VPN Common YANG Module
> > "Encapsulation features  such as" -> "Encapsulation features.  Such
> > as"
> > "Routing features  such as" -> "Routing features.  Such as"
> >
> 
> [Med] Fixed.


Okay.

> 
> > 2.
> > As a very minor comment.  Where you have lists (i.e., encapsulation
> > features, routing features, service type) and particularly because
> > they have references, it may be slightly easier to read if the list
> > was indented.  Also does it make sense for this list to just be
> > examples, or are they actually normative lists of service types that
> > are supported?
> 
> [Med] Sure. These are only examples. We cite them as we need to list include
> in the main text any reference quoted in the module.

Okay.


> 
> >
> > E.g.,
> >'service-type':  Used to identify the VPN service type.
> >   Examples of supported service types are:
> >
> >   o L3VPN,
> >
> >   o Virtual Private LAN Service (VPLS) using BGP [RFC4761],
> >
> >   o VPLS using Label Distribution Protocol (LDP) [RFC4762],
> >
> >   o Virtual Private Wire Service (VPWS) [RFC8214],
> >
> >   o BGP MPLS-Based Ethernet VPN [RFC7432],
> >
> >   o Ethernet VPN (EVPN) [RFC8365], and
> >
> >   o Provider Backbone Bridging Combined with Ethernet
> > VPN (PBB-EVPN) [RFC7623].
> >
> >
> > In the Yang Module:
> >
> > 3. OPSA => OPSAWG
> > Please can you check if this needs to be fixed for the L3NM YANG
> > model as well.
> 
> [Med] Fixed.

Okay.

> 
> >
> > 4.
> >   feature qinany {
> > description
> >   "Indicates the support of the QinAny encapsulation.";
> >   }
> >
> > Is there a reference, or perhaps a more detailed description that
> > you can use here?
> >
> 
> [Med] This was also a comment raised in the WGLC, but we don't have any
> acceptable authoritative reference to cite for it.

Okay, then perhaps give a brief description of what QinAny means, i.e., in this 
context I think that frames have a pair of VLAN Ids, where the outer VLAN Id is 
fixed, but the inner VLAN Id can take any valid VLAN Id value.


> 
> > 5.
> > Very minor:
> > feature ipv4, feature ipv6, is it worth adding references to the
> > RFCs?  I appreciate that they are obvious, but since you have
> > references for everything else, it seems like it might be worth
> > using adding them?
> 
> [Med] OK

Okay.

> 
> >
> > 6.
> >   feature rtg-ospf-sham-link {
> > description
> >   "Indicates support of OSPF sham links.";
> >
> > Does this mean that feature rtg-ospf excldues this support?  This
> > feature seems very specific relative to the other features in this
> > YANG module.
> 
> [Med] Yes. We are barrowing this one for RFC8299, fyi.

Okay, makes sense.


> 
> >
> > 7.
> > As mentioned in the other document, would "feature carrierscarrier"
> > be better as "feature carriers-carrier"?
> 
> [Med] No problem. Fixed.

Okay.

> 
> >
> > 8.
> > "Indicates the support of" => "Indicates support for"
> > "Indicates support of" -> "Indicates support for"
> 
> [Med] Fixed.

Okay.

> 
> >
> > 9.
> > This model defines a lot of features, and I wasn't sure how helpful
> > that will really be in practice.  Is the intention here for an SP to
> > use features to customize the model to their needs?  I wonder if the
> > heavy use of features won't work so well if both L2VPN and L3VPN's
> > are being modelled and support different protocols/etc.  Will having
> > the common features act as a limitation?  E.g., an alternative might
> > be to express the features in the L2NM and L3NM models directly
> > allowing them to enabled/disable different features.
> 
> [Med] The "common" set of features was initially included to rationalize the
> LxSM and LxNM. I don't know if/and to what extent this would have
> limitations when both L2xM and L3xM.

Okay.


> 
> >
> > 10. Status leaves:
> > Would UP, DOWN, UNKNWON be better as Up, Down, Unknown?
> 
> [Med] Fixed.

Okay.

> 
> > Would "admin-enabled" be better than "admin-up" and "admin-disabled"
> > be better than "admin-down".
> 
> [Med]

Re: [OPSAWG] AD review of draft-ietf-opsawg-l3sm-l3nm-09

[Rob Wilton (rwilton)]

Hi Med,

Thanks for the quick reply.

A few comments inline ...


> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: 12 July 2021 18:57
> To: Rob Wilton (rwilton) ; draft-ietf-opsawg-l3sm-
> l3nm@ietf.org
> Cc: opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-l3sm-l3nm-09
> 
> Re-,
> 
> Many thanks for the review. A candidate version can be tracked at:
> https://tinyurl.com/l3nm-latest.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > Envoyé : lundi 12 juillet 2021 14:13
> > À : draft-ietf-opsawg-l3sm-l3nm@ietf.org
> > Cc : opsawg@ietf.org
> > Objet : AD review of draft-ietf-opsawg-l3sm-l3nm-09
> >
> > Hi,
> >
> > Sorry for the delay in the review (it is a long draft).  The review
> > of the common l2vpn module will follow later today.
> >
> > I believe that this work will be really helpful for SPs modelling
> > their networks and hence I would like to thank the authors,
> > shepherd, and WG for the effort that they have put into this
> > document.
> >
> > Most of my comments on this draft are either minor, or editorial in
> > nature.  I've listed the minor questions first, for which a response
> > would be useful, and then the editorial/grammar suggestions are at
> > the end, and in the attached copy of the draft (labelled with #RW:).
> >
> >
> > 4.  L3NM Reference Architecture
> >
> >The terminology from [RFC8309] is introduced to show the
> > distinction
> >between the customer service model, the service delivery
> > model, the
> >network configuration model, and the device configuration
> > model.  In
> >that context, the "Domain Orchestration" and "Config
> > Manager" roles
> >may be performed by "Controllers".
> >
> > 1. Service delivery model doesn't seem to be included in figure 1,
> 
> [Med] This is supposed to be covered by "network model" in the figure.
> Updated the figure with an explicit mention.

Ok.

> 
> > and doesn't appear to be referenced further.  Does it need to be
> > mentioned at all?
> >
> >
> > 7.3.  VPN Services
> >
> >The 'vpn-service' is the data structure that abstracts a
> > VPN service
> >in the service provider network.  Each 'vpn-service' is
> > uniquely
> >identified by an identifier: 'vpn-id'.  Such 'vpn-id' is
> > only
> >meaningful locally within the network controller.  The
> > subtree of the
> >
> > 2. Why limit the vpn-id to the network controller?  Presumably, an
> > implementation could allow these identifiers to be unique within the
> > SP's management network (e.g., perhaps by using a network controller
> > specific prefix)?
> 
> [Med] Agree. Made this change: s/meaningful locally (e.g., within the
> network controller)

Ok.

> 
> >
> >
> > 7.4.  VPN Instance Profiles
> >
> > | |  |  +--rw vpn-policies
> > | |  | +--rw import-policy?   string
> > | |  | +--rw export-policy?   string
> >
> > 3. Is it right that import-policy and export-policy are plain
> > strings?
> 
> [Med] That usage is correct as we define vpn-id in the common draft as a
> generic identifier. That is why we mention "service identifier" as an example.
> We can make that more clearer in the common I-D.

Yes, making it clearer in the common I-D, will be helpful.


> 
> >
> >
> > 7.6.  VPN Network Access
> >
> > +--rw vpn-network-access* [id]
> >+--rw id vpn-
> > common:vpn-id
> >+--rw port-id?   vpn-
> > common:vpn-id
> >
> > 4. I'm surprised that port-id is of type vpn-common:vpn:id
> 
> [Med]  We don't require any structure for the identification of the port;
> hence the use of the string (vpn-common:vpn-id) type.

Okay, my point is that the model isn't just saying that it is a string (since 
it is using the type vpn-id) but is using a type with more meaning assigned to 
it.  I.e., I would expect that a vpn-id should be the identifier for a VPN.  If 
isn't one of these, then I don't think that it should be a vpn-id.

> 
> 
>  Also, is
> > the name port-id better than interface-id?  E.g., if the
> > connectivity was not via a physical port?  I think that the
> > description also defines this as an interface rather than a port.
> 
> [Med] The details about logical interfaces is covered in the connection and IP
> connection (e.g., lx-termination-point).

Okay, if this always identifies a physical port, then the description should 
presumably describe it in terms of port rather than interface.



> 
> >
> >
> >   'multipoint':  Represents a broadcast connection between the
> >  endpoints.  The controller must keep the association
> > between a
> >  logical or physical interface on the device with the 'id'
> > of
> >  the 'vpn-network-access'.
> >
> > 5.