Subject: [sunset4] "determine if CGN is a suitable sunsetting technology"

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 May 2012 11:00:35 +0100

I would suggest that RFC 6264 already discusses this point
and implicitly describes a sunset model. It isn't explicit,
because we weren't really trying to do that, but it certainly
shows how CGN can take a carrier in that direction.

However, this doesn't demonstrate a gap to be filled by new IPv4
work in this WG - it tends to show that for carriers, no new
standards work is needed (if they choose to go the CGN route).

It seems to me that the first work here should be to describe
scenarios at subscriber, carrier and enterprise sites and then
proceed to a gap analysis. That's what is needed to answer questions
1) and 2) in the charter, IMHO.

    Brian

-- 
Regards
   Brian Carpenter

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 02 May 2012 03:43:43 -0700

"1) describe the problem to be solved and show that there is widespread
demand for a solution"

>standards work is needed (if they choose to go the CGN route).

I think there is a body of work related to CGN that shows standard work is
needed. 

>proceed to a gap analysis.

We already have your draft,
http://tools.ietf.org/html/draft-kuarsingh-lsn-deployment-06 that deal
with scenarios and others. We have mine with some other co-authors that
show 'gaps' related to current implementations amongst others. Hopefully
we can leverage much of that as we go through the 'gap and scenarios'
motions.

>That's what is needed to answer questions

>    Brian
>
>
>
>
>
>-- 
>Regards
>   Brian Carpenter
>
>
>_______________________________________________
>sunset4 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sunset4

---

From: "George, Wes" <[email-masked]>
Date: Wed, 2 May 2012 09:54:39 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Wednesday, May 02, 2012 6:01 AM
> To: Sunset IPv4
> Subject: [sunset4] "determine if CGN is a suitable sunsetting technology"
>
[WEG] Yes, but we all need to re-read it with the appropriate changes to our prescription that this charter represents. It probably needs at least an update via another draft or even a Bis doc. More on that below.
> standards work is needed (if they choose to go the CGN route).
[WEG] The two don't have to be joined in every case. I think that CGN is probably one of those where those two items are not related because protocol work is unnecessary. Protocol work necessary for IPv4 sunset is things like new options in IPv4 protocols to handle the fact that they're being turned off (responses to legacy devices with "sorry, not supported" etc)

> 1) and 2) in the charter, IMHO.
[WEG] I agree with Reinaldo that the Kuarsingh draft may help with that. It's also likely that we need to make some modifications to draft-ietf-behave-lsn-requirements to absorb some lessons learned and more explicitly note the IPv4 sunset angle. That draft (or some other) may need to formally update 6264, as I've always seen 6264's "IPv6 transition" as a bit of an afterthought - here's how you do CGN, and oh by the way, it's an IPv6 transition technology in that it doesn't actively prevent IPv6. But then it recycles the standard set of methods to deploy IPv6 in a way that's almost wholly unrelated to the specifics of CGN.

I've already gone on record with the appropriate ADs as being a bit bothered by the language chosen in the charter regarding CGN as a sunsetting technology because I think it's a difficult argument to make. How does deploying CGN, by itself, advance IPv6 deployment? I don't have a good answer, but I believe that our charter requires us to figure one out if we proceed with standardizing CGN.

I'm expecting some additional guidance on the matter from the associated ADs, other WG chairs, etc in the coming weeks as we discuss how to transition things from existing WGs, division of work, etc, so while this is good discussion, we ask your patience while we figure this out in a way that helps us to make forward progress on the charter items. I know there's a lot of unanswered questions.

Thanks
Wes George

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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 May 2012 16:08:12 +0200

> [WEG] The two don't have to be joined in every case. I think that
> CGN is probably one of those where those two items are not related
> because protocol work is unnecessary.

I like to point out that there are no standard MIBs for monitoring
boxes such as CGN. The MIB modules we have lack features. See for
example here:

http://tools.ietf.org/html/draft-schoenw-behave-nat-mib-bis-00
http://tools.ietf.org/html/draft-perreault-opsawg-natmib-bis-00
http://tools.ietf.org/html/draft-ietf-behave-nat-mib-00

The last one is mentioned in the sunset4 charter, not sure whether
this means the intention is to move this document from behave to
sunset4. Perhaps the intention was just to be undefined. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 May 2012 17:35:35 +0100

Mainly agreed, comments in line:

On 2012-05-02 14:54, George, Wes wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Brian E
>> Carpenter Sent: Wednesday, May 02, 2012 6:01 AM To: Sunset
>> IPv4 Subject: [sunset4] "determine if CGN is a suitable
>> sunsetting technology"
>> 
>>  because we weren't really trying to do that, but it
>> certainly shows how CGN can take a carrier in that
>> direction.
> [WEG] Yes, but we all need to re-read it with the appropriate
> changes to our prescription that this charter represents. It
> probably needs at least an update via another draft or even a
> Bis doc. More on that below.
>> However, this doesn't demonstrate a gap to be filled by new
>> IPv4 work in this WG - it tends to show that for carriers,
>> no new standards work is needed (if they choose to go the
>> CGN route).
> [WEG] The two don't have to be joined in every case. I think
> that CGN is probably one of those where those two items are
> not related because protocol work is unnecessary. Protocol
> work necessary for IPv4 sunset is things like new options in
> IPv4 protocols to handle the fact that they're being turned
> off (responses to legacy devices with "sorry, not supported"
> etc)
> 
>> It seems to me that the first work here should be to
>> describe scenarios at subscriber, carrier and enterprise
>> sites and then proceed to a gap analysis. That's what is
>> needed to answer questions 1) and 2) in the charter, IMHO.
>> 
> [WEG] I agree with Reinaldo that the Kuarsingh draft may help
> with that. It's also likely that we need to make some
> modifications to draft-ietf-behave-lsn-requirements to absorb
> some lessons learned and more explicitly note the IPv4 sunset
> angle. That draft (or some other) may need to formally update
> 6264, as I've always seen 6264's "IPv6 transition" as a bit
> of an afterthought - here's how you do CGN, and oh by the
> way, it's an IPv6 transition technology in that it doesn't
> actively prevent IPv6. 

I'm a bit disappointed that it can read that way. My frame of
mind (and I believe my co-author's too) was: "Some carriers will
insist on CGN. Let's document how that fits into an IPv6
transition strategy." We didn't spend much time on IPv6-only,
because that really didn't seem like a fruitful discussion
with major carriers for a number of years to come.

> But then it recycles the standard set
> of methods to deploy IPv6 in a way that's almost wholly
> unrelated to the specifics of CGN.

Absolutely, and that's the whole point. You can do CGN and do
the IPv6 transition of your choice, simultaneously and on
the same platform. No new protocol, which is why it was in
the V6OPS charter - and exactly why I don't see it as needing
more work here.

> I've already gone on record with the appropriate ADs as being
> a bit bothered by the language chosen in the charter
> regarding CGN as a sunsetting technology because I think it's
> a difficult argument to make. How does deploying CGN, by
> itself, advance IPv6 deployment? I don't have a good answer,
> but I believe that our charter requires us to figure one out
> if we proceed with standardizing CGN.

We may in fact be agreeing violently ;-). I see how NAT46 and
464XLAT might assist in v4 sunsetting, but those are quite
different scenarios from CGN.

   Brian

> 
> I'm expecting some additional guidance on the matter from the
> associated ADs, other WG chairs, etc in the coming weeks as
> we discuss how to transition things from existing WGs,
> division of work, etc, so while this is good discussion, we
> ask your patience while we figure this out in a way that
> helps us to make forward progress on the charter items. I
> know there's a lot of unanswered questions.
> 
> Thanks Wes George

---

From: "George, Wes" <[email-masked]>
Date: Wed, 2 May 2012 13:46:00 -0400

> > That draft (or some other) may need to formally update
> transition strategy."

[WEG] Brian - I have no doubt that was your intent. I think what has happened is that this is the only document that "standardizes" CGN thus far, because CGN is more of a conceptual application of existing protocols and technology than it is a new standard. As a result, 6264 is being viewed more as a CGN document and less as a document that says "you can and should still do IPv6 even if you have to do CGN". Reopening the discussion gives us an opportunity to put a finer point on it.

Wes George