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

From: "Mallette, Edwin J." <[email-masked]>
Date: Wed, 12 Nov 2014 21:08:38 +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:

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

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

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

[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 think this would be a less confusing outcome.
>
>Completely opposite view, based on the above.
>
>> 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.
>
>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
>
>
>>
>> Thanks!
>> _______________________________________________
>> Softwires mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/softwires
>
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires

________________________________

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: "Petersen, Matt J" <[email-masked]>
Date: Sat, 15 Nov 2014 09:39:30 -0600

I agree that we should move MAP-T out of experimental to a standard.  We are current looking at deploying
MAP-T in 2015.

Sent from my Verizon Wireless 4GLTE smartphone

----- Reply message -----
From: "Xing Li" <[email-masked]>
To: "Rémi Després" <[email-masked]>
Cc: "Softwires WG" <[email-masked]>, "IESG" <[email-masked]>
Subject: [Softwires] map-t to proposed standard rather than experimental
Date: Sat, Nov 15, 2014 4:34 am

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.

Rémi Després 写道:

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

On Nov 14, 2014, at 12:22 PM, Rémi Després <[email-masked]><mailto:[email-masked]> wrote:

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.

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.

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