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

Hi Ian,

sure. In the current MAP the BR gets configured via the DMR (as an IP
address) -
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.3
That's not set in stone, but it's a reasonable way of doing things. A name
could be another equivalent way.

Note: The working of this, incl DHCPv6, has been verified in trials also
with the 1:1 mode and hooking up to a DS-lite AFTR, and an issue of
compatibility, which you're voicing a concern about, hasn't come up.

Regards,
Woj.

On 9 April 2013 17:59, <ian.farrer@telekom.de> wrote:

> 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>
> Date: Tuesday, 9 April 2013 13:09
> To: Ian Farrer <ian.farrer@telekom.de>
> Cc: Suresh Krishnan <suresh.krishnan@ericsson.com>, Softwires-wg <
> softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, Ralph Droms <
> 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> 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
>>
>
>