Re: [v6ops] draft-byrne-v6ops-clatip-01

"Heatley, Nick" <nick.heatley@ee.co.uk> Tue, 22 April 2014 15:27 UTC

Return-Path: <nick.heatley@ee.co.uk>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E7E1A059F for <v6ops@ietfa.amsl.com>; Tue, 22 Apr 2014 08:27:18 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=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 GHehQECCgAzO for <v6ops@ietfa.amsl.com>; Tue, 22 Apr 2014 08:27:13 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.176]) by ietfa.amsl.com (Postfix) with ESMTP id 79F781A04E8 for <v6ops@ietf.org>; Tue, 22 Apr 2014 08:27:12 -0700 (PDT)
Received: from [85.158.137.35:61670] by server-16.bemta-3.messagelabs.com id 74/48-13481-A4A86535; Tue, 22 Apr 2014 15:27:06 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-12.tower-134.messagelabs.com!1398180426!33575295!1
X-Originating-IP: [193.36.79.211]
X-StarScan-Received:
X-StarScan-Version: 6.11.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29197 invoked from network); 22 Apr 2014 15:27:06 -0000
Received: from unknown (HELO autechre) (193.36.79.211) by server-12.tower-134.messagelabs.com with SMTP; 22 Apr 2014 15:27:06 -0000
Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.14]) by autechre with MailMarshal (v6, 8, 2, 9371) id <B53568a5c0000>; Tue, 22 Apr 2014 16:27:24 +0100
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.02.0318.004; Tue, 22 Apr 2014 16:27:05 +0100
From: "Heatley, Nick" <nick.heatley@ee.co.uk>
To: "Fred Baker (fred)" <fred@cisco.com>, V6 Ops List <v6ops@ietf.org>
Thread-Topic: draft-byrne-v6ops-clatip-01
Thread-Index: AQHPXX0VPqKMoKpk4UiNc1ynEex0T5sdwxlg
Date: Tue, 22 Apr 2014 15:27:05 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303AE2E9A@UK30S005EXS06.EEAD.EEINT.CO.UK>
References: <CAD6AjGTaDen01RWU9Eaha70ah9F2fGCx-xnO8GWqbJ7L-1gRpQ@mail.gmail.com> <852615d6f8d742a095d2701496c62275@BY2PR03MB412.namprd03.prod.outlook.com> <CAD6AjGR5k1TzrfGm9VuxE4qu3SG7_CDjRLhLWYWB9ojtU1G1hQ@mail.gmail.com> <CAD6AjGR_z_5GtKRUkaH-rwpV1oeCP52Vg+PHdPwGFqzbciEcxg@mail.gmail.com> <E0B4D278-15A8-4E0B-8180-82D85566695F@cisco.com> <CAD6AjGQaTjoXD9yNm5uarySMho5+JOgx3LeyxuzVVZY68biW=A@mail.gmail.com> <F5D479E2-35AA-4B67-8300-2D445A3103F0@cisco.com> <37C0752F-8766-43BF-AD3E-29EBB64FED96@tsinghua.edu.cn> <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com>
In-Reply-To: <9B724115-1AA3-423C-A0F2-658285D5F43D@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.246.208.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/kFri1b7w3dyKW4_TBXp-qSPu7Ec
Subject: Re: [v6ops] draft-byrne-v6ops-clatip-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Apr 2014 15:27:18 -0000

Needed, I'd like to see this standardised here.



-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred)
Sent: 21 April 2014 17:16
To: V6 Ops List
Subject: [v6ops] draft-byrne-v6ops-clatip-01

Following up from the recent meeting.

We discussed clatip. The outcome was that we wanted to know what softwire wanted done with it, and I took the action to ask. 

The response from the softwire chairs was that they wanted to consider the draft there, and advance it from there. However, it appears to be bottlenecked. So, the softwire chairs have stepped back.

I want the opinion of v6ops. Do we need this, or not? If we need this, we should adopt it, and then (I think) go to an immediate WGLC and potentially advance it. If it’s not needed, we should say it is not needed.

Please reply in this thread.

On Apr 21, 2014, at 5:55 AM, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:

> Hi Fred,
> 
> Thanks for your email and reminding.
> 
> You are right that we are glad to take this work in Softwire as we discussed in March. However, for some reasons we need to focus on MAP package right now. There is the consensus that Softwire will NOT take any new work before we submit the MAP package to IESG. There are even some other wg items blocked in Softwire at this moment. We are trying to solve the MAP issues asap and accelerate the process. But I'm afraid we still need some time.
> 
> So if you'd like to take this work in v6ops, please do so. Otherwise, we still need to wait for some time before taking it in Softwire.
> 
> Thanks for understanding and let us know your decision.
> 
> Yong
> 
> On 2014-4-19, at 上午12:23, Fred Baker (fred) <fred@cisco.com> wrote:
> 
>> Softwire chairs:
>> 
>> In March, you indicated that you wanted to progress this in softwire. The authors haven’t heard from you and are looking for guidance. Pick one: do you want it, or do you want it done for you?
>> 
>> Fred
>> 
>> 
>> On Apr 18, 2014, at 4:55 AM, TheIpv6guy . <cb.list6@gmail.com> wrote:
>> 
>>> *fixing the softwire chair email address since it bounced.
>>> 
>>> On Fri, Apr 4, 2014 at 5:44 PM, Fred Baker (fred) <fred@cisco.com> wrote:
>>>> 
>>>> On Apr 4, 2014, at 6:34 AM, Cb B <cb.list6@gmail.com> wrote:
>>>> 
>>>> Hello folks,
>>>> 
>>>> No follow-up in a week. I assume the below explanation and 
>>>> exisiting text are ok.
>>>> 
>>>> To restate, this I-D simply generalizes the scope of 192.0.0.0/29.  
>>>> There is no guidance on how specific addresses may be used. It is 
>>>> assumed the deploying party will not cause a conflict on the host 
>>>> by assiging the same address to the host multipls times.... as that 
>>>> is a general ip configuration rule.
>>>> 
>>>> I will ask v6ops to accept this i-d and direct them to this thread 
>>>> to see the softwire view.
>>>> 
>>>> 
>>>> My understanding is that softwires wants to progress this one. I 
>>>> guess I’d like to hear from the softwires chairs before bringing it back.
>>>> 
>>> 
>>> 
>>> Fred,
>>> 
>>> It has been 14 days since your  email.  I am not sure if you sent 
>>> the email to the wrong address of fixed it.  Either way, i would 
>>> like to make progress on this I-D in v6ops since this I-D is about a 
>>> generalized approach that exceeds the bounds of softwires.  This has 
>>> also been presented twice in person to v6ops.
>>> 
>>> Cameron
>>> 
>>>> CB
>>>> 
>>>> On Mar 29, 2014 4:59 AM, "Cb B" <cb.list6@gmail.com> wrote:
>>>>> 
>>>>> On Thu, Mar 27, 2014 at 3:38 PM, Dave Thaler 
>>>>> <dthaler@microsoft.com>
>>>>> wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of 
>>>>>>> Cb B
>>>>>>> Sent: Thursday, March 27, 2014 10:58 AM
>>>>>>> To: softwires@ietf.org
>>>>>>> Subject: [Softwires] draft-byrne-v6ops-clatip-01
>>>>>>> 
>>>>>>> Hi Softwires,
>>>>>>> 
>>>>>>> Ales presented draft-byrne-v6ops-clatip-01 in softwires at the 
>>>>>>> last IETF meeting.
>>>>>>> 
>>>>>>> I am attempting to have this I-D adopted by v6ops, but v6ops 
>>>>>>> requested feedback from softwires first.
>>>>>>> 
>>>>>>> Pertaining to the minutes, i would like to address some topics 
>>>>>>> to make sure it is ok  for v6ops to move forward with adoption
>>>>>>> 
>>>>>>> 
>>>>>>> https://tools.ietf.org/wg/softwire/minutes?item=minutes-89-softw
>>>>>>> ire.html
>>>>>>> 
>>>>>>> The addresses, both in DS-lite and 464xlat, never appears on the 
>>>>>>> wire so there is no chance of overlap or collision.
>>>>>> 
>>>>>> Disagree, that conclusion doesn't follow (and in my experience 
>>>>>> it's wrong).
>>>>>> Overlap/collision happens when there are two interfaces on the same host
>>>>>> (even if they're not in use simultaneously).   The collisions can affect
>>>>>> the routing table (if the host implements in such a way), ACLs 
>>>>>> like in host firewall policies and such, and various application-layer uses.
>>>>>> 
>>>>> 
>>>>> Ah, i see your point.  If the host is itself both a B4 and a CLAT 
>>>>> at the same time, then this collision may occur within the host, 
>>>>> not on the wire.
>>>>> 
>>>>>> It's fine to specify use as the default range (e.g. for 464xlat 
>>>>>> or
>>>>>> DS-lite) but
>>>>>> important to never constrain it to only that range, assuming the 
>>>>>> range is made non-DS-lite specific.
>>>>>> 
>>>>>> -Dave
>>>>> 
>>>>> Is there such a constraint that would cause a problem?
>>>>> 
>>>>> Looking at RFC6333 and draft-byrne-v6ops-clatip, i see that 
>>>>> RFC6333 says the B4 SHOULD use 192.0.0.2.  To a rational person, a 
>>>>> good reason to not use  192.0.0.2 is that it is in use for a CLAT 
>>>>> interface on the same host, which fits with the SHOULD wording.
>>>>> 
>>>>> Is there some text that you could suggest that may clarify this 
>>>>> situation in draft-byrne-v6ops-clatip or is it ok for v6ops to 
>>>>> adopt as-is?  As it stands, the I-D simply says that 192.0.0.0/29 
>>>>> will be generalized without making any further statements how 
>>>>> addresses may be used within that range.
>>>>> 
>>>>> CB
>>>> 
>>>> 
>>>> ------------------------------------------------------
>>>> 8 issues in virtual infrastructure
>>>> http://dcrocker.net/#fallacies
>>>> 
>> 
>> ------------------------------------------------------
>> 8 issues in virtual infrastructure
>> http://dcrocker.net/#fallacies
>> 
> 
> 

------------------------------------------------------
8 issues in virtual infrastructure
http://dcrocker.net/#fallacies


NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW