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

From: Alain Durand <[email-masked]>
Date: Mon, 19 Mar 2012 16:38:42 -0700

Dear wg,

After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, T & U actually solve the stateless  problem we started with.
    There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation
    proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those
    documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T & U).
Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation.

Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to?

If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market.
If the answer is YES, we move to the next question.

Q2: Do you believe that the WG should publish U as the one Standards Track document?

If the answer is YES, the process stop, we put U on the Standard Track and publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be abandoned or published as Historical/Informational)

Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)?

If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both E & T as Experimental.

In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other.

  Alain & Yong, wg co-chairs.

---

From: Xing Li <[email-masked]>
Date: Wed, 21 Mar 2012 21:39:07 +0800

Hi, Alain, Yong and Ralph,

The newly posted agenda does not match the consensus as you mentioned on 
6 Oct 2011, that “multiple address and port mapping technologies could 
and should converge” and you formally announced “the creation of the MAP 
(Mapping of Addresses and Ports) design team”, a design team which “is 
tasked to formulate a unified format to be used either in an 
encapsulation or double translation mode” 
(http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). 
For the past few months, the design team has produced a series of MAP 
documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list 
has also showed positive feedback on the adoption of the MAP series as 
the standard track of working group documents. Moreover, the dIVI (an 
earlier version of MAP-T) has been running successfuly at CERNET2 for 
two years now.

4rd-U was submitted later, and the goal is to replace the MAP Series. 
There have been discussions in the mailing list, but the discussions are 
mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still 
in the early design stage. Due to its proposed modification of the IPv6 
architecture (V-Oct and the fragmentation header), the discussion should 
be extended at least to 6man WG before the Softwire WG makes any 
decision of adoption. Furthermore, experimental data should be presented 
to the WG to show that these modifications are not harmful. In addition, 
the fragmentation header modifications actually only deal with a very 
corner case of double translation (10e-5% of the packets, not production 
traffic).

Therefore, I don’t think we have any reason to change the procedure and 
in the coming meeting, we should discuss whether consensus can be 
reached for the adoption of the MAP series. We should discuss whether 
4rd-U can be adopted in a later meeting when it gets proved by 6man and 
its modifications are proved to be not harmful by experimental data.

Regards,

xing

? 2012/3/20 7:38, Alain Durand ??:
> 1) There  is an observation that all the solutions on the table E, T&  U actually solve the stateless  problem we started with.
> We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T&  U).
> If the answer is YES, the process stop, we put U on the Standard Track and publish E&  T as Informational.
> If the answer is NO, we are left with E&  T (U then might be abandoned or published as Historical/Informational)
>
>
> If there is no clear consensus on this question, we will publish both E&  T as Experimental.
>
>    Alain&  Yong, wg co-chairs.
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 22 Mar 2012 14:32:36 +0100

Hello Chairs, all

In essence, while at a very high level all solutions appear to solve a
common problem, just like all ducks look the same, some solve extra
problems that are of critical importance to some operators, this forms the
basis for the different approaches, and what led to the MAP draft set, and
in that set there is no way to "sqaure the circle"
The "hybrid solution" also does not "square the circle", and what more
raises several technical questions, besides lacking the trial
implementation & experience factor that MAP's constituents have shown - it
thus appears to be in a different, rather experimental, league .

Respectfully thus, the view presented under item 1) below and ultimately
the questions appear set to cause further thrashing of arguments all over
again. All this going a long way off from actually progressing the
development of solutions that solve problems the WG cares about and under
majority consensus if universal consensus is not possible.

As a way forward I would suggest a much simpler approach that is more
likely to result in some progress, with the following questions being asked:
1. Should MAP (all MAP drafts) be adopted as WG drafts all on Informational
track?
2. Should 4rd-u as WG draft on the Experimental or Informational track, if
shown to be in line with existing specs.

Along with an acceptance of any/all of the above, there should be a charter
clause indicating that one, or all of these drafts can be moved to a
Standards track following WG consensus, without altering the status of the
others, unless similarly consented.

Regards,
Wojciech.

On 20 March 2012 00:38, Alain Durand <[email-masked]> wrote:

> Dear wg,
>
> After a number of discussions with my co-chair, our AD and various
> authors, here is how we would like to move forward wrt 4rd.
>
> 1) There  is an observation that all the solutions on the table E, T & U
> actually solve the stateless  problem we started with.
>    There are differences, but it is unclear if those differences are
> really significant. E and T are the original Encapsulation and Translation
> 2) We have already agreed back in Beijing that we would publish all
> necessary documents. The issue here is the 'label' or 'status' those
>    documents have at IETF. In particular, do we want to publish them as
> Experimental, Informational or Standard Track.
>
> We are at the point now where we need to make progress. In Paris, we would
> like to ask for presentations from the proponents of each candidate
> solution (E, T & U).
> Each presentation should cover an overview of the proposed solution,
> explain how it compares to the others and make a case as why it should be
> the one on the Standard Track. We will allocate 20 minutes for each
> presentation.
>
> Then, we, chairs, would like to ask a series of questions to the working
> group. In order to make this process transparent, here is the list of
> questions we want to ask
> and their sequence.
>
> Q1: Without pre-supposing which one will be selected, do you agree to
> publish 1 of the 3 proposals on the Standard Track and publish the other(s)
> as Informational if still asked to?
>
> If the answer is NO, then the process stops and we will publish everything
> as Experimental and come back in 12-24 months to see what gets adopted by
> the market.
> If there is a clear outcome from this question, we would publish that
> proposal on the Standard Track and the other one as Informational.
> In the meantime, we would like to encourage discussion on the mailing list
> to foster our common understanding of the various technologies and how they
> relate to each other.
>

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Thu, 22 Mar 2012 14:53:59 +0100

On 3/20/12 12:38 AM, Alain Durand wrote:
> publish 1 of the 3 proposals on the Standard Track and publish the
> other(s) as Informational if still asked to?
>
> If the answer is NO, then the process stops and we will publish
> everything as Experimental and come back in 12-24 months to see what
> gets adopted by the market. If the answer is YES, we move to the next
> question.

Hi,

I'm not really happy with this decision.

RFC 6346 Stateless A+P (a.k.a. 4rd/MAP) world is polarized in 
encapsulation and translation part. MAP-U is brave attempt to unify both 
worlds, but I;m not sure all the best parts from both world ended up in 
-U proposal and that result is what I would like to see in reality.

Coming from operational ISP world, where this stuff will actually be 
implemented in reality, I would suggest to publish -E and -T as 
documents in standards track - and -U as experimental or informational.

What I would like to see as network architect is that vendors deploys -E 
and -T in the same product named 4RD and operator can choose operating 
mode when implementing the solution - deciding between encapsulation or 
translation at will.

This way this working group work and effort would become useful for 
operations.

Cheers and see you in few days,

Jan Zorz
Go6 Institute Slovenia

---

From: Zhankao WEN <[email-masked]>
Date: Thu, 22 Mar 2012 22:07:53 +0800 (CST)

+1, support

Best regards
--
Name:    Zhankao WEN(温占考)
Email:   [email-masked]
         [email-masked]
Tel&Fax: +86-24-83687240
Address: Networking Center Northeastern University
         Shenyang Liaoning Province P.R. China (110819)

----- Original Message -----
From: "Xing Li" <[email-masked]>
To: "Alain Durand" <[email-masked]>
Cc: "Softwires WG" <[email-masked]>, "Yong Cui" <[email-masked]>, "Ralph Droms" <[email-masked]>
Sent: Wednesday, 21 March, 2012 9:39:07 PM
Subject: Re: [Softwires] Path to move forward with 4rd…

The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that “multiple address and port mapping technologies could and should converge” and you formally announced “the creation of the MAP (Mapping of Addresses and Ports) design team”, a design team which “is tasked to formulate a unified format to be used either in an encapsulation or double translation mode” ( http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html ). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now. 

4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic). 

Therefore, I don’t think we have any reason to change the procedure and in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data. 

Regards, 

xing 

于 2012/3/20 7:38, Alain Durand 写道: 

Dear wg,

  Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing list [email-masked] https://www.ietf.org/mailman/listinfo/softwires

---

From: Rajiv Asati <[email-masked]>
Date: Thu, 22 Mar 2012 10:23:25 -0400

I am disappointed with this approach.

Despite the support, the WG adoption of MAP documents has been delayed for
a "label" reason. I find it unfair since the label can be changed any time
until the IESG review. How can it be a hold-up?

One would have to wonder the intent of forming the design team at first
place. It seems that we keep putting roadblocks on the path for the
stateless solutions to get standardized. One after another. What's the
purpose?   

It seems that the work done by the design team, which was formed for a
reason, is being ignored. If not, then their documents would have been the
WG documents by now and the email would be referring to MAP (and not 4rd).
This is a bit disrespectful.

I would suggest to put all the documents developed by the MAP design team
as "Standards" track document, and anything else is up for discussion.

Cheers,
Rajiv

-----Original Message-----
From: Alain Durand <[email-masked]>
Date: Mon, 19 Mar 2012 16:38:42 -0700
To: Softwires WG <[email-masked]>
Cc: Yong Cui <[email-masked]>, Ralph Droms <[email-masked]>
Subject: [Softwires] Path to move forward with 4rdŠ

>We are at the point now where we need to make progress. In Paris, we
>would like to ask for presentations from the proponents of each candidate
>solution (E, T & U).
>everything as Experimental and come back in 12-24 months to see what gets
>adopted by the market.
>In the meantime, we would like to encourage discussion on the mailing
>list to foster our common understanding of the various technologies and
>how they relate to each other.
>

---

From: Maoke <[email-masked]>
Date: Thu, 22 Mar 2012 14:40:11 +0000

dear Alain, Yong, Ralph and all,

in program, the effort of the MAP team should be respected. The formation
of the MAP team was also the consensus of our meeting in beijing and we
have seen the the team is working with clear progress. I don't think it is
correct now to insert 4rd-u into a sort of exclusive decision of choice.
And 4rd-u also has the address format elements abondoned by the MAP design
team. I believe the MAP format reflects that the common understanding
concludes the insignificance of those features. Sorry but the chair's
questions  a little confused me: if we need to go back to the stage before
the works of the MAP design team?

The MAP series have reached running codes and the collective understanding
of the community. From a view of a middle-sized ISP and cloud service
provider, we do support to accept MAP series into standard track in order
we can utilize it into business as soon as possible.

in technology, first of all, MAP now has approached address mapping
algorithm and that enough to make the series a unified solution. In our
practice, we need to use either encapsulation or translation according to
the actual needs and environment. The most important is, both the building
blocks of transition architecture: virtual link (supported by
encapsulation/tunneling) and participant of the delivery path (supported by
translation), have their suitable use cases. And their advantages and
limitations have been well investigated and understood by the community.

second, i deeply discussed and explored 4rd-u, but i found its attempting
of mixing the tunneling and translation, if accepted as standard, may trap
the operators into a harsh situation of being unable to define what
building block it really is. It is stated as tunneling but actually behaves
like tunnel in some aspects while like translation in some other aspects.
(I have pointed out in the 4rd-u discussion thread). We see it only a
yet-another-translation that try to solve some corner problems but
introduces new, possibly major flaws (also pointed out in the technical
threads on 4rd.) In either the term of architectural philosophy or
technical details, introducing 4rd-u into standards would be harmful.

personally, i respect the exploration of the author(s), and the discussion
between me and the author encouraged me to comprehensively review E and T,
and the result is: i bacame much more confident of the correctness of the
MAP track. We should move forward.

regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP are
of a whole suite needing to be put into standard track. Question is not
about T, E or U.

best regards,
Maoke

在 2012年3月20日星期二，Alain Durand 写道：

> [email-masked] <javascript:;>

---

From: "Shu Wang (shuwang)" <[email-masked]>
Date: Fri, 23 Mar 2012 00:07:55 +0800

Fully agree with Maoke. From operation point of view, 4rd-u has too many issues. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Maoke
Sent: 2012年3月22日 22:40
To: Alain Durand
Cc: Softwires WG; Yong Cui; Ralph Droms (rdroms)
Subject: Re: [Softwires] Path to move forward with 4rd…

in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions  a little confused me: if we need to go back to the stage before the works of the MAP design team?  

The MAP series have reached running codes and the collective understanding of the community. From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. 

in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment. The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community. 

second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing the tunneling and translation, if accepted as standard, may trap the operators into a harsh situation of being unable to define what building block it really is. It is stated as tunneling but actually behaves like tunnel in some aspects while like translation in some other aspects. (I have pointed out in the 4rd-u discussion thread). We see it only a yet-another-translation that try to solve some corner problems but introduces new, possibly major flaws (also pointed out in the technical threads on 4rd.) In either the term of architectural philosophy or technical details, introducing 4rd-u into standards would be harmful. 

personally, i respect the exploration of the author(s), and the discussion between me and the author encouraged me to comprehensively review E and T, and the result is: i bacame much more confident of the correctness of the MAP track. We should move forward. 

regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be put into standard track. Question is not about T, E or U. 

best regards,

Maoke

Dear wg,

---

From: Ole Trøan <[email-masked]>
Date: Fri, 23 Mar 2012 10:46:27 +0100

Alain, et al,

we have been at an impasse, so thank you very much for proposing a path forward.

>    proposals, U is an hybrid unifying solution.

I do agree with that. the Venn diagram for the three solutions would look awfully similar to a single circle. ;-)
there are some use cases though, that can only be fulfilled with one mode of transport versus the other.
I left the interim meeting in Beijing having been convinced that there are use cases requiring both encapsulation and requiring translation. if we for a moment accept that, I would suggest that we treat MAP as one single solution. it will have two options/flavours of transport.

> If there is no clear consensus on this question, we will publish both E & T as Experimental.

with the above proposal, we can drop question 3.

> In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other.

can ask the chairs to take a hum of how many would want t-shirts for the meeting with: "Just pick one for F's sake and stop arguing". ;-)

cheers,
Ole

---

From: <[email-masked]>
Date: Fri, 23 Mar 2012 11:13:02 +0100

Dear WG members,

I didn't had time to read the last version of 4rd-U but I read carefully -03 when it was published. 

I really appreciated the work done by Rémi to write down -03. The document is well written, easy to read and the requirements are clearly sketched. I really think this spirit should be adopted by MAP documents.

As I already told Rémi, I would like if all proponents of stateless A+P converge and avoid wasting energies in comparing individual proposals. I thought this is what has been agreed during the softwire interim meeting: IMO, MAP effort meets the objective of group work.

Some of the points raised by Rémi can be easily considered in the context of MAP; except the idea of unified header which is a step forward. Adopt a unified approach is exclusive to encapsulation and/or translation. 

The question now is: Does the unified approach bring new features + simplification compared to the normal IPv4-in-IPv6 encapsulation scheme (which I'm mainly interested in)? The answer is: No. 

Perhaps this is selfish but given what I mentioned above, I vote for the following:

* Adopt the work of the MAP design team as the base specification for stateless A+P effort.

* Make sure proposals from Rémi (except U) are discussed: e.g., Checksum neutrality
(1) Share the archives of MAP Design Team discussion
(2) Use IETF Issue Tracker to record the issues and the consensus/conclusion
(3) Adopt a clear procedure within the Design Team to make decisions when there are conflicts

* Reduce the amount of MAP documents: IMHO, three documents are needed
(1) MAP Address Format
(2) MAP Overall Architecture and Design Recommendations
(3) MAP DHCPv6 Options

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Alain Durand
>Envoyé : mardi 20 mars 2012 00:39
>À : Softwires WG
>Cc : Yong Cui; Ralph Droms
>Objet : [Softwires] Path to move forward with 4rd.
>
>Dear wg,
>
>After a number of discussions with my co-chair, our AD and 
>various authors, here is how we would like to move forward wrt 4rd.
>
>1) There  is an observation that all the solutions on the 
>table E, T & U actually solve the stateless  problem we started with.
>    There are differences, but it is unclear if those 
>differences are really significant. E and T are the original 
>Encapsulation and Translation
>2) We have already agreed back in Beijing that we would 
>publish all necessary documents. The issue here is the 'label' 
>or 'status' those
>    documents have at IETF. In particular, do we want to 
>publish them as Experimental, Informational or Standard Track.
>
>We are at the point now where we need to make progress. In 
>Paris, we would like to ask for presentations from the 
>proponents of each candidate solution (E, T & U).
>Each presentation should cover an overview of the proposed 
>solution, explain how it compares to the others and make a 
>case as why it should be the one on the Standard Track. We 
>will allocate 20 minutes for each presentation.
>
>Then, we, chairs, would like to ask a series of questions to 
>the working group. In order to make this process transparent, 
>here is the list of questions we want to ask
>and their sequence.
>
>Q1: Without pre-supposing which one will be selected, do you 
>agree to publish 1 of the 3 proposals on the Standard Track 
>and publish the other(s) as Informational if still asked to?
>
>If the answer is NO, then the process stops and we will 
>publish everything as Experimental and come back in 12-24 
>months to see what gets adopted by the market.
>If the answer is YES, the process stop, we put U on the 
>Standard Track and publish E & T as Informational.
>If the answer is NO, we are left with E & T (U then might be 
>abandoned or published as Historical/Informational)
>
>
>Q3: Which of E and T do you want to see moving on the standard 
>track (you can only express support for one)?
>
>If there is a clear outcome from this question, we would 
>publish that proposal on the Standard Track and the other one 
>as Informational.
>In the meantime, we would like to encourage discussion on the 
>mailing list to foster our common understanding of the various 
>technologies and how they relate to each other.
>

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 14:51:05 +0100

> I didn't had time to read the last version of 4rd-U but I read carefully -03 when it was published. 

Note that -04 and -05 are significantly improved.
Expertise of its now co-authors include broadband and mobile services as ell as product vendors.

AFAIK, no reason why it wouldn't work, or do less than claimed, remained unanswered.
If later on a flaw or uncertainty is identified, and confirmed after discussion, this will be fairly acknowledged.

> * Make sure proposals from Rémi (except U) are discussed:

This may be taken as  "I don't care how many designs are standardized... provided my use case is covered by one of them". 
This is not AFAIK the best approach to simplify standards we make for the future.

The chair encouraged further work on U after IETF 82 after arguments used to exclude it in Taipei were acknowledged to be invalid. 
Excluding to discuss U although  it provides a unified design, with more operational features than either T or E, seems to me difficult to justify.

Regards,
RD

> e.g., Checksum neutrality

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 17:11:43 +0100

Le 2012-03-22 à 15:40, Maoke a écrit :

> The MAP series have reached running codes

> and the collective understanding of the community.

Here are some issues among those remaining before reaching "collective understanding":
a) T operation in hub&spoke (hasn't been so far answered in an understandable way).
b) IDs from shared-address CEs.  T currently has so far no solution while both U and E include one. 
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 ..."  
d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp.

The fact that no-one involved in the MAP design raised any of these issues is AFAIK sign that MAP has NOT reached "collective understanding of the community".
(Note that, concerning stateless v4/v6 solutions, I think I should be considered part of this community. Right? ).

Maoke, clarifications on these points will be welcome.

> From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. 
> 
> in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment.

Note: This excludes ISPs that would like to offer full IPv4 transparency with some IPv6-only middles boxes.
Right?

> The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community. 
> 
> second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing the tunneling and translation, if accepted as standard, may trap the operators into a harsh situation of being unable to define what building block it really is.

Such an operator would know it uses 4rd-U. 
This doesn't seem to justify any FUD from co-authors from broadband and mobile operators (or from product vendors).

> It is stated as tunneling but actually behaves like tunnel in some aspects while like translation in some other aspects.

Yes indeed, thus achieving the best of both worlds without making it more complex. Actually making it clearly less complex than supporting both T and E.

> (I have pointed out in the 4rd-u discussion thread).

> We see it only a yet-another-translation that try to solve some corner problems but introduces new, possibly major flaws (also pointed out in the technical threads on 4rd.)

"Possibly major flaws" isn't an identified point on which U would do less than what it has been designed to do (unified replacement of T + E).

IMPORTANT:  
- The essential characterization of U (vs T and E) is its Reversible header mapping (as replacement of both Double RFC6145 translation and Encapsulation).
- Other features of U that differ from MAP (V-octet, CNP), or are complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this respect. Each of these features could be abandoned in U, or, if the WG appreciates what they offer, added to MAP.
- For this, community acceptance to listen to explanations, would be the normal process. I will be available this week for this.

Cheers,
RD

> In either the term of architectural philosophy or technical details, introducing 4rd-u into standards would be harmful. 
>

---

From: Maoke <[email-masked]>
Date: Sun, 25 Mar 2012 12:34:26 +0900

dear Remi,
2012/3/24 Rémi Després <[email-masked]>

> Here are some issues among those remaining before reaching "collective

some issues remaining not yet reaching collective undertanding is not a
reason of making things over. the collective understanding has been reached
for the major part of the
1) MAP address format and the corresponding algorithms
2) encapsulation and translation modes being supported by MAP format and
the existing header processing standards
3) DHCP extensions as a way of distributing rules.

the above big picture are what i call "collective understanding". the
correct way is: making these already gained approaches as bases, continuing
discussion or even dabate on the details. i don't think it is a correct way
of action to disrespect a team's work. 4rd-u's problem is even its big
picture is still fuzzy.

> a) T operation in hub&spoke (hasn't been so far answered in an

i doubt i understand what you mean. may you please specify the question in
details?

> both U and E include one.

what do you mean with the IDs? or do you mean interface IDs? i don't see
"IDs from shared-address CEs" in U too. please teach!

>
> 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. but it doesn't mean one doc is definitely reflecting "collective
understanding" better than multiple.

>
> d) Whether T can work with a single mapping rule (as was, I think, the
> case for IVI). So far DMR and BMR seem exclusive, and there is no way to
> distinguish them in MAP-dhcp.
>
>

single mapping rule for a domain != single mapping rule for the IPv4 world.
the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't
need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and
BMR being exclusive is a problem.

>
> The fact that no-one involved in the MAP design raised any of these issues
> is AFAIK sign that MAP has NOT reached "collective understanding of the
> community".
> (Note that, concerning stateless v4/v6 solutions, I think I should be
> considered part of this community. Right? ).
>
>

well, "collective understanding" was mentioned by Sally Floyd to the
community of Internet researchers, and i borrowed her term. but i
understand: no matter it is research or engineering, collective
understanding is the understanding on the problems and the architecture
rather than the detailed technical solutions. the MAP architecture has been
reflected in the works of the draft suite. on the other hand, the community
is not the softwires wg but the whole Internet engineering circle.

> From a view of a middle-sized ISP and cloud service provider, we do
> support to accept MAP series into standard track in order we can utilize it
> into business as soon as possible.
>
> the actual needs and environment.
>
>

i cannot follow your "full IPv4 transparency" with "some" IPv6-only middle
boxes. what does the "transparency" mean for the middle boxes? i
understand, when we talk about the Internet transparency, we refer to the
"end-to-end transparency". please specify your question concretely.

>
>
> The most important is, both the building blocks of transition
> architecture: virtual link (supported by encapsulation/tunneling) and
> participant of the delivery path (supported by translation), have their
> suitable use cases. And their advantages and limitations have been well
> investigated and understood by the community.
>
> building block it really is.
>
>

well, this is what i mean the uncertainty of 4rd-U in the architecture to
the common understanding. as a analogy, one of Mr. E and Mr. T said, "i
give you a horse", while the other said "i give you a donkey". then people
well understand when they need a horse when they need a donkey. now Mr. U
said "wow, i give you a fantastic donkorse!". there would be 2 possible
results, not certain right now:
A. donkorse is just another sort of donkey, somehow good but somehow
flawed.
B. donkorse is just donkorse, and people, taking a long time to understand
it, and finally find it either a flawed or a quite good hybrid, like mule,
useful in some cases.

no matter if the future result is A or B, now Mr. O understand what he
needs for his business is either a horse and a donkey, with their
well-known characteristics. Mr. MAP provides a wheeled car as the common
instrument, while Mr. O needs a standard suite for the wheeled-car, the
horse-driving and donkey-driving methods and the way of feeding the horse
and donkey. this is the task of our wg, right now.

Mr. U said you must have another type of wheel and drive it with my
donkorse --- and when Mr. O asked him, what your donkorse is, he answered:
you will know it is donkorse, having both the advantages of the horse and
the advantages of the donkey. however, Mr. O doubts donkorse hasn't also
the disadvantages of horse and the disadvantages of donkey and some flaws
not yet documented. why not?

>
> This doesn't seem to justify any FUD from co-authors from broadband and
> mobile operators (or from product vendors).
>
> It is stated as tunneling but actually behaves like tunnel in some aspects
> while like translation in some other aspects.
>
>
> Yes indeed, thus achieving the best of both worlds without making it more
> complex. Actually making it clearly less complex than supporting both T and
> E.
>
>

i don't think those who made out mule expected the mule could replace horse
and donkey and achieving a better world without horse and donkey but only
mule. surely mule-only world is simpler.

> We see it only a yet-another-translation that try to solve some corner
> problems but introduces new, possibly major flaws (also pointed out in the
> technical threads on 4rd.)
>
>
> "Possibly major flaws" isn't an identified point on which U would do less
> than what it has been designed to do (unified replacement of T + E).
>
>

i believe they are major flaws but i was gently argued with the "possibly"
because i respected that maybe others didn't think so critically like me.

>
>
> IMPORTANT:
> - The essential characterization of U (vs T and E) is its Reversible
> header mapping (as replacement of both Double RFC6145 translation and
> Encapsulation).
>
>

yet-another-translation, with some issues still in debates.

>
> - Other features of U that differ from MAP (V-octet, CNP), or are
> complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this
> respect. Each of these features could be abandoned in U, or, if the WG
> appreciates what they offer, added to MAP.
>
>

MAP team has concluded V-octet and CNP are not necessary. do we need to
debate again? i doubt people have unlimited time.

>
> - For this, community acceptance to listen to explanations, would be the
> normal process. I will be available this week for this.
>
>

i think we are all open to listen to and to discuss on any explorations but
it doesn't mean we should stop standardization of our
wheeled-car/horse-driving/donkey-driving/feeding suite with an expectation
of a "better world" with only donkorse and the donkorse-specific wheeled
car.

regards,
maoke

>
>
> Cheers,
> RD
>
>
> In either the term of architectural philosophy or technical details,
> introducing 4rd-u into standards would be harmful.
>
>> list to foster our common understanding of the various technologies and how
>> they relate to each other.
>>

---

From: Rémi Després <[email-masked]>
Date: Sun, 25 Mar 2012 08:58:57 +0200

Le 2012-03-25 à 05:34, Maoke a écrit :

> some issues remaining not yet reaching collective undertanding is not a reason of making things over. the collective understanding has been reached for the major part of the
> 2) encapsulation and translation modes being supported by MAP format and the existing header processing standards 
> the above big picture are what i call "collective understanding". the correct way is: making these already gained approaches as bases, continuing discussion or even dabate on the details. i don't think it is a correct way of action to disrespect a team's work. 4rd-u's problem is even its big picture is still fuzzy.

Not more fuzzy than MAP (actually less fuzzy IMHO).
Debate on details is possible for U as wall as for T+E.

> i doubt i understand what you mean. may you please specify the question in details?

Is a DHCPv6 parameter needed, yes or no?

> what do you mean with the IDs? or do you mean interface IDs? i don't see "IDs from shared-address CEs" in U too. please teach!

Sec 4.5.3. is "Packet Identifications from Shared-Address CEs".
Did you read the complete draft?

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

> but it doesn't mean one doc is definitely reflecting "collective understanding" better than multiple.
>  
>  

???

> the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and BMR being exclusive is a problem.

How many MAP mapping rules do you see for the equivalent of the IVI use case in a MAP domain? 
None? 
If one, is it a DMR or a BMR?
If two, what are they?

> well, "collective understanding" was mentioned by Sally Floyd to the community of Internet researchers, and i borrowed her term. but i understand: no matter it is research or engineering, collective understanding is the understanding on the problems and the architecture rather than the detailed technical solutions. the MAP architecture has been reflected in the works of the draft suite. on the other hand, the community is not the softwires wg but the whole Internet engineering circle.
>  
>  
> 
> i cannot follow your "full IPv4 transparency" with "some" IPv6-only middle boxes. what does the "transparency" mean for the middle boxes? i understand, when we talk about the Internet transparency, we refer to the "end-to-end transparency". please specify your question concretely.

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.

> well, this is what i mean the uncertainty of 4rd-U in the architecture to the common understanding. as a analogy, one of Mr. E and Mr. T said, "i give you a horse", while the other said "i give you a donkey". then people well understand when they need a horse when they need a donkey. now Mr. U said "wow, i give you a fantastic donkorse!". there would be 2 possible results, not certain right now:
> A. donkorse is just another sort of donkey, somehow good but somehow flawed.
> B. donkorse is just donkorse, and people, taking a long time to understand it, and finally find it either a flawed or a quite good hybrid, like mule, useful in some cases.
>  
> no matter if the future result is A or B, now Mr. O understand what he needs for his business is either a horse and a donkey, with their well-known characteristics. Mr. MAP provides a wheeled car as the common instrument, while Mr. O needs a standard suite for the wheeled-car, the horse-driving and donkey-driving methods and the way of feeding the horse and donkey. this is the task of our wg, right now.  
>  
> Mr. U said you must have another type of wheel and drive it with my donkorse --- and when Mr. O asked him, what your donkorse is, he answered: you will know it is donkorse, having both the advantages of the horse and the advantages of the donkey. however, Mr. O doubts donkorse hasn't also the disadvantages of horse and the disadvantages of donkey and some flaws not yet documented. why not?
>  
>  
> i don't think those who made out mule expected the mule could replace horse and donkey and achieving a better world without horse and donkey but only mule. surely mule-only world is simpler.

Comparison is not reason (French proverb).

> i believe they are major flaws but i was gently argued with the "possibly" because i respected that maybe others didn't think so critically like me.

I have still to understand where you see "major flaws".
Just asserting they exist, without explanation although others who read the specification don't see them isn't enough.
Saying that E+T is better because its current inconsistencies are "details" isn't enough either (IMHO).

> yet-another-translation, with some issues still in debates.

You can call it as you wish, but the point remains that, with U, one doesn't need both E and T.

> MAP team has concluded V-octet and CNP are not necessary. do we need to debate again? i doubt people have unlimited time.

I made the point many times that the right to analyze problems didn't stop after a majority decision obtained during an improvised meeting.
Many MAP contributors were absents, and no time was given to correct invalid objections that had been made just before during a WG meeting.

Note that several co-authors of the U proposal have been MAP contributors.  

> i think we are all open to listen to and to discuss on any explorations but it doesn't mean we should stop standardization of our wheeled-car/horse-driving/donkey-driving/feeding suite with an expectation of a "better world" with only donkorse and the donkorse-specific wheeled car.

Your stand is clear, but comparison isn't reason.

RD

---

From: Maoke <[email-masked]>
Date: Sun, 25 Mar 2012 21:28:38 +0900

2012/3/25 Rémi Després [email-masked]
> Debate on details is possible for U as wall as for T+E.

you may argue that MAP is much more fuzzy. but as i said, nobody knows
exactly what the "4rd-u tunnel" is. you said it is just a reversible header
mapping that is not tunnel nor translation path section. then what does the
"reversible header mapping" provides to the architecture of transition? you
never clearly state this.

> Is a DHCPv6 parameter needed, yes or no?

i am not sure i know about the details of what you mean. do you mean the
feature of R-2.C? if so, i happen to have following questions:
1) why hub&spoke topology should be announced to the CE? (IMHO, if a  CE is
informed with the FMR involving other CEs, it works as mesh; if only BMR
and DMR is informed, surely it is hub&spoke. i think this has been
clarified in MAP Section 5.)
2) to this parameter issue, what is the difference between T and E?
look forward to your further clarification/discussions! if you mean not the
hub&spoke mode indicator, please specify your question further.

> Did you read the complete draft?

execuse me. it is my fault. i read it but i didn't realize you mean the
datagram identification here. it is a good point, and not only this but
also the issue of how BR deals with fragments of the same datagram where
only the first fragment has the port number. for this point, i think MAP-T
also needs to consider this problem described in the MAP-E Section 7, last
2 paragraphs. thanks a lot!

> 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. the text of Sec 8.2
of MAP-T and that of Sec 8.2 of MAP-E are clear enough to me. no one among
MAP/MAP-T/MAP-E here needs to be changed. (i may partly agree with you that
one could be further clarified).

> How many MAP mapping rules do you see for the equivalent of the IVI use

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.

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.

> ...
> 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); 2) with introducing
#1. uncommon definition of the fragment header of IPv6; #2 uncommon packet
of IPv6 carrying ICMPv4 messages?

>> It is stated as tunneling but actually behaves like tunnel in some
>> aspects while like translation in some other aspects.
>>
>>
> i don't think those who made out mule expected the mule could replace
> horse and donkey and achieving a better world without horse and donkey but
> only mule. surely mule-only world is simpler.
>
>

i mean "such an operator would know it uses 4rd-U" can approve nothing. i
just try to understand what the 4rd-u reversible header mapping really is,
in the term of architecture. this analogy is written as problem
understanding rather than a reason of anything.

> Just asserting they exist, without explanation although others who read
> the specification don't see them isn't enough.
>
>

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.

> "details" isn't enough either (IMHO).

different problems. E + T is actually not only the MAP-E and MAP-T, but the
utilization of existing, already mature E and T with the new MAP format.

> doesn't need both E and T.

no. U has changed the layered model of Internet protocol stack. 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. on the other hand, an operator
needs the translation to encourage transition and mutual communications
between IPv4 and IPv6 and double translation is included in such an
environment. T has specifications for this working but U needs still
discussion and running code approval. it cannot replace T at least this
moment.

> I made the point many times that the right to analyze problems didn't stop
> after a majority decision obtained during an improvised meeting.
> Many MAP contributors were absents, and no time was given to correct
> invalid objections that had been made just before during a WG meeting.
>
>

MAP can work even without the V-octet and CNP, at least in significant
cases. 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.

- maoke

> i think we are all open to listen to and to discuss on any explorations
> but it doesn't mean we should stop standardization of our

---

From: Rémi Després <[email-masked]>
Date: Sun, 25 Mar 2012 16:02:43 +0200

Maoke,
(Retransmission after deleting unnecessary old text. Message was too big for the mailing list)

2012-03-25  14:08, Maoke :

> 2012/3/25 Rémi Després <[email-masked]>
...
> you may argue that MAP is much more fuzzy. but as i said, nobody knows exactly what the "4rd-u tunnel" is.

> you said it is just a reversible header mapping that is not tunnel

I rather say that reversible header mapping implements a "tunnel" variant.
 
> nor translation path section.

> then what does the "reversible header mapping" provides to the architecture of transition? you never clearly state this. 

The draft is AFAIK not ambiguous.
I tried to answer all your questions on this point I barely understand (neither an implementation nor an operation issue)

End of this point for me, if there is nothing significantly new.

> i am not sure i know about the details of what you mean.

Today, there is no DHCPv6 parameter to require H&S, right?
My question is then: "is it sufficient to have none, or is it needed to add a new parameter".
Looking at more details would be premature for me until you have answered this question.

> do you mean the feature of R-2.C? if so, i happen to have following questions:
> 1) why hub&spoke topology should be announced to the CE? (IMHO, if a  CE is informed with the FMR involving other CEs, it works as mesh; if only BMR and DMR is informed, surely it is hub&spoke. i think this has been clarified in MAP Section 5.)

None AFAIK.

> look forward to your further clarification/discussions! if you mean not the hub&spoke mode indicator, please specify your question further.
>  
>  
> execuse me. it is my fault. i read it but i didn't realize you mean the datagram identification here. it is a good point, and not only this but also the issue of how BR deals with fragments of the same datagram where only the first fragment has the port number. for this point, i think MAP-T also needs to consider this problem described in the MAP-E Section 7, last 2 paragraphs. thanks a lot!

(*)
End of this subject.

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

> the text of Sec 8.2 of MAP-T and that of Sec 8.2 of MAP-E are clear enough to me. no one among MAP/MAP-T/MAP-E here needs to be changed. (i may partly agree with you that one could be further clarified).
... 

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

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

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

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

> i just try to understand what the 4rd-u reversible header mapping really is, in the term of architecture. this analogy is written as problem understanding rather than a reason of anything.

...

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

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. 
BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient. 
A new solution for this isn't needed. 

...
> ... U has changed the layered model of Internet protocol stack.

> 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.
A detailed E use case that cannot be supported by U (if it exists) would give substance to this claim.
Open to look at it.  

> on the other hand, an operator needs the translation to encourage transition and mutual communications between IPv4 and IPv6 and double translation is included in such an environment. T has specifications for this working

BIH does the job with single translation.
Where U applies, both ends are IPv4, T has AFAIK no operational superiority while U is more transparent.

> but U needs still discussion

T too.
See, for example, (*) above.

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

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

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

---

From: Maoke <[email-masked]>
Date: Mon, 26 Mar 2012 04:35:06 +0000

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

> 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
> were in hub&spokes mode for an unknown destination CE.
>
>

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.

> (In this respect at least, IVI significantly differs from a running

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.

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

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

...
> ICMPv4 payloads in IPv6 packets appear only during domain traversal, where

see above.

> hosts, there are already workable RFCs.

common understanding, including RFC6052/RFC6145/RFC6146 but surely not
limited to these.

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

> See, for example, (*) above.

you have ended that subject. fine to me. people have known the difference
between the "needs discussions" for the both.

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

> cases.

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

---

From: Rémi Després <[email-masked]>
Date: Mon, 26 Mar 2012 13:49:07 +0200

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. 

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

> then there is no more "not reaching collective understanding" for this point. End of this topic for me. 
>  
> 
>> None? 
> 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. 

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

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!
> 
>> ... 
> common understanding, including RFC6052/RFC6145/RFC6146 but surely not limited to these. 
>  
> 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 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) 
>                \                                                        /
>                 \                                                      /

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

> well, it works just like another translator, surely it doesn't need great expertise. 
>  
> 
> 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)?

> 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

---

From: "Jiang Dong" <[email-masked]>
Date: Mon, 26 Mar 2012 21:32:49 +0800

Hi, Remi,

I get some questions about the 4rd-u draft.

1) The "tunnel packet" defined in your draft includes an IPv6 header followed by a IPv6 fragmentation. Can this packet be defined as a tunnel packet or a translation packet or neither or both? Since this is not the traditional tunneling packet format, I'm not sure still using "tunnel packet" is a good idea.

2) You mentioned NAT64+ which is upgraded to support both 4rd-u and NAT64. When a BR receives a tunnel packet, how can it distinguish the packet is a 4rd packet so that it can perform the 4rd procedure, or a NAT64 packet so that it can perform the NAT64 procedure? And does the NAT64 procedure still the traditional one?

3) Is there any possibility that a CE contains both BR mapping rule and NAT64+ mapping rule?

4) You mentioned the process to deal with a  unspecified IPv4 address format in Section 4.4. How the BR(NAT64+) deal with such a packet?

Another comment: it would be better to understand the draft if you can put some complete data plan procedures in the example section.

Regards!

Jiang Dong
Tsinghua University

---

From: "Jiang Dong" <[email-masked]>
Date: Mon, 26 Mar 2012 21:59:21 +0800

Hi, authors of 6rd MIB,

I get some comments about 6rd MIB draft.

1) You mentioned the "tunnelIfXTable" in section 5.2. I think it is a good idea to extend the tunnel MIB, some scenario cannot be included in RFC4087, such as point to multi-point tunnel like softwire mesh.

2) It seems you miss the conformance part in the definition.

3) I'm not quite sure what's the "sixRdIpv4MaskLen " used for, can you explain it?

Regards!

Jiang Dong
Tsinghua University

---

From: Shishio Tsuchiya <[email-masked]>
Date: Mon, 26 Mar 2012 16:19:13 +0200

Jiang
Thanks for comments.
I will do presentation this draft at Friday,and I will ask which idea is better to the audience and chairs.
If IP tunnel MIB extended is better than 6rdMIB,so we would update and define extension of IP tunnel MIB.
6rd MIB is completely reflecting to 6rd configuration.
http://tools.ietf.org/html/rfc5969#section-7
"sixRdIpv4MaskLen "  is same function as IPv4MaskLen.

IPv4MaskLen         The number of high-order bits that are identical
                       across all CE IPv4 addresses within a given 6rd
                       domain.  For example, if there are no identical
                       bits, IPv4MaskLen is 0 and the entire CE IPv4
                       address is used to create the 6rd delegated
                       prefix.  If there are 8 identical bits (e.g., the
                       Private IPv4 address range 10.0.0.0/8 is being
                       used), IPv4MaskLen is equal to 8 and IPv4MaskLen
                       high-order bits are stripped from the IPv4
                       address before constructing the corresponding 6rd
                       delegated prefix.

Regards,
-Shishio

(2012/03/26 15:59), Jiang Dong wrote:
> Hi,authors of 6rd MIB,
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 --

---

From: Kevin Y <[email-masked]>
Date: Mon, 26 Mar 2012 16:30:22 -0500

Dear WG Co-Chairs,

I looked at your arguments in this email here and Softwaire WG agenda you
proposed on Wed and Fri, I am kind of confusing, hope you can clarify:

There are several drafts discussed in Wed agenda which basically solved
same problem as we discussed in Friday and they are all variant solution of
encapsulations in stateless mode for 464 user case. how do you deal
with all those proposals, should we put all of those along with MAP, 4rd-u
as part of selecting decision from WG on
Friday all together ?  It will be unfair to treat those differently on Wed
vs those on Friday !

If we are facing the problem for too many standard proposals from softwire
WG,  they occured in situations we had too many variant of encapsulations,
so far, from what I can see, MAP represents the best efforts from WG to
unify encapsulation and translation solutions from softwire.  I agreed with
many in this mailing-list said before,  respect the collaborating
efforts in past 6 month and select MAP as standard track,rather
other individual variant such as 4rd-U, stateless DS-lite, etc. let us be
more productive through collaboration than count-productive through more
individual drafts.

Best Regards,

Kevin Yin

---

From: Kevin Y <[email-masked]>
Date: Mon, 26 Mar 2012 16:41:31 -0500

Maoke,

I like your analog of horse, donkey, and donkorse! and fully agree with you.

People know what kind of situation horse and donkey can help to solve the
problem.  People do not want unknown donkorse because it creates more
problem rather than solving specific problem.

Kevin Yin

> well understand when they need acwhen they need a donkey. now Mr. U said
> "wow, i give you a fantastic donkorse!". there would be 2 possible results,
> not certain right now:

---

From: "Jiang Dong" <[email-masked]>
Date: Tue, 27 Mar 2012 11:36:57 +0800

Hi, Shishio,

Thanks for your reply and clarification.

Best Regards!

Jiang Dong
Tsinghua University
2012-03-27

From: Shishio Tsuchiya
Date: 2012-03-26 22:19
To: jiangdong345
CC: cai.lei3; jacni; softwires; cuiyong
Subject: Re: [Softwires]Comments about 6rd MIB
Jiang
Thanks for comments.
I will do presentation this draft at Friday,and I will ask which idea is better to the audience and chairs.
If IP tunnel MIB extended is better than 6rdMIB,so we would update and define extension of IP tunnel MIB.

[DJ] I think RFC4087 is designed for common information about tunnels. So extra information that can not be included in RFC4087 need to be contained in specialized MIB such as 6rd, softwire mesh. 
BTW, since 6rd can perform encapsulation in a stateless way, there is no need to maintain an encapsulation table. AFBRs in softwire mesh scenario need to perform I-IP encapsulation with E-IP prefix information, a we defined an Encapsulation Table in the softwire mesh MIB. Comments are welcome : )

Regards,
-Shishio

(2012/03/26 15:59), Jiang Dong wrote:
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Jiang Dong
> Tsinghua University
>

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 27 Mar 2012 05:54:26 +0200

As a member of the MAT DT, I am naturally biased in favor of what Xing, Maoke and Ole said.

I also think that the chair's questions are not adequate. I don't think that the questions should be which of document the wg choose, make documents to be unified or not. I think that it should be what 'solution space' has been clarified beyond the MAP suite. Let me try to figure these out.

1. Reduce the number of parameters for MAP configuration
 The MAP currently needs bunch of parameters such as 'Rule IPv6 prefix', 'Rule IPv4 prefix' and 'EA-bits length' for each of BMR, FMR and DMR. It would be more convenient when one or some of them can be reduced or omitted.

2. Trying to keep more header transparency 
 When operators think that it would be nice if the MAP-T can keep header transparency, which includes checksum neutrality, beyond the current header translation specification, the wg should be work on that, or ask other wg to do that.

3. Truly 'Unified' operation 
 Since encapsulation and translation are completely separated operation in operator's network (I mean 'polarized' on Jan's comment) but the implementation of both is possible into one box. Beyond just 'unified document', does operators think it would be more attractive with 'unified' operation for which both encapsulation and translation co-exist in same time, on same network, for same service.

Above three are my thought of what 4rd-u proposed to the wg. Discussions and more suggestions are welcome.

Best regards,
--satoru

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 27 Mar 2012 14:19:45 -0700

On 3/26/12 8:54 PM, "Satoru Matsushima" <[email-masked]>
wrote:

>I also think that the chair's questions are not adequate. I don't think
>that the questions should be which of document the wg choose, make
>documents to be unified or not. I think that it should be what 'solution
>space' has been clarified beyond the MAP suite. Let me try to figure
>these out.
>
> The MAP currently needs bunch of parameters such as 'Rule IPv6 prefix',
>'Rule IPv4 prefix' and 'EA-bits length' for each of BMR, FMR and DMR. It
>would be more convenient when one or some of them can be reduced or
>omitted.

