Re: [OPSAWG] Erik Kline's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)
Understood, thanks. (I yield to the combined power of "out of scope" and "future extension".) On Wed, Sep 22, 2021 at 11:14 PM 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 > > 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 (L3N
Re: [OPSAWG] Erik Kline's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with DISCUSS and COMMENT)
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 > 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 re
[OPSAWG] 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. [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
