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

Hi Tomasz,

On Jul 24, 2011, at 10:53 PM, Tomasz Mrugalski wrote:

> 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.

Thanks for reviewing -02. Comments inline.

> 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".

Makes sense.

> 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.

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.

> 
> 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.

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

> 
> Good luck with the presentation on Thursday!
> 
> Regards,
> Tomek
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg