From nobody Thu Dec 4 16:25:10 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E266D1A883E; Thu, 4 Dec 2014 16:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD3rDOOHn_Q2; Thu, 4 Dec 2014 16:24:59 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3561A8839; Thu, 4 Dec 2014 16:24:59 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id rd18so16841649iec.22 for ; Thu, 04 Dec 2014 16:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=9mmrgimc85eT/1bEeooqGGPDUd0R1OTcTFbSjL7GuhE=; b=rzgebS3N7q/z9uJM755JkP+Vgz3ukPFOyAY4Z+wswvDtgGgc2Ye8sYq9V1N4TsYS16 we2IDqg8G55w2/RZksQdTLG8nKZUtE5XUE8QnREDhcCd/UEm8V4+eMzLdZ3gmiuax13/ OgkAHcAgSPPgYXGxNO4G+hYTAVKHAOIl2Wb8htTxoigsxFI5AYvxzg6BLU4L9n7qjscR aUrGlTqDUYQoiiXMhDVW4VGoYg0zMSRag54NhbqC8RMXET6wx8ShHLX00B6voGswTQS8 kvA74Q4H+1VC5RUQZGW7YNqmJJdbzlRVbnb+SoS3+1Pa+JM3Apxa8KyqrRxKpn43/XNX zGjA== X-Received: by 10.50.3.67 with SMTP id a3mr50208iga.42.1417739098124; Thu, 04 Dec 2014 16:24:58 -0800 (PST) Received: from [192.168.0.101] ([216.254.164.46]) by mx.google.com with ESMTPSA id kv4sm33565igb.13.2014.12.04.16.24.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Dec 2014 16:24:57 -0800 (PST) Message-ID: <5480FB54.9040003@gmail.com> Date: Thu, 04 Dec 2014 19:24:52 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/FPIxsKllQc1Z8t_3CbaHoiKcJ3I Cc: Tina TSOU Subject: [BEHAVE] NAT MIB: Tying packet classification to address realms rather than subscribers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 00:25:01 -0000 I've been thinking through the implications of the NAT application scenarios presented in my E-mail of 21 November ("NAT MIB: compliance levels"). One of them is that the large-scale NAT application, even though it does not understand individual subscribers, must have a means to classify received packets into address realms. The conclusion is that the packet classification criteria represented by natSubscriberIdentifierType, natSubscriberVlanIdentifier, etc. in the -11 version of the NAT MIB draft should be pulled out of natSubscribersTable and put into a separate realm table. My instinct is to make this NAT instance specific, in that: -- different NAT instances on the same device may support different realms -- different NAT instances may use different criteria to distinguish the same realms, as a kind of load-sharing control Comments? Tom Taylor From nobody Fri Dec 5 17:34:08 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F031A87C8; Fri, 5 Dec 2014 17:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va-C7LWVydnZ; Fri, 5 Dec 2014 17:34:03 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490FD1A87CC; Fri, 5 Dec 2014 17:34:03 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so1802992ier.32 for ; Fri, 05 Dec 2014 17:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aeRK0/0QiYFCUZRakMo/VEaUFbgpIZtrkZ0xt1R0IZk=; b=ry9YKa6vYUwe03ntmh6FCt4m934ecG1Z32eHzb5wfYtbyy6RKDJggklApv0EEsp5pp ji7G6fCjSOluK7NYZFAnV4KnX3jlK3Qt4Q1/B6shChtACipEtWfMz7kxEAeg4K7MdhL6 KrS5HqqKp3bp9h4GUZJD9Nc3Y1X3RJ7DVgOKbMeo9hHKp76+PTfTGkUht8Q2kFKD+oAv QS6AQbxyJbLPh/RC+6xGUeBklu3GUMEASTU4oCTQjZtnpTcKb2Hrw7BLr1A2FwXpHJMF ptN4q87kqDQDYiniF2ZftZQy1a165YQXOfiC7ACB980/Q3Y1SAG3DRgvaH/mv0D6tO1a mEvw== X-Received: by 10.107.149.13 with SMTP id x13mr1378636iod.35.1417829642355; Fri, 05 Dec 2014 17:34:02 -0800 (PST) Received: from [192.168.0.101] ([216.254.164.46]) by mx.google.com with ESMTPSA id kv4sm73137igb.13.2014.12.05.17.34.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Dec 2014 17:34:01 -0800 (PST) Message-ID: <54825D0A.8060107@gmail.com> Date: Fri, 05 Dec 2014 20:34:02 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" References: <5480FB54.9040003@gmail.com> In-Reply-To: <5480FB54.9040003@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/behave/NKHyjbXogFts8HtJvem9JypCeyc Cc: Tina TSOU Subject: Re: [BEHAVE] NAT MIB: Tying packet classification to address realms rather than subscribers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 01:34:05 -0000 I've had second thoughts. The data used for packet classification by subscriber and realm is actually configuration data. "When in doubt, throw it out": this data didn't belong in the MIB in the first place unless someone sees it as particularly valuable for trouble-shooting. Tom Taylor On 04/12/2014 7:24 PM, Tom Taylor wrote: > I've been thinking through the implications of the NAT application > scenarios presented in my E-mail of 21 November ("NAT MIB: compliance > levels"). One of them is that the large-scale NAT application, even > though it does not understand individual subscribers, must have a means > to classify received packets into address realms. The conclusion is that > the packet classification criteria represented by > natSubscriberIdentifierType, natSubscriberVlanIdentifier, etc. in the > -11 version of the NAT MIB draft should be pulled out of > natSubscribersTable and put into a separate realm table. My instinct is > to make this NAT instance specific, in that: > -- different NAT instances on the same device may support different realms > -- different NAT instances may use different criteria to distinguish the > same realms, as a kind of load-sharing control > > Comments? > > Tom Taylor From nobody Sat Dec 6 11:46:38 2014 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8761A1B10 for ; Sat, 6 Dec 2014 11:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n38JPW7sIXx for ; Sat, 6 Dec 2014 11:46:35 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D398C1A1AE5 for ; Sat, 6 Dec 2014 11:46:34 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gm9so2227737lab.26 for ; Sat, 06 Dec 2014 11:46:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BV0OxckwteBh15CZigvuIWbLY/bOkq3WSpFP3Ij2t5E=; b=Pv4aQjHiUz6hyIx5nV/8EOTcSeauztyPvaEL+96gNkhJU/5+JbrnLF7RyfNahk8513 SsgxPXBi/GPVM0Zk3F8n3QcgIz+9jYjVfFlQpqFM6eF/YtCHuywRm/PfCjFXG4DFTccf v3FEJEoiOuflIQehqFyh4M910/WOU8ERQIFR9lCfLX7iBeR3jOkCs5mOQAsiqnN2iiRB w0og7xw2OfEOdFsjj9e9cvxj8rws7MDuqnQi5LQaDQCYQd9w/qw870L/ozSj9WXf7szO K+OGNH1kXhf1TBMG54V8j58X9vbk/7m7ShiLeq7UYpszBsOirWpqtZ+SYXRNx7OnvkVW cn9w== X-Gm-Message-State: ALoCoQlBwnXRNtkxljJSilp326RT/hySgCB1CyAma8psQLpyatogL3ovu5ShQ4UeR58iDaifRyRc MIME-Version: 1.0 X-Received: by 10.152.37.38 with SMTP id v6mr9068065laj.10.1417895193261; Sat, 06 Dec 2014 11:46:33 -0800 (PST) Received: by 10.25.84.145 with HTTP; Sat, 6 Dec 2014 11:46:33 -0800 (PST) Received: by 10.25.84.145 with HTTP; Sat, 6 Dec 2014 11:46:33 -0800 (PST) In-Reply-To: <54825D0A.8060107@gmail.com> References: <5480FB54.9040003@gmail.com> <54825D0A.8060107@gmail.com> Date: Sat, 6 Dec 2014 12:46:33 -0700 Message-ID: From: Simon Perreault To: Tom Taylor Content-Type: multipart/alternative; boundary=089e0160b5f252d1e4050991737c Archived-At: http://mailarchive.ietf.org/arch/msg/behave/FcVwQZo4hlihcN7Pl4Qamcp-yPU Cc: "behave@ietf.org" , opsawg@ietf.org, Tina TSOU Subject: Re: [BEHAVE] NAT MIB: Tying packet classification to address realms rather than subscribers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 19:46:36 -0000 --089e0160b5f252d1e4050991737c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable WFM. Simon Le 2014-12-05 20:34, "Tom Taylor" a =C3=A9crit = : > I've had second thoughts. The data used for packet classification by > subscriber and realm is actually configuration data. "When in doubt, thro= w > it out": this data didn't belong in the MIB in the first place unless > someone sees it as particularly valuable for trouble-shooting. > > Tom Taylor > > On 04/12/2014 7:24 PM, Tom Taylor wrote: > >> I've been thinking through the implications of the NAT application >> scenarios presented in my E-mail of 21 November ("NAT MIB: compliance >> levels"). One of them is that the large-scale NAT application, even >> though it does not understand individual subscribers, must have a means >> to classify received packets into address realms. The conclusion is that >> the packet classification criteria represented by >> natSubscriberIdentifierType, natSubscriberVlanIdentifier, etc. in the >> -11 version of the NAT MIB draft should be pulled out of >> natSubscribersTable and put into a separate realm table. My instinct is >> to make this NAT instance specific, in that: >> -- different NAT instances on the same device may support different real= ms >> -- different NAT instances may use different criteria to distinguish the >> same realms, as a kind of load-sharing control >> >> Comments? >> >> Tom Taylor >> > --089e0160b5f252d1e4050991737c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

WFM.

Simon

Le 2014-12-05 20:34, "Tom Taylor" <= tom.taylor.stds@gmail.com&= gt; a =C3=A9crit :

I= 've had second thoughts. The data used for packet classification by sub= scriber and realm is actually configuration data. "When in doubt, thro= w it out": this data didn't belong in the MIB in the first place u= nless someone sees it as particularly valuable for trouble-shooting.

Tom Taylor

On 04/12/2014 7:24 PM, Tom Taylor wrote:

I've been thinking through the implications of the NAT application
scenarios presented in my E-mail of 21 November ("NAT MIB: compliance<= br> levels"). One of them is that the large-scale NAT application, even though it does not understand individual subscribers, must have a means
to classify received packets into address realms. The conclusion is that the packet classification criteria represented by
natSubscriberIdentifierType, natSubscriberVlanIdentifier, etc. in the
-11 version of the NAT MIB draft should be pulled out of
natSubscribersTable and put into a separate realm table. My instinct is
to make this NAT instance specific, in that:
-- different NAT instances on the same device may support different realms<= br> -- different NAT instances may use different criteria to distinguish the same realms, as a kind of load-sharing control

Comments?

Tom Taylor

--089e0160b5f252d1e4050991737c--