On 02/10/2011 02:58, "Qiong" <[email protected]> wrote: > Hi Ole and Remi, > >>> > This is my answer to your first (double) question. >>> > If it is not enough, as suggested below, please explain what you don't >>> understand. >> >> I specifically do not want a solution that changes forwarding behaviour for >> _all_ IPv6 packets. >> e.g. looking at 24 bits in the middle of an IPv6 address is such a change. >> >> Woj> What are you referring to? Routing ³just works² as normal and is non >> disaggregated because of the CE-index in the prefix. Classification can/is >> done on a subset of the v6 address, and that is perfectly legit. >> >> I don't understand what requirements you are basing this 'solution' on. >> if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of >> the delegated prefix. then why do you need any of that? > > Qiong : I agree that routing lookup for a provisioned /64 prefix would be > better that extracting certain bits for each IPv6 address in CE. This would > bring less change to existing routing model. > > Woj> There is no change to the existing destination based routing model. Each > CE is uniquely addressed by the CE bits in the top /64 ie the CE index is as > proposed by all the 4rd and divi-pd drafts. The full v4 source address of each > CE is however also embedded in the interface-id, as per RFC6052. There appears > to be no cost for this operation, and has the upside of the full v4 info > visible in the header and allowing source based classification (should one > want to do that). > > Regards, > Woj. > > Best wishes > > Qiong > >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
