Subject: [Softwires] map-t to proposed standard rather than experimental

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Nov 2014 11:11:11 -1000

Dear softwire participants,

As we've gotten closer to finally finishing the stateless address-sharing suite of softwire specifications, I've had to explain what happened to a number of different people, both in the directorates and on the IESG, and even to nomcom.  As a consequence I've had to do a lot of thinking about why things wound up the way they did, and whether what happened was the right outcome.

As a result of the directorate reviews and the IESG review, it became clear that the plan to advance MAP-T as experimental didn't make sense.  The three solutions, MAP-E, MAP-T and Lightweight 4over6 actually make a lot of sense when presented together.   Because of this there is no reason that one should be experimental and the other two standards track.

I would therefore like the working group to consider changing the proposed status of MAP-T to Proposed Standard.   I think this would be a less confusing outcome.   If the working group agrees, we would go through a second IETF last call and then advance the document.

I have not made the same suggestion with respect to 4RD because it actually is quite different from the other three documents.   This is not intended as an editorial comment about 4RD: rather, it's simply that I think the three documents together offer a good suite of solutions that can be understood and implemented together, whereas 4RD is essentially its own solution.   I think the working group has already chosen to advance the MAP-style lightweight solutions, and it would actually be confusing to advance 4RD as a separate standard solution.

Suresh and Cui Yong will be asking the working group to weigh in on this issue, and then assuming no blocking objections are raised we will re-do the IETF last call for map-t as a proposed standard.

Thanks!

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 12 Nov 2014 08:21:19 +0000

Ted,

I would therefore like the working group to consider changing the proposed status of MAP-T to Proposed Standard.

That's quite reasonable. And I agree, especially given that few operators have already deployed and asked for the same.

If the working group agrees, we would go through a second IETF last call and then advance the document.

Could we not combine the LC and the question in 1-go?

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services
CITT CTO Office

On Nov 11, 2014, at 11:12 AM, "Ted Lemon" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks!
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: <[email-masked]>
Date: Wed, 12 Nov 2014 08:29:27 +0000

I support this move as in Reliance we are heavily banking upon this technology for our  deployment.

With regards,

B.Nagaraj

Cabin 3, 2nd floor, 2A /Cabin 8, B wing, 3rd floor, TC 23
RCP complex,
Thane Belapur Road
Ghansoli, Navi Mumbai-400701

Phone:
Work: +912244773047 / +912244787958
Mobile: +919867564147

