Re: [dhcwg] Comments on draft-ietf-dhc-pd-exclude-02 (& draft-mrugalski-dhc-dhcpv6-suboptions-01)

["Bernie Volz (volz)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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,

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg