Re: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-vpn-common-10: (with COMMENT)

[mohamed.boucadair]

Hi Eric, 

Thank you for the comment. 

I added this NEW text: 

   The QoS match criteria reuse groupings that are defined in the
   packet fields module "ietf-packet-fields" (Section 4.2 of
   [RFC8519]).

Cheers,
Med

> -Message d'origine-
> De : Éric Vyncke via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mercredi 22 septembre 2021 22:10
> À : The IESG 
> Cc : draft-ietf-opsawg-vpn-com...@ietf.org; opsawg-cha...@ietf.org;
> opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk;
> sur...@kaloom.com
> Objet : Éric Vyncke's No Objection on draft-ietf-opsawg-vpn-common-10:
> (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-opsawg-vpn-common-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/
> 
> 
> 
> --
> COMMENT:
> --
> 
> As I am abroad on vacations, I had not time to review in depth this
> document, hence I am trusting the Internet directorate Last-Call review
> by Suresh:
> https://datatracker.ietf.org/doc/review-ietf-opsawg-vpn-common-09-
> intdir-lc-krishnan-2021-08-30/
> 
> I was about to post similar comments as Erik Kline's ones about the lack
> of
> IPv6 terminology in the classification but Med's reply is OK. May I
> suggest though to clearly reference RFC 8519 (which should be updated)
> where this topic is discussed ? I also appreciate the reuse of the
> (incomplete) ACL YANG modules.
> 
> Regards
> 
> -éric
> 
> 


_

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

[OPSAWG] Erik Kline's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)

[Erik Kline via Datatracker]

Erik Kline has entered the following ballot position for
draft-ietf-opsawg-l3sm-l3nm-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/



--
DISCUSS:
--

[general]

* I'm sure there are plenty things I'm not understanding, and probably
  these things are easy to address.  But in general I feel like there
  could be some tension between needing to specify/model the L3
  attributes that are used to provision both the endpoint and the
  clients with a possibly somewhat cleaner separation for holding client
  IP provisioning info.  At what point, for example, should there be
  something like a separate "client-ip-provisioning-profile" string
  that is referenced?  I think some of the richness of what can be
  expressed in IPv6 RAs may be bringing these ideas up, some of which
  can be expressed in DHCP as well but operationally may be less common.
  The contents of RIOs in particular seem like a bit of client
  provisioning information that an endpoint might need to be aware
  of as well.

[S7.6.2]

* Provisioning IPv6 clients can be more rich than the DHCPv6/SLAAC
  model noted here (and much more so than IPv4/DHCPv4).

  Since you document how local-address/prefix-length becomes a PIO,
  should there be other related IP connectivity provisioning information
  in here, like:

  * more than just one PIO? (is this just repeated
ip-connection/ipv6 entries, one for each on-link prefix?)
  * one or more RIOs that might need to be advertised to clients?
  * others (PVDIO, ...)?

  If this is "out of scope" for this document, where does it belong
  in the overall provisioning of an L3VPN service (out of curiosity,
  given that this document kinda models DHCP IP allocation ranges)?

[S8]

* Under provider DHCPv6 servers, the server definition has an
  "address-assign" choice of "number" with a
  "number-of-dynamic-address" (defaulting to "1"), but the description
  talks about the number of allocated prefixes.  Should this value be
  "number-of-dynamic-prefixes" instead?

 * Which of these elements describes whether or not DHCPv6 PD
   (Prefix Delegation) is enabled, and the prefix pools used?


--
COMMENT:
--

[S7.2, nit]

* "refers to as set of policies" ->
  "refers to a set of policies"

[S7.3, nit]

* "a P node or event a dedicated node" ->
  "a P node or even a dedicated node"

[S7.4, nit]

* "Indicates the maximum prefixes" ->
  "Indicates the maximum number of prefixes", perhaps?

[S7.6.1, nit]

* "is the layer two connections" ->
  "is the layer two connection"

  (although this sentence may be redundant with the one two sentences
   prior)

[S7.6.6, nit]

* "carrierscarrier" -> "carriers-carrier"



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-vpn-common-10: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-vpn-common-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/



--
COMMENT:
--

As I am abroad on vacations, I had not time to review in depth this document,
hence I am trusting the Internet directorate Last-Call review by Suresh:
https://datatracker.ietf.org/doc/review-ietf-opsawg-vpn-common-09-intdir-lc-krishnan-2021-08-30/

I was about to post similar comments as Erik Kline's ones about the lack of
IPv6 terminology in the classification but Med's reply is OK. May I suggest
though to clearly reference RFC 8519 (which should be updated) where this topic
is discussed ? I also appreciate the reuse of the (incomplete) ACL YANG modules.

Regards

-éric



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Alvaro Retana's Abstain on draft-ietf-opsawg-l3sm-l3nm-11: (with COMMENT)

[mohamed.boucadair]

Hi Alvaro, 

One comment about the interoperability point: many implementers (Nokia, Huawei, 
Juniper, Cisco, Infinera, Ribbon, ..) were involved in this work and have 
reported their implementations. No issues were reported by them. 

Given the complex nature of the functionalities touched in the L3NM, there 
might be some name mismatches vs those present in the device model. We have 
indicated that we will fix these to ease the mapping with the device modules. 
If you have identified some not already discussed in the list, please share 
them and will take them into account. 

We will do check on our side to find mismatches that we missed. 

Thank you. 

Cheers,
Med

> -Message d'origine-
> De : Alvaro Retana via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mercredi 22 septembre 2021 17:54
> À : The IESG 
> Cc : draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-cha...@ietf.org;
> opsawg@ietf.org; adr...@olddog.co.uk
> Objet : Alvaro Retana's Abstain on draft-ietf-opsawg-l3sm-l3nm-11: (with
> COMMENT)
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-opsawg-l3sm-l3nm-11: Abstain
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I understand that L3NM is not a device model and that, as such, it is
> not intended to include every possible parameter.
> 
> However, not leveraging existing work has resulted in inconsistencies:
> from using different names to changing implementation expectations.  I
> believe that this result impacts the implementation-specific work needed
> to derive device-specific actions (using existing models) and
> potentially reduces the value of using this network model.
> 
> Many WGs in the routing area work on related technology, including bess,
> idr, lsr, pim, bfd, rtgwg, and teas. However, I found no evidence in the
> archives that any of these WGs were consulted or asked to review this
> work.
> 
> Both points (lack of reuse and lack of review) have been mentioned in
> the mailing list, so I assume they have been considered.  This fact and
> the existence of multiple implementations lead me to ABSTAIN.
> 
> 


