Subject: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt

From: [email-masked]
Date: Mon, 12 Aug 2013 05:16:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Softwires Working Group of the IETF.

	Title           : Mapping of Address and Port with Encapsulation (MAP)
	Author(s)       : Ole Troan
                          Wojciech Dec
                          Xing Li
                          Congxiao Bao
                          Satoru Matsushima
                          Tetsuya Murakami
                          Tom Taylor
	Filename        : draft-ietf-softwire-map-08.txt
	Pages           : 30
	Date            : 2013-08-12

Abstract:
   This document describes a mechanism for transporting IPv4 packets
   across an IPv6 network using IP encapsulation, and a generic
   mechanism for mapping between IPv6 addresses and IPv4 addresses and
   transport layer ports.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-map

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-softwire-map-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Mon, 12 Aug 2013 15:53:22 +0200

Ole, all,

I have two comments about the new version:

* The document does not cite the unified CPE I-D. I think Senthil already raised this point to the authors, but it seems this was not taken into account. I suggest adding that document as a normative reference.
 
* I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve provisioning (other means can be supported). This ref can be cited as informative and not normative one.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]]
>De la part de [email-masked]
>Envoyé : lundi 12 août 2013 14:17
>À : [email-masked]
>Cc : [email-masked]
>Objet : I-D Action: draft-ietf-softwire-map-08.txt
>
>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 13 Aug 2013 15:05:22 +0900

Hi Med, thank you for your comments.

When I did review the current version of unified cpe draft, I couldn't find
any kind of stuff on which the map draft should depend so please point
things out more specific to what unified cpe draft want map to be.

cheers,
--satoru

On Mon, Aug 12, 2013 at 10:53 PM, <[email-masked]> wrote:

> * The document does not cite the unified CPE I-D. I think Senthil already
> raised this point to the authors, but it seems this was not taken into
> account. I suggest adding that document as a normative reference.
>
> * I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve
> provisioning (other means can be supported). This ref can be cited as
> informative and not normative one.
>
> Cheers,
> Med
>
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Aug 2013 09:34:19 +0200

Med,

> * The document does not cite the unified CPE I-D. I think Senthil already raised this point to the authors, but it seems this was not taken into account. I suggest adding that document as a normati…

the unified CPE document depends on MAP, not the other way around. 

> * I-D.ietf-softwire-map-dhcp is to be listed as an example to achieve provisioning (other means can be supported). This ref can be cited as informative and not normative one.

true, the reason it is listed as normative is because we have a SHOULD for DHCP:
   "A CE that allows IPv6 configuration by DHCP SHOULD implement this option."

cheers,
Ole

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 11:10:07 +0200

Hi Satoru,

Provisioning-related discussion should be included in the unified CPE not in each individual document. This is true for MAP, lw4o6, etc.
Ensuring a coherency among ongoing specification documents will require a coordination effort among existing documents.

Cheers,
Med

De : Satoru Matsushima [mailto:[email-masked]]
Envoyé : mardi 13 août 2013 08:05
À : BOUCADAIR Mohamed OLNC/OLN
Cc : [email-masked]
Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt

When I did review the current version of unified cpe draft, I couldn't find any kind of stuff on which the map draft should depend so please point things out more specific to what unified cpe draft want map to be.

cheers,
--satoru

On Mon, Aug 12, 2013 at 10:53 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Ole, all,

Cheers,
Med

>De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
>De la part de [email-masked]<mailto:[email-masked]>
>À : [email-masked]<mailto:[email-masked]>
>Cc : [email-masked]<mailto:[email-masked]>
>until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
>[email-masked]<mailto:[email-masked]>
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 11:11:25 +0200

Hi Ole,

The documents should be cross-references, that's clear. 

If I recall well what was discussed (and which I assumed agreed) in Atlanta, is the unified CPE draft governs the CE side for all softwire flavors. The consequence is provisioning discussion in particular should be removed from MAP, LW4ov6, etc documents ... instead be discussed exclusively in the unified CPE I-D. 

I will refer to Suresh on this point since he was present during that discussion and also because this is a action to preserve the coherency of the overall ongoing specification efforts conducted by the WG.

Cheers,
Med

>De : Ole Troan [mailto:[email-masked]]
>Envoyé : mardi 13 août 2013 09:34

---

From: Maoke <[email-masked]>
Date: Tue, 13 Aug 2013 18:26:06 +0900

hi Med and others,

IMHO, MAP doesn't depend on any specific provisioning methodology and even
manual configuration works well. on the other hand, unified CPE should
define a certain method that suitable for both MAP and lw4o6. This
difference/relationship doesn't support the bi-directional mutual citation.

- maoke

2013/8/13 <[email-masked]>

> Hi Satoru,****
>
> ** **
>
> Provisioning-related discussion should be included in the unified CPE not
> in each individual document. This is true for MAP, lw4o6, etc. ****
>
> Ensuring a coherency among ongoing specification documents will require a
> coordination effort among existing documents.  ****
>
> ** **
>
> Cheers,****
>
> Med****
>
> ** **
>
> *De :* Satoru Matsushima [mailto:[email-masked]]
> *Envoyé :* mardi 13 août 2013 08:05
> *À :* BOUCADAIR Mohamed OLNC/OLN
> *Cc :* [email-masked]
> *Objet :* Re: [Softwires] I-D Action: draft-ietf-softwire-map-08.txt****
>
> ** **
>
> Hi Med, thank you for your comments.****
>
> ** **
>
> When I did review the current version of unified cpe draft, I couldn't
> find any kind of stuff on which the map draft should depend so please point
> things out more specific to what unified cpe draft want map to be.****
>
> ** **
>
> cheers,****
>
> --satoru****
>
> ** **
>
> On Mon, Aug 12, 2013 at 10:53 PM, <[email-masked]> wrote:***
> *
>
> Ole, all,
>
> >Objet : I-D Action: draft-ietf-softwire-map-08.txt****
>
> >
> >
> >_______________________________________________****
>
> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt****
>
> https://www.ietf.org/mailman/listinfo/softwires****
>
> ** **
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Aug 2013 11:45:54 +0200

Med,

> I will refer to Suresh on this point since he was present during that discussion and also because this is a action to preserve the coherency of the overall ongoing specification efforts conducted b…

the MAP document only specifies how a CE must function and what parameters must be provisioned. there is no provisioning discussion there to remove as far as I can see. MAP as a mechanism should stand on its own.

the unified CPE effort, if successful, is trying to create a coherent picture of all the different mechanisms to make it possible to support all of them in a single CPE. my understanding of the unified CPE effort was that it was NOT going to define protocol, but only specify how mechanisms co-exist.

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Tue, 13 Aug 2013 18:11:11 +0800

Hi Ole ,

IMHO, the Unified CPE defines some functionalities and behaviors of CE side, e.g. tunnel endpoint, NAT44, how to use these functions on CPE etc., which MAP depends on. 

As for the provisioning method, map-dhcp is one of the methods could be used in MAP. The discussion is taking place in the Unified CPE for provisioning. So I think it should be an informative reference in MAP base draft.

Best Regards,
Qi

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Aug 2013 13:15:42 +0200

Qi,

> As for the provisioning method, map-dhcp is one of the methods could be used in MAP. The discussion is taking place in the Unified CPE for provisioning. So I think it should be an informative refer…

so you are saying that draft-ietf-softwire-map cannot stand on its own, but depend on text in unified CPE?
if so, what is missing? which parts of the unified CPE draft should be referenced? please propose text changes to the document.

I am open to the possibility that I'm wrong of course, but I can't know that for sure, before I see what text changes you propose.
I'm not trying to be difficult (at least not more than usual), but the document has passed WGLC, and we're restrictive about accepting changes.

cheers,
Ole

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 13:58:48 +0200

Re-,

It seems we agree on the provisioning part of the discussion. The MAP document should be sufficient in its own and should not make any assumption on how configuration parameters are provisioned. This can be done manually or dynamically (e.g., dhcp). So, any reference to a provisioning means should be informative, and even better be removed in favor of a single pointer to the unified CPE, where all this is discussed. 

Then, to the question why I'm asking for this I-D to be referenced as normative and not informative, the answer is that the generic bootstrapping logic described in the unified CPE must be followed by all softwire solution flavors. That's the minimum bar I see if we really want all a consistency to be ensured. Ideally, the CE part of all solutions should be documented in the unified CPE while the BR/lwAFTR parts in MAP and lw4o6 document, but I won't ask for that.

Cheers,
Med

>Envoyé : mardi 13 août 2013 11:46
>> If I recall well what was discussed (and which I assumed agreed) in
>Atlanta, is the unified CPE draft governs the CE side for all softwire
>flavors. The consequence is provisioning discussion in particular should be
>removed from MAP, LW4ov6, etc documents ... instead be discussed
>exclusively in the unified CPE I-D.
>>
>> I will refer to Suresh on this point since he was present during that
>discussion and also because this is a action to preserve the coherency of
>the overall ongoing specification efforts conducted by the WG.
>
>the MAP document only specifies how a CE must function and what parameters
>must be provisioned. there is no provisioning discussion there to remove as
>far as I can see. MAP as a mechanism should stand on its own.
>
>the unified CPE effort, if successful, is trying to create a coherent
>picture of all the different mechanisms to make it possible to support all
>of them in a single CPE. my understanding of the unified CPE effort was
>that it was NOT going to define protocol, but only specify how mechanisms
>co-exist.
>
>cheers,
>Ole

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 14:12:17 +0200

Re-,

Yes, there is a WGLC but this does not mean that the document as it is solves all raised issues. Senthil did already raised this point to the authors of MAP and MAP-T drafts in June 19, but unless I'm mistaken I didn't saw a follow up to his request. 

I hope we can close this point ASAP so that the MAP document can move forward.

Thanks.
Cheers,
Med

>Envoyé : mardi 13 août 2013 13:16
>À : Qi Sun
>Cc : BOUCADAIR Mohamed OLNC/OLN; [email-masked]
>> IMHO, the Unified CPE defines some functionalities and behaviors of CE
>side, e.g. tunnel endpoint, NAT44, how to use these functions on CPE etc.,
>which MAP depends on.
>>
>> As for the provisioning method, map-dhcp is one of the methods could be
>used in MAP. The discussion is taking place in the Unified CPE for
>provisioning. So I think it should be an informative reference in MAP base
>draft.
>
>if so, what is missing? which parts of the unified CPE draft should be
>referenced? please propose text changes to the document.
>
>I am open to the possibility that I'm wrong of course, but I can't know
>that for sure, before I see what text changes you propose.
>I'm not trying to be difficult (at least not more than usual), but the
>document has passed WGLC, and we're restrictive about accepting changes.
>
>cheers,
>Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Aug 2013 14:18:31 +0200

Med,

> Then, to the question why I'm asking for this I-D to be referenced as normative and not informative, the answer is that the generic bootstrapping logic described in the unified CPE must be followed…

I see the relationship between the documents in the opposite way.
there are 2-5 independent mechanisms. the unified CPE document describes how these can be provisioned and ensures there is some consistency between how a CPE can support all the mechanisms. the unified CPE document was never intended to drive changes in the protocol specifications of the mechanisms themselves.

I'm not necessarily against removing the normative reference to the MAP DHCP draft. I am against a reference to the unified DHCP document. reason being as I stated above, there should not be a dependency from MAP to DHCP. there is also the issue of not blocking MAP document progress waiting for the progress of the unified CPE document.

cheers,
Ole

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 14:39:27 +0200

Re-,

We both agree there is no justification to maintain the dhcp draft in the normative section. I consider that point closed and will wait to see this fixed in the document. Given that this document does not rely on how provisioning is achieved and given the unified CPE is where this is supposed to be discussed, I do still think any reference to provisioning should refer to the unified CPE. 

