Re: [dhcwg] WGLC on draft-ietf-dhc-pd-exclude-01

[Jouni Korhonen <[e-mail]>]

Hi,


On 5/11/11 10:16 AM, "ext Ole Troan" <[e-mail]> wrote:

> Tomek,
> 
> thanks for good comments!

+1

>>> We had a last call on this prior to the Prague meeting, and there was
>>> work done off list, but no responses on-list.   If you support this
>>> work, please indicate that you support it.   If you oppose the work,
>>> please provide suggestions, comments, or reasons why it's entirely a
>>> bad idea.
>> I read and support this draft.
>> 
>> I know that it's way past dead-line, so feel free to ignore my comments.
>> 
>> Here are my comments. If it is not too late, you could consider them:
>> 
>> 1. Section 1:
>> "single aggregatable route/prefix has to represents one customer"
>> => remove "has to" or change represents to represent.
> 
> agree.

Will change to:

"single aggregatable route/prefix has to represent one customer"



> 
>> 2. Section 4.1
>> "The requesting router MUST NOT assign the excluded prefix to any of its
>> downstream interfaces.". Is this implicit suggestion that assigning
>> excluded prefix to upstream interface is ok? That would be against
>> RFC3633, Section 12.1 that forbids that. This is probably ok, but then
>> "updates: 3633" should be added to the preamble (and possibly a simple
>> clarification). However, if the excluded prefix is handled in some
>> different way (like SLAAC), then it is ok in current form.
> 
> we are basically trying to say that the excluded prefix is not delegated to
> the requesting router.
> that means the requesting router has no 'ownership' of that prefix and cannot
> assign it to any interface.
> obviously the delegating router can advertise that prefix in an RA and then
> the requesting router can use SLAAC to configure an address out of the prefix.
> do you think this needs clarification, if so suggested text?
> 
>> 3. Section 4.2
>> "The OPTION_PD_EXCLUDE option MUST be located before the possible Status
>> Code option in the IAprefix-options field." Why forcing to use specific
>> order? DHCPv6 does not impose any restrictions regarding sequence, in
>> which options appear in a message or within other options. There's good
>> reason for that - implementations may keep the options in structures
>> other than simple lists or vector, like hash tables. Enforcing any
>> specific order would be troublesome in that case. I propose to remove
>> this sentence.
> 
> I tend to agree, what do my co-authors think?
> can't remember why we put this in the first place...

I put this there for some reason. Now I have been trying to remember what
was the original reason.. without success. Therefore, if I cannot even
remember it anymore there is no reason to have the MUST there. Ok to remove
the sentence.

> 
>> 4. Section 5.1
>> My understanding was that requesting router is supposed to include
>> PD_EXCLUDE in ORO in SOLICIT, REQUEST, RENEW, REBIND and CONFIRM. Yet,
>> there is only Solicit message mentioned in the first sentence of 5.1.
>> Remaining message types should probably be mentioned as well.
> 
> what about:
> 
> If the requesting router implements the solution described in Section 4.1
> then the requesting router SHOULD include the OPTION_PD_EXCLUDE option code in
> the OPTION_ORO option in DHCP messages
> as described in section 22.7 of RFC3315.

Ole's text looks good to me.

> 
>> 5. PD_EXCLUDE option is going to be delivered in IAPREFIX that is
>> located in IA_PD (not in the message options field), but draft says that
>> requesting router should request PD_EXCLUDE in ORO placed in message
>> options field. Wouldn't it be more appropriate to put second instance of
>> ORO (with PD_EXCLUDE code) in IA_PD sent by requesting router? You may
>> consider reading draft-mrugalski-dhc-dhcpv6-suboptions and follow its
>> suggestions, if you that they are reasonable.
> 
> good point, I wasn't aware of this. I also think including the ORO at the
> correct option 'scope' is better.
> any objections to that?

I have no strong opinion here. However, options that are used and what we
also define have a flat option number space, thus scoping does not bring
much advantage as we are not defining a sub-option per se. I see no
compelling reason to change the current text/behavior.

- Jouni


> 
> cheers,
> Ole