Subject: [v6ops] Fwd: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt

From: jouni korhonen <[email-masked]>
Date: Tue, 20 Dec 2011 09:49:20 +0200

Hemant, all,

We added the applicability statement into the Introduction, which now states the pd-exclude is intended for deployments where CEs are on their own layer 2 domain. This should clear your concern on 'multicast RAs".

- Jouni

Begin forwarded message:

> From: [email-masked]
> Date: December 20, 2011 9:39:24 AM GMT+02:00
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked], [email-masked]
> Subject: New Version Notification for draft-ietf-dhc-pd-exclude-04.txt
> 
> A new version of I-D, draft-ietf-dhc-pd-exclude-04.txt has been successfully submitted by Jouni Korhonen and posted to the IETF repository.
> 
> Filename:	 draft-ietf-dhc-pd-exclude
> Revision:	 04
> Title:		 Prefix Exclude Option for DHCPv6-based Prefix Delegation
> Creation date:	 2011-12-20
> WG ID:		 dhc
> Number of pages: 10
> 
> Abstract:
>   This specification defines an optional mechanism to allow exclusion
>   of one specific prefix from a delegated prefix set when using DHCPv6-
>   based prefix delegation.  The new mechanism updates RFC 3633.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 20 Dec 2011 07:29:18 -0600

Jouni,

The changes look fine to me and appreciate taking care of my comments,

Thanks,

Happy Holidays.

Hemant

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Tuesday, December 20, 2011 2:49 AM
To: [email-masked] Operations; Hemant Singh (shemant)
Subject: Fwd: New Version Notification for
draft-ietf-dhc-pd-exclude-04.txt

Hemant, all,

We added the applicability statement into the Introduction, which now
states the pd-exclude is intended for deployments where CEs are on their
own layer 2 domain. This should clear your concern on 'multicast RAs".

- Jouni

Begin forwarded message:

> Cc: [email-masked], [email-masked],
[email-masked], [email-masked]
> A new version of I-D, draft-ietf-dhc-pd-exclude-04.txt has been
successfully submitted by Jouni Korhonen and posted to the IETF
repository.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Dec 2011 11:28:46 -0800

> own layer 2 domain. This should clear your concern on 'multicast RAs".

As discussed already, I have two objections to this on the grounds that it
needlessly complicates implementations.

First, I object to the text that says "The requesting router must create
sink routes for the delegated prefixes minus the excluded prefixes." This
is complex to implement properly.

I think it should say: "The requesting router must create sink routes for
the entire delegated prefix. If it is desired that the requesting router
route the excluded prefix in any other way, this MUST be configured to do
so via other means (for example, via a Router Advertisement containing a
Prefix Information Option for the excluded prefix and the on-link bit set).

Second, I think the draft should make it clear that only one prefix can be
excluded per delegated prefix, and that if the RR receives (at any time),
another OPTION_IAPREFIX option for the same prefix with different excluded
prefixes, then the RR is free to ignore the previous excluded prefix.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 21 Dec 2011 13:46:35 +0200

Lorenzo,

On Dec 20, 2011, at 9:28 PM, Lorenzo Colitti wrote:

> On Mon, Dec 19, 2011 at 23:49, jouni korhonen <[email-masked]> wrote:
> As discussed already, I have two objections to this on the grounds that it needlessly complicates implementations.
> First, I object to the text that says "The requesting router must create sink routes for the delegated prefixes minus the excluded prefixes." This is complex to implement properly.

I am not sure I agree. Can you clarify why it is so complex to implement properly? Ole already responded to this in http://www.ietf.org/mail-archive/web/v6ops/current/msg11526.html

> I think it should say: "The requesting router must create sink routes for the entire delegated prefix. If it is desired that the requesting router route the excluded prefix in any other way, this MUST be configured to do so via other means (for example, via a Router Advertisement containing a Prefix Information Option for the excluded prefix and the on-link bit set).

Why not proposing the exact text you want to see in the draft?

> 
> Second, I think the draft should make it clear that only one prefix can be excluded per delegated prefix, and that if 

Section 4.1 says  "There can be at most one OPTION_PD_EXCLUDE option in one OPTION_IAPREFIX option". I say it is clearly stated.

> the RR receives (at any time), another OPTION_IAPREFIX option for the same prefix with different excluded prefixes, then the RR is free to ignore the previous excluded prefix.

Why would a DR do such? I do not see such scenario. No problem to state this though.

- Jouni