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

[<[e-mail]>]

Hello *,

yes, I would like to see this advanced please. Necessary to bring forward IPv6-only access solutions reliably.

Holger


-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[e-mail]] Im Auftrag von Fred Baker (fred)
Gesendet: Montag, 21. April 2014 18:16
An: V6 Ops List
Betreff: [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 <[e-mail]> 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) <[e-mail]> 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 . <[e-mail]> wrote:
>> 
>>> *fixing the softwire chair email address since it bounced.
>>> 
>>> On Fri, Apr 4, 2014 at 5:44 PM, Fred Baker (fred) <[e-mail]> wrote:
>>>> 
>>>> On Apr 4, 2014, at 6:34 AM, Cb B <[e-mail]> 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" <[e-mail]> wrote:
>>>>> 
>>>>> On Thu, Mar 27, 2014 at 3:38 PM, Dave Thaler 
>>>>> <[e-mail]>
>>>>> wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Softwires [mailto:[e-mail]] On Behalf Of 
>>>>>>> Cb B
>>>>>>> Sent: Thursday, March 27, 2014 10:58 AM
>>>>>>> To: [e-mail]
>>>>>>> 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