Xiaohong, Thanks for you contribution for this debate. More below.
Le 4 oct. 2011 à 15:26, xiaohong deng a écrit : > Hi Remi, Ole, Woj, and all, > > I understand the argument of IID bits is resulted from a last minute > agreement between 4rd and divi-pd people that having full IPv4 address > embedded in the address format helps source based classification, The agreement is just between those who participated. In no way does it commit the group to anything. Yet I believed it was useful to inform the group that something was found possible, in common by some proponents of encapsulation and double-translation solutions. > but > before we argue that, shall we first make this agreement also be > accepted by community wide? No WG agreement can obviously be reached before an open exchange of views. Exchanging arguments is a necessary part of this process. > As far as current time-being concerned, I > don't see a consensus has been reached on this agreement from > community wide. Very clear. > It IMHO would be helpful if anybody would clarify some details to 1) > first prove source based classification is either a valid or a > non-valid requirement for address mapping; For this regard, I would > begin with that why do we think the source based IPv4 classification > ability instead of the more general five-tuple based IPv4 > classification ability should be reserved, when deliver IPv4 over > IPv6? After having checked details of our common understanding with Xing, Congxiao and Wojciech, I will very soon communicate what we found promising. Sorry for the time it took us. > and 2) then show us how much other efforts are required to achieve so > besides address format definition itself, in other words, if it's a > valid requirement, let's first have feasibility of this requirement > analyzed from both deployment and operational perspectives: > > 1. For double translation, how does a traditional router perform the > source based IPv4 packet classification on IPv6 (translated from IPv4) > packets? Or does it suggest that using IPv6 classification filters to > filter IPv4 packets? The latter was my understanding. With it, filters on IPv4-address, and IPv4-shared-addreses, can be exercised in existing devices if having appropriately configured IPv6-address filters. If this can be achieved with negligible capex and opex costs, and without obligation to do it, why not? > If so, should we also note that this suggests > IPv4 operation and managed are tightly coupled with IPv6 operation and > management? which in turn implies complexity in operational, or put in > other words, > OPEX increasing, the last thing among others that > operators would like to see. Indeed, keeping in mind also that a single well chosen standard tends to reduce overall costs. > 2. For encapsulation, even if embedding source IPv4 addresses in the > lower bits of the address formats, where does the router find the > source port without de-capsulation? Are you suggesting also encode 16 > bits port in the lower part of address? In either case, it leads to > the concerns of increased OPEX to operators stated above. > > Thoughts? An expectation is that copying an available information into a fixed part of an IID shouldn't be expensive at all, and that having IPv4 addresses and port-set IDs in clear form in IPv6 addresses should facilitate maintenance, even if no filter is configured. Cheers, RD > Cheers, > Xiaohong > >> Hi Qiong, >> >> Some fields of a unified address format for double translation and >> encapsulation might be unnecessary for hub and spoke, but using the >> same format should be advantageous for maintenance and training if for >> nothing else (assuming that any added complexity is negligible >> enough). >> >> Believing that a completely unified format is possible, I mentioned it to >> Alain. >> Also, I volunteered to be editor-coordinator for this to happen, but >> decision of who does what is his. >> >> Regards, >> RD >> >> >> Le 4 oct. 2011 à 00:13, Qiong a écrit : >> >>> Hi Remi and Wojciech, >>> >>> Thanks for your clarification. I fully agree with you that embedding the >>> full IPv4 address in the last 64 bits would be quite helpful for some kind >>> of source address classification and I also suggest that this can be taken >>> in the same way for encapsulation-based approach. It would be easier for >>> systems in-the-middle to identify the IPv4 address without packet >>> decapsulation. >>> >>> I guess the thing that Ole has mentioned to "look at 24 bits in the middle >>> of IPv6 address" is for CE to determine whether a downstream IPv6 packet >>> should be taken for translation or native forwarding. Here, for a >>> dual-stack host, there would be no difference in the first /64 bits for a >>> native IPv6 packet and a translated packet. What's why the CE should >>> further looking into the last 64 bits to determine the translation process >>> or native forwarding. Maybe Ole can clarify for this part again. >>> >>> However, the situation would still be different in "Hub & Spoke" and "Mesh" >>> mode. For Hub & Spoke case, since BR will have a default prefix/address, it >>> would be easily to identify the translated traffic from native IPv6 traffic >>> by just doing source address routing lookup for a downstream packet. So, >>> the corresponding mechanics would be different. >>> >>> Thanks >>> >>> Best wishes >>> >>> Qiong >>> >>> 2011/10/3 Wojciech Dec <wdec at cisco.com> >>> >>> >>> >>> >>> On 02/10/2011 02:58, "Qiong" <bingxuere at gmail.com> 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 >>> Softwires at ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> >> > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
