Hi, >> It seems to me, when delegating CE ipv6 prefix, a longest match might >> be used. But when forwarding a IPv4 packet, a longest match is >> useless, because domain 4rd prefixes don't overlap. > > Why? Sorry, I don't follow. The domain IPv4 prefixes can overlap.
if domain 4rd prefixes overlap, when a CE forwards a ipv4 package, it will get confused. because, let's say, two rules matched, it doesn't know which domain ipv6 prefix is used to build outer ipv6 destination address. Thanks, washam > Cheers, > Jacni > >> >> 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
