Subject: [Softwires] Changes to DHCP MAP Option draft

From: Wojciech Dec <[email-masked]>
Date: Mon, 8 Jul 2013 12:18:31 +0200

Hi All,

I've begun preparing the next ste of changes to the DHCP MAP option draft,
and would like to highlight the main changes.

- Naming: The name of the option will be changed, tentatively, to
OPTION_S46_*. This it in line with the recognition that there is wider
applicability of the options. Furthermore the "Mapping" term will be
removed from the text, except when describing their use with MAP algorithm.
- Default Mapping Rule: The DMR option will be removed, to allow the re-use
of the existing AFTR option, if desired and when applicable.
- Flags: The flags field will be removed from the options. To accomplish
this, what was previously known as the BMR/FMR option, which was using the
flag to make the difference, will now be recast as two separate "Basic
Rule" and a "Forwarding Rule" Options.
- Some of the generic DHCP requirements about known or unknown processing
appear to actually conflict with DHCP practice and will be changed, eg an
unknown sub-option should not lead to the entire option being discarded.
- A new sub-section intended only for clients using the MAP algorithm will
be introduced, and will describe how the options apply to MAP provisioning.
- Various other editorial changes to bring the text into shape.

If you have any initial comments, reactions to the above, please let us
know.

Regards,
W. Dec

---

From: Qi Sun <[email-masked]>
Date: Thu, 11 Jul 2013 21:04:25 +0800

Hi Woj,

> - Naming: The name of the option will be changed, tentatively, to OPTION_S46_*. This it in line with the recognition that there is wider applicability of the options.

Would you please elaborate (sorry if I missed some of the discussions...)? 

> - Flags: The flags field will be removed from the options. To accomplish this, what was previously known as the BMR/FMR option, which was using the flag to make the difference, will now be recast as two separate "Basic Rule" and a "Forwarding Rule" Options.

From my understanding, the 'flags' are referred to those in MAP Rule Option (rule-flags), right? Or do you mean the flags in MAP Container Option will also be removed?

> - A new sub-section intended only for clients using the MAP algorithm will be introduced, and will describe how the options apply to MAP provisioning.

I'm not quite sure about the content that you plan to provide. IMHO, the DHCPv6 client (not a MAP DHCPv6 client) is only able to handle the DHCPv6 related interactions, rather than MAP related interactions. If this part is about how the client side uses the MAP options, maybe the MAP-E or the Unified CPE is a more proper place to go, IMHO.

In addition, I notice in the current MAP option draft, the offset in MAP Port Parameters Option is still 4, which is not consistent with the draft-ietf-softwire-map-07. Maybe you can update it as well.

Best Regards,
Qi

On 2013-7-8, at 下午6:18, Wojciech Dec wrote:

> Hi All,
> 
> I've begun preparing the next ste of changes to the DHCP MAP option draft, and would like to highlight the main changes.
> 
> - Naming: The name of the option will be changed, tentatively, to OPTION_S46_*. This it in line with the recognition that there is wider applicability of the options. Furthermore the "Mapping" term will be removed from the text, except when describing their use with MAP algorithm.
> - Default Mapping Rule: The DMR option will be removed, to allow the re-use of the existing AFTR option, if desired and when applicable.
> - Flags: The flags field will be removed from the options. To accomplish this, what was previously known as the BMR/FMR option, which was using the flag to make the difference, will now be recast as two separate "Basic Rule" and a "Forwarding Rule" Options.
> - Some of the generic DHCP requirements about known or unknown processing appear to actually conflict with DHCP practice and will be changed, eg an unknown sub-option should not lead to the entire option being discarded.
> - A new sub-section intended only for clients using the MAP algorithm will be introduced, and will describe how the options apply to MAP provisioning.
> If you have any initial comments, reactions to the above, please let us know.
> 
> Regards,
> W. Dec
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 11 Jul 2013 16:43:36 +0200

Hi,

On 11 July 2013 15:04, Qi Sun <[email-masked]> wrote:

> applicability of the options.
>

Yes, there was a long thread started by Tomek. Given that the option is
applicable beyond MAP a *suggestion* was to rename it. I'm personally ok
either way. The "Softwire46" option is the currently proposed name.

> From my understanding, the 'flags' are referred to those in MAP Rule
> Option (rule-flags), right? Or do you mean the flags in MAP Container
> Option will also be removed?
>

All flag fields removed.

>
> > - A new sub-section intended only for clients using the MAP algorithm
> will be introduced, and will describe how the options apply to MAP
> provisioning.
>
> I'm not quite sure about the content that you plan to provide. IMHO, the
> DHCPv6 client (not a MAP DHCPv6 client) is only able to handle the DHCPv6
> related interactions, rather than MAP related interactions. If this part is
> about how the client side uses the MAP options, maybe the MAP-E or the
> Unified CPE is a more proper place to go, IMHO.
>

Well, the MAP Port Parameters option is clearly only applicable to a client
that understands what it means. While having a separate, standalone 1-page
draft for this single option is doable, it does become to look like
unnecessary bureaucracy. DHCP Options are options after all...

>
> In addition, I notice in the current MAP option draft, the offset in MAP
> Port Parameters Option is still 4, which is not consistent with the
> draft-ietf-softwire-map-07. Maybe you can update it as well.
>

Yes, that will be updated.

Thanks,
Woj.

> > I've begun preparing the next ste of changes to the DHCP MAP option
> draft, and would like to highlight the main changes.
> >
> > - Default Mapping Rule: The DMR option will be removed, to allow the
> re-use of the existing AFTR option, if desired and when applicable.
> > - Some of the generic DHCP requirements about known or unknown
> processing appear to actually conflict with DHCP practice and will be
> changed, eg an unknown sub-option should not lead to the entire option
> being discarded.
> > - A new sub-section intended only for clients using the MAP algorithm
> will be introduced, and will describe how the options apply to MAP
> provisioning.

---

From: Qi Sun <[email-masked]>
Date: Fri, 12 Jul 2013 10:48:10 +0800

Hi Woj,

On 2013-7-11, at 下午10:43, Wojciech Dec wrote:

> Hi,
> 
> 
> Yes, there was a long thread started by Tomek. Given that the option is applicable beyond MAP a *suggestion* was to rename it. I'm personally ok either way. The "Softwire46" option is the currently proposed name.

[Qi] At the first glance, I thought it stood for "Stateless46" option... (sorry for missing the discussion)

> From my understanding, the 'flags' are referred to those in MAP Rule Option (rule-flags), right? Or do you mean the flags in MAP Container Option will also be removed?

[Qi] If so, how could a MAP node finds out it should work as MAP-E or MAP-T? Or we can take this MAP DHCP draft as "MAP-E DHCP"? 

> Well, the MAP Port Parameters option is clearly only applicable to a client that understands what it means. While having a separate, standalone 1-page draft for this single option is doable, it does become to look like unnecessary bureaucracy. DHCP Options are options after all...

[Qi] So this sub-section is about the behaviors of the client after receiving the MAP Port Parameters Option? 

Best Regards,
Qi

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 15 Jul 2013 15:29:34 +0000

Since this is a WG draft, did the authors ask the WG to update this? When
the WG accepted this draft, it was only for MAP. But seems the scope has
been changed. This should start as an Individual draft. I will recommend to
revert back to the last version and present this in Berlin to replace the
MAP draft if the WG agrees with it.

From:  Wojciech Dec <[email-masked]>
Date:  Thursday, July 11, 2013 10:43 AM
To:  Qi Sun <[email-masked]>
Cc:  Softwires-wg <[email-masked]>
Subject:  Re: [Softwires] Changes to DHCP MAP Option draft

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 15 Jul 2013 18:01:15 +0200

Yes. See Mail of July 8. So far your objection is the only one, although I
don't quite see in it any technically grounded objection.
A fair bit of discussions between authors (MAP and lw46), softwire & dhc
chairs, and WG participants have taken place, and naturally will also be
held in Berlin.

Re-spinning draft versions is easy.

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 15 Jul 2013 16:48:37 +0000

Woj,

I am not objecting it. I just stated the new draft has been updated the
scope w/o getting explicit consent from the ML.

BR,
Yiu

From:  Wojciech Dec <[email-masked]>
Date:  Monday, July 15, 2013 12:01 PM
To:  "Yiu L. LEE" <[email-masked]>
Cc:  Softwires-wg <[email-masked]>
Subject:  Re: [Softwires] Changes to DHCP MAP Option draft

On 15 July 2013 17:29, Lee, Yiu <[email-masked]> wrote:
> Since this is a WG draft, did the authors ask the WG to update this? When the
> WG accepted this draft, it was only for MAP. But seems the scope has been
> changed. This should start as an Individual draft. I will recommend to revert
> back to the last version and present this in Berlin to replace the MAP draft
> if the WG agrees with it.
> 
>

---

From: Qi Sun <[email-masked]>
Date: Tue, 16 Jul 2013 01:41:29 +0800

Hi Woj ,

The scope of the document has changed dramatically. I think it necessary to get more consensus from the WG to do so. From my reading, it's something different from the draft-ietf-softwire-map-dhcp. It's more like a 'unified-dhcp'. We need more discussing on this.

Best Regards,
Qi

On 2013-7-16, at 上午12:01, Wojciech Dec wrote:

> Yes. See Mail of July 8. So far your objection is the only one, although I don't quite see in it any technically grounded objection.
> A fair bit of discussions between authors (MAP and lw46), softwire & dhc chairs, and WG participants have taken place, and naturally will also be held in Berlin.
> 
> Since this is a WG draft, did the authors ask the WG to update this? When the WG accepted this draft, it was only for MAP. But seems the scope has been changed. This should start as an Individual draft. I will recommend to revert back to the last version and present this in Berlin to replace the MAP draft if the WG agrees with it.
> 
>

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 15 Jul 2013 20:25:35 +0200

Hi Qi,

the scope  remains unchanged: Define DHCPv6 options for CPEs that a MAP CPE
can use. It so happens that these same options can be used by any A+P CPE,
and I have previously made the case that most of the existing proposals can
use the same scheme of dhcp options: Please see -
http://www.ietf.org/proceedings/84/slides/slides-84-softwire-13.pdf. This
was the document that actually paved for discussion of what then became the
uCPE.
What more, based on the prototype implementations of the options defined in
draft-ietf-map-dhcp-03 we know that they were perfectly capable of
addressing MAP, Lw46, ds-lite, etc, CPEs. The fact that they have changed
is to address the expressed reservations from parties about the options
being "too MAP specific", about flags, naming, etc. I gave the outline of
those changes before publishing, and they were also the subject of
discussion by numerous parties (not just authors) before.

Anyway, for me, the previous "MAP centric" draft was ready for WG last call
(bar a few edits). The changes made in -04 reflect the desire to actually
have a set of options that address common concerns that apply to A+P.
Perhaps you could explain what is the issue in this that needs to be
discussed?

Alternatively, we can proceed to nail any outstanding technical issues and
have the draft sail quickly.

Thanks.
Woj.

On 15 July 2013 19:41, Qi Sun <[email-masked]> wrote:

>
> Hi Woj ,
>
> The scope of the document has changed dramatically. I think it necessary
> to get more consensus from the WG to do so. From my reading, it's something
> different from the draft-ietf-softwire-map-dhcp. It's more like a
> 'unified-dhcp'. We need more discussing on this.
>
>
> Best Regards,
> Qi
>
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 17 Jul 2013 22:25:55 +0200

> scope w/o getting explicit consent from the ML.
The proposed unification of DHCP provisioning method was discussed at
length during last meeting (and I think in Atlanta as well). See
minutes: http://www.ietf.org/proceedings/86/minutes/minutes-86-softwire

Here's the relevant part (excellent notes btw):

Tomek: Should the draft be kept as it is with a new name?
Suresh: It is not so important to change the name. Makes sense to fold
this into the MAP DHCP document.

Also see Ian's presentation from Orlando:
http://www.ietf.org/proceedings/86/slides/slides-86-softwire-3.pdf

I won't make any statements about Softwire aspects of the draft, but I
can tell that the draft looks reasonable from the DHCP perspective. It
is intended as a generic extensible mechanism for provisioning A+P
solutions, hence the options name change (OPTION_MAP_* => OPTION_S46_*).
Woj sent me an unpublished version asking for a review and I have
provided one. There was a handful of nits, but nothing serious.

draft-ietf-softwire-map-dhcp seems to adhere to DHCPv6 option guidelines
(draft-ietf-dhc-option-guidelines-12). As a DHC co-chair, I plan to
encourage DHCP folks to participate in a broader review as soon as this
draft reaches WGLC in Softwires (which I hope will happen soon).

Hope that helps,
Tomek

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 17 Jul 2013 17:23:13 -0400

Hi Yiu,
  As Tomek said we discussed this a bit in Orlando. If you are concerned
about this, we can do a short call on the list and follow up at the
meeting to see if there are any objections in the wg. Does that work for
you?

Thanks
Suresh

On 07/15/2013 12:48 PM, Lee, Yiu wrote:
> From: Wojciech Dec <[email-masked] <mailto:[email-masked]>>
> To: "Yiu L. LEE" <[email-masked]
> <mailto:[email-masked]>>
> Cc: Softwires-wg <[email-masked] <mailto:[email-masked]>>
> Yes. See Mail of July 8. So far your objection is the only one, although
> I don't quite see in it any technically grounded objection.
> On 15 July 2013 17:29, Lee, Yiu <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Since this is a WG draft, did the authors ask the WG to update this?
>     When the WG accepted this draft, it was only for MAP. But seems the
>     scope has been changed. This should start as an Individual draft. I
>     will recommend to revert back to the last version and present this
>     in Berlin to replace the MAP draft if the WG agrees with it.
> 
> 
>     From: Wojciech Dec <[email-masked] <mailto:[email-masked]>>
>     To: Qi Sun <[email-masked]
>     <mailto:[email-masked]>>
>     Cc: Softwires-wg <[email-masked] <mailto:[email-masked]>>
>     Yes, there was a long thread started by Tomek. Given that the option
>     is applicable beyond MAP a *suggestion* was to rename it. I'm
>     personally ok either way. The "Softwire46" option is the currently
>     proposed name.
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 18 Jul 2013 18:24:18 +0000

It works for me.

Thanks,
Yiu

---

From: <[email-masked]>
Date: Fri, 19 Jul 2013 13:08:24 +0200

Hi Suresh / Yiu,

>From my perspective, the new version of the MAP DHCP draft is very much
aligned with the recent discussions that we've had in the SW & DHC
workgroups. There's still a little fine tuning needed, but it's pretty
close to what's been proposed in draft-ietf-softwire-unified-cpe and
definitely a big step in the right direction.

What I think the problem here is that we have had quite a lot of change
within the SW workgroup and the corresponding active drafts across the
last 6 months or so. The provisioning drafts are now being updated to
reflect these changes. At the same time, the provisioning mechanisms are
being updated and extended (e.g. DHCPv4overDHCPv6, dynamic v4 provisioning
and probably others).

In order to pull all of this together and to enable meaningful discussion,
I suggest that there needs to be an overview of the relevant provisioning
drafts, mechanisms, DHCP options and whatever else documented in one place
so that we can take stock of how (and maybe if) all of this works together.

If people agree that this is the right way forward, I'll volunteer to put
this overview together. I would also ask for another volunteer to assist,
though as I'm sure that I don't have the complete overview.

If there's still space on the agenda for Berlin, then we can use this as
the basis of the discussion.

Cheers,
Ian

---

From: <[email-masked]>
Date: Mon, 22 Jul 2013 11:18:40 +0200

Hi Ian, all,

I agree with you the changes are in the good direction and are much compliant draft-ietf-softwire-unified-cpe. 

IMHO, draft-ietf-softwire-map-dhcp is sufficient on its own to accommodate softwire-related needs. I understand this is only my opinion and that the WG may consider the companion dhc documents you mentioned as needed. In such case, draft-ietf-softwire-unified-cpe should be the place to specify under which conditions draft-ietf-softwire-map-dhcp or dhc I-Ds are to be followed.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la
>part de [email-masked]
>Envoyé : vendredi 19 juillet 2013 13:08
>À : [email-masked]; [email-masked]
>Cc : [email-masked]
>Objet : Re: [Softwires] Changes to DHCP MAP Option draft
>
>Hi Suresh / Yiu,
>