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
