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.

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

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

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?

> > 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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg