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

Ole Troan <otroan@employees.org> Mon, 13 May 2013 10:21 UTC

Return-Path: <otroan@employees.org>
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 CE05521F9425 for <softwires@ietfa.amsl.com>; Mon, 13 May 2013 03:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 6K6Rz-zAJHiC for <softwires@ietfa.amsl.com>; Mon, 13 May 2013 03:21:46 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B85D621F9433 for <softwires@ietf.org>; Mon, 13 May 2013 03:21:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,660,1363132800"; d="scan'208";a="13901787"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 13 May 2013 10:21:32 +0000
Received: from dhcp-lys02-vla252-10-147-116-53.cisco.com (dhcp-lys02-vla252-10-147-116-53.cisco.com [10.147.116.53]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4DALUdx009113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 May 2013 10:21:30 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CDB68420.6FCB2%ian.farrer@telekom.de>
Date: Mon, 13 May 2013 12:21:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA7C5B47-C2F9-468B-99B7-C116BA3DA4CB@employees.org>
References: <CDB68420.6FCB2%ian.farrer@telekom.de>
To: ian.farrer@telekom.de
X-Mailer: Apple Mail (2.1503)
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 10:21:50 -0000

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.

>>> 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.

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?

cheers,
Ole