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

[Erik Kline <[e-mail]>]

Understood, thanks.

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

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

> Hi Erik,
>
> Thank you for the comments.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Erik Kline via Datatracker [mailto:[e-mail]]
> > Envoyé : mercredi 22 septembre 2021 22:36
> > À : The IESG <[e-mail]>
> > Cc : [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; [e-mail]
> > Objet : Erik Kline's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with
> > DISCUSS and COMMENT)
> >
> > 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.
>
> [[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]
> >
> > * Provisioning IPv6 clients can be more rich than the DHCPv6/SLAAC
> >   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
>
> >
> >   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)?
>
> [[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]
> >
> > * 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?
>
> [[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.
>
> >
> >  * Which of these elements describes whether or not DHCPv6 PD
> >    (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).
>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
>
> [[Med]] Good catches. Fixed all for them.
>
> > [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"
> >
> >
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>