Subject: [dhcwg] Comments on draft-ietf-dhc-pd-exclude-02

From: Tomasz Mrugalski <[email-masked]>
Date: Sun, 24 Jul 2011 15:53:26 -0400

Hi,
I've just read the updated version of draft-ietf-dhc-pd-exclude-02
draft. Thank you for amending the draft according to most of my
comments. It looks good.

I have several more comments:

1. Section 5.1 describes SOLICIT-ADVERTISE exchange and concludes that
received PD_EXCLUDE may be used to select best server. You may want to
add a single sentence similar to "Requesting router MUST proceed to
Prefix Delegation procedure described in section 6.1".

2. Section 5.1 describes 4 message exchange. What if delegating router
wants to use rapid-commit (SOLICIT-REPLY)? You should add a
clarification that requesting router MUST use received values in REPLY
if rapid-commit option was sent in SOLICIT (recommended). Alternatively,
you may say that rapid-commit is not allowed with PD_EXCLUDE (that would
be unnecessary restriction, so it is not recommended).

3. I acknowledge that authors chose not to follow ORO suboption approach
proposed in draft-mrugalski-dhc-dhcpv6-suboptions. That is unfortunate,
but I can live with it. However, if you still considering that
possibility, I'd like to present additional arguments that may support
ORO suboption approach.

Since PD_EXCLUDE implementation requires modification of both server
(delegating router) and client (requesting router) code, there's no real
difference if you:
a) send top-level ORO and server needs to know that this specific
PD_EXCLUDE option does not go to the message directly, but rathere
within IAPPREFIX
b) send ORO within IA_PD (or IAPREFIX) and server needs to parse it in
those scopes

In both cases, server requires custom logic to be coded to serve
PD_EXCLUDE to requesting routers. My opinion is that option b) would be
generic and would allow reusing this logic for other options that may be
stored as suboptions.

Think about this in a long term. 10 years from now, there will  probably
be around 200 options defined. With your current approach, server will
need to decide on a per option basis, where to return requested options
- directly in message or perhaps within other options.

Ok, that was the last time I tried to convince you to use ORO suboption.
Regardless of your decision, I strongly support your draft.

Good luck with the presentation on Thursday!

Regards,
Tomek

---

From: jouni korhonen <[email-masked]>
Date: Mon, 25 Jul 2011 21:07:44 +0300

Hi Tomasz,

> draft. Thank you for amending the draft according to most of my

Thanks for reviewing -02. Comments inline.

> Prefix Delegation procedure described in section 6.1".

Makes sense.

> be unnecessary restriction, so it is not recommended).

Hmm.. restricting rapid-commit wouldn't make sense, agree. However, the current wording is like it is now due trying to be align with RFC3633, which has the following text in Section 11.1:

   ...
   3315.  The requesting router MAY choose to consider the presence of
   advertised prefixes in its decision about which delegating router to
   respond to.

The above implies me also a 4 message exchange. How about:

   Once receiving Advertise message, the requesting router uses the
   prefix(es) received in OPTION_PD_EXCLUDE in addition to the
   advertised prefixes to choose the delegating router. Requesting
   router MUST proceed to Prefix Delegation procedure described in
   Section 6.1. If Advertise message did not include
   OPTION_PD_EXCLUDE option, then the requesting router MUST fall
   back to normal [RFC3633] Section 11.1 behavior.

> Regardless of your decision, I strongly support your draft.

I understand this. My issue is more of the lack of clear text for this type of OPTION_ORO usage in RFC3315. I can see it mentioned in Appendix B table but that is all. In order to provide unambiguous solution I would most probably add all required text in this I-D as standalone or reference to draft-mrugalski (apparently it the should be a normative reference, with normative language). I don't find either of these as a good approach.

- Jouni

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomasz Mrugalski <[email-masked]>
Date: Mon, 25 Jul 2011 18:02:13 -0400

On 11-07-25 14:07, jouni korhonen wrote:
> Hi Tomasz,
>> 1. Section 5.1 describes SOLICIT-ADVERTISE exchange and concludes
>> that received PD_EXCLUDE may be used to select best server. You may
>> want to add a single sentence similar to "Requesting router MUST
>> proceed to Prefix Delegation procedure described in section 6.1".
> 
> Makes sense.
Great.
> 
>> 2. Section 5.1 describes 4 message exchange. What if delegating
>> router wants to use rapid-commit (SOLICIT-REPLY)? You should add a 
>> clarification that requesting router MUST use received values in
>> REPLY if rapid-commit option was sent in SOLICIT (recommended).
>> Alternatively, you may say that rapid-commit is not allowed with
>> PD_EXCLUDE (that would be unnecessary restriction, so it is not
>> recommended).
> 
> Hmm.. restricting rapid-commit wouldn't make sense, agree. However,
> the current wording is like it is now due trying to be align with
> RFC3633, which has the following text in Section 11.1:
> 
> ... 3315.  The requesting router MAY choose to consider the presence
> of advertised prefixes in its decision about which delegating router
> to respond to.
It is MAY, not MUST. Requesting router may choose not to do it. My
understanding is that requesting router may use rapid-commit and then it
MUST use whatever is required. On the other hand, the use case for
router doing rapid-commit is really a minor use case.

> Section 6.1. If Advertise message did not include OPTION_PD_EXCLUDE
> option, then the requesting router MUST fall back to normal [RFC3633]
> Section 11.1 behavior.
Sounds good.

As for the rapid-commit, maybe something along the following lines would
do the trick: "Requesting router MAY use rapid-commit. Requesting router
that sent SOLICIT message with rapid-commit option, MUST use received
prefix, regardless if PD_EXCLUDE option was provided or not."

