On 8/18/2011 3:24 PM, Washam Fan wrote:
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.
There could be,
1.{2408:db8:100::/40, 10.10.1.0/24, 48}
2.{2408:db8::/32, 10.10.0.0/16, 48}
just make sure that the ":100" + ".1.0/24" are excluded when assigning
the CPE IPv6 prefixes to CPEs which will select the second rule to
calculate the IPv4 prefixes. For traffics to these CPEs, longest match
of IPv4 prefix will work.
Cheers,
Jacni
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