Understood, thanks. (I yield to the combined power of "out of scope" and "future extension".)
On Wed, Sep 22, 2021 at 11:14 PM <mohamed.boucad...@orange.com> wrote: > Hi Erik, > > Thank you for the comments. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Erik Kline via Datatracker [mailto:nore...@ietf.org] > > Envoyé : mercredi 22 septembre 2021 22:36 > > À : The IESG <i...@ietf.org> > > Cc : draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-cha...@ietf.org; > > opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk > > 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. > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
