Re: [rbridge] [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt]
Donald Eastlake <d3e3e3@gmail.com> Tue, 25 January 2011 18:24 UTC
Return-Path: <rbridge-bounces@postel.org>
X-Original-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Delivered-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C7B03A6816 for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Tue, 25 Jan 2011 10:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.877
X-Spam-Level:
X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=-0.278, 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 5F4jJWPjdtmJ for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Tue, 25 Jan 2011 10:24:04 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 0DF473A6811 for <trill-archive-Osh9cae4@lists.ietf.org>; Tue, 25 Jan 2011 10:24:03 -0800 (PST)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0PI9qV8021769; Tue, 25 Jan 2011 10:09:55 -0800 (PST)
Received: from mail-qw0-f52.google.com (mail-qw0-f52.google.com [209.85.216.52]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p0PI9BTk021569 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rbridge@postel.org>; Tue, 25 Jan 2011 10:09:20 -0800 (PST)
Received: by qwi4 with SMTP id 4so38764qwi.39 for <rbridge@postel.org>; 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 <d3e3e3@gmail.com>
Date: Tue, 25 Jan 2011 13:08:50 -0500
Message-ID: <AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com>
To: James Carlson <carlsonj@workingcode.com>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: d3e3e3@gmail.com
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id p0PI9BTk021569
Cc: pppext@ietf.org, rbridge@postel.org
Subject: Re: [rbridge] [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: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org
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 ============================= Donald E. Eastlake 3rd 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Jan 24, 2011 at 8:16 PM, James Carlson <carlsonj@workingcode.com> wrote: > 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 <carlsonj@workingcode.com> > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext > _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge
- [rbridge] Fwd: [Pppext] I-D Action:draft-ietf-ppp… Donald Eastlake
- [rbridge] working group last call for PPP TRILL p… James Carlson
- Re: [rbridge] [Pppext] working group last call fo… James Carlson
- Re: [rbridge] [Pppext] working group last call fo… James Carlson
- Re: [rbridge] [Pppext] working group last call fo… James Carlson
- Re: [rbridge] [Pppext] working group last call fo… Donald Eastlake
- Re: [rbridge] [Pppext] working group last call fo… Donald Eastlake
- Re: [rbridge] [Pppext] working group last call fo… Donald Eastlake
- Re: [rbridge] [Pppext] working group last call fo… James Carlson
- Re: [rbridge] [Pppext] working group last call fo… Vishwas Manral
- Re: [rbridge] [Pppext] working group last call fo… James Carlson
- Re: [rbridge] [Pppext] working group last call fo… James Carlson
- Re: [rbridge] [Pppext] working group last call fo… Donald Eastlake
- Re: [rbridge] [Pppext] working group last call fo… James Carlson
- Re: [rbridge] [Pppext] working group last call fo… Donald Eastlake
- Re: [rbridge] [Pppext] working group last call fo… James Carlson