Subject: [Softwires] MAP-E&T vs 4rd-U

From: GangChen <[email-masked]>
Date: Tue, 10 Apr 2012 13:35:27 +0800

Hello all,

I have tried to work hard and technically contribute to all documents:
MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also cosigned
with all of them. Please allow me to share some points here.

Basic idea of MAP algorithm were originally built on 4rd and DIVI
(draft-despres-softwire-4rd,draft-murakami-softwire-4rd,
draft-xli-behave-divi, ..). It was improved by design team members and
evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T and
MAP-E. Identical address format is used for -T and -E. Backing to the
earlier version of MAP document, it included all features (e.g.
Checksum-neutrality, Vbit etc.). Some people were in favor of it; some
thought it not key points. For example, CNP is desirable for
translation solution. But it's in some extent against current tunnel
implementation, because encapsulation requires fixed IPv6 address
representing an endpoint depending on tunnel code today. People have
to sacrifice this feature in order to keep the benefits of unified
address format. However, that obviously is of value to transparency.
(PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 Network
Prefix Translation).

4rd-U was trying to keep all merits together considering trade-off
points. It was targeted to be reversible process and full transparency
which I guess is important for a stateless design. Meanwhile, some
additional extensions have to be considered. It's maybe a point to
bring up "endless discussion" on the list.

I agree with what Yiu said it's hard to simply answer YES or NO at
this time. Both solutions deserve spending more time, because these
solutions were born only for half a year. Implementation may need more
time and operation normally will also need to wait.

OTOH, I'm still not fully convinced MAP-E and -T should be treated as
one solution. I like MAP-E or -T to be deployed as a separate
solution. However, coexistence means operators should have double
packages inspection toolkits, double operational rules delivery and
double provisioning costs. In some cases, translation solution is
exclusive to encapsulation (Please see more in
draft-dec-stateless-4v6). Even you can implement in the same box,
that's very inconvenient for operation and subscriber. According
RFC6180, it is fundamental two different solution.

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 09:31:38 +0200

Le 2012-04-10 à 07:35, GangChen a écrit :

> solutions were born only for half a year.

+1

> Implementation may need more
> one solution.

+1
(They were previously considered to be two distinct candidates for standard track.)  

> I like MAP-E or -T to be deployed as a separate
> that's very inconvenient for operation and subscriber.

+1 
With MAP-T+E, subscribers wouldn't have the same service depending on which specification their local operator has chosen, with subtle differences they shouldn't be concerned with.

RD

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

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 10 Apr 2012 09:38:00 +0200

> RFC6180, it is fundamental two different solution.

Hi,

I see MAP-E/T combo as one solution, where you "turn the knob" when 
implementing it - you choose encap *or* translation mode. Whichever mode 
you choose, there is no sign of the other anymore.

Cheers, Jan

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 10 Apr 2012 09:59:03 +0200

On 10 April 2012 09:31, Rémi Després <[email-masked]> wrote:

> With MAP-T+E, subscribers wouldn't have the same service depending on
> which specification their local operator has chosen, with subtle
> differences they shouldn't be concerned with.
>

The service would be the same. Note: NAT64 based services are a reality
today, and although you may think differently, no operator calls "checksum
neutrality" a service (with this apparently being the main feature of
4rd-u).
What more, given that 4rd-U needs to be combined with BIH, the claim of it
offering some "unified" solution, different operationally from MAP is
bogus. If anything this combination and the fact that there is a IPv6.1
being created actually makes 4rd-u operations a major challenge in
comparison to what we know of as IPinIP tunnelling or NAT64 with MAP.

Remi, at one point you stated publicly that you would withdraw 4rd-u should
it not gain WG consensus. You also chose to quit the MAP design team, where
your proposals failed to get consensus. At this stage it appears that not
only you are not intending to honour you public statement, but also in
general disputing the process of establishing consensus in the WG. One is
tempted to see it that no consensus other than "consensus on your terms" is
what you really want, and those terms change with each new draft revision.
Perhaps its time for draft 4rd-X in a new WG...

-Woj.

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Tue, 10 Apr 2012 08:01:39 +0000

Hi Jan,
 
  ISPs can't deploy MAP-E/T and use the two mechanism to transmit IPv4 traffic in their network at the same time. 
  So I aggree with Gang that MAP-E and MAP-T should be treated as separate solutions.

 BR 
 Yu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jan Zorz @ go6.si
Sent: Tuesday, April 10, 2012 3:38 PM
To: [email-masked]
Subject: Re: [Softwires] MAP-E&T vs 4rd-U

Hi,

Cheers, Jan

---

From: GangChen <[email-masked]>
Date: Tue, 10 Apr 2012 16:21:48 +0800

Hello Jan,

> you choose, there is no sign of the other anymore.

You could combo 100 solultions as you want. However, that is still
seems to me separated solutions. This recalls me 6204bits recommended
6rd and DS-Lite for IPv6 CPE. I prefer to understand that are two
solutions, even you can combo them together?

BTW, this combo thing is not only CE business, but also corresponding
complexity on network sides. As I mentioned above it requires double
efforts to operators.

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 10:23:36 +0200

Le 2012-04-10 à 09:59, Wojciech Dec a écrit :

> The service would be the same. Note: NAT64 based services are a reality today, and although you may think differently, no operator calls "checksum neutrality" a service (with this apparently being the main feature of 4rd-u). 

Please avoid inventing my thoughts to then criticize them.
The key service offered by 4rd-U is complete IPv4 transparency (a MAP-E property) combined with compatibility with IPv6-only O&M-tools (a MAP-T property). Checksum neutrality is just a tool.

> What more, given that 4rd-U needs to be combined with BIH, the claim of it offering some "unified" solution, different operationally from MAP is bogus. If anything this combination and the fact that there is a IPv6.1 being created actually makes 4rd-u operations a major challenge in comparison to what we know of as IPinIP tunnelling or NAT64 with MAP.

The need for an IPv6 6.1 is AFAIK an invention of yours, not something needed by 4rd-U.

> Remi, at one point you stated publicly that you would withdraw 4rd-u should it not gain WG consensus.

(*) I said, and confirm, that my personal work is to achieve a single standard, not to have 3.  
My appreciation is that 4rd-U is more than ever the best candidate for this since the idea of having only MAP-T OR MAP-E on standard track has ben abandoned. 
 
> You also chose to quit the MAP design team, where your proposals failed to get consensus.

Conditions in which the 4rd-U approach has been rejected, in an improvised meeting in Taipei, has already been commented.

There has been after that no alternative to a separate work, approved by the chair. 
result is the self contained and complete 4rd-U specification, which, despite aggressive comments made on the list and in meetings, has already arisen substantial interest in the WG.
 
> At this stage it appears that not only you are not intending to honour you public statement,

See (*) above.

> but also in general disputing the process of establishing consensus in the WG. One is tempted to see it that no consensus other than "consensus on your terms" is what you really want, and those terms change with each new draft revision.

???

> Perhaps its time for draft 4rd-X in a new WG...

???

RD

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 10 Apr 2012 11:21:44 +0200

On 10 April 2012 10:23, Rémi Després <[email-masked]> wrote:

> The key service offered by 4rd-U is complete IPv4 transparency (a MAP-E
> property) combined with compatibility with IPv6-only O&M-tools (a MAP-T
> property). Checksum neutrality is just a tool.
>

That is not a service as an operator would typically see it. In any case,
there is nothing preventing MAP from supporting the purported IPv4
transparency, but so far there has been no consensus that this is actually
desirable, or worthwhile.

> The need for an IPv6 6.1 is AFAIK an invention of yours, not something

 4rd-u does change the basic semantics of fields in IPv6, and that is not
my invention.

> My appreciation is that 4rd-U is more than ever the best candidate for
> this since the idea of having only MAP-T OR MAP-E on standard track has ben
> abandoned.
>

4rd-u requires coupling with BIH, so it's not a single standard by any
means (not to mention the changes to IPv6).

> Conditions in which the 4rd-U approach has been rejected, in an improvised
> meeting in Taipei, has already been commented.
>

The design team worked on the principles of common consensus and seeking
compromise in an effort to create a solution that addressed the core
problems and the agreement of the Beijing meeting in a timely manner.
Concepts that are apparently foreign to those who choose first to work on
the design team and then abandoned the team to seek the personal
advancement of their own solution.
As mentioned, forming a new WG for 4rd-X, if not actually an RD WG, is a
worthy idea that should be considered, allowing the rest of the world to
proceed with getting things done.

-Woj.

> result is the self contained and complete 4rd-U specification, which,
> despite aggressive comments made on the list and in meetings, has already
> arisen substantial interest in the WG.
>
>

> but also in general disputing the process of establishing consensus in the
> WG. One is tempted to see it that no consensus other than "consensus on
> your terms" is what you really want, and those terms change with each new
> draft revision.
>
>
> ???
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 11:35:04 +0200

Le 2012-04-10 à 11:21, Wojciech Dec a écrit :

> That is not a service as an operator would typically see it. In any case, there is nothing preventing MAP from supporting the purported IPv4 transparency, but so far there has been no consensus that this is actually desirable, or worthwhile.
>  
> 
>  4rd-u does change the basic semantics of fields in IPv6,

???
(If you would have evidence that everything isn't backward compatible, please share this information.)

> and that is not my invention.
> 
> 
> 4rd-u requires coupling with BIH, so it's not a single standard by any means (not to mention the changes to IPv6).

4rd-U is is a Softwire solution (IPv4 via IPv6).
IPv4-only to IPv6-only communication is a different subject, already covered by a standard-track RFC.
If there are criticisms of this existing RFC, they belong to a different forum.

RD

> The design team worked on the principles of common consensus and seeking compromise in an effort to create a solution that addressed the core problems and the agreement of the Beijing meeting in a timely manner. Concepts that are apparently foreign to those who choose first to work on the design team and then abandoned the team to seek the personal advancement of their own solution.
> As mentioned, forming a new WG for 4rd-X, if not actually an RD WG, is a worthy idea that should be considered, allowing the rest of the world to proceed with getting things done.
> 
> -Woj.
>  
>

---

From: Alain Durand <[email-masked]>
Date: Tue, 10 Apr 2012 05:18:30 -0700

Remi, Woj:

We have heard a number of times that you both think the "other" solution is broken. Technical points have been made, no need for personal attacks.

I'm getting concerned that the working group is losing sight of the very reason why we participate to the IETF; to promote good standards, not to fight endlessly about which of the two or three solutions we have on the table (and that are 99% identical) is more "pure". Standardizing is about finding common ground, not about ego, fighting for whose name is on the draft, character assassination, using disparaging language, threatening appeals, boycotting, or ballot stuffing.

Alain, wg-co-chair.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Apr 2012 09:07:49 -0400

On 2012-04-10 04:21, GangChen wrote:
>> implementing it - you choose encap *or* translation mode.
>
> seems to me separated solutions.

+1

 From a deployment point of view, it makes no sense to treat them as 
one. You would need to evaluate T and E separately for *everything*: 
routers, provisioning, customer equipment, accounting, etc. So it makes 
no sense to treat T and E as a single protocol.

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

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 15:12:33 +0200

Hi, Alain,

2012-04-10 14:18, Alain Durand:

> Remi, Woj:
> 
> We have heard a number of times that you both think the "other" solution is broken.

> Technical points have been made,

Exchanging real technical points with Maoke isn't finished (he just posted a new draft about 4rd-U).
Since this has been productive so far (despite some heat from time to time), clarifying the last points which we understand differently is useful (IMHO).

> no need for personal attacks.

I don't recognize myself in this one (at least as the initiator).

> I'm getting concerned that the working group is losing sight of the very reason why we participate to the IETF; to promote good standards, not to fight endlessly about which of the two or three solutions we have on the table (and that are 99% identical) is more "pure". Standardizing is about finding common ground, not about ego,

> fighting for whose name is on the draft, character assassination, using disparaging language,

Neither in this one.

> threatening appeals,

Feeling concerned with this one.
However, exercising an appeal if found appropriate is each one's prerogative, and can sometimes be a duty.
Sincerely hope to have no need for that.

> boycotting,

Feeling concerned with this one too.
However, the fact is that, personally, I cannot answer YES and cannot answer NO either:
- Now convinced that either MAP-T+E or 4rd-U on standard track is premature, I can't answer YES.
- Also convinced that both on standard track would be a mistake, I can't vote NO.  

> or ballot stuffing.

The proportion of this is well beyond what I thought was predictable.

Please be sure that all these efforts of mine are for the best of standardization.

Regards,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 10 Apr 2012 16:49:20 +0200

For some reason, it's also forgotten that WG adoption does not equate to a
WG last call...
It has been said several times that several of the 4rd-u features can be
accommodated by the MAP spec should these ever be consented to by the WG as
necessary.
Candidly, however these technical matters appear to be secondary, as they
were on the MAP design team, and the circus on the matter is more about the
ego of an individual and his style of collaboration, including also the
name of the draft.

There likely is no better way to end this than to get the WG to adopt a
solution that not only has considerable support but also several trial
implementations, and let it progress as a standards track WG document
capturing consented WG feedback as it does so. This is indeed a basis of
standardization.

My 2c.

2012/4/10 Alain Durand <[email-masked]>

> Remi, Woj:
>
> We have heard a number of times that you both think the "other" solution
> is broken. Technical points have been made, no need for personal attacks.
>
> I'm getting concerned that the working group is losing sight of the very
> reason why we participate to the IETF; to promote good standards, not to
> fight endlessly about which of the two or three solutions we have on the
> table (and that are 99% identical) is more "pure". Standardizing is about
> finding common ground, not about ego, fighting for whose name is on the
> draft, character assassination, using disparaging language, threatening
> appeals, boycotting, or ballot stuffing.
>
> Alain, wg-co-chair.
>

---

From: Alain Durand <[email-masked]>
Date: Tue, 10 Apr 2012 08:01:37 -0700

On Apr 10, 2012, at 10:49 AM, Wojciech Dec wrote:

> For some reason, it's also forgotten that WG adoption does not equate to a WG last call...

Very good point, and thank you for raising it.
If this wg succeed in deciding which document (or document set) to put on standard track, that is not the end of the road.
It just means that these document(s) will be adopted as working group item(s) and will have to evolve to take  into consideration
working group input (as opposed to  design team  input). These documents will then have to mature to the point where
we, as a wg, feel comfortable we can have a working group last call.

Alain.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Apr 2012 11:28:38 -0500

> I'm getting concerned that the working group is losing sight of the very reason why we participate to the IETF; to promote good standards, not to fight endlessly about which of the two or three sol…

+1.

Why don't we ask Remi and Ole to come together and come up with a
"unified" solution and do that in one week?

They both leave in Europe and can even arrange f2f meetings.

Behcet

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 10 Apr 2012 18:54:01 +0200

> They both leave in Europe and can even arrange f2f meetings.

-1
That, at best will only get a solution that truly nobody understands. We
need solutions that work, solve problems and can get into products in a
timely manner, not an endless stream of rehashed "unified" drafts.

-Woj.

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 10 Apr 2012 21:55:03 +0200

On 4/10/12 10:01 AM, Fuyu (Eleven) wrote:
> Hi Jan,
>
> ISPs can't deploy MAP-E/T and use the two mechanism to transmit IPv4
> traffic in their network at the same time. So I aggree with Gang that
> MAP-E and MAP-T should be treated as separate solutions.

Dear Fuyu.

Please read my message again and try to parse it correctly.

What you understood is not what I said.

Cheers, Jan Zorz

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 10 Apr 2012 21:56:24 +0200

On 4/10/12 2:18 PM, Alain Durand wrote:
> Remi, Woj:
>
> We have heard a number of times that you both think the "other"
> solution is broken. Technical points have been made, no need for
> personal attacks.
>
> I'm getting concerned that the working group is losing sight of the
> very reason why we participate to the IETF; to promote good
> standards, not to fight endlessly about which of the two or three
> solutions we have on the table (and that are 99% identical) is more
> "pure". Standardizing is about finding common ground, not about ego,
> fighting for whose name is on the draft, character assassination,
> using disparaging language, threatening appeals, boycotting, or
> ballot stuffing.

+1

Too much repeating noise on the ml. lately :)

Cheers, Jan

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 10 Apr 2012 19:57:26 +0000

+1. 

If the WG decided to standardize both MAP-T and MAT-E, there would be two
standards. Operators still needed to make the choice between them.

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 10 Apr 2012 20:50:42 +0000

Hi Remi,

???

For example, the existing implementation for processing the fragment header is not working on your definition of the fragment header. MAP-E/T does not require any change of existing process of IPv6 header.

Thanks,
Tetsuya Murakami