From: Softwires [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Wednesday, November 12, 2014 1:51 PM
To: Ted Lemon
Cc: Softwires WG
Subject: Re: [Softwires] map-t to proposed standard rather than experimental

Ted,

Cheers,
Rajiv Asati

Thanks!
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires
"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Nov 2014 10:46:01 +0100

Hi Ted,

You are right in that an old decision may always be revisited before casting it in concrete.
Yet, changing an old decision has to be done carefully, especially if consequences of the change haven’t been documented.
Comments below suggest that wisdom is rather to maintain the old decision as it is: only one standard for stateless IPv4 connectivity across IPv6-only domains.

Le 11 nov. 2014 à 22:11, Ted Lemon <[email-masked]> a écrit :

> As a result of the directorate reviews and the IESG review, it became clear that the plan to advance MAP-T as experimental didn't make sense.
AFAIK, not at all as clear as you say:
- If  both MAP-E and MAP-T would become standard, CPE providers would need to support (and maintain) both. 
- If both would become standard, full transparency to IPv4 fragmentation, which is guaranteed with MAP-E but not with MAP-T, would no longer be guaranteed to any customer, due to multiple standards.
- If an ISP domain would activate both, CPEs would have to select one of the two standards for their transmissions, with AFAIK no advice on how to do it. 

> The three solutions, MAP-E, MAP-T and Lightweight 4over6 actually make a lot of sense when presented together.

MAP-E and lw4over6 make a lot of sense, yes, but not with MAP-T in addition:
- MAP-E is and lw4over6 have well separated uses ( stateless and static, stateful and dynamic)
- MAP-E and MAP-T are two different solutions for essentially the same use. (Their DHCPv6 commonality is not an operational consideration.)

>   Because of this there is no reason that one should be experimental and the other two standards track.

The above shows that there are such reasons. 
Deciding such a change without re-visiting technical arguments would depart from customary IETF practice.
While the consensus on making MAP-E the only standard has held for long, re-visiting technical arguments would lead to an undesirable extra delay before the already-over-awaited MAP finalization.

> I think this would be a less confusing outcome.   

Completely opposite view, based on the above.

> I have not made the same suggestion with respect to 4RD because it actually is quite different from the other three documents.

Wise decision, in line with the current WG consensus.

>   This is not intended as an editorial comment about 4RD: rather, it's simply that I think the three documents together offer a good suite of solutions that can be understood and implemented together, whereas 4RD is essentially its own solution.   I think the working group has already chosen to advance the MAP-style lightweight solutions, and it would actually be confusing to advance 4RD as a separate standard solution.

> Suresh and Cui Yong will be asking the working group to weigh in on this issue, and then assuming no blocking objections are raised we will re-do the IETF last call for map-t as a proposed standard.

What makes objections to become blocking may be unclear, but I hope that the above will be enough for the WG to maintain its old and wise consensus.

Best regards,
RD

> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 05:13:36 -1000

> Could we not combine the LC and the question in 1-go? 

The problem with that is that the chairs (and the IESG!) would like to get the assent of the working group to make this change, and that has to be complete before the IETF last call can start.

---

From: "Mallette, Edwin J." <[email-masked]>
Date: Wed, 12 Nov 2014 20:33:50 +0000

Hi Remi,

Thanks for your comments.  My added comments are below...

On 11/11/14, 11:46 PM, "Rémi Després" <[email-masked]> wrote:

>Yet, changing an old decision has to be done carefully, especially if
>consequences of the change haven¹t been documented.
>Comments below suggest that wisdom is rather to maintain the old decision
>as it is: only one standard for stateless IPv4 connectivity across
>IPv6-only domains.
>
>> As we've gotten closer to finally finishing the stateless
>>address-sharing suite of softwire specifications, I've had to explain
>>what happened to a number of different people, both in the directorates
>>and on the IESG, and even to nomcom.  As a consequence I've had to do a
>>lot of thinking about why things wound up the way they did, and whether
>>what happened was the right outcome.
>>
>> As a result of the directorate reviews and the IESG review, it became
>>clear that the plan to advance MAP-T as experimental didn't make sense.

[EJM] it has never been the case that just because a standard exists that
can be used on an element, that said suppliers of that element have to
implement the standard. They implement standards on their devices based on
their customer demand. I fully expect that MAP-T will be implemented in
production networks and having broad deployments of a protocol documented
in an experimental-track RFC seems to be in poor judgement.

>
>- If both would become standard, full transparency to IPv4 fragmentation,
>which is guaranteed with MAP-E but not with MAP-T, would no longer be
>guaranteed to any customer, due to multiple standards.

[EJM] This is not something I care about operationally. It seems like an
academic argument, not a practical one.

>- If an ISP domain would activate both, CPEs would have to select one of
>the two standards for their transmissions, with AFAIK no advice on how to
>do it.

[EJM] Necessity is the mother of invention; given this turns out to be a
problem, I¹m unconcerned.  I¹m sure the smart people this impacts can get
together and document such advice.

>- MAP-E and MAP-T are two different solutions for essentially the same
>use. (Their DHCPv6 commonality is not an operational consideration.)
>
>While the consensus on making MAP-E the only standard has held for long,
>re-visiting technical arguments would lead to an undesirable extra delay
>before the already-over-awaited MAP finalization.

[EJM] My view is that this is a mischaracterization. The decision from my
POV was to move these drafts forward in light of a clear understanding
that there would be no converging around the religious debates. Remember
the coin flip ?  That¹s not exactly a technical decision.

>
>> I would therefore like the working group to consider changing the
>>proposed status of MAP-T to Proposed Standard.
>
>> I have not made the same suggestion with respect to 4RD because it
>>actually is quite different from the other three documents.
>
>>   This is not intended as an editorial comment about 4RD: rather, it's
>>simply that I think the three documents together offer a good suite of
>>solutions that can be understood and implemented together, whereas 4RD
>>is essentially its own solution.   I think the working group has already
>>chosen to advance the MAP-style lightweight solutions, and it would
>>actually be confusing to advance 4RD as a separate standard solution.
>
>> Suresh and Cui Yong will be asking the working group to weigh in on
>>this issue, and then assuming no blocking objections are raised we will
>>re-do the IETF last call for map-t as a proposed standard.
>
>What makes objections to become blocking may be unclear, but I hope that
>the above will be enough for the WG to maintain its old and wise
>consensus.
>
>Best regards,
>RD
>
>
>>
>> Thanks!

________________________________

CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. **If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Nov 2014 14:46:43 -1000

> What makes objections to become blocking may be unclear, but I hope that the above will be enough for the WG to maintain its old and wise consensus.

For an objection to be blocking, you should be able to say that some interoperability issue exists or is thought to exist in the document that needs to be explored, and that is the reason for the experiment.   Otherwise the presumption is that an experimental document could be promoted to standards track at any time after publication.

---

From: Rémi Després <[email-masked]>
Date: Thu, 13 Nov 2014 14:59:14 +0100

> For an objection to be blocking, you should be able to say that some interoperability issue exists or is thought to exist in the document that needs to be explored, and that is the reason for the e…

Thanks for the clarification.

1.
Concerning interoperability, can a MAP-T-only CPE communicate with a MAP-E only DTE? 
AFAIK, the answer is a clear NO. 

2.
Note that, although MAP-E being THE standard, necess , any ISP that provides CPEs to all its customers can deploy any workable solution of its own for the same purpose.
- If the design is right, it can work perfectly.
- Two such solutions are specified in IETF for this (in addition to the standard itself), with different pros and cons (MAP-T and 4rd).
For ISPs whose CPEs may be supplied by customers themselves, interworking between CPEs depends on all of them supporting only THE standard. This becomes supporting ALL THE standards if there are several.

This being said, if the WG consensus becomes that 2 standards are preferred to 1, my point is that it should be done consciously. 
Besides, my personal view remains that, for a given purpose, 1 standard is better than 2.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 13 Nov 2014 17:29:16 +0100

Hi Edwin,
Thanks for sharing you views.
More comments below.

...
>>>  a result of the directorate reviews and the IESG review, it became
> implement the standard.

Sure: customer demand is the key.
I was implicitly referring only to vendors that want their CPEs to interwork with all other CPEs that support  v4/v6 stateless v4/v6 solutions as standardized in IETF.

...
> I fully expect that MAP-T will be implemented in

If there is sufficient customer demand for an experimental alternative to the standard, I can hardly see why a vendor would refuse to support it (in addition to the standard). Especially if it sells products to ISPs that supply all CPEs. 

> [EJM] This is not something I care about operationally.

Note that, by not caring, you neglect what RFC4821  (standard track) recommends for path MTU discovery in IPv4.  It use packets with MF=DF=1 (fragmented packets that may no longer be fragmented), a combination that is lost in MAP-T (and preserved in MAP-E). 
I know some people say it’s negligible, but this is IMHO a lack of understanding.

> It seems like an

- AFAIK, PMTU discovery serves a real purpose.
- In any case, standardizing both MAP-E and MAP-T would require a modification of RFC4821.

...
> the coin flip ?  That¹s not exactly a technical decision.

The only decision I remember, is that MAP-E will the unique standard, and that both MAP-T and 4rd will be experimental.

I recall that,first, the WG clearly wanted only one standard.
Then, various supporters of MAP-E, and various supporters of MAP-T, voted that a combination of the 2 would not be 2 standards. (By doing so, it is a fact that they objectively increased their chances to find their preferred design in the standard). 
No consensus was reached on this 2=1, but not on 2=2 either. 
The coin flip that followed, decided by the chairs, was indeed an non-technical procedure, but it proved efficient: 
- After MAP-E has been voted to become THE chosen standard (with the two others as experimental), a clear WG consensus supported this as the final decision. 
- This was IMHO a remarkable chairs’ achievement in the difficult context of that time.

CONCLUSION:
If the IESG, now proposes 2 standards instead of 1, that’s a choice I view as based on a misunderstanding.
I therefore vote against a WG support of this proposal.

Regards,
RD

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 10:00:29 -1000

> If the IESG, now proposes 2 standards instead of 1, that’s a choice I view as based on a misunderstanding.

The IESG proposes one standard with three profiles or, if you prefer, three standards instead of two.

> I therefore vote against a WG support of this proposal.

You were not asked for a vote.   You were asked if you had any technical objection: some reason why MAP-T might have interop problems or operational problems and thus ought to be only an experiment and not a standard.  A process objection would also be viable, but as I've explained, I don't think there _is_ a process objection you could raise here.

---

From: Rémi Després <[email-masked]>
Date: Thu, 13 Nov 2014 22:32:43 +0100

13 nov. 2014  21:00, Ted Lemon <[email-masked]>  :

> You were not asked for a vote.

Wasn’t so clear, but OK.

> You were asked if you had any technical objection: some reason why MAP-T might have interop problems or operational problems and thus ought to be only an experiment and not a standard.

(a) Incompatibility with path MTU discovery  (standard-track RFC4821) is, in my understanding, sufficient a reason to keep MAP-T experimental.  

(b) I understand that the MAP-DHCP draft includes specifications for both MAP-E and MAP-T, and that an RFC cannot be both standard and experimental track.
Isn’t it possible, in the MAP-DHCPv6 RFC to have:
- for stateful operation, a MUST for lw4over6
- for stateless, a MUST for MAP-E, and, for MAP-T, a "MAY as long as it remains experimental, to become a MUST if and when "

If (a) is deemed insignificant, and (b) is found impossible, I guess  there is no more useful contribution I can hope to make for IPv4 across IPv6. 

Regards,
RD

>  A process objection would also be viable, but as I've explained, I don't think there _is_ a process objection you could raise here.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 11:40:37 -1000

> (a) Incompatibility with path MTU discovery  (standard-track RFC4821) is, in my understanding, sufficient a reason to keep MAP-T experimental. 

Pretty much everything on the internet is incompatible with ICMP-based PMTU discovery, unfortunately.   But can you explain the specific issue here?   Is the problem present only for MAP-T and not MAP-E and lw4over6?

---

From: Rémi Després <[email-masked]>
Date: Fri, 14 Nov 2014 11:49:58 +0100

13 nov. 2014  22:40, Ted Lemon <[email-masked]>  :

> Pretty much everything on the internet is incompatible with ICMP-based PMTU discovery, unfortunately.

Indeed.
That’s why the packetization-layer PMTUD has been specified (precisely in the RFC4821 I mentioned).
It says (ref. http://tools.ietf.org/html/rfc4821#section-4):
"All hosts SHOULD use IPv4 fragmentation in a mode that mimics IPv6 functionality.  All fragmentation SHOULD be done on the host, and all IPv4 packets, including fragments, SHOULD have the DF bit set such that they will not be fragmented (again) in the network."

>   But can you explain the specific issue here?   Is the problem present only for MAP-T and not MAP-E and lw4over6?

- Only MAP-T lacks transparency to the IPv4 DF bit. 
(Encapsulations of MAP-E and lw4over6 preserve the DF bit; 4rd has a specific provision for DF transparency.)
- This problem has been known since the interim Softwire meeting in Beijing, in September 2011.
- The WG has been made aware at various occasions (see in particular the first bullet of slide 4 in http://www.ietf.org/proceedings/83/slides/slides-83-softwire-12.pdf) 

Regards,
RD

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Nov 2014 09:35:08 -1000

> - Only MAP-T lacks transparency to the IPv4 DF bit. 

So your concern is that if fragmentation at the translator results in an IPv6 packet that is larger than the MTU of the IPv6 path between the 4->6 translator and the 6->4 translator, fragmentation will not occur?   This would result in a packet too big ICMP message being sent back to the translator, which would then use a lower MTU in making its fragmentation decision on the next packet.

So I guess your concern is that the problem is that in this case the specific packet that was dropped due to IPv6 PMTU discovery on the path between the two translators would _not_ result in an ICMP Packet Too Big message being sent to the IPv4 host.   Instead that host would see this as a dropped packet.

Can you explain why this is bad?   I mean, I can see that there is possibly a small advantage to the DF transparency you are talking about, but it doesn't amount to an interop problem, and clearly the right thing will happen.   So why is this a blocking issue?

---

From: Rémi Després <[email-masked]>
Date: Fri, 14 Nov 2014 23:22:30 +0100

14 nov. 2014 20:35, Ted Lemon <[email-masked]> :

> So your concern is that if fragmentation at the translator results in an IPv6 packet that is larger than the MTU of the IPv6 path between the 4->6 translator and the 6->4 translator, fragmentation will not occur?

The opposite. With a DF=1 according to RFC4821, fragmentation can occur while it shouldn’t.

For instance, if a DF=MF=1 packet traverses a MAP-T domain without being fragmented in it, and is too long for a link MTU further downstream, it will be fragmented. This is contrary to what is required by DF=1. 
Consequently, the packet is accepted, and acknowledged, while il should have  being lost (and not acknowledged).
The transmitter looses the expected warning that it may have to reduce its transmit MTU;

>   This would result in a packet too big ICMP message being sent back to the translator, which would then use a lower MTU in making its fragmentation decision on the next packet.
> 
> Can you explain why this is bad?   I mean, I can see that there is possibly a small advantage to the DF transparency you are talking about,

> but it doesn't amount to an interop problem
Not an "interop" problem, agreed. 
But it does amount to an operational problem, for whoever is interested in PMTU discovery. 

> and clearly the right thing will happen.   

As explained above, what happens is clearly the wrong thing (and this in some conditions that are needed for PMTU discovery of RFC4821).

> So why is this a blocking issue?

Because, as explained above, it breaks PMTU discovery of RFC4821.

If this is acceptable to whoever wants to deploy MAP-T, in due knowledge of its experimental status, it is not AFAIK acceptable in a standard. 
(In standard-track MAP-E and  lw4over6, are fine because free from such a problem. Also, for those who prefer translation to encapsulation but don’t want to break PMTU discovery, experimental 4rd is available.)

BTW, shouldn't this information be forwarded to the IESG for its understanding the issue?

Regards,
RD

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Nov 2014 14:40:36 -1000

> If this is acceptable to whoever wants to deploy MAP-T, in due knowledge of its experimental status, it is not AFAIK acceptable in a standard. 

I do hear your point, Rémi.   However, the problem actually exists in RFC 6145, not in this document, and RFC 6145 is a standards track document.   Also, this is a topic that the working group discussed and considered addressed long before the coin toss.   So I think this counts as re-raising an issue that was previously addressed, and not as an issue that would have any bearing on the current discussion.

---

From: Rémi Després <[email-masked]>
Date: Sat, 15 Nov 2014 10:45:57 +0100

15 nov. 2014 01:40, Ted Lemon <[email-masked]> :

> I do hear your point, Rémi.   

Understanding in what MAP-T is incompatible with IPv4 PMTU discovery is then progressing.
But, as shown below, your understanding of the point isn’t complete yet.
 
> However, the problem actually exists in RFC 6145, not in this document, and RFC 6145 is a standards track document.  

Misunderstanding of yours: the problem does not exist in RFC6145:
- With the single translation of RFC6145, an IPv4 packet which is sent with DF=1 (as needed for PMTUD of RFC4821) will never be fragmented (neither before nor after translation).  This is simply because IPv6 routers never fragment packets. => RFC4821 isn’t broken by RFC6145
- That is double translation that brings the problem: an IPv4 packet sent with DF=1 (as needed for RFC4821)  can be fragmented after being translated back to IPv4. => RFC4821 is broken by MAP-T.

> Also, this is a topic that the working group discussed and considered addressed long before the coin toss.

It is clear that real understanding of this point isn’t widely shared. (Even in your case, you needed to ask a number of clarifications).
That’s what makes this contribution worth doing: decisions have to be made with consciousness of significant facts.

>   So I think this counts as re-raising an issue that was previously addressed, and not as an issue that would have any bearing on the current discussion.

IMHO, a clear explanation of this contradiction between MAP-T and PMTU discovery of RFC4821 should be present in the draft itself. 
If I stopped spending energy to try and get it, it is because I felt a strong preference  of MAP-T authors for keeping it concealed, and I had to move to other activities.

Why then does the issue comes now? 
Because it is now that a proposal comes to promote MAP-T from experimental to standard.

I am sorry that this contribution goes against a smooth and easy acceptance of an IESG goof faith proposal, but significant facts need to be known.

Regards,
RD

PS: As this discussion continues, and as you didn’t answer my question about when the IESG should be informed, I hope you won’t find inappropriate my opening the channel now.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Nov 2014 01:32:37 -1000

> PS: As this discussion continues, and as you didn’t answer my question about when the IESG should be informed, I hope you won’t find inappropriate my opening the channel now.

Normally the way it works is that the working group chairs do a consensus call; if someone believes that the consensus was called incorrectly, then that person appeals to the chairs.   If the chairs do not agree, that person would then appeal to the responsible AD.   If the responsible AD doesn't agree, then that person would appeal to the IESG as a whole.

It is true that double translation has the problem that the DF bit is not communicated through.   This is a limitation of the MAP-T specification.   I've asked the authors about this, and they did not deny that this limitation exists, so your claim that the authors are trying to conceal it seems a bit un-collegial.   As I said, the working group did consider this issue, and it was not a factor in the coin toss.

---

From: Xing Li <[email-masked]>
Date: Sat, 15 Nov 2014 19:33:37 +0800

This is a very corner case (DF=1&MF=1), and it has been discussed in

page 8 (DF=1&MF=1) in 
http://www.ietf.org/proceedings/83/slides/slides-83-softwire-11.pdf

and if people really want to address this corner case (DF=1&MF=1), MAP-E 
can be used (only for the packets with DF=1&MF=1) without any problem, 
as shown  in (the mixed mode)

page 6 of http://www.ietf.org/proceedings/84/slides/slides-84-softwire-5.ppt

Regards,

xing

ps. Pretty much everything on the internet is incompatible with 
ICMP-based PMTU discovery, unfortunately.

---

From: Rémi Després <[email-masked]>
Date: Sat, 15 Nov 2014 21:14:15 +0100

Hi Xing,

15 nov. 2014 12:33, Xing Li <[email-masked]>  :

> page 8 (DF=1&MF=1) in http://www.ietf.org/proceedings/83/slides/slides-83-softwire-11.pdf

Showing a statistic where use of MF=DF=1 has been very limited doesn’t change that MF=DF=1 is what is recommended in RFC4821 for deployment of Path MTU Discovery. The RFC does say:
"All hosts SHOULD use IPv4 fragmentation in a mode that mimics IPv6 functionality.  All fragmentation SHOULD be done on the host, and all IPv4 packets, including fragments, SHOULD have the DF bit set such that they will not be fragmented (again) in the network."

> and if people really want to address this corner case (DF=1&MF=1), MAP-E can be used (only for the packets with DF=1&MF=1) without any problem, as shown  in (the mixed mode)
> 

I didn’t understand that the "Mixed MAP-T/MAP-E" mode was included in available drafts. 
Anyway, be it included or not, it remains that any use of MAP-T breaks the DF=MF=1 combination of RFC4821, and therefore ICMP-independent Path MTU discovery.

> Regards,
> 
> xing
> 
> ps. Pretty much everything on the internet is incompatible with ICMP-based PMTU discovery, unfortunately. 

As already answered to Ted, the PMTU discovery of RFC4821 is precisely that which is designed not to depend on ICMP.
That’s why breaking is in no way negligible.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 15 Nov 2014 21:24:58 +0100

15 nov. 2014 12:32, Ted Lemon <[email-masked]> :

> It is true that double translation has the problem that the DF bit is not communicated through.   This is a limitation of the MAP-T specification.  

>  I've asked the authors about this, and they did not deny that this limitation exists,

Good to know authors confirmed.
(Note that denial would have been difficult. That’s just a simple technical analysis.)
But did they confirm my complete point, namely that MAP-T breaks the ICMP-independent Path MTU Discovery of RFC4821?
If they didn’t, the fact remains, is important, and is also easy to verify.

> so your claim that the authors are trying to conceal it seems a bit un-collegial.

It seemed to you a bit un-collegial, but it certainly didn’t intend to be:
- To explain why I didn’t insist at that time to document the PMTUD problem, I just said "I felt a strong preference  of MAP-T authors for keeping it concealed, and I had to move to other activities." .  
- This is just the truth about what I felt then.
- In any case,  if anyone is crossed by what I said, I apologize for having told, in good faith but too frankly, what I had felt.

>   As I said, the working group did consider this issue, and it was not a factor in the coin toss.

This seems to suggest that someone viewed this issue had been "a factor in the coin toss". 
No one did AFAIK, and certainly not me. 
But this isn’t the point.

Even in its experimental status, I do think MAP-T's specification should have included a warning that it is incompatible with Path MTU Discovery of RFC4821, and that MAP-E should be used if such compatibility is desired.

Yet, IMHO, harm of this warning being absent remains limited enough to be acceptable as long as the status of MAP-T remains Experimental.

Regards,
RD

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Nov 2014 17:54:43 -1000

> But this isn’t the point.

If it wasn't a factor in the coin toss, it doesn't have anything to do with the working group's decision to choose Experimental vs. Proposed status.

> Even in its experimental status, I do think MAP-T's specification should have included a warning that it is incompatible with Path MTU Discovery of RFC4821, and that MAP-E should be used if such co…

I would not object to such a statement if the authors and the working group agree to add it, but that's not the question we're asking at the moment.

---

From: Ole Troan <[email-masked]>
Date: Sat, 15 Nov 2014 20:45:25 -0800

Remi,

> If they didn’t, the fact remains, is important, and is also easy to verify.

while you may consider it simple, it took me quite some effort to refresh all the context necessary, thanks for providing the simple explanation of the issue.

you are correct that MAP-T has this issue (or any double translation using RFC6145) including 464XLAT.

> - In any case,  if anyone is crossed by what I said, I apologize for having told, in good faith but too frankly, what I had felt.

not claiming to speak for all the authors here, but I don't think anyone was trying to conceal anything. I think it was more that we didn't feel that the issue was serious enough to warrant not reusing RFC6145 for double translation. (I also think someone did measurements in live networks looking for DF=MF=1 packets and found very few?)

> Yet, IMHO, harm of this warning being absent remains limited enough to be acceptable as long as the status of MAP-T remains Experimental.

we had this exact same discussion 464XLAT, RFC6877. in the end the disclaimer wasn't included in that document.

I agree with you that the issue is worth pointing out though, with f.ex text similar to what was proposed for RFC6877. see:
https://mailarchive.ietf.org/arch/msg/v6ops/66dSxb-i9kjGi1UeySBu5MYAV3w

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Sun, 16 Nov 2014 13:42:55 +0100

Ted, I support the move to PS, and agree with the characterisation you
presented.

Thanks,
Wojciech.

On 11 November 2014 22:11, Ted Lemon <[email-masked]> wrote:

> As we've gotten closer to finally finishing the stateless address-sharing
> suite of softwire specifications, I've had to explain what happened to a
> number of different people, both in the directorates and on the IESG, and
> even to nomcom.  As a consequence I've had to do a lot of thinking about
> why things wound up the way they did, and whether what happened was the
> right outcome.
>
> The three solutions, MAP-E, MAP-T and Lightweight 4over6 actually make a
> lot of sense when presented together.   Because of this there is no reason
> that one should be experimental and the other two standards track.
>
> I would therefore like the working group to consider changing the proposed
> status of MAP-T to Proposed Standard.   I think this would be a less
> confusing outcome.   If the working group agrees, we would go through a
> second IETF last call and then advance the document.
>
> actually is quite different from the other three documents.   This is not
> intended as an editorial comment about 4RD: rather, it's simply that I
> think the three documents together offer a good suite of solutions that can
> be understood and implemented together, whereas 4RD is essentially its own
> solution.   I think the working group has already chosen to advance the
> MAP-style lightweight solutions, and it would actually be confusing to
> advance 4RD as a separate standard solution.
>
> Suresh and Cui Yong will be asking the working group to weigh in on this
> issue, and then assuming no blocking objections are raised we will re-do
> the IETF last call for map-t as a proposed standard.
>
> Thanks!

---

From: Xing Li <[email-masked]>
Date: Sun, 16 Nov 2014 21:47:51 +0800

FYI:

Text from the page 8 of the divi-pd draft (individual submission for the 
stateless double transation, which is renamed to MAP-T, before the WG 
adoption) http://www.ietf.org/archive/id/draft-xli-softwire-divi-pd-01.txt

   Due to the differences between the IPv4 header and the IPv6 header,
   the dual stateless IPv4/IPv6 translation cannot be entirely lossless
   [RFC6145], for example the IPv4 options are lost.  The experimental
   data shows that the IPv4 packets which contain options are very few
   (10e-6) and causes no harm.  Another corner case is the fragmentation
   handling.  For IPv4 packets with DF=1 and MF=1, the dual stateless
   translation will results in DF=0.  The experimental data shows that
   the IPv4 packets with DF=1 and MF=1 are very few (10e-5) and causes
   no harm.

Additional information:

The CERNET BR/CPE code has a configuration  function which has the 
feature of

"For the packets contains DF=1&MF=1, MAP-T MAY encapsulate the packets 
using RFC2473, and this will make MAP-T compatible with ICMP-based PMTU 
discovery."

Frankly speaking, we never turn this option on in the real services, 
since the users cannot tell the difference between on/off of this 
configuration function.

Regards,

xing

.

Rémi Després ??:
> Hi Xing,
>
>
> 15 nov. 2014 12:33, Xing Li <[email-masked] 
> <mailto:[email-masked]>>  :
>
> Showing a statistic where use of MF=DF=1 has been very limited doesn’t 
> change that MF=DF=1 is what is recommended in RFC4821 for deployment 
> of Path MTU Discovery. The RFC does say:
> /"All hosts SHOULD use IPv4 fragmentation in a mode that mimics IPv6 
> functionality.  All fragmentation SHOULD be done on the host, and all 
> IPv4 packets, including fragments, SHOULD have the DF bit set such 
> that they will not be fragmented (again) in the network."/
>
>> and if people really want to address this corner case (DF=1&MF=1), 
>> MAP-E can be used (only for the packets with DF=1&MF=1) without any 
>> problem, as shown  in (the mixed mode)
>>
>> page 6 of 
>> http://www.ietf.org/proceedings/84/slides/slides-84-softwire-5.ppt
>
> Anyway, be it included or not, it remains that any use of MAP-T breaks 
> the DF=MF=1 combination of RFC4821, and therefore ICMP-independent 
> Path MTU discovery.
>
>> Regards,
>>
>> xing
>>
> As already answered to Ted, the PMTU discovery of RFC4821 is precisely 
> that which is designed not to depend on ICMP.

---

From: Rémi Després <[email-masked]>
Date: Sun, 16 Nov 2014 15:51:08 +0100

> If it wasn't a factor in the coin toss, it doesn't have anything to do with the working group's decision to choose Experimental vs. Proposed status.

This was exactly my point.
End of this subject fro me.

> I would not object to such a statement if the authors and the working group agree to add it,

Yes, beyond authors themselves, the WG is concerned in what the RFC will say.
Avoiding such clarification in the RFC after this discussion would amount, IMHO, to consciously withholding useful information. 

> but that's not the question we're asking at the moment.

If the current question is whether an operational limitation exists in MAP-T, which would justify to keep it experimental, the answer is: 
Incompatibility with the only ICMP-independent PMTU discovery in IPv4 (as  specified in standard-track RFC 4821).

Regards,
RD

PS:
Ole Troan just mentioned, rightly, that the 464XLAT of RFC6877 (specified by Behave) had the same limitation.
To be noted:
- RFC6877 explicitly concerns a "technique to quickly deploy limited IPv4 access service" (underline added). Even if what its operational limitations aren’t explained, this is an warning that that some limitation exists.
- Explaining in the RFC what was the known IPv4 service limitation was IMHO a must, and I made the point in Behave. A text proposal for it was proposed by Gang Chen (as referenced by Ole).
- Yet, the WG had a majority vote against such clarification. 
What influenced decision to withhold relevant information is still unclear to me, and IMHO unfortunate.

---

From: Tom Taylor <[email-masked]>
Date: Sun, 16 Nov 2014 10:12:05 -0500

As a WG participant aware of the history of this whole effort, I would 
support adding the statement to MAP-T in particular.

Tom Taylor

---

From: Rémi Després <[email-masked]>
Date: Sun, 16 Nov 2014 17:55:30 +0100

Hi Tom,

If a statement proceeds to be added, I propose something like this in the introduction:

Warning: on paths that traverse MAP-T IPv6 networks, ICMP-independent PathMTU Discovery, as specified in  [RFC 4821], ceases to be reliable. (This is because  DF=1/MF=1 combination, used in [RFC 4821],  becomes DF=0&MF=1 after traversal of a MAP-T network). This specification is for service providers that, being conscious of this limitation, accept it as negligible.

(This is, I believe, more explanatory here than what Gang had proposed in the different context of 464XLAT.)

Regards,
RD 

16 nov. 2014 16:12, Tom Taylor <[email-masked]>  :

> As a WG participant aware of the history of this whole effort, I would support adding the statement to MAP-T in particular.

---

From: Tom Taylor <[email-masked]>
Date: Sun, 16 Nov 2014 16:37:29 -0500

I'd replace "Warning" with the more conventional "Note". I would also 
drop the last sentence on grounds of redundancy. This is NOT a big issue 
as I understand from my reading of various lists, because no one expects 
RFC 4821 discovery to work anyway.

Tom Taylor

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Nov 2014 09:25:17 +0100

16 nov. 2014 22:37, Tom Taylor <[email-masked]> :

> I'd replace "Warning" with the more conventional "Note".

Less explicit, but can be good enough AFAIAC.

> I would also drop the last sentence on grounds of redundancy. This is NOT a big issue as I understand from my reading of various lists, because

> no one expects RFC 4821 discovery to work anyway.

If this is true (which isn’t clear to me at all ) wouldn’t RFC4821 deprecation be the right action?
Without that, considering here, implicitly, that RFC4821 is negligible would be too confusing.

An alternative, to take your point, could be to add "in view of doubts expressed about RFC4821 practicability"  after "negligible".

RD

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Nov 2014 08:45:47 -0500

> An alternative, to take your point, could be to add "in view of doubts expressed about RFC4821 practicability"  after "negligible".

If you want to start the process of deprecating RFC 4821, we could certainly do that.  I don't think it's a requirement for this, though.   We have lots of disused RFCs that have never been deprecated.

---

From: Rémi Després <[email-masked]>
Date: Mon, 17 Nov 2014 16:11:43 +0100

> If you want to start the process of deprecating RFC 4821, we could certainly do that.  I don't think it's a requirement for this, though.   We have lots of disused RFCs that have never been depreca…

1.
- I cited deprecation as the right action only if it is true that " no one expects RFC 4821 discovery to work anyway", and made clear my serious doubt that it it is indeed true).
- BTW, keeping the quoted sentence in your comment would have been appreciated: it was what gave sense to what I said. 
- To be more precise, the reason why RFC4821 does makes sense to me, is that, for hosts that send numerous large UDP datagrams (e.g. for some networked games), it is the only ICMP-independent solution (i.e. practical solution) to avoid excessive network fragmentations. 

2.
I agree that "disused RFCs" are in general not worth spending energy on them.
But a standard-track RFC "no one expects to work"  would be different (IMHO).
It would raise a problem of IETF credibility .

Regards,
RD