From william.allen.simpson@gmail.com Wed Jun 1 06:19:41 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A428E06F0 for ; Wed, 1 Jun 2011 06:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzO8yuwqtg6W for ; Wed, 1 Jun 2011 06:19:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8706BE067F for ; Wed, 1 Jun 2011 06:19:40 -0700 (PDT) Received: by yxk30 with SMTP id 30so2990701yxk.31 for ; Wed, 01 Jun 2011 06:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=opUbcn7RDF6cqrWslIwc/ocMrgXqjv4WLwWitSUoAzo=; b=bX4AATH20Qyui2Xla1HzzXGLki8wfFK3A9+JAfGPeUTe4mMzCC5C5Z2TwYMTusZwci t2pUiPRoRTQbNlS2O96jM163S8XcTtGKvsHAFsV2JbTBlOR4JuNRTAoGptbdfCjfGMUd XU6SnnHViZ80rTZ4k+oimbpo7mR/8ulEXXR2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Pt11w8VON5scm3kgSpNTnHojozpzU+2bLsQBbdHAjGxrIlUPql+V9PunG0qajC/Syq WCFW2RyclvQD525NNWgRM/82Q8dZjjLHc/FQPRv0Z3yvw4i0ANvLhdn3TkdCJDReffZo BnzsNK98DFyLw7sj9umHzb7tLK23JsHYf/1Ak= Received: by 10.150.69.5 with SMTP id r5mr6533362yba.63.1306934379952; Wed, 01 Jun 2011 06:19:39 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id u64sm1077702yhm.83.2011.06.01.06.19.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 06:19:38 -0700 (PDT) Message-ID: <4DE63C68.9070102@gmail.com> Date: Wed, 01 Jun 2011 09:19:36 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: PPP Extensions References: <4DE51FC3.2070301@workingcode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org, Stewart Bryant Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:19:41 -0000 Obviously, Stewart is wrong. We've gone to great lengths to ensure PPP is zero configuration. We never need to buy and burn IEEE MAC identifiers. TRILL seems to have zero configuration design goals, too. Therefore, James is also wrong. This is not an operator issue. You should *NOT* put this burden on operators. It would really help for anybody with aspirations of designing protocols to have actually been an operator, and pay attention to discussions on the NANOG list! As a personal example, just last summer I spent *many* hours trying to figure our what was happening as a political campaign couldn't get their wireless access point to work. It was very flaky. At long last, traces discovered that the AP had a conflicting MAC with another device at another office somewhere else in the Comcast region. You cannot expect political operatives (and quite frankly any other business) to fix this. Therefore, this is a protocol design issue. I've been trying to live with the various compromises on language, but this goes too far! Technically, that MUST is certainly wrong. There's no guarantee of uniqueness, and uniqueness is required by both ISIS and TRILL. Moreover, there's no guarantee that a hot swappable or card or board based device will not become (even temporarily) a PPP-only device. To meet that MUST, every vendor of PPP devices will have to burn an IEEE number for every device. Yet, it still might not work! That's simply wrong! There's a lot of nonsense in IETF protocols, but we don't have to add more here and now. On 5/31/11 2:20 PM, Donald Eastlake wrote: > James, > > I'm fine with your suggested tweak of Stewart Bryant's wording. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3@gmail.com > > > On Tue, May 31, 2011 at 1:05 PM, James Carlson wrote: >> As part of IETF review, the Routing ADs are looking over >> draft-ietf-pppext-trill-protocol-06. Not too surprising to me -- given >> that I still think it's far out of scope -- the text concerning IS-IS >> System IDs is causing trouble in that review. See this thread: >> >> http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533 >> >> I wish I could leave the worms safely in the can, but it's looking like >> that might not be one of the options. >> >> Instead of the reference to Bill Simpson's draft, Stewart Bryant >> suggested replacement text like this: >> >> ISO/IEC 10589 states that it is the responsibility of the routeing >> domain administrative authority to enforce the uniqueness of the >> system ID. In cases where a zero configuration system is >> supplied the system manufacturer MUST install a suitable >> unique identifier at manufacturing time. One way to achieve >> this is for the manufacturer to use a unique IEEE MAC address >> following the allocation procedures normally used in the >> manufacture of an Ethernet interface. >> >> This tosses the issue back into the implementor's lap (which, >> incidentally, is exactly where I think the problem belongs), and >> suggests an existing and known solution where a MAC identifier may be >> allocated for the system itself and used as a global ID to construct the >> necessary IS-IS System ID. >> >> For use in this draft, I would alter the wording slightly to indicate >> that zero-configuration is strongly preferred for TRILL (as guidance), >> and that obtaining a suitable identifier is the implementor's >> responsibility, rather than just saying "in cases where." >> >> Would this change fly without breaking consensus? Or do we have to >> start over? >> >> -- >> James Carlson 42.703N 71.076W >> _______________________________________________ >> Pppext mailing list >> Pppext@ietf.org >> https://www.ietf.org/mailman/listinfo/pppext >> > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext > From stbryant@cisco.com Wed Jun 1 06:56:00 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB814E081E; Wed, 1 Jun 2011 06:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.597 X-Spam-Level: X-Spam-Status: No, score=-110.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ot8GWbHTxZ-T; Wed, 1 Jun 2011 06:56:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 93F82E07FD; Wed, 1 Jun 2011 06:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4747; q=dns/txt; s=iport; t=1306936559; x=1308146159; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5fwXi4p62MvimaRssw51m3t0zcJNnnCQuTwtu6zXz3k=; b=OUV1JICCXuCUVyDD/pXoxeADVeCp/Ga1khPb4rwNk6Q2PyeeGqVQFGua ovmYgZg26/b8fETnHeXzaZ34bC2zFDAHnG6GUfFc7mWEKUrtxo6mW0SIe eiqflkcTGuPZT4muJn0wD6hliXIF1mr7mU1hBEM1zL7hZlIU7guL/VouR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK5D5k2Q/khR/2dsb2JhbABNBqYkd6o0gnoPAZpGgzGCbwSQVYhvhj0 X-IronPort-AV: E=Sophos;i="4.65,303,1304294400"; d="scan'208";a="91780244" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 01 Jun 2011 13:55:58 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p51DtwZZ013513; Wed, 1 Jun 2011 13:55:58 GMT Received: from dhcp-gpk02-vlan300-64-103-65-100.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p51DtuW26726; Wed, 1 Jun 2011 14:55:56 +0100 (BST) Message-ID: <4DE644F8.5060800@cisco.com> Date: Wed, 01 Jun 2011 14:56:08 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: William Allen Simpson References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> In-Reply-To: <4DE63C68.9070102@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PPP Extensions , rbridge@postel.org Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:56:01 -0000 Bill The discussion of suitable methods of ISIS and hence TRILL SystemID uniqueness needs to take place on the ISIS list (copied) regardless of the data link technology under consideration. James I am fine with your proposed text. Stewart On 01/06/2011 14:19, William Allen Simpson wrote: > Obviously, Stewart is wrong. We've gone to great lengths to ensure > PPP is > zero configuration. We never need to buy and burn IEEE MAC identifiers. > > TRILL seems to have zero configuration design goals, too. > > Therefore, James is also wrong. This is not an operator issue. You > should *NOT* put this burden on operators. It would really help for > anybody with aspirations of designing protocols to have actually been an > operator, and pay attention to discussions on the NANOG list! > > As a personal example, just last summer I spent *many* hours trying to > figure our what was happening as a political campaign couldn't get their > wireless access point to work. It was very flaky. At long last, traces > discovered that the AP had a conflicting MAC with another device at > another office somewhere else in the Comcast region. You cannot expect > political operatives (and quite frankly any other business) to fix this. > > Therefore, this is a protocol design issue. I've been trying to live > with > the various compromises on language, but this goes too far! > > Technically, that MUST is certainly wrong. There's no guarantee of > uniqueness, and uniqueness is required by both ISIS and TRILL. > > Moreover, there's no guarantee that a hot swappable or card or board > based > device will not become (even temporarily) a PPP-only device. To meet > that > MUST, every vendor of PPP devices will have to burn an IEEE number for > every device. Yet, it still might not work! > > That's simply wrong! There's a lot of nonsense in IETF protocols, but we > don't have to add more here and now. > > > On 5/31/11 2:20 PM, Donald Eastlake wrote: >> James, >> >> I'm fine with your suggested tweak of Stewart Bryant's wording. >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street >> Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> >> On Tue, May 31, 2011 at 1:05 PM, James >> Carlson wrote: >>> As part of IETF review, the Routing ADs are looking over >>> draft-ietf-pppext-trill-protocol-06. Not too surprising to me -- given >>> that I still think it's far out of scope -- the text concerning IS-IS >>> System IDs is causing trouble in that review. See this thread: >>> >>> http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533 >>> >>> I wish I could leave the worms safely in the can, but it's looking like >>> that might not be one of the options. >>> >>> Instead of the reference to Bill Simpson's draft, Stewart Bryant >>> suggested replacement text like this: >>> >>> ISO/IEC 10589 states that it is the responsibility of the routeing >>> domain administrative authority to enforce the uniqueness of the >>> system ID. In cases where a zero configuration system is >>> supplied the system manufacturer MUST install a suitable >>> unique identifier at manufacturing time. One way to achieve >>> this is for the manufacturer to use a unique IEEE MAC address >>> following the allocation procedures normally used in the >>> manufacture of an Ethernet interface. >>> >>> This tosses the issue back into the implementor's lap (which, >>> incidentally, is exactly where I think the problem belongs), and >>> suggests an existing and known solution where a MAC identifier may be >>> allocated for the system itself and used as a global ID to construct >>> the >>> necessary IS-IS System ID. >>> >>> For use in this draft, I would alter the wording slightly to indicate >>> that zero-configuration is strongly preferred for TRILL (as guidance), >>> and that obtaining a suitable identifier is the implementor's >>> responsibility, rather than just saying "in cases where." >>> >>> Would this change fly without breaking consensus? Or do we have to >>> start over? >>> >>> -- >>> James Carlson 42.703N 71.076W >>> _______________________________________________ >>> Pppext mailing list >>> Pppext@ietf.org >>> https://www.ietf.org/mailman/listinfo/pppext >>> >> _______________________________________________ >> Pppext mailing list >> Pppext@ietf.org >> https://www.ietf.org/mailman/listinfo/pppext >> > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Wed Jun 1 07:19:02 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC62E0879; Wed, 1 Jun 2011 07:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.547 X-Spam-Level: X-Spam-Status: No, score=-110.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4ZedYr-8LWJ; Wed, 1 Jun 2011 07:19:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 356E6E079C; Wed, 1 Jun 2011 07:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4805; q=dns/txt; s=iport; t=1306937941; x=1308147541; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Co9YfJE6SHvfv2IahpOZTA5pG6aTpak6tlNsEibUExE=; b=J0bTUYmfqmtZXYBDh3yNYmeds2Z3L2yIaGs+oPizKQOIrZI/gNRv2Va5 +O/xV7Z+n79G1tjNwxtSFTmOfDbKX/iRwyAsSeuA8TQdplL7oQwlnkmpq eBHfYHqKqXN5SDscWxi5t4eBzjOtq9MptKQXdfNWVNk/gpNx9qijpRSci 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ9J5k2Q/khL/2dsb2JhbABNBqYkd6ohgnoPAZpJgzGCbwSQVYhvhj0 X-IronPort-AV: E=Sophos;i="4.65,303,1304294400"; d="scan'208";a="33271961" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Jun 2011 14:19:00 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p51EIx6s026578; Wed, 1 Jun 2011 14:19:00 GMT Received: from dhcp-gpk02-vlan300-64-103-65-100.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p51EIwW28615; Wed, 1 Jun 2011 15:18:58 +0100 (BST) Message-ID: <4DE64A5E.1090900@cisco.com> Date: Wed, 01 Jun 2011 15:19:10 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: William Allen Simpson References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> In-Reply-To: <4DE63C68.9070102@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PPP Extensions , isis-wg , rbridge@postel.org Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:19:02 -0000 Bill The discussion of suitable methods of ISIS and hence TRILL SystemID uniqueness needs to take place on the ISIS list (copied) regardless of the data link technology under consideration. James I am fine with your proposed text. Stewart Sending again with the ISIS WG in the cc list not the BCC list. On 01/06/2011 14:19, William Allen Simpson wrote: > Obviously, Stewart is wrong. We've gone to great lengths to ensure > PPP is > zero configuration. We never need to buy and burn IEEE MAC identifiers. > > TRILL seems to have zero configuration design goals, too. > > Therefore, James is also wrong. This is not an operator issue. You > should *NOT* put this burden on operators. It would really help for > anybody with aspirations of designing protocols to have actually been an > operator, and pay attention to discussions on the NANOG list! > > As a personal example, just last summer I spent *many* hours trying to > figure our what was happening as a political campaign couldn't get their > wireless access point to work. It was very flaky. At long last, traces > discovered that the AP had a conflicting MAC with another device at > another office somewhere else in the Comcast region. You cannot expect > political operatives (and quite frankly any other business) to fix this. > > Therefore, this is a protocol design issue. I've been trying to live > with > the various compromises on language, but this goes too far! > > Technically, that MUST is certainly wrong. There's no guarantee of > uniqueness, and uniqueness is required by both ISIS and TRILL. > > Moreover, there's no guarantee that a hot swappable or card or board > based > device will not become (even temporarily) a PPP-only device. To meet > that > MUST, every vendor of PPP devices will have to burn an IEEE number for > every device. Yet, it still might not work! > > That's simply wrong! There's a lot of nonsense in IETF protocols, but we > don't have to add more here and now. > > > On 5/31/11 2:20 PM, Donald Eastlake wrote: >> James, >> >> I'm fine with your suggested tweak of Stewart Bryant's wording. >> >> Thanks, >> Donald >> ============================= >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street >> Milford, MA 01757 USA >> d3e3e3@gmail.com >> >> >> On Tue, May 31, 2011 at 1:05 PM, James >> Carlson wrote: >>> As part of IETF review, the Routing ADs are looking over >>> draft-ietf-pppext-trill-protocol-06. Not too surprising to me -- given >>> that I still think it's far out of scope -- the text concerning IS-IS >>> System IDs is causing trouble in that review. See this thread: >>> >>> http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533 >>> >>> I wish I could leave the worms safely in the can, but it's looking like >>> that might not be one of the options. >>> >>> Instead of the reference to Bill Simpson's draft, Stewart Bryant >>> suggested replacement text like this: >>> >>> ISO/IEC 10589 states that it is the responsibility of the routeing >>> domain administrative authority to enforce the uniqueness of the >>> system ID. In cases where a zero configuration system is >>> supplied the system manufacturer MUST install a suitable >>> unique identifier at manufacturing time. One way to achieve >>> this is for the manufacturer to use a unique IEEE MAC address >>> following the allocation procedures normally used in the >>> manufacture of an Ethernet interface. >>> >>> This tosses the issue back into the implementor's lap (which, >>> incidentally, is exactly where I think the problem belongs), and >>> suggests an existing and known solution where a MAC identifier may be >>> allocated for the system itself and used as a global ID to construct >>> the >>> necessary IS-IS System ID. >>> >>> For use in this draft, I would alter the wording slightly to indicate >>> that zero-configuration is strongly preferred for TRILL (as guidance), >>> and that obtaining a suitable identifier is the implementor's >>> responsibility, rather than just saying "in cases where." >>> >>> Would this change fly without breaking consensus? Or do we have to >>> start over? >>> >>> -- >>> James Carlson 42.703N 71.076W >>> _______________________________________________ >>> Pppext mailing list >>> Pppext@ietf.org >>> https://www.ietf.org/mailman/listinfo/pppext >>> >> _______________________________________________ >> Pppext mailing list >> Pppext@ietf.org >> https://www.ietf.org/mailman/listinfo/pppext >> > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From carlsonj@workingcode.com Wed Jun 1 07:54:11 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC29E07D1 for ; Wed, 1 Jun 2011 07:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWjasFyqbO3A for ; Wed, 1 Jun 2011 07:54:11 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 88535E07DC for ; Wed, 1 Jun 2011 07:54:10 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p51Es3bv008414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 10:54:04 -0400 (EDT) Message-ID: <4DE6528B.7070501@workingcode.com> Date: Wed, 01 Jun 2011 10:54:03 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: William Allen Simpson References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> In-Reply-To: <4DE63C68.9070102@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist Cc: PPP Extensions , rbridge@postel.org, Stewart Bryant Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:54:11 -0000 William Allen Simpson wrote: > Therefore, James is also wrong. This is not an operator issue. You > should *NOT* put this burden on operators. It would really help for > anybody with aspirations of designing protocols to have actually been an > operator, and pay attention to discussions on the NANOG list! It's worth noting that I said "implementor" not "operator." Perhaps the language I'm using isn't clear. By "implementor," I mean the person who designs the hardware and software components that will be sold as a product claiming to support TRILL. I do not mean the person who buys these products and installs them in a network. Like you, I do not believe that it's appropriate or reasonable for general-purpose TRILL implementations to require any sort of action on the part of the person installing and using the equipment -- that is, the "operator." I've never suggested that as a solution, so the straw man doesn't work here. Nor do the ad-hominem jibes. However, unlike you, I do not believe that the IETF must resolve this potential system-level design issue. Instead, I still strongly prefer to leave it up to the people designing and building systems. If they can't resolve this relatively simple problem in a reasonable way then, frankly, I have no faith that they can get any of the other million or so complex system design decisions right. Most importantly, I don't want to be dictating anything about IS-IS design issues from within the PPP Extensions working group. It's just not appropriate or even feasible. That's why I agree with the ideas behind Stewart Bryant's text. All that said, I don't really care. This is a tempest in a teapot. I can mash together both texts if the Routing ADs are willing to accept a passing reference here to a draft that, in their words, hasn't even been considered by the IS-IS community. -- James Carlson 42.703N 71.076W From stbryant@cisco.com Wed Jun 1 08:24:45 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7482AE08CF for ; Wed, 1 Jun 2011 08:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.502 X-Spam-Level: X-Spam-Status: No, score=-110.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdFdvrHigB4C for ; Wed, 1 Jun 2011 08:24:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E405DE08CA for ; Wed, 1 Jun 2011 08:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=383; q=dns/txt; s=iport; t=1306941884; x=1308151484; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xytnnkGnxA8i2wDA1j2ZpVlRVRf5qlaBQYHpkbv3TIU=; b=Lq0yZQOuT4IfrY/3S2NSbY4fg9unE1yH7wg2ECwKbOKaM8KEvRQAbDjT oayiR4aYah005qPUFqoqC7ZaOb7efG4aO0UoiwU5D650lV0s5klgyiAOq sbldbHXTF+0OS+nfcZn0/CynGTlfLmdnKSg1/X1QGVR2kkXmh6bKjouI/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMRY5k2Q/khR/2dsb2JhbABTpiR3iHGgYoJ6DwGaSYYgBJBVjyw X-IronPort-AV: E=Sophos;i="4.65,303,1304294400"; d="scan'208";a="91797476" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 01 Jun 2011 15:24:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p51FOcNV004153; Wed, 1 Jun 2011 15:24:38 GMT Received: from dhcp-gpk02-vlan300-64-103-65-100.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p51FObW03819; Wed, 1 Jun 2011 16:24:37 +0100 (BST) Message-ID: <4DE659C1.2050306@cisco.com> Date: Wed, 01 Jun 2011 16:24:49 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: James Carlson References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> In-Reply-To: <4DE6528B.7070501@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PPP Extensions , rbridge@postel.org, William Allen Simpson Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:24:45 -0000 > All that said, I don't really care. This is a tempest in a teapot. I > can mash together both texts if the Routing ADs are willing to accept a > passing reference here to a draft that, in their words, hasn't even been > considered by the IS-IS community. James, I believe that any departure from the text in ISO10589 needs to be discussed in the ISIS WG. - Stewart From carlsonj@workingcode.com Wed Jun 1 08:50:59 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773C2E0931 for ; Wed, 1 Jun 2011 08:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiDv5sOaRxnt for ; Wed, 1 Jun 2011 08:50:59 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76CE0934 for ; Wed, 1 Jun 2011 08:50:58 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p51Fome2009364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 11:50:48 -0400 (EDT) Message-ID: <4DE65FD8.1090702@workingcode.com> Date: Wed, 01 Jun 2011 11:50:48 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: stbryant@cisco.com References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> <4DE659C1.2050306@cisco.com> In-Reply-To: <4DE659C1.2050306@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist Cc: PPP Extensions , rbridge@postel.org, William Allen Simpson Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:50:59 -0000 Stewart Bryant wrote: > >> All that said, I don't really care. This is a tempest in a teapot. I >> can mash together both texts if the Routing ADs are willing to accept a >> passing reference here to a draft that, in their words, hasn't even been >> considered by the IS-IS community. > James, > > I believe that any departure from the text in ISO10589 needs > to be discussed in the ISIS WG. "Any" departure? No matter how subservient? That seems as inflexible as the other end of this spectrum. If I suggested text like this, would it require ISIS WG discussion, and, if so, what's the chance that this discussion would terminate in a positive way? 3. An implementation that has only PPP links might have no Organizationally Unique Identifier (OUI) that can form an IS-IS System ID. Resolving that issue is outside the scope of this document, however it is strongly RECOMMENDED that all TRILL implementations have at least one zero-configuration mechanism to obtain a valid System ID. Refer to ISO/IEC 10589 regarding System ID uniqueness requirements. Alternative solutions to this issue may also be defined in the future; see [8] for an example. -- James Carlson 42.703N 71.076W From stbryant@cisco.com Wed Jun 1 09:10:53 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7089FE07DC for ; Wed, 1 Jun 2011 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.461 X-Spam-Level: X-Spam-Status: No, score=-110.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63qvzbSYKy7V for ; Wed, 1 Jun 2011 09:10:52 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 82639E05D3 for ; Wed, 1 Jun 2011 09:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1477; q=dns/txt; s=iport; t=1306944652; x=1308154252; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=aYVhnmas6xfOxpmeY1OBgP5o3Jp5RdGKH1MtCOiHM24=; b=KXb5V3G4SqvXg3gmj4CpMJUtz1vBokcK+5l2TLa5cKEY2Ikk9clbQTDD +GiP7HC6xNojgr8IzMBAC2mW/8i3jhjHONQ0TCFSgoYC4nXNN6gUubHrY gMLb13tqfGKO49gMYICGOH5P2kC2EyY/mmJQw3jIgF7jSPqOO/2uXtjwm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFBj5k2Q/khR/2dsb2JhbABTpiR3iHGgb4J6DwGaQ4YgBJBVjyw X-IronPort-AV: E=Sophos;i="4.65,304,1304294400"; d="scan'208";a="33289482" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 01 Jun 2011 16:10:51 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p51GAmIk015413; Wed, 1 Jun 2011 16:10:51 GMT Received: from dhcp-gpk02-vlan300-64-103-65-100.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p51GAgW07612; Wed, 1 Jun 2011 17:10:46 +0100 (BST) Message-ID: <4DE6648E.7040605@cisco.com> Date: Wed, 01 Jun 2011 17:10:54 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: James Carlson References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> <4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> In-Reply-To: <4DE65FD8.1090702@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PPP Extensions , rbridge@postel.org, William Allen Simpson Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:10:53 -0000 On 01/06/2011 16:50, James Carlson wrote: > Stewart Bryant wrote: >>> All that said, I don't really care. This is a tempest in a teapot. I >>> can mash together both texts if the Routing ADs are willing to accept a >>> passing reference here to a draft that, in their words, hasn't even been >>> considered by the IS-IS community. >> James, >> >> I believe that any departure from the text in ISO10589 needs >> to be discussed in the ISIS WG. > "Any" departure? No matter how subservient? That seems as inflexible > as the other end of this spectrum. > If I suggested text like this, would it require ISIS WG discussion, and, > if so, what's the chance that this discussion would terminate in a > positive way? > > 3. An implementation that has only PPP links might have no > Organizationally Unique Identifier (OUI) that can form an IS-IS > System ID. Resolving that issue is outside the scope of this > document, however it is strongly RECOMMENDED that all TRILL > implementations have at least one zero-configuration mechanism to > obtain a valid System ID. Refer to ISO/IEC 10589 regarding System > ID uniqueness requirements. You are OK up to here since you conform to the current ISIS spec. > Alternative solutions to this issue > may also be defined in the future; see [8] for an example. This needs to be discussed in the ISIS WG, and I cannot vouch for the outcome. - Stewart From william.allen.simpson@gmail.com Wed Jun 1 09:23:42 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1277AE05D3 for ; Wed, 1 Jun 2011 09:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvMtf9vQUGTP for ; Wed, 1 Jun 2011 09:23:39 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64F6DE0709 for ; Wed, 1 Jun 2011 09:23:39 -0700 (PDT) Received: by gxk19 with SMTP id 19so3091715gxk.31 for ; Wed, 01 Jun 2011 09:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oTGl2cQ71Oz4SmxoWWlO6lHtRuJ6DH/BXHMcZhTrd10=; b=hiVGXnaCmlKWsSi/jlRRRIe+z7I3rnqEIk1GN+JBJRLaM4fj+zeiaunSJ++4DVOXC9 BKl755Dn8IxzX4ThgIxbHUL9bbNYZmqTxcVOJvfKCqwpRqt5aOdzB1NySmit9rm6653F W6i81ecutCcThppK1d9kE7gKWs4cO0La1WPvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FnpqR/m8CIqKuLEsMCobl+pfz/n6vKl6WDR6qPMij50GkF5vYz/77uoHHt0ttSFY1i h8gha6MzrhN92mz9S4RtmAyuuM4TGvp4pk0WX/iOAXfGun1vKKFJW2Vr9r4vtR/rRTdP EkENlHKVticqSDMZtconcnJlJPrG2J/0uSGRc= Received: by 10.90.249.27 with SMTP id w27mr6350072agh.139.1306945418866; Wed, 01 Jun 2011 09:23:38 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id x37sm792407ana.26.2011.06.01.09.23.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 09:23:37 -0700 (PDT) Message-ID: <4DE66787.30407@gmail.com> Date: Wed, 01 Jun 2011 12:23:35 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: James Carlson References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> In-Reply-To: <4DE6528B.7070501@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PPP Extensions , rbridge@postel.org, Stewart Bryant Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:23:42 -0000 On 6/1/11 10:54 AM, James Carlson wrote: > William Allen Simpson wrote: >> Therefore, James is also wrong. This is not an operator issue. You >> should *NOT* put this burden on operators. It would really help for >> anybody with aspirations of designing protocols to have actually been an >> operator, and pay attention to discussions on the NANOG list! > > It's worth noting that I said "implementor" not "operator." Perhaps the > language I'm using isn't clear. By "implementor," I mean the person who > designs the hardware and software components that will be sold as a > product claiming to support TRILL. I do not mean the person who buys > these products and installs them in a network. > When you say "implementor", are you proposing a penalty for failure? How do you enforce this as a protocol matter? Is there an automated discovery protocol in your draft? Currently, every system that has an IEEE interface is supposed to pay IEEE a fee. For PPP, we decided long ago that we would not require IETF implementers to pay a fee -- not to IETF or IEEE. I formally object to a specification that has no method of resolving duplicate identifiers. I have proposed three (3) methods. > Like you, I do not believe that it's appropriate or reasonable for > general-purpose TRILL implementations to require any sort of action on > the part of the person installing and using the equipment -- that is, > the "operator." I've never suggested that as a solution, so the straw > man doesn't work here. Nor do the ad-hominem jibes. > In point of fact, the enforcement burden falls on the operators, since in the real world here and now there are duplicate MAC identifiers. Let's try to write specifications that actually handle known problems. Any ad-hominem jibes would have to be a personal attack irrelevant to the issue at hand. That's not happening here. > However, unlike you, I do not believe that the IETF must resolve this > potential system-level design issue. Instead, I still strongly prefer > to leave it up to the people designing and building systems. If they > can't resolve this relatively simple problem in a reasonable way then, > frankly, I have no faith that they can get any of the other million or > so complex system design decisions right. > The IETF always used to handle any "system-level design issue" -- heck, our bake-offs used to spend a lot of time on it! That's one reason why we actually talk about specifics of implementations. > Most importantly, I don't want to be dictating anything about IS-IS > design issues from within the PPP Extensions working group. It's just > not appropriate or even feasible. That's why I agree with the ideas > behind Stewart Bryant's text. > I'm sick and tired of the inter-working group silliness. It's "I Plop Down" (IP over Large Data Networks) all over again. And really old folks will remember the huge fight between PPP and ANSI T1 et alia, as they didn't think IETF should specify anything over SONet without their concurrence.... > All that said, I don't really care. This is a tempest in a teapot. I > can mash together both texts if the Routing ADs are willing to accept a > passing reference here to a draft that, in their words, hasn't even been > considered by the IS-IS community. > Mash away. Thank you. From carlsonj@workingcode.com Wed Jun 1 09:33:35 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6E8E089F for ; Wed, 1 Jun 2011 09:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVba5OTfzdQs for ; Wed, 1 Jun 2011 09:33:34 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4BE08B7 for ; Wed, 1 Jun 2011 09:32:51 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p51GWjbL010159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 12:32:45 -0400 (EDT) Message-ID: <4DE669AD.5060208@workingcode.com> Date: Wed, 01 Jun 2011 12:32:45 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: stbryant@cisco.com References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> <4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> <4DE6648E.7040605@cisco.com> In-Reply-To: <4DE6648E.7040605@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist Cc: PPP Extensions , rbridge@postel.org, William Allen Simpson Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:33:35 -0000 Stewart Bryant wrote: > On 01/06/2011 16:50, James Carlson wrote: >> 3. An implementation that has only PPP links might have no >> Organizationally Unique Identifier (OUI) that can form an IS-IS >> System ID. Resolving that issue is outside the scope of this >> document, however it is strongly RECOMMENDED that all TRILL >> implementations have at least one zero-configuration mechanism to >> obtain a valid System ID. Refer to ISO/IEC 10589 regarding System >> ID uniqueness requirements. > You are OK up to here since you conform to the current ISIS spec. OK; that's good. >> Alternative solutions to this issue >> may also be defined in the future; see [8] for an example. > This needs to be discussed in the ISIS WG, and I cannot vouch > for the outcome. I see. -- James Carlson 42.703N 71.076W From ginsberg@cisco.com Wed Jun 1 09:33:35 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B981E08A7; Wed, 1 Jun 2011 09:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWuHznjZkltO; Wed, 1 Jun 2011 09:33:34 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id C4EDAE08AA; Wed, 1 Jun 2011 09:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=2376; q=dns/txt; s=iport; t=1306945956; x=1308155556; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UBbPCuqo1cfZQVPM3Bd7VOgY6pogUaECcPxGa3ZjLxg=; b=J211lKunokM+xvdSzZPrLs2jxHGRJ6MVdgOsPrwvefC6J0cJGXG/hq6J 06JBLiTX5cIVsat5Xn8SJvOkAKXLjb+QzCoBBQc183wAyoE/e5CkbLAc/ t+Dz3gUWrnAVA0mdcrSAIlim9ECuJM/vqnhynWvWpRMAw7ZrOYMtum9ih s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBACpp5k2rRDoH/2dsb2JhbABTl1KOVHepe51QhiAEhmWOPIp/ X-IronPort-AV: E=Sophos;i="4.65,304,1304294400"; d="scan'208";a="327930911" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2011 16:32:35 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p51GWZbl021761; Wed, 1 Jun 2011 16:32:35 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 09:32:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jun 2011 09:32:33 -0700 Message-ID: In-Reply-To: <4DE65FD8.1090702@workingcode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] [Pppext] TRILL, IS-IS, and System ID Thread-Index: AcwgdzEKMXVGlKq8T5O+BPVVvWbjtAAAcloQ References: <4DE51FC3.2070301@workingcode.com><4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com><4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> From: "Les Ginsberg (ginsberg)" To: "James Carlson" , "Stewart Bryant (stbryant)" X-OriginalArrivalTime: 01 Jun 2011 16:32:35.0566 (UTC) FILETIME=[837730E0:01CC2079] X-Mailman-Approved-At: Wed, 01 Jun 2011 09:37:34 -0700 Cc: PPP Extensions , rbridge@postel.org, isis mailing list , William Allen Simpson Subject: Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:33:35 -0000 (Please include isis-wg on this thread.) James - > -----Original Message----- > From: rbridge-bounces@postel.org [mailto:rbridge-bounces@postel.org] On > Behalf Of James Carlson > Sent: Wednesday, June 01, 2011 8:51 AM > To: Stewart Bryant (stbryant) > Cc: PPP Extensions; Donald Eastlake; rbridge@postel.org; William Allen > Simpson > Subject: Re: [rbridge] [Pppext] TRILL, IS-IS, and System ID >=20 > Stewart Bryant wrote: > > > >> All that said, I don't really care. This is a tempest in a teapot. > I > >> can mash together both texts if the Routing ADs are willing to > accept a > >> passing reference here to a draft that, in their words, hasn't even > been > >> considered by the IS-IS community. > > James, > > > > I believe that any departure from the text in ISO10589 needs > > to be discussed in the ISIS WG. >=20 > "Any" departure? No matter how subservient? That seems as inflexible > as the other end of this spectrum. >=20 > If I suggested text like this, would it require ISIS WG discussion, > and, > if so, what's the chance that this discussion would terminate in a > positive way? >=20 > 3. An implementation that has only PPP links might have no > Organizationally Unique Identifier (OUI) that can form an IS-IS > System ID. Resolving that issue is outside the scope of this > document, however it is strongly RECOMMENDED that all TRILL > implementations have at least one zero-configuration mechanism to > obtain a valid System ID. Refer to ISO/IEC 10589 regarding > System > ID uniqueness requirements. Alternative solutions to this issue > may also be defined in the future; see [8] for an example. I have a BIG PROBLEM with references to=20 [8] W. Simpson, "Generation of Unique IS-IS System Identifiers," (draft-simpson-isis-ppp-unique), work in progress, March 2011 This has been publicly reviewed and noted (and I think quite correctly so) as being seriously flawed. So even a passing suggestion that this might be a reasonable alternative for someone seems at best very premature. Les >=20 > -- > James Carlson 42.703N 71.076W > > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge From william.allen.simpson@gmail.com Wed Jun 1 09:37:59 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0913000E for ; Wed, 1 Jun 2011 09:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZ9m5YsdwZBr for ; Wed, 1 Jun 2011 09:37:58 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C91F313001B for ; Wed, 1 Jun 2011 09:37:54 -0700 (PDT) Received: by gwb20 with SMTP id 20so3099766gwb.31 for ; Wed, 01 Jun 2011 09:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qJiE6UqFAQZOOj5zFF96HVxqEFXQLd8pS+0gyFx6bgI=; b=kRTB3X18rFOzi1ggzOz+vzfTrTCecJ1cjWErRBkhLLMomTtdI0MOb4MHXU0dM0oEJs 9+xSYDXqtN1Zpez0UeenTvZiLYkfMAlAnBUVRNbPaDImRsoq+3+549DUNigXlWcX5BEE n9oc4x8NZ8P31RH3o0PiuiB6JQtD3PRDRpnxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=quY1367iAY8MWhLtlqrWVj9u1ZbXEpIjk9HoFZlCNZWOXwmrszN9ahowRznTv4Ea6b EM11A3jvHBNz/RVBkzQxYUr5lG8R3XJomih1dYTWrcKBTp+a+XaY2S2rjfyIm53hUYNc SPi0D3LeoTC/tL7c8sfy+KcdBUHWy+AqCBbLw= Received: by 10.151.154.7 with SMTP id g7mr6132874ybo.265.1306946274169; Wed, 01 Jun 2011 09:37:54 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id i61sm1283258yhe.19.2011.06.01.09.37.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 09:37:53 -0700 (PDT) Message-ID: <4DE66ADF.20002@gmail.com> Date: Wed, 01 Jun 2011 12:37:51 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: stbryant@cisco.com References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> <4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> <4DE6648E.7040605@cisco.com> In-Reply-To: <4DE6648E.7040605@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PPP Extensions , rbridge@postel.org Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 16:37:59 -0000 On 6/1/11 12:10 PM, Stewart Bryant wrote: > On 01/06/2011 16:50, James Carlson wrote: >> Stewart Bryant wrote: >>>> All that said, I don't really care. This is a tempest in a teapot. I >>>> can mash together both texts if the Routing ADs are willing to accept a >>>> passing reference here to a draft that, in their words, hasn't even been >>>> considered by the IS-IS community. >>> James, >>> >>> I believe that any departure from the text in ISO10589 needs >>> to be discussed in the ISIS WG. Please point to the text in ISO10589 on configuring System Identifiers. Quote the section and page. Please point to the text in ISO10589 on autonomously resolving conflicting System Identifiers. Quote the section and page. Heck, I've not seen any reference to duplicate System Identifiers in ISO10589 anywhere. Perhaps the standardese escaped my notice? >> "Any" departure? No matter how subservient? That seems as inflexible >> as the other end of this spectrum. >> If I suggested text like this, would it require ISIS WG discussion, and, >> if so, what's the chance that this discussion would terminate in a >> positive way? >> >> 3. An implementation that has only PPP links might have no >> Organizationally Unique Identifier (OUI) that can form an IS-IS >> System ID. Resolving that issue is outside the scope of this >> document, however it is strongly RECOMMENDED that all TRILL >> implementations have at least one zero-configuration mechanism to >> obtain a valid System ID. Refer to ISO/IEC 10589 regarding System >> ID uniqueness requirements. > You are OK up to here since you conform to the current ISIS spec. > >> Alternative solutions to this issue >> may also be defined in the future; see [8] for an example. > This needs to be discussed in the ISIS WG, and I cannot vouch > for the outcome. > Maybe you should try following the IETF process as written, instead of wasting all of our time. The ISIS chairs refused to take it up months ago. They have had plenty of notice. The draft has been well reviewed. You have mere days left to writeup any text the IESG wants included. Better get cracking.... From william.allen.simpson@gmail.com Wed Jun 1 10:04:26 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31316E0651; Wed, 1 Jun 2011 10:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jr+VlgV3Mvyj; Wed, 1 Jun 2011 10:04:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E796EE0878; Wed, 1 Jun 2011 10:02:56 -0700 (PDT) Received: by yxk30 with SMTP id 30so3111603yxk.31 for ; Wed, 01 Jun 2011 10:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VlnTNskrnsPEwq9ljOj0wGt/D2oUbxUpB7qlor9bupA=; b=r5fX/WrNcxpgqn3gciB8v8EUgbuQSligi4M+I6AXXKZ/crVwB0zH9HN6DMDSCPihqJ 5Hq0J4Xf7qqvlhvPJqosyoJYCe3fdPlZ4oASTkQzkASSMJJ1hg290RxR1SQl0juAGEQf U4iF8J6l4sOShxmn5MjXy0daf1zRY7+ko6Uvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dIq79SqqQyJ0mYDS0PCjw61O1L75JxA5PyWOr5+hRtl3kic9XYQX2DnovGRl7rp0kn 6d2kI6hqx9J0EwDoiLmG/YRzH8zXyHWB22QhPIQEbXAF4RSBEooomy+yC9d5jETIEZKw XEGWdXpJcVgOt5gCjk9UvWu8p1D2TKTyoH6R4= Received: by 10.101.117.17 with SMTP id u17mr4778296anm.106.1306947776469; Wed, 01 Jun 2011 10:02:56 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id c3sm813638and.18.2011.06.01.10.02.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 10:02:55 -0700 (PDT) Message-ID: <4DE670BD.9010508@gmail.com> Date: Wed, 01 Jun 2011 13:02:53 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" References: <4DE51FC3.2070301@workingcode.com><4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com><4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PPP Extensions , rbridge@postel.org, "Stewart Bryant \(stbryant\)" Subject: Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:04:26 -0000 On 6/1/11 12:32 PM, Les Ginsberg (ginsberg) wrote: > (Please include isis-wg on this thread.) > No. It bounces, and ends up in my spam folder. There's some kind of moderator for non-members. > I have a BIG PROBLEM with references to > > [8] W. Simpson, "Generation of Unique IS-IS System Identifiers," > (draft-simpson-isis-ppp-unique), work in progress, March 2011 > > This has been publicly reviewed and noted (and I think quite correctly > so) as being seriously flawed. So even a passing suggestion that this > might be a reasonable alternative for someone seems at best very > premature. > This is *NOT* true! You have been aware of the draft for months, and had every opportunity to review. The only comments you've sent me are neither textual nor protocol relevant. Your comments were: On 4/25/11 1:39 PM, Les Ginsberg (ginsberg) wrote: # Is there a reason why the author is averse to bringing the draft to the # WG? # # Is there a reason why the WG chairs/ADs are not "encouraging" the author # to bring the draft to the WG? On 4/25/11 4:31 PM, Les Ginsberg (ginsberg) wrote: # I am not aware that you EVER sent this to IS-IS WG for comments. I am # aware that it was discussed on the TRILL list and the TRILL folks - # quite correctly - said this had nothing to do w TRILL. I don't follow # the PPP WG - but I could easily imagine that they would have said the # same thing. As you propose a change in behavior for IS-IS # implementations which is visible on the wire: # # # After detecting a conflicting System Identifier in a neighbor, or # receiving 3 or more IS-IS Hellos and failing to resolve participation # in an area within 10 seconds, an implementation conforming with this # specification MUST generate a replacement System Identifier using one # of the techniques specified above. # # # it seems a bit obvious that the IS-IS WG would be an appropriate place # to pursue the work. # # As to the need for speed in publishing this, I would point out that the # IS-IS protocol has been successfully deployed for 20 years and this # issue has not been a show stopper. That is not to say that your proposal # may not have merit - but any suggestion that this is a precondition for # publishing other IS-IS related drafts is flawed in my opinion. # # I encourage you to submit the draft to the IS-IS WG. # Five (5) months ago, that might have been helpful, but the work has been completed and ready for publication for some time. There is no need to "pursue the work" in ISIS, since that implies there is more work. I'm not interested in unpaid make-work projects. There is no need to "submit" to ISIS. There are no oaths of fealty involved. I've included (and acknowledged) all the useful comments received from ISIS WG members. From ginsberg@cisco.com Wed Jun 1 11:24:22 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A776130025; Wed, 1 Jun 2011 11:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.266 X-Spam-Level: X-Spam-Status: No, score=-9.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7av1eyU4dstS; Wed, 1 Jun 2011 11:24:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 64A8513004B; Wed, 1 Jun 2011 11:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=10995; q=dns/txt; s=iport; t=1306952637; x=1308162237; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=pjXD1g8SAPNXWpxDVdTvo1oNvt+54vXiK4Cpv61LDd8=; b=Xtj5sqp6wCgTrKGUUIR23m87l5Hg8PWSmnzXNNjsjE9rh2V3VlmFRGtS j9cwZlrd8ndy7D7OHgv9+LdJt6urcdwP1ZHmtVomVph/LDndzxi8vrL47 29udcTA0WMd3uWIF6oBgIFrpSLfT68k+MHl8A3xj9cw3TEOjp187syMLS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIBAPmC5k2rRDoI/2dsb2JhbABTl1eOVnepRZ1IhiAEhmWOPIQjhlw X-IronPort-AV: E=Sophos;i="4.65,304,1304294400"; d="scan'208";a="328019178" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2011 18:23:57 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p51INomw011097; Wed, 1 Jun 2011 18:23:56 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Jun 2011 11:23:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC2089.111AA182" Date: Wed, 1 Jun 2011 11:23:54 -0700 Message-ID: In-Reply-To: <4DE670BD.9010508@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rbridge] [Pppext] TRILL, IS-IS, and System ID Thread-Index: AcwgfczwVIZCYA9ARuCfQxZuQsYOAQACuMRA References: <4DE51FC3.2070301@workingcode.com><4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com><4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> <4DE670BD.9010508@gmail.com> From: "Les Ginsberg (ginsberg)" To: "William Allen Simpson" X-OriginalArrivalTime: 01 Jun 2011 18:23:56.0241 (UTC) FILETIME=[11754C10:01CC2089] Cc: PPP Extensions , rbridge@postel.org, isis mailing list , "Stewart Bryant \(stbryant\)" Subject: Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:24:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC2089.111AA182 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable William - I am attaching Mike Shand's post of 4/26 to the isis-wg. Perhaps you never saw this if you are not a WG member. Les > -----Original Message----- > From: William Allen Simpson [mailto:william.allen.simpson@gmail.com] > Sent: Wednesday, June 01, 2011 10:03 AM > To: Les Ginsberg (ginsberg) > Cc: James Carlson; Stewart Bryant (stbryant); PPP Extensions; Donald > Eastlake; rbridge@postel.org > Subject: Re: [rbridge] [Pppext] TRILL, IS-IS, and System ID >=20 > On 6/1/11 12:32 PM, Les Ginsberg (ginsberg) wrote: > > (Please include isis-wg on this thread.) > > > No. It bounces, and ends up in my spam folder. There's some kind of > moderator for non-members. >=20 >=20 > > I have a BIG PROBLEM with references to > > > > [8] W. Simpson, "Generation of Unique IS-IS System Identifiers," > > (draft-simpson-isis-ppp-unique), work in progress, March 2011 > > > > This has been publicly reviewed and noted (and I think quite > correctly > > so) as being seriously flawed. So even a passing suggestion that this > > might be a reasonable alternative for someone seems at best very > > premature. > > > This is *NOT* true! You have been aware of the draft for months, and > had every opportunity to review. The only comments you've sent me are > neither textual nor protocol relevant. Your comments were: >=20 >=20 > On 4/25/11 1:39 PM, Les Ginsberg (ginsberg) wrote: > # Is there a reason why the author is averse to bringing the draft to > the > # WG? > # > # Is there a reason why the WG chairs/ADs are not "encouraging" the > author > # to bring the draft to the WG? >=20 >=20 > On 4/25/11 4:31 PM, Les Ginsberg (ginsberg) wrote: > # I am not aware that you EVER sent this to IS-IS WG for comments. I am > # aware that it was discussed on the TRILL list and the TRILL folks - > # quite correctly - said this had nothing to do w TRILL. I don't follow > # the PPP WG - but I could easily imagine that they would have said the > # same thing. As you propose a change in behavior for IS-IS > # implementations which is visible on the wire: > # > # > # After detecting a conflicting System Identifier in a neighbor, or > # receiving 3 or more IS-IS Hellos and failing to resolve > participation > # in an area within 10 seconds, an implementation conforming with > this > # specification MUST generate a replacement System Identifier using > one > # of the techniques specified above. > # > # > # it seems a bit obvious that the IS-IS WG would be an appropriate > place > # to pursue the work. > # > # As to the need for speed in publishing this, I would point out that > the > # IS-IS protocol has been successfully deployed for 20 years and this > # issue has not been a show stopper. That is not to say that your > proposal > # may not have merit - but any suggestion that this is a precondition > for > # publishing other IS-IS related drafts is flawed in my opinion. > # > # I encourage you to submit the draft to the IS-IS WG. > # > Five (5) months ago, that might have been helpful, but the work has > been > completed and ready for publication for some time. There is no need to > "pursue the work" in ISIS, since that implies there is more work. I'm > not interested in unpaid make-work projects. >=20 > There is no need to "submit" to ISIS. There are no oaths of fealty > involved. I've included (and acknowledged) all the useful comments > received from ISIS WG members. ------_=_NextPart_001_01CC2089.111AA182 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 04:18:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-rcd-101.cisco.com ([72.163.62.138]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 04:18:31 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 06:18:30 -0500 Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2011 11:18:23 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3QBILdR007152; Tue, 26 Apr 2011 11:18:23 GMT Received: from mail.ietf.org ([64.170.98.30]) by sj-inbound-f.cisco.com with ESMTP; 26 Apr 2011 11:18:23 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5462E072B; Tue, 26 Apr 2011 04:17:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B71E0728 for ; Tue, 26 Apr 2011 04:17:13 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD2wDfkGghNI for ; Tue, 26 Apr 2011 04:17:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AED34E0723 for ; Tue, 26 Apr 2011 04:17:12 -0700 (PDT) Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 26 Apr 2011 11:17:11 +0000 Received: from [10.61.95.73] (ams3-vpn-dhcp8010.cisco.com [10.61.95.73]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3QBHBYJ008642 for ; Tue, 26 Apr 2011 11:17:11 GMT Content-class: urn:content-classes:message Subject: Re: [Isis-wg] draft-simpson-isis-ppp-unique-00 Date: Tue, 26 Apr 2011 04:17:11 -0700 Message-ID: <4DB6A9B7.9010808@cisco.com> In-Reply-To: <4DB5AE7D.3020108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] draft-simpson-isis-ppp-unique-00 Thread-Index: AcwEA60MKITARKCzQLK3YQts4HvItw== References: <4DB5AE7D.3020108@cisco.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Mike Shand (mshand)" Sender: To: I have some comments on this draft. If a duplicated MAC is used as a System Identifier within an IS-IS area, this leads to the condition colloquially called "LSR War". Currently, IS-IS has no method to detect or resolve such conflicts. It is something of an exaggeration to say that IS-IS has NO method to detect this situation. It will result in the affected systems = persistently increasing the sequence numbers of their LSPs, in an attempt to assert their own LSPs over the duplicates. Most implementations will detect = this condition and raise appropriate system warning messages. Admittedly, the consequences, while this persists, are quite serious. After detecting a conflicting System Identifier in a neighbor, or receiving 3 or more IS-IS Hellos and failing to resolve = participation in an area within 10 seconds, an implementation conforming with this specification MUST generate a replacement System Identifier using = one of the techniques specified above. I don't understand this paragraph. It talks about detecting the = conflicting system IDs in the neighbor using ISHs. But the problem arises across an = entire flooding domain (a single level 1 area or the level 2 domain). It is = possible, and indeed probable that the offending system IDs are not adjacent, but = will still cause the same level of disruption. I also don't understand what is meant by "failing to resolve = participation in an area within 10 seconds". Surely this doesn't mean a simple mismatch = of area address, or any other reason for failing to bring up an L1 adjacency. = I'm guessing the author means receiving a hello with the same system ID as itself? = But this can occur benignly when a system has multiple interfaces onto the same LAN ( = either deliberately or by some bridging misconfiguration), and it is indeed = hearing its own hellos. So this seems to make no sense at all, and clearly wouldn't work. For it to work, it would have to be based on receiving an LSP which = somehow indicated the conflict. But receiving your own LSPs (with your own system ID) is a = normal occurrence, especially when rejoining a domain after a crash etc. So a = means needs to be provided to distinguish the common benign case, from a genuine = doppelganger. Other that using some other "more unique" id to distinguish really = different system (which just punts the problem), it seems that some variant of the normal detection method (i.e. detecting a persitent sequence number = increment), is the only viable alternative. Yet this draft says nothing about such a = mechanism. Whatever method were chosen, it would have to be proof against false = positives, since accidentally invoking a changed system ID would seem to make the cure = worse than the disease. Indeed, there seems to be a danger that bringing up a new system with an = incorrectly assigned system ID (the usual case is accidentally joining a test = network to the production network) would cause the existing (and previously stable) = system to change its ID. Note that gratuitously changing a system ID can affect things other that = the operation of IS-IS itself. For example the system ID is often used as = the key in the hash function for preventing polarisation in hop by hop = forwarding ECMP paths, so changing the system ID is likely to affect traffic patterns = adversely. This whole thing needs to be MUCH, more carefully thought out, if indeed = a solution is to be attempted. Mike On 25/04/2011 18:25, Stewart Bryant wrote: > ISIS WG > > It seems likely that draft-simpson-isis-ppp-unique-00 will > be submitted as an experimental submission on the > independent stream. > > Please look out for it. > > If you have any views on this document please make them known. > > - Stewart > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg ------_=_NextPart_001_01CC2089.111AA182-- From vjs@calcite.rhyolite.com Wed Jun 1 13:04:01 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA77E085E for ; Wed, 1 Jun 2011 13:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyVzVHDyHh6y for ; Wed, 1 Jun 2011 13:04:01 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 6E083E085D for ; Wed, 1 Jun 2011 13:03:59 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p51K3kiZ058553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from ; Wed, 1 Jun 2011 20:03:47 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p51K3i0g058552; Wed, 1 Jun 2011 20:03:44 GMT Date: Wed, 1 Jun 2011 20:03:44 GMT From: Vernon Schryver Message-Id: <201106012003.p51K3i0g058552@calcite.rhyolite.com> To: pppext@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Cc: rbridge@postel.org, ginsberg@cisco.com, stbryant@cisco.com Subject: Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:04:01 -0000 > ... > This whole thing needs to be MUCH, more carefully thought out, if indeed = > a solution > is to be attempted. Indeed. The PPPEXT WG and all documents produced by the PPPEXT WG should stick to PPP, and not try to fix other protocols, whether IS-IS, RIP, BGP, HTTP, TCP, or anything else. It is as wrong to try solve IS-IS problems in the PPPEXT WG as it is to solve PPP problems in other IETF working groups or other standards organizations' committees. It's irrelevant that the familiar, often well founded suspicions of forum shopping do not fit this controversy. More to the point, if neither forum shopping nor coup counting matter, then the "LSR War" and related IS-IS problems talked about in http://tools.ietf.org/html/draft-simpson-isis-ppp-unique-01 must be considered first in the ISIS WG. Only if and when the ISIS WG decides that IS-IS needs help in the point-to-point protocol should the PPPEXT WG notice. That participants in the ISIS WG might need to subscribe to the ISIS-WG mailing list to participate in those discussions is irrelevant here. If the ISIS WG fails to agree that a problem needs to be solved, then this PPPEXT WG is required to keep quiet and not be helpful. The ISIS WG group has a duty to be as wrong as it feels is right. None of that precludes individual submissions or non-standards track RFCs, but those would be irrelevant to J.Carlson's standards track document. Are PPP WGs still ruled by consensus? Does anyone besides W.Simpson think that J.Carlson's PPP TRILL document should say more than the global minimum about IS-IS system identifiers, possibly nothing at all? I propose that mention of the IS-IS identifier uniqueness be minimized in the PPP TRILL document. If ISIS WG decides on a problem and wants PPP TRILL changes, then a new PPP TRILL RFC can published. Vernon Schryver vjs@rhyolite.com From vjs@calcite.rhyolite.com Thu Jun 2 01:15:56 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D72E068B for ; Thu, 2 Jun 2011 01:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raXVWa4ukEdv for ; Thu, 2 Jun 2011 01:15:55 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0A3E06B6 for ; Thu, 2 Jun 2011 01:15:53 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p528Fex5029578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from ; Thu, 2 Jun 2011 08:15:41 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p528FdXL029577; Thu, 2 Jun 2011 08:15:39 GMT Date: Thu, 2 Jun 2011 08:15:39 GMT From: Vernon Schryver Message-Id: <201106020815.p528FdXL029577@calcite.rhyolite.com> To: pppext@ietf.org X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Cc: rbridge@postel.org, ginsberg@cisco.com, stbryant@cisco.com Subject: Re: [Pppext] [rbridge] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 08:15:56 -0000 I don't understand the second application of the Birthday Paradox in http://tools.ietf.org/html/draft-simpson-isis-ppp-unique-01 It is true that the probability that at least 2 of N random, uniformly distributed selections from the set of M numbers from 1 to M are the same is greater than 0.5 when N is greater than the square root of M. That justifies the first application of the Paradox in section 2. I don't understand the reasoning behind the claim in section 3: ] The probability ] of conflict is defined by a birthday attack of the order N/2**16; ] where N is the number of systems in the same IS-IS area. ] ] Also, many companies reuse the same MAC for different product lines, ] or different speeds or types of media. It is true that for a single OUI, a vendor can assigned 2**24 distinct non-multicast MAC addresses. My problems are that: - The square root of 2**24 is 4096 instead of 2**16. Where did 2**16 come from? - Companies making more than 2**24 devices have always been able to get additional OUIs. - The least significant 24 bits of the MAC addresses for a given OUI seen in a given network are often not uniformly distributed, which makes the Birthday Paradox inapplicable. If you buy many devices made by a single vendor, you might well get 'runs' of consecutive addresses. That can significantly reduce the likelihood of collision. - During the approximately dozen years that I was the MAC address czar for a computer vendor, I was aware of one or two cases of duplicate MAC addresses. They were cases where the people on the factory floor messed up and used re-used blocks of numbers that I had released instead of asking for another block. The resulting distributions of duplicate addresses going out the factory door or arriving at customer sites were not at all uniform, again making the Birthday Paradox the wrong model. - After decades of IEEE 48-bit MAC address assignments, it must be possible to measure the probability of 48-bit IEEE MAC address collisions. Handwaving about vendors too lazy to get additional OUIs and talk about broken, 1990 vintage Ethernet-FDDI bridges cannot justify solving a problem that can now be measured and found serious, non-existent, or somewhere between. It is necessary to collect 48-bit IEEE addresses and look for duplicates. If the probability of duplicate MAC addresses in an IS-IS area using TRILL is enough smaller than probability of other failures, then the problem 'MUST NOT' be solved. Vernon Schryver vjs@rhyolite.com From stbryant@cisco.com Thu Jun 2 03:44:28 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADB9E0736 for ; Thu, 2 Jun 2011 03:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.427 X-Spam-Level: X-Spam-Status: No, score=-110.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiTd4XXRyDUK for ; Thu, 2 Jun 2011 03:44:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0956BE06EC for ; Thu, 2 Jun 2011 03:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2782; q=dns/txt; s=iport; t=1307011467; x=1308221067; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LR1Vlubf85nkyLKlpYcw79Fr6nkqnWV5FlNHFQ5pfRQ=; b=E60Aal+8cTIT2PyBQxSaCRyBA6iEbQpkTnhLX1SjkKzTnlbv8+aGMjf1 MiWSoiLT+7q0gSnFR6EabOE94hZ+etSEDjXitDFsqTcyICSBVaCJ9yM8+ CIK9UlN4Kdi7iAGAd6++7IpE6X8GklzwapSAEMg8/OQmOIWDH5L0aPVb1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKpo502Q/khR/2dsb2JhbABTpjF3iHGhdoJ6DwGaZoYhBJBnjzE X-IronPort-AV: E=Sophos;i="4.65,308,1304294400"; d="scan'208";a="33411713" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 02 Jun 2011 10:44:25 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p52AiPNa022695; Thu, 2 Jun 2011 10:44:25 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p52AiNW13740; Thu, 2 Jun 2011 11:44:23 +0100 (BST) Message-ID: <4DE76994.3040807@cisco.com> Date: Thu, 02 Jun 2011 11:44:36 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: William Allen Simpson References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> <4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> <4DE6648E.7040605@cisco.com> <4DE66ADF.20002@gmail.com> In-Reply-To: <4DE66ADF.20002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PPP Extensions , rbridge@postel.org Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 10:44:28 -0000 On 01/06/2011 17:37, William Allen Simpson wrote: > On 6/1/11 12:10 PM, Stewart Bryant wrote: >> On 01/06/2011 16:50, James Carlson wrote: >>> Stewart Bryant wrote: >>>>> All that said, I don't really care. This is a tempest in a teapot. I >>>>> can mash together both texts if the Routing ADs are willing to >>>>> accept a >>>>> passing reference here to a draft that, in their words, hasn't >>>>> even been >>>>> considered by the IS-IS community. >>>> James, >>>> >>>> I believe that any departure from the text in ISO10589 needs >>>> to be discussed in the ISIS WG. > > Please point to the text in ISO10589 on configuring System Identifiers. > > Quote the section and page. The following text: ISO/IEC 10589:2002(E) Page15 7.1.4 Administration and deployment of systems in a routeing domain "It is the responsibility of the routeing domain administrative authority to enforce the requirements stated below in this clause" ISO/IEC 10589:2002(E) Page16 section (a) point 2 "Each system in an area must have an unambiguous ID; that is, no two systems (IS or ES) in an area may use the same ID value." ISO/IEC 10589:2002(E) Page16 section (b) point 1 "Each Level 2 Intermediate system within a routeing domain must have an unambiguous value for its ID field; that is, no two level 2 ISs in a routeing domain can have the same value in their ID fields." ISO/IEC 10589:2002(E) Page148 Informational Annex B.1.1.3 The identifier (id) field para 3 "Second, a considerable savings can be obtained in manual address administration for all systems in the routeing domain. If the ID is chosen from the ISO 8802 48-bit address space (represented as a sequence of 6 octets as specified in ISO/IEC 10039), the ID is known to be globally unique. Furthermore, since LAN systems conforming to ISO 8802 often have their 48-bit MAC address stored in ROM locally, each system can be guaranteed to have a globally unambiguous NET and NSAP(s) without centralised address administration at the area level2). This not only eliminates administrative overhead, but also drastically reduces the possibility of duplicate NSAP addresses, which are illegal, difficult to diagnose, and often extremely difficult to isolate." Seems to fully describe the intent of the authors. > Please point to the text in ISO10589 on autonomously resolving > conflicting > System Identifiers. > > Quote the section and page. The text above seems to make it clear that the specifcation requires resolution at either configuration or manufacturing time. > > Heck, I've not seen any reference to duplicate System Identifiers in > ISO10589 anywhere. Perhaps the standardese escaped my notice? Please see Annex B.1.1.3 Stewart From carlsonj@workingcode.com Thu Jun 2 08:32:28 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2A2E0726 for ; Thu, 2 Jun 2011 08:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.07 X-Spam-Level: X-Spam-Status: No, score=-103.07 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1Bla4aZQMPA for ; Thu, 2 Jun 2011 08:32:27 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B711E06AF for ; Thu, 2 Jun 2011 08:32:27 -0700 (PDT) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p52FWG7m001493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jun 2011 11:32:16 -0400 (EDT) Message-ID: <4DE7AD00.3080708@workingcode.com> Date: Thu, 02 Jun 2011 11:32:16 -0400 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: stbryant@cisco.com References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> <4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> <4DE6648E.7040605@cisco.com> In-Reply-To: <4DE6648E.7040605@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: carlson; whitelist Cc: PPP Extensions , rbridge@postel.org, William Allen Simpson Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 15:32:28 -0000 Stewart Bryant wrote: > On 01/06/2011 16:50, James Carlson wrote: >> 3. An implementation that has only PPP links might have no >> Organizationally Unique Identifier (OUI) that can form an IS-IS >> System ID. Resolving that issue is outside the scope of this >> document, however it is strongly RECOMMENDED that all TRILL >> implementations have at least one zero-configuration mechanism to >> obtain a valid System ID. Refer to ISO/IEC 10589 regarding System >> ID uniqueness requirements. > You are OK up to here since you conform to the current ISIS spec. It looks like we have convergence of sorts. I will update the specification to include the text above, and remove the reference to William Simpson's IS-IS draft. I realize this doesn't make everyone happy. It's impossible to do so. However, I do have an Area Director strongly suggesting this path, along with concurrence from both other PPPEXT participants and RBridge participants. I'm going to call that "rough consensus" and drive on. Anyone who disagrees ought to take the issue up with the IETF last call process (ietf@ietf.org) or, if necessary, the IESG. For convenience, the tracker entry is here: https://datatracker.ietf.org/doc/draft-ietf-pppext-trill-protocol/ The responsible AD is Jari Arkko . IETF last call ends June 8th, 2011, and comments (with the draft file name in the subject line) may be sent to ietf@ietf.org. -- James Carlson 42.703N 71.076W From jari.arkko@piuha.net Thu Jun 2 10:01:20 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A26E065B for ; Thu, 2 Jun 2011 10:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYrZhg6JLchD for ; Thu, 2 Jun 2011 10:01:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 9F18BE05D3 for ; Thu, 2 Jun 2011 10:01:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 80F852CC4D; Thu, 2 Jun 2011 20:01:18 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g5vhNs60w5q; Thu, 2 Jun 2011 20:01:18 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DD4C22CC3B; Thu, 2 Jun 2011 20:01:17 +0300 (EEST) Message-ID: <4DE7C1DD.9010605@piuha.net> Date: Thu, 02 Jun 2011 20:01:17 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: James Carlson References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE6528B.7070501@workingcode.com> <4DE659C1.2050306@cisco.com> <4DE65FD8.1090702@workingcode.com> <4DE6648E.7040605@cisco.com> <4DE7AD00.3080708@workingcode.com> In-Reply-To: <4DE7AD00.3080708@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PPP Extensions , "rbridge@postel.org" , William Allen Simpson , "stbryant@cisco.com" Subject: Re: [Pppext] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:01:20 -0000 James, all, >>> 3. An implementation that has only PPP links might have no >>> Organizationally Unique Identifier (OUI) that can form an IS-IS >>> System ID. Resolving that issue is outside the scope of this >>> document, however it is strongly RECOMMENDED that all TRILL >>> implementations have at least one zero-configuration mechanism to >>> obtain a valid System ID. Refer to ISO/IEC 10589 regarding System >>> ID uniqueness requirements. I like this text. And I agree with everything else you said in your e-mail James. To the working group: lets not get too hung over on this reference. Here's the positive takeaway: 1. We have a PPPEXT-TRILL doc moving forward, as simple as possible. 2. There seems to be pretty wide consensus that we need a good zero-configuration mechanism for ISIS System IDs. 3. There is a clear place for discussion about such mechanisms to happen in: ISIS WG 4. For sure, there may be disagreements about what the right proposal is, but that's usual (and far better than silence and no interest). Lets move forward with this. Bill, can you work with Stewart and the ISIS guys on the solutions (with the understanding that we'll probably need some amount of back-and-forth before we know what the right answer is)? I would appreciate having you (and others as well, of course) working on it. Jari From internet-drafts@ietf.org Fri Jun 3 12:45:15 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10F6E07B5; Fri, 3 Jun 2011 12:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fda5GKHsO1mu; Fri, 3 Jun 2011 12:45:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4DFE067F; Fri, 3 Jun 2011 12:45:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110603194515.16070.30947.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2011 12:45:15 -0700 Cc: pppext@ietf.org Subject: [Pppext] I-D Action: draft-ietf-pppext-trill-protocol-07.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 19:45:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Point-to-Point Protocol Extensions Wo= rking Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : James Carlson Filename : draft-ietf-pppext-trill-protocol-07.txt Pages : 7 Date : 2011-06-03 The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. This document describes PPP support for Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-07.txt From chopps@rawdofmt.org Mon Jun 6 09:09:15 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6FE11E8170; Mon, 6 Jun 2011 09:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE13aB3E5t75; Mon, 6 Jun 2011 09:09:15 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1273E11E817A; Mon, 6 Jun 2011 09:09:15 -0700 (PDT) Received: by pzk5 with SMTP id 5so2177592pzk.31 for ; Mon, 06 Jun 2011 09:09:14 -0700 (PDT) Received: by 10.68.22.197 with SMTP id g5mr2065311pbf.254.1307376554528; Mon, 06 Jun 2011 09:09:14 -0700 (PDT) Received: from rtp-chopps-8711.cisco.com (rtp-isp-nat1.cisco.com [64.102.254.33]) by mx.google.com with ESMTPS id p5sm3771950pbd.92.2011.06.06.09.09.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2011 09:09:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Christian Hopps In-Reply-To: <4DE644F8.5060800@cisco.com> Date: Mon, 6 Jun 2011 12:09:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11EFD6B0-5CD7-4D4A-890F-59AE7C52AFD5@rawdofmt.org> References: <4DE51FC3.2070301@workingcode.com> <4DE63C68.9070102@gmail.com> <4DE644F8.5060800@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 06 Jun 2011 09:13:00 -0700 Cc: PPP Extensions , rbridge@postel.org, Christian Hopps , "isis-wg@ietf.org list" , William Allen Simpson Subject: Re: [Pppext] [Isis-wg] TRILL, IS-IS, and System ID X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 16:09:15 -0000 [Adding in correct isis-wg address..] On Jun 1, 2011, at 9:56 AM, Stewart Bryant wrote: > Bill >=20 > The discussion of suitable methods of ISIS and hence TRILL > SystemID uniqueness needs to take place on the ISIS list > (copied) regardless of the data link technology under > consideration. >=20 > James I am fine with your proposed text. >=20 > Stewart >=20 >=20 >=20 > On 01/06/2011 14:19, William Allen Simpson wrote: >> Obviously, Stewart is wrong. We've gone to great lengths to ensure = PPP is >> zero configuration. We never need to buy and burn IEEE MAC = identifiers. >>=20 >> TRILL seems to have zero configuration design goals, too. >>=20 >> Therefore, James is also wrong. This is not an operator issue. You >> should *NOT* put this burden on operators. It would really help for >> anybody with aspirations of designing protocols to have actually been = an >> operator, and pay attention to discussions on the NANOG list! >>=20 >> As a personal example, just last summer I spent *many* hours trying = to >> figure our what was happening as a political campaign couldn't get = their >> wireless access point to work. It was very flaky. At long last, = traces >> discovered that the AP had a conflicting MAC with another device at >> another office somewhere else in the Comcast region. You cannot = expect >> political operatives (and quite frankly any other business) to fix = this. >>=20 >> Therefore, this is a protocol design issue. I've been trying to live = with >> the various compromises on language, but this goes too far! >>=20 >> Technically, that MUST is certainly wrong. There's no guarantee of >> uniqueness, and uniqueness is required by both ISIS and TRILL. >>=20 >> Moreover, there's no guarantee that a hot swappable or card or board = based >> device will not become (even temporarily) a PPP-only device. To meet = that >> MUST, every vendor of PPP devices will have to burn an IEEE number = for >> every device. Yet, it still might not work! >>=20 >> That's simply wrong! There's a lot of nonsense in IETF protocols, = but we >> don't have to add more here and now. >>=20 >>=20 >> On 5/31/11 2:20 PM, Donald Eastlake wrote: >>> James, >>>=20 >>> I'm fine with your suggested tweak of Stewart Bryant's wording. >>>=20 >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street >>> Milford, MA 01757 USA >>> d3e3e3@gmail.com >>>=20 >>>=20 >>> On Tue, May 31, 2011 at 1:05 PM, James = Carlson wrote: >>>> As part of IETF review, the Routing ADs are looking over >>>> draft-ietf-pppext-trill-protocol-06. Not too surprising to me -- = given >>>> that I still think it's far out of scope -- the text concerning = IS-IS >>>> System IDs is causing trouble in that review. See this thread: >>>>=20 >>>> = http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533 >>>>=20 >>>> I wish I could leave the worms safely in the can, but it's looking = like >>>> that might not be one of the options. >>>>=20 >>>> Instead of the reference to Bill Simpson's draft, Stewart Bryant >>>> suggested replacement text like this: >>>>=20 >>>> ISO/IEC 10589 states that it is the responsibility of the routeing >>>> domain administrative authority to enforce the uniqueness of the >>>> system ID. In cases where a zero configuration system is >>>> supplied the system manufacturer MUST install a suitable >>>> unique identifier at manufacturing time. One way to achieve >>>> this is for the manufacturer to use a unique IEEE MAC address >>>> following the allocation procedures normally used in the >>>> manufacture of an Ethernet interface. >>>>=20 >>>> This tosses the issue back into the implementor's lap (which, >>>> incidentally, is exactly where I think the problem belongs), and >>>> suggests an existing and known solution where a MAC identifier may = be >>>> allocated for the system itself and used as a global ID to = construct the >>>> necessary IS-IS System ID. >>>>=20 >>>> For use in this draft, I would alter the wording slightly to = indicate >>>> that zero-configuration is strongly preferred for TRILL (as = guidance), >>>> and that obtaining a suitable identifier is the implementor's >>>> responsibility, rather than just saying "in cases where." >>>>=20 >>>> Would this change fly without breaking consensus? Or do we have to >>>> start over? >>>>=20 >>>> --=20 >>>> James Carlson 42.703N 71.076W >>>> _______________________________________________ >>>> Pppext mailing list >>>> Pppext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pppext >>>>=20 >>> _______________________________________________ >>> Pppext mailing list >>> Pppext@ietf.org >>> https://www.ietf.org/mailman/listinfo/pppext >>>=20 >>=20 >>=20 >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From jari.arkko@piuha.net Sun Jun 12 06:37:35 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21FC11E80E1; Sun, 12 Jun 2011 06:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABroXdlNJ5KI; Sun, 12 Jun 2011 06:37:35 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1C57B11E8072; Sun, 12 Jun 2011 06:37:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3CEDE2CC4D; Sun, 12 Jun 2011 16:37:34 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-+pE7a6o8H2; Sun, 12 Jun 2011 16:37:33 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 3B6682CC3B; Sun, 12 Jun 2011 16:37:33 +0300 (EEST) Message-ID: <4DF4C11C.9020500@piuha.net> Date: Sun, 12 Jun 2011 16:37:32 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: ietf@ietf.org References: <20110525161357.5909.40860.idtracker@ietfa.amsl.com> In-Reply-To: <20110525161357.5909.40860.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org Subject: Re: [Pppext] Last Call: (PPP TRILL Protocol Control Protocol) to Proposed Standard X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 13:37:35 -0000 This document has been in IESG review last week. A number of technical issues were raised (thank you!) and we are almost done with addressing them. Still negotiating what change, if any, to be done based on the Security AD's Discuss. However, the IESG has also asked me to treat this document as if it were an Individual Submission. This is not a negative assessment of the document content, the document was appreciated. But the IESG correctly noted that its not within the PPPEXT group's charter. It was my mistake to not catch this earlier. Sorry. In any case, as a result, we will deal with this document as an Individual Submission. The main change is the last call period. The last call of this document will continue until it has been under review for four weeks, and will be re-evaluated in the IESG telechat on June 23rd. We'd be happy to receive additional reviews. Jari From mark@townsley.net Fri Jun 17 06:22:13 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED9211E811A; Fri, 17 Jun 2011 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aaf49eQN2prs; Fri, 17 Jun 2011 06:22:12 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAC411E8111; Fri, 17 Jun 2011 06:22:11 -0700 (PDT) Received: by wwe5 with SMTP id 5so289794wwe.13 for ; Fri, 17 Jun 2011 06:22:10 -0700 (PDT) Received: by 10.227.12.15 with SMTP id v15mr2097053wbv.77.1308316930370; Fri, 17 Jun 2011 06:22:10 -0700 (PDT) Received: from ams-townsley-8713.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id ge4sm957658wbb.13.2011.06.17.06.22.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Jun 2011 06:22:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> Date: Fri, 17 Jun 2011 15:22:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> To: X-Mailer: Apple Mail (2.1084) Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 13:22:13 -0000 Technically, this approach is naturally feasible as PPP was designed = back when short-lived connectivity was commonplace. There is one crucial = difference though in that you will be exercising PPP stacks in a way = that is not common by tearing down and bringing up IPCP while not doing = so with LCP. According to all the RFCs this should work just fine, but = my intuition is that some PPP stacks will be forced into new code paths = that have never been exercised in this manner with the expectation of it = being the normal desired behavior. You can surely find a set of clients = where this will work, but it probably will not across the entire gamut = of deployed PPP today.=20 Applications may not be all that forgiving to IPv4 coming and going = either, e.g., I have a popular mail client that has recently taken to = crashing when I switch from wired to wireless and get a different IP = address in the process. Some of the IM connections I keep up recover = quickly to IP changes, others do not. The IETF has a whole WG (DNA) = dedicated to this tricky behavior of an IP address coming and going - = it's not always easy, in particular when the link-layer is not giving = your IP stack any up/down notification, which I believe by definition is = what your proposal requires from the very start. Finally, devices are moving towards a "cloud connected" mode of = operation. In IPv4, there is essentially no end-to-end reachability, so = modern applications are moving toward persistent, long-lived, = connections in order to achieve this. I suspect you'll see a noticeable = uptick in reliance upon such persistent, long-lived, IPv4 connections as = Apple's Lion and iOS 5 software is rolled out later this year. Both have = integration of the free "iCloud" services, and have replaced the USB = cord for device synchronization with a persistent network connection. = It's not just Apple though, the same trend is forming across the = industry.=20 So, my fear is that by the time you have built TDM into IPv4 across your = user base, it will have required at the very least a grand testing = effort and at the same time your users may well have changed their = behavior to make it unworkable anyway. I as much as anyone would hope = that all these new persistent connections would run over IPv6 if = available, but that is of course the exception not the rule for the time = being as well. - Mark On Jun 14, 2011, at 6:45 PM, = wrote: > Hi folks, >=20 > right in time before the next IETF in Quebec, we would like to come up = again with our Internet Draft > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > in order to gather further feedback from the WG. > During our presentation in Prague I got several remarks and questions > and from my understanding there has been some interest in the approach = we describe in this I-D. > Regarding the questions I want to focus on the following two and will = try to answer them once more: >=20 > - Use case: > In general we see this mechanism applicable for all Dual-Stack PPP = network scenarios allthrough we focussed our presentation for = illustrative reasons on routed gateways that may be provided by the = Access Network provider. > In principle as more IPv4 addresses can be saved, as more services are = IPv6 enabled > (especially those which require always-on connectivity (e.g. VoIP, = mail, update services)) . > The PPP protocol has not to be changed in order to achieve the needed = functionality - > the described behaviour (of independently releasing and > refreshing the IPv4 context within a Dual-Stack PPP session) > is already inherently covered by the existing PPP spec and also = mentioned as requirements for > CPEs (see RFC 6204 - WLL-3). >=20 > - Efficiency of the mechanism: > In principle we assume (with ongoing IPv6 deployment) that it is = possible to save > after one year of roll-out of the described mechanism about 3%, > after two years about 8%, > and after three years up to 13% of the provisioned IPv4 addresses. > After 8 years 70% of the IPv4 addresses can be "re-cycled" according = to our model calculations. > (You will find more details here: > = "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&t= hema=3DEffizienzabsch=E4tzung" > (please copy the whole text between the exclamation marks in the = address line of you browser).) >=20 >=20 > We plan to come up with a 01 version of the I-D and would that's why = like to gather more feedback from the WG regarding the possible open = issues (e.g. what has to be described in more detail, ), unanswered = questions or any other useful hints how to progress with this work/I-D. > And of course we are also interested in your opinion if this work = should be done within the Intarea WG or if other WGs (PPPEXT?) may be = more appropriate. >=20 >=20 > Thanks and kind regards >=20 > KARSTEN Fleischhauer > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From vjs@calcite.rhyolite.com Fri Jun 17 14:48:21 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E0511E80EF; Fri, 17 Jun 2011 14:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9ml-apexpDb; Fri, 17 Jun 2011 14:48:20 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9183211E807F; Fri, 17 Jun 2011 14:48:19 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p5HLmAB9098514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from ; Fri, 17 Jun 2011 21:48:10 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p5HLm8wt098512; Fri, 17 Jun 2011 21:48:08 GMT Date: Fri, 17 Jun 2011 21:48:08 GMT From: Vernon Schryver Message-Id: <201106172148.p5HLm8wt098512@calcite.rhyolite.com> To: K.Fleischhauer@telekom.de, mark@townsley.net In-Reply-To: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 21:48:21 -0000 > From: Mark Townsley > To: "" > Cc: pppext@ietf.org, int-area@ietf.org > Technically, this approach ... > > The PPP protocol has not to be changed in order to achieve the needed functionality - > > "http://www.ix-konferenz.de/getfoldat.php?vid=1638&t=application/pdf&thema=Effizienzabschätzung" What is the topic or issue? That PDF slide show has plenty of words and pictures justifying and advocating whatever it is talking about, but I don't seem much about concrete mechanisms or changes to PPP code. My guess is that the topic is something about PPP peers killing their IPCP state machines after IP inactivity (presumably ignoring LCP activity as well as other activity such as bridging) and then restarting IPCP on new activity to negotiate potentially new IPv4 addresses. If I've guessed the topic correctly then: - I bet M.Townsley is right and that some PPP implementations treat a broken IPCP state as reason to kill LCP and restart the whole session. - I think M.Townsley has understated the problems in changing IP addresses on running systems. I bet most server programs will not notice that their carefully constructed lists of TCP LISTEN or UDP sockets are kaput because the local IP addresses changed. Of course, any and all existing TCP sessions break when IP addresses change. Besides apparently quiet ssh, ftp, and (secure-)telnet sessions, and so forth, what about cached SMTP and HTTP connections? What about firewalls? - How often is IPCP used today to allocate IP addresses? Isn't DHCP often used even over PPP, especially for the consumer grade Internet services that are most likely to be targets of a scheme like this? - Would this scheme have more or fewer odd side effects and bad boundary cases than the other schemes for dealing with IPv4 address shortages such as "large scale" or "carrier grade NAT"? Besides application hiccups on changing addresses, what happens when all of your users try to be active and so you temporary can't allocate addresses for all of them? > > We plan to come up with a 01 version of the I-D ... > > And of course we are also interested in your opinion if this > > work should be done within the Intarea WG or if other WGs (PPPEXT?) > > may be more appropriate. Given the statement about the protocol itself not changing, how does the PPPEXT working group or the IETF in general have standing to talk about the issue or object to the proposal, whatever it is? Before writing an I-D that would merely try to convince others to write and test code, why not write and test some code before writing an I-D? Successful tests with a few 100 real users would go a long way to answering objections and generating interest in the idea. The idea might sound good if 500 real Windows users behind Lunix-based cable or DSL modems with the modest code implementing this idea have no problems. (What's the name of the commodity consumer router that is frequently and routinely hacked to support new things?) On the other hand, if it is impossible or impractical to write code, get it installed in a small test environment (e.g. a few 100 users), or get positive results from tests, then there's no need to write an I-D or for anyone else or any working group to consider it. If there is no hope of getting a router vendors to implement the idea before an RFC (not just an I-D) is published, then the idea has no hope. By the time an RFC could be approved and published and vendors respond, the IPv4 address shortage will have been solved for years one way or another. Vernon Schryver vjs@rhyolite.com From K.Fleischhauer@telekom.de Sun Jun 19 04:07:37 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AE021F8522; Sun, 19 Jun 2011 04:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xZ1OcquR0w0; Sun, 19 Jun 2011 04:07:34 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 05FC621F8519; Sun, 19 Jun 2011 04:07:33 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 19 Jun 2011 13:07:29 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Sun, 19 Jun 2011 13:07:29 +0200 From: To: Date: Sun, 19 Jun 2011 13:07:27 +0200 Thread-Topic: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwtOErscG1GntjtQNWsiA3dGo/begBLfhow Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C2A@HE111648.emea1.cds.t-internal.com> References: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> <201106172148.p5HLm8wt098512@calcite.rhyolite.com> In-Reply-To: <201106172148.p5HLm8wt098512@calcite.rhyolite.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 11:07:37 -0000 Dear Vernon, See my comments inline. Best KARSTEN > -----Urspr=FCngliche Nachricht----- > Von: Vernon Schryver [mailto:vjs@calcite.rhyolite.com] > Gesendet: Freitag, 17. Juni 2011 23:48 > An: Fleischhauer, Karsten; mark@townsley.net > Cc: int-area@ietf.org; pppext@ietf.org > Betreff: Re: [Pppext] [Int-area] IETF80 questions regarding > "On demand IPv4 address provisioning in Dual-Stack PPP > deployment" - Topic for WG? > > > From: Mark Townsley > > To: "" > > Cc: pppext@ietf.org, int-area@ietf.org > > > Technically, this approach ... > > > > The PPP protocol has not to be changed in order to > achieve the needed functionality - > > > > > "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplicati on/pdf&thema=3DEffizienzabsch=E4tzung" > > What is the topic or issue? That PDF slide show has plenty of words > and pictures justifying and advocating whatever it is talking about, > but I don't seem much about concrete mechanisms or changes to > PPP code. > My guess is that the topic is something about PPP peers killing their > IPCP state machines after IP inactivity (presumably ignoring LCP > activity as well as other activity such as bridging) and then > restarting > IPCP on new activity to negotiate potentially new IPv4 addresses. KF: You are right. > > If I've guessed the topic correctly then: > > - I bet M.Townsley is right and that some PPP implementations > treat a broken IPCP state as reason to kill LCP and restart > the whole session. I afraid you would win the bet. Therefore we are thinking it is important to have this ID/RFC to discuss/inform that also implementations are needed and will exists that expect an standard compliant PPP session peer. > > - I think M.Townsley has understated the problems in changing IP > addresses on running systems. I bet most server programs will > not notice that their carefully constructed lists of TCP LISTEN > or UDP sockets are kaput because the local IP addresses changed. > > Of course, any and all existing TCP sessions break when > IP addresses > change. Besides apparently quiet ssh, ftp, and (secure-)telnet > sessions, and so forth, what about cached SMTP and HTTP > connections? > > What about firewalls? That is right. But we would configure an "IPCP idle timer" value (for releasing the IPv4 a= ddress) which is equal to the today used "PPP idle timer" value. So we are expecting no additional problems in this implementations. Nevertheless, when here problems occur we provide at least in the internet = access area IPv6 as an alternative. Applications, services etc. can using IPv6! > - How often is IPCP used today to allocate IP addresses? Isn't DHCP > often used even over PPP, especially for the consumer grade > Internet services that are most likely to be targets of a scheme > like this? We are addressing here PPP and IPCP. Of course a similar use case is possible with DHCP with or without PPP. Maybe here the DHCP/DHCPv6 implementations have here not so many dependenci= es as Mark has reported for IPCP/IPv6CP. I do not know if the description of the same scenario for DHCP/DHCPv6 is ne= eded. In any case I would see this in an additional ID and not in PPPEXT or INTAR= EA. > > - Would this scheme have more or fewer odd side effects and bad > boundary cases than the other schemes for dealing with > IPv4 address > shortages such as "large scale" or "carrier grade NAT"? Besides > application hiccups on changing addresses, what happens when all > of your users try to be active and so you temporary > can't allocate > addresses for all of them? Olaf's calculation of the saving effects is based on statistics. The calculation/configuration of the address pool size in the operational n= etwork Will be done as a result of practical experience that we have already today for IPv4-only PPP usage (usage in the past + trend + reserve). Maybe today the PPP session capacity is a bottleneck, which will change to the size of the IPv4 address pools. But also in a CGN scenario a calculation is needed to optimize the network configuration/usage and costs. An also in this case bottlenecks will exist. > > > > > We plan to come up with a 01 version of the I-D ... > > > > And of course we are also interested in your opinion if this > > > work should be done within the Intarea WG or if other WGs > (PPPEXT?) > > > may be more appropriate. > > Given the statement about the protocol itself not changing, how does > the PPPEXT working group or the IETF in general have standing to talk > about the issue or object to the proposal, whatever it is? As indended status of the ID we proposed in the version 00 "Informational". The final classification will be a result of the discussion within the IETF= . In any case we want to discuss the draft in the IETF community and considering the feedback from all experts in future versions. > Before writing an I-D that would merely try to convince > others to write > and test code, why not write and test some code before writing an I-D? > Successful tests with a few 100 real users would go a long way to > answering objections and generating interest in the idea. The idea > might sound good if 500 real Windows users behind Lunix-based cable > or DSL modems with the modest code implementing this idea have no > problems. (What's the name of the commodity consumer router that is > frequently and routinely hacked to support new things?) > > On the other hand, if it is impossible or impractical to write code, > get it installed in a small test environment (e.g. a few 100 users), > or get positive results from tests, then there's no need to write > an I-D or for anyone else or any working group to consider it. > > If there is no hope of getting a router vendors to implement the > idea before an RFC (not just an I-D) is published, then the idea > has no hope. Before we introducing anything in the network for customer we analyzing, specifying, prototyping, implementing, testing internal and testing external. Because of our experience with PPP we see no need for a customer field tria= l. Currently we or our vendors are in different phases of speciying, prototyping and implementing. But we are thinking that it is not useful to discuss within the IETF commun= ity any project or business plans. > By the time an RFC could be approved and published > and vendors respond, the IPv4 address shortage will have been solved > for years one way or another. We believe that several solutions will be needed to mitigate the IPv4 address shortage. As stated above we are thinking that this solution can be one of them that could also applicable for other ISPs. Because of the relativly few changes in the implementatipons/message flow we are thinking that we will have until end of this year a very stable draf= t. So there is no burden to implement and use and solve the IPv4 address short= age. The IETF ID/RFC processing could be done in parallel. IMHO it is important that on the end the description of the mechanism is av= ailable/published as an IETF Draft or finally RFC. > > Vernon Schryver vjs@rhyolite.com > From K.Fleischhauer@telekom.de Sun Jun 19 04:51:33 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B73711E8094; Sun, 19 Jun 2011 04:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chJy+ySX5iOl; Sun, 19 Jun 2011 04:51:32 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9711E8072; Sun, 19 Jun 2011 04:51:31 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 19 Jun 2011 13:51:26 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Sun, 19 Jun 2011 13:51:26 +0200 From: To: Date: Sun, 19 Jun 2011 13:51:24 +0200 Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: Acws8ZmPzhgV3W/QTeOu234XVXc9pABgLCcg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C2B@HE111648.emea1.cds.t-internal.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> In-Reply-To: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 11:51:33 -0000 Dear Mark, See my comments inline. Best KARSTEN > -----Urspr=FCngliche Nachricht----- > Von: Mark Townsley [mailto:mark@townsley.net] > Gesendet: Freitag, 17. Juni 2011 15:22 > An: Fleischhauer, Karsten > Cc: int-area@ietf.org; pppext@ietf.org > Betreff: Re: [Int-area] IETF80 questions regarding "On demand > IPv4 address provisioning in Dual-Stack PPP deployment" - > Topic for WG? > > > Technically, this approach is naturally feasible as PPP was > designed back when short-lived connectivity was commonplace. > There is one crucial difference though in that you will be > exercising PPP stacks in a way that is not common by tearing > down and bringing up IPCP while not doing so with LCP. > According to all the RFCs this should work just fine, but my > intuition is that some PPP stacks will be forced into new > code paths that have never been exercised in this manner with > the expectation of it being the normal desired behaviour. You > can surely find a set of clients where this will work, but it > probably will not across the entire gamut of deployed PPP today. I share this fear but on the end this as also any other changes in the netw= ork needs testing before launch. On the network PPP peer side you could be "backward compatible". So also non draft "On demand IPv4 address provisioning in Dual-Stack PPP de= ployment" compatible PPP peers will work without problems. Maybe a problem can occur when a draft "On demand IPv4 address provisioning= in Dual-Stack PPP deployment" compliant PPP peers will appear on a network= where this support is missed. Maybe in this case an upgrade is needed. > > Applications may not be all that forgiving to IPv4 coming and > going either, e.g., I have a popular mail client that has > recently taken to crashing when I switch from wired to > wireless and get a different IP address in the process. Some > of the IM connections I keep up recover quickly to IP > changes, others do not. The IETF has a whole WG (DNA) > dedicated to this tricky behaviour of an IP address coming and > going - it's not always easy, in particular when the > link-layer is not giving your IP stack any up/down > notification, which I believe by definition is what your > proposal requires from the very start. In this case a "deactivation" of the feature on the HG would be useful. This could be done maybe due configuration or simply with sending IPv4 requ= ests within the "IPCP idle timer" value. But we would hope that these always-on applications will be move quickly to= IPv6. > > Finally, devices are moving towards a "cloud connected" mode > of operation. In IPv4, there is essentially no end-to-end > reach ability, so modern applications are moving toward > persistent, long-lived, connections in order to achieve this. > I suspect you'll see a noticeable uptick in reliance upon > such persistent, long-lived, IPv4 connections as Apple's Lion > and iOS 5 software is rolled out later this year. Both have > integration of the free "iCloud" services, and have replaced > the USB cord for device synchronization with a persistent > network connection. It's not just Apple though, the same > trend is forming across the industry. That should be considered in our efficiency calculation. As already mentioned we would recommend here the usage of IPv6. This is also valid for other update services (anti-virus, OS, email, etc.). I think the support of NAT444 as "alternative" would not simplify such apps= . > > So, my fear is that by the time you have built TDM into IPv4 > across your user base, it will have required at the very > least a grand testing effort and at the same time your users > may well have changed their behavior to make it unworkable > anyway. I as much as anyone would hope that all these new > persistent connections would run over IPv6 if available, but > that is of course the exception not the rule for the time > being as well. Our estimation of the saving effects is more or less conservative and consi= dering a rather small adaption of IPv6. We will introduce Dual-Stack in the first phase, the address saving in the = second phase. So the IPv6 content provider would have here a small advance to enable thei= r apps. Maybe other ISPs can initially implement the address saving feature (no rev= ision of the Dual-Stack implementation is needed). But these ISPs would be = benefit from the early mover. Surely beside the implementation of the draft also other ISP internal IPv4 = address efficiency measures would be useful und helpful to provide the cust= omer the best IP connectivity as possible. > > - Mark > > > On Jun 14, 2011, at 6:45 PM, > wrote: > > > Hi folks, > > > > right in time before the next IETF in Quebec, we would like > to come up again with our Internet Draft > > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > > in order to gather further feedback from the WG. > > During our presentation in Prague I got several remarks and > questions > > and from my understanding there has been some interest in > the approach we describe in this I-D. > > Regarding the questions I want to focus on the following > two and will try to answer them once more: > > > > - Use case: > > In general we see this mechanism applicable for all > Dual-Stack PPP network scenarios allthrough we focussed our > presentation for illustrative reasons on routed gateways that > may be provided by the Access Network provider. > > In principle as more IPv4 addresses can be saved, as more > services are IPv6 enabled > > (especially those which require always-on connectivity > (e.g. VoIP, mail, update services)) . > > The PPP protocol has not to be changed in order to achieve > the needed functionality - > > the described behaviour (of independently releasing and > > refreshing the IPv4 context within a Dual-Stack PPP session) > > is already inherently covered by the existing PPP spec and > also mentioned as requirements for > > CPEs (see RFC 6204 - WLL-3). > > > > - Efficiency of the mechanism: > > In principle we assume (with ongoing IPv6 deployment) that > it is possible to save > > after one year of roll-out of the described mechanism about 3%, > > after two years about 8%, > > and after three years up to 13% of the provisioned IPv4 addresses. > > After 8 years 70% of the IPv4 addresses can be "re-cycled" > according to our model calculations. > > (You will find more details here: > > > "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplicati on/pdf&thema=3DEffizienzabsch=E4tzung" > > (please copy the whole text between the exclamation marks > in the address line of you browser).) > > > > > > We plan to come up with a 01 version of the I-D and would > that's why like to gather more feedback from the WG regarding > the possible open issues (e.g. what has to be described in > more detail, ), unanswered questions or any other useful > hints how to progress with this work/I-D. > > And of course we are also interested in your opinion if > this work should be done within the Intarea WG or if other > WGs (PPPEXT?) may be more appropriate. > > > > > > Thanks and kind regards > > > > KARSTEN Fleischhauer > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > From vjs@calcite.rhyolite.com Sun Jun 19 08:45:55 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFD111E80CA; Sun, 19 Jun 2011 08:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg2+GvsRrBqN; Sun, 19 Jun 2011 08:45:54 -0700 (PDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1711E8070; Sun, 19 Jun 2011 08:45:54 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p5JFjmrv042970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from ; Sun, 19 Jun 2011 15:45:48 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p5JFjlWL042969; Sun, 19 Jun 2011 15:45:47 GMT Date: Sun, 19 Jun 2011 15:45:47 GMT From: Vernon Schryver Message-Id: <201106191545.p5JFjlWL042969@calcite.rhyolite.com> To: K.Fleischhauer@telekom.de In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C2A@HE111648.emea1.cds.t-internal.com> X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 15:45:55 -0000 > From: > To: > CC: , , > > My guess is that the topic is something about PPP peers killing their > > IPCP state machines after IP inactivity (presumably ignoring LCP > > activity as well as other activity such as bridging) and then > > restarting > > IPCP on new activity to negotiate potentially new IPv4 addresses. > > KF: You are right. That seems to contradict the later statement that the new IPCP idle timer would have the same value as existing LCP idle timers. > > - I think M.Townsley has understated the problems in changing IP > > addresses on running systems. I bet most server programs will > > Of course, any and all existing TCP sessions break when > > What about firewalls? > > That is right. > But we would configure an "IPCP idle timer" value (for releasing the IPv4 address) > which is equal to the today used "PPP idle timer" value. In that case, I wonder if I understand what is being proposed I think that LCP idle timers are generally reset by IP traffic. So an additional explicit IPCP idle timer would not be needed. See http://www.google.com/search?q=lcp+idle+timer > > - How often is IPCP used today to allocate IP addresses? Isn't DHCP > > often used even over PPP, especially for the consumer grade > We are addressing here PPP and IPCP. I think it is best to consider to entire systems. A PPP mechanism that would almost never be used because other standardized mechanism are and will be used to provide its facilities is inadmissable to a reasonable official standards process. > Of course a similar use case is possible with DHCP with or without PPP. It sounds as if the proposal is a recommendation that Internet services provides who lack IPv4 addresses configure things so that: - IPv4 addresses are not statically assigned on PPP links, - dynamic IPCP IPv4 address assignments do not endure PPP resets, especially those triggered by LCP idle timers, - DHCP lease times be shortened - the de facto standard DHCP features that try to give returning users the same IPv4 addresses be turned off Those ideas seem like common sense (al beit rather obvious) and don't unnecessarily violate layers or introduce distasteful IPCP options like certain proposals outside the PPPEXT working group. > In any case I would see this in an additional ID and not in PPPEXT or INTAREA. Since no point-to-point protocol changes are being proposed and contents of an ID would be obvious operational advice, I don't see a PPP RFC. Perhaps an informational RFC could be justified. It would be better than some informational I-Ds involving vendor-specific IPCP options. > > - Would this scheme have more or fewer odd side effects and bad > > boundary cases than the other schemes for dealing with > > shortages such as "large scale" or "carrier grade NAT"? Besides > Olaf's calculation of the saving effects is based on statistics. > The calculation/configuration of the address pool size in the operational network > Will be done as a result of practical experience that we have already > today for IPv4-only PPP usage (usage in the past + trend + reserve). > Maybe today the PPP session capacity is a bottleneck, > which will change to the size of the IPv4 address pools. > But also in a CGN scenario a calculation is needed to optimize > the network configuration/usage and costs. > An also in this case bottlenecks will exist. I do not see an answer to my question about how this proposal compares with schemes such as LSN or CGN. See http://www.google.com/search?q=IPv4+cgn+OR+lsn Perhaps your informational I-D could say something about that. See also http://www.google.com/search?q=ietf+IPv4+address+shortage+bcp and even http://www.google.com/search?q=ietf+IPv4+address+shortage+ppp > As indended status of the ID we proposed in the version 00 "Informational". I thought informational RFCs do not depend on the let, leave, or hindrance of IETF working groups. Vernon Schryver vjs@rhyolite.com From cb.list6@gmail.com Fri Jun 17 07:24:42 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8056C11E80B9; Fri, 17 Jun 2011 07:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Urc4U9UZcJ1; Fri, 17 Jun 2011 07:24:41 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3D24811E80A4; Fri, 17 Jun 2011 07:24:40 -0700 (PDT) Received: by wwg11 with SMTP id 11so446340wwg.1 for ; Fri, 17 Jun 2011 07:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tNmDF3RqaVLi2WmzNBEP7q0zSk2L4m4BK2P9t06/WGY=; b=HSb0DhWNFebfm1jSubK4dM2NF2yNkeWNhgAQjsigQVYWx6IGRHgP7Iip6mJoSG4RUm 6nG/9kHGBZ5/16+vaqlm2anuBWNu4Dw/7OtrHstG4HNfl3c/jMfUPOAOxBezooZ1tlzd 72rCgK25LGXpJjcz2BlQpY3NQDww4EqFAZHPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gFDdq1m1Ve87inMPn2WMOo91xanoobuaz+wzkRoerRxbMWFWfybydtDSApoHInowZX idxoB8wTX7OrkSEmZ5J5NghEwlLUTewA58LYuErgkAXSUVksJ61Ldc/ZDz0u+uM8kXRy 5IUiv1BBgXmQQImYcimQBvp8itDe0AsjlRhTQ= MIME-Version: 1.0 Received: by 10.216.52.193 with SMTP id e43mr2280167wec.40.1308320679285; Fri, 17 Jun 2011 07:24:39 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Fri, 17 Jun 2011 07:24:39 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Fri, 17 Jun 2011 07:24:39 -0700 (PDT) In-Reply-To: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> Date: Fri, 17 Jun 2011 07:24:39 -0700 Message-ID: From: Cameron Byrne To: Mark Townsley Content-Type: multipart/alternative; boundary=0016e6dee70f57527f04a5e92512 X-Mailman-Approved-At: Sun, 19 Jun 2011 14:25:46 -0700 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 14:24:42 -0000 --0016e6dee70f57527f04a5e92512 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Jun 17, 2011 6:22 AM, "Mark Townsley" wrote: > > > Technically, this approach is naturally feasible as PPP was designed back when short-lived connectivity was commonplace. There is one crucial difference though in that you will be exercising PPP stacks in a way that i= s not common by tearing down and bringing up IPCP while not doing so with LCP= . According to all the RFCs this should work just fine, but my intuition is that some PPP stacks will be forced into new code paths that have never bee= n exercised in this manner with the expectation of it being the normal desire= d behavior. You can surely find a set of clients where this will work, but i= t probably will not across the entire gamut of deployed PPP today. > > Applications may not be all that forgiving to IPv4 coming and going either, e.g., I have a popular mail client that has recently taken to crashing when I switch from wired to wireless and get a different IP addres= s in the process. Some of the IM connections I keep up recover quickly to IP changes, others do not. The IETF has a whole WG (DNA) dedicated to this tricky behavior of an IP address coming and going - it's not always easy, i= n particular when the link-layer is not giving your IP stack any up/down notification, which I believe by definition is what your proposal requires from the very start. > > Finally, devices are moving towards a "cloud connected" mode of operation= . In IPv4, there is essentially no end-to-end reachability, so modern applications are moving toward persistent, long-lived, connections in order to achieve this. I suspect you'll see a noticeable uptick in reliance upon such persistent, long-lived, IPv4 connections as Apple's Lion and iOS 5 software is rolled out later this year. Both have integration of the free "iCloud" services, and have replaced the USB cord for device synchronizatio= n with a persistent network connection. It's not just Apple though, the same trend is forming across the industry. > I believe the motivation is to send a clear signal and path for cloud service providers that ipv6 is the only sustainable way forward. I support this work as legitimate technique to avoid or defer cgn. It is the cloud long lived sessions that pose the most challenge for cgn. I would love for this work to be the foundation for similar work in 3gpp. Granted, a testing effort is always required for any new approach. Cb > So, my fear is that by the time you have built TDM into IPv4 across your user base, it will have required at the very least a grand testing effort and at the same time your users may well have changed their behavior to mak= e it unworkable anyway. I as much as anyone would hope that all these new persistent connections would run over IPv6 if available, but that is of course the exception not the rule for the time being as well. > > - Mark > > > On Jun 14, 2011, at 6:45 PM, < K.Fleischhauer@telekom.de> wrote: > > > Hi folks, > > > > right in time before the next IETF in Quebec, we would like to come up again with our Internet Draft > > "On demand IPv4 address provisioning in Dual-Stack PPP deployment" > > in order to gather further feedback from the WG. > > During our presentation in Prague I got several remarks and questions > > and from my understanding there has been some interest in the approach we describe in this I-D. > > Regarding the questions I want to focus on the following two and will try to answer them once more: > > > > - Use case: > > In general we see this mechanism applicable for all Dual-Stack PPP network scenarios allthrough we focussed our presentation for illustrative reasons on routed gateways that may be provided by the Access Network provider. > > In principle as more IPv4 addresses can be saved, as more services are IPv6 enabled > > (especially those which require always-on connectivity (e.g. VoIP, mail= , update services)) . > > The PPP protocol has not to be changed in order to achieve the needed functionality - > > the described behaviour (of independently releasing and > > refreshing the IPv4 context within a Dual-Stack PPP session) > > is already inherently covered by the existing PPP spec and also mentioned as requirements for > > CPEs (see RFC 6204 - WLL-3). > > > > - Efficiency of the mechanism: > > In principle we assume (with ongoing IPv6 deployment) that it is possible to save > > after one year of roll-out of the described mechanism about 3%, > > after two years about 8%, > > and after three years up to 13% of the provisioned IPv4 addresses. > > After 8 years 70% of the IPv4 addresses can be "re-cycled" according to our model calculations. > > (You will find more details here: > > " http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&the= ma=3DEffizienzabsch=E4tzung " > > (please copy the whole text between the exclamation marks in the addres= s line of you browser).) > > > > > > We plan to come up with a 01 version of the I-D and would that's why like to gather more feedback from the WG regarding the possible open issues (e.g. what has to be described in more detail, ), unanswered questions or any other useful hints how to progress with this work/I-D. > > And of course we are also interested in your opinion if this work shoul= d be done within the Intarea WG or if other WGs (PPPEXT?) may be more appropriate. > > > > > > Thanks and kind regards > > > > KARSTEN Fleischhauer > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --0016e6dee70f57527f04a5e92512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 17, 2011 6:22 AM, "Mark Townsley" <mark@townsley.net> wrote:
>
>
> Technically, this approach is naturally feasible as PPP was designed b= ack when short-lived connectivity was commonplace. There is one crucial dif= ference though in that you will be exercising PPP stacks in a way that is n= ot common by tearing down and bringing up IPCP while not doing so with LCP.= According to all the RFCs this should work just fine, but my intuition is = that some PPP stacks will be forced into new code paths that have never bee= n exercised in this manner with the expectation of it being the normal desi= red behavior. =A0You can surely find a set of clients where this will work,= but it probably will not across the entire gamut of deployed PPP today. >
> Applications may not be all that forgiving to IPv4 coming and going ei= ther, e.g., I have a popular mail client that has recently taken to crashin= g when I switch from wired to wireless and get a different IP address in th= e process. Some of the IM connections I keep up recover quickly to IP chang= es, others do not. The IETF has a whole WG (DNA) dedicated to this tricky b= ehavior of an IP address coming and going - it's not always easy, in pa= rticular when the link-layer is not giving your IP stack any up/down notifi= cation, which I believe by definition is what your proposal requires from t= he very start.
>
> Finally, devices are moving towards a "cloud connected" mode= of operation. In IPv4, there is essentially no end-to-end reachability, so= modern applications are moving toward persistent, long-lived, connections = in order to achieve this. =A0I suspect you'll see a noticeable uptick i= n reliance upon such persistent, long-lived, IPv4 connections as Apple'= s Lion and iOS 5 software is rolled out later this year. Both have integrat= ion of the free "iCloud" services, and have replaced the USB cord= for device synchronization with a persistent network connection. It's = not just Apple though, the same trend is forming across the industry.
>

I believe the motivation is to send a clear signal and path for cloud se= rvice providers that ipv6 is the only sustainable way forward.=A0 I support= this work as legitimate technique to avoid or defer cgn.

It is the cloud long lived sessions that pose the most challenge for cgn= .

I would love for this work to be the foundation for similar work in 3gpp= .

Granted, a testing effort is always required for any new approach.

Cb

> So, my fear is that by the time you have built TDM into IPv4 across= your user base, it will have required at the very least a grand testing ef= fort and at the same time your users may well have changed their behavior t= o make it unworkable anyway. I as much as anyone would hope that all these = new persistent connections would run over IPv6 if available, but that is of= course the exception not the rule for the time being as well.
>
> - Mark
>
>
> On Jun 14, 2011, at 6:45 PM, <K.Fleischhauer@telekom.de> <K.Fleischhauer@telekom.de> wrote:
>
> > Hi folks,
> >
> > right in time before the next IETF in Quebec, we would like to co= me up again with our Internet Draft
> > "On demand IPv4 address provisioning in Dual-Stack PPP deplo= yment"
> > in order to gather further feedback from the WG.
> > During our presentation in Prague I got several remarks and quest= ions
> > and from my understanding there has been some interest in the app= roach we describe in this I-D.
> > Regarding the questions I want to focus on the following two and = will try to answer them once more:
> >
> > - Use case:
> > In general we see this mechanism applicable for all Dual-Stack PP= P network scenarios allthrough we focussed our presentation for illustrativ= e reasons on routed gateways that may be provided by the Access Network pro= vider.
> > In principle as more IPv4 addresses can be saved, as more service= s are IPv6 enabled
> > (especially those which require always-on connectivity (e.g. VoIP= , mail, update services)) .
> > The PPP protocol has not to be changed in order to achieve the ne= eded functionality -
> > the described behaviour (of independently releasing and
> > refreshing the IPv4 context within a Dual-Stack PPP session)
> > is already inherently covered by the existing PPP spec and also m= entioned as requirements for
> > CPEs (see RFC 6204 - WLL-3).
> >
> > - Efficiency of the mechanism:
> > In principle we assume (with ongoing IPv6 deployment) that it is = possible to save
> > after one year of roll-out of the described mechanism about 3%, > > after two years about 8%,
> > and after three years up to 13% of the provisioned IPv4 addresses= .
> > After 8 years 70% of the IPv4 addresses can be "re-cycled&qu= ot; according to our model calculations.
> > (You will find more details here:
> > "http://w= ww.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&the= ma=3DEffizienzabsch=E4tzung"
> > (please copy the whole text between the exclamation marks in the = address line of you browser).)
> >
> >
> > We plan to come up with a 01 version of the I-D and would that= 9;s why like to gather more feedback from the WG regarding the possible ope= n issues (e.g. what has to be described in more detail, ), unanswered quest= ions or any other useful hints how to progress with this work/I-D.
> > And of course we are also interested in your opinion if this work= should be done within the Intarea WG or if other WGs (PPPEXT?) may be more= appropriate.
> >
> >
> > Thanks and kind regards
> >
> > KARSTEN Fleischhauer
> > _______________________________________________
> > Int-area mailing list
> > Int-area@ietf.org
> > https:= //www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www= .ietf.org/mailman/listinfo/int-area

--0016e6dee70f57527f04a5e92512-- From dthaler@microsoft.com Fri Jun 17 10:04:40 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05999E8007; Fri, 17 Jun 2011 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9MT-GBihkJX; Fri, 17 Jun 2011 10:04:40 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 43B2E9E8005; Fri, 17 Jun 2011 10:04:40 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 17 Jun 2011 10:04:40 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 17 Jun 2011 10:04:39 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.165]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Fri, 17 Jun 2011 10:04:39 -0700 From: Dave Thaler To: Mark Townsley , "K.Fleischhauer@telekom.de" Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AQHMLPGivtoY85X6EUKujJJYVGTXOZTBxJ+A Date: Fri, 17 Jun 2011 17:04:39 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> In-Reply-To: <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 19 Jun 2011 14:25:46 -0700 Cc: "pppext@ietf.org" , "int-area@ietf.org" Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:04:40 -0000 Mark Townsley wrote: [...] > Applications may not be all that forgiving to IPv4 coming and going eithe= r, e.g., > I have a popular mail client that has recently taken to crashing when I s= witch > from wired to wireless and get a different IP address in the process. Som= e of > the IM connections I keep up recover quickly to IP changes, others do not= . The > IETF has a whole WG (DNA) dedicated to this tricky behavior of an IP addr= ess > coming and going - it's not always easy, in particular when the link-laye= r is not > giving your IP stack any up/down notification, which I believe by definit= ion is > what your proposal requires from the very start. [...] I'll second the above. This is very problematic for some applications. (Other solutions like DSTM that have on-demand IP addresses have this same = issue.) So any network that deploys such a solution in anything other than=20 a tightly controlled environment where directly connected nodes are restric= ted to a specific set of pre-tested applications, will likely result in many su= pport calls. -Dave From cb.list6@gmail.com Fri Jun 17 10:17:10 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CD921F8542; Fri, 17 Jun 2011 10:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3aribSTuEuQ; Fri, 17 Jun 2011 10:17:09 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0854921F8538; Fri, 17 Jun 2011 10:17:08 -0700 (PDT) Received: by wyb29 with SMTP id 29so2186809wyb.31 for ; Fri, 17 Jun 2011 10:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bn/gk4qc+BD9ZYIUs/1OJ9miIu+CjrPnPHJpT6lTYI0=; b=nee9ePQLH0Ou069uxAgHJtwR/x6lgcs44I2CkXt0bwxTZIstAvCjaWW6cQ3cvwQlKJ PbfhVF3Kh1j4Us2ubAKvSSaRE8hKOZlAXYCM30DnYI5KY//9zHVxn/xvVlpDU++6qAbC TeJzNzik9KYcFDdy3bkVXMFXKCxcdOnnHBr4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mFinJa5G9KiqnVpGZUaiznawpxNLEaIdtVLy2E+HorxGMezafqTrnKK5IQqAZ6MsJA COdcORF1rKFnK5f1Th6Py4u5wkhJmxxHikCL6a0JoqK7ugSzE1K7Yl58lrVura5rjiKJ 5OIeEdZ26bkP6t7D7I65QOpl+kswNjUsb6rq0= MIME-Version: 1.0 Received: by 10.217.6.197 with SMTP id y47mr2408192wes.55.1308331028018; Fri, 17 Jun 2011 10:17:08 -0700 (PDT) Received: by 10.216.165.82 with HTTP; Fri, 17 Jun 2011 10:17:07 -0700 (PDT) In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com> <03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net> <9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 17 Jun 2011 10:17:07 -0700 Message-ID: From: Cameron Byrne To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 19 Jun 2011 14:25:46 -0700 Cc: "pppext@ietf.org" , "int-area@ietf.org" Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:17:10 -0000 On Fri, Jun 17, 2011 at 10:04 AM, Dave Thaler wrote= : > Mark Townsley wrote: > [...] >> Applications may not be all that forgiving to IPv4 coming and going eith= er, e.g., >> I have a popular mail client that has recently taken to crashing when I = switch >> from wired to wireless and get a different IP address in the process. So= me of >> the IM connections I keep up recover quickly to IP changes, others do no= t. The >> IETF has a whole WG (DNA) dedicated to this tricky behavior of an IP add= ress >> coming and going - it's not always easy, in particular when the link-lay= er is not >> giving your IP stack any up/down notification, which I believe by defini= tion is >> what your proposal requires from the very start. > [...] > > I'll second the above. =A0 This is very problematic for some applications= . > (Other solutions like DSTM that have on-demand IP addresses have this sam= e issue.) > > So any network that deploys such a solution in anything other than > a tightly controlled environment where directly connected nodes are restr= icted > to a specific set of pre-tested applications, will likely result in many = support calls. > Is this really different from the dial-on-demand routing that has existed for years and still exist as common backup connectivity technique? I assume that this would be implemented on an Home Gateway which provides consistent addressing to IPv4 hosts within the home, and dial-on-demand type mechanism request the IPv4 address to the home gateway to do NAT44 in the event of an IPv4 stream arrives. Cameron From jshire@hyduke.com Fri Jun 17 10:31:30 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A5911E807B; Fri, 17 Jun 2011 10:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogngu-WZC5d5; Fri, 17 Jun 2011 10:31:29 -0700 (PDT) Received: from mail.hyduke.net (mail.hyduke.net [67.226.164.185]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09111E8071; Fri, 17 Jun 2011 10:31:29 -0700 (PDT) Received: from HYDSRV6.hyduke.net (192.168.10.44) by nsk1mx02.hyduke.net (192.168.10.49) with Microsoft SMTP Server id 8.1.436.0; Fri, 17 Jun 2011 11:26:30 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Class: urn:content-classes:message Date: Fri, 17 Jun 2011 11:31:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <5D359AE112816C46AE85C0494190F973027FCF92@hydsrv6.hyduke.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwtEmd4PNcU6b92RuKvm2cDC6jKKwAAZfcg References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com><03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net><9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> From: Joshua Shire To: "Cameron Byrne" , "Dave Thaler" X-TM-AS-Product-Ver: SMEX-8.0.0.4125-6.500.1024-18204.004 X-TM-AS-Result: No--18.339600-4.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Mailman-Approved-At: Sun, 19 Jun 2011 14:25:46 -0700 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:31:30 -0000 I'll second this. Most of the new SMB level gateway devices we're seeing = on the market support some type of USB connected 3G/HSPA dial-on demand = system as a backup link. We've implemented it quite extensively with = little to no problems. Josh -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On = Behalf Of Cameron Byrne Sent: Friday, June 17, 2011 11:17 AM To: Dave Thaler Cc: pppext@ietf.org; int-area@ietf.org Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 = address provisioning in Dual-Stack PPP deployment" - Topic for WG? On Fri, Jun 17, 2011 at 10:04 AM, Dave Thaler = wrote: > Mark Townsley wrote: > [...] >> Applications may not be all that forgiving to IPv4 coming and going = either, e.g., >> I have a popular mail client that has recently taken to crashing when = I switch >> from wired to wireless and get a different IP address in the process. = Some of >> the IM connections I keep up recover quickly to IP changes, others do = not. The >> IETF has a whole WG (DNA) dedicated to this tricky behavior of an IP = address >> coming and going - it's not always easy, in particular when the = link-layer is not >> giving your IP stack any up/down notification, which I believe by = definition is >> what your proposal requires from the very start. > [...] > > I'll second the above. =A0 This is very problematic for some = applications. > (Other solutions like DSTM that have on-demand IP addresses have this = same issue.) > > So any network that deploys such a solution in anything other than > a tightly controlled environment where directly connected nodes are = restricted > to a specific set of pre-tested applications, will likely result in = many support calls. > Is this really different from the dial-on-demand routing that has existed for years and still exist as common backup connectivity technique? I assume that this would be implemented on an Home Gateway which provides consistent addressing to IPv4 hosts within the home, and dial-on-demand type mechanism request the IPv4 address to the home gateway to do NAT44 in the event of an IPv4 stream arrives. Cameron _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From dthaler@microsoft.com Fri Jun 17 12:00:44 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170C79E805C; Fri, 17 Jun 2011 12:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRtDe9lU7QX4; Fri, 17 Jun 2011 12:00:43 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3FC9E808C; Fri, 17 Jun 2011 12:00:29 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 17 Jun 2011 12:00:29 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 17 Jun 2011 12:00:28 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.165]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Fri, 17 Jun 2011 12:00:28 -0700 From: Dave Thaler To: Joshua Shire , Cameron Byrne Thread-Topic: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AQHMLRJl9qcFCAZHV0a5gvbXuIaqHpTCQ/mA//+jTkA= Date: Fri, 17 Jun 2011 19:00:28 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B10F936@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08AD4AB8F3@HE111648.emea1.cds.t-internal.com><03348BD8-3004-4DE2-978A-0952765B5F86@townsley.net><9B57C850BB53634CACEC56EF4853FF653B10EE86@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <5D359AE112816C46AE85C0494190F973027FCF92@hydsrv6.hyduke.net> In-Reply-To: <5D359AE112816C46AE85C0494190F973027FCF92@hydsrv6.hyduke.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 19 Jun 2011 14:25:46 -0700 Cc: "pppext@ietf.org" , "int-area@ietf.org" Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 19:00:44 -0000 Requiring the CPE to be a gateway rather than a host running arbitrary appl= ications is one way to restrict directly connected nodes to a specific set of pre-te= sted applications. -Dave > -----Original Message----- > From: Joshua Shire [mailto:jshire@hyduke.com] > Sent: Friday, June 17, 2011 10:31 AM > To: Cameron Byrne; Dave Thaler > Cc: pppext@ietf.org; int-area@ietf.org > Subject: RE: [Int-area] IETF80 questions regarding "On demand IPv4 addres= s > provisioning in Dual-Stack PPP deployment" - Topic for WG? >=20 > I'll second this. Most of the new SMB level gateway devices we're seeing = on the > market support some type of USB connected 3G/HSPA dial-on demand system > as a backup link. We've implemented it quite extensively with little to n= o > problems. >=20 > Josh >=20 > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Beh= alf > Of Cameron Byrne > Sent: Friday, June 17, 2011 11:17 AM > To: Dave Thaler > Cc: pppext@ietf.org; int-area@ietf.org > Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 addres= s > provisioning in Dual-Stack PPP deployment" - Topic for WG? >=20 > On Fri, Jun 17, 2011 at 10:04 AM, Dave Thaler > wrote: > > Mark Townsley wrote: > > [...] > >> Applications may not be all that forgiving to IPv4 coming and going > >> either, e.g., I have a popular mail client that has recently taken to > >> crashing when I switch from wired to wireless and get a different IP > >> address in the process. Some of the IM connections I keep up recover > >> quickly to IP changes, others do not. The IETF has a whole WG (DNA) > >> dedicated to this tricky behavior of an IP address coming and going - > >> it's not always easy, in particular when the link-layer is not giving > >> your IP stack any up/down notification, which I believe by definition = is what > your proposal requires from the very start. > > [...] > > > > I'll second the above. =A0 This is very problematic for some applicatio= ns. > > (Other solutions like DSTM that have on-demand IP addresses have this > > same issue.) > > > > So any network that deploys such a solution in anything other than a > > tightly controlled environment where directly connected nodes are > > restricted to a specific set of pre-tested applications, will likely re= sult in many > support calls. > > >=20 > Is this really different from the dial-on-demand routing that has existed= for > years and still exist as common backup connectivity technique? >=20 > I assume that this would be implemented on an Home Gateway which provides > consistent addressing to IPv4 hosts within the home, and dial-on-demand t= ype > mechanism request the IPv4 address to the home gateway to do NAT44 in the > event of an IPv4 stream arrives. >=20 >=20 > Cameron > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From Olaf.Bonness@telekom.de Mon Jun 20 00:56:54 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CA611E8114; Mon, 20 Jun 2011 00:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROpE1BLqQtyA; Mon, 20 Jun 2011 00:56:53 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6511E80F9; Mon, 20 Jun 2011 00:56:51 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 20 Jun 2011 09:56:36 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.158]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Mon, 20 Jun 2011 09:56:36 +0200 From: To: , Date: Mon, 20 Jun 2011 09:56:34 +0200 Thread-Topic: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? Thread-Index: AcwumAHgi1pRnzWpQOKcZAsIRuAf9QAgzzKA Message-ID: References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C2A@HE111648.emea1.cds.t-internal.com> <201106191545.p5JFjlWL042969@calcite.rhyolite.com> In-Reply-To: <201106191545.p5JFjlWL042969@calcite.rhyolite.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pppext@ietf.org, int-area@ietf.org Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG? X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 07:56:54 -0000 Hi folks, please find my comments inline. Kind regards Olaf > Im Auftrag von Vernon Schryver > Gesendet: Sonntag, 19. Juni 2011 17:46 > An: Fleischhauer, Karsten ... (Some lines deleted) > > > My guess is that the topic is something about PPP peers > killing their > > > IPCP state machines after IP inactivity (presumably ignoring LCP > > > activity as well as other activity such as bridging) and then > > > restarting > > > IPCP on new activity to negotiate potentially new IPv4 addresses. > > > > KF: You are right. > > That seems to contradict the later statement that the new IPCP idle > timer would have the same value as existing LCP idle timers. As far as I understand it Karsten tries to say the following: The IPCP session is released after an timeout interval that is comparable t= o the timeout used in _todays_ LCP implementations. (Thats why this IPCP r= elease will show the same effects to the IPv4 part of the user as todays PP= P release.) The LCP timeout is assumed to be longer and the LCP is usually kept alive b= ecause of the IPCPv6 or bridging or whatever. ... > In that case, I wonder if I understand what is being proposed I think > that LCP idle timers are generally reset by IP traffic. So > an additional > explicit IPCP idle timer would not be needed. See > http://www.google.com/search?q=3Dlcp+idle+timer Hopefully my 3 sentenses above answer this. (BTW it is IMHO not very useful to post Google search requests here. I woul= d prefer to have a real link to a dedicated source in order to find the rig= ht reference and to make sure that I do understand your point.) > > > - How often is IPCP used today to allocate IP addresses? Isn't DHC= P > > > often used even over PPP, especially for the consumer grade Amazingly often PPP is used for that within legacy networks especially if y= ou do not _want_ to implement / run DHCP because of several reasons. > > We are addressing here PPP and IPCP. > > I think it is best to consider to entire systems. A PPP mechanism > that would almost never be used because other standardized mechanism > are and will be used to provide its facilities is inadmissable to a > reasonable official standards process. The proposed mechanism in this I-D is described for scenarios where IPCP i= s used for IPv4 address provisioning in Dual-Stack PPP sessions. The idea i= tself may easily be extended to DHCP based scenarios, 3G and 4G networks - = but this is not part of the mentioned I-D. > It sounds as if the proposal is a recommendation that Internet services > provides who lack IPv4 addresses configure things so that: > - IPv4 addresses are not statically assigned on PPP links, > - dynamic IPCP IPv4 address assignments do not endure PPP resets, > especially those triggered by LCP idle timers, > - DHCP lease times be shortened > - the de facto standard DHCP features that try to give returning > users the same IPv4 addresses be turned off Where did you read these remarks regarding DHCP? > In any case I would see this in an additional ID and not in > PPPEXT or INTAREA. Hmmm additional I-D. Do you mean informational or individual? Or where is "= additional" > Since no point-to-point protocol changes are being proposed > and contents of an ID would be obvious operational advice, I don't see a = PPP RFC. > Perhaps an informational RFC could be justified. It would be better > than some informational I-Ds involving vendor-specific IPCP options. O.k. you are voting for informational. > I do not see an answer to my question about how this proposal compares > with schemes such as LSN or CGN. See > http://www.google.com/search?q=3DIPv4+cgn+OR+lsn > Perhaps your informational I-D could say something about that. Just another nice google search list :). Couly you be more specific what you mean with "compares"? Do you mean compa= rability in terms of efficiency? Regards Olaf > See also > http://www.google.com/search?q=3Dietf+IPv4+address+shortage+bcp > and even > http://www.google.com/search?q=3Dietf+IPv4+address+shortage+ppp :) > > As indended status of the ID we proposed in the version 00 > "Informational". > > I thought informational RFCs do not depend on the let, leave, or > hindrance of IETF working groups. > > > Vernon Schryver vjs@rhyolite.com > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext >