Re: [Softwires] Path to move forward with 4rd… 4rd-U as transparent as MAP-E
+1 I've read the endless discussion, and found that is seems the MAP also has not fully convinced the ISP operation guys. Since there's explicit controversy, why not just publish them both as experimental. why we must chose one as a standard track? Being a standard track can eliminate operators' misgiving? If the technology is really appropriate, I don't think the experimental status would be a issue for the operators to adopt. Just let the operator decide by themselves. I remembered in the meeting venue, Joel Halpern who chairs Karp and lisp WG, suggested we publish both of them as experimental, and that was exactly how they handle the similar situation in their WG. I think his suggestion is reasonable to be considered. (To Joel: Pardon me if I improperly quoted your comment, or I just misunderstood your suggestion ). -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Simon Perreault Sent: Tuesday, April 03, 2012 8:16 PM To: softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd… 4rd-U as transparent as MAP-E On 2012-04-03 05:40, Ole Trøan wrote: 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using hub and spoke mode with a separate mapping rule per subscriber. in this mode e.g only ports could be embedded in the address. this is not possible in a translation solution like 4rd-U. This mode of operation was suggested last week during the SD-NAT presentation. There seemed to be consensus among operators that it was not practically feasible. 2) a node inside the network will treat translated packets different from encapsulated ones. e.g. for the purposes of counting or for applying features. for an encapsulated packet both the complete IPv4 datagram and the IPv6 header is available, and different features can be applied to both. In practice, the contents of encapsulated packets are rarely inspected by firewalls and other such devices. IMHO at this point we should let the market decide. Publish both as experimental. Let's work on something else now. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
Le 2012-04-03 à 14:43, guoliang han a écrit : Hi, Remi: I don't think my case illustrates MAP-T needs to remain experimental, my comments are below: 2012/4/3 Rémi Després despres.r...@laposte.net Hi, Guoliang, Interesting enough, the example you give illustrates that MAP-T needs to remain experimental, more than any other solution. 1. RFC6145 doesn't say that a PTB1280 WILL BE changed to PTB=1280. It specifies two behaviors, one that does this, and one that doesn't. Which one to choose isn't AFAIK specified in the MAP-T draft. RFC6145 says in Section 6: It SHOULD be possible to configure a translator for either of the two approaches, the first approach is that IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can be administered in compliance with Section 4.3.1 of [RFC4890], the second approach is to change PTB MTU value to 1280 in case PTB1280 and set DF bit to 0 in case the packet is less than or equal to 1280 bytes, if the requirements of the first approach can't be met. It doesn't mean the administrator can refuse to take the second approach according to his will. 2. With 4rd-U, an ICMPv4 PTB1280 always goes to its destination unchanged. This is exactly what is necessary for PMTU discovery to work. Actually, what I worry about is whether IPv6 packets of 4rd-U embedding ICMPv4 packets could traverse current IPv6 firewalls successfully. Typical use cases of 4rd-U have no firewall between BRs and CEs. If some would exist, they should be configured to let ICMPv4 payloads go through (Protocol = 1) This is like configuring them to accept IPv4 headers in IPv6 payloads (Protocol = 4) 3. Now, you suggest to replace DF=1 by DF=0 in BRs. This differs AFAIK from RFC6145, and therefore from MAP-T. See Section 6 of RFC6145. This isn't in RFC6145, simply a reference to (*) below. If I misunderstood, please explain what. When we have a detailed report on which parts of MAP-T have been validated, with which options of RFC6145, it will be easier to analyze scenarios like the one you propose. In any case, thanks for providing one more evidence that the MAP-T specification isn't as clear as claimed to all those who support it, and in particular to some also criticize 4rd-U with invalid arguments. Regards, RD In fact, MAP-T is clear enough to be deployed without any problems, if you read RFC6145 carefully. Replacing IPv4 PTB1280 by IPv4 PTB=1280 should AFAIK be avoided for IPv4 PMTU discovery to work. Still waiting for a clarification on this issue. Regards, RD regards, Guoliang Le 2012-04-03 à 05:26, 韩国梁 a écrit : +1. As a follower of MAP team, I participated much in developing and deploying double-translation in CERNET. As far as I am concerned, in the translation scenario, 4rd-U only solved some corner cases but missed some other cases simultaneously. As an example, I suppose one fragmentation case as following: (IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translator)--(IPv4 network)---IPv4 host The minumum MTU of IPv6 access network is 1400, and the minimum MTU of IPv4 network on the right side is 800. Now an IPv4 host on the left side sends a packet with length set to 1200 and MTU set to 1, to the IPv4 host in the right side. The packet could traverse the IPv6 access network, but will be blocked in the IPv4 network. (*) In this case, BR(Core Translator) must set DF to 0 when translating from IPv6 back to IPv4, instead of preserving the original IPv4 DF bit. In fact, according to RFC6145, if BR(Core Translator) receives an ICMP Packet Too Big packet whose indicating MTU is less than 1280 bytes, it will change it to 1280. So if the BR preserve the DF bit, the sender will always believe the path MTU is 1280, which will certainly lead to a black hole. This is only one deployment problem, and we don't know how many issues will be encountered in the future. So my point is that 4rd-U still needs examination in the actual deployment, and it's a bit early to propose it as an Informational/Standards Track Document. The mail sent yesterday seemed to encounter some problems. So if you see this mail twice, sorry for that. regards, Guoliang 2012/3/26 Maoke fib...@gmail.com hi Remi, let me remove those you have marked as end. they are fine to me too. only one point: no implementation nor operation trouble != it is safe to say it an architectural building block of tunnel. if we both say 4rd-u is an alternative for translation, it would be much clear. (i don't think it is a tunnel variant at all, due to not providing virtual links; while you insist it not a translation at all). 2012/3/25 Rémi Després despres.r...@laposte.net c) MAP-A+P says Each MAP node in the domain has the same set of rules while MAP-T says if a CE knows only a subset of the
Re: [Softwires] Path to move forward with 4rd…
2012/4/3, Wojciech Dec wdec.i...@gmail.com: On 2 April 2012 19:10, Rémi Després despres.r...@laposte.net wrote: Woj Well, in terms of facts we have 1. 4rd-U does not supporting single translation mode, Not claimed to. It's good to get clarity now that previous 4rd-U claims of supporting services such as web-caching, log-on-portals, etc. are now false, and no longer claimed. MAP(-T) continues to allow these. I don't see the difference between 4rd-U and MAP-T on this pionts. BTW, woj, do you really see the value of supporting single translation. I guess that is not targeting scenario for Softwires wg. IMHO, this single translation is not sufficient in the wild. It's only applicable for a subset of IPv6 address (i.e. IPv4-converted addresses communicating with IPv4-translatable addresses) BRs Gang ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
2012-04-03 18:32, Marc Blanchet : I don't see a way out of this thread. my suggestion: - published both as experimental - let the market decide - come back later to move one or the other standard track. +1 RD Above all, I think having a stable specification (i.e. RFC) that implementers can code against and providers to require is what is needed first. Marc. Le 2012-04-03 à 11:14, Jan Zorz @ go6.si a écrit : Dear Softwires WG chairs. For how long will you leave this useless cockfight go on instead of steering the working group into a direction, that may enable us to decide on something and chose the direction? We are running in circles here and just amplificating the noise, coming from certain usual suspects. Cheers, Jan P.S: I too enjoy observing the roosters fight, but I don't think we have time for this now. :) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
Here's the situation. There was no clear consensus in the WG meeting in Paris. But the IETF conducts its business on the mailing list, so - as we always do - the chairs asked for feedback on the two questions asked in Paris. We'll use the responses to assess if there is consensus for the choices in each of those questions. - Ralph On Apr 4, 2012, at 8:52 PM 4/4/12, Maoke wrote: 2012/4/4 Marc Blanchet marc.blanc...@viagenie.ca Le 2012-04-03 à 22:25, Maoke a écrit : a serious point not of the Apr-1 joke: as an IETF WG, we are obliged to provide surely high-quality document to the market. even we believe market choice, at least we have to publish what we ourselves have well understood, carefully coded and well tested. otherwise, the market would see IETF more of a group of doc-makers rather than technology-explorers. agreed. then what do we do in the absence of consensus? I proposed one solution. i propose another, maybe closer to the chairs' opinion: let's do the vote and decide with the game rule of majority wins, stopping the endless vote. ;-) - maoke Marc. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
On 4/3/12 3:53 AM, Satoru Matsushima wrote: FYI, choosing MAP doesn't mean that committing to a 'single'. But choosing 4rd-u means that committing to a 'single'. There're just transport variants, which are encapsulation, translation and new one we've never seen before. Proponents of the new one claim to unify transport only to the new one, which means that eliminating both encapsulation and translation variants of MAP because they say two choice of transport type would make confusion for operators. The new one is transparent than translation, but less than encapsulation. I couldn't decide transport type to be unified with the new one. No evidence, no expertise, no experience for that. Do we need them to be sure in spite of we already have existing mature transport variants? cheers, --satoru +1 Given the situation with IPv4 exhaustion we have to hurry and go with what we know and what is proven to work today with no funky new features. I agree that 4RD-U brings some good new features, but as it changes the IPv6 current usage I suggest to redirect 4RD-U to BoF and to go through revision of also other working groups that needs to say their understanding of changed IPv6 transport behavior. I also believe that when 4RD-U goes through the whole proper procedure it might be widely adopted later as MAP replacement. Meantime - let's fix the problem with what we know and understand. Speaking as A+P (RFC6346) co-author, we got many questions about A+P progress from operators and we learned that the time-frame for decision between CGN and something else is already nearly expired. If we want anything-A+P to still reach the operators, then the time for decision is now. We already missed the majority of that train, but last seats in last wagon are still reachable. We need to act and not just to push the endless discussion (that is not that uncommon for any IETF WG :) ). Cheers, Jan Zorz ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… 4rd-U as transparent as MAP-E
Le 2012-04-03 à 03:53, Satoru Matsushima a écrit : FYI, choosing MAP doesn't mean that committing to a 'single'. But choosing 4rd-u means that committing to a 'single'. There're just transport variants, which are encapsulation, translation and new one we've never seen before. Proponents of the new one claim to unify transport only to the new one, which means that eliminating both encapsulation and translation variants of MAP because they say two choice of transport type would make confusion for operators. The new one is transparent than translation, but less than encapsulation. If you would have a detailed scenario where ANY transparency difference could be noticeable e2e between a MAP-E tunnel and a 4rd-U tunnel, this sentence would be fair. However, you haven't shown such a scenario, and AFAIK you can't have one because it doesn't exist. The above assertion, being wrong, is therefore misleading. I couldn't decide transport type to be unified with the new one. No evidence, no expertise, no experience for that. But many of those who have no motivation to look for flaws that don't exist, do understand that the design is safe. Do we need them to be sure in spite of we already have existing mature transport variants? MAP-E+T isn't as mature as repeatedly claimed. MAP-T may be more imprecise than MAP-E in this respect, but both have known bugs to be fixed (at least packet IDs of shared-addres CEs of MAP-T, and BR hairpinning in MAP-E). Besides, the exact list of MAP DHCPv6 parameters has yet to be finalized. Cheers, RD cheers, --satoru On 2012/04/03, at 2:47, Tom Taylor wrote: People on the list might get the impression that Rene is single-handedly holding up WG progress. I have not been involved in this work, but did observe at the meeting a show of hands for 4rd-U at least as numerous as that for MAP. For whatever reason, the WG at large does not seem prepared to commit to a single solution. On 02/04/2012 11:17 AM, Wojciech Dec wrote: On 2 April 2012 15:46, Rémi Desprésdespres.r...@laposte.net wrote: Le 2012-04-02 à 12:33, Ole Trøan a écrit : If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections. the objections I'm aware of are: - people are uncomfortable with only a double translation solution Are you furtively suggesting that 4rd-U has all limitations of a real double translation solution like MAP-T? That mays sound tactically smart, but isn't justified by facts. Woj Well, in terms of facts we have 1. 4rd-U does not supporting single translation mode, or if it does then is requires NAT64/BIH/Something else. (How anybody thinks that deploying 4rd-u + something else is manageable is a mystery) 2. 4rd-u is incompatible with NAT64 use or deployment 2. MAP solution (call it MAP, divi, or other variants) has proven deployment 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves problems that are non-issues to operators. 4. 4rd-u changes the basic structure/use of the v6 header, which is a change to IPv6 that needs to be vetted by 6man, etc. Creating such novel (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and use, effectively creates a new IPv6 protocol sub-class. Indeed 4rd-u deserves an experimental status track, more than anything. -Wojciech. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… 4rd-U as transparent as MAP-E
If you would have a detailed scenario where ANY transparency difference could be noticeable e2e between a MAP-E tunnel and a 4rd-U tunnel, this sentence would be fair. However, you haven't shown such a scenario, and AFAIK you can't have one because it doesn't exist. The above assertion, being wrong, is therefore misleading. there is more to this than comparing the IPv4 packet put into to the 4rd-U cloud against the packet exiting the 4rd-U cloud. (from that perspective MAP-T and 4rd-U are for most practical solutions equal (IMHO)). 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using hub and spoke mode with a separate mapping rule per subscriber. in this mode e.g only ports could be embedded in the address. this is not possible in a translation solution like 4rd-U. 2) a node inside the network will treat translated packets different from encapsulated ones. e.g. for the purposes of counting or for applying features. for an encapsulated packet both the complete IPv4 datagram and the IPv6 header is available, and different features can be applied to both. Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… 4rd-U as transparent as MAP-E
Le 2012-04-03 à 11:40, Ole Trøan a écrit : If you would have a detailed scenario where ANY transparency difference could be noticeable e2e between a MAP-E tunnel and a 4rd-U tunnel, this sentence would be fair. However, you haven't shown such a scenario, and AFAIK you can't have one because it doesn't exist. The above assertion, being wrong, is therefore misleading. there is more to this than comparing the IPv4 packet put into to the 4rd-U cloud against the packet exiting the 4rd-U cloud. What else? (from that perspective MAP-T and 4rd-U are for most practical solutions equal (IMHO)). Nothing new here, but this is only an opinion, not a technical consideration. 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using hub and spoke mode with a separate mapping rule per subscriber. in this mode e.g only ports could be embedded in the address. New requirement? New feature? Your draft says Each MAP node in the domain has the same set of rules. It's getting very confusing. BTW, is this something you claim to have been tested? If you want to pursue this point, a use-case example with its mapping rules could help to understand what you have in mind. this is not possible in a translation solution like 4rd-U. 2) a node inside the network will treat translated packets different from encapsulated ones. Yes, but so what? e.g. for the purposes of counting or for applying features. for an encapsulated packet both the complete IPv4 datagram and the IPv6 header is available, and different features can be applied to both. I don't see what would be missing with 4rd-U: - the IPv4 payload is available - IPv4 source and destination addresses are available in a fixed position of IPV6 addresses - IPv6 packets that are header-mapped IPv4 packets are recognizable wit the V octet of the CE address Cheers, RD Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
Hi, Remi: Pls read my comments below. 2012/4/3 Rémi Després despres.r...@laposte.net 2012-04-03 14:43, guoliang han : Hi, Remi: I don't think my case illustrates MAP-T needs to remain experimental, my comments are below: 2012/4/3 Rémi Després despres.r...@laposte.net Hi, Guoliang, Interesting enough, the example you give illustrates that MAP-T needs to remain experimental, more than any other solution. 1. RFC6145 doesn't say that a PTB1280 WILL BE changed to PTB=1280. It specifies two behaviors, one that does this, and one that doesn't. Which one to choose isn't AFAIK specified in the MAP-T draft. RFC6145 says in Section 6: It SHOULD be possible to configure a translator for either of the two approaches, the first approach is that IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can be administered in compliance with Section 4.3.1 of [RFC4890], the second approach is to change PTB MTU value to 1280 in case PTB1280 and set DF bit to 0 in case the packet is less than or equal to 1280 bytes, if the requirements of the first approach can't be met. It doesn't mean the administrator can refuse to take the second approach according to his will. 2. With 4rd-U, an ICMPv4 PTB1280 always goes to its destination unchanged. This is exactly what is necessary for PMTU discovery to work. Actually, what I worry about is whether IPv6 packets of 4rd-U embedding ICMPv4 packets could traverse current IPv6 firewalls successfully. Typical use cases of 4rd-U have no firewall between BRs and CEs. If some would exist, they should be configured to let ICMPv4 payloads go through (Protocol = 1) This is like configuring them to accept IPv4 headers in IPv6 payloads (Protocol = 4) Hope so. Still anticipating experimental results proving that yet. 3. Now, you suggest to replace DF=1 by DF=0 in BRs. This differs AFAIK from RFC6145, and therefore from MAP-T. See Section 6 of RFC6145. This isn't in RFC6145, simply a reference to (*) below. If I misunderstood, please explain what. You surely misunderstood that. I mentioned in that case, instead of replacing DF=1 by DF=0 in all cases. Replacing DF bit only occurs in the case that incoming packet size is less that 1280 bytes, which is exactly the requirement of RFC6145. When we have a detailed report on which parts of MAP-T have been validated, with which options of RFC6145, it will be easier to analyze scenarios like the one you propose. In any case, thanks for providing one more evidence that the MAP-T specification isn't as clear as claimed to all those who support it, and in particular to some also criticize 4rd-U with invalid arguments. Regards, RD In fact, MAP-T is clear enough to be deployed without any problems, if you read RFC6145 carefully. Replacing IPv4 PTB1280 by IPv4 PTB=1280 should AFAIK be avoided for IPv4 PMTU discovery to work. Still waiting for a clarification on this issue. If the translator set DF bit to 0 in case the packet is less than or equal to 1280 bytes, and replace PTB1280 by PTB=1280, there are no problems on the data path, whether in single/double translation. Regards, Guoliang Regards, RD regards, Guoliang Le 2012-04-03 à 05:26, 韩国梁 a écrit : +1. As a follower of MAP team, I participated much in developing and deploying double-translation in CERNET. As far as I am concerned, in the translation scenario, 4rd-U only solved some corner cases but missed some other cases simultaneously. As an example, I suppose one fragmentation case as following: (IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translator)--(IPv4 network)---IPv4 host The minumum MTU of IPv6 access network is 1400, and the minimum MTU of IPv4 network on the right side is 800. Now an IPv4 host on the left side sends a packet with length set to 1200 and MTU set to 1, to the IPv4 host in the right side. The packet could traverse the IPv6 access network, but will be blocked in the IPv4 network. (*) In this case, BR(Core Translator) must set DF to 0 when translating from IPv6 back to IPv4, instead of preserving the original IPv4 DF bit. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
Le 2012-04-03 à 15:41, Guoliang a écrit : Hi, Remi: Pls read my comments below. 2012/4/3 Rémi Després despres.r...@laposte.net Le 2012-04-03 à 14:43, guoliang han a écrit : Hi, Remi: I don't think my case illustrates MAP-T needs to remain experimental, my comments are below: 2012/4/3 Rémi Després despres.r...@laposte.net Hi, Guoliang, Interesting enough, the example you give illustrates that MAP-T needs to remain experimental, more than any other solution. 1. RFC6145 doesn't say that a PTB1280 WILL BE changed to PTB=1280. It specifies two behaviors, one that does this, and one that doesn't. Which one to choose isn't AFAIK specified in the MAP-T draft. RFC6145 says in Section 6: It SHOULD be possible to configure a translator for either of the two approaches, the first approach is that IPv6 hosts, IPv6-host-based firewalls, and IPv6 network firewalls can be administered in compliance with Section 4.3.1 of [RFC4890], the second approach is to change PTB MTU value to 1280 in case PTB1280 and set DF bit to 0 in case the packet is less than or equal to 1280 bytes, if the requirements of the first approach can't be met. It doesn't mean the administrator can refuse to take the second approach according to his will. 2. With 4rd-U, an ICMPv4 PTB1280 always goes to its destination unchanged. This is exactly what is necessary for PMTU discovery to work. Actually, what I worry about is whether IPv6 packets of 4rd-U embedding ICMPv4 packets could traverse current IPv6 firewalls successfully. Typical use cases of 4rd-U have no firewall between BRs and CEs. If some would exist, they should be configured to let ICMPv4 payloads go through (Protocol = 1) This is like configuring them to accept IPv4 headers in IPv6 payloads (Protocol = 4) Hope so. Still anticipating experimental results proving that yet. 3. Now, you suggest to replace DF=1 by DF=0 in BRs. This differs AFAIK from RFC6145, and therefore from MAP-T. See Section 6 of RFC6145. This isn't in RFC6145, simply a reference to (*) below. If I misunderstood, please explain what. You surely misunderstood that. I mentioned in that case, instead of replacing DF=1 by DF=0 in all cases. Replacing DF bit only occurs in the case that incoming packet size is less that 1280 bytes, which is exactly the requirement of RFC6145. The so called corner case where RFC6145 looses the DF=1 is when a packet with DF=1 is already fragmented by its source. In this case, because there are several fragments, translates back to IPv4 with DF=0. In the example you give, RFC6145 doesn't add a fragment header, in the IPv4 to IPv6 translation because the packet has DF=1 and isn't fragmented (sec 4). The inverse translation, seeing no fragment header, the DF bit is normally set to 1 (sec 5.1). (A configuration option is mentioned so that the node MAY set it to 0 in some conditions, but MAP-T makes clear this must not be the case: the IPv4 packets with DF=1 will be translated to IPv6 packets without fragmentation header and will be translated back to IPv4 packets with DF=1.) When we have a detailed report on which parts of MAP-T have been validated, with which options of RFC6145, it will be easier to analyze scenarios like the one you propose. In any case, thanks for providing one more evidence that the MAP-T specification isn't as clear as claimed to all those who support it, and in particular to some also criticize 4rd-U with invalid arguments. Regards, RD In fact, MAP-T is clear enough to be deployed without any problems, if you read RFC6145 carefully. Replacing IPv4 PTB1280 by IPv4 PTB=1280 should AFAIK be avoided for IPv4 PMTU discovery to work. Still waiting for a clarification on this issue. If the translator set DF bit to 0 in case the packet is less than or equal to 1280 bytes, and replace PTB1280 by PTB=1280, there are no problems on the data path, whether in single/double translation. In any case, not a MAP-T feature. RD Regards, Guoliang Regards, RD regards, Guoliang Le 2012-04-03 à 05:26, 韩国梁 a écrit : +1. As a follower of MAP team, I participated much in developing and deploying double-translation in CERNET. As far as I am concerned, in the translation scenario, 4rd-U only solved some corner cases but missed some other cases simultaneously. As an example, I suppose one fragmentation case as following: (IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translator)--(IPv4 network)---IPv4 host The minumum MTU of IPv6 access network is 1400, and the minimum MTU of IPv4 network on the right side is 800. Now an IPv4 host on the left side sends a packet with length set to 1200 and MTU set to 1, to the IPv4 host in the right side. The packet could traverse the IPv6 access network, but will be blocked in the IPv4 network. (*)
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
Dear Softwires WG chairs. For how long will you leave this useless cockfight go on instead of steering the working group into a direction, that may enable us to decide on something and chose the direction? We are running in circles here and just amplificating the noise, coming from certain usual suspects. Cheers, Jan P.S: I too enjoy observing the roosters fight, but I don't think we have time for this now. :) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… 4rd-U as transparent as MAP-E
Hi Remi, Do we need them to be sure in spite of we already have existing mature transport variants? MAP-E+T isn't as mature as repeatedly claimed. MAP-T may be more imprecise than MAP-E in this respect, but both have known bugs to be fixed (at least packet IDs of shared-addres CEs of MAP-T, and BR hairpinning in MAP-E). If you pointed out bugs in the text of MAP-E/MAP-T drafts, we will correct it soon. But what you pointed out in the above has been already tested with our implementation of MAP-T/MAP-E. So, our MAP-E/MAP-T implementation has already supported BR hairpinning (hubspoke model). Thanks, Tetsuya Murakami ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
I don't see a way out of this thread. my suggestion: - published both as experimental - let the market decide - come back later to move one or the other standard track. Above all, I think having a stable specification (i.e. RFC) that implementers can code against and providers to require is what is needed first. Marc. Le 2012-04-03 à 11:14, Jan Zorz @ go6.si a écrit : Dear Softwires WG chairs. For how long will you leave this useless cockfight go on instead of steering the working group into a direction, that may enable us to decide on something and chose the direction? We are running in circles here and just amplificating the noise, coming from certain usual suspects. Cheers, Jan P.S: I too enjoy observing the roosters fight, but I don't think we have time for this now. :) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
The irony is that this is an apples and oranges comparison, and throwing away ripe apples into some box with raw oranges looks rather unfair. Some of the of the indicators are: - MAP is not only the result of a consensus of a broad WG design team, but also that of numerous authors of the merged drafts whihc have been discussed for 1 year+. The 4rd-u technical proposals were evaluated by the design team, and have not gained support there. - MAP running code exist - 4rd-U covers a technical corner case that is self created (if not self invented/motivated) - 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 sign-up portal, etc) - 4rd-U is not by any means universal. As admitted it requires the coupling with BIH, which features the same technical corner case that 4rd-u claims to solve (doh). The other aspect is that some different measure appears to be being applied in this selection *for WG adoption* vs the selection of the other drafts in softwire, which have gained WG draft status without even a shred of running code. -Woj. On 3 April 2012 18:32, Marc Blanchet marc.blanc...@viagenie.ca wrote: I don't see a way out of this thread. my suggestion: - published both as experimental - let the market decide - come back later to move one or the other standard track. Above all, I think having a stable specification (i.e. RFC) that implementers can code against and providers to require is what is needed first. Marc. Le 2012-04-03 à 11:14, Jan Zorz @ go6.si a écrit : Dear Softwires WG chairs. For how long will you leave this useless cockfight go on instead of steering the working group into a direction, that may enable us to decide on something and chose the direction? We are running in circles here and just amplificating the noise, coming from certain usual suspects. Cheers, Jan P.S: I too enjoy observing the roosters fight, but I don't think we have time for this now. :) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
well, i cannot help but send out this late Apr-1 joke: let's see what is the problem publishing the two document plus an informational doc analysing what problems 4rd-u introduces to architecture and real operation, with them all stable and having an RFC number for each? if this is fine, we all could be happy and the peace comes. lol a serious point not of the Apr-1 joke: as an IETF WG, we are obliged to provide surely high-quality document to the market. even we believe market choice, at least we have to publish what we ourselves have well understood, carefully coded and well tested. otherwise, the market would see IETF more of a group of doc-makers rather than technology-explorers. - maoke - we reject kings, presidents, and voting... - Rex redivit. vive le Roi. 2012/4/3 Marc Blanchet marc.blanc...@viagenie.ca well, let's see the other way around: what is the problem of publishing the two documents now?So that they are stable and have a RFC number. Then any implementer can implement based on the RFC. Providers can request their manufacturers to have a product which conforms to the RFC. Marc. Le 2012-04-03 à 14:56, Wojciech Dec a écrit : The irony is that this is an apples and oranges comparison, and throwing away ripe apples into some box with raw oranges looks rather unfair. Some of the of the indicators are: - MAP is not only the result of a consensus of a broad WG design team, but also that of numerous authors of the merged drafts whihc have been discussed for 1 year+. The 4rd-u technical proposals were evaluated by the design team, and have not gained support there. - MAP running code exist - 4rd-U covers a technical corner case that is self created (if not self invented/motivated) - 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 sign-up portal, etc) - 4rd-U is not by any means universal. As admitted it requires the coupling with BIH, which features the same technical corner case that 4rd-u claims to solve (doh). The other aspect is that some different measure appears to be being applied in this selection *for WG adoption* vs the selection of the other drafts in softwire, which have gained WG draft status without even a shred of running code. -Woj. On 3 April 2012 18:32, Marc Blanchet marc.blanc...@viagenie.ca wrote: I don't see a way out of this thread. my suggestion: - published both as experimental - let the market decide - come back later to move one or the other standard track. Above all, I think having a stable specification (i.e. RFC) that implementers can code against and providers to require is what is needed first. Marc. Le 2012-04-03 à 11:14, Jan Zorz @ go6.si a écrit : Dear Softwires WG chairs. For how long will you leave this useless cockfight go on instead of steering the working group into a direction, that may enable us to decide on something and chose the direction? We are running in circles here and just amplificating the noise, coming from certain usual suspects. Cheers, Jan P.S: I too enjoy observing the roosters fight, but I don't think we have time for this now. :) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd… More MAP-T experiment needed
Fully agree with Maoke! This is not just the issue of publishing two documents...To accormodate with 4rd-U, many existing RFCs should be updated, like RFC 4291,RFC6052,etc. There is no evidence to show that we need to do that because 4rd-U havn't been shown that it is workable in today's Internet. Congxiao 2012/4/4 Maoke fib...@gmail.com well, i cannot help but send out this late Apr-1 joke: let's see what is the problem publishing the two document plus an informational doc analysing what problems 4rd-u introduces to architecture and real operation, with them all stable and having an RFC number for each? if this is fine, we all could be happy and the peace comes. lol a serious point not of the Apr-1 joke: as an IETF WG, we are obliged to provide surely high-quality document to the market. even we believe market choice, at least we have to publish what we ourselves have well understood, carefully coded and well tested. otherwise, the market would see IETF more of a group of doc-makers rather than technology-explorers. - maoke - we reject kings, presidents, and voting... - Rex redivit. vive le Roi. 2012/4/3 Marc Blanchet marc.blanc...@viagenie.ca well, let's see the other way around: what is the problem of publishing the two documents now?So that they are stable and have a RFC number. Then any implementer can implement based on the RFC. Providers can request their manufacturers to have a product which conforms to the RFC. Marc. Le 2012-04-03 à 14:56, Wojciech Dec a écrit : The irony is that this is an apples and oranges comparison, and throwing away ripe apples into some box with raw oranges looks rather unfair. Some of the of the indicators are: - MAP is not only the result of a consensus of a broad WG design team, but also that of numerous authors of the merged drafts whihc have been discussed for 1 year+. The 4rd-u technical proposals were evaluated by the design team, and have not gained support there. - MAP running code exist - 4rd-U covers a technical corner case that is self created (if not self invented/motivated) - 4rd-U does not allow v4-v6 communication (say a v4 host to a v6 sign-up portal, etc) - 4rd-U is not by any means universal. As admitted it requires the coupling with BIH, which features the same technical corner case that 4rd-u claims to solve (doh). The other aspect is that some different measure appears to be being applied in this selection *for WG adoption* vs the selection of the other drafts in softwire, which have gained WG draft status without even a shred of running code. -Woj. On 3 April 2012 18:32, Marc Blanchet marc.blanc...@viagenie.ca wrote: I don't see a way out of this thread. my suggestion: - published both as experimental - let the market decide - come back later to move one or the other standard track. Above all, I think having a stable specification (i.e. RFC) that implementers can code against and providers to require is what is needed first. Marc. Le 2012-04-03 à 11:14, Jan Zorz @ go6.si a écrit : Dear Softwires WG chairs. For how long will you leave this useless cockfight go on instead of steering the working group into a direction, that may enable us to decide on something and chose the direction? We are running in circles here and just amplificating the noise, coming from certain usual suspects. Cheers, Jan P.S: I too enjoy observing the roosters fight, but I don't think we have time for this now. :) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
2012/4/2 Rémi Després remi.desp...@free.fr Frankly, I don't understand the new objection: concern if 4rd-u possibly introduces... is IMHO an incitation to FUD, but not a technically justified issue. If you can detail what you mean, with a point an experiment might reveal, dialogue will continue. Without that, I don't understand what you mean. well, IMHO i have expressed the question and it is concrete. i gently used the wording possibly because the verification could only be done after you have the 4rd-u system built out. it would become as a ridiculous and weird record in the ietf history, had the wg made a decision of putting two as experimental, That was Alain's plan in case no consensus on a single standard would emerge. It was expressed on the ML well before the meeting. You didn't object to it then, did you? yes, i did objected (in this very thread) the chair's questions, esp. Q2, with I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. regards, maoke ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
2012/4/2 Rémi Després despres.r...@laposte.net it is flawed in both architecture and technical aspects, Which ones? please refer to discussion mails and also my real-time comments on 4rd-u presentation in the jabber room as a brief summary focusing on major points. - maoke ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Le 2012-04-02 à 11:16, Maoke a écrit : 2012/4/2 Rémi Després despres.r...@laposte.net it is flawed in both architecture and technical aspects, Which ones? please refer to discussion mails I carefully read all emails addressed to me, plus most others, but don't understand that any flaw really exists in 4rd-u-06. Sorry if I am not as shrewd as I should be in your opinion. and also my real-time comments on 4rd-u presentation in the jabber room as a brief summary focusing on major points. - maoke Do you know where I could get access to these comments? Thanks, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Le 2012-04-01 à 20:11, Satoru Matsushima a écrit : On 2012/04/02, at 3:02, Satoru Matsushima wrote: After the meeting, I've figured out that 4rd-u define new type of transport, since it adds several new semantics in its packet format with V-octet as a helper of packet format distinguisher. That kind of work is of course out of scope of Softwire working group. I therefore suggest to the 4rd-u authors that a new BOF or a working group which named like 'unified packet format for tunneling'. Best regards, --satoru In addition, April Fool is ended at JST. Thanks for understanding yourself that it could have ben taken as a fools' day joke ;-). Kind regards, RD cheers, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
2012-04-02 11:45, Maoke: ... i am still in review on the version -06, but i have found something not qualified (inconsistent semantics). Asserting there are flaws implies ability to describe them. What you have already found will be looked at fairly when described. (Just saying inconsistent semantics is unsuffcient). on the other hand, this message is more about progress rather than the technical details. if we have the BoF or new working group for the unified header mapping, i'd love to keep discussion there, with contributing my list of semantics/architecture/technical-detail questions that i found during the review. If Satoru-san and yourself want to set up a BOF on this, that remains up to you. AFAIK, it won't prevent those who want to test 4rd-U-06 to do it. Sorry if I am not as shrewd as I should be in your opinion. and also my real-time comments on 4rd-u presentation in the jabber room as a brief summary focusing on major points. - maoke Do you know where I could get access to these comments? i guess we have the jabber log. Not seen where. And there isn't AFAIK an audio record either. but it is less informative. Less informative than what? if the unified header mapping wg or BoF is started, i will contribute a comprehensive, and well-studied list of questions. A WG now without a previous BOF is of course completely unrealistic. If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections. Fair enough? Cheers, RD best, maoke ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
2012/4/2 Rémi Després despres.r...@laposte.net but it is less informative. Less informative than what? well i found that, through the ietf agenda page: http://www.ietf.org/jabber/logs/softwire/2012-03-30.html, FYI. less informative than my email discussions. if the unified header mapping wg or BoF is started, i will contribute a comprehensive, and well-studied list of questions. A WG now without a previous BOF is of course completely unrealistic. If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections. Fair enough? i din't say what if the BoF is not started but only said about what if the BoF would started. ;-) best, maoke Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections. the objections I'm aware of are: - people are uncomfortable with only a double translation solution * injection of IPv4 routes into IPv6 * transparency * hard to identify IPv4 traffic in the core * higher risk of leakage. i.e single translation / packets outside the domain (all these apply equally to MAP-T btw) - redefining the modified EUI-64 format (V-octet) and the consequences standardization wise of that - overloading information in the fragment header (please don't respond to these, FYI only. I'm on Easter holiday.) if it wasn't for my general uncomfortableness with double-translation I'd could be convinced that a single solution was possible. the status quo; with no path forward just means that we'll effectively kill A+P. I would certainly not recommend my product managers to implement either of this given the risk. is there consensus to abandon these efforts (which is basically what we do by publishing them as experimental anyway)? the alternatives we have are perfectly fine: - Shared IPv4 address over IPv4 transport - NAT444 / CGN - Shared IPv4 address over IPv6 transport - 464XLAT / DS-lite - Full IPv4 address over IPv6 transport - DS-lite with Public IPv4 address problem solved. ;-) cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
2012/4/2 Rémi Després despres.r...@laposte.net 2012-04-02 11:45, Maoke: ... i am still in review on the version -06, but i have found something not qualified (inconsistent semantics). Asserting there are flaws implies ability to describe them. What you have already found will be looked at fairly when described. (Just saying inconsistent semantics is unsuffcient). because i don't think we didn't cover that topic before. on the other hand, this message is more about progress rather than the technical details. if we have the BoF or new working group for the unified header mapping, i'd love to keep discussion there, with contributing my list of semantics/architecture/technical-detail questions that i found during the review. If Satoru-san and yourself want to set up a BOF on this, that remains up to you. AFAIK, it won't prevent those who want to test 4rd-U-06 to do it. i don't believe 4rd-u but we respect your belief and therefore we suggest you do. but what we can make is only suggestion. surely it is welcome if anyone would like to test 4rd-u. but the test is not the scope of softwire, and AFAIK, the test of 4rd-u won't prevent those who want to deploy MAP in real. regards, maoke ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
On 4/2/12 12:33 PM, Ole Trøan wrote: the status quo; with no path forward just means that we'll effectively kill A+P. I would certainly not recommend my product managers to implement either of this given the risk. is there consensus to abandon these efforts (which is basically what we do by publishing them as experimental anyway)? the alternatives we have are perfectly fine: - Shared IPv4 address over IPv4 transport - NAT444 / CGN - Shared IPv4 address over IPv6 transport - 464XLAT / DS-lite - Full IPv4 address over IPv6 transport - DS-lite with Public IPv4 address problem solved. ;-) So, if we deprecate RFC6346 and with that the whole A+P idea - is that solving anything? Really? I'm also really tempted to do that if this community can't decide what to do in a quick time manner, showing the industry the path forward. Cheers, Jan Zorz (speaking for myself only) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si wrote: On 4/2/12 12:33 PM, Ole Trøan wrote: the status quo; with no path forward just means that we'll effectively kill A+P. I would certainly not recommend my product managers to implement either of this given the risk. is there consensus to abandon these efforts (which is basically what we do by publishing them as experimental anyway)? the alternatives we have are perfectly fine: - Shared IPv4 address over IPv4 transport - NAT444 / CGN - Shared IPv4 address over IPv6 transport - 464XLAT / DS-lite - Full IPv4 address over IPv6 transport - DS-lite with Public IPv4 address problem solved. ;-) So, if we deprecate RFC6346 and with that the whole A+P idea - is that solving anything? Really? - less IPv4 exit mechanisms to implement and choose among. that must be good, no? (currently there are at least 4 mechanisms proposed in the A+P HS and mesh space) - large stateful boxes in the SP network; we know how to build them, and we can charge more for them. that's a good thing too, no? ;-) I'm also really tempted to do that if this community can't decide what to do in a quick time manner, showing the industry the path forward. yes, if there was a path forward I would also be a lot less despondent with regards to A+P. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
So, I choose MAP. the alternatives we have are perfectly fine: - Shared IPv4 address over IPv4 transport - NAT444 / CGN - Shared IPv4 address over IPv6 transport - 464XLAT / DS-lite - Full IPv4 address over IPv6 transport - DS-lite with Public IPv4 address Otherwise, I'm tempted to do the above, if the wg decide to choose 4rd-u. As an operator, the 4rd-u scares us too much since no experience of 4rd-u's new unified tunneling in our circumstance at this time. Sorry, Remi-san. I really respect you, but I can't decide to do 4rd-u in our real production network. cheers, --satoru On 2012/04/02, at 19:33, Ole Trøan wrote: If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections. the objections I'm aware of are: - people are uncomfortable with only a double translation solution * injection of IPv4 routes into IPv6 * transparency * hard to identify IPv4 traffic in the core * higher risk of leakage. i.e single translation / packets outside the domain (all these apply equally to MAP-T btw) - redefining the modified EUI-64 format (V-octet) and the consequences standardization wise of that - overloading information in the fragment header (please don't respond to these, FYI only. I'm on Easter holiday.) if it wasn't for my general uncomfortableness with double-translation I'd could be convinced that a single solution was possible. the status quo; with no path forward just means that we'll effectively kill A+P. I would certainly not recommend my product managers to implement either of this given the risk. is there consensus to abandon these efforts (which is basically what we do by publishing them as experimental anyway)? the alternatives we have are perfectly fine: - Shared IPv4 address over IPv4 transport - NAT444 / CGN - Shared IPv4 address over IPv6 transport - 464XLAT / DS-lite - Full IPv4 address over IPv6 transport - DS-lite with Public IPv4 address problem solved. ;-) cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
于 2012/4/2 19:13, Ole Trøan 写道: On Apr 2, 2012, at 12:44 , Jan Zorz @ go6.si wrote: On 4/2/12 12:33 PM, Ole Trøan wrote: the status quo; with no path forward just means that we'll effectively kill A+P. I would certainly not recommend my product managers to implement either of this given the risk. is there consensus to abandon these efforts (which is basically what we do by publishing them as experimental anyway)? the alternatives we have are perfectly fine: - Shared IPv4 address over IPv4 transport - NAT444 / CGN - Shared IPv4 address over IPv6 transport - 464XLAT / DS-lite - Full IPv4 address over IPv6 transport - DS-lite with Public IPv4 address problem solved. ;-) So, if we deprecate RFC6346 and with that the whole A+P idea - is that solving anything? Really? - less IPv4 exit mechanisms to implement and choose among. that must be good, no? (currently there are at least 4 mechanisms proposed in the A+P HS and mesh space) - large stateful boxes in the SP network; we know how to build them, and we can charge more for them. that's a good thing too, no? ;-) I'm also really tempted to do that if this community can't decide what to do in a quick time manner, showing the industry the path forward. yes, if there was a path forward I would also be a lot less despondent with regards to A+P. I choose MAP and fully believe in A+P, based on the operation experiences of the large IPv6-only network - CERNET2. Regards, xing cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Remi, (please don't respond to these, FYI only. I'm on Easter holiday.) Asking that a list of objections shouldn't be answered is to me very unusual! it was to remind you of the problems with 4rd-U. we have been many rounds on these exact arguments, and I don't see the point of rehashing the discussion. we're going to continue to have different views on the new use of u/g, the overloading of fragmentation, and that double translation can replace tunneling. I'd rather see arguments from non-authors. (this reminds me of cockfighting; somewhat entertaining for the spectators (if that's your kind of thing), one is declared a winner, but both combatants die... cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Le 2012-04-02 à 16:05, Ole Trøan a écrit : Remi, (please don't respond to these, FYI only. I'm on Easter holiday.) Asking that a list of objections shouldn't be answered is to me very unusual! it was to remind you of the problems with 4rd-U. we have been many rounds on these exact arguments, and I don't see the point of rehashing the discussion. Then, don't do it yourself. we're going to continue to have different views on the new use of u/g, the overloading of fragmentation, and that double translation can replace tunneling. I'd rather see arguments from non-authors. Then, arguments from others than MAP-team members and 4rd-U authors would be the most valuable. Sheng Jiang of Huawei writing we are going to implement 4rd-u and do operational tests is therefore a very important one (like it or not). (this reminds me of cockfighting; somewhat entertaining for the spectators (if that's your kind of thing), one is declared a winner, but both combatants die... You may fear that MAP T+E would be about to die (your judgement) but, in particular in view of the quotation above, I think 4rd-U as in a good position to remain alive. Your recent comment suggesting that hubspoke and per-customer stateful solutions might after all be sufficient seems to me a sheer lack of confidence in the solution you propose. (It looks like you become tired to work on the double-standard approach, knowing that arguments for it are too weak for success.) This doesn't justify, however, your trying to also kill the single standard solution, the most credible A+P approach we have on the table. RD cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
On Apr 2, 2012 8:17 AM, Wojciech Dec wdec.i...@gmail.com wrote: On 2 April 2012 15:46, Rémi Després despres.r...@laposte.net wrote: Le 2012-04-02 à 12:33, Ole Trøan a écrit : If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections. the objections I'm aware of are: - people are uncomfortable with only a double translation solution Are you furtively suggesting that 4rd-U has all limitations of a real double translation solution like MAP-T? That mays sound tactically smart, but isn't justified by facts. Woj Well, in terms of facts we have 1. 4rd-U does not supporting single translation mode, or if it does then is requires NAT64/BIH/Something else. (How anybody thinks that deploying 4rd-u + something else is manageable is a mystery) 2. 4rd-u is incompatible with NAT64 use or deployment 2. MAP solution (call it MAP, divi, or other variants) has proven deployment Just for my own clarification, do these proven deployments use static ipv4 address+port sharing with coordinated dhcp assignment? These are the key feature and method of map-t, and it would be good to know if and how these key features have been proven. Cb 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves problems that are non-issues to operators. 4. 4rd-u changes the basic structure/use of the v6 header, which is a change to IPv6 that needs to be vetted by 6man, etc. Creating such novel (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and use, effectively creates a new IPv6 protocol sub-class. Indeed 4rd-u deserves an experimental status track, more than anything. -Wojciech. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Cameron, - less IPv4 exit mechanisms to implement and choose among. that must be good, no? (currently there are at least 4 mechanisms proposed in the A+P HS and mesh space) - large stateful boxes in the SP network; we know how to build them, and we can charge more for them. that's a good thing too, no? ;-) Do you have data? Or are you perpetuating the myth that stateless is cheaper? where did you get the myth idea from? cost obviously depends on platform. scaling a solution based on per flow state, versus per subscriber state versus no state at all. it obviously costs money to keep this state around, increased complexity to maintain it and so on. in addition you need solutions for redundancy that typically involves hot-standbys. while a purely stateless solution can easily do load balancing between multiple active systems. of course, if we end up with all platforms have to support all mechanisms, including stateful translation, then these may end up on special service cards anyway... Last I checked stateless requires some heavy duty provisioning systems and less efficient static allocation of expensive ipv4 addresses I don't think a DHCP server was considered a heavy duty provisioning system. I'm also really tempted to do that if this community can't decide what to do in a quick time manner, showing the industry the path forward. I ietf has seldom shown the path forward. In this particular context especially so. yes, if there was a path forward I would also be a lot less despondent with regards to A+P. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Remi, (this reminds me of cockfighting; somewhat entertaining for the spectators (if that's your kind of thing), one is declared a winner, but both combatants die... You may fear that MAP T+E would be about to die (your judgement) but, in particular in view of the quotation above, I think 4rd-U as in a good position to remain alive. Your recent comment suggesting that hubspoke and per-customer stateful solutions might after all be sufficient seems to me a sheer lack of confidence in the solution you propose. (It looks like you become tired to work on the double-standard approach, knowing that arguments for it are too weak for success.) can we just cite irreconcilable differences and stop discussing this? This doesn't justify, however, your trying to also kill the single standard solution, the most credible A+P approach we have on the table. I believe that a consequence of us not being able to agree on a A+P solution will have the effect of killing A+P. the problem with MAP isn't that it has two modes of encapsulation. the problem with MAP is 4rd-U. the unification of churches rarely work. I would have been happy to concede and go with 4rd-U, but only if I thought it worked. and would have an easy way through standardization. unfortunately, the esoteric features with the V-octet and fragment header will make that not so. this is my last mail to you on this subject. Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
On 2 April 2012 19:10, Rémi Després despres.r...@laposte.net wrote: Woj Well, in terms of facts we have 1. 4rd-U does not supporting single translation mode, Not claimed to. It's good to get clarity now that previous 4rd-U claims of supporting services such as web-caching, log-on-portals, etc. are now false, and no longer claimed. MAP(-T) continues to allow these. or if it does then is requires NAT64/BIH/Something else. The 4rd-u-06 draft says: This specification only concerns IPv4 communication between IPv4-capable endpoints. For communication between IPv4-only endpoints and IPv6 only remote endpoints, the BIH specification of [RFC6535] can be used. It can coexist in a node with the CE function, including if the IPv4-only function is a NAT44 [RFC1631] The reference here to NAT64 and something else is clearly inappropriate. There already is a decent solution for IPv4-IPv4 only, without loss of info = IPinIP tunnel. Now, let something else be BIH (or whatever), this is an admission that 4rd-U is not any kind of unified solution, but rather a different collation a novel pseudo-tunneling solution with an addon in the form of BIH. Ironically since BIH is NAT64 based, all the problems 4rd-U tries to solve, remain still applicable in that BIH dimension. It is thus no complete solution. (How anybody thinks that deploying 4rd-u + something else is manageable is a mystery) In RFC6535, BIH lets the IPv4 stack to be used if only an record is received (which characterizes an an IPv6-only host). If 4rd-U is activated in the same node, IPv4 packets of the IPv4 stack are simply tunneled across IPv6, according to the 4rd-U specification. No mystery. The managing of a MAP deployment looks far much simpler, and less mysterious too, including the use of less moving parts. 2. 4rd-u is incompatible with NAT64 use or deployment Not claimed to, and no need to. That's your call, but its neither the starting point of most customers who deploy and use NAT64 today, or the direction which sees NAT64 usage. With 4rd-u, such NAT64's need to be replaced or extra operational complexity brought in by running in parallel with 4rd-u (possibly serving the same end points). 464XLAT, for example, doesn't need MAP-T (and even less MAP-E) to work with NAT64. In this respect, 464XLAT and BIH work identically. The sentence of RFC6535 that doesn' recommend using BIH for double translation, isn't a formal objection to using it if it is the only way to satisfy a need. (In this instance, the exact need that the 464XLAT draft identifies) I added a copy to Teemu Savolainen, a better specialist of BIH than I am. This is not about BIH, but rather that 4rd-U needs something else to cover the MAP space. It thus is no unifying solution at all as it claims to be 2. MAP solution (call it MAP, divi, or other variants) has proven deployment Just for my own clarification, do these proven deployments use static ipv4 address+port sharing with coordinated dhcp assignment? These are the key feature and method of map-t, and it would be good to know if and how these key features have been proven. +1 (To renew, once more, my request to know which set of MAP-T mapping rules have actually been validated.) One work in progress... http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02. More data was presented at the softwire IETF interim (lost the link for now) Cb 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves problems that are non-issues to operators. According to this statement, co-authors of 4rd-U coming from network operators don't understand their problems as well as Wojciech does. I find this doubtful. Rather, according to this statement co-authors of MAP, including numerous operators, don't care about the problems 4rd-U solves. 4. 4rd-u changes the basic structure/use of the v6 header, which is a change to IPv6 that needs to be vetted by 6man, etc. Creating such novel (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and use, effectively creates a new IPv6 protocol sub-class. In discussions in Paris with Dave Thaler, Dan Wing, Stuart Cheshire, Lorenzo Colitti, I didn't get any indication that using the unused u-g combination, if useful, would be a big issue. Making a backward-compatible extension of RFC2373 shouldn't in my understanding be too difficult (if confirmed to be useful for 4rd-U). Not sure how the above constitute the v6man WG, or what the personal opinions of these individuals have to do with the fact that ultimately you're changing core IPv6 semantics, incl those of the fragmentation header, which is not within softwire charter. Indeed 4rd-u deserves an experimental status track, more than anything. Well, with no WG consensus achieved on any 4via6 solution working on mesh topologies, that's probably the best that can be done so far. Still, it is a step forward. For 4rd-U experimental would
Re: [Softwires] Path to move forward with 4rd…
+1. 4rd-u is tweaking IPv6 header such as fragment header, hop limit, V-octet, etc to create a unified transport instead of the encapsulation (MAP-E) and the translation (MAP-T). MAP-E and MAP-T do not intend to create a new transport. In fact, MAP-E utilizes rfc2473 and MAP-T utilizes rfc6145. We implemented the mapping rule with the standard transport. So, from my point of view, since 4rd-u focus on defining a new transport, the discussion point of 4rd is a little bit different from MAP-E/MAP-T. Also, the following idea is a good way to get the consensus widely to define the new transport instead of the existing tunneling/translation. Thanks, Tetsuya Murakami On 2012/04/01, at 11:02, Satoru Matsushima wrote: After the meeting, I've figured out that 4rd-u define new type of transport, since it adds several new semantics in its packet format with V-octet as a helper of packet format distinguisher. That kind of work is of course out of scope of Softwire working group. I therefore suggest to the 4rd-u authors that a new BOF or a working group which named like 'unified packet format for tunneling'. Best regards, --satoru On 2012/04/01, at 16:38, Jan Zorz @ go6.si wrote: On 3/31/12 4:56 PM, Rémi Després wrote: Alain, You had initially announced that either one specification would be chosen for standard track (among T, E, and U), or specifications would all become WG drafts on the experimental track ((*) below). In Paris: (a)The MAP proposal became presented as an inseparable T+E package. (b) The WG couldn't make a consensus choice between T+E or U. Now publishing both MAP-T+E and 4rd-U as WG documents on the experimental track, is therefore consistent with what was announced (and was also asked for by several at the end of the meeting). As you explained, this won't prevent from selecting one for standard track later on, based on better market experience. Not sure that was the outcome - as I understood Alain, we'll make a decision here on mailinglist in a very short period of time. Cheers, Jan ___ Softwires mailing list Softwires@ietf.orgmailto:Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.orgmailto:Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
2012/4/3 Satoru Matsushima satoru.matsush...@gmail.com: FYI, choosing MAP doesn't mean that committing to a 'single'. But choosing 4rd-u means that committing to a 'single'. There're just transport variants, which are encapsulation, translation and new one we've never seen before. Proponents of the new one claim to unify transport only to the new one, which means that eliminating both encapsulation and translation variants of MAP because they say two choice of transport type would make confusion for operators. The new one is transparent than translation, but less than encapsulation. I couldn't decide transport type to be unified with the new one. No evidence, no expertise, no experience for that. Do we need them to be sure in spite of we already have existing mature transport variants? +1. With all due respect, I cannot image making a standard that has neither rough consensus nor running code. Regards, Wentao cheers, --satoru On 2012/04/03, at 2:47, Tom Taylor wrote: People on the list might get the impression that Rene is single-handedly holding up WG progress. I have not been involved in this work, but did observe at the meeting a show of hands for 4rd-U at least as numerous as that for MAP. For whatever reason, the WG at large does not seem prepared to commit to a single solution. On 02/04/2012 11:17 AM, Wojciech Dec wrote: On 2 April 2012 15:46, Rémi Desprésdespres.r...@laposte.net wrote: Le 2012-04-02 à 12:33, Ole Trøan a écrit : If this is to say that until a BOF is started, you will keep your objection(s) unknown, I continue to take it as a lack of identified objections. the objections I'm aware of are: - people are uncomfortable with only a double translation solution Are you furtively suggesting that 4rd-U has all limitations of a real double translation solution like MAP-T? That mays sound tactically smart, but isn't justified by facts. Woj Well, in terms of facts we have 1. 4rd-U does not supporting single translation mode, or if it does then is requires NAT64/BIH/Something else. (How anybody thinks that deploying 4rd-u + something else is manageable is a mystery) 2. 4rd-u is incompatible with NAT64 use or deployment 2. MAP solution (call it MAP, divi, or other variants) has proven deployment 3. Any operator who runs NAT64 today is a proof point that 4rd-U solves problems that are non-issues to operators. 4. 4rd-u changes the basic structure/use of the v6 header, which is a change to IPv6 that needs to be vetted by 6man, etc. Creating such novel (bogus?) IPv6 packets, that no regular IPv6 host today will recognize and use, effectively creates a new IPv6 protocol sub-class. Indeed 4rd-u deserves an experimental status track, more than anything. -Wojciech. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- Wentao Shang Master Candidate and Research Assistant at CERNET Center NGN Lab, EE Department, Tsinghua University ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
+1. As a follower of MAP team, I participated much in developing and deploying double-translation in CERNET. As far as I am concerned, in the translation scenario, 4rd-U only solved some corner cases but missed some other cases simultaneously. As an example, I suppose one fragmentation case as following: (IPv4 customer network)--CE---(IPv6 access network)--BR(Core Translator)--(IPv4 network)---IPv4 host The minumum MTU of IPv6 access network is 1400, and the minimum MTU of IPv4 network on the right side is 800. Now an IPv4 host on the left side sends a packet with length set to 1200 and MTU set to 1, to the IPv4 host in the right side. The packet could traverse the IPv6 access network, but will be blocked in the IPv4 network. In this case, BR(Core Translator) must set DF to 0 when translating from IPv6 back to IPv4, instead of preserving the original IPv4 DF bit. In fact, according to RFC6145, if BR(Core Translator) receives an ICMP Packet Too Big packet whose indicating MTU is less than 1280 bytes, it will change it to 1280. So if the BR preserve the DF bit, the sender will always believe the path MTU is 1280, which will certainly lead to a black hole. This is only one deployment problem, and we don't know how many issues will be encountered in the future. So my point is that 4rd-U still needs examination in the actual deployment, and it's a bit early to propose it as an Informational/Standards Track Document. The mail sent yesterday seemed to encounter some problems. So if you see this mail twice, sorry for that. regards, Guoliang 2012/3/26 Maoke fib...@gmail.com hi Remi, let me remove those you have marked as end. they are fine to me too. only one point: no implementation nor operation trouble != it is safe to say it an architectural building block of tunnel. if we both say 4rd-u is an alternative for translation, it would be much clear. (i don't think it is a tunnel variant at all, due to not providing virtual links; while you insist it not a translation at all). 2012/3/25 Rémi Després despres.r...@laposte.net c) MAP-A+P says Each MAP node in the domain has the same set of rules while MAP-T says if a CE knows only a subset of the mapping rules ... first of all, they are not conflicting logically. ??? second, if you mean one doc is superior than multiple with better consistency in writing, i could agree. This is not the point. Separate documents can be consistent, but they aren't on this point. One of the two assertions must be changed. Remaining question: which one? well. this is why i said they are not conflict in logic. as a definition of the MAP rule, right, each MAP node in the domain SHOULD have the same set of rules. however, in practice of operation, it is possible that this MAY not strictly achieved due to some information losses (which is often happens in the Internet environment), MAP-T defines the CE working as it were in hubspokes mode for an unknown destination CE. I am not aware that a CE might receive some of the MAP DHCPv6 parameters but not all due to lost packets. Clarification on this will be welcome. my understanding is: DHCPv6 is not running on a reliable protocol, while MAP DHCPv6 does not yet determine if all FMR would be carried in a single or multiple DHCPv6 messages provided they are many. (if the MAP-dhcp has done with this, please teach me, thanks!) if you assume Internet is always reliable for everything, we must change our discussion on a lot of issues. if you mean the single mapping rule in IVI case, the answer is NONE, surely. IVI uses RFC6052 address format rather than the MAP, without the business of MAP. OK (In this respect at least, IVI significantly differs from a running version of MAP-T). well, here i don't know how significantly you mean. IVI/dIVI/MAP-T(or dIVI-pd) are same in header processing but different in address mapping and operation. the context of IVI above mentioned the original IVI/dIVI that applies RFC6052 mapping, while MAP-T (dIVI-pd) applies MAP mapping rules. if you mean using the MAP for the single translation as we did in IVI (though actually we have IVI working for both single and double translations simultaneously), MAP-T Sec 8.3 has answered your question. Saying that there is no mapping rule in IVI is sufficient an answer. then there is no more not reaching collective understanding for this point. End of this topic for me. None? If one, is it a DMR or a BMR? If two, what are they? ... OK, could have been clearer. Yet, I think you understand that with U, one has SIMULTANEOUSLY, transparency to DF=MF=1 and applicability of IPv6-only middle boxes that look at TCP ports. ok. then may i conclude, for the major part of U, that 1) U, as a stated enhancement for double translation, gain the transparency for DF=MF=1 (the 10^-6 minor cases, commonly thought abnormal); 1) A statistic at a given time, and in a given
Re: [Softwires] Path to move forward with 4rd…
After the meeting, I've figured out that 4rd-u define new type of transport, since it adds several new semantics in its packet format with V-octet as a helper of packet format distinguisher. That kind of work is of course out of scope of Softwire working group. I therefore suggest to the 4rd-u authors that a new BOF or a working group which named like 'unified packet format for tunneling'. Best regards, --satoru On 2012/04/01, at 16:38, Jan Zorz @ go6.si wrote: On 3/31/12 4:56 PM, Rémi Després wrote: Alain, You had initially announced that either one specification would be chosen for standard track (among T, E, and U), or specifications would all become WG drafts on the experimental track ((*) below). In Paris: (a)The MAP proposal became presented as an inseparable T+E package. (b) The WG couldn't make a consensus choice between T+E or U. Now publishing both MAP-T+E and 4rd-U as WG documents on the experimental track, is therefore consistent with what was announced (and was also asked for by several at the end of the meeting). As you explained, this won't prevent from selecting one for standard track later on, based on better market experience. Not sure that was the outcome - as I understood Alain, we'll make a decision here on mailinglist in a very short period of time. Cheers, Jan ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
On 2012/04/02, at 3:02, Satoru Matsushima wrote: After the meeting, I've figured out that 4rd-u define new type of transport, since it adds several new semantics in its packet format with V-octet as a helper of packet format distinguisher. That kind of work is of course out of scope of Softwire working group. I therefore suggest to the 4rd-u authors that a new BOF or a working group which named like 'unified packet format for tunneling'. Best regards, --satoru In addition, April Fool is ended at JST. cheers, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
hi all, i listented to the softwire wg live on March 30 online and recorded my comments in the jabber room. as the person who was mentioned by the presenter not less than twice, i have to point out that it is unfair that the presenter mentioned me with only acknowledgment to my effort but my point of views. my summerized comment on 4rd-u is: it is flawed in both architecture and technical aspects, and now still uncertain in several details. it would become as a ridiculous and weird record in the ietf history, had the wg made a decision of putting two as experimental, one is well-understood, well-coded and well-practised while the other is misleading the understanding on the Internet architecture, not yet coded, not yet tested by any operators. our company, as an ISP and as a provider doing also application services, including those over mobile platforms, is waiting for the MAP standard desirably. we have no interest in introducing the 4rd-u elements into our platforms. personally i won't code a stuff with obvious architectural flaws but, if i were believing in the 4rd-u, i would do the code and operational test with serious self-checking as MAP-T and MAP-E teams already have done, before talking on any doc-track issue with the community. this is the way of being responsible. thanks, maoke ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd
On 3/26/12 8:54 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: As a member of the MAT DT, I am naturally biased in favor of what Xing, Maoke and Ole said. I also think that the chair's questions are not adequate. I don't think that the questions should be which of document the wg choose, make documents to be unified or not. I think that it should be what 'solution space' has been clarified beyond the MAP suite. Let me try to figure these out. 1. Reduce the number of parameters for MAP configuration The MAP currently needs bunch of parameters such as 'Rule IPv6 prefix', 'Rule IPv4 prefix' and 'EA-bits length' for each of BMR, FMR and DMR. It would be more convenient when one or some of them can be reduced or omitted. [Reinaldo] Good point. Irrespective of MAP/4rd-U it would be good to have a simplified model for ease of deployment. Usually when implementing such standards things get very complicated for both development and ISP due to - Consistency checks across all parameters - Consistency checks within a parameter - Debugging, operational commands, testing, - Interop testing, naming conventions - Network planning and staff training. Thanks, Reinaldo 2. Trying to keep more header transparency When operators think that it would be nice if the MAP-T can keep header transparency, which includes checksum neutrality, beyond the current header translation specification, the wg should be work on that, or ask other wg to do that. 3. Truly 'Unified' operation Since encapsulation and translation are completely separated operation in operator's network (I mean 'polarized' on Jan's comment) but the implementation of both is possible into one box. Beyond just 'unified document', does operators think it would be more attractive with 'unified' operation for which both encapsulation and translation co-exist in same time, on same network, for same service. Above three are my thought of what 4rd-u proposed to the wg. Discussions and more suggestions are welcome. Best regards, --satoru On 2012/03/23, at 10:46, Ole Trøan wrote: Alain, et al, we have been at an impasse, so thank you very much for proposing a path forward. After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. I do agree with that. the Venn diagram for the three solutions would look awfully similar to a single circle. ;-) there are some use cases though, that can only be fulfilled with one mode of transport versus the other. I left the interim meeting in Beijing having been convinced that there are use cases requiring both encapsulation and requiring translation. if we for a moment accept that, I would suggest that we treat MAP as one single solution. it will have two options/flavours of transport. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will
Re: [Softwires] Path to move forward with 4rd…
Dear WG Co-Chairs, I looked at your arguments in this email here and Softwaire WG agenda you proposed on Wed and Fri, I am kind of confusing, hope you can clarify: There are several drafts discussed in Wed agenda which basically solved same problem as we discussed in Friday and they are all variant solution of encapsulations in stateless mode for 464 user case. how do you deal with all those proposals, should we put all of those along with MAP, 4rd-u as part of selecting decision from WG on Friday all together ? It will be unfair to treat those differently on Wed vs those on Friday ! If we are facing the problem for too many standard proposals from softwire WG, they occured in situations we had too many variant of encapsulations, so far, from what I can see, MAP represents the best efforts from WG to unify encapsulation and translation solutions from softwire. I agreed with many in this mailing-list said before, respect the collaborating efforts in past 6 month and select MAP as standard track,rather other individual variant such as 4rd-U, stateless DS-lite, etc. let us be more productive through collaboration than count-productive through more individual drafts. Best Regards, Kevin Yin On Mon, Mar 19, 2012 at 6:38 PM, Alain Durand adur...@juniper.net wrote: Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E T as Experimental. In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. Alain Yong, wg co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Maoke, I like your analog of horse, donkey, and donkorse! and fully agree with you. People know what kind of situation horse and donkey can help to solve the problem. People do not want unknown donkorse because it creates more problem rather than solving specific problem. Kevin Yin well, this is what i mean the uncertainty of 4rd-U in the architecture to the common understanding. as a analogy, one of Mr. E and Mr. T said, i give you a horse, while the other said i give you a donkey. then people well understand when they need acwhen they need a donkey. now Mr. U said wow, i give you a fantastic donkorse!. there would be 2 possible results, not certain right now: A. donkorse is just another sort of donkey, somehow good but somehow flawed. B. donkorse is just donkorse, and people, taking a long time to understand it, and finally find it either a flawed or a quite good hybrid, like mule, useful in some cases. no matter if the future result is A or B, now Mr. O understand what he needs for his business is either a horse and a donkey, with their well-known characteristics. Mr. MAP provides a wheeled car as the common instrument, while Mr. O needs a standard suite for the wheeled-car, the horse-driving and donkey-driving methods and the way of feeding the horse and donkey. this is the task of our wg, right now. Mr. U said you must have another type of wheel and drive it with my donkorse --- and when Mr. O asked him, what your donkorse is, he answered: you will know it is donkorse, having both the advantages of the horse and the advantages of the donkey. however, Mr. O doubts donkorse hasn't also the disadvantages of horse and the disadvantages of donkey and some flaws not yet documented. why not? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
As a member of the MAT DT, I am naturally biased in favor of what Xing, Maoke and Ole said. I also think that the chair's questions are not adequate. I don't think that the questions should be which of document the wg choose, make documents to be unified or not. I think that it should be what 'solution space' has been clarified beyond the MAP suite. Let me try to figure these out. 1. Reduce the number of parameters for MAP configuration The MAP currently needs bunch of parameters such as 'Rule IPv6 prefix', 'Rule IPv4 prefix' and 'EA-bits length' for each of BMR, FMR and DMR. It would be more convenient when one or some of them can be reduced or omitted. 2. Trying to keep more header transparency When operators think that it would be nice if the MAP-T can keep header transparency, which includes checksum neutrality, beyond the current header translation specification, the wg should be work on that, or ask other wg to do that. 3. Truly 'Unified' operation Since encapsulation and translation are completely separated operation in operator's network (I mean 'polarized' on Jan's comment) but the implementation of both is possible into one box. Beyond just 'unified document', does operators think it would be more attractive with 'unified' operation for which both encapsulation and translation co-exist in same time, on same network, for same service. Above three are my thought of what 4rd-u proposed to the wg. Discussions and more suggestions are welcome. Best regards, --satoru On 2012/03/23, at 10:46, Ole Trøan wrote: Alain, et al, we have been at an impasse, so thank you very much for proposing a path forward. After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. I do agree with that. the Venn diagram for the three solutions would look awfully similar to a single circle. ;-) there are some use cases though, that can only be fulfilled with one mode of transport versus the other. I left the interim meeting in Beijing having been convinced that there are use cases requiring both encapsulation and requiring translation. if we for a moment accept that, I would suggest that we treat MAP as one single solution. it will have two options/flavours of transport. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E T as Experimental. with the above proposal, we can drop question 3. In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. can ask the chairs to take a hum of how many would want t-shirts for the meeting with: Just pick one for F's sake and stop arguing. ;-) cheers, Ole
Re: [Softwires] Path to move forward with 4rd…
Le 2012-03-25 à 05:34, Maoke a écrit : dear Remi, 2012/3/24 Rémi Després despres.r...@laposte.net Le 2012-03-22 à 15:40, Maoke a écrit : dear Alain, Yong, Ralph and all, in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions a little confused me: if we need to go back to the stage before the works of the MAP design team? The MAP series have reached running codes and the collective understanding of the community. Here are some issues among those remaining before reaching collective understanding: some issues remaining not yet reaching collective undertanding is not a reason of making things over. the collective understanding has been reached for the major part of the 1) MAP address format and the corresponding algorithms 2) encapsulation and translation modes being supported by MAP format and the existing header processing standards 3) DHCP extensions as a way of distributing rules. the above big picture are what i call collective understanding. the correct way is: making these already gained approaches as bases, continuing discussion or even dabate on the details. i don't think it is a correct way of action to disrespect a team's work. 4rd-u's problem is even its big picture is still fuzzy. Not more fuzzy than MAP (actually less fuzzy IMHO). Debate on details is possible for U as wall as for T+E. a) T operation in hubspoke (hasn't been so far answered in an understandable way). i doubt i understand what you mean. may you please specify the question in details? Is a DHCPv6 parameter needed, yes or no? b) IDs from shared-address CEs. T currently has so far no solution while both U and E include one. what do you mean with the IDs? or do you mean interface IDs? i don't see IDs from shared-address CEs in U too. please teach! Sec 4.5.3. is Packet Identifications from Shared-Address CEs. Did you read the complete draft? c) MAP-A+P says Each MAP node in the domain has the same set of rules while MAP-T says if a CE knows only a subset of the mapping rules ... first of all, they are not conflicting logically. ??? second, if you mean one doc is superior than multiple with better consistency in writing, i could agree. This is not the point. Separate documents can be consistent, but they aren't on this point. One of the two assertions must be changed. Remaining question: which one? but it doesn't mean one doc is definitely reflecting collective understanding better than multiple. d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp. single mapping rule for a domain != single mapping rule for the IPv4 world. ??? the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and BMR being exclusive is a problem. How many MAP mapping rules do you see for the equivalent of the IVI use case in a MAP domain? None? If one, is it a DMR or a BMR? If two, what are they? The fact that no-one involved in the MAP design raised any of these issues is AFAIK sign that MAP has NOT reached collective understanding of the community. (Note that, concerning stateless v4/v6 solutions, I think I should be considered part of this community. Right? ). well, collective understanding was mentioned by Sally Floyd to the community of Internet researchers, and i borrowed her term. but i understand: no matter it is research or engineering, collective understanding is the understanding on the problems and the architecture rather than the detailed technical solutions. the MAP architecture has been reflected in the works of the draft suite. on the other hand, the community is not the softwires wg but the whole Internet engineering circle. Maoke, clarifications on these points will be welcome. From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment. Note: This excludes ISPs that would like to offer full IPv4 transparency
Re: [Softwires] Path to move forward with 4rd…
2012/3/25 Rémi Després despres.r...@laposte.net some issues remaining not yet reaching collective undertanding is not a reason of making things over. the collective understanding has been reached for the major part of the 1) MAP address format and the corresponding algorithms 2) encapsulation and translation modes being supported by MAP format and the existing header processing standards 3) DHCP extensions as a way of distributing rules. the above big picture are what i call collective understanding. the correct way is: making these already gained approaches as bases, continuing discussion or even dabate on the details. i don't think it is a correct way of action to disrespect a team's work. 4rd-u's problem is even its big picture is still fuzzy. Not more fuzzy than MAP (actually less fuzzy IMHO). Debate on details is possible for U as wall as for T+E. you may argue that MAP is much more fuzzy. but as i said, nobody knows exactly what the 4rd-u tunnel is. you said it is just a reversible header mapping that is not tunnel nor translation path section. then what does the reversible header mapping provides to the architecture of transition? you never clearly state this. a) T operation in hubspoke (hasn't been so far answered in an understandable way). i doubt i understand what you mean. may you please specify the question in details? Is a DHCPv6 parameter needed, yes or no? i am not sure i know about the details of what you mean. do you mean the feature of R-2.C? if so, i happen to have following questions: 1) why hubspoke topology should be announced to the CE? (IMHO, if a CE is informed with the FMR involving other CEs, it works as mesh; if only BMR and DMR is informed, surely it is hubspoke. i think this has been clarified in MAP Section 5.) 2) to this parameter issue, what is the difference between T and E? look forward to your further clarification/discussions! if you mean not the hubspoke mode indicator, please specify your question further. b) IDs from shared-address CEs. T currently has so far no solution while both U and E include one. what do you mean with the IDs? or do you mean interface IDs? i don't see IDs from shared-address CEs in U too. please teach! Sec 4.5.3. is Packet Identifications from Shared-Address CEs. Did you read the complete draft? execuse me. it is my fault. i read it but i didn't realize you mean the datagram identification here. it is a good point, and not only this but also the issue of how BR deals with fragments of the same datagram where only the first fragment has the port number. for this point, i think MAP-T also needs to consider this problem described in the MAP-E Section 7, last 2 paragraphs. thanks a lot! c) MAP-A+P says Each MAP node in the domain has the same set of rules while MAP-T says if a CE knows only a subset of the mapping rules ... first of all, they are not conflicting logically. ??? second, if you mean one doc is superior than multiple with better consistency in writing, i could agree. This is not the point. Separate documents can be consistent, but they aren't on this point. One of the two assertions must be changed. Remaining question: which one? well. this is why i said they are not conflict in logic. as a definition of the MAP rule, right, each MAP node in the domain SHOULD have the same set of rules. however, in practice of operation, it is possible that this MAY not strictly achieved due to some information losses (which is often happens in the Internet environment), MAP-T defines the CE working as it were in hubspokes mode for an unknown destination CE. the text of Sec 8.2 of MAP-T and that of Sec 8.2 of MAP-E are clear enough to me. no one among MAP/MAP-T/MAP-E here needs to be changed. (i may partly agree with you that one could be further clarified). but it doesn't mean one doc is definitely reflecting collective understanding better than multiple. d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp. single mapping rule for a domain != single mapping rule for the IPv4 world. ??? the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and BMR being exclusive is a problem. How many MAP mapping rules do you see for the equivalent of the IVI use case in a MAP domain? None? if you mean the single mapping rule in IVI case, the answer is NONE, surely. IVI uses RFC6052 address format rather than the MAP, without the business of MAP. if you mean using the MAP for the single translation as we did in IVI (though actually we have IVI working for both single and double translations simultaneously), MAP-T Sec 8.3 has answered your question. If one, is it a DMR or a BMR? If two, what are they? ... Note: This excludes ISPs that
Re: [Softwires] Path to move forward with 4rd…
Maoke, (Retransmission after deleting unnecessary old text. Message was too big for the mailing list) 2012-03-25 14:08, Maoke : 2012/3/25 Rémi Després despres.r...@laposte.net ... you may argue that MAP is much more fuzzy. but as i said, nobody knows exactly what the 4rd-u tunnel is. you said it is just a reversible header mapping that is not tunnel I rather say that reversible header mapping implements a tunnel variant. nor translation path section. then what does the reversible header mapping provides to the architecture of transition? you never clearly state this. The draft is AFAIK not ambiguous. I tried to answer all your questions on this point I barely understand (neither an implementation nor an operation issue) End of this point for me, if there is nothing significantly new. a) T operation in hubspoke (hasn't been so far answered in an understandable way). i doubt i understand what you mean. may you please specify the question in details? Is a DHCPv6 parameter needed, yes or no? i am not sure i know about the details of what you mean. Today, there is no DHCPv6 parameter to require HS, right? My question is then: is it sufficient to have none, or is it needed to add a new parameter. Looking at more details would be premature for me until you have answered this question. do you mean the feature of R-2.C? if so, i happen to have following questions: 1) why hubspoke topology should be announced to the CE? (IMHO, if a CE is informed with the FMR involving other CEs, it works as mesh; if only BMR and DMR is informed, surely it is hubspoke. i think this has been clarified in MAP Section 5.) 2) to this parameter issue, what is the difference between T and E? None AFAIK. look forward to your further clarification/discussions! if you mean not the hubspoke mode indicator, please specify your question further. b) IDs from shared-address CEs. T currently has so far no solution while both U and E include one. what do you mean with the IDs? or do you mean interface IDs? i don't see IDs from shared-address CEs in U too. please teach! Sec 4.5.3. is Packet Identifications from Shared-Address CEs. Did you read the complete draft? execuse me. it is my fault. i read it but i didn't realize you mean the datagram identification here. it is a good point, and not only this but also the issue of how BR deals with fragments of the same datagram where only the first fragment has the port number. for this point, i think MAP-T also needs to consider this problem described in the MAP-E Section 7, last 2 paragraphs. thanks a lot! (*) End of this subject. c) MAP-A+P says Each MAP node in the domain has the same set of rules while MAP-T says if a CE knows only a subset of the mapping rules ... first of all, they are not conflicting logically. ??? second, if you mean one doc is superior than multiple with better consistency in writing, i could agree. This is not the point. Separate documents can be consistent, but they aren't on this point. One of the two assertions must be changed. Remaining question: which one? well. this is why i said they are not conflict in logic. as a definition of the MAP rule, right, each MAP node in the domain SHOULD have the same set of rules. however, in practice of operation, it is possible that this MAY not strictly achieved due to some information losses (which is often happens in the Internet environment), MAP-T defines the CE working as it were in hubspokes mode for an unknown destination CE. I am not aware that a CE might receive some of the MAP DHCPv6 parameters but not all due to lost packets. Clarification on this will be welcome. the text of Sec 8.2 of MAP-T and that of Sec 8.2 of MAP-E are clear enough to me. no one among MAP/MAP-T/MAP-E here needs to be changed. (i may partly agree with you that one could be further clarified). ... How many MAP mapping rules do you see for the equivalent of the IVI use case in a MAP domain? if you mean the single mapping rule in IVI case, the answer is NONE, surely. IVI uses RFC6052 address format rather than the MAP, without the business of MAP. OK (In this respect at least, IVI significantly differs from a running version of MAP-T). if you mean using the MAP for the single translation as we did in IVI (though actually we have IVI working for both single and double translations simultaneously), MAP-T Sec 8.3 has answered your question. Saying that there is no mapping rule in IVI is sufficient an answer. ... ... with U, one has SIMULTANEOUSLY, transparency to DF=MF=1 and applicability of IPv6-only middle boxes that look at TCP ports. ok. then may i conclude, for the major part of U, that 1) U, as a stated enhancement for double translation, gain the transparency for DF=MF=1 (the 10^-6 minor cases, commonly thought abnormal); 1) A statistic at a given time, and
Re: [Softwires] Path to move forward with 4rd?
-邮件原件- 发件人: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] 代表 softwires-requ...@ietf.org 发送时间: 2012年3月25日 1:47 收件人: softwires@ietf.org 主题: Softwires Digest, Vol 76, Issue 94 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/softwires Click the 'Unsubscribe or edit options' button, log in, and set Get MIME or Plain Text Digests? to MIME. You can set this option globally for all the list digests you receive at this point. Send Softwires mailing list submissions to softwires@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/softwires or, via email, send a message with subject or body 'help' to softwires-requ...@ietf.org You can reach the person managing the list at softwires-ow...@ietf.org When replying, please edit your Subject line so it is more specific than Re: Contents of Softwires digest... Today's Topics: 1. Re: Path to move forward with 4rd? (Jan Zorz @ go6.si) 2. Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris (Alistair Woodman) 3. Re: Path to move forward with 4rd? (R?mi Despr?s) 4. Re: 4rd-u tunnels and stateful NAT64s (R?mi Despr?s) -- Message: 1 Date: Sat, 24 Mar 2012 17:29:43 +0100 From: Jan Zorz @ go6.si j...@go6.si To: softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd? Message-ID: 4f6df677.8080...@go6.si Content-Type: text/plain; charset=windows-1252; format=flowed On 3/23/12 4:04 AM, Guanghui Yu wrote: Hi Yiu 4rd-u changes the IPv6 header architecture (redefine fragmentation header extension) and IPv6 address architecture (different meaning of u-bit when g-bit=1). These are the fundamental changes. If 4rd-u becomes the standard, then there will be new defined ?IPv6? packets on the Internet, which are not compatible with existing IPv6 packets and no existing devices can understand those packets. Exactly. +1 Cheers, Jan Zorz +1 Justin Chen -- Message: 2 Date: Sat, 24 Mar 2012 09:37:53 -0700 From: Alistair Woodman awood...@isc.org To: softwires@ietf.org Cc: fdup...@isc.org Subject: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25thfrom 15h30 to 17h00 room #201 at IETF in Paris Message-ID: 356701cd09dc$7872b190$695814b0$@org Content-Type: text/plain; charset=us-ascii All, you are cordially invited. Francis Dupont, Paul Selkirk and Alain Durant are hosting a live demo of draft-penno-softwire-sdnat-02. The following will be shown: 1) Stateless DS-Lite 2) Stateless CPE B4 NAT 3) Anycast Failover 4) DHCPv4 proxy over v6 5) NAT Port range re-allocation via ICMP method. When: Sunday the 25th from 15h30 to 17h00. Where: Room #201 (Front left of Hall Maillot when facing Porte Maillot), IETF 83, Paris -- next part -- An HTML attachment was scrubbed... URL: http://www.ietf.org/mail-archive/web/softwires/attachments/20120324/fa23069 f/attachment.htm -- Message: 3 Date: Sat, 24 Mar 2012 17:58:25 +0100 From: R?mi Despr?s despres.r...@laposte.net To: Jan Zorz @ go6.si j...@go6.si Cc: softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd? Message-ID: 2c41a97b-38a7-4bed-9ca5-96e39fad4...@laposte.net Content-Type: text/plain; charset=windows-1252 Hi, Jan, Please see my answer to Guanghui. Thanks, RD Le 2012-03-24 ? 17:29, Jan Zorz @ go6.si a ?crit : On 3/23/12 4:04 AM, Guanghui Yu wrote: Hi Yiu 4rd-u changes the IPv6 header architecture (redefine fragmentation header extension) and IPv6 address architecture (different meaning of u-bit when g-bit=1). These are the fundamental changes. If 4rd-u becomes the standard, then there will be new defined ?IPv6? packets on the Internet, which are not compatible with existing IPv6 packets and no existing devices can understand those packets. Exactly. +1 Cheers, Jan Zorz ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- Message: 4 Date: Fri, 23 Mar 2012 18:46:52 +0100 From: R?mi Despr?s despres.r...@laposte.net To: Maoke fib...@gmail.com Cc: Softwires WG softwires@ietf.org Subject: Re: [Softwires] 4rd-u tunnels and stateful NAT64s Message-ID: 51ba7f56-7b83-4ef5-9223-7b21ab37b...@laposte.net Content-Type: text/plain; charset=iso-8859-1 Le 2012-03-19 ? 11:44, Maoke a ?crit : 2012/3/19 R?mi Despr?s despres.r...@laposte.net Le 2012-03-19 ? 10:21, Maoke a ?crit : 2012/3/19 R?mi Despr?s despres.r...@laposte.net Le 2012-03-19 ? 09:16, Maoke a ?crit
Re: [Softwires] Path to move forward with 4rd…
dear Remi, 2012/3/24 Rémi Després despres.r...@laposte.net Le 2012-03-22 à 15:40, Maoke a écrit : dear Alain, Yong, Ralph and all, in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions a little confused me: if we need to go back to the stage before the works of the MAP design team? The MAP series have reached running codes and the collective understanding of the community. Here are some issues among those remaining before reaching collective understanding: some issues remaining not yet reaching collective undertanding is not a reason of making things over. the collective understanding has been reached for the major part of the 1) MAP address format and the corresponding algorithms 2) encapsulation and translation modes being supported by MAP format and the existing header processing standards 3) DHCP extensions as a way of distributing rules. the above big picture are what i call collective understanding. the correct way is: making these already gained approaches as bases, continuing discussion or even dabate on the details. i don't think it is a correct way of action to disrespect a team's work. 4rd-u's problem is even its big picture is still fuzzy. a) T operation in hubspoke (hasn't been so far answered in an understandable way). i doubt i understand what you mean. may you please specify the question in details? b) IDs from shared-address CEs. T currently has so far no solution while both U and E include one. what do you mean with the IDs? or do you mean interface IDs? i don't see IDs from shared-address CEs in U too. please teach! c) MAP-A+P says Each MAP node in the domain has the same set of rules while MAP-T says if a CE knows only a subset of the mapping rules ... first of all, they are not conflicting logically. second, if you mean one doc is superior than multiple with better consistency in writing, i could agree. but it doesn't mean one doc is definitely reflecting collective understanding better than multiple. d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp. single mapping rule for a domain != single mapping rule for the IPv4 world. the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and BMR being exclusive is a problem. The fact that no-one involved in the MAP design raised any of these issues is AFAIK sign that MAP has NOT reached collective understanding of the community. (Note that, concerning stateless v4/v6 solutions, I think I should be considered part of this community. Right? ). well, collective understanding was mentioned by Sally Floyd to the community of Internet researchers, and i borrowed her term. but i understand: no matter it is research or engineering, collective understanding is the understanding on the problems and the architecture rather than the detailed technical solutions. the MAP architecture has been reflected in the works of the draft suite. on the other hand, the community is not the softwires wg but the whole Internet engineering circle. Maoke, clarifications on these points will be welcome. From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment. Note: This excludes ISPs that would like to offer full IPv4 transparency with some IPv6-only middles boxes. Right? i cannot follow your full IPv4 transparency with some IPv6-only middle boxes. what does the transparency mean for the middle boxes? i understand, when we talk about the Internet transparency, we refer to the end-to-end transparency. please specify your question concretely. The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community. second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing
Re: [Softwires] Path to move forward with 4rd
4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd
Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Alain, et al, we have been at an impasse, so thank you very much for proposing a path forward. After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. I do agree with that. the Venn diagram for the three solutions would look awfully similar to a single circle. ;-) there are some use cases though, that can only be fulfilled with one mode of transport versus the other. I left the interim meeting in Beijing having been convinced that there are use cases requiring both encapsulation and requiring translation. if we for a moment accept that, I would suggest that we treat MAP as one single solution. it will have two options/flavours of transport. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E T as Experimental. with the above proposal, we can drop question 3. In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. can ask the chairs to take a hum of how many would want t-shirts for the meeting with: Just pick one for F's sake and stop arguing. ;-) cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd
Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno repe...@cisco.com Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd.
Dear WG members, I didn't had time to read the last version of 4rd-U but I read carefully -03 when it was published. I really appreciated the work done by Rémi to write down -03. The document is well written, easy to read and the requirements are clearly sketched. I really think this spirit should be adopted by MAP documents. As I already told Rémi, I would like if all proponents of stateless A+P converge and avoid wasting energies in comparing individual proposals. I thought this is what has been agreed during the softwire interim meeting: IMO, MAP effort meets the objective of group work. Some of the points raised by Rémi can be easily considered in the context of MAP; except the idea of unified header which is a step forward. Adopt a unified approach is exclusive to encapsulation and/or translation. The question now is: Does the unified approach bring new features + simplification compared to the normal IPv4-in-IPv6 encapsulation scheme (which I'm mainly interested in)? The answer is: No. Perhaps this is selfish but given what I mentioned above, I vote for the following: * Adopt the work of the MAP design team as the base specification for stateless A+P effort. * Make sure proposals from Rémi (except U) are discussed: e.g., Checksum neutrality (1) Share the archives of MAP Design Team discussion (2) Use IETF Issue Tracker to record the issues and the consensus/conclusion (3) Adopt a clear procedure within the Design Team to make decisions when there are conflicts * Reduce the amount of MAP documents: IMHO, three documents are needed (1) MAP Address Format (2) MAP Overall Architecture and Design Recommendations (3) MAP DHCPv6 Options Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : mardi 20 mars 2012 00:39 À : Softwires WG Cc : Yong Cui; Ralph Droms Objet : [Softwires] Path to move forward with 4rd. Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E T as Experimental. In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. Alain Yong, wg co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd
I have been running single translation (IVI) for one year and have tested divi in the same environment by cascading second translator successfully. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn -Original E-mail- From: Reinaldo Penno repe...@cisco.com Sent Time: 2012-3-23 14:33:00 To: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org Cc: Subject: Re: [Softwires] Path to move forward with 4rd Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- 张焕杰 E-mail/msn: ja...@ustc.edu.cn 安徽省合肥市金寨路96号 中国科学技术大学网络信息中心 (230026) Mobile: +86-13505693311 Tel: +86-551-3601897 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Le 2012-03-22 à 13:26, Guanghui Yu a écrit : Hi all This mail raises a very important issue. MAP-T and MAP-E are not competing technologies. They have different user scenarios. I read 4rd-u draft and found it is flawed. Please explain what, in your understanding, would be flawed. I will not support the adoption of 4rd-u, since there is no running code and there is no experimental evaluation. The theory of Reversible header mapping is so simple that, AFAIK, nobody with implementation experience would negate that it will work when tested. Other features of the U proposal may be debated, but they are not necessary to replace T and E by a solution that is suitable for use cases of these two. In summary, 4rd-U is not in the same level of MAP series Would you claim that there are no inconsistencies today in the MAP set of drafts? Actually, the U draft is more complete and self consistent than the set of MAP documents. Regard, RD and it should not be considered for adoption in coming Paris IETF meeting. PS: I'am sorry if this mail sends more than one time, the mail system of our university may have problems with this mail list today. Yu Guanghui ygh at dlut.edu.cn Network and Information Center Dalian University of Technology, China Tel: +86 411 84708117 在 2012-3-21，下午9:39， Xing Li 写道： Hi, Alain, Yong and Ralph, The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that “multiple address and port mapping technologies could and should converge” and you formally announced “the creation of the MAP (Mapping of Addresses and Ports) design team”, a design team which “is tasked to formulate a unified format to be used either in an encapsulation or double translation mode” (http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now. 4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic). Therefore, I don’t think we have any reason to change the procedure and in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data. Regards, xing 于 2012/3/20 7:38, Alain Durand 写道: Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish
Re: [Softwires] Path to move forward with 4rd
Hi, On 23 March 2012 13:10, Reinaldo Penno repe...@cisco.com wrote: Thank you. I believe the answer to my question is 'no'. divi and divi-pd and MAP-T are essentially the same, algorithmically, ie with the MAP algorithm and certain paramaters set (eg M=1) they are the same. The difference of on-the-wire encoding would not appear to have any tangible effect on experimental data collected for divi. Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02 -Woj. Still, it is good to see that you are planning to deploy MAP-T. It is certainly an important data point. Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in parallel? From: Congxiao Bao cx.cer...@gmail.com Date: Fri, 23 Mar 2012 18:04:47 +0800 To: Cisco Employee repe...@cisco.com Cc: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno repe...@cisco.com Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd
From: Wojciech Dec wdec.i...@gmail.com Date: Fri, 23 Mar 2012 13:26:48 +0100 To: Cisco Employee repe...@cisco.com Cc: Congxiao Bao cx.cer...@gmail.com, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi, On 23 March 2012 13:10, Reinaldo Penno repe...@cisco.com wrote: Thank you. I believe the answer to my question is 'no'. divi and divi-pd and MAP-T are essentially the same, algorithmically, ie with the MAP algorithm and certain paramaters set (eg M=1) they are the same. The difference of on-the-wire encoding would not appear to have any tangible effect on experimental data collected for divi. [RP] Interesting, thanks for the clarification. Can dIVI and MAP-T hosts/CPEs interoperate given they are essentially the same? Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02 [RP] I will read it and provide feedback. Thanks for the pointer. -Woj. Still, it is good to see that you are planning to deploy MAP-T. It is certainly an important data point. Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in parallel? From: Congxiao Bao cx.cer...@gmail.com Date: Fri, 23 Mar 2012 18:04:47 +0800 To: Cisco Employee repe...@cisco.com Cc: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno repe...@cisco.com Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd
On 23 March 2012 13:40, Reinaldo Penno repe...@cisco.com wrote: From: Wojciech Dec wdec.i...@gmail.com Date: Fri, 23 Mar 2012 13:26:48 +0100 To: Cisco Employee repe...@cisco.com Cc: Congxiao Bao cx.cer...@gmail.com, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi, On 23 March 2012 13:10, Reinaldo Penno repe...@cisco.com wrote: Thank you. I believe the answer to my question is 'no'. divi and divi-pd and MAP-T are essentially the same, algorithmically, ie with the MAP algorithm and certain paramaters set (eg M=1) they are the same. The difference of on-the-wire encoding would not appear to have any tangible effect on experimental data collected for divi. [RP] Interesting, thanks for the clarification. Can dIVI and MAP-T hosts/CPEs interoperate given they are essentially the same? Well, MAP-T and divi-pd in non-address-sharing mode (ie 1:1) should be totally compatible. However, given that the on-the-wire encoding of the PSID is different in the address sharing mode, interoperability in that mode won't be there. Cheers, Woj. Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02 [RP] I will read it and provide feedback. Thanks for the pointer. -Woj. Still, it is good to see that you are planning to deploy MAP-T. It is certainly an important data point. Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in parallel? From: Congxiao Bao cx.cer...@gmail.com Date: Fri, 23 Mar 2012 18:04:47 +0800 To: Cisco Employee repe...@cisco.com Cc: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno repe...@cisco.com Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd.
Le 2012-03-23 à 11:13, mohamed.boucad...@orange.com mohamed.boucad...@orange.com a écrit : Dear WG members, I didn't had time to read the last version of 4rd-U but I read carefully -03 when it was published. Note that -04 and -05 are significantly improved. Expertise of its now co-authors include broadband and mobile services as ell as product vendors. AFAIK, no reason why it wouldn't work, or do less than claimed, remained unanswered. If later on a flaw or uncertainty is identified, and confirmed after discussion, this will be fairly acknowledged. I really appreciated the work done by Rémi to write down -03. The document is well written, easy to read and the requirements are clearly sketched. I really think this spirit should be adopted by MAP documents. As I already told Rémi, I would like if all proponents of stateless A+P converge and avoid wasting energies in comparing individual proposals. I thought this is what has been agreed during the softwire interim meeting: IMO, MAP effort meets the objective of group work. Some of the points raised by Rémi can be easily considered in the context of MAP; except the idea of unified header which is a step forward. Adopt a unified approach is exclusive to encapsulation and/or translation. The question now is: Does the unified approach bring new features + simplification compared to the normal IPv4-in-IPv6 encapsulation scheme (which I'm mainly interested in)? The answer is: No. Perhaps this is selfish but given what I mentioned above, I vote for the following: * Adopt the work of the MAP design team as the base specification for stateless A+P effort. * Make sure proposals from Rémi (except U) are discussed: This may be taken as I don't care how many designs are standardized... provided my use case is covered by one of them. This is not AFAIK the best approach to simplify standards we make for the future. The chair encouraged further work on U after IETF 82 after arguments used to exclude it in Taipei were acknowledged to be invalid. Excluding to discuss U although it provides a unified design, with more operational features than either T or E, seems to me difficult to justify. Regards, RD e.g., Checksum neutrality (1) Share the archives of MAP Design Team discussion (2) Use IETF Issue Tracker to record the issues and the consensus/conclusion (3) Adopt a clear procedure within the Design Team to make decisions when there are conflicts * Reduce the amount of MAP documents: IMHO, three documents are needed (1) MAP Address Format (2) MAP Overall Architecture and Design Recommendations (3) MAP DHCPv6 Options Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : mardi 20 mars 2012 00:39 À : Softwires WG Cc : Yong Cui; Ralph Droms Objet : [Softwires] Path to move forward with 4rd. Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as
Re: [Softwires] Path to move forward with 4rd…
Le 2012-03-22 à 15:40, Maoke a écrit : dear Alain, Yong, Ralph and all, in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions a little confused me: if we need to go back to the stage before the works of the MAP design team? The MAP series have reached running codes and the collective understanding of the community. Here are some issues among those remaining before reaching collective understanding: a) T operation in hubspoke (hasn't been so far answered in an understandable way). b) IDs from shared-address CEs. T currently has so far no solution while both U and E include one. c) MAP-A+P says Each MAP node in the domain has the same set of rules while MAP-T says if a CE knows only a subset of the mapping rules ... d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp. The fact that no-one involved in the MAP design raised any of these issues is AFAIK sign that MAP has NOT reached collective understanding of the community. (Note that, concerning stateless v4/v6 solutions, I think I should be considered part of this community. Right? ). Maoke, clarifications on these points will be welcome. From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment. Note: This excludes ISPs that would like to offer full IPv4 transparency with some IPv6-only middles boxes. Right? The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community. second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing the tunneling and translation, if accepted as standard, may trap the operators into a harsh situation of being unable to define what building block it really is. Such an operator would know it uses 4rd-U. This doesn't seem to justify any FUD from co-authors from broadband and mobile operators (or from product vendors). It is stated as tunneling but actually behaves like tunnel in some aspects while like translation in some other aspects. Yes indeed, thus achieving the best of both worlds without making it more complex. Actually making it clearly less complex than supporting both T and E. (I have pointed out in the 4rd-u discussion thread). We see it only a yet-another-translation that try to solve some corner problems but introduces new, possibly major flaws (also pointed out in the technical threads on 4rd.) Possibly major flaws isn't an identified point on which U would do less than what it has been designed to do (unified replacement of T + E). IMPORTANT: - The essential characterization of U (vs T and E) is its Reversible header mapping (as replacement of both Double RFC6145 translation and Encapsulation). - Other features of U that differ from MAP (V-octet, CNP), or are complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this respect. Each of these features could be abandoned in U, or, if the WG appreciates what they offer, added to MAP. - For this, community acceptance to listen to explanations, would be the normal process. I will be available this week for this. Cheers, RD In either the term of architectural philosophy or technical details, introducing 4rd-u into standards would be harmful. personally, i respect the exploration of the author(s), and the discussion between me and the author encouraged me to comprehensively review E and T, and the result is: i bacame much more confident of the correctness of the MAP track. We should move forward. regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be put into standard track. Question is not about T, E or U. best regards, Maoke 在 2012年3月20日星期二，Alain Durand 写道： Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how
Re: [Softwires] Path to move forward with 4rd
Hi Wjociech, So the only different between MAP-T and dIVI-PD is the new PSID calculation in MAP. Otherwise, they are identical. Thanks, Yiu From: Wojciech Dec wdec.i...@gmail.com Date: Fri, 23 Mar 2012 14:01:59 +0100 To: Reinaldo Penno repe...@cisco.com Cc: Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Well, MAP-T and divi-pd in non-address-sharing mode (ie 1:1) should be totally compatible. However, given that the on-the-wire encoding of the PSID is different in the address sharing mode, interoperability in that mode won't be there. Cheers, Woj. smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Hi all This mail raises a very important issue. MAP-T and MAP-E are not competing technologies. They have different user scenarios. I read 4rd-u draft and found it is flawed. I will not support the adoption of 4rd-u, since there is no running code and there is no experimental evaluation. In summary, 4rd-U is not in the same level of MAP series and it should not be considered for adoption in coming Paris IETF meeting. PS: I'am sorry if this mail sends more than one time, the mail system of our university may have problems with this mail list today. Yu Guanghui ygh at dlut.edu.cn Network and Information Center Dalian University of Technology, China Tel: +86 411 84708117 在 2012-3-21，下午9:39， Xing Li 写道： Hi, Alain, Yong and Ralph, The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that “multiple address and port mapping technologies could and should converge” and you formally announced “the creation of the MAP (Mapping of Addresses and Ports) design team”, a design team which “is tasked to formulate a unified format to be used either in an encapsulation or double translation mode” ( http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now. 4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic). Therefore, I don’t think we have any reason to change the procedure and in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data. Regards, xing 于 2012/3/20 7:38, Alain Durand 写道: Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this
Re: [Softwires] Path to move forward with 4rd…
Hello Chairs, all In essence, while at a very high level all solutions appear to solve a common problem, just like all ducks look the same, some solve extra problems that are of critical importance to some operators, this forms the basis for the different approaches, and what led to the MAP draft set, and in that set there is no way to sqaure the circle The hybrid solution also does not square the circle, and what more raises several technical questions, besides lacking the trial implementation experience factor that MAP's constituents have shown - it thus appears to be in a different, rather experimental, league . Respectfully thus, the view presented under item 1) below and ultimately the questions appear set to cause further thrashing of arguments all over again. All this going a long way off from actually progressing the development of solutions that solve problems the WG cares about and under majority consensus if universal consensus is not possible. As a way forward I would suggest a much simpler approach that is more likely to result in some progress, with the following questions being asked: 1. Should MAP (all MAP drafts) be adopted as WG drafts all on Informational track? 2. Should 4rd-u as WG draft on the Experimental or Informational track, if shown to be in line with existing specs. Along with an acceptance of any/all of the above, there should be a charter clause indicating that one, or all of these drafts can be moved to a Standards track following WG consensus, without altering the status of the others, unless similarly consented. Regards, Wojciech. On 20 March 2012 00:38, Alain Durand adur...@juniper.net wrote: Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E T as Experimental. In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. Alain Yong, wg co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
On 3/20/12 12:38 AM, Alain Durand wrote: Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Hi, I'm not really happy with this decision. RFC 6346 Stateless A+P (a.k.a. 4rd/MAP) world is polarized in encapsulation and translation part. MAP-U is brave attempt to unify both worlds, but I;m not sure all the best parts from both world ended up in -U proposal and that result is what I would like to see in reality. Coming from operational ISP world, where this stuff will actually be implemented in reality, I would suggest to publish -E and -T as documents in standards track - and -U as experimental or informational. What I would like to see as network architect is that vendors deploys -E and -T in the same product named 4RD and operator can choose operating mode when implementing the solution - deciding between encapsulation or translation at will. This way this working group work and effort would become useful for operations. Cheers and see you in few days, Jan Zorz Go6 Institute Slovenia ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
+1, support Best regards -- Name:Zhankao WEN(温占考) Email: w...@synet.edu.cn w...@mail.neu.edu.cn TelFax: +86-24-83687240 Address: Networking Center Northeastern University Shenyang Liaoning Province P.R. China (110819) - Original Message - From: Xing Li x...@cernet.edu.cn To: Alain Durand adur...@juniper.net Cc: Softwires WG softwires@ietf.org, Yong Cui cuiy...@tsinghua.edu.cn, Ralph Droms rdr...@cisco.com Sent: Wednesday, 21 March, 2012 9:39:07 PM Subject: Re: [Softwires] Path to move forward with 4rd… Hi, Alain, Yong and Ralph, The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that “multiple address and port mapping technologies could and should converge” and you formally announced “the creation of the MAP (Mapping of Addresses and Ports) design team”, a design team which “is tasked to formulate a unified format to be used either in an encapsulation or double translation mode” ( http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html ). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now. 4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic). Therefore, I don’t think we have any reason to change the procedure and in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data. Regards, xing 于 2012/3/20 7:38, Alain Durand 写道: Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E T as Experimental. In the meantime, we would like to encourage discussion on the mailing
Re: [Softwires] Path to move forward with 4rd
I am disappointed with this approach. Despite the support, the WG adoption of MAP documents has been delayed for a label reason. I find it unfair since the label can be changed any time until the IESG review. How can it be a hold-up? One would have to wonder the intent of forming the design team at first place. It seems that we keep putting roadblocks on the path for the stateless solutions to get standardized. One after another. What's the purpose? It seems that the work done by the design team, which was formed for a reason, is being ignored. If not, then their documents would have been the WG documents by now and the email would be referring to MAP (and not 4rd). This is a bit disrespectful. I would suggest to put all the documents developed by the MAP design team as Standards track document, and anything else is up for discussion. Cheers, Rajiv -Original Message- From: Alain Durand adur...@juniper.net Date: Mon, 19 Mar 2012 16:38:42 -0700 To: Softwires WG softwires@ietf.org Cc: Yong Cui cuiy...@tsinghua.edu.cn, Ralph Droms rdr...@cisco.com Subject: [Softwires] Path to move forward with 4rd Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E T as Experimental. In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. Alain Yong, wg co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Hi, Alain, Yong and Ralph, The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that “multiple address and port mapping technologies could and should converge” and you formally announced “the creation of the MAP (Mapping of Addresses and Ports) design team”, a design team which “is tasked to formulate a unified format to be used either in an encapsulation or double translation mode” (http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now. 4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic). Therefore, I don’t think we have any reason to change the procedure and in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data. Regards, xing ? 2012/3/20 7:38, Alain Durand ??: Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E T as Experimental. In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. Alain Yong, wg co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