It really does not make sense to not require the CE to follow the unified CPE behavior (in particular http://tools.ietf.org/html/draft-ietf-softwire-unified-cpe-01#section-3.2) if we want a minimum of coherency among the solutions discussed so far. 

I don't think that referring to the unified CPE draft will block the publication of the MAP document. This is not a technical reason BTW.

If we maintain the same positive energy as we have started to do in the Atlanta meeting, I do think that we will be able to deliver all these documents as a package. 

I hope this issue can be resolved ASAP.

Cheers,
Med

>Envoyé : mardi 13 août 2013 14:19
>> It seems we agree on the provisioning part of the discussion. The MAP
>document should be sufficient in its own and should not make any assumption
>on how configuration parameters are provisioned. This can be done manually
>or dynamically (e.g., dhcp). So, any reference to a provisioning means
>should be informative, and even better be removed in favor of a single
>pointer to the unified CPE, where all this is discussed.
>>
>> Then, to the question why I'm asking for this I-D to be referenced as
>normative and not informative, the answer is that the generic bootstrapping
>logic described in the unified CPE must be followed by all softwire
>solution flavors. That's the minimum bar I see if we really want all a
>consistency to be ensured. Ideally, the CE part of all solutions should be
>documented in the unified CPE while the BR/lwAFTR parts in MAP and lw4o6
>document, but I won't ask for that.
>
>there are 2-5 independent mechanisms. the unified CPE document describes
>how these can be provisioned and ensures there is some consistency between
>how a CPE can support all the mechanisms. the unified CPE document was
>never intended to drive changes in the protocol specifications of the
>mechanisms themselves.
>
>I'm not necessarily against removing the normative reference to the MAP
>DHCP draft. I am against a reference to the unified DHCP document. reason
>being as I stated above, there should not be a dependency from MAP to DHCP.
>there is also the issue of not blocking MAP document progress waiting for
>the progress of the unified CPE document.
>
>cheers,
>Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Aug 2013 15:00:03 +0200

Med,

> We both agree there is no justification to maintain the dhcp draft in the normative section. I consider that point closed and will wait to see this fixed in the document. Given that this document d…

"not necessarily against...", is quite far from agree. ;-)
MAP doesn't discuss the details of provisioning, but it does have a SHOULD to implement the MAP DHCP option. the reason for this is so that all MAP implementations at least support one provisioning mechanism in common.

does the unified CPE propose something conflicting with the current text in MAP?
(the temptation is of course to remove the normative reference, given that progress on a 'unified' DHCP option is slow).

> It really does not make sense to not require the CE to follow the unified CPE behavior (in particular http://tools.ietf.org/html/draft-ietf-softwire-unified-cpe-01#section-3.2) if we want a minimum…

that's for the unified CPE document to say.

> I don't think that referring to the unified CPE draft will block the publication of the MAP document. This is not a technical reason BTW.

no, it is not a technical reason. it is a design goal to keep MAP independent of the other mechanisms, i.e. it must be possible to implement routers that only support MAP and no other of the mechanisms.

> If we maintain the same positive energy as we have started to do in the Atlanta meeting, I do think that we will be able to deliver all these documents as a package. 

positive energy is good! might be a little misplaced here though. ;-)
to me it looks like we've moved the contentious parts that led to all of DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to the DHCP/unified CPE documents.

cheers,
Ole

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 15:46:11 +0200

Re-,

It seems we are in disagreement here. Looking to have more feedback for the list.

Thanks for engaging.

Cheers,
Med

>Envoyé : mardi 13 août 2013 15:00
>> We both agree there is no justification to maintain the dhcp draft in the
>normative section. I consider that point closed and will wait to see this
>fixed in the document. Given that this document does not rely on how
>provisioning is achieved and given the unified CPE is where this is
>supposed to be discussed, I do still think any reference to provisioning
>should refer to the unified CPE.
>
>MAP doesn't discuss the details of provisioning, but it does have a SHOULD
>to implement the MAP DHCP option. the reason for this is so that all MAP
>implementations at least support one provisioning mechanism in common.
>
>(the temptation is of course to remove the normative reference, given that
>progress on a 'unified' DHCP option is slow).
>
>> It really does not make sense to not require the CE to follow the unified
>CPE behavior (in particular http://tools.ietf.org/html/draft-ietf-softwire-
>unified-cpe-01#section-3.2) if we want a minimum of coherency among the
>solutions discussed so far.
>
>> I don't think that referring to the unified CPE draft will block the
>publication of the MAP document. This is not a technical reason BTW.
>
>no, it is not a technical reason. it is a design goal to keep MAP
>independent of the other mechanisms, i.e. it must be possible to implement
>routers that only support MAP and no other of the mechanisms.
>
>> If we maintain the same positive energy as we have started to do in the
>Atlanta meeting, I do think that we will be able to deliver all these
>documents as a package.
>
>to me it looks like we've moved the contentious parts that led to all of
>DS-lite, MAP-E, MAP-T, 4rd, LW46, Public 4over6 and no consensus to the
>DHCP/unified CPE documents.
>
>cheers,
>Ole

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 13 Aug 2013 23:17:42 +0900

Med,

I didn't think that unified CPE draft is to govern specific solution. But I find out that MAP must refer unified CPE draft as a normative ref in the case of MAP IS the unified solution, make sense?

cheers,
--satoru

---

From: Maoke <[email-masked]>
Date: Wed, 14 Aug 2013 11:31:36 +0900

my technical understanding on this issue:

1. (the reason of using unified CPE) unified CPE is a sort of CPE that is
used by an ISP that wants to
    A. simultaneously deploy MAP and lw4o6 and 4rd (and/or something else,
out-of-scope or not?) there and here respectively but doesn't want to
distinguish the device distribution among those subscribers;
    B. potentially deploy MAP or lw4o6 according to backbone strategy but
currently hasn't be sure there will be no change in the future and
therefore doesn't like to leave limitations at the subscribers' side.
    C. deploy either MAP or lw4o6 but doesn't care what to distribute to
the subscribers as long as compatibility is ensured.

2. (the reason of not using unified CPE) for some ISPs, they may not use
unified CPE because
    A. they are clearly know they only need either MAP or lw4o6 and does
want to use the MAP- or lw4o6-specific devices with MAP- or lw4o6-oriented
optimization, with the low cost corresponding to supporting only one
protocol;
    B. they are concerning the future extensions of MAP, e.g. the
inter-domain operation (making a cross-ISP MAP domain), where the
MAP-specific implementation is needed while current unified CPE is unsure
of supporting that.

for the 2B, i don't argue it is a problem that currently the unified CPE
doesn't cover any topic of cross-ISP provisioning at all. i do accept it is
an issue out of the scope of the unified CPE --- including this topic, too
early to discuss for most people, into unified CPE draft may delay its
progress much more.

but i worry, if citing unified CPE, the MAP as an architecture
specification might become restricted so that inter-domain (and potentially
other) extensions may not be available. we have logically checked current
MAP does work in an inter-domain environment (of course, currently only
through manual configuration) and we don't like this feature is hurt by any
extra, not much necessary references. unified CPE is about an
implementation while MAP draft is architecture specification. generally
speaking, an architecture specification should stand on itself rather than
depending upon any specific implementation.

if the citation is DEFINITELY needed for any non-technical reason, the
above explanation on the understanding  must also be included in order to
avoid any misleading or restrictions on extensive usage.

cheers,
- maoke

> >does the unified CPE propose something conflicting with the current text
> in
> >MAP?
> >CPE behavior (in particular
> http://tools.ietf.org/html/draft-ietf-softwire-

---

From: <[email-masked]>
Date: Wed, 14 Aug 2013 17:20:57 +0200

Hi Ole,

I'm a little late to the conversation, but picking up on
http://www.ietf.org/mail-archive/web/softwires/current/msg05636.html

Cheers,
Ian

>being as I stated above, there should not be a dependency from MAP to
>DHCP. there is also the issue of not blocking MAP document progress
>waiting for the progress of the unified CPE document.

[ian] There is no Unified DHCP document. The Unified CPE doc describes
generic logic for using parameters, rather than how those parameters are
provisioned. Section 3.3 does describe how this is applied using DHCP as
an example (based on softwire-map-dhcp), though it states that other
methods may be used. It states that DHCP provisioning should be
implemented.

Is this the (technical) problem between the two? If we align the
requirement for implementing DHCP based provisioning between the two
drafts, does that fix the first issue above?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2013 09:10:21 +0200 (CEST)

> the subscribers as long as compatibility is ensured.

D. Customer buys a retail box that should be plug and play in any 
provider network regardless of what mechanism the provider supports.

-- 
Mikael Abrahamsson    email: [email-masked]