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

Reply via email to