Any thoughts about the >64 address or a "variable length" longer address as regards this point?
JINMEI Tatuya / 神明達哉 wrote: > >>>>> On Fri, 07 Dec 2001 17:12:17 +0700, > >>>>> Robert Elz <[EMAIL PROTECTED]> said: > > > | is in my opinion more suitable than sorting interfaces on the particular > > | brand of NIC card they are using. > > > There's certainly nothing to commend using the MAC addresses, other than > > that they simplify the algorithm (no special cases), and most particularly > > avoid building in any knowledge of 64 in places where it does not belong. > > > If you can specify this such that it actually uses the currently configured > > prefix lengths (no mention of the number 64 anywhere) and actually find a > > way to make the outcome predictable, then I'd be more inclined to accept it > > as a reasonable change. Otherwise not. > > I agree with kre as for hardcoding 64; it's better to use the > configured prefix length (which may or may not be equal to 64). > > However, I'd rather think longest matching is meaningless in the > destination address ordering, especially with this generalization. > For example consider the following configuration: > > A host has two prefix P::/32 and Q::/64 (P:: != Q::), both of which > can be used to autoconfigure addresses and are regarded as on-link. > The host thus configures P::a and Q::b as its addresses accordingly. > Then the host tries to send a packet to a remote node, and the host > name resolves to P::c and Q'::d, where Q' matches Q:: in 48 bits. > Then the longest matching rule will choose the set of (src=Q::b, > dst=Q'::d). But this may not be the best combination, because the > source and the destination is not on-link and may need many hops in > terms of routing, while P::a and P::c is on-link and can be accessed > within the same single link. > > I know this is quite an artificial example, but I still think the > longest matching in the destination address ordering does not buy much. > > For the source address selection, however, the longest matching is > sometimes useful, because for a given destination address we can > choose a source address in the same ISPs prefix block, which may have > advantage wrt the routing. > > BTW, as for the deterministic behavior, the longest matching still > cannot be the final tie-breaker, as described in the addr-select > draft. If we need full deterministic algorithm, we'll need another > (almost meaningless) rule like "choose a smaller address" which I > recall someone mentioned before in this list. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > [EMAIL PROTECTED] > -------------------------------------------------------------------- > 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] > --------------------------------------------------------------------
begin:vcard n:Adair;Dianna tel;fax:408-986-8482 tel;work:408-986-8689 / 800-845-2323 x-mozilla-html:FALSE org:Volpar Inc adr:;;941 Laurelwood Rd ;Santa Clara ;CA;95054; version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;-1 end:vcard
