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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 17 July 2012 10:07 UTC

Return-Path: <alexey.melnikov@isode.com>
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 D4CD221F86CF for <ietf@ietfa.amsl.com>; Tue, 17 Jul 2012 03:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.86
X-Spam-Level:
X-Spam-Status: No, score=-101.86 tagged_above=-999 required=5 tests=[AWL=-1.561, BAYES_00=-2.599, MANGLED_GIRL=2.3, USER_IN_WHITELIST=-100]
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 fW7pEI6RgHSI for <ietf@ietfa.amsl.com>; Tue, 17 Jul 2012 03:07:48 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id CF9C621F86CE for <ietf@ietf.org>; Tue, 17 Jul 2012 03:07:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1342519714; d=isode.com; s=selector; i=@isode.com; bh=EksTNsMrBI9JsDmRo80XUJMmtiJKntybaesAIH8yfyI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=b9KT41O5Eq6gemQPHnlXHoku7cB8Rp5Nvr8X+r6QWNJIFq7THwZylxG5bkCcH7BAn5F88f wT048pWJS7H1FKmKtxHGUFxSZd8Bh1RA2vmFttMBihXcvkfoZivwlJjukNyOvS0YIu8jmw HZlfWXVL9B9uL0pQT8ty48OUHXaEtAg=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <UAU5oQAdigx3@statler.isode.com>; Tue, 17 Jul 2012 11:08:34 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <500539A1.9060200@isode.com>
Date: Tue, 17 Jul 2012 11:08:33 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Simon Perreault <simon.perreault@viagenie.ca>
Subject: Re: Gen-ART review of draft-ietf-behave-lsn-requirements-07
References: <4FF2E47C.80104@isode.com> <4FFC6B72.2010401@viagenie.ca>
In-Reply-To: <4FFC6B72.2010401@viagenie.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
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, 17 Jul 2012 10:07:49 -0000

Hi Simon,

On 10/07/2012 18:50, Simon Perreault wrote:
> 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.
I like this longer explanation. I agree that once I understand what you 
are trying to say the shorter explanation in the document makes sense. 
But it is a bit cryptic. (I don't have specific suggestions, so if you 
can't improve existing text, that is Ok with me.)
> 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