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

[Victor Kuarsingh <[e-mail]>]

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 <[e-mail]>
Date:  Fri, 18 Oct 2013 12:27:56 +0200
To:  Victor Kuarsingh <[e-mail]>
Cc:  <[e-mail]>, "[e-mail]"
<[e-mail]>
Subject:  Re: AD review: draft-ietf-opsawg-lsn-deployment-03

    
 
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 <[e-mail]>
>  Date:  Mon, 07 Oct 2013 13:57:08 +0200
>  To:  <[e-mail]>
>  Cc:  "[e-mail]" <[e-mail]>
>  Subject:  AD review: draft-ietf-opsawg-lsn-deployment-03
>  Resent-To:  <[e-mail]>, Victor Kuarsingh
> <[e-mail]>
>  
>  
> 
>  
>  
>  
>  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
>  
>  
>  
>  
>