My comments inline.... ~ Vijay
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Pekka Savola > Sent: Sunday, February 23, 2003 11:56 PM > To: Vijayabhaskar A K > Cc: 'Ralph Droms'; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > Some comments inline. > > On Sun, 23 Feb 2003, Vijayabhaskar A K wrote: > > > 1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > > > mostly redundant -- the requesting router should just > take the minimum > > > of lifetimes of the prefixes, calculate it in the same > fashion, that's > > > it. Of course, there is an assumption (which doesn't seem to be > > > properly addressed!) that the requesting router is free > to refresh the > > > delegation when it feels right, even every hour, day, month etc. > > > without regard to the lifetimes -- indeed, I think *NO* > implementation > > > would just wait until the last minute to refresh them. > > > > > > Is there something I'm missing? > > > > Normally, T1 will be assigned with a value which is 0.5 times the > > shortest preferred lifetime of the prefixes in the IA_PD. This > > means you have enough time till the expiration of lifetimes of the > > prefixes. > > That doesn't answer the real question. > > That is, the requesting router is in charge of all the > prefixes until they > expire. The robust requesting router implementation will > perform some > sane refreshing of these bindings way before they expire, even > periodically. > > Thus, I fail to see any reason why these values would have to be > communicated from the delegator. Yes, I agree that the it can refresh the bindings at any periodic intervals it want. But, what if the delegating router is dead and not responding at all? Hence, dhcpv6 provides you with two values: T1 -> This is the time at which the requesting router starts contacting the delegating router for the renewal of the lease... T2 -> If till the expiration of T2 it didn't get the response from the delegating router, it can contact any available dhcpv6 server to refresh its bindings. Ofcourse, the requesting router can generate these values itself. With DHCPv6 server sending T1 and T2 values, the requesting router dont need to recalculate the values again and again.. Trust the DHCPv6 server, the values provided by it makes the requesting router to refresh its bindings well before the expiry.. > > > > 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! > > > > Seperate IA_PDs for every downstream interface is not mandatory. > > Look at the following text: > > > > One IA_PD can be associated > > with the requesting router, with a set of interfaces or > with exactly > > one interface. A requesting router must create at least > one distinct > > IA_PD. It may associate a distinct IA_PD with each of > its downstream > > network interfaces and use that IA_PD to obtain a prefix for that > > interface from the delegating router. > > > > Its requesting routers' wish to have single or multiple IA_PDs. > > I know it is not mandatory: but it seems (mostly) unnecessary > to me, which > was the real point. > > > > The only feature I can quickly think of which could profit > > > from this is > > > kind of "shared routers" where the connected interfaces > are separate > > > administrative entities with differently configured > > > properties at the ISP. > > > > Exactly. That's the case. > > When the downstreaming interfaces are served my multiple ISPs, > > you need multiple IA_PDs. > > Prefix delegation by DHCP is not meant to be > all-purpose-zero-configuration tool for routers, I think. > > This seems conflicting -- a fringe case which should not came up. > > Better would be just require that the requesting router will get a > delegation from all the ISP's for itself, and subnet accordingly. > > If the following does not apply, it seems to me that there > must be routers > connected to the downstreaming interfaces -- which in turn > could perform > prefix delegation directly from the ISP, the first router acting as a > relay. > > Doesn't seem to be need for this.. Need not be. Simple case is Home networks, they dont afford to have individual routers for every ISPs. They may need multiple ISPs for high availablity or some other reason. In this case, there will be only one border router with mutiple appliances/nodes in the downstreaming interfaces, which may span in one or more links. In this case, it needs to unique IA_PD for every ISP. > > > > This seems questionable to me, a case for manual configuration or > > > "advanced prefix delegation" to me. > > > > > > So, I think the possibility to do prefix delegation in more > > > complex ways > > > than really necessary should be seriously considered. > Keep it Simple, > > > Stupid would be a good rule. > > > > Generate IA_PDs such that every ISP is associtated with a single > > IA_PD. I think, this is the simplest method possible. > > Seems wrong to me: > > An IA_PD is a construct through which a delegating router and a > requesting router can identify, group and manage a set of related > IPv6 prefixes. > > and: > > Identity Association for Prefix Delegation (IA_PD) A > collection of > prefixes assigned to the requesting > router. Each > IA_PD has an associated IAID. > > ==> the model appears to be, to me, that the requesting > router makes an > association with *one* delegating router. In that case, > multiple IA_PD's > for multiple seem unnecessary. > > If this is not the case, the applicability section needs to > be worked out > a bit more. > > Also, then I can't help wondering what multiple prefixes are for. Why > would anyone (except for bogus /64 for every downstream link > -delegating > requests) want multiple prefixes? (note: site-local is not > applicable, > different admin domains.) May be for high availabilty, it may get prefixes from multiple ISPs. > > Regardless of that, I'm not sure how the requesting router > would discover > more of these delegating routers -- how would they be > connected? Which > kind of infrastructure would typically be between requesting > router and > multiple delegating routers? I beleive there will be unique dialup connection with each ISPs. > > > > 3) One item that may also need some consideration is the > option to let > > > the requesting router give its preference to some values (prefix > > > length, lifetimes, IAprefix-options contents (maybe?), > the prefixes). > > > I'm not sure of the usefulness of these, really. In the > real world, I > > > think ISP's set them, either to some values communicated > off-band, or > > > otherwise. The complexity required (policy, policy,...) when the > > > delegating router must decide whether it can agree to the > requested > > > values seems like a big hit. I'm not really sure whether > it's worth > > > it, even though it may offer some flexibility for some > corner cases. > > > The only commonly used one I could think of would be whether the > > > customer wants _single_ /64 (for the only one subnet!) or > whole /48 -- > > > seems like a heavy baggage for that. > > > > Yes. I too agree with you. If there is no pre-configured information > > for the requesting router in the delegating router, it wont > > be able to to know whether the requesting routers needs /48 or > > /64 bit prefix. > > > > Probably, the solution would be, in the request message, > the requesting > > routers can specify prefix length it prefers. But, the server MUST > > process that and delegate prefixes accordingly, else it should > > send back NoPrefixAvail. > > I agree that for certain requested values, the outcome would get very > confusing for the requesting router if the delegating router > could not > fullfill these requirements. > > But the point was different: I think the whole "preference > for X" model > seems mostly unnecessary. > > > One could use prefix delegation to get multiple /64's > directly from > > > your ISP, then extra bits wouldn't be needed at all. > > > > Instead of getting multiple /64 prefixes, if the requesting router > > belonged to a site with huge number of links, then it can obtain /48 > > prefix and distribute it among the links. > > I totally agree with that (that's the sensible thing to do!), but the > first sentence was not accurate, as you don't split /64 prefixes *IF* > you'd do it nonetheless. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > dhcwg mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