_

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

[OPSAWG] Alvaro Retana's Abstain on draft-ietf-opsawg-l3sm-l3nm-11: (with COMMENT)

[Alvaro Retana via Datatracker]

Alvaro Retana has entered the following ballot position for
draft-ietf-opsawg-l3sm-l3nm-11: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/



--
COMMENT:
--

I understand that L3NM is not a device model and that, as such, it is not
intended to include every possible parameter.

However, not leveraging existing work has resulted in inconsistencies: from
using different names to changing implementation expectations.  I believe that
this result impacts the implementation-specific work needed to derive
device-specific actions (using existing models) and potentially reduces the
value of using this network model.

Many WGs in the routing area work on related technology, including bess, idr,
lsr, pim, bfd, rtgwg, and teas. However, I found no evidence in the archives
that any of these WGs were consulted or asked to review this work.

Both points (lack of reuse and lack of review) have been mentioned in the
mailing list, so I assume they have been considered.  This fact and the
existence of multiple implementations lead me to ABSTAIN.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS)

[Scharf, Michael]

Hi Med,

Thanks for the useful references. More inline.

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: Tuesday, September 21, 2021 2:56 PM
> To: Scharf, Michael ; Martin Duke
> ; The IESG 
> Cc: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; opsawg-
> cha...@ietf.org
> Subject: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> DISCUSS)
> 
> Hi Michael,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -Message d'origine-
> > De : Scharf, Michael [mailto:michael.sch...@hs-esslingen.de]
> > Envoyé : lundi 20 septembre 2021 12:05
> > À : BOUCADAIR Mohamed INNOV/NET
> ; Martin
> > Duke ; The IESG 
> > Cc : draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; opsawg-
> > cha...@ietf.org
> > Objet : RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> > (with DISCUSS)
> >
> > Hi Med,
> >
> > What happens if PEs and CEs are both under operator control? In that
> > case, the customer-facing L3SM model may not need any TCP-AO
> > configuration.
> >
> > However, in that case, TCP-AO may need to be configured on the PEs and
> > the "send-id" and "receive-id" values must be consistent with the CEs,
> > no?
> 
> [[Med]] Agree.
> 
>  If the PE configuration is done by L3NM, the "send-id" and "receive-
> > id" must be part of L3NM model, no?
> 
> [[Med]] Not necessarily. See below.
> 
>  If not, how would the TCP-AO
> > provisioning on CEs and PEs work?
> 
> [[Med]] The assumption we had for this version of the module is that send-id
> and recv-id are pre-configured while only the key reference is manipulated in
> the L3NM. Some of the implementations separate the TCP-AO configuration
> from the invocation in context of a particular protocol, e.g.,
> 
> *
> https://www.juniper.net/documentation/en_US/junos/topics/reference/g
> eneral/release-notes/20.3/infocus-topicmaps/tcp-authentication-option-
> map-infocus.html
> * https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/72x/b-bgp-
> cg-ncs5500-72x/implementing-master-key-tuple-
> configuration.html#id_77361

Good references. As far as I can see, in those two cases the send-id and 
recv-id are modelled in the key-chain and therefore configurable as part of the 
key-chain. With such a key-chain, your assumption would work.

However, draft-ietf-opsawg-l3sm-l3nm-11 references to the key-chain from RFC 
8177. Unlike in those two previous examples, I don't understand how one would 
encode send-id and recv-id in the RFC 8177 model. 

So, my reading is that draft-ietf-opsawg-l3sm-l3nm-11 assumes that the 
referenced key-chain includes additional entries beyond RFC 8177, such as 
send-id and recv-id.

If that assumption is correct, IMHO the document draft-ietf-opsawg-l3sm-l3nm 
has to highlight that additions to the key-chain model beyond RFC 8177 may be 
required for TCP-AO to work.

> We can add a note about it you think this helps. Thank you.

If the document assumes additions to RFC 8177, this must be noted, IMHO.

Of course, an alternative would be just to import draft-ietf-tcpm-yang-tcp, 
which models the relevant entries, but that will be your call.

Michael 

> 
> >
> > In a nutshell, I don't understand the argument "send-id and receive-id
> > are not needed in L3NM because they are not included in L3SM". Also,
> > that generic argument would apply to _a lot_ of network level
> > configuration that is not part of L3SM.
> >
> > BTW, I agree that augmentation will be important for many parameters,
> > but IMHO you have to ensure that the L3NM model includes all base
> > parameters that are required for connectivity. At least for TCP-AO, I
> > don't understand your specific choice in L3NM so far.
> >
> > Best regards
> >
> > Michael
> >
> >
> >
> >
> > > -Original Message-
> > > From: mohamed.boucad...@orange.com
> > > 
> > > Sent: Monday, September 20, 2021 11:42 AM
> > > To: Scharf, Michael ; Martin Duke
> > > ; The IESG 
> > > Cc: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; opsawg-
> > > cha...@ietf.org
> > > Subject: RE: Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> > > (with
> > > DISCUSS)
> > >
> > > Hi Michael,
> > >
> > > The L3NM focuses on the network side (that is, PEs). The module is
> > > typically triggered by an L3SM (where the values may be agreed with a
> > customer).
> > > FYI, the L3SM (RFC8299) does not support the capability to customize
> > > TCP- AO.
> > >
> > > When the L3SM (RFC8299) is augmented in the future to support send-id
> > > and recv-id, then the L3NM can be easily augmented to pass them to
> > PEs.
> > >
> > > What is really important is that we have a provision for such augment
> > > to happen.
> > >
> > > Thank you.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -Message d'origine-
> > > > De : Scharf, Michael [mailto:michael.sch...@hs-esslingen.de]
> > > > Envoyé : lundi 20 septembre 2021 11:10 À : BOUCADAIR Mohamed
> > > > INNOV/NET
> > > ; Martin
> > > > Duke ; The IESG  Cc :
> > > > 

Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)

[mohamed.boucadair]

Hi Roman, 

Thank you for the review. Much appreciated.

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Roman Danyliw via Datatracker [mailto:nore...@ietf.org]
> Envoyé : dimanche 19 septembre 2021 23:21
> À : The IESG 
> Cc : draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-cha...@ietf.org;
> opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk
> Objet : Roman Danyliw's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> DISCUSS and COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-opsawg-l3sm-l3nm-11: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> ** RFC8177 already defines a container to represent an individual key --
> key-string – as both a string and hex format. Additionally, this
> representation has built in ACLs to protect it.  This model appears to
> maximize flexibility by supporting both key-chains and an explicit key
> for protocols like BGP, RIP and ISIS.  Is there a reason why this model
> does not (or perhaps cannot) reuse the key-string representation from
> RFC8177 (the same way key-chain is)? And/or to not provide the
> flexibility for a hex encoded key?

[[Med]] We are echoing what is supported by the device models where the 
explicit key is supported. For example, 

* RFC8695 for RIP supports the following:

   | +--rw authentication
   | |  +--rw (auth-type-selection)?
   | | +--:(auth-key-chain)
   | | |  +--rw key-chain? key-chain:key-chain-ref
   | | +--:(auth-key)
   | |+--rw key?string
   | |+--rw crypto-algorithm?   identityref

* draft-ietf-isis-yang-isis-cfg for IS-IS supports the following:

  |  +--rw (authentication-type)?
  |  |  +--:(key-chain) {key-chain}?
  |  |  |  +--rw key-chain?key-chain:key-chain-ref
  |  |  +--:(password)
  |  | +--rw key?string
  |  | +--rw crypto-algorithm?   identityref


> 
> ** Section 9.  The text notes that ‘vpn-service’ is sensitive to write
> operations.  Wouldn’t ‘vpn-profiles’ be equally sensitive to alterations
> with similar consequences?  For example, altering an encryption-profile-
> identifier could change the algorithm chosen or the key.

[[Med]] We didn't because the profiles are defined with the following (see the 
common I-D):

"nacm:default-deny-write;"

And that we are saying the following under security considerations:

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.

FWIW, RFC8341 defines the default-deny-write as follows: 

 extension default-deny-write {
   description
 "Used to indicate that the data model node
  represents a sensitive security system parameter.

  If present, the NETCONF server will only allow the designated
  'recovery session' to have write access to the node.  An
  explicit access control rule is required for all other users.

  If the NACM module is used, then it must be enabled (i.e.,
  /nacm/enable-nacm object equals 'true'), or this extension
  is ignored.

  The 'default-deny-write' extension MAY appear within a data
  definition statement.  It is ignored otherwise.";
 }

> 
> 
> --
> COMMENT:
> --
> 
> Thank you to Rifaat Shekh-Yusef for the SECDIR review.
> 
> To the authors: the explanatory text in Sections 4 and 7 made this large
> YANG model very accessible.  It's sometimes hard to find the right
> balance between the text narrative and letting the model speak for
> itself, but this document negotiated it well.

[[Med]] Thanks. 

> 
> ** Section 7.6.5.  Could we ever end up in a situation where
> security/enabled=True but the key-chain-ref pointed a key-chain who’s
> crypto-algorithm was cleartext?

[[Med]] Not sure to get the question. Are you referring to customer-key-chain 
under security?

 |  +--rw encryption-profile
 | +--rw (profile)?
 |

Re: [OPSAWG] Lars Eggert's No Objection on draft-ietf-opsawg-l3sm-l3nm-11: (with COMMENT)

[mohamed.boucadair]

Hi Lars, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Lars Eggert via Datatracker [mailto:nore...@ietf.org]
> Envoyé : lundi 20 septembre 2021 14:39
> À : The IESG 
> Cc : draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-cha...@ietf.org;
> opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk
> Objet : Lars Eggert's No Objection on draft-ietf-opsawg-l3sm-l3nm-11:
> (with COMMENT)
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-opsawg-l3sm-l3nm-11: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/
> 
> 
> 
> --
> COMMENT:
> --
> 
> It would be useful to summarize this document's relationship to RFC8299
> in the abstract.

[[Med]] Sure. Made this change to the github copy: 

OLD:
   This document defines an L3VPN Network YANG Model (L3NM) that can be
   used for the provisioning of Layer 3 Virtual Private Network (VPN)
   services within a service provider network.  The model provides a
   network-centric view of L3VPN services.

NEW:
   As a complement to the Layer 3 Virtual Private Network Service YANG
   data Model (L3SM), used for communication between customers and
   service providers, this document defines an L3VPN Network YANG Model
   (L3NM) that can be used for the provisioning of Layer 3 Virtual
   Private Network (VPN) services within a service provider network.
   The model provides a network-centric view of L3VPN services.

> 
> 
> ---
> All comments below are about very minor potential issues that you may
> choose to address in some way - or ignore - as you see fit. Some were
> flagged by automated tools (via https://github.com/larseggert/ietf-
> reviewtool), so there will likely be some false positives. There is no
> need to let me know what you did with these suggestions.

[[Med]] Considered most of the proposals below. We kept "key chain" to align 
with the usage in RFC8177. 

All the changes can be seen at: 
https://github.com/IETF-OPSAWG-WG/lxnm/blob/master/I-D-L3NM/draft-ietf-opsawg-l3sm-l3nm.txt
 


> 
> Section 7.6.3. , paragraph 43, nit:
> > icates which BFD flavor is used to setup the session (e.g., classic
> BFD [RFC
> >^
> The verb "set up" is spelled as two words. The noun "setup" is spelled
> as one.
> 
> Section 7.7. , paragraph 1, nit:
> > y applicable if both RP redundancy and and delivery through optimal
> path are
> >^^^
> Possible typo: you repeated a word.
> 
> Section 8. , paragraph 8, nit:
> >  VPLS and, VXLAN. Other values may defined, if needed."; leaf type {
> type ide
> >^^^
> The modal verb "may" requires the verb's base form.
> 
> Section 8. , paragraph 32, nit:
> > cription "Reference to the TCP-AO key chain."; reference "RFC 8177:
> YANG Key
> >   ^
> This word is normally spelled as one.
> 
> Section 8. , paragraph 32, nit:
> > description "Reference to the MD5 key chain."; reference "RFC 8177:
> YANG Key
> >   ^
> This word is normally spelled as one.
> 
> Section 8. , paragraph 32, nit:
> > f; description "Customer-supplied key chain."; } } } } } container
> service {
> >   ^
> This word is normally spelled as one.
> 
> Section 8. , paragraph 32, nit:
> > cast static source/group associated to to IGMP session"; leaf group-
> addr { ty
> > ^
> Possible typo: you repeated a word.
> 
> Document references draft-ietf-opsawg-vpn-common-09, but -10 is the
> latest available revision.
> 
> Obsolete reference to RFC4447, obsoleted by RFC8077 (this may be on
> purpose).
> 
> These URLs point to tools.ietf.org, which is being deprecated:
>  * http://tools.ietf.org/wg/opsawg/
> 
> 


_

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 

Re: [OPSAWG] Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)

[mohamed.boucadair]

Re-, 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Zaheduzzaman Sarker via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mercredi 22 septembre 2021 10:16
> À : The IESG 
> Cc : draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-cha...@ietf.org;
> opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk
> Objet : Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l3sm-l3nm-11:
> (with DISCUSS and COMMENT)
> 
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-opsawg-l3sm-l3nm-11: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This specification refers to ietf-opsawg-vpn-common for qos related
> matching, hence I am raising similar discussion as I had for ietf-
> opsawg-vpn-common (see here https://datatracker.ietf.org/doc/draft-ietf-
> opsawg-vpn-common/).
> 
> This specification specifies qos classification based on L4 criteria and
> describes the procedure for TCP and UDP. It is possible that new L4
> protocols (for example QUIC) use UDP as substrate hence can create
> ambiguity based of the procedure described in the specification.
> 
> This specification should consider such potential substrate usage of L4
> protocols (specially UDP) and hint on the potential augmentations (there
> might be several ways to do that) or scope it down to not support such
> cases.

[[Med]] Added this NEW text to echo the proposal in the common module: 

 As discussed in [I-D.ietf-opsawg-vpn-common], some transport
 protocols use existing protocols (e.g., TCP or UDP) as
 substrate.  The match criteria for such protocols may rely upon
 the 'protocol' under 'l3', TCP/UDP match criteria shown in
 Figure 26, part of the TCP/UDP payload, or a combination
 thereof.  This version of the module does not support such
 advanced match criteria.  Future revisions of the VPN common
 module or augmentations to the L3NM may consider adding match
 criteria based on the transport protocol payload (e.g., by
 means of a bitmask match).

> 
> 
> --
> COMMENT:
> --
> 
> Thanks to the authors for their efforts in the specification.
> 
> Additional comment(s)-
> 
> * I think if would be good if this specification also discusses the
> implication of wrong classification (e.g. for qos) based on the model
> specified here (no particular suggestion from me where but may be in
> security considerations).
> 

[[Med]] I think this is already covered by this part in the draft: 

  In addition,
  an attacker may modify the attributes of a running service (e.g.,
  QoS, bandwidth, routing protocols), leading to malfunctioning of
  the service and therefore to SLA violations.

Please let me know if there is more to say here. Thanks. 

_

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] Benjamin Kaduk's No Objection on draft-ietf-opsawg-vpn-common-10: (with COMMENT)

[mohamed.boucadair]

Hi Ben, 

Thank you for the review. The changes to address your review can be tracked at: 
https://github.com/IETF-OPSAWG-WG/lxnm/commit/108707e8b2aea6590b0a9695756c7546887c9614
 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mercredi 22 septembre 2021 06:19
> À : The IESG 
> Cc : draft-ietf-opsawg-vpn-com...@ietf.org; opsawg-cha...@ietf.org;
> opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk
> Objet : Benjamin Kaduk's No Objection on draft-ietf-opsawg-vpn-common-
> 10: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-opsawg-vpn-common-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/
> 
> 
> 
> --
> COMMENT:
> --
> 
> I have a bold proposal for consideration: since we are defining a new
> common set of groupings for VPN and, in some cases, proposing to rename
> existing terminology already, can we consider moving away from the term
> "VPN" itself?  The word "private" is ambiguous as to what level of
> privacy is being provided (e.g., network routing vs cryptographic) and
> who the conveyed content is to be private from.  A term like "virtual
> network" removes that ambiguity, and lets us use the explicit attributes
> to convey whether encryption is in use when appropriate.
> 
> There is no particular triggering point (at least, not yet) at which it
> becomes clearly correct to make a breaking change like this, so we may
> end up just having to pick a time somewhat arbitrarily, if we are to
> make such a change at all.  Perhaps now is that time; perhaps not.

[[Med]] I hear some of your observations but VPN is a well-established name for 
a widely deployed technology. I don't think it is a good idea to touch this. 
Please note that there is already generic model for VNs 
(https://datatracker.ietf.org/doc/draft-ietf-teas-actn-vn-yang/) that is 
distinct from what we are doing here.

> 
> Section 3
> 
>   grouping vpn-profile-cfg
> +-- valid-provider-identifiers
>+-- external-connectivity-identifier* [id]
>|   {external-connectivity}?
>|  +-- id?   string
> 
> Presumably I am just misreading RFC 8340, but I thought that the list
> key was implicitly mandatory, so it would appear as just "id" (as
> opposed to "id?").  (Many instances.)

[[Med]] Good question. Actually we trusted what is in Section 3.2 of 8340. 
That's the output we get from pyang. Note that ? is not displayed when the 
grouping is used in another model (L2NM/L3NM). Will double check this with 
Martin.  

> 
>'vpn-route-targets':
>   *  A YANG grouping that defines Route Target (RT) import/export
>  rules used in a BGP-enabled VPN (e.g., [RFC4364][RFC4664]).
> 
> On very quick skim, it's not clear what motivates the RFC 4664 reference
> -- "route target" does not appear, for example, nor does "import" or
> "export".

[[Med]] This is just to insist that it can be used for both L3 and L2VPNs. 
Unlike L3NM, there are plenty L2VPN technologies; hence the choice to point to 
a generic L2 framework.

> 
> Section 4
> 
>  identity pim-proto {
>if-feature "pim";
>base routing-protocol-type;
> 
> This is in the section with the group-management-protocols; is "routing-
> protocol-type" really the intended base?

[[Med]] Yes. Both PIM and other group management protocols fall under:

  /*
   * Identities related to multicast
   */ 

> 
>  identity embb {
>  [...]
>  identity urllc {
>  [...]
>  identity mmtc {
> 
> Similar to Roman's comment, a reference seems useful for these.
> If we intend to implicitly rely on RFCs 8299 and/or 8466 for
> terminology, we should say so in the terminology section.

[[Med]] Added this note under the terminology section:

   The document inherits many terms from [RFC8299] and [RFC8466]
   (e.g., Enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low
   Latency Communications (URLLC), Massive Machine Type Communications
   (mMTC)).

> 
>leaf vpn-id {
>  type vpn-common:vpn-id;
>  description
>"A VPN identifier that uniquely identifies a VPN.
> This identifier has a local meaning, e.g., within
> a service provider network.";
> 
> Thank you for indicating the scope of validity of the identifier!
> (Elsewhere as 

[OPSAWG] Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)

[Zaheduzzaman Sarker via Datatracker]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-opsawg-l3sm-l3nm-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-l3sm-l3nm/



--
DISCUSS:
--

This specification refers to ietf-opsawg-vpn-common for qos related matching,
hence I am raising similar discussion as I had for ietf-opsawg-vpn-common (see
here https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/).

This specification specifies qos classification based on L4 criteria and
describes the procedure for TCP and UDP. It is possible that new L4 protocols
(for example QUIC) use UDP as substrate hence can create ambiguity based of the
procedure described in the specification.

This specification should consider such potential substrate usage of L4
protocols (specially UDP) and hint on the potential augmentations (there might
be several ways to do that) or scope it down to not support such cases.


--
COMMENT:
--

Thanks to the authors for their efforts in the specification.

Additional comment(s)-

* I think if would be good if this specification also discusses the implication
of wrong classification (e.g. for qos) based on the model specified here (no
particular suggestion from me where but may be in security considerations).



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New Version Notification for draft-palmero-opsawg-dmlmo-00.txt

[Shwetha Bhandari]

Hi Marisol,

I have read the draft draft-palmero-opsawg-dmlmo-00 and have the following
questions/suggestions on the scope and use cases:

1. Does the scope include lifecycle management and operations for an
application that can be managed by the application vendor i.e. Software as
a Service(SaaS) application? In other words can the asset referred to in
the document be a cloud hosted software asset? If yes, that's great! I
think there is no standard to collect metrics that will help in asset
management and billing in the SaaS space and this work would be interesting
to SaaS applications.

2. Related to this an interesting use case that would be added to the
document is to support Billing based on the usage and consumption of the
SaaS application. To support this use-case for software/SaaS application
assets can the metric collection be made extensible to cover application
specific metrics? for e.g. A data analytics application may be interested
in metrics related to amount of data analyzed, number of requests triggered
for analysis, concurrent user sessions that trigger the request etc. These
metrics could be used for billing the consumers of the SaaS application.

3. Would you be interested in contributions if the above use cases and
asset type can be supported to extend the information model?

Thanks,
Shwetha




On 8/24/2021 11:29 AM, Marisol Palmero Amador (mpalmero) wrote:
> Dear OPSA WG,
>
> We've just posted a new draft that introduces a data model for lifecycle 
> management and operations:
> https://www.ietf.org/archive/id/draft-palmero-opsawg-dmlmo-00.txt
>
>
> We don't yet have data models that deal with data concerning adoption and 
> usability, licensing, supported features and capabilities, enabled features 
> and capabilities, etc. of a hardware or software, physical or virtual 
> component.
> We hope that the new draft can help fill this gap.
>
> We greatly appreciate your thoughts and comments.
>
> Many thanks,
> Marisol
>
>
> Marisol Palmero
> CCIE #5122 | Technical Leader EMEAR | Cisco Customer Experience CTO | P: 
> +34.91.201.2643 | M: +34.629.634.595
>
>
>
> On 23/08/2021, 22:04, "internet-dra...@ietf.org" 
>   
>  wrote:
>
>
>  A new version of I-D, draft-palmero-opsawg-dmlmo-00.txt
>  has been successfully submitted by Marisol Palmero and posted to the
>  IETF repository.
>
>  Name:draft-palmero-opsawg-dmlmo
>  Revision:00
>  Title:   Data Model for Lifecycle Management and Operations
>  Document date:   2021-08-23
>  Group:   Individual Submission
>  Pages:   48
>  URL:
> https://www.ietf.org/archive/id/draft-palmero-opsawg-dmlmo-00.txt
>  Status: 
> https://datatracker.ietf.org/doc/draft-palmero-opsawg-dmlmo/
>  Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-palmero-opsawg-dmlmo
>
>
>  Abstract:
> This document motivates and specifies a data model for lifecycle
> management and operations.  It describes the motivation and
> requirements to collect asset-centric metrics including but not
> limited to asset adoption and usability, licensing, supported
> features and capabilities, enabled features and capabilities, etc.;
> with the primary objective to measure and improve the overall user
> experience along the lifecycle journey, from technical requirements
> and technology selection through advocacy and renewal, including the
> end of life of an asset.
>
>
>
>
>  The IETF Secretariat
>
>
>
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-vpn-common-10: (with DISCUSS and COMMENT)

[mohamed.boucadair]

Hi Zahed, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Zaheduzzaman Sarker via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mardi 21 septembre 2021 17:22
> À : The IESG 
> Cc : draft-ietf-opsawg-vpn-com...@ietf.org; opsawg-cha...@ietf.org;
> opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk
> Objet : Zaheduzzaman Sarker's Discuss on draft-ietf-opsawg-vpn-common-
> 10: (with DISCUSS and COMMENT)
> 
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-opsawg-vpn-common-10: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> I would like to discuss the extensibility of the model as described in
> section
> 3 regarding 'qos-classification-policy' when UDP is used as substrate.
> See more in my comments bellow.
> 

[[Med]] Good point. I added this NEW text:

 Some transport protocols use existing protocols (e.g., TCP or
 UDP) as substrate.  The match criteria for such protocols may
 rely upon the 'protocol' under 'l3', TCP/UDP match criteria
 shown in Figure 4, part of the TCP/UDP payload, or a
 combination thereof.  This version of the module does not
 support such advanced match criteria.  Future revisions of the
 module may consider adding match criteria based on the
 transport protocol payload (e.g., by means of a bitmask match).

Do we need to say more? Thanks.

> 
> --
> COMMENT:
> --
> 
> Thanks to the authors for working on this specifications and addressing
> TSVART review comments. Thanks Wesley Eddy for your TSVART reviews.
> 
> Comments -
> 
> * In this specification, UDP match criteria is described and claimed
> that the model can be augmented to include more L4 transport protocols.
> QUIC (RFC9000) is a new L4 transport protocol and uses UDP as substrate.
> For such L4 transport protocols, it might be ambiguous to apply qos
> classification policy based on what is defined here. In case of QUIC, it
> needs to identify from other UDP traffic that is traversing the network.
> Read more on QUIC traffic identification here ( https://quicwg.org/ops-
> drafts/draft-ietf-quic-manageability.html#name-identifying-quic-
> traffic).
> 
> I think this specification should consider such potential substrate
> usage of L4 protocols (specially UDP) and hint on the potential
> augmentations (there might be several ways to do that) or scope it down
> to not support such cases.
> 

[[Med]] I guess this is covered by the NEW text above.

> * May be the commented text in the section 4 for protocol identifiers
> should be updated to reflect what is describes in the section 3 for
> "underlay-transport".
> Section 3 talks about underlay transports and how they are set.
> 

[Med]] Good catch. Fixed. Please check 
https://github.com/IETF-OPSAWG-WG/lxnm/commit/b071ca3b8a9dec654b537ecf9c0116d2adf02aca
 


_

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