Skip to main content

Last Call Review of draft-ietf-opsawg-lsn-deployment-04
review-ietf-opsawg-lsn-deployment-04-opsdir-lc-abley-2014-01-23-00

Request Review of draft-ietf-opsawg-lsn-deployment
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-01-21
Requested 2013-12-30
Authors Victor Kuarsingh , John Cianfarani
I-D last updated 2014-01-23
Completed reviews Genart Last Call review of -04 by Martin Thomson (diff)
Opsdir Last Call review of -04 by Joe Abley (diff)
Assignment Reviewer Joe Abley
State Completed
Request Last Call review on draft-ietf-opsawg-lsn-deployment by Ops Directorate Assigned
Reviewed revision 04 (document currently at 06)
Result Has nits
Completed 2014-01-23
review-ietf-opsawg-lsn-deployment-04-opsdir-lc-abley-2014-01-23-00
All,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the operational area
directors. Document editors and WG chairs should treat these comments just like
any other last call comments.

My apologies for the ludicrous lateness of this review (which I gather is on
the IESG telechat agenda today).

I'll also note up front that following various converging employment changes
since this document's birth, I am now a colleague of Victor Kurasingh (the
top-listed editor of this document) at Dyn. I don't have any special reason to
go easy on the document because of our day-job proximity, but full disclosure,
etc.

Executive Summary

Ready with nits.

Editorial

A few sections of the document contain textual problems that seem worth calling
out in this review, since it might not be as obvious to staff at the RFC Editor
what suitable corrections should be as it is to a technical reviewer. I have
hence included some, despite the fact that they would not normally belong in an
Ops area review.

Section 1.1, "Internal Realm" -- replace "been" with "between"

Section 3, near end of first para -- replace "add additive" with "are additive"
(or "add")

Section 3.2, mid first para -- replace "be best served" with "be best served by"

Section 3.2, suggest modifying the final paragraph to make it sound a little
less hysterical, e.g. "are under considerable pressure to deliver greater
access bandwidth, and any inefficiencies in forwarding due to the use of CGN
must be minimised".

Section 4.4.1, second para, replace "others options" with "other options".

Terminology

The document assumes in various places that address pools which are not
globally unique will, however, be naturally unique within an operator's
network. See for example section 3.3. To be more general, the document might
define a term for the domain within which subscriber addresses are unique and
mention that an operator's network might contain more than one such domain.
This is illustrated explicitly in section 3.6, which as written seems at odds
with this assumption.

The acronym "GRT" is used in various diagrams apparently as a short-hand for a
domain within the network in which reachability (and hence address assignment)
is globally-unique. This might be spelt out, since otherwise the idea of
forwarding a packet into a routing table is a bit mentally jarring (a bit like
directions which send a car into a driver's licence).

Operations (see RFC 5706 section 2.1)

The document is motivated by a need to deploy CGN in a way that is
operationally simple and flexible, and does a good job at outlining the corner
cases that need to be considered before an operator chooses an approach. The
proposed approach seems more sane than the alternatives that are summarised in
the document.

Installation and Initial Setup (see RFC 5706 section 2.2), and
Migration Path (see RFC 5706 section 2.3)

It is impractical to imagine that this document (or one like it) could make
detailed recommendations for implementation that would be relevant generally to
all networks. Sensibly, the document does not attempt to do so.

Requirements on Other Protocols and Functional Components (see RFC 5706 section
2.4), and Impact on Network Operation (see RFC 5706 section 2.5), and Verifying
Correct Operation (see RFC 5706 section 2.6), and Interoperability (see RFC
5706 section 3.1), and Management Information (see RFC 5706 section 3.2), and
Fault Management (see RFC 5706 section 3.3), and Configuration Management (see
RFC 5706 section 3.4), and Accounting Management (see RFC 5706 section 3.5),
and Performance Management (see RFC 5706 section 3.6), and Security Management
(see RFC 5706 section 3.7)

The document's proposal makes conventional use of existing techniques and
protocols, and does not introduce any new requirements on them. Similarly,
there is no obvious impact on network operations beyond those already required
for the operation of CGNs and MPLS networks.

Documentation Guidelines (see RFC 5706 section 4)

The document doesn't follow the guidelines outlined in RFC 5706. Doing so would
have made this review a little easier, but I don't think would have
significantly helped the clarity or usefulness of the text, given the context
of the discussion which is clearly the presentation of an architectural
approach rather than the design of a protocol or guidance for implementation.

Joe

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail