From d3e3e3@gmail.com Mon Jan 3 09:25:39 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BA53A6935 for ; Mon, 3 Jan 2011 09:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.233 X-Spam-Level: X-Spam-Status: No, score=-103.233 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XZqPH2iGpd2 for ; Mon, 3 Jan 2011 09:25:38 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E45823A67C0 for ; Mon, 3 Jan 2011 09:25:34 -0800 (PST) Received: by wyf23 with SMTP id 23so14061160wyf.31 for ; Mon, 03 Jan 2011 09:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=k0KEPUIUTk4LuN6oz+txwo4SJzp8d1JVEgepLxzBlHc=; b=CHLixiIwsxfh8QUD44SKZPOe+i6fTfQ+TLsRAsfm4WKUe27HkEMT2fTNej9WbjsDbg 2YzihZ3QTjWqbAhhTT+4VR4iNGTTw+theyGV2XrZmyXrYWZoUNt9fKuyomzlD+JNNrxn G51Gl1ydvpYI37YSHXTU8XO5JvbXqiiS/u5YI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; b=IJC4yRMf/9IzHiQgxEnuvLQzvVBfbVn4aMAz1Lc0EWMapgL06icg0YAxK5wGkGMuA9 +C/yicEOCnxRkOM0OjkHQ2vvQNTbM5A9vUI4ngUtDOwBR1QZV6VgKN1WcmTlErZHmYsZ Xoy2LNPo1GX/+LBhiCvjJDv2o4L0zf21et99c= Received: by 10.227.201.5 with SMTP id ey5mr11646875wbb.182.1294075661322; Mon, 03 Jan 2011 09:27:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Mon, 3 Jan 2011 09:27:20 -0800 (PST) From: Donald Eastlake Date: Mon, 3 Jan 2011 12:27:20 -0500 Message-ID: To: pppext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , Radia Perlman Subject: [Pppext] Comment related to draft-ietf-pppext-trill-protocol-01.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 17:25:39 -0000 Hi, I've received a comment about the last figure in Section 2.3 of draft-ietf-trill-rbridge-protocol-16.txt. This figure shows a very high level generic view of a TRILL Data frame being sent over PPP. However, there is a possible problem with that figure. The general form of a TRILL Data frame is Link Header TRILL Header Encapsulated data frame in Ethernet format Link Trailer If the link is Ethernet, the Link Header is an Ethernet Header (destination MAC, source MAC, possible VLAN tag, Ethertype) and the Link Trailer is an Ethernet Trailer, that is, an FCS covering the entire frame. If the link is PPP, then we should have a PPP Header, which is fine and is shown in the figure, but is there a "PPP Trailer"? The figure shows an "Ethernet FCS" which may be wrongly labeled. If there is an FCS there, calculated as Ethernet does, how much of the frame does it cover? In particular, does it cover the PPP Header, in which case I think it should be labeled "PPP FCS"? Or should the convention in PPP be to have an FCS just covering the encapsulated Ethernet frame? In any case, I think a few words about this are needed in the pppext-trill draft... 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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From carlsonj@workingcode.com Mon Jan 3 10:26:17 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649D53A6A67 for ; Mon, 3 Jan 2011 10:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.745 X-Spam-Level: X-Spam-Status: No, score=-100.745 tagged_above=-999 required=5 tests=[AWL=1.854, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awwkUIJDmOXY for ; Mon, 3 Jan 2011 10:26:16 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 6F83E3A6A66 for ; Mon, 3 Jan 2011 10:26:16 -0800 (PST) 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 p03IS8UB022272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 13:28:09 -0500 (EST) Message-ID: <4D221538.4000004@workingcode.com> Date: Mon, 03 Jan 2011 13:28:08 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Donald Eastlake References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, Erik Nordmark , Radia Perlman Subject: Re: [Pppext] Comment related to draft-ietf-pppext-trill-protocol-01.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 18:26:17 -0000 Donald Eastlake wrote: > If the link is PPP, then we should have a PPP Header, which is fine > and is shown in the figure, but is there a "PPP Trailer"? It depends on the underlying link type and options (e.g., RFC 1570), but the short answer is "yes." > The figure > shows an "Ethernet FCS" which may be wrongly labeled. If there is an > FCS there, calculated as Ethernet does, how much of the frame does it > cover? The standard PPP FCS covers the entire frame, including any HDLC and PPP headers and user data, but without the medium-dependent bit or octet stuffing. See RFC 1662 for details. Yes, it covers the same things the Ethernet FCS does. > In particular, does it cover the PPP Header, in which case I > think it should be labeled "PPP FCS"? Or should the convention in PPP > be to have an FCS just covering the encapsulated Ethernet frame? > > In any case, I think a few words about this are needed in the > pppext-trill draft... We don't normally do that for PPP documents -- it's assumed that the NCP document just covers the bits that are particular to that NCP, and not all of the common PPP bits all the way down to the bare metal -- but I guess I can do that if it'll help with alignment with the other TRILL documents. (For what it's worth, I don't think the TRILL document should mention the Ethernet FCS, either. TRILL isn't defining Ethernet encapsulation, and including those bits seems like duplication. But I suppose that's just me ...) -- James Carlson 42.703N 71.076W From d3e3e3@gmail.com Mon Jan 3 10:55:25 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FF83A6AA5 for ; Mon, 3 Jan 2011 10:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.246 X-Spam-Level: X-Spam-Status: No, score=-103.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ILaXAwnqoxp for ; Mon, 3 Jan 2011 10:55:24 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 523823A6AA4 for ; Mon, 3 Jan 2011 10:55:24 -0800 (PST) Received: by wwa36 with SMTP id 36so13649734wwa.13 for ; Mon, 03 Jan 2011 10:57:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Z0SBNGPMs1ahCXwgeNqZPE1Q/lJH+v5mDgjRxrVKxYw=; b=rdc6EEW3CrihfOM/+t3QcNZK7WZScSjofmSDUUGD/PIXZEJ5J5bj/3gidc5lv7IMVe BQqkwZvDiXBO4dS1BhYLoH9IUrrr74uCo/ff+egGXaRJPMMtRwMPb/q3iG1EaKvHm5uG bcbGAqVbEvVC6u3Vr5TPt/YwzquyWfpwcp8OQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=cmshgd2fiCrpVbU+aUQp3hh5iz1xG4AxP5F59Wy47hxQ4bxKFOBTv2ERTZkUMt3DdQ wZ6cQeueh7Wg8GuD+2RCUrFKtxW2WA4xKdQTYmLbkADSrhHQHkFi6FyfrQwywd4wXidJ U4mj4yd6NVdO1uXTl6/7vfiS6XTSoVp/fV/Bw= Received: by 10.227.197.131 with SMTP id ek3mr11691970wbb.211.1294081050888; Mon, 03 Jan 2011 10:57:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Mon, 3 Jan 2011 10:57:10 -0800 (PST) In-Reply-To: <4D221538.4000004@workingcode.com> References: <4D221538.4000004@workingcode.com> From: Donald Eastlake Date: Mon, 3 Jan 2011 13:57:10 -0500 Message-ID: To: James Carlson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org, Erik Nordmark , Radia Perlman Subject: Re: [Pppext] Comment related to draft-ietf-pppext-trill-protocol-01.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 18:55:25 -0000 Hi James, On Mon, Jan 3, 2011 at 1:28 PM, James Carlson wr= ote: > Donald Eastlake wrote: >> If the link is PPP, then we should have a PPP Header, which is fine >> and is shown in the figure, but is there a "PPP Trailer"? > > It depends on the underlying link type and options (e.g., RFC 1570), but > the short answer is "yes." > >> The figure >> shows an "Ethernet FCS" which may be wrongly labeled. If there is an >> FCS there, calculated as Ethernet does, how much of the frame does it >> cover? > > The standard PPP FCS covers the entire frame, including any HDLC and PPP > headers and user data, but without the medium-dependent bit or octet > stuffing. =A0See RFC 1662 for details. > > Yes, it covers the same things the Ethernet FCS does. Ok. Then it should be labeled PPP FCS in that figure as an editorial correc= tion. >> In particular, does it cover the PPP Header, in which case I >> think it should be labeled "PPP FCS"? Or should the convention in PPP >> be to have an FCS just covering the encapsulated Ethernet frame? >> >> In any case, I think a few words about this are needed in the >> pppext-trill draft... > > We don't normally do that for PPP documents -- it's assumed that the NCP > document just covers the bits that are particular to that NCP, and not > all of the common PPP bits all the way down to the bare metal -- but I > guess I can do that if it'll help with alignment with the other TRILL > documents. Well, I would assume the RFC resulting from draft-ietf-pppext-trill-protocol will in some cases be read by people familiar with TRILL but not familiar with PPP. So, while it certainly doesn't need much, making it clear that there is no Ethernet FCS in the encapsulated material and having references pointing at the PPP Trailer info seem like a good idea to me. > (For what it's worth, I don't think the TRILL document should mention > the Ethernet FCS, either. =A0TRILL isn't defining Ethernet encapsulation, > and including those bits seems like duplication. =A0But I suppose that's > just me ...) More than once I've gotten specific questions about whether or not the "encapsulated Ethernet frame" inside a TRILL Data frame includes an Ethernet FCS just covering the encapsulated material. So I think it is better that this sort of thing be mentioned. > -- > James Carlson =A0 =A0 =A0 =A0 42.703N 71.076W =A0 =A0 =A0 =A0 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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From carlsonj@workingcode.com Mon Jan 3 11:19:24 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084A93A6B00 for ; Mon, 3 Jan 2011 11:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.672 X-Spam-Level: X-Spam-Status: No, score=-101.672 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUIgEXp0KeYY for ; Mon, 3 Jan 2011 11:19:23 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id E40493A6B01 for ; Mon, 3 Jan 2011 11:19:22 -0800 (PST) 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 p03JLO20023506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Jan 2011 14:21:25 -0500 (EST) Message-ID: <4D2221B4.3020504@workingcode.com> Date: Mon, 03 Jan 2011 14:21:24 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Donald Eastlake References: <4D221538.4000004@workingcode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, Erik Nordmark , Radia Perlman Subject: Re: [Pppext] Comment related to draft-ietf-pppext-trill-protocol-01.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 19:19:24 -0000 Donald Eastlake wrote: >>> In particular, does it cover the PPP Header, in which case I >>> think it should be labeled "PPP FCS"? Or should the convention in PPP >>> be to have an FCS just covering the encapsulated Ethernet frame? >>> >>> In any case, I think a few words about this are needed in the >>> pppext-trill draft... >> We don't normally do that for PPP documents -- it's assumed that the NCP >> document just covers the bits that are particular to that NCP, and not >> all of the common PPP bits all the way down to the bare metal -- but I >> guess I can do that if it'll help with alignment with the other TRILL >> documents. > > Well, I would assume the RFC resulting from > draft-ietf-pppext-trill-protocol will in some cases be read by people > familiar with TRILL but not familiar with PPP. So, while it certainly > doesn't need much, making it clear that there is no Ethernet FCS in > the encapsulated material and having references pointing at the PPP > Trailer info seem like a good idea to me. I've made the updates for both -- making it clear that the Ethernet FCS is not present and that the PPP FCS (if any) is used. I'll send you a draft to look over. (I think that if they're reading this and don't know much about PPP, I think they're probably in a world of hurt. Or at least their customers are going to be. I'm not about to turn this simple draft into a road map for implementation of PPP.) >> (For what it's worth, I don't think the TRILL document should mention >> the Ethernet FCS, either. TRILL isn't defining Ethernet encapsulation, >> and including those bits seems like duplication. But I suppose that's >> just me ...) > > More than once I've gotten specific questions about whether or not the > "encapsulated Ethernet frame" inside a TRILL Data frame includes an > Ethernet FCS just covering the encapsulated material. So I think it is > better that this sort of thing be mentioned. Same planet, different universes, I guess. ;-} -- James Carlson 42.703N 71.076W From Internet-Drafts@ietf.org Thu Jan 6 07:45:04 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087453A6E1A; Thu, 6 Jan 2011 07:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkuCwSMgsluR; Thu, 6 Jan 2011 07:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C957F3A67D4; Thu, 6 Jan 2011 07:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110106154501.15655.20204.idtracker@localhost> Date: Thu, 06 Jan 2011 07:45:01 -0800 Cc: pppext@ietf.org Subject: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-02.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:45:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP TRILL Protocol Control Protocol Author(s) : J. Carlson Filename : draft-ietf-pppext-trill-protocol-02.txt Pages : 6 Date : 2011-01-06 The Point-to-Point Protocol (PPP) [1] 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 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-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pppext-trill-protocol-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-06073619.I-D@ietf.org> --NextPart-- From carlsonj@workingcode.com Sun Jan 16 11:20:42 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC053A6DB6 for ; Sun, 16 Jan 2011 11:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdBm4D-oiWgq for ; Sun, 16 Jan 2011 11:20:39 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 011713A6E04 for ; Sun, 16 Jan 2011 11:20:38 -0800 (PST) Received: from [192.168.254.211] (dhcp-211 [192.168.254.211]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p0GJN89B025282 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 16 Jan 2011 14:23:08 -0500 (EST) Message-ID: <4D334595.3030507@workingcode.com> Date: Sun, 16 Jan 2011 14:23:01 -0500 From: James Carlson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org References: <20110106154501.15655.20204.idtracker@localhost> In-Reply-To: <20110106154501.15655.20204.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-SIHOPE-DCC-3-Metrics: carlson; whitelist Cc: "rbridge@postel.org" Subject: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 19:20:42 -0000 On 1/6/2011 10:45 AM, Internet-Drafts@ietf.org wrote: > Title : PPP TRILL Protocol Control Protocol > Author(s) : J. Carlson > Filename : draft-ietf-pppext-trill-protocol-02.txt > Pages : 6 > Date : 2011-01-06 > > The Point-to-Point Protocol (PPP) [1] 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 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-02.txt I'm starting a working group last-call comment period for this draft. The new version incorporates changes for all of the comments received up to this point. Last call will run for two weeks. Please submit any comments, questions, or concerns you might have to me or to the pppext@ietf.org mailing list (or both) on or before Sunday, January 30th, 2011. -- James Carlson 42.703N 71.076W From d3e3e3@gmail.com Fri Jan 21 18:35:34 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B993A68A0 for ; Fri, 21 Jan 2011 18:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.407 X-Spam-Level: X-Spam-Status: No, score=-103.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRO6wp3O0EK4 for ; Fri, 21 Jan 2011 18:35:32 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 71FCD3A6896 for ; Fri, 21 Jan 2011 18:35:32 -0800 (PST) Received: by wwa36 with SMTP id 36so2976677wwa.13 for ; Fri, 21 Jan 2011 18:38:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=BHFWhgfZQvsq5GM8sVf7u0obNp1BIPFc27NsYYsJsZQ=; b=V/A1ZMBsRTvPyDRfP84v1fsQaHrnC+f5zdYJ0JSJXPGn2M5WyZQxUnRopHZIZdmmaY RAqW9LNVkBnEm9KhvsFzYYkNcyTG+O5HNRhz+ZDncAharzJoxBf/YpXK3ATTe05TG7wN ZNIXBPb50H3DvVLpmqdfzN5Bd082bDOQYzj00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=PlnbDL/ALKN2KXJCEMB13ZYEgj6a8/RcLJkfBMTuyU7N/whrgSZXizZoBsACZ4V2T9 C1egcdJWNBf60LRcrVZDFEO9vZPD3YnkjKX2BdQ8iBaePyxaONy02Okl5C0dyVpFtpt/ dVj42L9zDS95duz5O1zkTtmpjn3J1CZdJCwB8= Received: by 10.227.201.5 with SMTP id ey5mr1610464wbb.182.1295663897787; Fri, 21 Jan 2011 18:38:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Fri, 21 Jan 2011 18:37:57 -0800 (PST) In-Reply-To: <4D334595.3030507@workingcode.com> References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> From: Donald Eastlake Date: Fri, 21 Jan 2011 21:37:57 -0500 Message-ID: To: James Carlson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 02:35:34 -0000 I have reviewed this draft and believe it should be advanced as a proposed standard but I suggest the following minor tweaks: I believe references are not allowed in an Abstract so you may have to explicitly say "RFC 1661" if necessary, or perhaps this reference can just be moved to the first occurrence of PPP in the body. Section 2.3, in the first sentence, for clarify suggest changing "the IS-IS Payload" with "the IS-IS Payload, starting with the IS-IS Network Layer Protocol Identifier byte (0x83)," 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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Sun, Jan 16, 2011 at 2:23 PM, James Carlson w= rote: > On 1/6/2011 10:45 AM, Internet-Drafts@ietf.org wrote: >> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : PPP TRILL Protocol Control Proto= col >> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : J. Carlson >> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-pppext-trill-protocol-0= 2.txt >> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 6 >> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-01-06 >> >> The Point-to-Point Protocol (PPP) [1] defines a Link Control Protocol >> (LCP) and a method for negotiating the use of multi-protocol traffic >> over point-to-point links. =A0This document describes 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-02.= txt > > I'm starting a working group last-call comment period for this draft. > The new version incorporates changes for all of the comments received up > to this point. > > Last call will run for two weeks. =A0Please submit any comments, > questions, or concerns you might have to me or to the pppext@ietf.org > mailing list (or both) on or before Sunday, January 30th, 2011. > > -- > James Carlson =A0 =A0 =A0 =A0 42.703N 71.076W =A0 =A0 =A0 =A0 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From carlsonj@workingcode.com Sat Jan 22 06:20:37 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221C93A694D for ; Sat, 22 Jan 2011 06:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj7giSl-JQcu for ; Sat, 22 Jan 2011 06:20:35 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id A17373A6949 for ; Sat, 22 Jan 2011 06:20:35 -0800 (PST) Received: from dhcp-226.workingcode.com (dhcp-226 [192.168.254.226]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p0MENK5i024030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 22 Jan 2011 09:23:20 -0500 (EST) Message-ID: <4D3AE858.7070800@workingcode.com> Date: Sat, 22 Jan 2011 09:23:20 -0500 From: James Carlson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Donald Eastlake References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 14:20:37 -0000 On 1/21/11 9:37 PM, Donald Eastlake wrote: > I have reviewed this draft and believe it should be advanced as a > proposed standard but I suggest the following minor tweaks: > > I believe references are not allowed in an Abstract so you may have to > explicitly say "RFC 1661" if necessary, or perhaps this reference can > just be moved to the first occurrence of PPP in the body. > > Section 2.3, in the first sentence, for clarify suggest changing "the > IS-IS Payload" with "the IS-IS Payload, starting with the IS-IS > Network Layer Protocol Identifier byte (0x83)," Both changes sound good to me; thanks! -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Mon Jan 24 08:48:18 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282733A6AE4 for ; Mon, 24 Jan 2011 08:48:18 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9DhAuOUA8ZQ for ; Mon, 24 Jan 2011 08:48:17 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 4C3043A6863 for ; Mon, 24 Jan 2011 08:48:15 -0800 (PST) Received: by gxk27 with SMTP id 27so1580763gxk.31 for ; Mon, 24 Jan 2011 08:51:10 -0800 (PST) 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=1/kTbZbwhVbOsa2lZT+imr3vYKxPp/Ft85svahUWR24=; b=QA2c+oV8gd1SKKI5yJCMvzjEPah0ORGEztiUIJWq5xYl5yST5py+12LDq06ryhUc6g e0nDXTzuDhPV25yUAfsnssjQUFockVXIrL6vuZhD77YfX+zUlNd2gXqBtCATe1oSvSy6 fEXp+Uy9KTSrbXEDyrIjRJgehStxy+n0/5uPw= 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=UZKX8smlG3AH/wQEXsJR64fdZEcIofcDbXiJR3mpkiHkFo5BmIt9kvRLklHg1x6Jqz eQj6U70Gs/aiqMM5YFhR6Iv+56ScG+BtrHXm5hYvlTuYAzeboUntkocO5CcOl8ockPbM 4iX6jfSttQIU5HnwhBisDyZijwu5QHukGdxJY= Received: by 10.42.166.200 with SMTP id p8mr5121759icy.87.1295887870000; Mon, 24 Jan 2011 08:51:10 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id k38sm10063346ick.9.2011.01.24.08.51.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Jan 2011 08:51:07 -0800 (PST) Message-ID: <4D3DADF9.4040009@gmail.com> Date: Mon, 24 Jan 2011 11:51:05 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> In-Reply-To: <4D334595.3030507@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 16:48:18 -0000 On 1/16/11 2:23 PM, James Carlson wrote: >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-02.txt > > I'm starting a working group last-call comment period for this draft. > The new version incorporates changes for all of the comments received up > to this point. > > Last call will run for two weeks. Please submit any comments, > questions, or concerns you might have to me or to the pppext@ietf.org > mailing list (or both) on or before Sunday, January 30th, 2011. > Caveat: I'm not familiar with TRILL. Radia does great work, but she's always been rather biased in favor of IS-IS. I remember a debate at Interop '91 (or was it '92).... But you have me at "Algorhyme"! ;-) In any case, I disagree with section 3 item 3 regarding the OUI. I'm a big fan of completely finishing a specification, not leaving holes for later. And a bigger fan of zero configuration that eliminates even the possibility of an additional operational consideration! IIRC, IETF now has an OUI. Back in the day, we'd use something in the CF0000 series (see [RFC-2153]). Either should work OK. PPP has a Magic Number, guaranteed to be unique between PPP interfaces on the same device. You should combine it with the OUI. Simply require it during LCP negotiation, as so many other PPP RFCs do already. From carlsonj@workingcode.com Mon Jan 24 09:03:02 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451E93A6B08 for ; Mon, 24 Jan 2011 09:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwp6X8UxMs91 for ; Mon, 24 Jan 2011 09:03:01 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 493653A6B02 for ; Mon, 24 Jan 2011 09:03:01 -0800 (PST) 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 p0OH5lK5006319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jan 2011 12:05:48 -0500 (EST) Message-ID: <4D3DB16B.5080803@workingcode.com> Date: Mon, 24 Jan 2011 12:05:47 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: William Allen Simpson References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> In-Reply-To: <4D3DADF9.4040009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:03:02 -0000 William Allen Simpson wrote: > In any case, I disagree with section 3 item 3 regarding the OUI. I'm a big > fan of completely finishing a specification, not leaving holes for later. > And a bigger fan of zero configuration that eliminates even the possibility > of an additional operational consideration! I agree that it'd be nice to fill in this hole, but I'm not so sure how to accomplish that task. I don't think IETF OUI plus LCP Magic Number works -- the Magic Number value is unique for a given endpoint on a given link, but is not guaranteed to be unique across a network. But the IS-IS System ID number does need to be unique across the network, and its construction based on MAC addresses normally protects that requirement. One way to avoid the hole would be to outlaw the use of systems that lack any way to form an IS-IS System ID, but that seems a little harsh. Forcing that corner case to use manual configuration is distasteful, but the alternatives seem worse, at least to me. -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Mon Jan 24 09:49:50 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0664728C0EE for ; Mon, 24 Jan 2011 09:49:50 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPAR8cncN4Z5 for ; Mon, 24 Jan 2011 09:49:48 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 212BC28C0E7 for ; Mon, 24 Jan 2011 09:49:48 -0800 (PST) Received: by gxk27 with SMTP id 27so1611987gxk.31 for ; Mon, 24 Jan 2011 09:52:43 -0800 (PST) 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=56GCUV6unX7OLegdTvw/Mshif8905rrbWrlnrD/+5oM=; b=o7Wm5KIwidiPjERr9AtZCSBd7Pcg4fe4XY1EOIMB3B6kwH5qfqq6g72iC2MzQajnGe suTqvXHb9IXIf2ty/wuEmf/d7WAX00pvT0dbeICOo84uYJ3Xv2mA1rB5lXXZKQ3f7g2J MccKj0TAINindN9RdOcaF1P0igQ1zSi6TpjQA= 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=r7YAqyTMJPucPqmtNObsXKHmIcnVld3nsmEPV6BmFrPaBv1RwjQIaHvyhJ7R2WTiip 6EJgleOq2yjmpKGVIZihVGLW28KN3ObB804K7BXYwCK36XMPQmcrvXTYj1VVihNtRLpY p/lMnqhI66P8cElVyhDQGV119wrwiVeGttsVU= Received: by 10.42.166.200 with SMTP id p8mr5215887icy.87.1295891562881; Mon, 24 Jan 2011 09:52:42 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id g4sm9170627ick.23.2011.01.24.09.52.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Jan 2011 09:52:39 -0800 (PST) Message-ID: <4D3DBC64.3070308@gmail.com> Date: Mon, 24 Jan 2011 12:52:36 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> In-Reply-To: <4D3DADF9.4040009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 17:49:50 -0000 On 1/24/11 11:51 AM, William Allen Simpson wrote: > IIRC, IETF now has an OUI. Back in the day, we'd use something in the > CF0000 series (see [RFC-2153]). Either should work OK. > > PPP has a Magic Number, guaranteed to be unique between PPP interfaces on > the same device. You should combine it with the OUI. Simply require it > during LCP negotiation, as so many other PPP RFCs do already. Upon further reflection, the IETF OUI won't work, because that would require either truncating the Magic Number (rendering it less likely to be unique), or using a EUI-64 form to make enough room for the full 32 bits. But I don't see any ability in the TRILL draft to use the EUI-64 format. So, you'd have to use the CF0000 series. AFAICT, the TRILL protocol never uses that System ID as the next hop destination (please correct me). It uses its own multicast value, so there should be no conflict. I'd recommend registering the CFFFxx series to add a Magic Number. The CF0000 series was not originally intended to be used outside of PPP Vendor Extensions, and thus never appears over an actual Ethernet link.... This would be a first. From william.allen.simpson@gmail.com Mon Jan 24 10:26:54 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3E53A6B23 for ; Mon, 24 Jan 2011 10:26:53 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw-xfWFx-kjh for ; Mon, 24 Jan 2011 10:26:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 354113A6907 for ; Mon, 24 Jan 2011 10:26:52 -0800 (PST) Received: by iyi42 with SMTP id 42so4686539iyi.31 for ; Mon, 24 Jan 2011 10:29:47 -0800 (PST) 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=DPD07MLHQuYCu5wjGU0LqIMyMbjB3WSoYeXhLi5v/X8=; b=f/41H+WxNhvIz4w+cggiMy8mvwRc4My0XL7s/leNqz/fKI1RJR7qWJEcP54jfxdtwH 1AnBc6QL2fn88lgYOwHIyRpm9ObTr64VbR2oD4dYUsKvtnWFIHU0Mcwvb5gxsOYZr2v9 +NyOJr7+tEU5h029HxEZob16Vv3aHr3jq/rcI= 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=BdsaLXvhdSBapdp9aaHDOTe2+gEQoX8c/hODnZ4Jrr5ruCcJZjRDOCcoSMM6dY7i7D LvXKJkW1/Czk+EjTiCJ9rSLoy4ACLc6gXrgAiudSNlQWArbJGdCJGA8F2FXhmOXCz/9Z WmSPuZzPTlnrzmCvzbfkcFUhmm8vfVs4z4UL4= Received: by 10.42.213.5 with SMTP id gu5mr5294948icb.240.1295893787402; Mon, 24 Jan 2011 10:29:47 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id d13sm4468621ice.16.2011.01.24.10.29.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Jan 2011 10:29:44 -0800 (PST) Message-ID: <4D3DC516.1000105@gmail.com> Date: Mon, 24 Jan 2011 13:29:42 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> In-Reply-To: <4D3DB16B.5080803@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 18:26:54 -0000 On 1/24/11 12:05 PM, James Carlson wrote: > I agree that it'd be nice to fill in this hole, but I'm not so sure how > to accomplish that task. I don't think IETF OUI plus LCP Magic Number > works -- the Magic Number value is unique for a given endpoint on a > given link, but is not guaranteed to be unique across a network. But > the IS-IS System ID number does need to be unique across the network, > and its construction based on MAC addresses normally protects that > requirement. > It must be nice to live in a world with unique MAC addresses! In my experience, I've run into rather a lot of them that are not -- and it will be much worse in this cross-linked multi-media environment. Many vendors think that it's OK to reuse the MAC address for different link speeds and types. The likelihood that two D-Link boxes have the same MAC is something on the order of 2**8 (and was *every* box for about 2 years)! I've had problems with Linksys, Intel, 3Com, etc. ad nauseam. The only way that the Magic Number has any significant chance to ever be non-unique would be a very large number of PPP-only bridges in the network, on the order of 2**16. Probably best to stick an IP router in there.... If the PPP-only bridges are talking to each other, there will *never* be any non-unique numbers. That's the more likely case of centrally located PPP-only bridges. > One way to avoid the hole would be to outlaw the use of systems that > lack any way to form an IS-IS System ID, but that seems a little harsh. And contrary to the whole point of PPP. > Forcing that corner case to use manual configuration is distasteful, > but the alternatives seem worse, at least to me. > Well, many boxes these days have the ability to over-ride the default, but it would be nice to have a default mechanism. From william.allen.simpson@gmail.com Mon Jan 24 11:03:08 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60893A6B32 for ; Mon, 24 Jan 2011 11:03:08 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvSBZ0Cz38nv for ; Mon, 24 Jan 2011 11:03:08 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E71E13A6B37 for ; Mon, 24 Jan 2011 11:03:07 -0800 (PST) Received: by iwn40 with SMTP id 40so4742850iwn.31 for ; Mon, 24 Jan 2011 11:06:03 -0800 (PST) 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=/mo11Jo+WvpgcpRyRfbeQ1NCE4RdUSPGDukQbRgRazk=; b=m/puWXe3Xtk5IWCXeWesKQbxoX5oeJMwKTG4mx9cchai9cGiU4Z/L4P+br0WYA15Gg 4QUtkUi7gfeEKbCL3xAPikIed6IWbLiCqQxt840h7No89YtVABU1n+yUe+xms5lqjOBb hyakUzEmKk3gBbGpvFPA//ySyZ/ZcflS6Bvc0= 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=wz8HsGm7NJQQ/XZDooSWKIfzNWBqwXicPY3COUTdM6SVe4as1gBZkE5xudkafcOeVE FFclsDsi1qb7qskzlfqMZ+8SdWF3f9QBOzuuNk6zeMShhKhtTKJ1yRuCLI0lNQhk0E2a 0DxCvaNUg7mNG77clyzvNFKl5n/51oxNGe7cY= Received: by 10.42.178.129 with SMTP id bm1mr5293132icb.121.1295895963136; Mon, 24 Jan 2011 11:06:03 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id y8sm10126617ica.14.2011.01.24.11.06.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Jan 2011 11:06:01 -0800 (PST) Message-ID: <4D3DCD97.7040005@gmail.com> Date: Mon, 24 Jan 2011 14:05:59 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> In-Reply-To: <4D3DC516.1000105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 19:03:09 -0000 On 1/24/11 1:29 PM, William Allen Simpson wrote: > On 1/24/11 12:05 PM, James Carlson wrote: >> I agree that it'd be nice to fill in this hole, but I'm not so sure how >> to accomplish that task. I don't think IETF OUI plus LCP Magic Number >> works -- the Magic Number value is unique for a given endpoint on a >> given link, but is not guaranteed to be unique across a network. But >> the IS-IS System ID number does need to be unique across the network, >> and its construction based on MAC addresses normally protects that >> requirement. >> > It must be nice to live in a world with unique MAC addresses! In my > experience, I've run into rather a lot of them that are not -- and it > will be much worse in this cross-linked multi-media environment. Many > vendors think that it's OK to reuse the MAC address for different link > speeds and types. > I'm staring at the TRILL draft, and cannot find anything in the protocol to detect, eliminate, or resolve duplicate System ID numbers. Obviously, I'm missing something. Please advise. > The only way that the Magic Number has any significant chance to ever be > non-unique would be a very large number of PPP-only bridges in the network, > on the order of 2**16. Probably best to stick an IP router in there.... > To elaborate, I've an old story to tell. Once upon a time, Michigan State University supposedly had the world's largest bridged ethernet, covering many square miles. Performance was abysmal. But once I stuck a 286 box with KA9Q net (this was circa 1985) between the computing center and engineering, performance miraculously improved! (The problem turned out to be fragments inserted by the IBM in the administration building next door to the computing center.) Thus, I got the routing religion.... Never use a bridge where a router could be used instead. I really doubt we'll ever see more than one or two PPP-only Rbridges in a single installation. The point being that PPP is vastly more robust than ethernet -- and you shouldn't let the good enough (ethernet) be the enemy of the better (PPP). > If the PPP-only bridges are talking to each other, there will *never* be > any non-unique numbers. That's the more likely case of centrally > located PPP-only bridges. > Of course, this assumes that the PPP Magic Number has been implemented correctly, and it checks the number against all its interfaces to avoid loops. It also assumes you haven't deployed Junipers with the fairly evil "ppp magic-number ignore-mismatch". From carlsonj@workingcode.com Mon Jan 24 12:39:06 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBF33A6962 for ; Mon, 24 Jan 2011 12:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UknR-0-8GbSV for ; Mon, 24 Jan 2011 12:39:05 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 34F703A692C for ; Mon, 24 Jan 2011 12:39:05 -0800 (PST) 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 p0OKftqF009445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jan 2011 15:41:55 -0500 (EST) Message-ID: <4D3DE413.80908@workingcode.com> Date: Mon, 24 Jan 2011 15:41:55 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: William Allen Simpson References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> In-Reply-To: <4D3DCD97.7040005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 20:39:06 -0000 William Allen Simpson wrote: > I'm staring at the TRILL draft, and cannot find anything in the protocol > to detect, eliminate, or resolve duplicate System ID numbers. Obviously, > I'm missing something. Please advise. I don't believe that anything can or will do that. It's assumed into existence, as far as I understand. The System ID is used (among other things) for pseudonode generation and TRILL nickname resolution. If those aren't unique, then my understanding is that the network will fly to bits. I'm not the IS-IS expert here. If someone else (preferably on the RBridge mailing list) has an opinion about running a TRILL IS-IS network where some of the nodes using only point-to-point links have System IDs that are possibly non-unique, then now is the time to speak up. But I certainly don't feel comfortable endorsing this sort of usage in the PPP TRILL draft without review by at least the TRILL group, and probably the IS-IS group as well. > Thus, I got the routing religion.... Never use a bridge where a router > could be used instead. Indeed. I agree completely, though I don't think it's really the problem at hand. If the user has PPP TRILL links, he's already decided (for whatever reason) that he wants to bridge. > Of course, this assumes that the PPP Magic Number has been implemented > correctly, and it checks the number against all its interfaces to avoid > loops. It also assumes you haven't deployed Junipers with the fairly evil > "ppp magic-number ignore-mismatch". I see nothing in RFC 1661 section 6.4 requiring or even suggesting a check across all of the node's interfaces. Off hand, I don't know of any that do that, and I do know of a few implementations where such a test would be architecturally impractical (if not outright impossible). In any event, I think this is a detour: the real issue is that the IS-IS System ID must be unique across the IS-IS campus, and PPP's Magic-Number option doesn't have that quality, even if it has the checks you're suggesting. With Ethernet, the assumption is that MAC addresses among systems that speak IS-IS are unique per the standards. Whether any vendor is able to achieve that and/or whether relying on MAC uniqueness is a smart thing to do is possibly an interesting topic, but I think is certainly one for a different mailing list. It doesn't involve PPP. -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Mon Jan 24 14:41:17 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5983A69AF for ; Mon, 24 Jan 2011 14:41:17 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDfdqQqi5MwT for ; Mon, 24 Jan 2011 14:41:16 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 990F83A6932 for ; Mon, 24 Jan 2011 14:41:16 -0800 (PST) Received: by iyi42 with SMTP id 42so4939061iyi.31 for ; Mon, 24 Jan 2011 14:44:12 -0800 (PST) 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=9x6XB0hxpwjdqQfI1IjmQeH7nWuCcFvDlncaobjhwz8=; b=EZmQHwtJ08XzxtlUrrpnc2qxA/68HgTddjIkAk+hSDUQ4icb8VDSryF32hg5Z84S4D VTZxgwYKW6Xgs+EsaSHZX0oF0+6Z1+IjLQlviFXrIvfNXBWdfXs5W+6ueaHD2dBlKNZd sep9lzYzHOXfclN7ljftKO02viak87Coqlq4Q= 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=GInkipqawJipXSwDhhOgllqKt/Manub2ne86Z70BHkS12WzQBDwrvRtTmtCJnAMPcj NMY+JTKpZfpiAq/aOJn5mYQWKDiDHiqxOS3pyK30ghA0b4xxzBYD1ccpw2xzj96wdjUf kB7v7QHnHyTUq2rXa3Vp+MvJsS5Yfbog2rOn0= Received: by 10.42.172.67 with SMTP id m3mr5635106icz.95.1295909052351; Mon, 24 Jan 2011 14:44:12 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id ca7sm10237816icb.12.2011.01.24.14.44.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Jan 2011 14:44:11 -0800 (PST) Message-ID: <4D3E00B9.7050509@gmail.com> Date: Mon, 24 Jan 2011 17:44:09 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> In-Reply-To: <4D3DE413.80908@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 22:41:17 -0000 On 1/24/11 3:41 PM, James Carlson wrote: > William Allen Simpson wrote: >> I'm staring at the TRILL draft, and cannot find anything in the protocol >> to detect, eliminate, or resolve duplicate System ID numbers. Obviously, >> I'm missing something. Please advise. > > I don't believe that anything can or will do that. It's assumed into > existence, as far as I understand. > > The System ID is used (among other things) for pseudonode generation and > TRILL nickname resolution. If those aren't unique, then my > understanding is that the network will fly to bits. > There is some text about resolving nicknames that aren't unique. Nicknames aren't deterministic on the System ID, though. They're small, so they have a 2*8 average chance of collision. (Section 3.7) I cannot find a description of pseudonode generation. (Or even a definition for "pseudonode".) > I'm not the IS-IS expert here. If someone else (preferably on the > RBridge mailing list) has an opinion about running a TRILL IS-IS network > where some of the nodes using only point-to-point links have System IDs > that are possibly non-unique, then now is the time to speak up. > > But I certainly don't feel comfortable endorsing this sort of usage in > the PPP TRILL draft without review by at least the TRILL group, and > probably the IS-IS group as well. > OK, let's wait a bit. The questions are: - How does TRILL handle System IDs that are not unique? - Are System IDs ever used in the ethernet source or destination fields? > I see nothing in RFC 1661 section 6.4 requiring or even suggesting a > check across all of the node's interfaces. Off hand, I don't know of > any that do that, and I do know of a few implementations where such a > test would be architecturally impractical (if not outright impossible). > The whole point is to avoid loops. It is "a unique number". You cannot avoid a loop with your *own* interfaces without checking against any existing interfaces to see whether your chosen number is unique.... Certainly, I'd never expect connecting serial port 1 to serial port 2 on the same machine would ever pass the magic number test. (Sometimes I wonder, how many more details must we write in specifications, when something this obvious is missed by some implementers?) > With Ethernet, the assumption is that MAC addresses among systems that > speak IS-IS are unique per the standards. Whether any vendor is able to > achieve that and/or whether relying on MAC uniqueness is a smart thing > to do is possibly an interesting topic, but I think is certainly one for > a different mailing list. It doesn't involve PPP. > I don't like assumptions. That's a tautology. If the proven existing MAC uniqueness in the field is already *less* than known mathematical uniqueness of the PPP Magic Number, then there's no PPP-specific issue to be solved. In either case of conflict, then manual configuration is required. The chance of PPP collision is *much* rarer. Automatic PPP configuration should be part of this specification. From carlsonj@workingcode.com Mon Jan 24 17:13:54 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42F43A69A4 for ; Mon, 24 Jan 2011 17:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0ZF91UobWAu for ; Mon, 24 Jan 2011 17:13:53 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id CDBEB3A699F for ; Mon, 24 Jan 2011 17:13:52 -0800 (PST) Received: from dhcp-226.workingcode.com (dhcp-226 [192.168.254.226]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p0P1Gj8Y013388 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Jan 2011 20:16:45 -0500 (EST) Message-ID: <4D3E247D.9090201@workingcode.com> Date: Mon, 24 Jan 2011 20:16:45 -0500 From: James Carlson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: William Allen Simpson References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> In-Reply-To: <4D3E00B9.7050509@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 01:13:54 -0000 On 1/24/11 5:44 PM, William Allen Simpson wrote: > On 1/24/11 3:41 PM, James Carlson wrote: >> William Allen Simpson wrote: >>> I'm staring at the TRILL draft, and cannot find anything in the protocol >>> to detect, eliminate, or resolve duplicate System ID numbers. >>> Obviously, >>> I'm missing something. Please advise. >> >> I don't believe that anything can or will do that. It's assumed into >> existence, as far as I understand. >> >> The System ID is used (among other things) for pseudonode generation and >> TRILL nickname resolution. If those aren't unique, then my >> understanding is that the network will fly to bits. >> > There is some text about resolving nicknames that aren't unique. Nicknames > aren't deterministic on the System ID, though. They're small, so they have > a 2*8 average chance of collision. (Section 3.7) > > I cannot find a description of pseudonode generation. (Or even a > definition for "pseudonode".) It's part of RFC 1142. I'm no IS-IS expert; it could possibly be just a LAN-type feature. The bottom line, though, is that I'm not willing to define a new mode of operation for IS-IS on my own. If there's some documentation of how existing IS-IS systems with only point-to-point links operate without a System ID, I'll be happy to provide a pointer to it along with an appropriate synopsis to make it as clear as possible. I am unable to locate any documentation of that sort. If you have pointers, please supply them, and I'll incorporate. I wrote this draft as a favor to the RBridges chair to describe how the protocol would work on some medium other than Ethernet. The TRILL protocol is designed so that it should be medium-agnostic (at least on the transport side), but without an existence proof, it's hard to know, and that's what this draft helps accomplish. But I don't intend this draft as an extension or modification of IS-IS in any way. If extensions are required, then I think it would be best to withdraw the draft and call it a day. Someone else will have to design whatever extensions you and the other reviewers feel are necessary. (I don't believe any such extensions are required, but if that's the case, then I'm out. I can't do that work.) > OK, let's wait a bit. > > The questions are: > > - How does TRILL handle System IDs that are not unique? I do not know. But I do know that RFC 1142 goes out of its way to say that MAC addresses are unique, and that System IDs must also be unique. As far as I can tell, it's just assumed. But this is *not* the IS-IS working group. I think any questions about how IS-IS does or does not work really ought to be directed to that group. I can't answer them in any reasonable way, and I'm pretty sure that questions like that are just plain out of scope for this draft. For that matter, this draft also doesn't address TRILL itself. It only addresses the operation of TRILL over PPP links. If there are design problems in TRILL itself -- if there needs to be some magic in TRILL that checks for the "impossible" duplicate System IDs -- then I believe that this is a generic issue with TRILL, and it should be addressed outside the scope of the last call for this draft. If there's a fix to the problem you're describing, then surely it's not dependent on PPP for operation. Right? > - Are System IDs ever used in the ethernet source or destination fields? Not that I'm aware of. They are used in the generation of LSPs as part of IS-IS, though. >> I see nothing in RFC 1661 section 6.4 requiring or even suggesting a >> check across all of the node's interfaces. Off hand, I don't know of >> any that do that, and I do know of a few implementations where such a >> test would be architecturally impractical (if not outright impossible). >> > The whole point is to avoid loops. It is "a unique number". You cannot > avoid a loop with your *own* interfaces without checking against any > existing interfaces to see whether your chosen number is unique.... It's to avoid looped-back interfaces. That's exactly what the RFC says. Not "avoid loops." The RFC goes to great length to describe when and why an implementation must generate a new Magic Number value due to conflict, and at no point does it describe comparisons against any value except the two values used by the two peers on the link. I agree that it'd be nice to have it do more, and that what you're suggesting sounds reasonable. However, it's certainly not what the RFC says. And worse still, even if the RFC were to describe the mechanism you're suggesting, IT WOULD NOT HELP! The requirement in IS-IS is for network-wide uniqueness, and merely checking all of your own links -- but not those of all of the nodes in the network -- is insufficient to meet that goal. Nothing PPP does can help with that. Thus, I believe this entire discussion about the operation of the LCP Magic-Number option is without a point. > Certainly, I'd never expect connecting serial port 1 to serial port 2 > on the same machine would ever pass the magic number test. > > (Sometimes I wonder, how many more details must we write in specifications, > when something this obvious is missed by some implementers?) If you'd like to publish an update to RFC 1661 with this sort of restriction, that sounds fine to me. For what it's worth, though, I can't say I know of any implementations that will pass this new stricter test. In particular, the common CMU/ANU/samba.org pppd implementation would not pass. It has no means of comparing Magic-Number option values across links. The control portion of each link runs in a completely different address space -- different processes. It'd require a database similar to the one currently used for RFC 1990 E-Ds and MP in order to implement it, and given the sorts of problems seen with that, it's not what I'd call an improvement. >> With Ethernet, the assumption is that MAC addresses among systems that >> speak IS-IS are unique per the standards. Whether any vendor is able to >> achieve that and/or whether relying on MAC uniqueness is a smart thing >> to do is possibly an interesting topic, but I think is certainly one for >> a different mailing list. It doesn't involve PPP. >> > I don't like assumptions. That's a tautology. > > If the proven existing MAC uniqueness in the field is already *less* than > known mathematical uniqueness of the PPP Magic Number, then there's no > PPP-specific issue to be solved. In either case of conflict, then manual > configuration is required. > > The chance of PPP collision is *much* rarer. Automatic PPP configuration > should be part of this specification. I still don't understand why this draft has to define this new special usage. We're talking about a corner case out of a corner case -- a special TRILL-speaking system with PPP links but that has zero Ethernet interfaces. Who is going to build such a beast? And why? In the unlikely case that someone does build that thing, I'd be happy to let that person define exactly how the required IS-IS System ID is computed, formed, configured, guessed, or drawn carefully out of the ether. For the simple case of allowing a TRILL-speaking system that already has its own means of deriving a System ID (whatever that may be) to use PPP links between other cooperating systems, I believe the existing text is sufficient. To be clear: TRILL over PPP allows the packets to be exchanged in a reasonable manner. Unlike Ethernet, it does not come with a burned-in "guaranteed globally unique" MAC address, and thus any existing text in TRILL and/or IS-IS documents that assume the existence of such an address on at least one link in the system -- such as section B.2.1.3 of RFC 1142 -- will have to look elsewhere for that value. PPP can't supply it. -- James Carlson 42.703N 71.076W From d3e3e3@gmail.com Mon Jan 24 23:32:56 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1571D3A6A69 for ; Mon, 24 Jan 2011 23:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPXEVDwleIwT for ; Mon, 24 Jan 2011 23:32:55 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id AEB213A6A20 for ; Mon, 24 Jan 2011 23:32:54 -0800 (PST) Received: by wyf23 with SMTP id 23so5343285wyf.31 for ; Mon, 24 Jan 2011 23:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=K9gWYrHFxZhkdGhcZDV0s2bRgSIgtWgIPZX0a2JjVm8=; b=byr6PBdGvtmaY5hXxA08sjRlH8tv+4DYWsMkNkgxB0Hv7g99ct30bPeZBSGXZDTQ2m i+mI1gbs4iQFA3qTmkCMD96hx8/s7Q3lL1SvJa6oeoZUth3LyFXt9H43y3ouv3Jk43E9 pQ+9H5eKVQ5A+wR0bsVX3ulJ1bDNpC4zcn0aY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=SUNc0e/djrrbmpGykI9C8apBgxyHhVPrMjv9S0QBeG4ORDFlqGLET8qtJUk02TL+t2 SPC1+g2RoGR5ukLwHHni+49Cp9EzEVZSrp36+VcnLg0qTUIgVNBfXOZx9EfmNOk2JEr5 UvKjBIkVPC3qBHbDfMyZGCLB8a3YmNeP3JUFM= Received: by 10.227.155.140 with SMTP id s12mr5429907wbw.153.1295940950949; Mon, 24 Jan 2011 23:35:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Mon, 24 Jan 2011 23:35:30 -0800 (PST) In-Reply-To: <4D3DCD97.7040005@gmail.com> References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> From: Donald Eastlake Date: Tue, 25 Jan 2011 02:35:30 -0500 Message-ID: To: William Allen Simpson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 07:32:56 -0000 Hi, On Mon, Jan 24, 2011 at 2:05 PM, William Allen Simpson wrote: > On 1/24/11 1:29 PM, William Allen Simpson wrote: >> >> On 1/24/11 12:05 PM, James Carlson wrote: >>> >>> I agree that it'd be nice to fill in this hole, but I'm not so sure how >>> to accomplish that task. I don't think IETF OUI plus LCP Magic Number >>> works -- the Magic Number value is unique for a given endpoint on a >>> given link, but is not guaranteed to be unique across a network. But >>> the IS-IS System ID number does need to be unique across the network, >>> and its construction based on MAC addresses normally protects that >>> requirement. >>> >> It must be nice to live in a world with unique MAC addresses! In my >> experience, I've run into rather a lot of them that are not -- and it >> will be much worse in this cross-linked multi-media environment. Many >> vendors think that it's OK to reuse the MAC address for different link >> speeds and types. >> > I'm staring at the TRILL draft, and cannot find anything in the protocol > to detect, eliminate, or resolve duplicate System ID numbers. =A0Obviousl= y, > I'm missing something. =A0Please advise. You are looking in the wrong place. The unique System ID requirement is an IS-IS requirement. It is my impression that manufacturers of ISIS routers either allocate a MAC address under their OUI to use as System ID or use the MAC address of one of their interfaces. Maybe, in this instance, they are more careful to not duplicate from some other box they built. But it doesn't matter what they do. It's an IS-IS requirement and their problem. Maybe the draft should just say less about this. Donald PS: Current traveling so I'm a bit out of phase... >> The only way that the Magic Number has any significant chance to ever be >> non-unique would be a very large number of PPP-only bridges in the >> network, >> on the order of 2**16. Probably best to stick an IP router in there.... >> > To elaborate, I've an old story to tell. =A0Once upon a time, Michigan St= ate > University supposedly had the world's largest bridged ethernet, covering > many square miles. =A0Performance was abysmal. =A0But once I stuck a 286 = box > with KA9Q net (this was circa 1985) between the computing center and > engineering, performance miraculously improved! > > (The problem turned out to be fragments inserted by the IBM in the > administration building next door to the computing center.) > > Thus, I got the routing religion.... =A0Never use a bridge where a router > could be used instead. > > I really doubt we'll ever see more than one or two PPP-only Rbridges in a > single installation. =A0The point being that PPP is vastly more robust th= an > ethernet -- and you shouldn't let the good enough (ethernet) be the enemy > of the better (PPP). > >> If the PPP-only bridges are talking to each other, there will *never* be >> any non-unique numbers. That's the more likely case of centrally >> located PPP-only bridges. >> > Of course, this assumes that the PPP Magic Number has been implemented > correctly, and it checks the number against all its interfaces to avoid > loops. =A0It also assumes you haven't deployed Junipers with the fairly e= vil > "ppp magic-number ignore-mismatch". From d3e3e3@gmail.com Mon Jan 24 23:55:26 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE6D3A6B75 for ; Mon, 24 Jan 2011 23:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynGnnNbLCBRd for ; Mon, 24 Jan 2011 23:55:24 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 633353A6A84 for ; Mon, 24 Jan 2011 23:55:24 -0800 (PST) Received: by wyf23 with SMTP id 23so5367322wyf.31 for ; Mon, 24 Jan 2011 23:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=5ZuqLnJuQh0rCHBlVfV+GoLYTrYlRHKIfcDB5tJn1RI=; b=GxDqHPNNra3FaU2thM2SWKxGVuQL4ekXalnoXHmt60vMw3UU6oKJfXSkJdWuYwpmyE dgBoJZ4ll6Azv6it/7zaHtUwDFO+AsZOXe70AnNIf0QVdGdzxiZYpw1rO5ytz4Oh29+t UQYxtOya9BvnKTRu7pWqmQMU/85HCDddVQU6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=JonNUI39ycaDJZbYfwRlSCeA3FZ6wCYQ5GHXm+/XfpJ9jOEhvC9rRfNNbo9fKbhsnR J69Bn37bOB0+PDCnb3UpyoYyp0BeqLUpkuorDyVkWiLCR2tOouOV7tPaVns/EpCgKzZu F6PPFiDuzsCKsiDiNVEyz1Zk06ASvoTx7VUik= Received: by 10.227.147.133 with SMTP id l5mr5605688wbv.37.1295942300569; Mon, 24 Jan 2011 23:58:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Mon, 24 Jan 2011 23:58:00 -0800 (PST) In-Reply-To: <4D3E00B9.7050509@gmail.com> References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> From: Donald Eastlake Date: Tue, 25 Jan 2011 02:58:00 -0500 Message-ID: To: William Allen Simpson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 07:55:26 -0000 Hi, On Mon, Jan 24, 2011 at 5:44 PM, William Allen Simpson wrote: > On 1/24/11 3:41 PM, James Carlson wrote: >> >> William Allen Simpson wrote: >>> >>> I'm staring at the TRILL draft, and cannot find anything in the protoco= l >>> to detect, eliminate, or resolve duplicate System ID numbers. =A0Obviou= sly, >>> I'm missing something. =A0Please advise. >> >> I don't believe that anything can or will do that. =A0It's assumed into >> existence, as far as I understand. >> >> The System ID is used (among other things) for pseudonode generation and >> TRILL nickname resolution. =A0If those aren't unique, then my >> understanding is that the network will fly to bits. >> > There is some text about resolving nicknames that aren't unique. =A0Nickn= ames > aren't deterministic on the System ID, though. =A0They're small, so they = have > a 2*8 average chance of collision. =A0(Section 3.7) Nickname resolution is dynamic so collisions get resolved. > I cannot find a description of pseudonode generation. =A0(Or even a > definition for "pseudonode".) That's because all of that is part of IS-IS. You need to start with ISO 10589, the 2002 edition. >> I'm not the IS-IS expert here. =A0If someone else (preferably on the >> RBridge mailing list) has an opinion about running a TRILL IS-IS network >> where some of the nodes using only point-to-point links have System IDs >> that are possibly non-unique, then now is the time to speak up. >> >> But I certainly don't feel comfortable endorsing this sort of usage in >> the PPP TRILL draft without review by at least the TRILL group, and >> probably the IS-IS group as well. >> > OK, let's wait a bit. > > The questions are: > > =A0- How does TRILL handle System IDs that are not unique? System IDs are used to uniquely identify IS-IS router in the link state database. There is no TRILL specific stuff related to non-unique System IDs. It's all IS-IS. > =A0- Are System IDs ever used in the ethernet source or destination field= s? There is no requirement to ever to that. Since they are the same size you can. As far as I know (which isn't that much), most manufacturers of IS-IS switches either allocate an MAC address they control to use as the System ID for a box or, a bit more commonly, use the MAC address of one of the boxes interface, such as the numerically lowest interface MAC address. There is no requirement for the MAC interfaces of RBridges in a campus to all have unique addresses as long as all the RBridges connected to a particular link have unique MAC addresses over that link. But the System IDs must be unique across the campus as per IS-IS subnet independent functions requirement. >> I see nothing in RFC 1661 section 6.4 requiring or even suggesting a >> check across all of the node's interfaces. =A0Off hand, I don't know of >> any that do that, and I do know of a few implementations where such a >> test would be architecturally impractical (if not outright impossible). >> > The whole point is to avoid loops. =A0It is "a unique number". =A0You can= not > avoid a loop with your *own* interfaces without checking against any > existing interfaces to see whether your chosen number is unique.... > > Certainly, I'd never expect connecting serial port 1 to serial port 2 > on the same machine would ever pass the magic number test. > > (Sometimes I wonder, how many more details must we write in specification= s, > when something this obvious is missed by some implementers?) > > >> With Ethernet, the assumption is that MAC addresses among systems that >> speak IS-IS are unique per the standards. =A0Whether any vendor is able = to >> achieve that and/or whether relying on MAC uniqueness is a smart thing >> to do is possibly an interesting topic, but I think is certainly one for >> a different mailing list. =A0It doesn't involve PPP. >> > I don't like assumptions. =A0That's a tautology. > > If the proven existing MAC uniqueness in the field is already *less* than > known mathematical uniqueness of the PPP Magic Number, then there's no > PPP-specific issue to be solved. =A0In either case of conflict, then manu= al > configuration is required. See above. MAC address uniqueness isn't the same as System ID uniqueness although in practice they might be conflated sometimes. Donald From d3e3e3@gmail.com Tue Jan 25 10:06:15 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5603A6882 for ; Tue, 25 Jan 2011 10:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.35 X-Spam-Level: X-Spam-Status: No, score=-103.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpOWd7BW6wS3 for ; Tue, 25 Jan 2011 10:06:13 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 1D36C3A684D for ; Tue, 25 Jan 2011 10:06:13 -0800 (PST) Received: by qyj19 with SMTP id 19so53229qyj.10 for ; Tue, 25 Jan 2011 10:09:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=8N2YLVxCZVIjUsj4FFExYIg2CdkYUEhFHx9Kw/hkjz0=; b=a+XVick+Wp5qmi29JJRNN5YE6juzmoEqcNG+Uru0Fx5dCSLAfNZqVkijNeV661FK5d hFXKI+HMyszn/dOKSfQORqCLF4felEV7yNeEbkt4UqbFu1XpNYZFEplhEkl1ogyeH+HH xsOyuhHa/jZfLHqHYB0fpoI5teeZzSSYlxP2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=JSpDAi17WKgYxfepWJFWO4395u/TfFlmvBgGDw8LthyCSllhEaR6+QR7tg+ebzNpE1 5nzizuTFNAMDNrlz+8opELE6vHn9e7rzjGhqzTuK4mh6LiZj5xYvJBh3hSlrNGIGeWSz Hn9mZE2cXr7MiE7FL0IlRKgbRECuLGHhaqLgI= Received: by 10.224.19.146 with SMTP id a18mr5568219qab.224.1295978950889; Tue, 25 Jan 2011 10:09:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.64.169 with HTTP; Tue, 25 Jan 2011 10:08:50 -0800 (PST) In-Reply-To: <4D3E247D.9090201@workingcode.com> References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> From: Donald Eastlake Date: Tue, 25 Jan 2011 13:08:50 -0500 Message-ID: To: James Carlson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 18:06:15 -0000 Hi James, I think your position below is reasonable. The System ID of an IS-IS router is certainly not required to be any sort of MAC address, it just has to be a 48-bit quantity unique among the IS-IS routers whose link state entries need to be distinguished. Perhaps Section 3, point 3, should be reworded to something like: "In the case of an RBridge with only PPP links, the practice of using the MAC address of an interface for the IS-IS System ID will not be available. The implementor will have to use other means, such as deriving a System ID from a MAC address allocated to the device as a whole, to assure that it has a campus-wide unique System ID." 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 =A0Donald E. Eastlake 3rd =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Mon, Jan 24, 2011 at 8:16 PM, James Carlson w= rote: > On 1/24/11 5:44 PM, William Allen Simpson wrote: >> On 1/24/11 3:41 PM, James Carlson wrote: >>> William Allen Simpson wrote: >>>> I'm staring at the TRILL draft, and cannot find anything in the protoc= ol >>>> to detect, eliminate, or resolve duplicate System ID numbers. >>>> Obviously, >>>> I'm missing something. =A0Please advise. >>> >>> I don't believe that anything can or will do that. =A0It's assumed into >>> existence, as far as I understand. >>> >>> The System ID is used (among other things) for pseudonode generation an= d >>> TRILL nickname resolution. =A0If those aren't unique, then my >>> understanding is that the network will fly to bits. >>> >> There is some text about resolving nicknames that aren't unique. =A0Nick= names >> aren't deterministic on the System ID, though. =A0They're small, so they= have >> a 2*8 average chance of collision. =A0(Section 3.7) >> >> I cannot find a description of pseudonode generation. =A0(Or even a >> definition for "pseudonode".) > > It's part of RFC 1142. =A0I'm no IS-IS expert; it could possibly be just = a > LAN-type feature. > > The bottom line, though, is that I'm not willing to define a new mode of > operation for IS-IS on my own. =A0If there's some documentation of how > existing IS-IS systems with only point-to-point links operate without a > System ID, I'll be happy to provide a pointer to it along with an > appropriate synopsis to make it as clear as possible. > > I am unable to locate any documentation of that sort. =A0If you have > pointers, please supply them, and I'll incorporate. > > I wrote this draft as a favor to the RBridges chair to describe how the > protocol would work on some medium other than Ethernet. =A0The TRILL > protocol is designed so that it should be medium-agnostic (at least on > the transport side), but without an existence proof, it's hard to know, > and that's what this draft helps accomplish. > > But I don't intend this draft as an extension or modification of IS-IS > in any way. =A0If extensions are required, then I think it would be best > to withdraw the draft and call it a day. =A0Someone else will have to > design whatever extensions you and the other reviewers feel are > necessary. =A0(I don't believe any such extensions are required, but if > that's the case, then I'm out. =A0I can't do that work.) > >> OK, let's wait a bit. >> >> The questions are: >> >> =A0- How does TRILL handle System IDs that are not unique? > > I do not know. =A0But I do know that RFC 1142 goes out of its way to say > that MAC addresses are unique, and that System IDs must also be unique. > =A0As far as I can tell, it's just assumed. > > But this is *not* the IS-IS working group. =A0I think any questions about > how IS-IS does or does not work really ought to be directed to that > group. =A0I can't answer them in any reasonable way, and I'm pretty sure > that questions like that are just plain out of scope for this draft. > > For that matter, this draft also doesn't address TRILL itself. =A0It only > addresses the operation of TRILL over PPP links. =A0If there are design > problems in TRILL itself -- if there needs to be some magic in TRILL > that checks for the "impossible" duplicate System IDs -- then I believe > that this is a generic issue with TRILL, and it should be addressed > outside the scope of the last call for this draft. > > If there's a fix to the problem you're describing, then surely it's not > dependent on PPP for operation. =A0Right? > >> =A0- Are System IDs ever used in the ethernet source or destination fiel= ds? > > Not that I'm aware of. =A0They are used in the generation of LSPs as part > of IS-IS, though. > >>> I see nothing in RFC 1661 section 6.4 requiring or even suggesting a >>> check across all of the node's interfaces. =A0Off hand, I don't know of >>> any that do that, and I do know of a few implementations where such a >>> test would be architecturally impractical (if not outright impossible). >>> >> The whole point is to avoid loops. =A0It is "a unique number". =A0You ca= nnot >> avoid a loop with your *own* interfaces without checking against any >> existing interfaces to see whether your chosen number is unique.... > > It's to avoid looped-back interfaces. =A0That's exactly what the RFC says= . > =A0Not "avoid loops." =A0The RFC goes to great length to describe when an= d > why an implementation must generate a new Magic Number value due to > conflict, and at no point does it describe comparisons against any value > except the two values used by the two peers on the link. > > I agree that it'd be nice to have it do more, and that what you're > suggesting sounds reasonable. =A0However, it's certainly not what the RFC > says. > > And worse still, even if the RFC were to describe the mechanism you're > suggesting, IT WOULD NOT HELP! =A0The requirement in IS-IS is for > network-wide uniqueness, and merely checking all of your own links -- > but not those of all of the nodes in the network -- is insufficient to > meet that goal. =A0Nothing PPP does can help with that. > > Thus, I believe this entire discussion about the operation of the LCP > Magic-Number option is without a point. > >> Certainly, I'd never expect connecting serial port 1 to serial port 2 >> on the same machine would ever pass the magic number test. >> >> (Sometimes I wonder, how many more details must we write in specificatio= ns, >> when something this obvious is missed by some implementers?) > > If you'd like to publish an update to RFC 1661 with this sort of > restriction, that sounds fine to me. =A0For what it's worth, though, I > can't say I know of any implementations that will pass this new stricter > test. > > In particular, the common CMU/ANU/samba.org pppd implementation would > not pass. =A0It has no means of comparing Magic-Number option values > across links. =A0The control portion of each link runs in a completely > different address space -- different processes. =A0It'd require a databas= e > similar to the one currently used for RFC 1990 E-Ds and MP in order to > implement it, and given the sorts of problems seen with that, it's not > what I'd call an improvement. > >>> With Ethernet, the assumption is that MAC addresses among systems that >>> speak IS-IS are unique per the standards. =A0Whether any vendor is able= to >>> achieve that and/or whether relying on MAC uniqueness is a smart thing >>> to do is possibly an interesting topic, but I think is certainly one fo= r >>> a different mailing list. =A0It doesn't involve PPP. >>> >> I don't like assumptions. =A0That's a tautology. >> >> If the proven existing MAC uniqueness in the field is already *less* tha= n >> known mathematical uniqueness of the PPP Magic Number, then there's no >> PPP-specific issue to be solved. =A0In either case of conflict, then man= ual >> configuration is required. >> >> The chance of PPP collision is *much* rarer. =A0Automatic PPP configurat= ion >> should be part of this specification. > > I still don't understand why this draft has to define this new special > usage. =A0We're talking about a corner case out of a corner case -- a > special TRILL-speaking system with PPP links but that has zero Ethernet > interfaces. =A0Who is going to build such a beast? =A0And why? > > In the unlikely case that someone does build that thing, I'd be happy to > let that person define exactly how the required IS-IS System ID is > computed, formed, configured, guessed, or drawn carefully out of the > ether. =A0For the simple case of allowing a TRILL-speaking system that > already has its own means of deriving a System ID (whatever that may be) > to use PPP links between other cooperating systems, I believe the > existing text is sufficient. > > To be clear: TRILL over PPP allows the packets to be exchanged in a > reasonable manner. =A0Unlike Ethernet, it does not come with a burned-in > "guaranteed globally unique" MAC address, and thus any existing text in > TRILL and/or IS-IS documents that assume the existence of such an > address on at least one link in the system -- such as section B.2.1.3 of > RFC 1142 -- will have to look elsewhere for that value. =A0PPP can't > supply it. > > -- > James Carlson =A0 =A0 =A0 =A0 42.703N 71.076W =A0 =A0 =A0 =A0 > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext > From carlsonj@workingcode.com Tue Jan 25 10:14:30 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57E03A6855 for ; Tue, 25 Jan 2011 10:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zGkmJh2grT9 for ; Tue, 25 Jan 2011 10:14:30 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 0468F3A6853 for ; Tue, 25 Jan 2011 10:14:29 -0800 (PST) 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 p0PIHNLZ028022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 13:17:23 -0500 (EST) Message-ID: <4D3F13B3.9070706@workingcode.com> Date: Tue, 25 Jan 2011 13:17:23 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Donald Eastlake References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 18:14:31 -0000 Donald Eastlake wrote: > Hi James, > > I think your position below is reasonable. The System ID of an IS-IS > router is certainly not required to be any sort of MAC address, it > just has to be a 48-bit quantity unique among the IS-IS routers whose > link state entries need to be distinguished. > > Perhaps Section 3, point 3, should be reworded to something like: "In > the case of an RBridge with only PPP links, the practice of using the > MAC address of an interface for the IS-IS System ID will not be > available. The implementor will have to use other means, such as > deriving a System ID from a MAC address allocated to the device as a > whole, to assure that it has a campus-wide unique System ID." That seems quite reasonable to me. I just want to steer clear of writing too much of the IS-IS requirements into this draft, as I think the overall system design implications are out of scope. -- James Carlson 42.703N 71.076W From vishwas.ietf@gmail.com Tue Jan 25 10:28:59 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2B33A6811 for ; Tue, 25 Jan 2011 10:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEGDDbI4posw for ; Tue, 25 Jan 2011 10:28:58 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5F49B3A6403 for ; Tue, 25 Jan 2011 10:28:58 -0800 (PST) Received: by wyf23 with SMTP id 23so78757wyf.31 for ; Tue, 25 Jan 2011 10:31:56 -0800 (PST) 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=uVem6QhsraVcmvGWmQxQ6HEqmXymVIGiAsqdxjd106w=; b=IEmBlVTbCbak5JnOQ1S8bZWe/1qYOlx0dnlFH1fbZ0138qRg3Ux4yoRrcEQMdHcc9g 8Qqkvma5hkLX8+vudQ9R1VFRm9D3AgQb/lLIKXeb+VFLIIKjk3nA2LNOV1hcd1ESlV5G PR8+NUDqUPbpP3lR0a5GSR8KNLg7fkadTu2SI= 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=pEiOojrj0KtDpxSiekKq2zwOkGYs5BiPpN7Fug8t5VDbH8+7s8EeLTxCyckLYnPXXY mq8gm7JMU3mn/R/Wo6Y57XZDqT1/KCs3+lRhVTm/QwEITfBBjFm1IMCBxF2i2wdNjS3P 9y8wVgnzCjFdoUC6dWkOMdogk9qTm1n9g/kq0= MIME-Version: 1.0 Received: by 10.216.182.212 with SMTP id o62mr4050418wem.52.1295980316014; Tue, 25 Jan 2011 10:31:56 -0800 (PST) Received: by 10.216.21.65 with HTTP; Tue, 25 Jan 2011 10:31:55 -0800 (PST) In-Reply-To: <4D3F13B3.9070706@workingcode.com> References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> <4D3F13B3.9070706@workingcode.com> Date: Tue, 25 Jan 2011 10:31:55 -0800 Message-ID: From: Vishwas Manral To: James Carlson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 25 Jan 2011 10:54:59 -0800 Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 18:28:59 -0000 Hi James, IMHO there should be no mention of IS-IS in the PPP draft. As IS-IS is a control plane protocol (we could as well use static Rbridge route entries - a requirement we have heard from 2 of our customers) and PPP is the data plane. Thanks, Vishwas On Tue, Jan 25, 2011 at 10:17 AM, James Carlson wrote: > Donald Eastlake wrote: >> Hi James, >> >> I think your position below is reasonable. The System ID of an IS-IS >> router is certainly not required to be any sort of MAC address, it >> just has to be a 48-bit quantity unique among the IS-IS routers whose >> link state entries need to be distinguished. >> >> Perhaps Section 3, point 3, should be reworded to something like: "In >> the case of an RBridge with only PPP links, the practice of using the >> MAC address of an interface for the IS-IS System ID will not be >> available. The implementor will have to use other means, such as >> deriving a System ID from a MAC address allocated to the device as a >> whole, to assure that it has a campus-wide unique System ID." > > That seems quite reasonable to me. =A0I just want to steer clear of > writing too much of the IS-IS requirements into this draft, as I think > the overall system design implications are out of scope. > > -- > James Carlson =A0 =A0 =A0 =A0 42.703N 71.076W =A0 =A0 =A0 =A0 > _______________________________________________ > rbridge mailing list > rbridge@postel.org > http://mailman.postel.org/mailman/listinfo/rbridge > From carlsonj@workingcode.com Tue Jan 25 11:01:25 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F3C3A6868 for ; Tue, 25 Jan 2011 11:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xfKONvLlGxr for ; Tue, 25 Jan 2011 11:01:24 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 25AA03A685B for ; Tue, 25 Jan 2011 11:01:24 -0800 (PST) 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 p0PJ4Dqp028765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jan 2011 14:04:13 -0500 (EST) Message-ID: <4D3F1EAD.5040901@workingcode.com> Date: Tue, 25 Jan 2011 14:04:13 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Vishwas Manral References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> <4D3F13B3.9070706@workingcode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-SIHOPE-DCC-3-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 19:01:25 -0000 Vishwas Manral wrote: > Hi James, > > IMHO there should be no mention of IS-IS in the PPP draft. As IS-IS is > a control plane protocol (we could as well use static Rbridge route > entries - a requirement we have heard from 2 of our customers) and PPP > is the data plane. I assume you're talking about the discussion of the System ID issue, and not the TLSP Packet Format described in section 2.3 for carrying IS-IS packets. (If you *do* mean TLSP, then I'll probably need some additional clarification.) I certainly agree with the sentiment (I don't like duplicating documentation at all, particularly for this issue), but the existing notation about MAC addresses (and the lack of them on PPP) was added at the behest of other reviewers who found that it was confusing to match up the PPP TRILL draft with the primary TRILL documentation without some indication that there are differences here. I find I'm walking a narrow line. I want to provide a little guidance so that it's clear what's expected here, but I also want to avoid either just copying hunks of the TRILL and IS-IS documentation or (worse) carving out special exceptions. I probably can't please everyone. -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Wed Jan 26 10:17:43 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E4B3A67D8 for ; Wed, 26 Jan 2011 10:17:43 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNF-Tb7TrBON for ; Wed, 26 Jan 2011 10:17:42 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 55E693A67B3 for ; Wed, 26 Jan 2011 10:17:42 -0800 (PST) Received: by iwn40 with SMTP id 40so1240436iwn.31 for ; Wed, 26 Jan 2011 10:20:43 -0800 (PST) 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=ukVd9MLJQSXr2btTlDu90+k55FkUTKy4+PAJULD5VPY=; b=jvMwZWvriM+Edst3hQ7nn1tIU6W7FpsF4sMKPLws9oqd37LWtjv1kGdeRhFK0GhccB VR9xqe1hMQWnFP9mF/DPtUUmubPKMbHdc/z1lUIay5zaageWolSilvCOjLsL8qa+O4mh qCc8nInp1pS9Gr5PkdxCK0t1U1vmcf9HuKrZM= 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=SHBy+fp1DHpBw/vU1T6QeEj6POzSHdS/6KlqQlMW9fX6ffke7/3RrCOG38My3jQLlh 47GwQ3ncaoiSCc9FcRvY6s/K1JUO82wYUad10qzXF1UI7TBHP08WPgNeNQP9eY18Bs83 Kq2xf9V086GWNWR4BYt6d/lF7GssebVH9lWPs= Received: by 10.231.199.10 with SMTP id eq10mr8527280ibb.112.1296066038750; Wed, 26 Jan 2011 10:20:38 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id z4sm13102915ibg.19.2011.01.26.10.20.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 10:20:36 -0800 (PST) Message-ID: <4D4065F2.3080305@gmail.com> Date: Wed, 26 Jan 2011 13:20:34 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> <4D3F13B3.9070706@workingcode.com> <4D3F1EAD.5040901@workingcode.com> In-Reply-To: <4D3F1EAD.5040901@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 18:17:43 -0000 On 1/25/11 2:04 PM, James Carlson wrote: > I certainly agree with the sentiment (I don't like duplicating > documentation at all, particularly for this issue), but the existing > notation about MAC addresses (and the lack of them on PPP) was added at > the behest of other reviewers who found that it was confusing to match > up the PPP TRILL draft with the primary TRILL documentation without some > indication that there are differences here. > I agree with the other reviewers. Pretty hard to understand TRILL over PPP without mentioning System IDs and the lack of MAC addresses. This is the first Last Call we've had on the list for years, so I wasn't paying sufficient attention. I'm sure we'll iron things out. > I find I'm walking a narrow line. I want to provide a little guidance > so that it's clear what's expected here, but I also want to avoid either > just copying hunks of the TRILL and IS-IS documentation or (worse) > carving out special exceptions. I probably can't please everyone. > Probably not. But it's fundamentally wrong to specify a configuration requirement for two protocols that are both premised on auto-configuration! I'm sorry that I was off-line yesterday. We've had responses about the requirements, and that clarifies things immensely. But I'm busy cleaning up yesterday's mess today. I promise some text tomorrow.... TIA! From carlsonj@workingcode.com Wed Jan 26 11:44:14 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E8C3A688B for ; Wed, 26 Jan 2011 11:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDWG7r+12Ioa for ; Wed, 26 Jan 2011 11:44:13 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 4F5733A6870 for ; Wed, 26 Jan 2011 11:44:13 -0800 (PST) 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 p0QJlAHX020020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2011 14:47:11 -0500 (EST) Message-ID: <4D407A3E.2000708@workingcode.com> Date: Wed, 26 Jan 2011 14:47:10 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: William Allen Simpson References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> <4D3F13B3.9070706@workingcode.com> <4D3F1EAD.5040901@workingcode.com> <4D4065F2.3080305@gmail.com> In-Reply-To: <4D4065F2.3080305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 19:44:14 -0000 William Allen Simpson wrote: > On 1/25/11 2:04 PM, James Carlson wrote: >> I find I'm walking a narrow line. I want to provide a little guidance >> so that it's clear what's expected here, but I also want to avoid either >> just copying hunks of the TRILL and IS-IS documentation or (worse) >> carving out special exceptions. I probably can't please everyone. >> > Probably not. But it's fundamentally wrong to specify a configuration > requirement for two protocols that are both premised on auto-configuration! The other possible solution to avoid manual configuration (as I think I mentioned) is to outlaw the use of TRILL systems that have only PPP links and that also have no built-in (implementation-dependent) means of acquiring a System ID automatically. That's obviously possible, but besides being draconian in nature (how is it my business how you plan to work with network administrators?), it seems to strike a bit too close to the fundamentals of IS-IS. In other words, I think I can point out the potential issue that exists over in IS-IS to readers who might not be aware that (as part of an overall system design, not as part of PPP TRILL itself) they could be stepping in an area that lacks good solutions, but I don't think I should say anything here that's at the level of requirement. It's not my place to repeat IS-IS requirements. I can only do so badly and out-of-sync with the original. ;-} Informative works for me on this issue, but normative doesn't. > I'm sorry that I was off-line yesterday. We've had responses about the > requirements, and that clarifies things immensely. But I'm busy > cleaning up > yesterday's mess today. I promise some text tomorrow.... TIA! Delay is not a problem. I set a standard two-week timer to make sure that folks would follow up. But if there's still discussion going on at that point, I'll continue with it as long as necessary to close it out. (Or until I remember that I have other things to do, I suppose ...) -- James Carlson 42.703N 71.076W From d3e3e3@gmail.com Wed Jan 26 12:06:13 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581DC3A6920 for ; Wed, 26 Jan 2011 12:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.402 X-Spam-Level: X-Spam-Status: No, score=-103.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqzRryqmq1DD for ; Wed, 26 Jan 2011 12:06:12 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 49F213A68D7 for ; Wed, 26 Jan 2011 12:06:12 -0800 (PST) Received: by wyf23 with SMTP id 23so1330203wyf.31 for ; Wed, 26 Jan 2011 12:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=uONw3fXNCRrp61SLj8LxTxiuIBXU+vH/dTO49cgV8bE=; b=TFL2g70Nphn5xghRog8DMQ/Z62cUgieWaWHm+To2WdtyARhmP5J0yuGpPafPDZWEE6 Nf76MCEUfXnAuLUVD1He96t7SU/pO4bH+3mySxIRX6hBG0XQqpeLtfqWjYZakjanw3zs xZTjLqefWp9wmiZc5GhSao0B7xKZyqzneZito= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=s+Gssll74gf9wcn6vvec1jzmrA3+CjCt6pSKqgl3tGJ2v05QpSK+uAuaU+2kmHKh/n 75oo5KB3/DvYiw+W1gfAsvOEMQ9ZnCt8p/FmyvI2mzOIKlL+8JiD32RLY0IljpY595YB GLRrrOoViO3NUQ5Hlqwk6uImFA9Qb9Vg+rJpE= Received: by 10.227.143.206 with SMTP id w14mr39949wbu.66.1296072553054; Wed, 26 Jan 2011 12:09:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Wed, 26 Jan 2011 12:08:52 -0800 (PST) In-Reply-To: <4D4065F2.3080305@gmail.com> References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> <4D3F13B3.9070706@workingcode.com> <4D3F1EAD.5040901@workingcode.com> <4D4065F2.3080305@gmail.com> From: Donald Eastlake Date: Wed, 26 Jan 2011 15:08:52 -0500 Message-ID: To: William Allen Simpson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 20:06:13 -0000 Hi, On Wed, Jan 26, 2011 at 1:20 PM, William Allen Simpson wrote: > On 1/25/11 2:04 PM, James Carlson wrote: >> >> I certainly agree with the sentiment (I don't like duplicating >> documentation at all, particularly for this issue), but the existing >> notation about MAC addresses (and the lack of them on PPP) was added at >> the behest of other reviewers who found that it was confusing to match >> up the PPP TRILL draft with the primary TRILL documentation without some >> indication that there are differences here. >> > I agree with the other reviewers. =A0Pretty hard to understand TRILL over > PPP without mentioning System IDs and the lack of MAC addresses. I don't understand why you say that. Seem to me that TRILL over PPP just involves the formats, code points, and PPP procedures. Anyway, it isn't clear to me that anyone will build a practical RBridge that doesn't have a MAC address Ethernet interface even if it is just a virtual internal interface for a virtual internal end station. If that doesn't exist, you can't really address the RBridge for management or maintenance. 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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA=A0=A0 +1-508-634-2066 (home) =A0d3e3e3@gmail.com From carlsonj@workingcode.com Wed Jan 26 13:35:45 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A763A6893 for ; Wed, 26 Jan 2011 13:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3VkkgOSDIAD for ; Wed, 26 Jan 2011 13:35:44 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 2CA123A6873 for ; Wed, 26 Jan 2011 13:35:44 -0800 (PST) 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 p0QLca5L021550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2011 16:38:36 -0500 (EST) Message-ID: <4D40945C.1070906@workingcode.com> Date: Wed, 26 Jan 2011 16:38:36 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Donald Eastlake References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> <4D3F13B3.9070706@workingcode.com> <4D3F1EAD.5040901@workingcode.com> <4D4065F2.3080305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org, William Allen Simpson Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 21:35:45 -0000 Donald Eastlake wrote: > I don't understand why you say that. Seem to me that TRILL over PPP > just involves the formats, code points, and PPP procedures. Anyway, it > isn't clear to me that anyone will build a practical RBridge that > doesn't have a MAC address Ethernet interface even if it is just a > virtual internal interface for a virtual internal end station. If that > doesn't exist, you can't really address the RBridge for management or > maintenance. Sure, you could. It would just have to be addressed via IP (e.g., via SNMP, ssh, or even TELNET) rather than by something locked into Ethernet. One could imagine a large TRILL bridge designed for telecom applications exclusively on the interior of the cloud, where the only possible links are point-to-point; no Ethernet need apply. Whether anyone ever builds that beast -- and, if so, whether it lacks any built-in mechanism for automatic System ID assignment -- is a different question. What we're really discussing is whether failing to cover this case with some sort of automatic resolution is a hole in the specification (as I think Mr. Simpson is contending), or whether it's just an unlikely corner that implementors should be warned away from (as I believe). -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Thu Jan 27 03:00:47 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23CC93A6B18 for ; Thu, 27 Jan 2011 03:00:47 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMHOPjvEDMRa for ; Thu, 27 Jan 2011 03:00:46 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 274A93A6AC7 for ; Thu, 27 Jan 2011 03:00:46 -0800 (PST) Received: by iwn40 with SMTP id 40so2026669iwn.31 for ; Thu, 27 Jan 2011 03:03:49 -0800 (PST) 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:content-type:content-transfer-encoding; bh=mPrI130PWjsTKUruPpendJFadd8q3zTNH3LZKg3Vo3g=; b=TLjBwpIk9JBVk69u3QkurCN70yVncPQHCkQz8XqY7BmtpahGwtZ54pRua+x9rRmp57 cAQZFSG8crRaxsMfTQmvOyKZa6TeYYN882kqmWJLrWM2zxSJbte7GFtkH1nNcnpQmOQk LgmnRh43gAzFYoMJAJM/gKnTvQG97BGQaUs/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=vxfabD8ZFAWm698+7WaFQeQFM+K0l6DbQPhoWwqJQNZ0A1XfxUj83wbRS99cR2cZBx jP1HWssRdEmAP9jPEf9s+jopxNY1YSEXHMoohm1vGBWgN55kNoC3aypOdOm9ESc5Anjn OSalujI/Z4/LTu8EQbSJnkZjQZxL+R88mP15A= Received: by 10.231.10.197 with SMTP id q5mr694361ibq.197.1296126229087; Thu, 27 Jan 2011 03:03:49 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id 8sm13776077iba.22.2011.01.27.03.03.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 03:03:47 -0800 (PST) Message-ID: <4D415111.4010009@gmail.com> Date: Thu, 27 Jan 2011 06:03:45 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: [Pppext] proposed TRILL IS-IS System ID text X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 11:00:47 -0000 3. An implementation that has only PPP links might have no previously configured Media Access Control (MAC) that can function as an IS-IS System ID. In this case, the System ID is formed by adding a randomly generated 14-bit leading number (in place of an OUI) to the link's unique LCP Magic Number. The Magic Number MUST be unique for all links and all known link peers. This pseudo-MAC MUST have both the "locally-assigned" and "broadcast/multicast" (group) bits set to 1; that is, the least significant two bits of the most significant octet are both set to 1. ... Operational Considerations Although the probability of conflict with another IS-IS System ID is minuscule, each implementation MUST have a configuration option to override the System ID. From d3e3e3@gmail.com Thu Jan 27 06:30:56 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9AE63A684E for ; Thu, 27 Jan 2011 06:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.4 X-Spam-Level: X-Spam-Status: No, score=-103.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bINscCZPyeoV for ; Thu, 27 Jan 2011 06:30:56 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 708FB3A67EF for ; Thu, 27 Jan 2011 06:30:55 -0800 (PST) Received: by wwa36 with SMTP id 36so2456967wwa.13 for ; Thu, 27 Jan 2011 06:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Ut2LDRXrky8PsLrdx34e+Ba9JPhDrS18rp69C2yifiI=; b=mfIT9HjStQyvN2be6eWgDNvGby8I9XaVQVm2Bf+b+jWzYNrI9nHLcADAr9DXSF0UxN RbmxlVmvBy1m1oHcxHDsNHuxq3Yza49sTkFfdHpFkQge4zLWyzq9BwgP5sANQM5s3nPH QNvTBVVjdmoDAVQhvw0acaYYclNsT79S1IeQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=vdEXwSDyAL2GZNpg9NU0ATLIrSVSsJ3egtSAv/qjqH85U4hIlkaoHvn4WHaPXI5b9P tc3XUG5Ew0sjCnq1kypZS+WauSiBjsJ6qj8VUL0LVChuMC0ptj1E0uLkQAXYc3/K8eU4 SRqjAvc8YfYpAUlvm8DIzIPAS6BsBKybZ+UV0= Received: by 10.227.145.139 with SMTP id d11mr1160163wbv.8.1296138838512; Thu, 27 Jan 2011 06:33:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Thu, 27 Jan 2011 06:33:34 -0800 (PST) In-Reply-To: <4D40945C.1070906@workingcode.com> References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> <4D3F13B3.9070706@workingcode.com> <4D3F1EAD.5040901@workingcode.com> <4D4065F2.3080305@gmail.com> <4D40945C.1070906@workingcode.com> From: Donald Eastlake Date: Thu, 27 Jan 2011 09:33:34 -0500 Message-ID: To: James Carlson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:30:56 -0000 Hi James, On Wed, Jan 26, 2011 at 4:38 PM, James Carlson w= rote: > Donald Eastlake wrote: >> I don't understand why you say that. Seem to me that TRILL over PPP >> just involves the formats, code points, and PPP procedures. Anyway, it >> isn't clear to me that anyone will build a practical RBridge that >> doesn't have a MAC address Ethernet interface even if it is just a >> virtual internal interface for a virtual internal end station. If that >> doesn't exist, you can't really address the RBridge for management or >> maintenance. > > Sure, you could. =A0It would just have to be addressed via IP (e.g., via > SNMP, ssh, or even TELNET) rather than by something locked into Ethernet. Really? RBridge don't route on IP addresses. They route based on nickname and, on ingress, they convert to nickname from MAC/VLAN. How are you going to get an RBridge to route on an IP address? Thanks, Donald > One could imagine a large TRILL bridge designed for telecom applications > exclusively on the interior of the cloud, where the only possible links > are point-to-point; no Ethernet need apply. > > Whether anyone ever builds that beast -- and, if so, whether it lacks > any built-in mechanism for automatic System ID assignment -- is a > different question. > > What we're really discussing is whether failing to cover this case with > some sort of automatic resolution is a hole in the specification (as I > think Mr. Simpson is contending), or whether it's just an unlikely > corner that implementors should be warned away from (as I believe). > > -- > James Carlson =A0 =A0 =A0 =A0 42.703N 71.076W =A0 =A0 =A0 =A0 From carlsonj@workingcode.com Thu Jan 27 06:47:32 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F06D3A68C6 for ; Thu, 27 Jan 2011 06:47:32 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOKa9EfnqnEg for ; Thu, 27 Jan 2011 06:47:31 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 531243A68C0 for ; Thu, 27 Jan 2011 06:47:30 -0800 (PST) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p0REoVqM006368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 09:50:31 -0500 (EST) Message-ID: <4D418637.10007@workingcode.com> Date: Thu, 27 Jan 2011 09:50:31 -0500 From: James Carlson User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Donald Eastlake References: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> <4D3F13B3.9070706@workingcode.com> <4D3F1EAD.5040901@workingcode.com> <4D4065F2.3080305@gmail.com> <4D40945C.1070906@workingcode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] [rbridge] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:47:32 -0000 On 01/27/11 09:33, Donald Eastlake wrote: > Hi James, > > On Wed, Jan 26, 2011 at 4:38 PM, James Carlson wrote: >> Donald Eastlake wrote: >>> I don't understand why you say that. Seem to me that TRILL over PPP >>> just involves the formats, code points, and PPP procedures. Anyway, it >>> isn't clear to me that anyone will build a practical RBridge that >>> doesn't have a MAC address Ethernet interface even if it is just a >>> virtual internal interface for a virtual internal end station. If that >>> doesn't exist, you can't really address the RBridge for management or >>> maintenance. >> >> Sure, you could. It would just have to be addressed via IP (e.g., via >> SNMP, ssh, or even TELNET) rather than by something locked into Ethernet. > > Really? RBridge don't route on IP addresses. They route based on > nickname and, on ingress, they convert to nickname from MAC/VLAN. How > are you going to get an RBridge to route on an IP address? You provide it with access to a management network, perhaps also through PPP. This could be done via separate interfaces or, if desired, by running IPCP in parallel with TRILL on the existing PPP links. Who said all management must be in-band with the data network? -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Thu Jan 27 09:28:27 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B4A3A696E for ; Thu, 27 Jan 2011 09:28:27 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HGZCEsBvOQy for ; Thu, 27 Jan 2011 09:28:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2E74D3A695E for ; Thu, 27 Jan 2011 09:28:26 -0800 (PST) Received: by iyi42 with SMTP id 42so1862769iyi.31 for ; Thu, 27 Jan 2011 09:31:30 -0800 (PST) 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=mEms3toBrEqhl9VNO9wJd6d2raYq+nS4JNwDa0ofU6Y=; b=sJt9wcMiAb7XN+daZNA15WXbVpiuvcqMSrMhPZk4vfZm+0hbjTYkV73zqrRTXsHR4T gPNB228bOuHOclA8BxY6GdvAEZ6MonKjuk7bvCXPL6g4+jD8qJXrWViTg56dMvajjxGa tKYe5v/ylPekvf4HRR85j6bsnzDfJ5kfUIvcE= 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=uF0ywChwYkyVIvkHAuiP4Z+2sQQ0f0j21vS3Z0av6L9/nbPNyybz59qKtHSo0FNq0n ckPuTklPpMPEmBDjsXdCCwL4gTF1jwugmjtM46KjZxxgNvDJPCcieM79Kip8WO6APLP5 qylLucyBp7QIvaXdJ2UwYiJhX7pVAqZubP4vc= Received: by 10.231.37.10 with SMTP id v10mr916827ibd.163.1296149490028; Thu, 27 Jan 2011 09:31:30 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id i16sm14002212ibl.6.2011.01.27.09.31.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 09:31:27 -0800 (PST) Message-ID: <4D41ABED.5070308@gmail.com> Date: Thu, 27 Jan 2011 12:31:25 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org References: <4D415111.4010009@gmail.com> In-Reply-To: <4D415111.4010009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: Re: [Pppext] proposed TRILL IS-IS System ID text X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:28:27 -0000 On 1/27/11 6:03 AM, William Allen Simpson wrote: > 3. An implementation that has only PPP links might have no previously > configured Media Access Control (MAC) that can function as an > IS-IS System ID. In this case, the System ID is formed by adding > a randomly generated 14-bit leading number (in place of an OUI) to > the link's unique LCP Magic Number. The Magic Number MUST be > unique for all links and all known link peers. This pseudo-MAC > MUST have both the "locally-assigned" and "broadcast/multicast" > (group) bits set to 1; that is, the least significant two bits of > the most significant octet are both set to 1. > Looking at this again, and remembering how fanatic the new RFC Editors (TM) are about abbreviations, probably needs to expand OUI, too: .... In this case, the System ID is formed by appending the link's unique 32-bit LCP Magic Number after a randomly generated 14-bit number in place of an Organizationally Unique Identifier (OUI). [Also makes the number of bits explicit: N/2**23 birthday attack; considerably less than having 2 identical MACs from the same vendor, or being killed by lightning. Could put that in the Security Considerations?] From carlsonj@workingcode.com Thu Jan 27 12:30:00 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811763A6A53 for ; Thu, 27 Jan 2011 12:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlwnHI81VRjd for ; Thu, 27 Jan 2011 12:29:59 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 37F303A6A3C for ; Thu, 27 Jan 2011 12:29:59 -0800 (PST) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p0RKX2V0011565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Jan 2011 15:33:02 -0500 (EST) Message-ID: <4D41D67E.7050807@workingcode.com> Date: Thu, 27 Jan 2011 15:33:02 -0500 From: James Carlson User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: pppext@ietf.org References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com> In-Reply-To: <4D41ABED.5070308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Subject: Re: [Pppext] proposed TRILL IS-IS System ID text X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:30:00 -0000 On 01/27/11 12:31, William Allen Simpson wrote: > On 1/27/11 6:03 AM, William Allen Simpson wrote: >> 3. An implementation that has only PPP links might have no previously >> configured Media Access Control (MAC) that can function as an >> IS-IS System ID. In this case, the System ID is formed by adding >> a randomly generated 14-bit leading number (in place of an OUI) to >> the link's unique LCP Magic Number. The Magic Number MUST be >> unique for all links and all known link peers. This pseudo-MAC >> MUST have both the "locally-assigned" and "broadcast/multicast" >> (group) bits set to 1; that is, the least significant two bits of >> the most significant octet are both set to 1. >> > Looking at this again, and remembering how fanatic the new RFC Editors (TM) > are about abbreviations, probably needs to expand OUI, too: > > .... In this case, the System ID is formed by appending > the link's unique 32-bit LCP Magic Number after a randomly generated > 14-bit number in place of an Organizationally Unique Identifier (OUI). > > [Also makes the number of bits explicit: N/2**23 birthday attack; > considerably less than having 2 identical MACs from the same vendor, or > being killed by lightning. Could put that in the Security Considerations?] Yes, I see where you're going with this. I don't think it's a "Security" issue. It's actually a correctness issue -- if there are duplicates, then IS-IS falls down. That aside, what you're suggesting is still a bit uncomfortable to me. You're essentially saying that this draft can forge up a new way of creating IS-IS System IDs on its own just to be helpful. I'm not so sure that it can or should. I think it's out of scope. While I certainly agree that, if implemented properly (and if existing system architectures allow implementation), what you're describing should work nicely, I don't want to run afoul of the IS-IS folks by tromping so squarely on their turf. In particular, IS-IS simply mandates that System IDs must be unique across the domain in which they're used. Not that they're "extremely unlikely to be duplicated" -- but that they're _never_ duplicated. The existing protocol clearly puts the responsibility for that in the hands of system implementers, not the link layer designers. Now, you're certainly within your rights to claim that MAC addresses are a feeble mechanism, and you may well be right that there are systems that duplicate them (though I can't say *I* have ever seen this), but the ISO people behind IS-IS appear (to me at least) to think differently. It's not a matter of statistics, or of field experience, but of specification. Instead, I think the issue you're talking about is really a fundamental issue in IS-IS itself, and is not one that is created by or altered by or in any way related to PPP or TRILL. IS-IS already supports point-to-point links without PPP or TRILL. And if you were to build an IS-IS router with only point-to-point links and without some source of a System ID, you would run into exactly this problem. But as the links on this hypothetical router are just plain old point-to-point links, you would not have the benefit of the mechanism you're proposing to have to this draft. And the same problem occurs if you run an IS-IS router with only PPP links using OSINLCP. So, it's not specifically a TRILL issue. It's the same problem, and it's not something that I think we ought to be addressing. We can certainly call it out, though. I think that if this is to be addressed -- it's probably the least important issue I can imagine in TRILL, and likely needs no fixing at all, as I strongly suspect that real systems won't have the problem -- it should be addressed in the TRILL IS-IS document, or perhaps in the base IS-IS documents themselves. It's IS-IS itself that demands a single unique System ID (PPP frankly doesn't care), and it's TRILL that demands zero configuration. At a minimum, I want to hear from IS-IS and TRILL experts before I go ahead with proposing any new random-number-based System ID mechanism. If they sign on, then I'll go ahead with it. But my off-the-cuff guess is that they'll have objections, and more objections probably aren't helpful in getting to consensus. -- James Carlson 42.703N 71.076W From carlsonj@workingcode.com Thu Jan 27 12:31:35 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EEC28C17C for ; Thu, 27 Jan 2011 12:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyVezx2b9W+i for ; Thu, 27 Jan 2011 12:31:34 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 4A95228C17B for ; Thu, 27 Jan 2011 12:31:34 -0800 (PST) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p0RKYalG011575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 15:34:36 -0500 (EST) Message-ID: <4D41D6DC.2040406@workingcode.com> Date: Thu, 27 Jan 2011 15:34:36 -0500 From: James Carlson User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: William Allen Simpson References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com> In-Reply-To: <4D41ABED.5070308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] proposed TRILL IS-IS System ID text X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 20:31:35 -0000 On 01/27/11 12:31, William Allen Simpson wrote: > On 1/27/11 6:03 AM, William Allen Simpson wrote: >> 3. An implementation that has only PPP links might have no previously >> configured Media Access Control (MAC) that can function as an >> IS-IS System ID. In this case, the System ID is formed by adding >> a randomly generated 14-bit leading number (in place of an OUI) to >> the link's unique LCP Magic Number. The Magic Number MUST be >> unique for all links and all known link peers. This pseudo-MAC >> MUST have both the "locally-assigned" and "broadcast/multicast" >> (group) bits set to 1; that is, the least significant two bits of >> the most significant octet are both set to 1. >> > Looking at this again, and remembering how fanatic the new RFC Editors (TM) > are about abbreviations, probably needs to expand OUI, too: > > .... In this case, the System ID is formed by appending > the link's unique 32-bit LCP Magic Number after a randomly generated > 14-bit number in place of an Organizationally Unique Identifier (OUI). > > [Also makes the number of bits explicit: N/2**23 birthday attack; > considerably less than having 2 identical MACs from the same vendor, or > being killed by lightning. Could put that in the Security Considerations?] [Sorry for the duplicate on the PPP list; Thunderbird hurt me with the CC-list again.] Yes, I see where you're going with this. I don't think it's a "Security" issue. It's actually a correctness issue -- if there are duplicates, then IS-IS falls down. That aside, what you're suggesting is still a bit uncomfortable to me. You're essentially saying that this draft can forge up a new way of creating IS-IS System IDs on its own just to be helpful. I'm not so sure that it can or should. I think it's out of scope. While I certainly agree that, if implemented properly (and if existing system architectures allow implementation), what you're describing should work nicely, I don't want to run afoul of the IS-IS folks by tromping so squarely on their turf. In particular, IS-IS simply mandates that System IDs must be unique across the domain in which they're used. Not that they're "extremely unlikely to be duplicated" -- but that they're _never_ duplicated. The existing protocol clearly puts the responsibility for that in the hands of system implementers, not the link layer designers. Now, you're certainly within your rights to claim that MAC addresses are a feeble mechanism, and you may well be right that there are systems that duplicate them (though I can't say *I* have ever seen this), but the ISO people behind IS-IS appear (to me at least) to think differently. It's not a matter of statistics, or of field experience, but of specification. Instead, I think the issue you're talking about is really a fundamental issue in IS-IS itself, and is not one that is created by or altered by or in any way related to PPP or TRILL. IS-IS already supports point-to-point links without PPP or TRILL. And if you were to build an IS-IS router with only point-to-point links and without some source of a System ID, you would run into exactly this problem. But as the links on this hypothetical router are just plain old point-to-point links, you would not have the benefit of the mechanism you're proposing to have to this draft. And the same problem occurs if you run an IS-IS router with only PPP links using OSINLCP. So, it's not specifically a TRILL issue. It's the same problem, and it's not something that I think we ought to be addressing. We can certainly call it out, though. I think that if this is to be addressed -- it's probably the least important issue I can imagine in TRILL, and likely needs no fixing at all, as I strongly suspect that real systems won't have the problem -- it should be addressed in the TRILL IS-IS document, or perhaps in the base IS-IS documents themselves. It's IS-IS itself that demands a single unique System ID (PPP frankly doesn't care), and it's TRILL that demands zero configuration. At a minimum, I want to hear from IS-IS and TRILL experts before I go ahead with proposing any new random-number-based System ID mechanism. If they sign on, then I'll go ahead with it. But my off-the-cuff guess is that they'll have objections, and more objections probably aren't helpful in getting to consensus. -- James Carlson 42.703N 71.076W From william.allen.simpson@gmail.com Fri Jan 28 09:44:13 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B893A6923 for ; Fri, 28 Jan 2011 09:44:13 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ff-wOHTJ4J4 for ; Fri, 28 Jan 2011 09:44:12 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 479AA3A6921 for ; Fri, 28 Jan 2011 09:44:12 -0800 (PST) Received: by iyi42 with SMTP id 42so3055916iyi.31 for ; Fri, 28 Jan 2011 09:47:19 -0800 (PST) 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=5IQfDxemZpKMfE0rVu70gtIMUi7DvLWebPKfxFXGWCk=; b=f7M7qAyhbUyTDluElGQW4G7XTA8pc3/OylNQf8D5vmaYqRbAqgJtWXQIHnsxuxDOvE BFCPZuG9UUpkFdixUIpXPx6wBBsWzWRKRhJNK3tNfzmyv4YhL3GbuTjWpMiYzEqUCxLy 7GXo+L1XsAo5oQ37a/ouCnCmPIPM2cenWU7vU= 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=ZuPtoBswi8yV7uyz0Ju8s2ySvp9T9VitIuMHwAi0cdQRuetYo2Uhq0aHKrsDP4wm2d 4B2Ela8ZTqJPwTsydgXeVayErEa1JbZn36ltq9KW9YYoAvX+W234JCkARKrcr+qUOQgr 7DGHt+SL5S8Ok6tULKlXwx/H6APX+bry+U/Z4= Received: by 10.42.167.74 with SMTP id r10mr4240037icy.80.1296236838875; Fri, 28 Jan 2011 09:47:18 -0800 (PST) Received: from Wastrel.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id gy41sm14951021ibb.11.2011.01.28.09.47.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 09:47:17 -0800 (PST) Message-ID: <4D430123.8010101@gmail.com> Date: Fri, 28 Jan 2011 12:47:15 -0500 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pppext@ietf.org References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com> <4D41D6DC.2040406@workingcode.com> In-Reply-To: <4D41D6DC.2040406@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rbridge@postel.org Subject: Re: [Pppext] proposed TRILL IS-IS System ID text X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 17:44:13 -0000 On 1/27/11 3:34 PM, James Carlson wrote: > On 01/27/11 12:31, William Allen Simpson wrote: >> On 1/27/11 6:03 AM, William Allen Simpson wrote: >>> 3. An implementation that has only PPP links might have no previously >>> configured Media Access Control (MAC) that can function as an >>> IS-IS System ID. In this case, the System ID is formed by adding >>> a randomly generated 14-bit leading number (in place of an OUI) to >>> the link's unique LCP Magic Number. The Magic Number MUST be >>> unique for all links and all known link peers. This pseudo-MAC >>> MUST have both the "locally-assigned" and "broadcast/multicast" >>> (group) bits set to 1; that is, the least significant two bits of >>> the most significant octet are both set to 1. >>> >> Looking at this again, and remembering how fanatic the new RFC Editors (TM) >> are about abbreviations, probably needs to expand OUI, too: >> >> .... In this case, the System ID is formed by appending >> the link's unique 32-bit LCP Magic Number after a randomly generated >> 14-bit number in place of an Organizationally Unique Identifier (OUI). >> >> [Also makes the number of bits explicit: N/2**23 birthday attack; >> considerably less than having 2 identical MACs from the same vendor, or >> being killed by lightning. Could put that in the Security Considerations?] > > [Sorry for the duplicate on the PPP list; Thunderbird hurt me with the > CC-list again.] > > Yes, I see where you're going with this. I don't think it's a > "Security" issue. It's actually a correctness issue -- if there are > duplicates, then IS-IS falls down. > Traditionally, we've put things that cause the implementation to fall over into the Security Considerations section. But heck, we could put it into the Operational Considerations section. Not a big deal.... > That aside, what you're suggesting is still a bit uncomfortable to me. > You're essentially saying that this draft can forge up a new way of > creating IS-IS System IDs on its own just to be helpful. I'm not so > sure that it can or should. I think it's out of scope. > It's a point-to-point link specific issue. In the IETF, it belongs in a PPP document. In the past, we had enough on our plates to ensure our *own* protocols worked. We didn't fuss about some other organization. > While I certainly agree that, if implemented properly (and if existing > system architectures allow implementation), what you're describing > should work nicely, I don't want to run afoul of the IS-IS folks by > tromping so squarely on their turf. > It's a sad comment on the IETF that it's become so fussy about "turf"! Remember the fights with ANSI T1 about defining a link layer over "their" bits? Or defining PPP over SONET/SDH (with two competing bodies)? Let's just get the job done. > In particular, IS-IS simply mandates that System IDs must be unique > across the domain in which they're used. Not that they're "extremely > unlikely to be duplicated" -- but that they're _never_ duplicated. The > existing protocol clearly puts the responsibility for that in the hands > of system implementers, not the link layer designers. > I cannot "clearly" find that "responsibility" anywhere in RFC-1142. Please cite references. Reminder: early PPP documents left a lot to the imagination of implementers, especially error recovery. It was more descriptive than prescriptive. That led to failure at Interop '90. It is the responsibility of protocol designers to completely specify the protocol, including error recovery! Only after changing to a prescriptive specification, PPP achieved wide-spread interoperability in '91. > Now, you're certainly within your rights to claim that MAC addresses are > a feeble mechanism, and you may well be right that there are systems > that duplicate them (though I can't say *I* have ever seen this), but > the ISO people behind IS-IS appear (to me at least) to think > differently. It's not a matter of statistics, or of field experience, > but of specification. > (Ahem) You seem to have forgotten the reasons for IETF existence, and the fun times we had with ISO, DECnet, CLNP, etc. (I have the T-shirt.) Apparently, you've never operated an ISP, nor read the NANOG list. Nor remember the problems with PPP multi-media bridges, as many companies reused the same MAC for different media. > Instead, I think the issue you're talking about is really a fundamental > issue in IS-IS itself, and is not one that is created by or altered by > or in any way related to PPP or TRILL. IS-IS already supports > point-to-point links without PPP or TRILL. And if you were to build an > IS-IS router with only point-to-point links and without some source of a > System ID, you would run into exactly this problem. But as the links on > this hypothetical router are just plain old point-to-point links, you > would not have the benefit of the mechanism you're proposing to have to > this draft. > > And the same problem occurs if you run an IS-IS router with only PPP > links using OSINLCP. So, it's not specifically a TRILL issue. > > It's the same problem, and it's not something that I think we ought to > be addressing. We can certainly call it out, though. > If you insist on waiting for ISO to issue a specification, then arguably you MUST wait to publish this document, as that would be a Normative Reference.... > I think that if this is to be addressed -- it's probably the least > important issue I can imagine in TRILL, and likely needs no fixing at > all, as I strongly suspect that real systems won't have the problem -- > it should be addressed in the TRILL IS-IS document, or perhaps in the > base IS-IS documents themselves. It's IS-IS itself that demands a > single unique System ID (PPP frankly doesn't care), and it's TRILL that > demands zero configuration. > Speaking authoritatively on this matter, PPP was intended to be zero configuration from the beginning! But I did pioneer the Operational Considerations section to handle any issues of configuration for special circumstances. > At a minimum, I want to hear from IS-IS and TRILL experts before I go > ahead with proposing any new random-number-based System ID mechanism. > If they sign on, then I'll go ahead with it. > > But my off-the-cuff guess is that they'll have objections, and more > objections probably aren't helpful in getting to consensus. > We don't have consensus now. From vjs@calcite.rhyolite.com Fri Jan 28 10:35:51 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62C43A67CF for ; Fri, 28 Jan 2011 10:35:51 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf0vo96+8Q36 for ; Fri, 28 Jan 2011 10:35:50 -0800 (PST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [IPv6:2001:4978:230::3]) by core3.amsl.com (Postfix) with ESMTP id 5FCDC3A63D3 for ; Fri, 28 Jan 2011 10:35:50 -0800 (PST) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.14.4/8.14.4) with ESMTP id p0SIcpjM094140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) env-from ; Fri, 28 Jan 2011 18:38:52 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.14.4/8.14.4/Submit) id p0SIco3F094139; Fri, 28 Jan 2011 18:38:50 GMT Date: Fri, 28 Jan 2011 18:38:50 GMT From: Vernon Schryver Message-Id: <201101281838.p0SIco3F094139@calcite.rhyolite.com> To: pppext@ietf.org In-Reply-To: <4D430123.8010101@gmail.com> X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Cc: rbridge@postel.org Subject: Re: [Pppext] proposed TRILL IS-IS System ID text X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 18:35:51 -0000 > From: William Allen Simpson > Apparently, you've never operated an ISP, nor read the NANOG list. > > Nor remember the problems with PPP multi-media bridges, as many companies > reused the same MAC for different media. > (Ahem) You seem to have forgotten the reasons for IETF existence, and the > fun times we had with ISO, DECnet, CLNP, etc. (I have the T-shirt.) > Speaking authoritatively on this matter, PPP was intended to be zero > configuration from the beginning! That sort of comment was inappropriate in the 1990s and is still inappropriate. Mr. Simpson's efforts to educate us in the histories of the IETF, PPP, the PPPEXT working group, SLIP, ISO and ITU conflicts and so forth are irrelevant. They're also unnecessary if the rest of us who could speak just as authoritatively on PPP have not slipped into senile dementia. They useless if we have. > > But my off-the-cuff guess is that they'll have objections, and more > > objections probably aren't helpful in getting to consensus. > > > We don't have consensus now. That is certainly not clear and I think it is wrong. We have one person objecting to the thrust of the TRILL draft and trying to use the eventual RFC to fix a potential or possible IS-IS configuration, installation, or implementation error. Consensus is not unanimity. More precisely, we do not have consensus for significantly changing the TRILL draft to fix IS-IS. I can't seem to get excited about TRILL, but I am convinced that fixing any lack of IS-IS auto-configuration or uniqueness of IS-IS identifiers is outside the scope of the PPPEXT working group and of this draft. It's not PPP that breaks if IS-IS's promise, premise, or demand for uniqueness is broken but IS-IS. Perhaps the TRILL document "call out" the issue, as Mr. Carlson said, but no more: > > It's the same problem, and it's not something that I think we ought to > > be addressing. We can certainly call it out, though. Vernon Schryver vjs@rhyolite.com From carlsonj@workingcode.com Fri Jan 28 11:07:18 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35AC23A680E for ; Fri, 28 Jan 2011 11:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cm2RgKmNZ1s4 for ; Fri, 28 Jan 2011 11:07:17 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id E6EA73A67F7 for ; Fri, 28 Jan 2011 11:07:16 -0800 (PST) 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 p0SJAD2d001235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jan 2011 14:10:14 -0500 (EST) Message-ID: <4D431494.6090906@workingcode.com> Date: Fri, 28 Jan 2011 14:10:12 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: William Allen Simpson References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com> <4D41D6DC.2040406@workingcode.com> <4D430123.8010101@gmail.com> In-Reply-To: <4D430123.8010101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org, rbridge@postel.org Subject: Re: [Pppext] proposed TRILL IS-IS System ID text X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 19:07:18 -0000 William Allen Simpson wrote: > On 1/27/11 3:34 PM, James Carlson wrote: >> That aside, what you're suggesting is still a bit uncomfortable to me. >> You're essentially saying that this draft can forge up a new way of >> creating IS-IS System IDs on its own just to be helpful. I'm not so >> sure that it can or should. I think it's out of scope. >> > It's a point-to-point link specific issue. In the IETF, it belongs in a > PPP document. In the past, we had enough on our plates to ensure our > *own* protocols worked. We didn't fuss about some other organization. The leap I think your argument might be making is that PPP is the only possible point-to-point protocol over which IS-IS would run, and that this is thus the right place to write this specification. I strongly disagree. The existing OSINLCP in PPP allows you to run IS-IS over PPP *TODAY*, and the problem you're citing isn't solved. Moreover, it isn't solved even if I put this special text into the draft under consideration, because this draft addresses only TRILL usage of PPP. And it's not fixed when IS-IS is run over _other_ point-to-point media. In other words, it's an IS-IS issue, not a PPP issue. >> While I certainly agree that, if implemented properly (and if existing >> system architectures allow implementation), what you're describing >> should work nicely, I don't want to run afoul of the IS-IS folks by >> tromping so squarely on their turf. >> > It's a sad comment on the IETF that it's become so fussy about "turf"! > > Remember the fights with ANSI T1 about defining a link layer over "their" > bits? Or defining PPP over SONET/SDH (with two competing bodies)? > > Let's just get the job done. If you don't like the word, then I can certainly use another. IS-IS operation is simply outside the purview of the IETF PPP Extensions working group. It's got nothing to do with us. We don't define IS-IS any more than we define SONET/SDH. We just live with it. I believe the best we can reasonably do here is say, gee, IS-IS people, it looks like you have a possibly ugly hole in your specification. If you care about it, please fix it, because we can't fix it for you. As a bonus, we can offer you these bits from our neck of the woods, if they'll help. >> In particular, IS-IS simply mandates that System IDs must be unique >> across the domain in which they're used. Not that they're "extremely >> unlikely to be duplicated" -- but that they're _never_ duplicated. The >> existing protocol clearly puts the responsibility for that in the hands >> of system implementers, not the link layer designers. >> > I cannot "clearly" find that "responsibility" anywhere in RFC-1142. Please > cite references. How about 7.1.1, where it's defined? ID, a 6 octet system identification. Correct operation of the routeing protocol requires that this field be unique within an area for End Systems and Level 1 Intermediate systems, and unique within the routeing domain for Level 2 Intermediate systems. It's unique; end of story. It doesn't say "you must demand this from your link layer interfaces." It doesn't say "you can optionally create one out of thin air by generating random numbers if you want." It doesn't even say whether administrative intervention is needed or desired. That puts it in the hands of the implementer. > It is the responsibility of protocol designers to completely specify the > protocol, including error recovery! Only after changing to a prescriptive > specification, PPP achieved wide-spread interoperability in '91. I agree, and I believe I've done that here. I think the only way I can comply with your demand is to put text like this into the draft: If the TRILL implementation using PPP links also uses IS-IS, then the IS-IS implementation MUST have a network-wide unique System ID. Commonly, this is derived from a link layer MAC address (which is not available on PPP) or from a system-wide MAC address (which may be available on certain systems). Acceptable means of determining a System ID for this use are covered in the IS-IS and TRILL IS-IS documentation. In other words, call out the issue, and effectively outlaw (via "MUST") the degenerate mode of operation where a system has only PPP links and _also_ has no means of getting a system-wide identifier. > Apparently, you've never operated an ISP, nor read the NANOG list. I refuse to respond to ad hominem attacks. Stick to the topic, please. >> It's the same problem, and it's not something that I think we ought to >> be addressing. We can certainly call it out, though. >> > If you insist on waiting for ISO to issue a specification, then arguably > you MUST wait to publish this document, as that would be a Normative > Reference.... I don't understand what you're saying. How is it Normative? What part of this specification changes in any way depending on what the IS-IS folks decide to do about this decades-old hole in their document? Do any of the PPP bits on the wire change as a result? Are there any configuration option changes? Or new packet formats? Or state machine variations? I see no dependency here at all, so no way the reference you're requiring could be Normative. It does not define the protocol. >> At a minimum, I want to hear from IS-IS and TRILL experts before I go >> ahead with proposing any new random-number-based System ID mechanism. >> If they sign on, then I'll go ahead with it. >> >> But my off-the-cuff guess is that they'll have objections, and more >> objections probably aren't helpful in getting to consensus. >> > We don't have consensus now. In observing the TRILL discussions with the IS-IS group, it seemed clear to me that making changes to IS-IS (beyond adding a few new data types) was not a substantial area of interest. I still don't see why any sort of System ID fabrication mechanism needs to be part of this specification. It's not a requirement that any given TRILL implementation uses IS-IS. And even if a given TRILL/IS-IS system doesn't have PPP links, the implementor already has substantial issues to resolve in getting the System ID right. (E.g., dealing with hot-swap hardware is a very interesting problem.) I do not believe it's PPP's fault if a given IS-IS implementation can't get the System ID it needs to run. It wouldn't be Ethernet's fault, either, if the implementor doesn't know how to deal with hot-swap, and uses a "bad" MAC address as a result. I think the fix you're proposing just polishes the tip of an iceberg. -- James Carlson 42.703N 71.076W From d3e3e3@gmail.com Sun Jan 30 19:36:24 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E973A6B74 for ; Sun, 30 Jan 2011 19:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.391 X-Spam-Level: X-Spam-Status: No, score=-103.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bKZKYD9vjUC for ; Sun, 30 Jan 2011 19:36:23 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 739413A6B62 for ; Sun, 30 Jan 2011 19:36:23 -0800 (PST) Received: by wyf23 with SMTP id 23so5299704wyf.31 for ; Sun, 30 Jan 2011 19:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=lD/E62Kwd9eoNNuHCG42KNyQHfq48krMMry1fjwqnaE=; b=PNnxRJn87Wfl5Z/cTU7VlTcjUTcb7waV8Ak5Pi/mZSQvw8J1Yxu0v6J1MjQuxSNcql lHRABGQXVRnFKYEVJviBm7oRSQyweewt1s9/54AVTu7drn+qTddGlqvUdYsO7Urd1YZT Q7vCp9f3erqV9q4UP1x5GJ8/j6hr3Url/3PLw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=jr7Jh7g2E39lxL0sVtSOezyC/rEVzK9h3wMx90LEGoaqb1U0CvMjSkjIFkeL/LnJcK KLqBPSoY1Smqoj0u3FxotNm/73qLkmEQhzZ3GUJhfBDI+aH1mAtmtkGxJP66TqzEYzFo gOHtlhg+GBB6ZECfh+SG9AENiDu24U4pA2htk= Received: by 10.227.144.213 with SMTP id a21mr813865wbv.8.1296445175989; Sun, 30 Jan 2011 19:39:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.61.81 with HTTP; Sun, 30 Jan 2011 19:39:13 -0800 (PST) In-Reply-To: <4D41D6DC.2040406@workingcode.com> References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com> <4D41D6DC.2040406@workingcode.com> From: Donald Eastlake Date: Sun, 30 Jan 2011 22:39:13 -0500 Message-ID: To: pppext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rbridge@postel.org Subject: Re: [Pppext] proposed TRILL IS-IS System ID text X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 03:36:24 -0000 On 01/27/11 12:31, William Allen Simpson wrote: > On 1/27/11 6:03 AM, William Allen Simpson wrote: >> 3. An implementation that has only PPP links might have no previously >> configured Media Access Control (MAC) that can function as an >> IS-IS System ID. In this case, the System ID is formed by adding >> a randomly generated 14-bit leading number (in place of an OUI) to >> the link's unique LCP Magic Number. I think it is a very bad idea to mandate this method which, as far as I know, is radically different from all methods currently in use. For example, some manufacturers just allocate a 48-bit number related to their MAC address space for each switch and use that as the System ID regardless of the type of any switch interfaces or the MAC addresses of any interfaces that have MAC addresses. Why should they change their behavior just because it happens that they have all PPP interfaces? Having all PPP interface is a state that could change dynamically. I would suggest, at a minimum, the following changes: - Replace the beginning with something more like "An RBridge that has only PPP interfaces might not have a conveniently available MAC address from which a System ID that would be unique across the campus can be derived. A possible statistical source of a System ID that implementors may wish to consider would be formed by ...." - Add a reference to [RFC4086] after "randomly generated". - Add a reference to [RFC5342] after "OUI". - The reference to "the link" is obviously problematic if their are more than one. Suggest changing to "a link". Even with the above changes, I'm pretty dubious. >> The Magic Number MUST be >> unique for all links and all known link peers. My impression from other posts is that you are not just trying to change how people do IS-IS, but aspects of how they do PPP as well. >> This pseudo-MAC >> MUST have both the "locally-assigned" and "broadcast/multicast" >> (group) bits set to 1; that is, the least significant two bits of >> the most significant octet are both set to 1. > > Looking at this again, and remembering how fanatic the new RFC Editors (T= M) > are about abbreviations, probably needs to expand OUI, too: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.... In this case, the System ID is formed= by appending > =A0 the link's unique 32-bit LCP Magic Number after a randomly generated > =A0 14-bit number in place of an Organizationally Unique Identifier (OUI)= . Sure. 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 =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com