Subject: [Softwires] A new consensus opportunity with a MAP-bis

From: Rémi Després <[email-masked]>
Date: Fri, 22 Jun 2012 18:52:24 +0200

Yong, Suresh, Ralph,

For mesh stateless v4/v6, we have so far a choice between only two solutions, MAP as is and 4rd.
On can hope that the consensus that couldn't be reached in Paris will be achievable in Vancouver, but this isn't sure, each "camp" keeping its own expectation.

Looking at recent history, we can remember that, not long ago, the chair's approach was to have 3 specifications completed (MAP-T, MAP-E, and MAP-H, as Alain called it with H for Hybrid), and then to choose only one for standardization.

After that, promoters of either -T and -E decided to merge -T and -E in a non-separable specification, as reflected in draft-ietf-softwire-map-00. 
Thus, the choice has become between a "two-variants" specification (MAP) and a "single-variant" specification (4rd).

In this context, a larger choice might well be the best chance for a WG consensus. It would include a MAP specification in which the forwarding mode of 4rd would be added as 3rd, say a "MAP-bis" . 
With this MAP-bis:
- vendors have to support 3 forwarding modes, which isn't ideal, but most of the design, in particular in what concerns mapping rules, remains common (Alain once said, possibly with optimism, the three were 99% identical!) 
- operators have a free choice between T, E, or H, based on their operational preferences.
- we have (at last) a stabilized design with no one badly frustrated.

If this approach makes sense for the WG, I can do the work of editing a MAP-bis proposal (taking the current MAP specification, adding a section that describes the hybrid forwarding mode, and adding a third variant in the address-format section). 

My personal preference remains for 4rd as single standard, but a choice between MAP-as-is, MAP-bis, and 4rd, is IMHO a sounder choice for the WG than just between MAP-as-is and 4rd.

Hoping that this will be found constructive,
Best regards,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Sat, 23 Jun 2012 17:52:03 +0900

Dear Remi,

Thank you for a kind offer. It would be a very positive compromise for us.

However, in the context of making another new stream document, which MAP-bis as you said, I decline it. Nevertheless, if you abandon 4rd work, I'm very welcome you as an author of MAP.

Best regards,
--satoru

On 2012/06/23, at 1:52, Rémi Després wrote:

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

---

From: Tetsuya Murakami <[email-masked]>
Date: Mon, 25 Jun 2012 06:24:06 +0000

+1.

Making another new document might cause more confusion. But if 4rd work is stopped and merged to MAP, it might be good. But from the implementation point of view, I would like to eliminate the complicated code as much as possible such as

if (MAP-E)
...
else if (MAP-T)
...
else if (MAP-H)
...

But this is the implementation/deployment choice. So, from the standard perspective, it might be good to merge H solution to MAP which has already merged both E and T.

Thanks,
Tetsuya Murakami

---

From: Mark Townsley <[email-masked]>
Date: Mon, 25 Jun 2012 10:39:53 +0200

If we can find a way to collapse H and T such that we are back to one "encap/decap" and one "entrans/detrans" version, I think this would be significant progress.  3 options here just seems ridiculous though. 

- Mark

---

From: Rémi Després <[email-masked]>
Date: Thu, 28 Jun 2012 19:05:50 +0200

> Thank you for a kind offer. It would be a very positive compromise for us.

I think we are making progress. Thanks.

> However, in the context of making another new stream document, which MAP-bis as you said, I decline it. Nevertheless, if you abandon 4rd work, I'm very welcome you as an author of MAP.

Well, the idea is only to introduce one more possibility for the choice the WG will have to mùake. The three alternatives become:
a. T+E (the current map proposal)
b. H alone (the current 4rd proposal)
c. T+E+H (whatever its name...  MAP-T+E+H, 4rd-T+E+H, anything)

With the third combination:
- T is still included, thus satisfying some firm requests that justified MAP-T+E
- E is still included, thus satisfying some firm requests that justified MAP-T+E
- H is available, thus satisfying some firm requests that justified 4rd (ability to combine complete IPv4 transparency with IPv6-ACL compatibility)  

How to introduce this 3rd choice in WG documents is AFAIK in chairs' hands.

Regards,
RD