Subject: [L3sm] Suresh Krishnan's Discuss on draft-ietf-l3sm-l3vpn-service-model-18: (with DISCUSS)

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 26 Oct 2016 10:13:26 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-l3sm-l3vpn-service-model-18: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I do have a concern about the definition of the IPv6 address allocation
mechanisms. It looks like the service model assumes that one of these
mechanisms will be used, while in reality more than one of these
mechanisms might be in use at the same time. I just wanted to make sure
that this was a considered decision and not an oversight.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Oct 2016 18:37:21 +0100

Hey Suresh,

So, you are asking whether an operator might use more than one of the four listed IPv6 address allocation mechanisms for a single point of attachment for a single site?

I need to defer that question to the operators. Seems a little unlikely to me, but who knows :-)

Thanks,
Adrian

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]]
> Sent: 26 October 2016 18:13
> To: The IESG
> Cc: [email-masked]; Qin Wu; [email-masked];
> [email-masked]; [email-masked]
> Subject: Suresh Krishnan's Discuss on draft-ietf-l3sm-l3vpn-service-model-18:
> (with DISCUSS)
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 27 Oct 2016 01:25:15 +0000

The issue you discussed here was also brought up in Giles's review on v(-15)
The author's answer was unlikely as well.
I quoted the relevant discussion below:
"
> 
> 23) You say “three ways of IP address allocation :” and then list four.
> [SLI] Thanks, we added one more couple of weeks ago :)
> 24) isn’t there also a case with v6 where you do both SLAAC and DHCP 
> (using DHCP to assign additional parameters?) 
[SLI] Yes, now the question is do we need to have it in the model ?
not sure :)
"
Talking with author about this issue before going to v(-16), we believe combination of multiple mechanism as an new option can be supported 
By augmentation, i.e., add new address-allocation-type in the model extension.

To address this issue, author proposed the following text in the section 5.1 of v(-16)
"
Section 5.1 Features and augmentation
....
   For example, this model proposes different options for IP address
   assignment, if those options are not filling all requirements, new
   options can be added through augmentation.

"

-Qin
-----邮件原件-----
发件人: Adrian Farrel [mailto:[email-masked]] 
发送时间: 2016年10月27日 1:37
收件人: 'Suresh Krishnan'; 'The IESG'
抄送: [email-masked]; Qin Wu; [email-masked]; Qin Wu; [email-masked]
主题: RE: Suresh Krishnan's Discuss on draft-ietf-l3sm-l3vpn-service-model-18: (with DISCUSS)

Hey Suresh,

Thanks,
Adrian

> Cc: [email-masked]; Qin Wu; 
> [email-masked]; [email-masked]; [email-masked]
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> I do have a concern about the definition of the IPv6 address 
> allocation mechanisms. It looks like the service model assumes that 
> one of these mechanisms will be used, while in reality more than one 
> of these mechanisms might be in use at the same time. I just wanted to 
> make sure that this was a considered decision and not an oversight.
> 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 27 Oct 2016 04:12:14 +0000

Hi Adrian,

> So, you are asking whether an operator might use more than one of the four listed IPv6 address allocation mechanisms for a single point of attachment for a single site?

Not exactly. I already know there are operators that will require more than 
one mechanism at the same time (e.g. SLAAC for addressing and DHCPv6 for 
prefix delegation). My question was *how* the model will support such 
operators, or if the WG made a decision to not support such operators at all.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 27 Oct 2016 04:14:29 +0000

Hi Qin,

>    options can be added through augmentation.

I think it is good to make that text change to allow for future mechanisms 
but that does not address my concern. My question was how the model will 
support cases where more than one of the such mechanisms needs to be in use 
at the same time.

Thanks
Suresh

---

From: Qin Wu <[email-masked]>
Date: Thu, 27 Oct 2016 06:07:50 +0000

Suresh:
-----邮件原件-----
发件人: Suresh Krishnan [mailto:[email-masked]] 
发送时间: 2016年10月27日 12:14
收件人: Qin Wu; [email-masked]; 'The IESG'
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: Suresh Krishnan's Discuss on draft-ietf-l3sm-l3vpn-service-model-18: (with DISCUSS)

