Re: Gen-ART review of draft-ietf-behave-lsn-requirements-07

Simon Perreault <simon.perreault@viagenie.ca> Tue, 10 July 2012 17:50 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E3C21F86F0 for <ietf@ietfa.amsl.com>; Tue, 10 Jul 2012 10:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level:
X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_GIRL=2.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDCmp6SndgWi for <ietf@ietfa.amsl.com>; Tue, 10 Jul 2012 10:50:15 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 675C921F86DE for <ietf@ietf.org>; Tue, 10 Jul 2012 10:50:15 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4D4CA415D9 for <ietf@ietf.org>; Tue, 10 Jul 2012 13:50:43 -0400 (EDT)
Message-ID: <4FFC6B72.2010401@viagenie.ca>
Date: Tue, 10 Jul 2012 13:50:42 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Gen-ART review of draft-ietf-behave-lsn-requirements-07
References: <4FF2E47C.80104@isode.com>
In-Reply-To: <4FF2E47C.80104@isode.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 17:50:16 -0000

On 07/03/2012 08:24 AM, Alexey Melnikov wrote:
> I found the justification for REQ-6 hard to read/understand. Why does
> access to
> servers being on the internal network need to go through CGN at all?

Here's the thing: the server is not on the internal network. It's on the 
external network, but it is still managed by the ISP. The ISP's network 
includes the internal network and some part of the external network. 
Furthermore, in many cases an ISP may run multiple CGNs, so the ISP's 
network is actually multiple internal networks and some part of the 
external network. The servers in the external network are operated by 
the ISP and "know" the internal networks (have routes to them), and can 
reach them directly without translation. And since connections from 
subscribers to those servers may account for a lot of traffic, it is 
important to not spend NAT resources on them.

Now, I'm not sure how to alter the existing text to make it easier to 
understand. It seems to me that all the information is there, just not 
with the same order/emphasis as what I wrote above. If the above was 
useful for you to understand, could you please point out in the text 
below what change would have helped you understand?

    REQ-6:  It MUST be possible to administratively turn off translation
            for specific destination addresses and/or ports.

    Justification:  It is common for a CGN administrator to provide
       access for subscribers to servers installed in the ISP's network,
       in the external realm.  When such a server is able to reach the
       internal realm via normal routing (which is entirely controlled by
       the ISP), translation is unneeded.  In that case, the CGN may
       forward packets without modification, thus acting like a plain
       router.  This may represent an important efficiency gain.

       Figure 2 illustrates this use-case.


                  X1:x1            X1':x1'            X2:x2
                  +---+from X1:x1  +---+from X1:x1    +---+
                  | C |  to X2:x2  |   |  to X2:x2    | S |
                  | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e |
                  | i |            | G |              | r |
                  | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v |
                  | n |from X2:x2  |   |from X2:x2    | e |
                  | t |  to X1:x1  |   |  to X1:x1    | r |
                  +---+            +---+              +---+

                         Figure 2: CGN pass-through

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca