Subject: [Softwires] Call for confirming the selection of MAP-E as the basis for the proposed standard stateless solution

From: Suresh Krishnan <[email-masked]>
Date: Tue, 7 Aug 2012 18:02:17 -0400

Hi all,
  During the softwire WG meeting at IETF84 a series of questions* to
determine the preferred solution in the meeting room indicated that the
sense of the room was in favor of MAP-E as the basis for the proposed
standard stateless solution.

This call is being initiated to confirm whether there is WG consensus
towards the selection of MAP-E as the basis for the proposed standard
stateless solution. Please state whether or not you're in favor of this
selection by replying to this email. If you are not in favor, please
also (re)state your objections in your response. The call will complete
at midnight EDT on 2012-08-21.

Regards
Suresh & Yong

* Questions are available at

http://www.ietf.org/proceedings/84/slides/slides-84-softwire-15.pdf

---

From: Jacni Qin <[email-masked]>
Date: Wed, 08 Aug 2012 13:13:52 +0800

Re-,

Seems to be a good choice, I'm in favor of it.

Cheers,
Jacni

On 8/8/2012 Wednesday 6:02 AM, Suresh Krishnan wrote:
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Maoke <[email-masked]>
Date: Wed, 8 Aug 2012 14:32:05 +0900

chairs and all,

as MAP-T and MAP-E were approved by the room of the IETF84 softwire session
as different solutions, i confirm here that i am in favor of selecting
MAP-E as the basis for the WG proposed standard for stateless solution.

and i support the WG continuing the effort in providing the same MAP
algorithm for both MAP-E and MAP-T, and making them inter-operable.

- maoke

2012/8/8 Suresh Krishnan <[email-masked]>

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Wed, 08 Aug 2012 10:01:32 +0200

> at midnight EDT on 2012-08-21.

+1

finally a WG made a decision so we can move forward with A+P work.

Cheers, Jan

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 8 Aug 2012 11:35:23 +0200

Hello,
    in my opinion the design team did a great job in creating the MAP draft as a common baseline specification for MAP-T and MAP-E flavors and the presentations we saw in Vancouver last week shown that implementations for both MAP-T and MAP-E already exist and they just differs for few lines of code.

As this working group already discussed in the past, there are use cases that can be simply covered by MAP-T flavor of the MAP solution, for example being able to apply ACL's and policies  tied to customer's profile stored in Radius server at the BNG level without requiring additional work and correlations on the BR.
Speaking as a Service Provider I do care about these use cases, thus I would encourage the working group to adopt the current MAP draft as is (including MAP-T and MAP-E) as the basis for the proposed standard stateless solution and keep working on common MAP solution.

Thanks
Best regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: mercoledì 8 agosto 2012 0.02
To: Softwires WG
Subject: [Softwires] Call for confirming the selection of MAP-E as the basis for the proposed standard stateless solution

Hi all,

Regards
Suresh & Yong

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Aug 2012 12:18:06 +0200

Hi, Suresh,

2012-08-08 00:02, Suresh Krishnan :

> selection by replying to this email.

Although I personally voted for 4rd, I acknowledge how important it is to make a choice, and that the WG expressed a clear preference  for Encapsulation.
Since some the identified limitations of MAP-E can easily eliminated in a new draft, as noted in particular by Mark and myself, I support Encapsulation as the WG choice for standard track.

Regards,
RD 

> If you are not in favor, please

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 8 Aug 2012 19:50:30 +0900

Chairs,

I support the decision we've reached in Vancouver.
Thank you for wonderful chairing so that we can finally move forward.

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 8 Aug 2012 14:05:37 +0200

Chairs,

thanks for moving the wg work forward by facilitating the discussion in Vancouver!

I support progressing MAP-E as a basis for the proposed standard stateless solution 
for mesh deployments.

Cheers,
Ales

> Sent: Wednesday, August 08, 2012 12:02 AM
> To: Softwires WG

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 8 Aug 2012 14:13:11 +0000

+1

I also support MAP-E and MAP-T, as Maglione pointed out. We need to be respectful of the design team that produced MAP based on consideration and requirements. Not to forget that MAP-T (unlike others) has already been deployed.

Cheers,
Rajiv

Sent from my Phone

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Aug 2012 16:51:52 +0200

Le 2012-08-08 à 16:13, Rajiv Asati (rajiva) a écrit :

