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

[Victor Kuarsingh <[e-mail]>]

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 <[e-mail]>wrote:

> On 15 January 2014 19:40, Victor Kuarsingh <[e-mail]> wrote:
> >> 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.
> >
> >
> > [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.
>
> 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.
>
> >> 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.
> >
> >
> > [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.
>
> 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.
>
> >> 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?
> >
> >
> > [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).
>
> 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.
>