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

<ian.farrer@telekom.de> Mon, 13 May 2013 12:45 UTC

Return-Path: <ian.farrer@telekom.de>
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 6DB1321F940B for <softwires@ietfa.amsl.com>; Mon, 13 May 2013 05:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6]
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 tUQH47tqaCiY for <softwires@ietfa.amsl.com>; Mon, 13 May 2013 05:45:43 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 15EF021F93E9 for <softwires@ietf.org>; Mon, 13 May 2013 05:45:42 -0700 (PDT)
Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 13 May 2013 14:45:41 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 13 May 2013 14:45:41 +0200
From: ian.farrer@telekom.de
To: otroan@employees.org
Date: Mon, 13 May 2013 14:45:42 +0200
Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-map-05
Thread-Index: Ac5P18asVbYWYMOpRLe2vtgelqJeVw==
Message-ID: <CDB69DF0.6FDB2%ian.farrer@telekom.de>
In-Reply-To: <BA7C5B47-C2F9-468B-99B7-C116BA3DA4CB@employees.org>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, 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: Mon, 13 May 2013 12:45:47 -0000

Hi Ole,

Comments in line.

Cheers,
Ian



On 13/05/2013 12:21, "Ole Troan" <otroan@employees.org> wrote:

>Ian,
>
>>>> Thanks for incorporating  my comments into this version.
>>>> 
>>>> Having re-read this version, there's one thing that I'd like to
>>>> clarify: Is the BMR still being proposed as the method for configuring
>>>> all IPv4 information, even with the EA=0 case? Section 5.2 states:
>>>> 
>>>> A length of 0 means that no part of the IPv4 address or port is
>>>> embedded in the address.
>>> 
>>> yes. that's is the meaning of EA=0.
>>> 
>>>> Which is OK, if a little ambiguous.
>>> 
>>> how so?
>> 
>> [ian] The description says what it doesn't do without saying what it
>>does
>> do. That's why I would say it's ambiguous.
>
>there was a lot of pushback from describing 1:1 mode in more detail in
>the MAP base
>document.

[ian] I recall:-) As I said, I'm OK with what it says and the ambiguity is
not really a problem in it's own right. It'sl Ex 4 in the appendix where
it states that you provision v4 using BMR/FMR.

>
>>>> Then in example 4 in the Appendix, the BMR is provisioning the /32
>>>>IPv4
>>>> prefix for the client, i.e 1:! mode or 'Binding Mode' to use the
>>>>Unified
>>>> CPE terminology.
>>>> 
>>>> I thought that we were going to use the OPTION_MAP_BIND proposed in
>>>> softwire-unified-cpe to tell a lw4o6 CPE, or a MAP CPE to provision
>>>>the
>>>> Binding Mode.
>>> 
>>> the MAP BMR isn't only a 'provisioning construct' it is also used for
>>> forwarding.
>>> the MAP document doesn't say anything about how the BMR is provisioned.
>>> 
>>> if you created a separate DHCP option for the corner case of EA=0, how
>>> should a Rule IPv4 prefix length of 32 with EA=0, be handled?
>>> seems like we then create more ambiguity...
>> 
>> [ian] As I proposed in Orlando (second to last slide):
>> http://www.ietf.org/proceedings/86/slides/slides-86-softwire-3.pdf
>> 
>> No objections were raised to this.
>
>see section 7.
>EA=0 and a configured Rule IPv4 prefix of /32 results in 1:1/binding mode.
>
>_how_ that Rule IPv4 prefix is configured is out of scope of the base MAP
>document.

[ian] App. A ex 4 does state that the IPv4 config is taken from the
BMR/FMR and 5.2/5.3 state the parameters for constructing BMRs/FMRs.
Although it doesn't state how (as in the configuration method / protocol)
this is configured, the parameters are stated, even though many of them
are not required for 1:1.

>
>my previous comment was to the provisioning document, where I think it
>would be ambiguous to have two options
>to do the same thing.
>
>do you have any proposed changes to MAP base, or is this for the
>provisioning document?

[ian] I think that the simplest way to make all this work is together is
to separate out the BMR for mesh mode and the 1:1 mapping rule. As long as
the BMR is described as the mechanism for provisioning 1:1 mode, then the
additional configuration parameters of the BMR must also be conveyed (I.e.
all of the things that are detailed in section 5.2), even though many of
them are only relevant for mesh.

So, the change in the MAP base draft would be: if EA=0, then the IPv4
configuration / port set is not provisioned within the BMR and is conveyed
through another means (static, OPTION_MAP_BIND, DHCPv4 over DHCPv6 or
whatever). This gives us the single method of configuring MAP 1:1/lw4o6.

The MAP DHCP option draft then needs to be brought in line with this.

>
>cheers,
>Ole