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

Ole Troan <otroan@employees.org> Wed, 10 April 2013 13:20 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 882A321F9779 for <softwires@ietfa.amsl.com>; Wed, 10 Apr 2013 06:20:45 -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 QT0bXi5qEzgG for <softwires@ietfa.amsl.com>; Wed, 10 Apr 2013 06:20:44 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 24D3821F9607 for <softwires@ietf.org>; Wed, 10 Apr 2013 06:20:43 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,447,1363132800"; d="scan'208";a="81889724"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 10 Apr 2013 13:20:43 +0000
Received: from dhcp-lys02-vla252-10-147-116-14.cisco.com (dhcp-lys02-vla252-10-147-116-14.cisco.com [10.147.116.14]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3ADKeQ9021069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Apr 2013 13:20:41 GMT
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CD8AE0F9.62247%ian.farrer@telekom.de>
Date: Wed, 10 Apr 2013 15:20:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABFC5C6B-DC54-40F0-A750-0A2B34763753@employees.org>
References: <CD8AE0F9.62247%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: Wed, 10 Apr 2013 13:20:45 -0000

Ian,

> Thanks for that. So we actually aren't too far apart. There needs to be a DMR (or equivalent) that has the IPv6 address of the BR.
> 
> But, this is one thing that's been confusing me since the publication of (I think v03), where the DMR is no longer described, or mentioned anywhere in the MAP base draft. However it does still exist in the MAP DHCP option draft. But neither of the drafts actually describes what it is and how to use it. The current map 05 draft only discusses the use of an IPv4 route, which I think is misleading – the IPv6 address of the BR is also needed (as Ole's pointed out in his mail). 
> 
> A DMR, or something functionally equivalent is necessary, but this is not just an IPv4 route. It has to have the v6 address of the BR, used to build a tunnel. The v4 route points then to that tunnel.
> 
> So, the reason that I said it's incompatible is that the current text in the MAP base draft doesn't describe any way of getting the v6 address of the BR other than those that can be provided with a BMR and FMRs. I.e. An IPv4 default route with an IPv4 next hop which is in a map domain which the CPE has an FMR for. lw4o6, which doesn't use mapping rules cannot calculate the v6 address of the concentrator from a v4 next hop address.
> 
> I realise that this is not how it is meant to work (and you've confirmed that), but this is the only way that you could make it work given the text that is actually in the draft and that's what I think needs to be changed. This would bring the MAP/lw4o6 & unified CPE drafts back in line…
> 
> … then we can have the discussion about what the best DHCP mechanism to provision the client with the v6 address of the concentrator is :-)

please propose text.
the MAP base document does not specify the provisioning mechanism itself.
but it does specify which parameters need to be provisioned.

section 7 states:

For a given MAP domain, the BR and CE MUST be configured with the
   following MAP elements.  The configured values for these elements are
   identical for all CEs and BRs within a given MAP domain.

   o  The Basic Mapping Rule and optionally the Forwarding Mapping
      Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and
      Length of EA bits

   o  The IPv6 address of the MAP BR.

   o  Hub and spoke mode or Mesh mode.  (If all traffic should be sent
      to the BR, or if direct CE to CE traffic should be supported).


section 5.4 states:
   To reach IPv4 destinations outside of the MAP domain, traffic is sent
   to the configured address of the MAP BR.  On the CE, the default can
   be represented as a point to point IPv4 over IPv6 tunnel [RFC2473] to..


would it help you if section 5.4 states the "configured IPv6 address of the MAP BR"?

cheers,
Ole