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

[Benoit Claise <[e-mail]>]

Dear authors, doc. shepherd,

Can you please answer Martin.

Regards, Benoit
> 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.
> .
>