Hi Victor,
See in-line.
Benoit,
Thanks for the thorough review. I will split my response into three
sections to address the various ares you commented on.
(1). As for section 3 (network deployment requirements list and
subsequent explanation), I will add text which clarifies this list
expanded and described in the following sub-sections [new text on
updated I-D]
(2). Editorial comments at the tail end of the email [will review and
make the updates to text]
(3). As for you comments on RFC6888, the ones specified in this
document are incremental to those.
The "requirements" as stated here are ones related a deployment
architecture (based on experience gained in actually going through the
process). There are different then those listed in RFC6888 which
concentrate on the NAT function itself.
Here (in document) we concentrate on architectural/deployment
requirements for deploying a system using NAT44. So by extension, no
direct reference was made to RFC4787, RFC5328 or RFC5508 since these
are more appropriate for someone building a CGN function.
The reason for the references in section 3.7 and 3.8 are related to
the fact that there is overlap between the architectural requirements
and the the functional (NAT44/CGN function) requirement of the CGN
box/device itself. This was in regard to (1) NAT logging which is
both a requirement as stated in RFC6888 for the implemented of CGN
box/device, but also a architectural requirement for an operator
needed to facilitate the needs of the business. In section 3.8 there
is mention of support for bulk port allocation. This again is a
architectural requirement (to deal with practical scaling issues in
real CGN deployments and ability to successful log) and as stated in
RFC6888 a CGN device level requirement.
Since there was existing text in RFC6888 which deal with NAT logging
and port allocation (I.e. REQ-14 in RFC6888), we thought references to
that RFC were appropriate.
So, I will make updates on point 1 and 2 above. As for point 3, if
you are satisfied with this explanation, then I can let it be. If you
think you want to see text that specifically describes what I have put
in my point 3 above, then I can do that as well.
From your draft, the paragraphs referring to RFC 6888 are:
To face this challenge, operators may need to deploy CGN (Carrier
Grade NAT) as described in [RFC6888 <http://tools.ietf.org/html/rfc6888>]
to help extend the connectivity
matrix once IPv4 addresses caches run out on the local local
operator.
...
Operators may need to keep track of this information (securely) to
meet regulatory and/or legal obligations._Further information_ can be
found in [RFC6888 <http://tools.ietf.org/html/rfc6888>] with respect to CGN
logging requirements (Logging
Section).
...
3.8. _Additional _CGN Requirements
The CGN platform will also need to meet the needs of additional
requirements such as Bulk Port Allocation and other CGN device
specific functions._These additional requirements_ are captured
within [RFC6888 <http://tools.ietf.org/html/rfc6888>].
The last paragraph ("additional" in the title and "these additional
requirements") is my source of confusion I guess, and led to the
question in my review
So the requirements in this document are
1. on top of the RFC6888
2. a subset of those that are important for
draft-ietf-opsawg-lsn-deployment
3. a complete different set
You must already be compliant with RFC 6888. As you wrote: "As for you
comments on RFC6888, the ones specified in this document are
_incremental _to those"
And now you have some additional CGN requirements ... but those
requirements are already captured into RFC 6888 ... to which you're
already complaint. So what are those additional to?
Regards, Benoit
Regards,
Victor K
From: Benoit Claise <[email protected] <mailto:[email protected]>>
Date: Mon, 07 Oct 2013 13:57:08 +0200
To: <[email protected]
<mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
Subject: AD review: draft-ietf-opsawg-lsn-deployment-03
Resent-To: <[email protected]
<mailto:[email protected]>>, Victor Kuarsingh
<[email protected] <mailto:[email protected]>>
Dear authors,
- Section 3. CGN Network Deployment Requirements
If a service provider is considering a CGN deployment with a provider
NAT44 function, there are a number of basic architectural
requirements which are of importance. Preliminary architectural
requirements may require all or some of the following from the
incoming CGN system:
Then there is a long list of points.
I spent some time on each point, making sure I understood it.
Then, reading further, I realized that each point is expanded in the sub
section.
This should be explained up front.
- I see Section 3 CGN Network Deployment Requirements
What is the link with the requirements in rfc6888?
Yes, there are a few references, for example in section 3.7 and 3.8
for specific requirements, but what about the other requirements. So
the requirements in this document are
1. on top of the RFC6888
2. a subset of those that are important for
draft-ietf-opsawg-lsn-deployment
3. a complete different set
Btw, RFC6888 lists:
3 <http://tools.ietf.org/html/rfc6888#section-3>. Requirements
for CGNs
What follows is a list of requirements for CGNs. They are in
addition to those found in other documents such as [RFC4787
<http://tools.ietf.org/html/rfc4787>],
[RFC5382 <http://tools.ietf.org/html/rfc5382>], and [RFC5508
<http://tools.ietf.org/html/rfc5508>].
Again, same question for these extra RFCs.
_
Editorial:_
Abstract
OLD:
This
document provides a practical integration model which allows the CGN
platform to be integrated into the network meeting the connectivity
needs of the subscriber while being mindful of not disrupting
existing services and meeting the technical challenges that CGN
brings.
NEW:
This
document provides a practical integration model which allows the CGN
platform to be integrated into the_network,_ meeting the connectivity
needs of the subscriber while being mindful of not disrupting
existing services and meeting the technical challenges that CGN
brings.
Section 1. Introduction
OLD:
To face this challenge, operators may need to deploy CGN (Carrier
Grade NAT) as described in [RFC6888] to help extend the connectivity
matrix once IPv4 addresses caches run out on the local local
operator.
NEW:
To face this challenge, operators may need to deploy CGN (Carrier
Grade NAT) as described in [RFC6888] to help extend the connectivity
matrix once IPv4 addresses caches run out on the local
operator.
Section 2. Motivation
OLD:
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.
NEW:
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.
Section 2. Motivation
OLD:
This will include solving a number of challenges
since subscribers who's connections require translation will have
network routing and flow needs which are different from legacy IPv4
connections.
NEW:
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.
Section 3.3 CGN By-Pass
OLD:
CGN
By-pass can be accomplished in many ways, but a simplistic,
deterministic and scalable model is preferred.
NEW:
CGN
by-pass can be accomplished in many ways, but a simplistic,
deterministic and scalable model is preferred.
Section 3.5. Flexible Deployment Options
OLD:
Depending on hardware capabilities, security practices and IPv4
address availability, the translation environments my need to be
segmented and/or scaled over time to meet organic IPv4 demand growth.
NEW:
Depending on hardware capabilities, security practices and IPv4
address availability, the translation environments may need to be
segmented and/or scaled over time to meet organic IPv4 demand growth.
- Section 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN
Attachment Options
Something weird with the section format, at least in the html version
- A couple of acronyms
- Flexibility should include integration options for common access
technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/
ASN-GW), and direct Ethernet;
- expand large-scale NAT (LSN)
Regards, Benoit
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
