Subject: [OPSAWG] AD review: draft-ietf-opsawg-lsn-deployment-03

From: Benoit Claise <[email-masked]>
Date: Mon, 07 Oct 2013 13:57:08 +0200

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

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 18 Oct 2013 00:21:15 -0400

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.

Regards,

Victor K

From:  Benoit Claise <[email-masked]>
Date:  Mon, 07 Oct 2013 13:57:08 +0200
To:  <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  AD review: draft-ietf-opsawg-lsn-deployment-03
Resent-To:  <[email-masked]>, Victor Kuarsingh
<[email-masked]>

 Dear authors,

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.

 Btw, RFC6888 lists:
>  
> 3 <http://tools.ietf.org/html/rfc6888#section-3> .  Requirements for CGNs
>    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> ].
>  

 Editorial:
 
 Abstract
 OLD:
 
   This

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:

NEW:
 
 Section 2. Motivation
 
 OLD:

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:

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

NEW:
   CGN

OLD:

NEW:

 - A couple of acronyms

 Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Oct 2013 12:27:56 +0200

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 
> 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-masked] <mailto:[email-masked]>>
> To: <[email-masked] 
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> Resent-To: <[email-masked] 
> <mailto:[email-masked]>>, Victor Kuarsingh 
> <[email-masked] <mailto:[email-masked]>>
>
> Dear authors,
>
> 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
>     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

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 18 Oct 2013 08:42:34 -0400

Benoit,

Ok, I see your point of confusion.  If 3.8 was called, "Base CGN
Requirements", and the text was modified a bit to not that other
architectural requirements are actually covered in RFC6888, would this help
remove the confusion and bring some clarity?

Regards,

Victor K

From:  Benoit Claise <[email-masked]>
Date:  Fri, 18 Oct 2013 12:27:56 +0200
To:  Victor Kuarsingh <[email-masked]>
Cc:  <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: AD review: draft-ietf-opsawg-lsn-deployment-03

Hi Victor,
 
 See in-line.

> 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.
>  
> 
>  
>  
> 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
> 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.
>  
> 
>  
>  
> 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.
>  

   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
 
 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
 
>    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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Oct 2013 14:46:56 +0200

Victor,
> architectural requirements are actually covered in RFC6888, would this 
> help remove the confusion and bring some clarity?
Yes, thanks.

Regards, Benoit
> To: Victor Kuarsingh <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] 
> <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
>> architecture (based on experience gained in actually going through 
>> the process).  There are different then those listed in RFC6888 which 
>> and port allocation (I.e. REQ-14 in RFC6888), we thought references 
>> to that RFC were appropriate.
>>
>> 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.
>
>>         3 <http://tools.ietf.org/html/rfc6888#section-3>.
>>         Requirements for CGNs
>>