Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward

From: Jacni Qin <[email-masked]>
Date: Thu, 03 May 2012 09:03:24 +0800

Re-,

On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote:
> Well, even the WG decided to go with MAP, we would still need to coin toss
> between MAP-T and MAP-E, wouldn't we?
May I share your concern.

Cheers,
Jacni

> On 4/26/12 10:50 AM, "Jan Zorz @ go6.si"<[email-masked]>  wrote:
>
>> On 4/26/12 11:50 AM, Mark Townsley wrote:
>>> Perhaps we would have been better off with the coin toss.
>> +1
>>
>> bingo.
>>
>> Cheers, Jan
>>
>> P.S: I'll not waste more bits on this topic as it's apparently a waste
>> of bandwidth :)
>>
>> P.P.S: Should we deprecate RFC6346?
>> _______________________________________________
>> Softwires mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/softwires

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 3 May 2012 02:18:13 +0000

My concern is MAP isn't a single solution. Operators still need to make a
choice between E and T because they are not compatible.

From:  Jacni Qin <[email-masked]>
Date:  Wednesday, May 2, 2012 9:03 PM
To:  "Yiu L. LEE" <[email-masked]>
Cc:  "Jan Zorz @ go6.si" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [Softwires] Result from the consensus call on Map vs 4rd-U and
official way forward

Re-,

Cheers,
Jacni

> On 4/26/12 10:50 AM, "Jan Zorz @ go6.si" <[email-masked]> <mailto:[email-masked]>
> wrote:
> 
>> [email-masked]://www.ietf.org/mailman/listinfo/softwires
>> 
>>  
>> [email-masked]://www.ietf.org/mailman/listinfo/softwires

---

From: Jacni Qin <[email-masked]>
Date: Thu, 03 May 2012 13:53:08 +0800

Re-,

On 5/3/2012 Thursday 10:18 AM, Lee, Yiu wrote:
> My concern is MAP isn't a single solution. Operators still need to 
> make a choice between E and T because they are not compatible.

Fully agree, and IMHO, there have been lots of compromise in the design 
of MAP algorithm to accommodate both E and T.

Cheers,
Jacni

>
> From: Jacni Qin <[email-masked] <mailto:[email-masked]>>
> To: "Yiu L. LEE" <[email-masked] 
> <mailto:[email-masked]>>
> Cc: "Jan Zorz @ go6.si" <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> Subject: Re: [Softwires] Result from the consensus call on Map vs 
> 4rd-U and official way forward
>
> Re-,
>

---

From: Ole Trøan <[email-masked]>
Date: Thu, 3 May 2012 08:58:35 +0200

Jacni,

>> My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible.

would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice?

> Fully agree, and IMHO, there have been lots of compromise in the design of MAP algorithm to accommodate both E and T.

examples?

cheers,
Ole

---

From: Jacni Qin <[email-masked]>
Date: Thu, 03 May 2012 15:17:35 +0800

Ole,

> would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice?
I'd rather prefer you pick one only.

>> Fully agree, and IMHO, there have been lots of compromise in the design of MAP algorithm to accommodate both E and T.

Section 5.4, the BR address,

And the 6 about the design of IID, I'm not a fan of the statement like 
"The encoding of the full IPv4 address into the interface identifier, 
both for the source and destination IPv6 addresses have been shown to 
be useful for troubleshooting. "

...

Cheers,
Jacni

---

From: Ole Trøan <[email-masked]>
Date: Thu, 3 May 2012 10:38:07 +0200

Jacni,

> I'd rather prefer you pick one only.

wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 3 May 2012 11:09:36 +0200

2012-05-03 à 10:38, Ole Trøan:
...
> let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive.

Agreed: each of E or T doesn't cover by itself all expressed requirements for a stateless 4via6 solution. 
The question that remains, however, is whether 4rd does cover, or not, all these requirements in a unified solution. 

This question will better be answered when the WG drafts on both MAP and 4rd are available and stabilized.

Looking forward to it,
RD

---

From: Jacni Qin <[email-masked]>
Date: Fri, 04 May 2012 10:03:13 +0800

Ole,

> wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive.
We put the requirements on the table and some discussions, but sorry, I 
can't remember what exactly the consensus/conclusion is, and I'm 
confused about where we are.

I see, maybe I'm wrong, the technical requirements are drawn more from 
the two incompatible solutions after, but not from the 
conversion/analysis of the statements in "motivation", then we got the 
mutually exclusive ones you mentioned above. How can we figure out the 
way to move forward? Just by some MUSTs/MAYs ...

Anyway, if generally we have a single target or design goal, IMHO, it's 
really a bad idea to keep parallel two, no matter we call them 
requirements/solutions, whatever.

Cheers,
Jacni

---

From: Leaf yeh <[email-masked]>
Date: Fri, 4 May 2012 10:08:32 +0000

Jacni - Anyway, if generally we have a single target or design goal,…

There are many design goals here. What Ole said in this email is the solution of Encapsulation & Translation will meet the different ones, which sounds mutually exclusive. Will you go for the further clarification or discussion on it here?

I would be open to accept these 2 solutions, which share part of the same address format. And let the operator get the right to pick one he believe it is feasible & suitable, or even not pick any of these solution.

Best Regards,
Leaf

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jacni Qin
Sent: Friday, May 04, 2012 10:03 AM
To: Ole Trøan
Cc: [email-masked]
Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward

Ole,

Jacni,

wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive.
We put the requirements on the table and some discussions, but sorry, I can't remember what exactly the consensus/conclusion is, and I'm confused about where we are.

I see, maybe I'm wrong, the technical requirements are drawn more from the two incompatible solutions after, but not from the conversion/analysis of the statements in "motivation", then we got the mutually exclusive ones you mentioned above. How can we figure out the way to move forward? Just by some MUSTs/MAYs ...

Anyway, if generally we have a single target or design goal, IMHO, it's really a bad idea to keep parallel two, no matter we call them requirements/solutions, whatever.

Cheers,
Jacni

cheers,

Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 4 May 2012 14:55:54 +0200

> I would be open to accept these 2 solutions, which share part of the same address format. And let the operator get the right to pick one he believe it is feasible & suitable, or even not pick any o…

Would you agree, though, that if a solution is confirmed to cover design goals of both Encapsulation and Translation, it would better meet the WG objective objective to have a single standard? 
(Operators would be relieved from having to make a choice.)

Regards,
RD

---

From: Leaf yeh <[email-masked]>
Date: Fri, 4 May 2012 16:16:15 +0000

Remi - Would you agree, though, that if a solution is confirmed to cover design goals of both Encapsulation and Translation, it would better meet the WG objective objective to have a single standard?  (Operators would be relieved from having to make a choice.)

That sounds great if the solution (eg. 4rd-U) is confirmedly feasible and extensively accepted by the group. Right?

Best Regards,

Leaf

________________________________
From: Rémi Després [[email-masked]]
Sent: Friday, May 04, 2012 20:55
To: Leaf yeh
Cc: Jacni Qin; Ole Trøan; [email-masked]
Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward

Regards,
RD

Best Regards,
Leaf

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jacni Qin
Sent: Friday, May 04, 2012 10:03 AM
To: Ole Trøan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward

Ole,

Jacni,

Cheers,
Jacni

cheers,

Ole

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

---

From: Rémi Després <[email-masked]>
Date: Fri, 4 May 2012 18:58:46 +0200

2012-05-04  18:16, Leaf yeh:

> That sounds great if the solution (eg. 4rd-U) is confirmedly feasible

Yes, feasibility is clearly  a decisive criterion.
(Not forgetting that feasibility of MAP-T+E, with all what there is in the specification without having be tested before, has also to be confirmed.)

>  and extensively accepted by the group. Right?

That's the purpose of this question: will standard unicity be confirmed by the WG an important criterion?

If you agree, we can resume this discussion when all specifications are available.

Kind regards,
RD

---

From: Jacni Qin <[email-masked]>
Date: Sat, 05 May 2012 10:58:49 +0800

I'll be open to accept N solutions, in case of necessity.
Of course, operators get the right to pick one, e.g. from DS-Lite, 
"stateless" like MAPs/4rd .., etc., but it'll be our fault to let them 
try to pick one from different variables of the "stateless", if there's 
no sufficient reason.

Back to the motivation document, I failed to see the "mutually 
exclusive" requirements were stated. Have we left it all behind or 
chosen to miss it, since the mission to prove "stateless" approaches are 
needed is complete?

Ok, let's wait for the output of the design team, while may I again 
suggest that you consider seriously the mutually exclusive requirements 
from E & T before moving forward?

Cheers,
Jacni

On 5/4/2012 Friday 6:08 PM, Leaf yeh wrote:
> There are many design goals here. What Ole said in this email is the 
> solution of Encapsulation & Translation will meet the different ones, 
> which sounds mutually exclusive. Will you go for the further 
> clarification or discussion on it here?
>
> I would be open to accept these 2 solutions, which share part of the 
> same address format. And let the operator get the right to pick one he 
> believe it is feasible & suitable, or even not pick any of these solution.
>
> Best Regards,
>
> Leaf
>
> *From:[email-masked] [mailto:[email-masked]] 
> *On Behalf Of *Jacni Qin
> *Sent:* Friday, May 04, 2012 10:03 AM
> *To:* Ole Trøan
> *Cc:* [email-masked]
> *Subject:* Re: [Softwires] Result from the consensus call on Map vs 
> We put the requirements on the table and some discussions, but sorry, 
> I can't remember what exactly the consensus/conclusion is, and I'm 
> Anyway, if generally we have a single target or design goal, IMHO, 
> it's really a bad idea to keep parallel two, no matter we call them