Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt

Ian Farrer <ianfarrer@gmx.com> Wed, 05 March 2014 16:23 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FCB1A0754 for <softwires@ietfa.amsl.com>; Wed, 5 Mar 2014 08:23:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNat_fGAlkJX for <softwires@ietfa.amsl.com>; Wed, 5 Mar 2014 08:23:33 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 897FD1A06E5 for <softwires@ietf.org>; Wed, 5 Mar 2014 08:23:33 -0800 (PST)
Received: from dhcp-ade2.meeting.ietf.org ([31.133.173.226]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MIuft-1WN9Ld0OZl-002XRw; Wed, 05 Mar 2014 17:23:28 +0100
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ian Farrer <ianfarrer@gmx.com>
In-Reply-To: <6BE4C1C1-17D6-44B6-A9FC-F270D29AA0B0@employees.org>
Date: Wed, 05 Mar 2014 16:23:23 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <F946C230-B91C-4463-823B-C3FB3B0577F2@gmx.com>
References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <FD878467-904B-4441-95B4-11D4461A612E@employees.org> <CF237FDE.AACEB%ian.farrer@telekom.de> <CAFFjW4jOBfvnqCV4UH8qt0HA5zZ-35f+q5ZepzjnwGX5_Oj9Gg@mail.gmail.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <CAFFjW4iP2KqNJFtJPr5rp0tzRwM5TPjaqiSP5r13JqbX46ao7w@mail.gmail.com> <CD1D4FF6-9509-43B4-AFC4-4F1AF99D0C4D@gmx.com> <CAFFjW4ibkj_xpTuXrbYjxkdxD=+qNzapCGPHJwXsZ-k0ZvGg-g@mail.gmail.com> <CF335888.AE89D%ian.farrer@telekom.de> <CAFFjW4hv5WBiqyw9jM+ZoLMGR5k49pjKXG0epnhrsOGoBBKMYA@mail.gmail.com> <78CE37BA-11FB-4AE4-9D49-A3053616A31A@gmx.com> <53173611.5070208@viagenie.ca> <4255E91E-B1F0-4FE0-9A86-171922C7BC43@gmx.com> <6BE4C1C1-17D6-44B6-A9FC-F270D29AA0B0@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.1874)
X-Provags-ID: V03:K0:1TByfEXAtjzcLdr7jIeozxHvTWjaI6UqfBINfgj6stx+BrtbxAb E7Gt8XhyKou2MjgnsmLdABwTsQ+Lp08qQ76jrM05zQ3zqcUGQqnvmi37Lq2og6z4tX/pnGY yTDpB7JZKqQKP5LEM01XkpWwumV9SMrX8fPJXTi1pa1JYpkf2PqGZZbWN/L/RRSdIW3zoJF CqBM84vrr7aya+Q8agS4Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/6YCdKwDtHvc5twJB9U2GhihcE3E
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
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, 05 Mar 2014 16:23:35 -0000

Hi Ole,

See inline.

Cheers,
Ian

On 5 Mar 2014, at 14:56, Ole Troan <otroan@employees.org> wrote:

> Ian,
> 
>> No. As long as you know what particular mechanism you B4 vendor has implemented, you can provision accordingly.
>> 
>> The lwAFTR never has to do the LPM. It’s just got a tunnel endpoint address configured by the operator.
> 
> I'm not comfortable with that.

[ian] Why aren’t you comfortable with it?

> 
> is there any reason why you couldn't do it as MAP does?
> 
> - include a "Domain IPv6 prefix" in the set of provisioning parameters.
> - the client does a longest match between the Domain IPv6 prefix and the End-user IPv6 prefixes
>  and uses that to create the tunnel end point address.
> 
> that also allows the operator to use either the WAN side /64 or an address out of the PD as the tunnel endpoint address.
> 
> cheers,
> Ole