It should be noted that rapid-commit benefits for routers are rather
small at this time, but mobile routers avialability is expected to rise
sharply. You may also put a comment about trade-offs between 4 message
exchange and rapid-commit: 4 message is slower, but client is allowed to
choose best server. 2 message is faster, but you have to use what you
get first.

>> Ok, that was the last time I tried to convince you to use ORO
>> suboption. Regardless of your decision, I strongly support your
>> draft.
> 
> I understand this. My issue is more of the lack of clear text for
> this type of OPTION_ORO usage in RFC3315. I can see it mentioned in
That's the whole reason for my draft. RFC3315 is completely silent about
requesting suboptions. I want to clarify that. I'm not lobbying for any
particular way of doing that. I just strongly feel that we should agree
on one way and stick to it. That will be the key message of my
presentation on Thursday. If the WG recommendation is to stick with a
single, top-level ORO, I'm fine with it. dhcpv6-suboptions draft will
just get much simpler.

> Appendix B table but that is all. In order to provide unambiguous
> solution I would most probably add all required text in this I-D as
> standalone or reference to draft-mrugalski (apparently it the should
> be a normative reference, with normative language). I don't find
> either of these as a good approach.
Yes, I see your point. If you put normative reference, it may hold back
publication if pd-exclude until dhcpv6-suboptions is published. I'm not
sure if that is something that can be avoided.

Tomek

---

From: jouni korhonen <[email-masked]>
Date: Tue, 26 Jul 2011 02:26:09 +0300

On Jul 26, 2011, at 1:02 AM, Tomasz Mrugalski wrote:

[snip]

> prefix, regardless if PD_EXCLUDE option was provided or not."

I think there is no need to explicitly mention rapid commit. However, a closer alignment with RFC3633 would be like below:

   Once receiving Advertise message, the requesting router MAY use
   the prefix(es) received in OPTION_PD_EXCLUDE in addition to the 
   advertised prefixes to choose the delegating router. Requesting 
   ...

> choose best server. 2 message is faster, but you have to use what you

Hmm.. rapid commit is something that is in RFC3315 and folks know its benefits. I don't think we need to explore that further in this document.

> sure if that is something that can be avoided.

Imho better just leave it out of this document.

- Jouni

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 Jul 2011 14:24:58 -0500

Regarding issue #3 and draft-mrugalski-dhc-dhcpv6-suboptions-01.txt ...
Actually the list in draft-mrugalski-dhc-dhcpv6-suboptions-01.txt on
page 5 somewhat compares apples and oranges ...

#3. in that list could NEVER use the RFC 3315 ORO as it provides only a
method to identify IANA assigned options and not vendor options. So, I
really don't think this is valid as an argument here. For vendor
options, the vendor will need to define their own ORO option in their
space to accommodate this (if needed). End of story.

Regarding draft-ietf-dhc-pd-exclude-02, I was thinking a bit about how
this might be implemented in servers (whether a delegating router or
server). And, actually, putting the ORO inside the IA_PD option would,
IMHO, be better as it does allow us to start thinking more about what
draft-mrugalski-dhc-dhcpv6-suboptions-01 is proposing.

And, I would think that this pd-exclude option could just be
pre-configured on the appropriate level for the server (prefix,
server-wide, etc) and sent out 'as is' when requested? While today this
would not work for servers that aren't updated to support the ORO at
various levels, it will require a generic server change and not
something specific to this one option.

While DHC RFCs generally stay away from 'server' configuration issues, I
think in this case the two configuration models are to pre-configure it
or have some settings as to whether exclude-pd is enabled, the target
excluded prefix length (likely 64), and whether the all-zero's or
all-one's prefix should be excluded (excluding other values, such as the
example in pd-exclude, is more difficult in this calculated case if the
delegated prefix length is allowed to be variable). This could then be
used in cases where 'clients' (requesting routers) might be delegated a
variety of prefix lengths depending on what they requested (hint) or are
to be given based on some policy decisions.

I also wonder this might even argue for a simplified option ...

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_PD_EXCLUDE       |         option-len = 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  prefix-len   |    flags      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where flags has just 1 bit for now which specifies whether to 0s or 1s
extend the delegated prefix to the prefix-len.

Is the example (where 5 bits of 0|1|1|1|1 where used really realistic)?
Do we really need this level of flexibility?

Another reason for placing this into an IA_PD ORO option is what if
there are multiple IA_PDs and the requesting router is only interested
in supporting this in some cases. Consider the case where the requesting
router has already obtained an IA_PD (w/PD_EXCLUDE) and now needs
another because there are more prefixes needed. In this case, this
request would NOT want to include the PD_EXCLUDE for these additional
IA_PD(s) because they would NOT be used on the WAN interface? So, I
think having this be at the IA_PD level is the correct way to go.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of jouni korhonen
Sent: Monday, July 25, 2011 2:08 PM
To: Tomasz Mrugalski
Cc: DHC WG
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-pd-exclude-02

Hi Tomasz,

Makes sense.

> be unnecessary restriction, so it is not recommended).

Hmm.. restricting rapid-commit wouldn't make sense, agree. However, the
current wording is like it is now due trying to be align with RFC3633,
which has the following text in Section 11.1:

   ...

> Ok, that was the last time I tried to convince you to use ORO
suboption.
> Regardless of your decision, I strongly support your draft.

I understand this. My issue is more of the lack of clear text for this
type of OPTION_ORO usage in RFC3315. I can see it mentioned in Appendix
B table but that is all. In order to provide unambiguous solution I
would most probably add all required text in this I-D as standalone or
reference to draft-mrugalski (apparently it the should be a normative
reference, with normative language). I don't find either of these as a
good approach.

- Jouni