[Reinaldo] Good point. Irrespective of MAP/4rd-U it would be good to have
a 
simplified model for ease of deployment. Usually when implementing such
standards things get
very complicated for both development and ISP due to

- Consistency checks across all parameters
- Consistency checks within a parameter
- Debugging, operational commands, testing,
- Interop testing, naming conventions
- Network planning and staff training.

Thanks,

Reinaldo 

> When operators think that it would be nice if the MAP-T can keep header
>transparency, which includes checksum neutrality, beyond the current
>header translation specification, the wg should be work on that, or ask
>other wg to do that.
>
> Since encapsulation and translation are completely separated operation
>in operator's network (I mean 'polarized' on Jan's comment) but the
>implementation of both is possible into one box. Beyond just 'unified
>document', does operators think it would be more attractive with
>'unified' operation for which both encapsulation and translation co-exist
>in same time, on same network, for same service.
>
>>> 1) There  is an observation that all the solutions on the table E, T &
>>>U actually solve the stateless  problem we started with.
>> I do agree with that. the Venn diagram for the three solutions would
>>look awfully similar to a single circle. ;-)
>> I left the interim meeting in Beijing having been convinced that there
>>are use cases requiring both encapsulation and requiring translation. if
>>we for a moment accept that, I would suggest that we treat MAP as one
>>single solution. it will have two options/flavours of transport.
>> 
>>>would like to ask for presentations from the proponents of each
>>>candidate solution (E, T & U).
>>>explain how it compares to the others and make a case as why it should
>>>be the one on the Standard Track. We will allocate 20 minutes for each
>>>presentation.
>>> Then, we, chairs, would like to ask a series of questions to the
>>>working group. In order to make this process transparent, here is the
>>>list of questions we want to ask
>>> and their sequence.
>>> 
>>>gets adopted by the market.
>>> If the answer is NO, we are left with E & T (U then might be abandoned
>>>or published as Historical/Informational)
>>> 
>>> 
>> can ask the chairs to take a hum of how many would want t-shirts for
>>the meeting with: "Just pick one for F's sake and stop arguing". ;-)
>> 
>> cheers,
>> Ole

---

From: Rémi Després <[email-masked]>
Date: Sat, 31 Mar 2012 16:56:43 +0200

Alain,

You had initially announced that either one specification would be chosen for standard track (among T, E, and U), or specifications would all become WG drafts on the experimental track ((*) below).
In Paris:
(a)The MAP proposal became presented as an inseparable T+E package. 
(b) The WG couldn't make a consensus choice between T+E or U.

Now publishing both MAP-T+E and 4rd-U as WG documents on the experimental track, is therefore consistent with what was announced (and was also asked for by several at the end of the meeting). 
As you explained, this won't prevent from selecting one for standard track later on, based on better market experience.

After what we had at IETF 83, this is in my understanding the only irreproachable course of action

Thanks,
RD

(*)

---

From: Maoke <[email-masked]>
Date: Sun, 1 Apr 2012 07:15:38 +0900

hi all,

i listented to the softwire wg live on March 30 online and recorded my
comments in the jabber room. as the person who was mentioned by the
presenter not less than twice, i have to point out that it is unfair that
the presenter mentioned me with only acknowledgment to my effort but my
point of views. my summerized comment on 4rd-u is: it is flawed in both
architecture and technical aspects, and now still uncertain in several
details.

it would become as a ridiculous and weird record in the  ietf history, had
the wg made a decision of putting two as experimental, one is
well-understood, well-coded and well-practised while the other is
misleading the understanding on the Internet architecture, not yet coded,
not yet tested by any operators.

our company, as an ISP and as a provider doing also application services,
including those over mobile platforms, is waiting for the MAP standard
desirably. we have no interest in introducing the 4rd-u elements into our
platforms.

personally i won't code a stuff with obvious architectural flaws but, if i
were believing in the 4rd-u, i would do the code and operational test with
serious self-checking as MAP-T and MAP-E teams already have done, before
talking on any doc-track issue with the community. this is the way of being
responsible.

thanks,
maoke

---

From: Sheng Jiang <[email-masked]>
Date: Sun, 1 Apr 2012 00:47:36 +0000

Without any prejudgement, we are going to implement 4rd-u and do operational tests. If there are any architecture conflict with the basic IPv6 archtecture, we would like to propose modification for 4rd-u design. In principle, we have no any interests to change the current IPv6 architecture at all. We will make sure it is a transition mechanism to help current IPv6 getting deployed, rather than another IP.

Best regards,

Sheng

________________________________
From: [email-masked] [[email-masked]] on behalf of Maoke [[email-masked]]
Sent: 01 April 2012 6:15
To: Softwires-wg
Cc: Yong Cui; Ralph Droms
Subject: Re: [Softwires] Path to move forward with 4rd…

hi all,

i listented to the softwire wg live on March 30 online and recorded my comments in the jabber room. as the person who was mentioned by the presenter not less than twice, i have to point out that it is unfair that the presenter mentioned me with only acknowledgment to my effort but my point of views. my summerized comment on 4rd-u is: it is flawed in both architecture and technical aspects, and now still uncertain in several details.

it would become as a ridiculous and weird record in the  ietf history, had the wg made a decision of putting two as experimental, one is well-understood, well-coded and well-practised while the other is misleading the understanding on the Internet architecture, not yet coded, not yet tested by any operators.

our company, as an ISP and as a provider doing also application services, including those over mobile platforms, is waiting for the MAP standard desirably. we have no interest in introducing the 4rd-u elements into our platforms.

personally i won't code a stuff with obvious architectural flaws but, if i were believing in the 4rd-u, i would do the code and operational test with serious self-checking as MAP-T and MAP-E teams already have done, before talking on any doc-track issue with the community. this is the way of being responsible.

thanks,
maoke

---

From: "Lee, Yiu" <[email-masked]>
Date: Sun, 1 Apr 2012 02:34:40 +0000

Hi Sheng,

Thanks very much for letting us know you are going to implement 4rd-u.
Please share the results in the ML. I am very much interested to see how
4rd-u would cause any conflict in IPv6.

Thanks,
Yiu

From:  Sheng Jiang <[email-masked]>
Date:  Sun, 1 Apr 2012 00:47:36 +0000
To:  Maoke <[email-masked]>, Softwires-wg <[email-masked]>
Cc:  Yong Cui <[email-masked]>, Ralph Droms <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rdŠ

Without any prejudgement, we are going to implement 4rd-u and do operational
tests. If there are any architecture conflict with the basic IPv6
archtecture, we would like to propose modification for 4rd-u design. In
principle, we have no any interests to change the current IPv6 architecture
at all. We will make sure it is a transition mechanism to help current IPv6
getting deployed, rather than another IP.

Best regards,

Sheng