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 <[email protected]> > > > 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 hub&spokes 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 place, isn't a proof that > the same ratio will be found later and somewhere else. > 2) Those that happen to be in the sacrificed minority, be it small, may > not like their situation. Solving the problem, be it only for them, is > progress. > 1) not only one statistics. i did it at Tsinghua University. prof. Bao and others did it at CERNET. other guys did it in Europe and published in IMC'07. and if you carefully read that paper, you may found that case was very abnormal. 2) well, it is good if we can take care of the minority without putting the majority into potential trouble and uncertainty. > > 2) with introducing #1. weird definition of the fragment header of IPv6; > #2 weird packet of IPv6 carrying ICMPv4 messages? > > > AFAIK, not weird to those who are open to accept that it is very simple. > AFAIK, you'd better to have #1 accepted by the IPv6 protocol and have #2 well discussed with the ICMP designers before concluding they are "not weird"! i am not so open. to those who are open to accept this, i think they should be also open to the following propositions (that are wrong to me): *1. IPv6 option header, as long as there are reverved or not-yet-used or padding bits, could be redefined as we like. *2. it is a useless design that ICMP(v4 or v6) error message body contains part of the original IP(v4 or v6) packet, where the source address is identical to the destination of the IP(v4 or v6) header carrying the ICMP(v4 or v6) message. *3. it is a useless design that ICMPv6 header checksum contains pseudo-header of the IPv6 header carrying it. *4. IPv4 header checksum is actually useless. if the community would accept these *1 ~ *4 as true statements, i would be also open to accept the above 2). but don't conclude before we get the feedback from the community! ... > well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are > major flaws (as we discussed so much, i was not convinced at all). i don't > think others who read the specification don't see them and other issues. > > > ICMPv4 payloads in IPv6 packets appear only during domain traversal, where > they don't hurt anyone. > see above. > > If a host is IPv6 only, it isn't a 4rd-U host. > For communication between IPv4-only applications of DS hosts and IPv6-only > hosts, there are already workable RFCs. > common understanding, including RFC6052/RFC6145/RFC6146 but surely not limited to these. > BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient. > A new solution for this isn't needed. > BIH serves DS hosts connected to DS networks. the use case does not cover the all cases of IPv4-IPv6 mutual communciations. > > an operator definitely needs the encapsulation as a fully featured virtual > link (underlay infrastructure) in real O&A for IPv4 communications over > IPv6 infrastructure. U cannot replace E at all. > > > Different understanding. > An detailed E use case that cannot be supported by U (if it exists) would > give substance to this claim. > Open to look at it. > in my personal experience i could give you at least three quick examples of the use case for the building block of "virtual link": first example, if the IPv4 customer network plays BGP over IPv4 with the provider, through the BGP session between CE and BR, a virtual link is desired. (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 world) second example, there are dynamic routing protocols like RIP running in the following (multihoming) topology for IPv4 routing. the operator may want to treat the CE-BR as a single hop in order the virtual link is considered the distance vector calculation. (IPv4 customer network)--- CE ----(IPv6-only domain)----- BR ----(IPv4 world) \ / \ / +------------ CE ----(Another, IPv4 domain)----------+ third example, same topology as above but OSPF are applied, and OSPF TTL-security check are enabled to ensure hop-passings less than a specified threshold. if the operator would like to treat CE---(IPv6-only domain)---BR as one hop because it is considered as virtual link, 4rd-u's rudiness in decreasing TTL will hurt. MAP-E (and other E) surely has no limitation in supporting any features of existing routing protocols. with at least the above three examples, i conclude "U cannot replace E at all"! (btw, surely the translation has the same limitation not to support the above features but, e.g., as you also said, it opens transport-layer stuff to the middle boxes). therefore i said operators may use either encapsulation or translation according to what they attach importance to.) > > but U needs still discussion > > > T too. > See, for example, (*) above. > you have ended that subject. fine to me. people have known the difference between the "needs discussions" for the both. > > and running code approval. it cannot replace T at least this moment. > > > Understanding how U's header mapping works doesn't need great expertise. > Co-autors readily understood it, with origins as varied as router-and-host > vendor, software vendor, broadband operator, mobile operator. > well, it works just like another translator, surely it doesn't need great expertise. > > Running code as soon couldn't be done yet, but isn't a big deal at all > (see (**) below) > > ... > > MAP can work even without the V-octet and CNP, at least in significant > cases. > > > Not a valid reason to stop progress, especially if easy to understand. > At least Med suggested to look at V octet even in the context of MAP (if > chosen for standard track). > no problem if you keep debate in/with the MAP design team. just our current understanding is: it is not necessary. > > if we have the standard of MAP, we can immediately deploy it into > practice through applying MAP rules into the already well understood, well > approved, well standardized encapsulation and translation modules, > without waiting for the approval of the new features in the address > format, and the approval of the reversible header mapping tightly coupled > with the address format. > > > (**) > When we discussed in Taipei, you first said you might code 4rd-U so that > it could be tested for real. You didn't do it for reasons that I perfectly > respect. > yes but i also mentioned the prerequisite: "when i fully understand it and see it qualified". i also talked with some others that i was interested in that and, if possible and necessary, i would try to code it out and test it, but again the prerequisite was attached. i have no reason to do a code for a stuff even suspected by myself. you should remember that, after a large amount of discussion, i told you i wouldn't code it when we reached the problem of IPv6 carrying ICMPv4. this made me re-think the issue in the aspect of architectural building block. sure the company's resource allocation was a reason but this reason was tightly correlated to my own academic judgement on the necessity. thanks, - maoke > Yet, modifying T code to support header mapping remains quite simple (you > even call it a translation variant). Starting from E code, it's simple too. > When this is done, all verifications can be easily done that what analysis > says is right is also right with running code. > > > Regards, > RD >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
