Re: [Softwires] Path to move forward with 4rd…

[Rémi Després <[e-mail]>]

Maoke,
More comments in line.

Tomek, could you please tell your view on (*) below.


Le 2012-03-26 à 06:35, Maoke a écrit :

> 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,

As already answered, "tunnel" is taken to mean a local setup such that you cannot detect, e2e, that packets weren't natively routed all the way. This is a AFAIK reasonable use of the word.
Some words to clarify this in the draft could be added if found desirable. 

> due to not providing virtual links; while you insist it not a translation at all). 

No objection to use Reversible header "translation" instead of Reversible header "mapping". The important points are: (1) reversibility of header mapping/translation; (2) payload preservation. (No religion against the word translation!). 

What MUST be avoided is only confusion with RFC6145 translation, because it is different. 


(*)
> 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!)

Copy to Tomek Mrugalski is added, in order to have his expertise on this subject.



> 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. 

No problem here.
End of this for me.


>> 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. 

What you call "abnormal" is a packet that is fragmented by its source and not to be fragmented in the network. 
note however that this is the choice that has become standard in IPv6 (fragmentation only by sources).

> 2) well, it is good if we can take care of the minority without putting the majority into potential trouble and uncertainty. 

Agreed.
That's precisely what U has been designed to achieve, successfully AFAIK. 


>> 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. 

None of these statements have ever been made before AFAIK. They seem to be your own construction.

If you could point to text in the U draft that justifies your concern, and explain what might go wrong, that would permit to understand what you mean.


> 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. 

The subject at hand is CE node having 4rd-U (for IPv4 across IPv6), and BIH (for IPv4 applications communicating with IPv6-only peers). Thanks to 4rd-U, BIH-capable nodes can be used on IPv6-only networks.


>> 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) 

I don't see in this scenario why anything that works with E (i.e. between CEs and BRs) wouldn't also work with U.
                                     

> 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)----------+

Same comment.


> 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. 

Same comment.

> MAP-E (and other E) surely has no limitation in supporting any features of existing routing protocols.

Why U would be less transparent between CEs and BRs than E for any L4 protocol remains unexplained.
 
> with at least the above three examples, i conclude "U cannot replace E at all"!

See above.

> (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.

???

- What about a domain parameter being needed or not in MAP for hub&spoke?
- Wojciech just suggested that, for MAP-T, CEs and BRs would compute UDP checksums of full IUDP packets received with null checksums. Is it something you would also recommend?

I don't see any substantial point about U that hasn't been answered.


>> 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.


Please note that several MAP team members are co-authors of the U proposal.
I never refused discussion (as you well know), and prefer to do it in the open.
Discussion is now on the WG ML.

> just our current understanding is: it is not necessary.

- Understanding of whom?
- If some others find it IS necessary, why not accepting to satisfy them too (that's what standardization is about)?
  

>>  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. 

No disagreement on any of this.


Cheers,
RD


> 
> 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
>