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

[Victor Kuarsingh <[e-mail]>]

Benoit/Martin,

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

regards,

Victor K


On Tue, Jan 14, 2014 at 12:10 PM, Benoit Claise <[e-mail]> wrote:

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