> +1
> 
> I also support MAP-E and MAP-T, as Maglione pointed out. We need to be respectful of the design team that produced MAP based on consideration and requirements.

> Not to forget that MAP-T (unlike others) has already been deployed.

Without ignoring that, 
- the clear order of preference for a single standard solution  has been in Vancouver first MAP-E, then 4rd, then  MAP-T well behind,
- the design team of 4rd also deserves respect,
- a number of issues have yet to be closed regarding what is exactly MAP-T, 
could you communicate, for the sake of information, the DMR, and the BMRs/FMRs if any, of the deployment(s) you are referring to?

Thanks,
RD

---

From: Ralph Droms <[email-masked]>
Date: Wed, 8 Aug 2012 11:11:01 -0400

Please move this discussion to a new thread.  The topic for this thread is confirmation of consensus for selecting MAP-E.

- Ralph

---

From: Tom Taylor <[email-masked]>
Date: Wed, 08 Aug 2012 11:22:07 -0400

Support. It's time a decision was made.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 8 Aug 2012 12:10:15 -0500

In favor. 

- Mark

---

From: Shishio Tsuchiya <[email-masked]>
Date: Thu, 09 Aug 2012 05:43:14 +0900

Chairs,
I really appreciate your great chairing in IETF84.
I support *MAP-E* as the basis for the proposed standard stateless solution.

As you might know,Japan already has nation wide IPv6 service.
Operators has interesting in softwire wg decision for stateless IPv4 over IPv6.
Many Japanese vendors already supported draft-murakami-softwire-4rd.
It is convenient for JAPAN,if MAP-E(encapsulation solution) would be selected as the standard technology.
We can move forward easily.

Regards,
-Shishio

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 8 Aug 2012 23:34:55 +0000

This email confirms my personal support for MAP-E as WG consensus from Vancouver meeting.

The chairs and ADs did a great job to move us forward. It was not easy to make any decisions under the pressure giving the long debate we were in. But the most important thing is the WG need a decision to stop the unstoppable arguments. Anything is better than nothing.

Thanks again for your marvelous work, chairs and Ads.

Best regards,

Sheng

>Sent: Wednesday, August 08, 2012 6:02 AM
>To: Softwires WG

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 9 Aug 2012 01:12:38 +0000

I support to standardize MAP-E as the stateless solution. Let's move
forward. Thanks for both chairs and Ralph to shepherd the discussion.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 10 Aug 2012 09:12:48 +0000

+1

A remarkable decision case in IETF.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Wednesday, August 08, 2012 6:02 AM
To: Softwires WG
Subject: [Softwires] Call for confirming the selection of MAP-E as the basis for the proposed standard stateless solution

Hi all,

Regards
Suresh & Yong

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 Aug 2012 11:25:13 -0500

+1

Encapsulation is the way to go.
Yuppi.
Just like DS-Lite :-).

Behcet

---

From: GangChen <[email-masked]>
Date: Wed, 15 Aug 2012 18:28:14 +0800

Hello Chairs,

I support the outcome from Vancouver meeting to choose MAP-E as the
basis. It's a fair decision after half-year of discussions. Many
thanks for the guidance of the chairs and ADs.

BRs

Gang

---

From: Peng Wu <[email-masked]>
Date: Wed, 15 Aug 2012 20:49:36 +0800

Dear Chairs,

I support MAP-E as the basis, and -T & 4rd as experimental/informational.
Let's move forward.
Thanks for the joyful experience in Vancouver meeting.

---

From: sunqi <[email-masked]>
Date: Wed, 15 Aug 2012 20:50:07 +0800

Hi , dear chairs,

       I would like to see the stateless solutions moving forward with MAP-E on the standard track and keep it focusing on mesh scenarios.

      Many thanks for the great guidance of our chairs and ADs.

Thanks,

Qi Sun

---

From: Qiong <[email-masked]>
Date: Wed, 15 Aug 2012 21:04:38 +0800

Hi Chairs,

Support to move forward with MAP-E as a basis stateless solution. It is a
remarkable milestone in Vancouver meeting to end the long time arguement
over the past two years.

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Leaf yeh <[email-masked]>
Date: Thu, 16 Aug 2012 03:15:27 +0000

Qi Sun - I would like ...MAP-E on the standard track and keep it focusing on mesh scenarios.

MAP sounds native in mesh mode, because CE got the public ipv4 address, its port set, and the mapping between IPv4 (A+P) and the accessible IPv6 prefix, but why can't we make it support hub-and-spoke?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of sunqi
Sent: Wednesday, August 15, 2012 8:50 PM
To: Suresh Krishnan
Cc: Softwires WG
Subject: Re: [Softwires] Call for confirming the selection of MAP-E as the basis for the proposed standard stateless solution

Hi , dear chairs,

Thanks,

Qi Sun

---

From: Maoke <[email-masked]>
Date: Thu, 16 Aug 2012 13:58:24 +0900

2012/8/16 Leaf yeh <[email-masked]>

> MAP sounds native in mesh mode, because CE got the public ipv4 address,
> its port set, and the mapping between IPv4 (A+P) and the accessible IPv6
> prefix, but why can't we make it support hub-and-spoke?
>

same view. some operator would like to deploy things only with hub&spokes
mode, it is fine. but for those who want to have mesh and hub&spokes
simultaneously, there is no reason that we need two solutions especially
when MAP has supported both. there is no need to limit MAP's scope with
"focusing on mesh".

in a service architecture that i am designing for one of my company's
product, i have had the very concrete requirement on both mesh and
hub&spokes.

- maoke

> Subject: Re: [Softwires] Call for confirming the selection of MAP-E as the
> basis for the proposed standard stateless solution
>
>
> Hi , dear chairs,
>
>        I would like to see the stateless solutions moving forward with
> MAP-E on the standard track and keep it focusing on mesh scenarios.
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 16 Aug 2012 09:19:01 -0400

Le 2012-08-16 00:58, Maoke a écrit :
> same view. some operator would like to deploy things only with
> hub&spokes mode, it is fine. but for those who want to have mesh and
> hub&spokes simultaneously, there is no reason that we need two solutions
> especially when MAP has supported both. there is no need to limit MAP's
> scope with "focusing on mesh".

The elephant in the room is that a provider that only needs 
hub-and-spoke doesn't want to pay for the needless (subjectively) 
complexity of MAP.

Here's an idea: a restricted "profile" of MAP-E that would only allow 
hub-and-spoke, described in a separate RFC, would look exactly like 
LW4o6, right? And it could be implemented stand-alone, without all the 
mesh code. And it could be listed on an RFP.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: sunqi <[email-masked]>
Date: Fri, 17 Aug 2012 10:39:52 +0800

On 2012-8-16, at 下午9:19, Simon Perreault wrote:

> The elephant in the room is that a provider that only needs hub-and-spoke doesn't want to pay for the needless (subjectively) complexity of MAP.

[Qi] Agreed.
> 
> Here's an idea: a restricted "profile" of MAP-E that would only allow hub-and-spoke, described in a separate RFC, would look exactly like LW4o6, right? And it could be implemented stand-alone, without all the mesh code. And it could be listed on an RFP.

[Qi] IMHO, with MAP-E sticking to the native MAP algorithm, that it achieves stateless at the cost of 4-6 coupling and makes full use of MAP rules, MAP-E will not be that like LW4o6. LW4o6 is a per-subscriber stateful solution. Am i right?

Thanks!

Qi

---

From: Xing Li <[email-masked]>
Date: Tue, 21 Aug 2012 11:30:53 +0800

I support MAP-E as the basis for the proposed standard stateless 
solution. xing

---

From: [email-masked]
Date: Tue, 21 Aug 2012 14:02:23 +0800

Dear Chairs,

 I support MAP-E as the basis, and -T & 4rd as experimental/informational 
also.
 Thanks for the decision.

BRs.

Suresh Krishnan <[email-masked]> 
发件人:  [email-masked]
2012-08-08 06:02

收件人
Softwires WG <[email-masked]>
抄送

主题
[Softwires] Call for confirming the selection of MAP-E as the basis for 
the proposed standard stateless solution

Hi all,

Regards
Suresh & Yong

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Leaf yeh <[email-masked]>
Date: Tue, 21 Aug 2012 06:09:56 +0000

+ 1

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: Thursday, August 09, 2012 1:10 AM
To: Suresh Krishnan
Cc: Softwires WG
Subject: Re: [Softwires] Call for confirming the selection of MAP-E as the basis for the proposed standard stateless solution

In favor. 

- Mark

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 24 Aug 2012 16:58:10 +0200

Qi,

by definition a hub & spoke is a subset of mesh, which MAP supports
naturally. Any solution that seeks to exclude hub& spoke mode from mesh is
in conflict with that and as stated multiple times, precluding such use is
actually complicating the MAP solution, for no apparent benefit or
technical reason as it is a deployment choice.

Thanks,
Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 24 Aug 2012 17:39:04 +0200

Simon,

On 16 August 2012 15:19, Simon Perreault <[email-masked]>wrote:

> The elephant in the room is that a provider that only needs hub-and-spoke
> doesn't want to pay for the needless (subjectively) complexity of MAP.
>

> hub-and-spoke, described in a separate RFC, would look exactly like LW4o6,
> right? And it could be implemented stand-alone, without all the mesh code.
> And it could be listed on an RFP.
>

MAP already supports hub& spoke, as documented, and no it doesn't look like
LW4o6, since MAP allows the:
1. Ability to optimize the amount of configuration/rules required. Eg 1
rule can cover millions of end points.
2. Ability to optimize traffic forwarding (which gets referred to as mesh
mode).

-Woj.

> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.**ca<http://postellation.viagenie.ca>
> ______________________________**_________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires>
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 11:50:02 -0400

Le 2012-08-24 11:39, Wojciech Dec a écrit :
>     Here's an idea: a restricted "profile" of MAP-E that would only
>     allow hub-and-spoke, described in a separate RFC, would look exactly
>     like LW4o6, right? And it could be implemented stand-alone, without
>     all the mesh code. And it could be listed on an RFP.
>
>
> MAP already supports hub& spoke, as documented, and no it doesn't look
> like LW4o6, since MAP allows the:
> 2. Ability to optimize traffic forwarding (which gets referred to as
> mesh mode).

Looks like my idea wasn't well understood. Let me try again...

RFC A: defines MAP as we know it.
RFC B: defines a hub-and-spoke only subset of MAP. refers to A.

My assumption is that RFC B would look very much like LW4o6.

An ISP needing only hub-and-spoke would cite RFC B in an RFP. The vendor 
would be free to implement RFC B without full support for A. A full 
implementation of RFC A would also implicitly be an implementation of B.

Just an idea, trying to find a way forward...

Simon

---

From: Mark Townsley <[email-masked]>
Date: Fri, 24 Aug 2012 21:52:40 +0200

> An ISP needing only hub-and-spoke would cite RFC B in an RFP. The vendor would be free to implement RFC B without full support for A. A full implementation of RFC A would also implicitly be an implementation of B.

We cannot have a standards track protocol RFC coming out of softwires for every manner in which a technology might show up in an RFP. This simply does not scale.

What we can have is as many informational use-case documents as v6ops is willing to shepherd.  

So, I suggest we let softwires produce as few standards-track alternatives as possible for base technology that can be used to meet the needs of as many operators as possible. If an operator wants to share how that technology is used in a specific manner, tradeoffs made, specific topologies and configuration, etc. via a BCP, Informational or Experimental document in the operations area, fantastic! We need real world feedback on how the technology is and is not being used. If an ISP wants to reference said operations document as advice for how they intend to use the softwires protocol in an RFP, that's fine too, but let's try and keep *this* group focused on as few base technologies (read: fewer standards track RFCs) as possible.

- Mark

---

From: Leaf yeh <[email-masked]>
Date: Sat, 25 Aug 2012 03:54:18 +0000

Simon - Here's an idea: a restricted "profile" of MAP-E that would only allow 
hub-and-spoke, described in a separate RFC, would look exactly like 
LW4o6, right?

I believe the 'F-flag' defined in section 4.2 of draft-ietf (MAP_DHCP, ver.-00 or -01, https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp/?include_text=1 ) already make MAP to support H&S mode. If the BMR is set with F-flag=0, that does mean H&S for MAP, because BMR will not be used for the packet forwarding... 

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Thursday, August 16, 2012 9:19 PM
To: [email-masked]
Subject: Re: [Softwires] Hub&Spoke of MAP-E

Simon

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 28 Aug 2012 12:45:39 +0200

On 8/24/12 9:52 PM, Mark Townsley wrote:
> We cannot have a standards track protocol RFC coming out of softwires
> for every manner in which a technology might show up in an RFP. This
> simply does not scale.

+1

we need a procurement guidance document then how to use all of those :)

Cheers, Jan