Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00

From: Wojciech Dec <[email-masked]>
Date: Wed, 7 Mar 2012 14:49:29 +0100

The draft contains text like

 "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6
   Fragment Header, since IPv4 host does not set the DF bit. "

What more it contains specific text in Section 6.1 like

"

IPv6 address format in 464XLAT is presented in the following format.

       +-----------------------------------------------+---------------+
       |              XLAT prefix(96)                  |    IPv4(32)   |
       +-----------------------------------------------+---------------+

Source address and destination address have IPv4 address embedded in the
low-order 32 bits of the IPv6 address. "

NAT64 RFCs does not make such requirements or place such a prefix
restriction, and IMO these effectively become normative for an
implementation. If they're not needed then they shouldn't be there.

Way of resolving the issue(s) would be to:
- Document the experiment, the set-up  and the results.
- Separately document any/all specific requirements, assumptions or
operations that are not covered by existing RFCs (eg the requirement for
XLAT to use a /96 prefix)

-Woj.

On 27 February 2012 18:36, Cameron Byrne <[email-masked]> wrote:

> V6ops,
>
> We received some feedback that draft-ietf-v6ops-464xlat-00 has
> normative language which is not correct for an informational draft.
>
> When pressed on where the normative language was, we were told that
> the issue was use of RFC 2119 key words.
>
> In reviewing RFC 2119, I could not find any limitation on how the
> keywords are used
>
> In reviewing RFC 4677, it seems the RFC 2119 drives clarity and
> therefore should be used to "tell it like it is"
>
> Further review of published Informational work, i see that RFC 6092 is
> informational and uses RFC 2119 key words
>
>  My preference is to keep the key words in 464XLAT for clarity of the
> document.
>
> Does the WG have an issue with this or statement on how this violates
> for complies with norms?
>
> Thanks,
>
> Cameron
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 7 Mar 2012 07:31:41 -0800

Woj,

>    Fragment Header, since IPv4 host does not set the DF bit. "

This will be changed in future revisions, RFC 2119 key words will be removed.

> IPv6 address format in 464XLAT is presented in the following format.

This is not a NAT64 RFC.  This an informational draft that states how
a scenario defined in a NAT64 RFC may be used.  The above IPv6 address
format is defined as one of many possible in RFC 6052.  The above
format for convenience of implementation is recommended in 464XLAT.  I
hope this recommendation of how a deployment scenario in an
informational document is not a problem for you.  The point of a
deployment scenario / architecture is that it constrains all possible
options into a reasonable set that work together in a particular way.

In general, /96 speeds up discover and helps create uniformity in the
464XLAT deployment model.  We do not see any specific utility in
support anything beyond a /96 for the purposes for which 464XLAT is
scoped.

> - Document the experiment, the set-up  and the results.

draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an
informational architecture which happens to be supported by running
code and informal network deployment reports

> XLAT to use a /96 prefix)

draft-ietf-v6ops-464xlat-00 does not create any new technology or
standards.  I don't believe an information document that does not use
RFC 2119 language and recommends a /96 prefix (which is one of many
defined in RFC 6052) should be an issue.  If it is, please let me know
why.

CB

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 8 Mar 2012 08:59:54 +0100

> options into a reasonable set that work together in a particular way.

Building architecture specifications conforming only to very narrow
deployment scenarios means that they will likely not work when taken
outside of that environment. In the xlat464 case this very narrow
deployment scenario appears to be the combined set of; a stateful core
NAT46 device; use of only /96 prefix for address mapping; only private IPv4
addresses for end hosts/apps.

I for one have no problem with someone choosing to set up their network to
operate like that, and documenting publicly their setup/experiences. Also
no problem with the use NAT64 stateless/stateful to solve the overall
problem of "connect v4 to and across v6". Where I do start having problems
is in seeking broad WG recommendations for effectively creating
devices/implementations that *only* work within this specific set of
constraints.

> support anything beyond a /96 for the purposes for which 464XLAT is

Can you substantiate how a /96 helps speed up discovery, and not other
prefix lengths, or operator assigned lengths? Why restrict the operator to
this specific prefix length for both source and destination address
mapping?
The NAT64 authors, operators amongst them, didn't think that such a
restriction was useful or necessary.

