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

[<[e-mail]>]

Dear Fred, all,

I support the adoption of this draft. 

Once comment about the proposed name of the IPv4 prefix, I would vote for "IPv4 service continuity Prefix" (or something similar) instead of "IPv6 Transitional Technology IPv4 Prefix".

Cheers,
Med

>-----Message d'origine-----
>De : v6ops [mailto:[e-mail]] De la part de Fred Baker (fred)
>Envoyé : lundi 21 avril 2014 18:16
>À : V6 Ops List
>Objet : [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-
>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