Re: [Softwires] Working group last call for draft-ietf-softwire-map-05

Hi Woj,

To (hopefully) prevent a long, cross purpose discussion, could you describe how you see that the BR address should be configured for MAP 1:1? It's described as a possible use case in the appendix, but it only covers how to provision the client, not how it learns the BR.

Thanks,
Ian

From: Wojciech Dec <wdec.ietf@gmail.com<mailto:wdec.ietf@gmail.com>>
Date: Tuesday, 9 April 2013 13:09
To: Ian Farrer <ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>>
Cc: Suresh Krishnan <suresh.krishnan@ericsson.com<mailto:suresh.krishnan@ericsson.com>>, Softwires-wg <softwires@ietf.org<mailto:softwires@ietf.org>>, Yong Cui <cuiyong@tsinghua.edu.cn<mailto:cuiyong@tsinghua.edu.cn>>, Ralph Droms <rdroms@cisco.com<mailto:rdroms@cisco.com>>
Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05

Hi Ian,

a default route appears to be by far the best way to model the reachability of destinations outside of the MAP domain, and actually *any* IP domain (i.e. this is not a MAP specific aspect).

On 5 April 2013 21:03, <ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>> wrote:
Hi,

I have one comment about the current version: It is using an IPv4 default route as the method for sending traffic out of the MAP domain. This is likely to cause provisioning complexity and conflicts with two other related drafts:

1, The unified CPE draft is looking for the presence of a configured BR/AFTR v6 address as the mechanism for whether to configure 'binding mode' (i.e. MAP 1:1 in this case). A v4 default route isn't easily compatible with this.

Could you elaborate on what incompatibility you see?
This is a case of an implicit default route (much as is also the norm in say PPP connections).

2, For DHCP based provisioning, the updated OPTION_MAP (described in the unified CPE draft) + RFC6334 give a method for configuring basic softwire functionality using just a DHCPv6 server. This doesn't provide any way of distributing IPv4 default routes. Therefore, to provision a MAP 1:1 client, you would need to deploy the DHCPv4 over DHCPv6 infrastructure just for this single DCHPv4 option. This is, of course assuming that the DHCPv4 over DHCPv6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechanism for v4 over v6 provisioning.

This appears back to front. RFC6334 is naturally the DS-lite AFTR option, and an AFTR does not equal a BR, (nor a Lw46 gateway). I believe that that the use of rfc6334 is unnecessary, and the unified CPE does not need to depend on it, esp given that it will need additional options anyway. In short, it makes little sense for a unified CPE to use both rfc6334 + some new option.

I raised this point in Orlando (See Ole's comment on using RFC6334 as the DMR in the minutes). I think that this change would fix the two points above.

IMO The unified CPE notion needs to be fixed (and it is something I have commented on previously): It's not unification by dumping all the existing stuff together, but a) a functional rationalization (all solution share the same functions) and b) a unified configuration method (which likely excludes things like rfc6334, given its  applicability to only one solution)

Regards,
Woj.

Thanks,
Ian

-----Original Message-----
From: softwires-bounces@ietf.org<mailto:softwires-bounces@ietf.org> [mailto:softwires-bounces@ietf.org<mailto:softwires-bounces@ietf.org>] On Behalf Of Suresh Krishnan
Sent: Dienstag, 26. März 2013 05:23
To: Softwires WG
Cc: Yong Cui; Ralph Droms
Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05

Hi all,
  This message starts a two week softwire working group last call on advancing the draft about providing Mapping of Address and Port with Encapsulation as a Standards Track RFC. The authors believe that this version has addressed all the issues raised on the document. The latest version of the draft is available at

http://www.ietf.org/id/draft-ietf-softwire-map-05.txt
http://tools.ietf.org/html/draft-ietf-softwire-map-05

Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. The chairs will send in their comments as well during the last call period. This last call will conclude on April 9, 2013.

Regards,
Suresh & Yong
_______________________________________________
Softwires mailing list
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires