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

"George, Wes" <> Mon, 05 May 2014 15:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8B0351A03BB for <>; Mon, 5 May 2014 08:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.116
X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zgXMgj0t_6G2 for <>; Mon, 5 May 2014 08:20:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 941AE1A03BD for <>; Mon, 5 May 2014 08:20:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,988,1389762000"; d="scan'208";a="298855186"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 05 May 2014 11:18:46 -0400
Received: from ([]) by ([]) with mapi; Mon, 5 May 2014 11:19:30 -0400
From: "George, Wes" <>
To: Fred Baker <>, "" <>
Date: Mon, 05 May 2014 11:19:29 -0400
Thread-Topic: [v6ops] draft-byrne-v6ops-clatip WGLC
Thread-Index: Ac9odWlEayjKINLpT6+vtoW1QkcXgg==
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [v6ops] draft-byrne-v6ops-clatip WGLC
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 May 2014 15:20:32 -0000

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.



On 5/4/14, 2:00 PM, "Fred Baker" <> wrote:

>This is to initiate a two week working group last call of
>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
>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

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.