Subject: Re: [OPSAWG] adoption of Draft-kuarsingh-lsn-deployment as WG item

From: "George, Wes" <[email-masked]>
Date: Sun, 1 Apr 2012 07:29:15 -0400

This seems like another of the drafts orphaned by BEHAVE. It's specific to CGN, and therefore not exactly suited to OpsAWG but I'm not opposed to us adopting it absent a better suggestion.

Some comments on the draft-
I think it would make sense for section 1/2 and the draft overall to focus a lot less on the rationale for deploying CGN. Yes, there are a lot of folks that view it as inherently evil and abhorrent, but we need to sort of get over that in order to make any forward progress. CGN exists, and it's going to get used no matter how much some protest. So rather than talking about why carriers might deploy it and expending considerable text performing apologetics about it, I'd rather the draft get straight to the point about the problems that this draft solves.
That is, assuming that the carrier has already decided they will use CGN, they have the following problems. This draft solves them by ...
" This document shows how MPLS/VPNs as described in [RFC4364] can be
   used to integrate the CGN infrastructure solving key problems faced
   by the operator."
It'd be helpful if those "key problems" could be summarized in the intro or second section, and then expounded upon in later sections along with the MPLS VPN-based solution.

I'm also not clear on what portions of section 3 have to do with the proposed problem/solution space. Portions of it seems to be to be generalized CGN deployment considerations. That may be fine, but that's not technically what this document purports to discuss, and maybe should be in another document, perhaps even the lsn-requirements document. I can sort of see where L3VPN might help with some of these requirements, but this section should focus more crisply on the requirements that are difficult to solve without the use of the solutions proposed in this document.

You have an orphan/empty section 5

I'd also drop the "problems this doesn't solve" in section 7 unless you'd like to turn it into a gap analysis with a mind towards asking IETF to solve those problems with protocol changes. If it's purely informational, you'll likely never be done documenting the problems with CGN that aren't solved. This is the essence of a "we don't know what we don't know" system, so it's misleading to discuss it as if it was a complete list.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christopher LILJENSTOLPE
> Sent: Wednesday, March 28, 2012 4:53 AM
> To: [email-masked]
> Cc: opsawg-chairs
> Subject: [OPSAWG] adoption of Draft-kuarsingh-lsn-deployment as WG item
>
> Greetings,
>
>       This is to start a poll in the working group to see if we want to accept
> Draft-kuarsingh-lsn-deployment as a working group item.  We will leave this
> poll open until 2359 UTC on 4 April.  Please speak early and often.
>
>       Chris
>
> --
> 李柯睿
> Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
> Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf
> Check my calendar availability: https://tungle.me/cdl
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

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: Victor Kuarsingh <[email-masked]>
Date: Sun, 01 Apr 2012 21:13:23 +0200

Wes,

On 12-04-01 1:29 PM, "George, Wes" <[email-masked]> wrote:

>I think it would make sense for section 1/2 and the draft overall to
>focus a lot less on the rationale for deploying CGN.

Understood.  The original -00 version was drafted early on in the CGN
discussion (July 2010) when such work required a boiler plate in front to
just get people to keep reading.  It's likely that enough other material
is available as reference that we can just point there and remove some of
this text.

>Yes, there are a lot of folks that view it as inherently evil and
>abhorrent, but we need to sort of get over that in order to make any
>forward progress. CGN exists, and it's going to get used no matter how
>much some protest. So rather than talking about why carriers might deploy
>it and expending considerable text performing apologetics about it, I'd
>rather the draft get straight to the point about the problems that this
>draft solves.

Understood.  This document is not directed at such dissenters.  It's
targeted to those operators who have by due diligence decided that CGN
plays a part of there network service for a period of time.

>That is, assuming that the carrier has already decided they will use CGN,
>they have the following problems. This draft solves them by ...
>It'd be helpful if those "key problems" could be summarized in the intro
>or second section, and then expounded upon in later sections along with
>the MPLS VPN-based solution.

I can look into doing that.

>
>I'm also not clear on what portions of section 3 have to do with the
>proposed problem/solution space. Portions of it seems to be to be
>generalized CGN deployment considerations. That may be fine, but that's
>not technically what this document purports to discuss, and maybe should
>be in another document, perhaps even the lsn-requirements document. I can
>sort of see where L3VPN might help with some of these requirements, but
>this section should focus more crisply on the requirements that are
>difficult to solve without the use of the solutions proposed in this
>document.

Wes, I can revisit the assessed requirements vs. what is in the
lsn-requiremetns document (which was not a WG draft when I first started).
 That said, some of the requirements were not about how an LSN should
work, but more about how to make an LNS work in a real network that has
running IPv4 legacy and may have IPv6 soon.  I can rework the requirements
to make sure I don't overlap with the lsn-requirement draft
(draft-ietf-behave-lsn-requirements-05).  I will keep mine closer to
"network" related issues.

>You have an orphan/empty section 5

Sorry, fallout from previous version.  I had included experiences in this
draft until a better draft was published. I have since pulled this out.
Reference - draft-donley-nat444-impacts-03.  I can just point to that now
(given our experiences where ported there).

>
>I'd also drop the "problems this doesn't solve" in section 7 unless you'd
>like to turn it into a gap analysis with a mind towards asking IETF to
>solve those problems with protocol changes. If it's purely informational,
>you'll likely never be done documenting the problems with CGN that aren't
>solved. This is the essence of a "we don't know what we don't know"
>system, so it's misleading to discuss it as if it was a complete list.

Seems fair.  I can address that.

>Wes George

I appreciate your review.  I spin a new version once I get some additional
feedback.

Victor K

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