Hi Erik, Thank you for the comments.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Erik Kline via Datatracker [mailto:[email protected]] > Envoyé : mercredi 22 septembre 2021 22:36 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
