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

[Ca By <[e-mail]>]

Thanks the comments Wes.

On Mon, May 5, 2014 at 8:19 AM, George, Wes <[e-mail]> wrote:
> I support adoption/publication of this draft. I think it’s useful to
> codify the block that is already being used in a production network so
> that others can take advantage of this implementation experience, and
> v6ops is an acceptable place in which to do it.
>
> Three comments:
>
> First, this draft needs to formally update RFC 6333 in its metadata, as I
> think there’s a need for a formal link between the two.
>

I humbly disagree.  Nothing changes in DS-lite or RFC6333 as function
of draft-ietf-v6ops-clatip-00.

What does change is the IANA registery of 192.0.0.0/29 to be more
general and serve a super set of scenarios, and that change will be
reflected there in IANA, not in DS-lite.

I am open to other opinions on this, but mine is that RFC6333 updated
IANA and draft-ietf-v6ops-clatip-00 updates IANA again.
draft-ietf-v6ops-clatip-00 does not update RFC6333

> Second, there is a fairly small discussion about the potential conflict
> between DSLite and 464XLat when they both use this reserved block. Right
> now it primarily implies that it’s only locally significant, thus avoiding
> global conflicts, but It might be worth expanding it a bit to discuss the
> scope of that significance in a single network, I.e. either explicitly
> recommend against using DSLite and 464XLat on the same network/routing
> domain, or to explicitly confirm that this will work, discuss any design
> considerations (such as location or isolation of the routing domain
> between the B4 and the AFTR) to avoid conflicts.
>

I have added some new text to
http://tools.ietf.org/html/draft-ietf-v6ops-clatip-00

" It is important that a host never be deployed with 2 active IPv4
continuity solutions
   simultaneously in a way that would cause a node to have overlapping
   address from 192.0.0.0/29."


> Lastly, I’m not sure about the “IPv6 transitional Technology IPv4 Prefix”
> designation, as this could lead to confusion by implying that it is
> appropriate to be used for any IPv6 transition technology that needs a
> small IPv4 prefix. That may be true, but it also may not be, so some
> additional language clarify what you mean and recommending that other
> potential uses for this address space should be separately evaluated might
> be a good idea.
>

Mohamed Boucadair has suggested "IPv4 Service Continuity Prefix" so i
adopted in the latest WG I-D.

This additional text was also added to provide scope.

"The result is that 192.0.0.0/29 may be used in any system that requires IPv4
   addresses for backward compatibility with IPv4 communications in an
   IPv6-only network, but does not emit IPv4 packets "on the wire"."


Thanks again for the feedback.

CB


> Thanks,
>
> Wes
>
>
>
> On 5/4/14, 2:00 PM, "Fred Baker" <[e-mail]> wrote:
>
>>This is to initiate a two week working group last call of
>>http://tools.ietf.org/html/draft-byrne-v6ops-clatip.
>>
>>This is unusual. Please bear with me here. We have discussed it several
>>times. In March, the working group decided to offer it to softwire,
>>whose chairs told me they wanted to take it on themselves and pursue
>>it.  However, it is HOL blocked by MAP, which they want to complete
>>first. With their concurrence, noting that the working group has said
>>in the past couple of weeks that it wants to finish it, we need to
>>finish it here.
>>
>>My game plan is to collect comments on the existing draft, including
>>any idnits issues, and have Cameron post an update named
>>draft-ietf-v6ops-clatip - a working group draft. If that passes the
>>smell test, we'll send it to Joel.
>>
>>Please read it now. If you find nits (spelling errors, minor suggested
>>wording changes, etc), comment to the authors; if you find greater
>>issues, such as disagreeing with a statement or finding additional
>>issues that need to be addressed, please post your comments to the
>>list.
>>
>>We are looking specifically for comments on the importance of the
>>document as well as its content. If you have read the document and
>>believe it to be of operational utility, that is also an important
>>comment to make.
>>
>>_______________________________________________
>>v6ops mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/v6ops
>
>
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops