Subject: [Gen-art] Gen-Art review of draft-ietf-opsawg-lsn-deployment-04

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Jan 2014 10:44:20 -0800

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-opsawg-lsn-deployment-04
Reviewer: Martin Thomson
Review Date: 2014-01-06
IETF LC End Date: 2014-01-06
IESG Telechat date: (if known)

Summary:  This document describes a generic way that MPLS LSPs can be
deployed to support the deployment of CGNs in a way that addresses a
range of common requirements.  As a draft, it's still a little rough,
but it is mostly ready for publication as an Informational RFC.

Major issues: none

Minor issues:

The abstract says this:

  This document does not intend to defend the
   merits of CGN.

Which seems wise given their somewhat contentious nature.  But then
the entirely of Section 2 does exactly the opposite.  I don't know
what the right answer is here, but maybe the right thing to do is
delete Section 2.

Figures 1 and 2 should probably use different labels for the two CPE
boxes.  The top one is being translated, the bottom one isn't.

Section 6 is a little too speculative to be valuable.  How about using
the boilerplate:

      This document has no IANA actions.

I'm not sure what "security measures" might be employed here:

   If a provider plans to operate the pre-translation realm (CPE towards
   translator IPv4 zone) as a non-public like network, then additional
   security measures may be needed to secure this environment.

What might be secured in these scenarios?  Confidentiality?  Access to
network resources?  Perhaps this should talk about what a network
operator wants to secure: access to the network.  Then maybe talk
about access control and isolation.

In Section 4, this seems a little vague:

   Various redundancy models
   can be used within this architecture to support failover from one
   physical CGN hardware instance to another.

I don't expect an enumeration of the options, but this seems important
enough to at least point to where the redundancy options might exist?
Redundant "VPNs"/LSPs?  Redundant paths from the VRF termination?

Nits:

Missing period in Section 9

I found the structure of the first part of Section 3.1 difficult:

   Centralized deployments of CGN (longer proximity to end user and/or
   higher densities of subscribers/connections to CGN instances) differ
   from distributed deployments of CGN (closer proximity to end user and
   /or lower densities of subscribers/connections to CGN instances).

Maybe this could be expanded a little to improve comprehension.

This statement seems redundant:

   Other requirements may be assessed on a operator-by-operator basis,
   but those listed above may be considered for any given deployment
   architecture.

As far as it goes, some of the requirements listed might not apply to
a particular deployment, or part thereof.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 14 Jan 2014 18:10:50 +0100

Dear authors, doc. shepherd,

Can you please answer Martin.

Regards, Benoit
> .

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 15 Jan 2014 22:06:25 -0500

Benoit/Martin,

I apologize. I seem to have missed reading that email.  I review and replay.

regards,

Victor K

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 15 Jan 2014 22:40:20 -0500

Martin,

My responses in-line

> what the right answer is here, but maybe the right thing to do is

[VK]  The intention of this section was to explain that CGN may be used by
operators and discuss some of the factors that may go (or have gone) into
that decision.  The point in the abstract was intended to tell the reader
that the authors were not suggesting that CGN was "good" or "needed".

There are some important points that I think are important within the
section (section 2), so perhaps if I/we can remove specific text that seems
to given the impression that we are defending CGN, I can do so.

> boxes.  The top one is being translated, the bottom one isn't.

[VK]  Yes, that makes sense.  I can make that update.  Thanks for the
suggestion

>       This document has no IANA actions.

[VK]  I am ok with that.   Noted.

> about access control and isolation.

[VK]  The point here was that the document/authors have assumed the
position that the CGN realm (within the context of this document) is that
it's publicly accessible (to the extent that it can be behind a translation
function.   The point was that if an operator wanted something more secure
(which can be a number of thinks include items you listed like access
to/from the Internet etc) that those would require mode consideration.

We did not itemize those considerations as any list I generate would be
somewhat arbitrary (should I select a few examples).  If you feel that such
a partial listing is material, I can do so.  My concern here is that once
we put in such a list, we may have to deal with conversations like "why did
you not include such and such .. etc"

The overall expectation is that the operator should expect the same level
of exposure as traditional customers.

> Redundant "VPNs"/LSPs?  Redundant paths from the VRF termination?

[VK] Our expectation was that the operator would be able to derive their
own answers on how to enable redundancy in their model.  The expectation is
that the reader already would understand (or would need to verse
themselves) CGN and MPLS/VPNs.  Therefore they would be able to enumerate
the options on their own.

We were trying to keep the text simple and show the basic association of
how to deploy the CGN using MPLS/VPNs.  I would not want to sound
prescriptive on how to actually design a specific instance.

In disclosure, when I did my design, I did use multiple RD/RTs and imported
those routes into a common CPE VPN.  But that specific option may not be
used by others. I would expect an operator who has already deployed
MPLS/VPNs to have a redundancy model already in place, and they would
evolve that for this purpose.

To exemplify that point, I had discussions with two other Canadian ISPs who
tested/integrated CGNs using this method (MPLS/VPNs) and one did not put in
network based redundancy (just had to CGN functions at a common
endpoint/VRF) and the other did have redundancy but only employed a single
RD/RT (and just had multiple defaults).  Each of us (three) chose
redundancy models which matched our pre-existing MPLS network designs.  I
would expect the same from others as well (although this may be a poor
assumption).

> a particular deployment, or part thereof.

[VK]  I will make adjustments as specified.  I appreciate the text.

[VK]  I hope my responses are adequate.  Once again, I appreciate your
review of the draft.

regards,

Victor K

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Jan 2014 10:33:01 -0800

> to given the impression that we are defending CGN, I can do so.

I'd like to understand what you think is important here.  Much of the
text explaining why CGN is used basically amounts to justification for
it.

In contrast, the list of requirements you provide is fairly neutral
and seems to cover most of the reasons well enough for me at least.

> [VK]  The point here was that the document/authors have assumed the position
> that the CGN realm (within the context of this document) is that it's
> publicly accessible (to the extent that it can be behind a translation
> a partial listing is material, I can do so.  My concern here is that once we
> put in such a list, we may have to deal with conversations like "why did you
> not include such and such .. etc"
>
> The overall expectation is that the operator should expect the same level of
> exposure as traditional customers.

The problem with the text as it stands is that it is vague to the
point that it actively encourages the sorts of questions I raised.

If you want to avoid the questions, maybe consider whether the
sentence is even needed.

> [VK] Our expectation was that the operator would be able to derive their own
> answers on how to enable redundancy in their model.  The expectation is that
> the reader already would understand (or would need to verse themselves) CGN
> and MPLS/VPNs.  Therefore they would be able to enumerate the options on
> their own.
>
> We were trying to keep the text simple and show the basic association of how
> to deploy the CGN using MPLS/VPNs.  I would not want to sound prescriptive
> on how to actually design a specific instance.
>
> MPLS/VPNs to have a redundancy model already in place, and they would evolve
> that for this purpose.
>
> RD/RT (and just had multiple defaults).  Each of us (three) chose redundancy
> models which matched our pre-existing MPLS network designs.  I would expect
> the same from others as well (although this may be a poor assumption).

I don't think that you have to enumerate, though it is perhaps the
wording that is the problem here.  As phrased it implies a panoply of
wonderful options that are being purposefully withheld from the
reader.  Perhaps a rephrasing will make this intent clearer:

The described architecture does not prescribe a single redundancy
model that ensures network availability as a result of CGN failure.
Deployments are able to select a redundancy model that fits best with
their network design.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Jan 2014 01:06:20 +0200

Thanks for your detailed review, Martin!

And thank you Victor for a very useful document!

Much of the discussion in this thread is important but also partly editorial. I'll leave it to sort out between yourselves.

However, I do think Section 6 last sentence:

   Should a provide choose to use non-assigned IP address space within their translation realms, then considerations may apply.

gives an odd impression. We already have shared address space (as the document notes elsewhere), so it is not clear to me what the above might entail, particularly when (a) regular address space assignments go through the RIR system not IANA (b) use of unassigned address space is probably not something that we want to recommend and (c) if we need to do something beyond the existing shared address space allocation, then that probably deserves its own document.

I can see that Victor you've already agreed to make a change wrt Section 6. I just wanted to check that this is indeed the plan, so that we can move on to approving the document :-)

Jari

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 21 Jan 2014 23:24:39 -0500

Jari/Martin,

With respect to section 6, I agree we can remove the odd text and I will
follow Martin's suggestion.  The inclusion of that text was a bit
historical as the document was actual first drafted before RFC6598.

I would agree that (as this point) that text, as I have in the document,
servers little value - so it will be removed.  I will also respond to
Martins last email and confirm some of the editorial changes.

Jari,  Please let me know if I need if you need to see a new draft spun
before approvals or if confirmation of the changes is sufficient (I am ok
with either).  I was trying to capture all final adjustments for a -05
version before publishing.

regards,

Victor K

On Tue, Jan 21, 2014 at 6:06 PM, Jari Arkko <[email-masked]> wrote:

> Much of the discussion in this thread is important but also partly
> editorial. I'll leave it to sort out between yourselves.
>
>    Should a provide choose to use non-assigned IP address space within
> their translation realms, then considerations may apply.
>
> gives an odd impression. We already have shared address space (as the
> document notes elsewhere), so it is not clear to me what the above might
> entail, particularly when (a) regular address space assignments go through
> the RIR system not IANA (b) use of unassigned address space is probably not
> something that we want to recommend and (c) if we need to do something
> beyond the existing shared address space allocation, then that probably
> deserves its own document.
>
> I can see that Victor you've already agreed to make a change wrt Section
> 6. I just wanted to check that this is indeed the plan, so that we can move
> on to approving the document :-)
>
> Jari
>
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Jan 2014 13:00:25 +0100

Martin,
> On 15 January 2014 19:40, Victor Kuarsingh<[email-masked]>  wrote:
Is your concern that  the sentence "IPv6 is considered the strategic 
answer" in section 2 is not stressed enough?

Regards, Benoit

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Jan 2014 16:01:49 +0100

On 22 January 2014 13:00, Benoit Claise <[email-masked]> wrote:
> Is your concern that  the sentence "IPv6 is considered the strategic answer"
> in section 2 is not stressed enough?

I think that the text in the second paragraph is slightly more loaded.
 In particular,

   These issues
   leave an operator in a precarious position which may lead to the
   decision to deploy CGN.

The rest of the section uses similarly loaded:

   The ability to replace IPv4-only equipment may be out of the control
   of the operator, and even when it's in the administrative control, it
   poses both cost and technical challenges as operators build out
   massive programs for equipment retirement or upgrade.

"precarious position", "poses both cost and technical challenges", ...
all arguably true, but not strictly neutral.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Jan 2014 16:16:05 +0100

> all arguably true, but not strictly neutral.
Understood.

Victor, can you please improve those sentences, to be more neutral.
Also, you might be stress again in that section:

Regards, Benoit

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 22 Jan 2014 17:14:14 -0500

Martin,

I appreciate your review and followup.  Your input was most helpful.  I
have made a few changes which will address you concerns.

(1). Used your simplified text in IANA considerations section

(2).  Added CGN label to Diagrams

(3). Removed significant amount of text from Modification section.  Basic
points say that IPv6 is the strategic answer, and CGN choice is an operator
independent decision. If used (CGN) deployment should not impact IPv4
legacy or IPv6 deployment.

(4). Removed second paragraph from security section as you suggested to
help up and remove vagueness.

(5)  Used your recommended text on redundancy model.

regards,

Victor K

On Thu, Jan 16, 2014 at 1:33 PM, Martin Thomson <[email-masked]>wrote:

> position
> own
> how
> redundancy

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 22 Jan 2014 17:18:17 -0500

Jari,

I just responded to the gen-art list and Martin on his comments.

I have made a number of changes that address his comments and have used
much of his text.  ( I will be sending the Benoit and the rest of the IESG
a full summary of changes and new version posting tonight).

This includes the changes to section 6 as prescribed.

regards,

Victor K

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 22 Jan 2014 17:22:07 -0500

Martin,

I am loading a new new version today, but here is that section (originally
called "Motivation") for quick review.

** Beginning of section **

Existing Network Considerations (new name of section)

The selection of CGN may be made by an operator based on a number of
factors. The overall driver to use CGN may be the depletion of IPv4 address
pools which leaves little to no addresses for a growing IPv4 service or
connection demand growth. IPv6 is considered the strategic answer for IPv4
address depletion; however, the operator may independently decide that CGN
is needed to supplement IPv6 and address their particular IPv4 service
deployment needs.

If the operator has chosen to deploy CGN, they should do this in a manner
as not to negatively impact the existing IPv4 or IPv6 subscriber base. This
will include solving a number of challenges since subscribers whose
connections require translation will have network routing and flow needs
which are different from legacy IPv4 connections.

** End of section **

regards,

Victor K

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Jan 2014 05:21:13 +0100

WFM

On 22 January 2014 23:22, Victor Kuarsingh <[email-masked]> wrote:
> If the operator has chosen to deploy CGN, they should do this in a manner as
> not to negatively impact the existing IPv4 or IPv6 subscriber base. This
> On Wed, Jan 22, 2014 at 10:01 AM, Martin Thomson <[email-masked]>
> wrote:
>>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Jan 2014 18:03:01 +0100

Thanks! I have cleared.

Jari

On Jan 22, 2014, at 11:18 PM, Victor Kuarsingh <[email-masked]> wrote:

> I have made a number of changes that address his comments and have used much of his text.  ( I will be sending the Benoit and the rest of the IESG a full summary of changes and new version posting tonight).
>