Hi Qin,

On 10/26/2016 09:25 PM, Qin Wu wrote:
> The issue you discussed here was also brought up in Giles's review on 
> v(-15) The author's answer was unlikely as well.
> Talking with author about this issue before going to v(-16), we 
> believe combination of multiple mechanism as an new option can be supported By augmentation, i.e., add new address-allocation-type in the model extension.
>
> To address this issue, author proposed the following text in the 
> section 5.1 of v(-16) "

I think it is good to make that text change to allow for future mechanisms but that does not address my concern. My question was how the model will support cases where more than one of the such mechanisms needs to be in use at the same time.

[Qin]:Let me make it clear, the base model doesn't support this case since isn't one allocation mechanism for a single point of attachment for a single site enough?, suppose you need to support both SLAAC and DHCP, we can define a new address-allocation-type (let's call it dhcp-slaac) as a new option in the base model extension rather than in base model, to support this case by augmentation. You may add a few parameters and YANG statements under container ipv4 and ipv6 to describe when address-allocation-type is dhcp-slaac what should be included. I can give you an example if needed.

Thanks
Suresh

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 27 Oct 2016 11:38:17 +0100

Thanks Suresh,

I'm still trying to understand.
This is an L3VPN service so the address assignment we are looking at is for a
single CE-PE connection only.
If you tell me that there are operators that want to use multiple address
assignment mechanisms for this, then I believe you. It's kind of unfortunate
that we didn't encounter any of them in the WG.

So it's not a conscious decision to not support those operators. Rather a
non-decision.

Perhaps if you can put us in touch with one of the operators you know require
more than one mechanism, we can work with them to work out what changes are
needed in the model.

Thanks,
Adrian

> Sent: 27 October 2016 05:12
> To: [email-masked]; 'The IESG'
> Cc: [email-masked]; 'Qin Wu';
[email-masked];
> [email-masked]
> Subject: Re: Suresh Krishnan's Discuss on
draft-ietf-l3sm-l3vpn-service-model-18:
> > So, you are asking whether an operator might use more than one of the four
> listed IPv6 address allocation mechanisms for a single point of attachment for
a
> single site?
> =

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 27 Oct 2016 12:18:26 +0000

Hi Adrian,

> single CE-PE connection only.

This is where my disconnect is. The DHCPv6 Prefix delegation is how the 
operator delegates a prefix for use *inside* the customer network (not for 
the CE-PE link - that is probably done using SLAAC or left unnumbered). So 
without PD how does the operator allocate an IPv6 address block for the 
customer? I did read RFC4364 and it is mum about how IPv6 address allocation 
for the C. Is there another normative reference that I am missing?

> more than one mechanism, we can work with them to work out what changes are

Comcast does both SLAAC and DHCPv6-PD on the same link.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 27 Oct 2016 12:19:16 +0000

> [Qin]:Let me make it clear, the base model doesn't support this case since isn't one allocation mechanism for a single point of attachment for a single site enough?, suppose you need to support bot…

Thanks Qin. That makes sense.

Regards
Suresh

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Oct 2016 18:06:31 +0200

Dear authors,

We discussed 
https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/ballot/#suresh-krishnan 
during the IESG telechat.
It's now a COMMENT (as opposed to a DISCUSS), but there is an 
expectation that this issue will be addressed.

Adding a 5th address-allocation-type, dhcp-slaac, would solve the issue.
We can't think of any other valid combinations at this point.

We were also thinking in the direction of adding a sentence that 
address-allocation-type could be augmented in the future (for new type 
or new combinations). However, this is already covered by this generic 
statement.

        In addition, as for any YANG model, this service model can be
        augmented to implement new behaviors or specific features.  For
        example, this model proposes different options for IP address
        assignment, if those options are not filling all requirements, new
        options can be added through augmentation.

So I believe we're good.

Regards, B.
> .