Hi Washam, Le 18 août 2011 à 07:19, Washam Fan a écrit :
> It seems to me, when delegating CE ipv6 prefix, a longest match might > be used. OK, but, again, if a realistic use case is available where longest match is indeed REQUIRED, there is no problem to impose longest match. What is missing so far is this use case. Regards, RD "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove" (A de St Exupéry) > But when forwarding a IPv4 packet, a longest match is > useless, because domain 4rd prefixes don't overlap. > > Thanks, > washam > > 2011/8/17 Rémi Després <[email protected]>: >> >> Le 17 août 2011 à 03:10, Jacni Qin a écrit : >> >>> hi Remi, >>> >>> On 8/16/2011 4:27 PM, Rémi Després wrote: >>>> ... >>>> As already discussed privately, I don't know realistic cases where two >>>> rules would have IPv6 or IPv4 overlapping prefixes. >>>> Consequently, it seems that "longest" match, while being permitted, >>>> doesn't need to be a requirement. >>> If there are multiple ways for CPE to decide the IPv6 prefix, we have to >>> specify the order of priority. e.g., firstly check if there is any >>> implication assigned along with the rules, no? then choose the "longest" >>> match. >>> BTW, I think the longest match is not bad. >> >> It isn't bad, agreed, because it gives the same result as first match when >> prefixes don't overlap. >> It shouldn't however be made a _requirement_ if there is no well understood >> use case because that additional complexity, small but real. >> >> Whether there may be realistic configurations where prefix overlap is useful >> remains AFAIK an open question. >> I have serious doubts, but no time now to argue in details. >> IMHO, It's up to those who argue in favor of longest match to provide at >> least one realistic example (if there is one). >> Then we will agree (or discuss). >> Is that fair? >> >> Cheers, >> RD >> >> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
