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

Wojciech Dec <wdec.ietf@gmail.com> Wed, 10 April 2013 13:12 UTC

Return-Path: <wdec.ietf@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF1321F8E6E for <softwires@ietfa.amsl.com>; Wed, 10 Apr 2013 06:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAahJFMXP3qj for <softwires@ietfa.amsl.com>; Wed, 10 Apr 2013 06:12:25 -0700 (PDT)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C507521F8EC1 for <softwires@ietf.org>; Wed, 10 Apr 2013 06:12:23 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id b12so179706qca.18 for <softwires@ietf.org>; Wed, 10 Apr 2013 06:12:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7WlnGyn/ycUwYLIlYRDai9uBtEAmKT/MhrtCIS0AbTc=; b=GziMfd+tvczZYYQ7cwmNFSAOhdIRWtcUM7P3DAH+Vt3qX865HWWBXYrZFJT6dhkxRL 2IPppIjTdUPd74mtd6r8TCPgL9NTk1mRN8lQ1NnwD3bOxJ0JEK4KdPZb5WHqJoLsMKjS NGMy+tntkt7a2dMt0IrVmGRlTYfE1aEFdNQ/AB2RCB/Yw9urpexx8VEP9npwyd6qteCp b1QunduajwZnCnjqx1xsYvchzgARstYQzKuy+nzow7qSrQy+g5d7BeqQLfu4cTcqLK1v Hs8bV9BAJMxqv0qBmMltAhvjQ7i06GZtq7jB/9/vfImulduUkU86KfEXiC1GPWp9zsmg r8Ag==
MIME-Version: 1.0
X-Received: by 10.49.11.178 with SMTP id r18mr2175686qeb.56.1365599536692; Wed, 10 Apr 2013 06:12:16 -0700 (PDT)
Received: by 10.49.12.84 with HTTP; Wed, 10 Apr 2013 06:12:16 -0700 (PDT)
In-Reply-To: <FD314973-46AF-4EB7-88C9-1DF8B9DE284F@gmail.com>
References: <CAFFjW4jMrAPVm48R1TbiAAHG__UaDxKSiJ3hVDh5kBy5pvMjkw@mail.gmail.com> <CD8A04C0.61ECA%ian.farrer@telekom.de> <CAFFjW4gHvFYMUG+XL4bDACjEhxV+zp4e1gRy1c9__knNqVWXXA@mail.gmail.com> <FD314973-46AF-4EB7-88C9-1DF8B9DE284F@gmail.com>
Date: Wed, 10 Apr 2013 15:12:16 +0200
Message-ID: <CAFFjW4ji2ewG-pS6qXjKpB=GeFAf7rNtbmpK58RmiuXrFAG30g@mail.gmail.com>
From: Wojciech Dec <wdec.ietf@gmail.com>
To: Qi Sun <sunqi.thu@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b2e7ad24aa56604da016b0f"
Cc: 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
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 13:12:26 -0000

Qi,

the name doesn't matter. It's an IP address, it can be a name, of the BR.
MAP-E talks about that. In the dhcpv6 draft it has been codified as a DMR
and is actually much more flexible than 6334. (feel free to use a name you
feel comfortable with). That said 6334, is an orthogonal discussion - topic
for comments on the dhcp draft.

MAP-E requires the address of a BR to operate and implicitly points a
default route to it, and as much is said in the draft. How it gets that
address is clearly part of provisioning.

The original claim was of some incompatibilities, I'm still wondering what
these are.

Cheers,
Woj.




On 10 April 2013 09:48, Qi Sun <sunqi.thu@gmail.com> wrote:

>
> Hi Woj ,
>
> AFAIK, there is no DMR defined in draft-map-05. And for map-e, what a
> 'DMR' DHCPv6 option does is the same as that of RFC6334, both for
> configuring the IPv6 address of the tunnel concentrator. It is convenient
> for the unified CPE to leverage RFC6334 for this configuration, IMHO.
>
>
> Best Regards,
> Qi Sun
>
>
> On 2013-4-10, at 上午12:46, Wojciech Dec wrote:
>
> 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
>>>
>>
>>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>
>