Pekka,

>> > 2) Multiple IA_PD looks unnecessarily complex.  Are there any valid
>> > reasons why it wouldn't be just enough to have only one IA_PD per
>> > requesting router?  (The option to and subsequent complexity of)
>> > generating one for each interface seems like a completely unnecessary
>> > feature to me -- it's the router which should be doing prefix delegation
>> > to it's downstream interfaces!
>> 
>> let me pick this one up from the start.
>> the reasons for allowing multiple IA_PDs are:
>> 
>>  - consistency with address assignment as you can use multiple IA_NAs
>>  - future-proofing. in the ISP/user scenario I do see little need for
>>    multiple IA_PDs. if PD is used within an administrative domain
>>    assigning prefixes to downstream interfaces may make more sense
>
> My take on this is is that "we don't need that yet, so why add it yet"; 
> leaving the "base prefix delegation spec" extendable (e.g. define multiple 
> IA_PD's in a later document) would be just fine.
>  
>> it does add some complexity, and I think we've made it pretty clear in
>> the draft that the typical usage will be to use one IA_PD. we just
>> didn't want to close the door on possible future uses of the protocol.
>
> IMO, it wasn't as clear as that.
>
> I can live with this, but I can't help wondering why the base spec has to
> cover even all the theoretical cases.  I'd much rather see a very simple 
> basic version of prefix delegation which can be used to get started.  
> There's no way we could anticipate what will be needed in 3-5 years and we 
> could further define the extensions when they're needed.

well, I have to disagree with you there. keeping PD consistent with
other DHCP options makes for an easier understanding of how it works
and for a simpler implementation. the fundamental idea behind using
DHCP for PD is to re-use the existing DHCP infrastructure including
option semantics. Distilled into one line: "Prefix Delegation with
DHCP is done in exactly the same way as address assignment with DHCP is".

/ot
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to