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> 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] 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
> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>