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

["Fred Baker (fred)" <[e-mail]>]

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