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

From: Erik Kline via Datatracker <[email-masked]>
Date: Wed, 22 Sep 2021 13:35:47 -0700

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"

---

From: <[email-masked]>
Date: Thu, 23 Sep 2021 06:14:57 +0000

Hi Erik, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Erik Kline via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 22 septembre 2021 22:36
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Erik Kline's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> DISCUSS and COMMENT)
> 

[[Med]] The L3NM focuses on what is required to be provisioned at the PE side. As such, we are not directly touching a CE.   

>   model noted here (and much more so than IPv4/DHCPv4).

[[Med]] Agree, but we restricted the scope on purpose to what can be actually passed by the service request: Please see https://datatracker.ietf.org/doc/html/rfc8299#section-6.3.2.2.1 

>   given that this document kinda models DHCP IP allocation ranges)?

[[Med]] These are really out of scope. The focus is on aspects that are widely used in current deployments and that can be requested by means of the L3SM (RFC8299). Advanced features may be added in the future by augmenting this module. Please note that given the large set of technical component that we are touching, we had to make a decision about the usability of the module vs. exhaustiveness of supported capabilities.
 
>   "number-of-dynamic-prefixes" instead?

[[Med]] This element is inherited from RFC8299 (L3SM). We prefer to maintain the same name to ease the mapping between a service (L3SM) and the network instantiation of the service (L3NM). As you can see in RFC8299, the description talks about addresses, but that's not correct for IPv6 as we reason in term of prefixes hence the updated description in the draft. 

>    (Prefix Delegation) is enabled, and the prefix pools used?

[[Med]] When PD is enabled, 'local-address' and 'prefix-length' will be used to control the pool and the delegated prefix length. However, enabling that functionality is not supported in this version because of the scope we set for the document: what can be passed by a service request (L3SM). 

[[Med]] Good catches. Fixed all for them.

> * "carrierscarrier" -> "carriers-carrier"

_________________________________________________________________________________________________________________________

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.

---

From: Erik Kline <[email-masked]>
Date: Thu, 23 Sep 2021 07:20:03 -0700

Understood, thanks.

(I yield to the combined power of "out of scope" and "future extension".)

On Wed, Sep 22, 2021 at 11:14 PM <[email-masked]> wrote:

> [[Med]] The L3NM focuses on what is required to be provisioned at the PE
> side. As such, we are not directly touching a CE.
>
> >
> > [S7.6.2]
> >
> [[Med]] Agree, but we restricted the scope on purpose to what can be
> actually passed by the service request: Please see
> https://datatracker.ietf.org/doc/html/rfc8299#section-6.3.2.2.1
>
> >
> [[Med]] These are really out of scope. The focus is on aspects that are
> widely used in current deployments and that can be requested by means of
> the L3SM (RFC8299). Advanced features may be added in the future by
> augmenting this module. Please note that given the large set of technical
> component that we are touching, we had to make a decision about the
> usability of the module vs. exhaustiveness of supported capabilities.
>
> >
> > [S8]
> >
> [[Med]] This element is inherited from RFC8299 (L3SM). We prefer to
> maintain the same name to ease the mapping between a service (L3SM) and the
> network instantiation of the service (L3NM). As you can see in RFC8299, the
> description talks about addresses, but that's not correct for IPv6 as we
> reason in term of prefixes hence the updated description in the draft.
>
> >
> [[Med]] When PD is enabled, 'local-address' and 'prefix-length' will be
> used to control the pool and the delegated prefix length. However, enabling
> that functionality is not supported in this version because of the scope we
> set for the document: what can be passed by a service request (L3SM).
>
> >
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;