> defined in RFC 6052) should be an issue.  If it is, please let me know

If this is a recommendation and not a spec, how would a regular stateless
NAT64 device, like the CLAT claims to be, know that it should use a /96 as
its source prefix for mapping v4?

-Woj.

CB

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 8 Mar 2012 00:03:22 -0800

---------- Forwarded message ----------
From: "Cameron Byrne" <[email-masked]>
Date: Mar 7, 2012 4:34 PM
Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00
To: "Wojciech Dec" <[email-masked]>

we seem to be off list, in line

> Building architectures conforming only to very narrow deployment scenarios
> means that they will likely break when taken outside of that environment.
In

if they are taken outside of their environment, they are not the
specified architecture.

> the xlat464 case this very narrow deployment scenario appears to be the

narrow or not, it patches the 15% app breakage that we see when
nat64/dns64 is deployed alone.

That alone is the utility of the service.

> combined set of; a stateful core NAT46 device; use of only /96 prefix for
> address mapping; only private IPv4 addresses for end hosts/apps.
>
no
> problem with the use NAT64 stateless/stateful to solve the overall problem
> of "connect v4 to and across v6". Where I do start having problems is in
> seeking broad WG recommendations for effectively creating

this is an informational doc and not a device spec.

mapping?
> restriction was useful or necessary.

I got the impression that /96 is faster here
http://www.ietf.org/mail-archive/web/behave/current/msg08893.html

the fact that it is simpler is intuitive.

i see know reason why to introduce the additional complexity of having
other side prefixes.

Is there a benefit?

> its source prefix for mapping v4?

The fact that is knows means that it is CLAT subset of any CPE that does
6145

CB

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 8 Mar 2012 13:26:17 +0100

On 8 March 2012 09:03, Cameron Byrne <[email-masked]> wrote:

> > means that they will likely break when taken outside of that
> environment. In
>

Yes, that's why architectures should be broad usage based.

> That alone is the utility of the service.

Case in hand appears that if one takes a CLAT and connects it to say any
other network, say your enterprise network where NAT64 may even be present
but configured outside of the narrow xlat464 constraints, the CLAT won't
work, ie the app breakage will be there, even though it they could be
avoided.

> > operate like that, and documenting publicly their setup/experiences.
> Also no

For a start, NAT64 authors saw a benefit, so unless we're redefining that
we should follow, or be very precise why not. To me, the impression that
/96 is faster not entirely justified.
Besides this, the length of the prefix is relevant to operators who care
about route summarization and optimization, besides actual subnetting. It's
similar to why we don't have rules for a "simple and intuitive" fixed host
subnet length in IPv6.

> The fact that is knows means that it is CLAT subset of any CPE that does

This seems to contradict the previous statement about this draft not being
a device spec.
If the CLAT is fully RFC6145 compliant, it should be clearly stated, and
text about /96, etc removed. If you're assuming that the CLAT is a subset
of RFC6145, then it would be best if you put the specifics of those
assumptions + anything else that is needed for the spec in a separate draft.

-Woj.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 8 Mar 2012 06:09:05 -0800

environment. In
> Yes, that's why architectures should be broad usage based.

Disagree. You may have a successful architecture for an air plane, but if
you change the use case such that it must act as a boat ... that is an
implementation failure. It does not make the airplane architecture a
failure as soon as somebody puts it in the water

Out of scope.

Also no
mapping?

Saying the nat64 authors saw a benefit is not demonstrating value for the
464xlat scenario.

Quantify how it is not faster, if that is your claim.

Route summaries? As the draft says clearly, /64 is the best and likely case
is that is with dhcp pd. The /96 is a case of nd proxy or similar. Neither
have any impact on route summaries.

In both cases above you made unsupported claims which makes me go back and
justify why your unsubstantiated claim is wrong with facts and use cases.

Please clearly substantiate your claims with examples in the future. ...
for example, if you are going to claim this makes more routes, clearly
articulate why you believe that. Otherwise you will be dismissed as
creating FUD.

6145
>
>
> This seems to contradict the previous statement about this draft not
being a device spec.

Disagree.

Cb

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 14 Mar 2012 19:52:48 +0100

> >> >> > IPv6 address format in 464XLAT is presented in the following

Nobody defines airplanes to be fixed size 96 seaters, etc.

> > For a start, NAT64 authors saw a benefit, so unless we're redefining
> that we should follow, or be very precise why not. To me, the impression
> that /96 is faster not entirely justified.
Basic question: Why are you asking the WG to adopt your document and define
your architecture CLAT and all? If you're seeking the blessing for
operating a standard based NAT64 network set-up in a specific way that you
call xlat464, then IMO you don't need a specific WG blessing. Indicators
are that this draftl is intended to drive a specific device specification
which it calls CLAT xlat464. This is a "sub class" of NAT64 effectively
that is not suitable for use as a vanilla NAT64, beyond the narrow &
specific assumptions and constraints you found convenient in your setup.
Anything else is marked as "out of scope" and I think that this specificity
is a problem. There is no problem with having your setup documented, but
there is with having your setup be the only subject of a device spec.

> Quantify how it is not faster, if that is your claim.
LOL. You made a design decision that claims benefit in curtailing valid use
of an existing RFC specification. If anything, the burden of proving the
case of how a /96 is faster/whatever vs a /64 or a /32  rests on you,
otherwise just follow the existing spec, and loose the specificity.

> Route summaries? As the draft says clearly, /64 is the best and likely
> case is that is with dhcp pd. The /96 is a case of nd proxy or similar.
> Neither have any impact on route summaries.
>
DHCP-PD's will be shorter than /64. The /64 is another assumption that is
highly limiting.

> articulate why you believe that. Otherwise you will be dismissed as

Given your previous posts something tells me that any use-case will be
dismissed as "out of scope" for your specific deployment.
FWIW a couple of cases are:

Case 1: Operator wants to assign a specific IPv4 address (public) for a
CLAT user. Under the existing spec, the operator would need to also install
an extra /96+ route
Case 2: Two CLATs on a shared link segment network (eg a WiFi). How do we
route to each CLAT?
etc..

> >> The fact that is knows means that it is CLAT subset of any CPE that
> does 6145
> >
> >

You disagree with what? If you're claiming that the CLAT is fully in line
with RFC6145 compliant then why do you object to removing specificity or
assumptions (ie hard coded configuration) that is NOT present in RFC6145?
Having it both ways looks untenable.

Suggestion of a way forward: Just replace the text in Section 6.1, besides
other normative terms, with text like "The CLAT is a device conforming to
stateless NAT46 as per RFCxxxx. In the xlat464 set-up it was configured to
use /X (whatever prefix you found convenient. This was due to ... (whatever
reasons you thought of", etc.

-Woj.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 14 Mar 2012 12:32:43 -0700

On Wed, Mar 14, 2012 at 11:52 AM, Wojciech Dec <[email-masked]> wrote:
>> implementation failure. It does not make the airplane architecture a failure
>> as soon as somebody puts it in the water
>
>
> your architecture CLAT and all? If you're seeking the blessing for operating
> a standard based NAT64 network set-up in a specific way that you call

It's an informational document, not a standard.

> xlat464, then IMO you don't need a specific WG blessing. Indicators are that

Actually its called 464XLAT, not xlat464

> this draftl is intended to drive a specific device specification which it
> calls CLAT xlat464. This is a "sub class" of NAT64 effectively that is not

Yes, any unique and specific architecture, such is the case with
464XLAT, can be considered a sub-class of all the possible scenarios
for using a standard, such as NAT64

> suitable for use as a vanilla NAT64, beyond the narrow & specific
> assumptions and constraints you found convenient in your setup. Anything
> else is marked as "out of scope" and I think that this specificity is a
> problem. There is no problem with having your setup documented, but there is

Why is it a problem to you specifically?

> with having your setup be the only subject of a device spec.
>
>>

I think your definition of "highly limiting" is bizarre.
Informational documents do not limit anything.  They are simply
descriptive.

Once again, we are simply documenting something that is known to work,
we are not trying to enable *you*  or the internet at large with a
standard track document.

We are documenting a known solution and running code in an
informational document.

>> articulate why you believe that. Otherwise you will be dismissed as creating
>> FUD.
>
>
>

I am documenting what i know to work.  If you want to write another
document describing *your scenario* of something *you know to work*,
please do so.

> Case 1: Operator wants to assign a specific IPv4 address (public) for a CLAT
> user. Under the existing spec, the operator would need to also install an
> extra /96+ route

That is not 464XLAT, that is MAP-T.  You seem to confuse these 2, and
i assume that is the root of all your confusion and comments.

Trying to do what you suggest, assigning public IPv4 addresses (and i
assume ports sets ...which is MAP-T) , would directly preclude the
ability of 464XLAT to do port overloading on the PLAT to get beyond
64,000 sessions per IPv4 address.  It is also not dynamic.  Please
stop trying to pound the known implementation of 464XLAT into MAP-T,
it is not helpful to the list.

> Case 2: Two CLATs on a shared link segment network (eg a WiFi). How do we

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.7

>> > text about /96, etc removed. If you're assuming that the CLAT is a subset of
>> > RFC6145, then it would be best if you put the specifics of those assumptions
>> > + anything else that is needed for the spec in a separate draft.
>> >
>>
>> Disagree.
>
>

Once again, this is an informational document describing and known
working architecture that leverages existing standards and running
code, both commercial and open source.

It is not a new standard, and it simply shows how a specific scenario
is known to work today.

> reasons you thought of", etc.

But i do not know that to work and i do not see the benefit in
expounding on theoreticals in an informational document that describes
a known working scenario.  The "running code" does not support the
setup you speak of, and adding that does not provide a tangible
benefit to the implementors.

If you know things to work in a certain way, then you may document them as such.

CB

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 15 Mar 2012 10:03:00 +0100

> operating

You haven't answered a major question; what is the purpose/goal of the
document?
Please also see: http://tools.ietf.org/html/rfc2026#section-4.2.2 regarding
Informational specification track.

> we are not trying to enable *you*  or the internet at large with a

You are seeking WG adoption of the document, which to most means that you
want contribution and backing of the wider IETF WG community. If you have
no interest in this, I would suggest that this work be progressed as an
individual contribution. There should be no issue with that if all you seek
is to document a setup that works (we do already know that NAT64 works -
thanks). If not, then what is it that you're seeking/expecting from the WG
adoption of this document?

> it is not helpful to the list.

Assigning a public IPv4 v6 embedded address, without sharing, is a
legitimate use-case and applicable to the general NAT64 spec - it's not
MAP-T. How does xlat handle this use-case would be helpful to understand.
You haven't explained that.

> benefit to the implementors.

I don't quite see why you object to the proposed alternative text. But, if
as you say, the running code, based on you spec, does not support such a
setup, then it's not regular NAT64 as you claim it to be.
Your statement about "benefit to implementors" again underscores the fact
that you're trying to define/recommend (ie specify) implementations, based
on some "described" sub-set of NAT64 and some assumptions, rather than
simply document a setup that uses regular NAT64 functionality (as I
suggested you did). While there may be a valid case for such a
"description", the case for it should validated a bit more rather than just
saying "I have it running in my network", and effectively "I don't care
about it working on other networks where the same problem applies".

-Woj.

---

From: Gert Doering <[email-masked]>
Date: Thu, 15 Mar 2012 12:38:25 +0100

Hi,

> You haven't answered a major question; what is the purpose/goal of the

To tell people about a specific solution that solves a specific problem.

I, for one, appreciate that.  I'm an operator, and I like it if I can
look at recipes for "if you have a problem similar to *this*, here's one 
possible solution that could work for you as well" - and the IETF benefits
from producing documents that operators find useful.

Now, what is the goal of *your* actions?  I find this somewhat confusing,
you spend quite some effort in telling Cameron that he's getting it all
wrong - so what is your agenda?

Gert Doering
        -- Operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 15 Mar 2012 14:25:52 +0100

> from producing documents that operators find useful.

Cool, no problem with that, but in doing so would you agree if the solution
did not attempt to be a spec for implementers of a "sub-class" NAT64 -
which it appears intended on being. I proposed formulating some text that
would remove this concern.

> wrong - so what is your agenda?

Perhaps you didn't quite read the thread where I wrote "I think that this
work is very useful and am supporting...".
In terms of the issue; consider some of the use-cases that this solution
apparently does not support, but which a standard NAT64 based solution has
no problem with, eg use on non 3G networks, or even on 3G networks where
operators have some different ideas on IP subnet design or routing or
services. Given that this solution claims to be using regular NAT64, but
doesn't support such use-cases, there is something amiss.
Seeking clarity on that, the underlying assumptions, is a good thing to
have for a document seeking WG acceptance. Furthermore, the core problem
that this draft addresses fundamentally (IPv4 over and acrss IPv6) is the
subject of various other drafts - knowing how these compare should be
understood, unless you're saying that you're happy with potentially
operating N different solutions for this core problem due to specific
issues with each, that you'll only find out about when specific & not
compatible devices are shipping for each?

Woj
- Individual

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 15 Mar 2012 08:13:48 -0700

On Thu, Mar 15, 2012 at 6:25 AM, Wojciech Dec <[email-masked]> wrote:
> did not attempt to be a spec for implementers of a "sub-class" NAT64 - which
> it appears intended on being. I proposed formulating some text that would
> remove this concern.
>
>>
>>
>>

You say that it will not work on 3G or non-3G networks when they have
'different ideas' about addressing?

"different ideas" is not a technical argument.

And, in fact, the case of 3GPP... there is no different ideas about
numbering in IPv6, there is only 1 idea, /64 per network attachment,
no other way.

http://tools.ietf.org/html/rfc6459#section-5.2

> services. Given that this solution claims to be using regular NAT64, but

Yes, a regular NAT64 can be configured with Pref64 =  /96, and in
fact, AKAIK, this is best practice for NAT64 operators to use a /96
specifically.

I have, in practice, never seen anything other than a /96.

> Seeking clarity on that, the underlying assumptions, is a good thing to have

Seeking clarity?  You have sent several emails with the same hand wavy request.

> for a document seeking WG acceptance. Furthermore, the core problem that

Rough consensus and all meaningful technical issues have been addressed, AFAIK

> this draft addresses fundamentally (IPv4 over and acrss IPv6) is the subject
> of various other drafts - knowing how these compare should be understood,

^^^^^^ there's the meat.  Woj wants to cast 464XLAT as a subcase of
MAP-T.  But this is not possible since MAP-T is explicitly by Softwire
charter a stateless solution.  And, 464XLAT is explicitly a stateful
solution.

> unless you're saying that you're happy with potentially operating N
> different solutions for this core problem due to specific issues with each,

Some people like IS-IS, others like OSPF, i don't see the problem with
having both and letting operators choose.

464XLAT can been seen as simply an operational guide to improving
chances of success with the existing transition strategy outlined in
RFC6144

> that you'll only find out about when specific & not compatible devices are
> shipping for each?
>

Ah, but be afraid of the unknown. FUD.  The purpose of 464XLAT is to
explain what works, not define what does not work.

> - Individual
^^^^
Who also works at Cisco and does not run a network and is a co-author
of MAP-T in Softwires (since someone asked about "agendas" on the
list)

CB

---

From: Rémi Després <[email-masked]>
Date: Thu, 15 Mar 2012 17:02:09 +0100

>> of various other drafts - knowing how these compare should be understood,

+1 on the need for conscious study of what is common to stateless and stateful (quite a bit AFAIK).
> charter a stateless solution.  And, 464XLAT is explicitly a stateful

I proposed to explain, in v6ops, the common ground between 464XLAT-like scenarios and a feature of the 4rd-u proposal that has been introduced precisely for such scenarios.

This doesn't seem to be welcome so far in v6ops, but I KEEP HOPE that people like you could become such a presentation (after all, avoiding to talk about problems isn't the best way to solve them, right?).

> chances of success with the existing transition strategy outlined in

There has been an interesting discussion beginning in v6ops on whether it would be preferable to have NAT44s in UEs, or not. 
Isn't this, for example, a valid subject to be continued in v6ops (an with due understanding of what is common to Softwire solutions regarding NAT44s in customer nodes).

Regards,
RD

PS: To me, 4X4XLAT as a v6ops informational document is less logical than having it as an individual submission, but can be acceptable provided discussion on how it relates to Softwire's solutiopns isn't excluded.

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 15 Mar 2012 19:40:49 +0100

> fact, AKAIK, this is best practice for NAT64 operators to use a /96

The point is that NAT64 allows other configurations while your "document"
somehow insist on that /96 hard rule. Modify the text to saying that this
is what you used/configured in your deployment, why you found it useful
perhaps, and we'd be settled on this point.

> have

Let's see. So far we've deduced that you do NOT expect this to work (ie it
is out of scope):
- beyond your 3G network, eg it's not expected to work when a user connects
that same device via WiFi say (unless all networks are made to look like
3G, apparently)
-  with a different core NAT64 device, ie a stateless core NAT64.
- if an operator actually wants to support a fixed/public IPv4 address to
the UE (a service model seen in many 3G networks today - not yours, I
understand).
- Cases where routing on /96s is not viable.
- Connecting clients on a shared prefix/subnet
- Addressing with a DHCP PD that's different than a /64
- NAT44 on the UE.
While you may say that this is hand waving, at least I know your better
assumptions now. It would be useful to have these, or rather the inverse
"working service" assumptions clarified in the doc IMO.

> charter a stateless solution.  And, 464XLAT is explicitly a stateful

You keep on coming back to MAP-T, not me, nor am I pushing to present that
as the "right" solution. I'm focusing on the fact that you claim the CLAT
to be regular NAT64, but yet continue to refuse to relax text (section 6.1)
that a regular NAT64 does not have. That and understanding the assumptions
of your solution.

> explain what works, not define what does not work.

There is nothing unknown here, other than perhaps further undocumented
assumptions of 464xlat. :-)
What is known however is that there are multiple solutions to the same core
problem of v4 over & across v6 (dIVI, BIH, MAP-T, 4rd-u, etc), of which
464xlat appears to be one, and which does involve some unique functional
specification that you seek to drive, eg the workings of the CLAT.
Without some IETF consolidation/rationalization/guidance, and given that
this document (and others) are to steer implementers (your words), we're
headed for a likely scenario of partially or fully incompatible solutions.
Each solution does have its specific nuances, and IMO it would be of
interest to the v6ops WG ie the operator & vendor community to actually
understand these, when making one or multiple recommendations. Effectively
saying "Here's my solution, it works for what I need, don't care about
anything else. Please adopt it as is as an IETF recommendation, because I
need that to get it in front of my implementers/vendors" without even
bothering to look for commonality appears not entirely reasonable, to me at
least in terms of an IETF doc. I believe Remi also called for as much. The
prospect of N WG's all with work on this "common problem" is not appealing.

> of MAP-T in Softwires (since someone asked about "agendas" on the

I know that you're perhaps not very familiar with the customs of the ietf,
but the general rule is that everyone speaks as an individual.
My MAP-T if not other work, allows me some modest insight into this problem
space, and as stated previously my agenda is to seek clarity in your
specification and an understanding of the differences between xlat and the
various other solutions.

-Woj.
 -Individual (working currently for a vendor, and net-ops guy in a former
life)

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 15 Mar 2012 13:26:53 -0700

On Thu, Mar 15, 2012 at 11:40 AM, Wojciech Dec <[email-masked]> wrote:
> somehow insist on that /96 hard rule. Modify the text to saying that this is
> what you used/configured in your deployment, why you found it useful
> that same device via WiFi say (unless all networks are made to look like 3G,
> apparently)

The list above is a bit of a broad brush, but i believe the 464XLAT
draft describes accurately the situation that we know to work.

464XLAT is not expected to work in environments that are not 464XLAT.

Can we please agree to disagree and end the these emails?  If other WG
folks have a concern, they may express it.

Woj, your perspective is well documented in the archive.

> as the "right" solution. I'm focusing on the fact that you claim the CLAT to
> be regular NAT64, but yet continue to refuse to relax text (section 6.1)

ACK, your position is known.

> assumptions of 464xlat. :-)

Classy.

> headed for a likely scenario of partially or fully incompatible solutions.

Yes.  This is not a new problem, and i would argue that it is not a
problem at all.

IS-IS is not compatible with OSPF, and i don't see people coming up
with extension to make it so.

> understand these, when making one or multiple recommendations. Effectively

This is not a recommendation, it is an informational draft.

> prospect of N WG's all with work on this "common problem" is not appealing.

ACK. Thanks for the feedback.

CB

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 16 Mar 2012 14:43:48 +0900

> perhaps, and we'd be settled on this point.

Where does the draft insist that a /96 should be used? Are you talking
about the IPv6 address format in section 6.1 or the text in section 6.5
that says "CLAT may take ownership of a /96 from an attached interface's
/64"?

---

From: "George, Wes" <[email-masked]>
Date: Sat, 24 Mar 2012 08:58:20 -0400

I've read and support this draft. One comment after having read the draft and this thread:
Currently in 6.1 the draft says "The format is defined in
   Section 2.2 of [RFC6052].  However, 464XLAT does not use the Well-
   Known IPv6 Prefix "64:ff9b::/96"."

However, it does not explicitly explain why it does not use the WKP, and unless I'm being thick (which is entirely possible), the discussion you've had with Woj does not either. I assume that there's a valid reason, which should be explained following that statement.

Thanks,

Wes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cameron Byrne
>

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: Cameron Byrne <[email-masked]>
Date: Sat, 24 Mar 2012 07:28:33 -0700

> I've read and support this draft. One comment after having read the draft
and this thread:

Thanks for the support

> However, it does not explicitly explain why it does not use the WKP, and
unless I'm being thick (which is entirely possible), the discussion you've
had with Woj does not either. I assume that there's a valid reason, which
should be explained following that statement.

Wkp constrains the architecture too much.

Wkp does not work well at large scale where it is desired to specifically
traffic engineer load  using unique NSP to load and unload a given PLAT.

One could anycast the wkp, but anycast clashes with stateful behavior at
the PLAT... I'd rather not tightly couple PLAT load with routing topology.

In the case where the PLAT is located in a different administrative domain,
wkp is not possible .... as where NSP may be carried even in the DFZ to
allow CLAT on the internet to communicate with internet hosted PLATs

We can boil the above down to a sentence and add it to the draft to
increase clarity.

Thanks again for the review and support.

Cb

> 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.
 On Mar 24, 2012 5:58 AM, "George, Wes" <[email-masked]> wrote:

> However, it does not explicitly explain why it does not use the WKP, and
> unless I'm being thick (which is entirely possible), the discussion you've
> had with Woj does not either. I assume that there's a valid reason, which
> should be explained following that statement.
>
> Thanks,
>
> Wes
>
>
>
> 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: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 24 Mar 2012 20:56:15 -0400

Cameron,

I agree with you, if we assume that PLAT function is not enabled on the UE's IP next-hope e.g. GGSN/P-GW. 

Of course, if that assumption weren't true in any deployment, then WKP could well be used without any of those concerns you rightly pointed out.

Just an (obvious) observation that may be worth including.

Cheers,
Rajiv

Sent from my Phone

On Mar 24, 2012, at 10:28 AM, "Cameron Byrne" <[email-masked]> wrote:

> Wkp does not work well at large scale where it is desired to specifically traffic engineer load  using unique NSP to load and unload a given PLAT.
> 
> One could anycast the wkp, but anycast clashes with stateful behavior at the PLAT... I'd rather not tightly couple PLAT load with routing topology.
> 
> In the case where the PLAT is located in a different administrative domain, wkp is not possible .... as where NSP may be carried even in the DFZ to allow CLAT on the internet to communicate with internet hosted PLATs
> 
> We can boil the above down to a sentence and add it to the draft to increase clarity.
>