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

From: Fred Baker <[email-masked]>
Date: Sun, 4 May 2014 11:00:22 -0700 (PDT)

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.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 5 May 2014 11:19:29 -0400

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.

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.

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.

Thanks,

Wes

On 5/4/14, 2:00 PM, "Fred Baker" <[email-masked]> wrote:

>_______________________________________________
>v6ops mailing list
>[email-masked]
>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.

---

From: Ca By <[email-masked]>
Date: Mon, 5 May 2014 13:00:09 -0700

Thanks the comments Wes.

> 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

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

> potential uses for this address space should be separately evaluated might

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

---

From: "George, Wes" <[email-masked]>
Date: Mon, 5 May 2014 17:04:46 -0400

>draft-ietf-v6ops-clatip-00 does not update RFC6333

A fair point. I agree that the direction to IANA doesn’t explicitly
require an update to 6333 and you’re not really changing DSLite. My
thought was more from the perspective that originally 6333 was written
assuming exclusive use of the block, and it no longer has it. Since there
are at least small considerations about overlap, it’s worth the DSLite doc
having a link to this one for those implementing DSLite that may not be
aware of this change.

Wes

---

From: David Farmer <[email-masked]>
Date: Mon, 05 May 2014 17:43:15 -0500

+1

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: David Farmer <[email-masked]>
Date: Mon, 05 May 2014 17:45:56 -0500

> having a link to this one for those implementing DSLite that may not be

I think maybe formally updating Section 5.7 of RFC6333 by adding a 
version of the text from the last paragraph of Section 3 of 
draft-ietf-v6ops-clatip-00 as the last paragraph of Section 5.7 of 
RFC6333, would ensure that DS-lite implementers are made aware of the 
new constraint created by this change.

    192.0.0.0/29 has now been generalized across multiple IPv4
    continuity solutions such as 464XLAT and DS-lite.  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.

Just a thought.