From owner-ion@sunroof.eng.sun.com Thu Mar 2 05:05:03 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09355 for ; Thu, 2 Mar 2000 05:05:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09417; Thu, 2 Mar 2000 02:04:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA24063; Thu, 2 Mar 2000 02:03:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22A1n727858 for ion-dist; Thu, 2 Mar 2000 02:01:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22A1d927851 for ; Thu, 2 Mar 2000 02:01:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA24013; Thu, 2 Mar 2000 02:01:39 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA03269; Thu, 2 Mar 2000 03:01:37 -0700 (MST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA25899; Thu, 2 Mar 2000 11:00:42 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA14680; Thu, 2 Mar 2000 10:59:00 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 11:02:19 +0100 Message-ID: From: Petri Bernhard To: "'Gabriel Montenegro'" Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, "'ion@sunroof.eng.sun.com'" Subject: (ION) RE: [MOBILE-IP] Private addressing reference in rfc2002-bis ? Date: Thu, 2 Mar 2000 11:02:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ Hi Gabriel, my proposal wasn't to take oui's as another name space. Instead, I think, the basic question is whether to solve the handling of private IP addresses in Mobile IP by a kind of dns/nai-like solution or by something more directly related to the IP level itself. NAIs are currently used for authentication and identification purposes, and by using them, you can benefit from the existing DNS infrastructure. However, I currently don't see yet, how they could efficiently be inserted into every IP packet, e.g. between FA and HA (the HA somehow has to find the realm, a private IP address received in an IP packet belongs to). I would be very interested in your ideas about this. With regard to your questions on OUIs and realms, please note that not the OUI, but the whole VPN-ID (= OUI + index value, see RFC 2685) would be used to identify an IP address realm. This allows for various possibile uses or allocation algorithms, e.g.: - a big company runs its own corporate network, and uses one or more private address realms. In this case, the company may use its own OUI, and may allocate various identifiers for the particular realms - small companies may use the services of a network operator or service provider. If they use a private addressing realm, they may retrieve an index value from their operator or service provider - there's also the possibility that IANA acts as a neutral source for the allocation realm-IDs based on IANA's own OUI (0x00-00-5E). Although this is just a single OUI, it would allow IANA to allocate as much realm-IDs as we currently have IP addresses (4 byte value). Your suggestion to use AS numbers for the VPN-ID, and its implication of having one VPN-ID / realm ID per AS domain, was also discussed in the ION group at that time. The agreed format of the VPN-ID somehow reflects a compromise on this. While most people want to have their VPN-IDs / realm-IDs to be independent from the specific BGP-4 protocol domains, some in fact wanted to have 1 realm-ID per BGP-4 domain. The latter was the reason for the extension of the initial 3-octet index value (as in current MAC addresses) to 4-octets; this allows to sub-structure the index-values for a particular OUI into: 2-octet ASN + 2 octet ASN-specific index value. Looking forward to some more talks on this in Adelaide Kind regards - Bernhard Bernhard Petri, Siemens Tel: +49 89 722-34578 Fax: +49 89 722-29098 bernhard.petri@icn.siemens.de ______________________________ > -----Original Message----- > From: Gabriel Montenegro [SMTP:gab@eng.sun.com] > Sent: Saturday, February 26, 2000 1:59 AM > To: Petri Bernhard > Cc: 'Gabriel Montenegro'; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; > 'ion@sunroof.eng.sun.com' > Subject: RE: [MOBILE-IP] Private addressing reference in rfc2002-bis > ? > > interesting, thanks for the pointer to the vpn-id stuff. > hmmm... oui's are another name space... > > what i like about realm names is that there is no extra > administration overhead and they are already used within the > nai. from rfc2486 (nai): > > This document defines a new namespace that will need to be > administered, namely the NAI realm namespace. In order to to avoid > creating any new administrative procedures, administration of the NAI > realm namespace will piggyback on the administration of the DNS > namespace. > > NAI realm names are required to be unique and the rights to use a > given NAI realm for roaming purposes are obtained coincident with > acquiring the rights to use a particular fully qualified domain name > (FQDN). Those wishing to use an NAI realm name should first acquire > the rights to use the corresponding FQDN. Using an NAI realm without > ownership of the corresponding FQDN creates the possibility of > conflict and therefore is to be discouraged. > > also, what is the oui for the root realm? > > not all realms will map to a unique oui. in order to specify different > realms (for example for small/informal/impromptu/soho), owners of oui's > might > have to get in the business of further administering the subsequent > 4 byte octet index value in the vpn-id, to avoid collisions. it gets > messy, specially because the small network operators (driving forces > behind nats and rsip applications) now have to ask a much larger > corporation (large enough to own an oui) to allocate some vpn-id > space for them. perhaps oui's work best at the high-end, with large > corporations and ISP's. not sure they're a good easy thing to use > for smaller networks, where a DNS domain name may be simpler. > > by the way, if the idea is to use a fixed size binary representation > for a "vpn-id", did the ion working group consider > > in addition to this: > > 3 octet oui + 4 octet index value > > this?: > > 2 octet ASN (autonomous system number) + 4 octet index value > > saves you one byte, but most importantly, it reuses stuff that's > already needed as a precondition to getting on the internet. > seems like both oui and asn variations could be useful. > > regards, > > -gabriel X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Thu Mar 2 10:46:22 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15615 for ; Thu, 2 Mar 2000 10:46:21 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18460; Thu, 2 Mar 2000 07:46:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA13111; Thu, 2 Mar 2000 07:44:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22Fgpb28260 for ion-dist; Thu, 2 Mar 2000 07:42:51 -0800 (PST) Message-ID: <20000301195425.4369.qmail@web115.yahoomail.com> Date: Wed, 1 Mar 2000 11:54:25 -0800 (PST) From: sutirtha saha Subject: (ION) Query on RFC 1483 To: ion@sunroof.eng.sun.com Cc: kerou@lucent.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ Hello I am implementing a system which has the following layers: --------------- 802.1D Bridge --------------- RFC 1483 --------------- SAR Driver (AAL5) --------------- Utopia The BPDUs generated by the 802.1D has the following header: Ethernet Hdr - 01-80-C2-00-00-00,Src address(6 bytes), 2 byte length (0x003c) LLC Snap Header - 42-42-03 Protocol id, Version id and rest of BPDU... Now when I am sending the BPDU to the SAR Driver, I understand, that according to RFC 1483, I put a header on top of it. Now what header do I use ? Is it the one for 802.3 or is it the one given on page 9 of the RFC , ie 0xAA-AA-03-00-80-C2-00-0E ? If I use the one on Pg 9 of RFC 1483, my frame becomes: ------------------------ RFC Header (8 bytes) ------------------------ Ethernet Hdr(14 bytes) ---------------------- LLC Snap Hdr (3 bytes) ------------------------ Rest of BPDU ------------------------ Please confirm if my understanding is correct or am I missing anything. Also, I understand, that the BPDU will not need a LAN-FCS at the end. I was recommended this mailing list by Juha Heinanen, the author of RFC 1483 and I would be grateful to anyone who can answer me. Thanks and Regards Sutirtha __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Thu Mar 2 14:56:24 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23980 for ; Thu, 2 Mar 2000 14:56:22 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04241; Thu, 2 Mar 2000 11:56:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA08706; Thu, 2 Mar 2000 11:56:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22JsO929102 for ion-dist; Thu, 2 Mar 2000 11:54:24 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22Jrj929092 for ; Thu, 2 Mar 2000 11:53:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA08063 for ; Thu, 2 Mar 2000 11:53:03 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23200 for ; Thu, 2 Mar 2000 12:53:03 -0700 (MST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA06403 for ; Thu, 2 Mar 2000 11:52:25 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id LAA29863 for ; Thu, 2 Mar 2000 11:53:00 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 2 Mar 2000 11:52:54 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 14:52:52 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EE81@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Dean Willis'" , enum@ietf.org Cc: "ION Group (E-mail)" Subject: (ION) RE: [Enum] Portable unique identifiers Date: Thu, 2 Mar 2000 14:52:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ 1. An authority that manages globally unique IDs of a geographically "flat" address space exists already: the IEEE. I think that they could manage portable IDs as they manage MAC addresses. It's a similar problem, and no one seems to attribute partisanship there. 2. A name-to-number mapping would work too. I proposed such a scheme to the ATMF (atmf 98-0383) a couple of years ago. Any number of schemes could be adopted to do such a thing. Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@wcom.com] > Sent: Thursday, March 02, 2000 2:05 PM > To: Manfredi, Albert E; enum@ietf.org > Cc: ION Group (E-mail) > Subject: RE: [Enum] Portable unique identifiers > > > > Two points: > > 1) I enter domain addresses with some regularity on the 6-key > pad of my > Glenayre pager and the somewhat larger keypads of my Nokia > cellphone and the > (CLASSIFIED) sipphone on my desk at home. Seems to work OK. > > 2) Attempts to define the "One True Name" tend to be fraught > with peril. > Joke: Why not just make everyone in the world a US Taxpayer > and use their > Taxpayer ID Number (also called Social Security Number) as > their Universal > ID? But this points out the real problem -- Who will be the > root source of > Universal Identity? ICANN? Will any choice be acceptable to > the great mass > of users? We've even seen the single-root fight going on in > DNS regularly . > . . > > RFC 2486 seems to recognize that the answer to #2 is "no" -- > there will be > many sources of identity (domains) and many users or devices > will demand > multiple identities. I think that to make it really operable > requires a > single-root registry of domains, like DNS. > > I seem to remember proposals a while back to do a > name-to-number mapping, > such that any DNS name could be represented numerically using > a "tumbler" > (as coined by Ted Nelson) notation, dotted number sequences. This was > proposed as a way to simplify twelve-key entry for analog > phones. Perhaps > some revival of that approach might be feasible for our needs as well? > > -- > Dean > > > -----Original Message----- > > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > > Manfredi, Albert E > > Sent: Tuesday, February 29, 2000 4:04 PM > > To: 'enum@ietf.org' > > Cc: ION Group (E-mail) > > Subject: [Enum] Portable unique identifiers > > > > > > A short time ago, the topic of how to formulate portable identifiers > > relating to E.164 numbers was broached, and someone mentioned > > using RFC 2486 > > for this purpose. RFC 2486 seems appropriate at first > glance, because it > > addresses a similar problem, for roaming terminals. But I don't > > think it is > > the right approach for this application. > > > > RFC 2486 defines something called Network Access Identifier > > (NAI), which is > > a location-independent unique ID for a user. And the NAI > makes use of the > > same naming convention used in e-mail addressing: > username@realm. This is > > nice because it's a familiar and user-friendly format, but > it has two > > drawbacks for our purposes: > > > > 1. It is next to impossible to use such a scheme from a > small appliance, > > provided with keypad entry only (e.g. cell phone), and > > > > 2. The realm part of the unique ID ties the user to some > service provider, > > making the scheme less than totally portable. > > > > Instead, I propose that a number, perhaps 15 digits long, > identified by a > > unique prefix, would be about right. This would work with > the enum scheme > > already scoped out. It could even more easily work with the > > existing ATM End > > System Identifier (AESA) scheme defined in ATM. > > > > In the enum world, one might use a domain other than e164.int. > > This is not, > > after all, an E.164 number. > > > > In the AESA world, one could either define a specific > Address and Format > > Identifier (AFI) prefix for these AESAs, _or_ one can use > the AFI for the > > existing embedded E.164 format, and then make use of parts > of that 20-byte > > frame that are currently unused (the HO-DSP and ESI, for example). > > > > It seems possible to give these portable numbers some sort of > > hierarchy that > > is not geographically based, so as to even the load among > several servers. > > Not unlike what happens now with E.164. As you go down the > digits, the > > search is sent off to different servers. > > > > For fancy IP appliances that have a keyboard, RFC 2486 > would still be > > usable, of course. But there must also be a solution for the smaller > > appliance, I think. > > > > Bert > > albert.e.manfredi@boeing.com > > > > _______________________________________________ > > enum mailing list > > enum@ietf.org > > http://www.ietf.org/mailman/listinfo/enum > > > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Thu Mar 2 15:10:03 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24572 for ; Thu, 2 Mar 2000 15:10:03 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11661; Thu, 2 Mar 2000 12:10:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA12055; Thu, 2 Mar 2000 12:09:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22K88Y29338 for ion-dist; Thu, 2 Mar 2000 12:08:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22K80929331 for ; Thu, 2 Mar 2000 12:08:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA17828 for ; Thu, 2 Mar 2000 12:08:00 -0800 (PST) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18088 for ; Thu, 2 Mar 2000 12:07:59 -0800 (PST) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQieuy23962; Thu, 2 Mar 2000 20:07:56 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA05819; Thu, 2 Mar 00 15:05:01 EST Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA22152; Thu, 2 Mar 2000 15:07:55 -0500 Date: Thu, 2 Mar 2000 15:07:55 -0500 Message-Id: <200003022007.PAA22152@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Albert.Manfredi@PHL.Boeing.com Cc: dean.willis@wcom.com, enum@ietf.org, ion@sunroof.eng.sun.com Subject: Re: (ION) RE: [Enum] Portable unique identifiers References: <4102273CEB77D211869200805FE6F59356EE81@xch-phl-01.he.boeing.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ Content-Transfer-Encoding: 7bit I get the feeling I dropped into the middle of a long discussion (did it only just recently get redirected to include the ion list?). If the goal is to get unique identifiers that are easily administered and have no geographic significance, I agree with Bert that solutions to this have been around for a long time. IEEE, of course, assigns OUIs, which can be used to form MAC addresses. They can also be used to form new things, all you have to do is define that they start with the OUI as administered by IEEE. There are others. Object identifiers are globally unique, non-geographic, and hierarchically administered. They are variable length, which may be the wrong thing here. Several AESA choices are also suitable. DCD format AESAs are at least as flexible as IEEE OUI based IDs. In spite of what you might think, they do NOT have geographic significance. (The fact that a DCD starts with country code 840 means it was assigned by ANSI, but it says nothing whatsoever about the location of the entity identified by that number). So while I don't believe the issue of a single root is a real problem (the DNS "single root fight" claim doesn't sound like it is real), you in fact have several places to pick from already. paul X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Thu Mar 2 15:10:54 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24604 for ; Thu, 2 Mar 2000 15:10:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27316; Thu, 2 Mar 2000 12:08:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA26160; Thu, 2 Mar 2000 10:55:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22GLKJ28469 for ion-dist; Thu, 2 Mar 2000 08:21:20 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22GLA928462 for ; Thu, 2 Mar 2000 08:21:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA19784 for ; Thu, 2 Mar 2000 08:21:10 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA16983 for ; Thu, 2 Mar 2000 09:21:08 -0700 (MST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA23250 for ; Thu, 2 Mar 2000 08:20:30 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id IAA20670 for ; Thu, 2 Mar 2000 08:20:43 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 2 Mar 2000 08:20:31 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 11:20:26 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EE80@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'sutirtha saha'" , ion@sunroof.eng.sun.com Subject: RE: (ION) Query on RFC 1483 Date: Thu, 2 Mar 2000 11:20:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ RFC 2684 obsoletes RFC 1483. As this RFC explains, you have the option of assuming that a particular VC only carries one type of link layer protocol, in which case the PDU contains only the fields that would appear over that type of link layer. Or you can add a second wrapper around that, and identify explicitly that the enclosed PDU is 802.3, 802.4, 802.5, or 802.6. This might involve two different LLC headers: the one telling you that an encapsulated link layer PDU follows, and the LLC header that belongs to that encapsulated PDU. This is sort of a double-wrapped PDU. If the top LLC header reads LLC 0xAA-AA-03 OUI 0x00-80-C2, then you know that this is double-wrapped. A Protocol ID must follow this, and that Protocol ID will identify the encapsulated link layer (i.e. will tell you whether it's 802.3, 802.4, etc.). And inside that encapsulated PDU, you will maybe see another LLC header. For IEEE 802.3, you might see no other LLC header. For the others, you will. Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: sutirtha saha [mailto:sutirtha@yahoo.com] > Sent: Wednesday, March 01, 2000 2:54 PM > To: ion@sunroof.eng.sun.com > Cc: kerou@lucent.com > Subject: (ION) Query on RFC 1483 > > > Hello > I am implementing a system which has the following layers: > > --------------- > 802.1D Bridge > --------------- > RFC 1483 > --------------- > SAR Driver (AAL5) > --------------- > Utopia > > > > The BPDUs generated by the 802.1D has the following header: > Ethernet Hdr - 01-80-C2-00-00-00,Src address(6 bytes), 2 byte length > (0x003c) > LLC Snap Header - 42-42-03 > Protocol id, Version id and rest of BPDU... > > Now when I am sending the BPDU to the SAR Driver, I understand, that > according to RFC 1483, I put a header on top of it. Now what header do > I use ? Is it the one for 802.3 or is it the one given on > page 9 of the > RFC , ie 0xAA-AA-03-00-80-C2-00-0E ? > > If I use the one on Pg 9 of RFC 1483, my frame becomes: > > ------------------------ > RFC Header (8 bytes) > ------------------------ > Ethernet Hdr(14 bytes) > ---------------------- > LLC Snap Hdr (3 bytes) > ------------------------ > Rest of BPDU > ------------------------ > > Please confirm if my understanding is correct or am I missing > anything. > Also, I understand, that the BPDU will not need a LAN-FCS at the end. > I was recommended this mailing list by Juha Heinanen, the > author of RFC > 1483 and I would be grateful to anyone who can answer me. > > Thanks and Regards > Sutirtha > > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com > > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with > X-Info: 'unsubscribe ion' in the body of the message. > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Thu Mar 2 16:09:31 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27143 for ; Thu, 2 Mar 2000 16:09:31 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11058; Thu, 2 Mar 2000 13:09:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01202; Thu, 2 Mar 2000 13:09:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22L6a629573 for ion-dist; Thu, 2 Mar 2000 13:06:36 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) with ESMTP id e22L6Q929566 for ; Thu, 2 Mar 2000 13:06:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA22965 for ; Thu, 2 Mar 2000 13:06:25 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18628 for ; Thu, 2 Mar 2000 13:06:22 -0800 (PST) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA02348 for ; Thu, 2 Mar 2000 13:05:42 -0800 (PST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id NAA29997 for ; Thu, 2 Mar 2000 13:06:17 -0800 (PST) Received: from xch-phlbh-01.he.boeing.com by slb-hub-01.boeing.com with ESMTP; Thu, 2 Mar 2000 13:06:08 -0800 Received: by xch-phlbh-01.he.boeing.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Mar 2000 16:06:07 -0500 Message-Id: <4102273CEB77D211869200805FE6F59356EE83@xch-phl-01.he.boeing.com> From: "Manfredi, Albert E" To: "'Paul Koning'" Cc: enum@ietf.org, ion@sunroof.eng.sun.com Subject: RE: (ION) RE: [Enum] Portable unique identifiers Date: Thu, 2 Mar 2000 16:06:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ Paul Koning wrote: > I get the feeling I dropped into the middle of a long discussion (did > it only just recently get redirected to include the ion list?). Hi Paul. This is a spin-off of a similar discussion, which I think applies to enum and to ion. I am forwarding below a mailing made today on the "parent" thread. Agree on all your points, btw. Bert albert.e.manfredi@boeing.com ------ Forwarded message ------- From: Petri Bernhard [mailto:Bernhard.Petri@icn.siemens.de] Sent: Thursday, March 02, 2000 5:02 AM To: 'Gabriel Montenegro' Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; 'ion@sunroof.eng.sun.com' Subject: (ION) RE: [MOBILE-IP] Private addressing reference in rfc2002-bis ? Hi Gabriel, my proposal wasn't to take oui's as another name space. Instead, I think, the basic question is whether to solve the handling of private IP addresses in Mobile IP by a kind of dns/nai-like solution or by something more directly related to the IP level itself. NAIs are currently used for authentication and identification purposes, and by using them, you can benefit from the existing DNS infrastructure. However, I currently don't see yet, how they could efficiently be inserted into every IP packet, e.g. between FA and HA (the HA somehow has to find the realm, a private IP address received in an IP packet belongs to). I would be very interested in your ideas about this. With regard to your questions on OUIs and realms, please note that not the OUI, but the whole VPN-ID (= OUI + index value, see RFC 2685) would be used to identify an IP address realm. This allows for various possibile uses or allocation algorithms, e.g.: - a big company runs its own corporate network, and uses one or more private address realms. In this case, the company may use its own OUI, and may allocate various identifiers for the particular realms - small companies may use the services of a network operator or service provider. If they use a private addressing realm, they may retrieve an index value from their operator or service provider - there's also the possibility that IANA acts as a neutral source for the allocation realm-IDs based on IANA's own OUI (0x00-00-5E). Although this is just a single OUI, it would allow IANA to allocate as much realm-IDs as we currently have IP addresses (4 byte value). Your suggestion to use AS numbers for the VPN-ID, and its implication of having one VPN-ID / realm ID per AS domain, was also discussed in the ION group at that time. The agreed format of the VPN-ID somehow reflects a compromise on this. While most people want to have their VPN-IDs / realm-IDs to be independent from the specific BGP-4 protocol domains, some in fact wanted to have 1 realm-ID per BGP-4 domain. The latter was the reason for the extension of the initial 3-octet index value (as in current MAC addresses) to 4-octets; this allows to sub-structure the index-values for a particular OUI into: 2-octet ASN + 2 octet ASN-specific index value. Looking forward to some more talks on this in Adelaide Kind regards - Bernhard Bernhard Petri, Siemens Tel: +49 89 722-34578 Fax: +49 89 722-29098 bernhard.petri@icn.siemens.de ______________________________ > -----Original Message----- > From: Gabriel Montenegro [SMTP:gab@eng.sun.com] > Sent: Saturday, February 26, 2000 1:59 AM > To: Petri Bernhard > Cc: 'Gabriel Montenegro'; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; > 'ion@sunroof.eng.sun.com' > Subject: RE: [MOBILE-IP] Private addressing reference in rfc2002-bis > ? > > interesting, thanks for the pointer to the vpn-id stuff. > hmmm... oui's are another name space... > > what i like about realm names is that there is no extra > administration overhead and they are already used within the > nai. from rfc2486 (nai): > > This document defines a new namespace that will need to be > administered, namely the NAI realm namespace. In order to to avoid > creating any new administrative procedures, administration of the NAI > realm namespace will piggyback on the administration of the DNS > namespace. > > NAI realm names are required to be unique and the rights to use a > given NAI realm for roaming purposes are obtained coincident with > acquiring the rights to use a particular fully qualified domain name > (FQDN). Those wishing to use an NAI realm name should first acquire > the rights to use the corresponding FQDN. Using an NAI realm without > ownership of the corresponding FQDN creates the possibility of > conflict and therefore is to be discouraged. > > also, what is the oui for the root realm? > > not all realms will map to a unique oui. in order to specify different > realms (for example for small/informal/impromptu/soho), owners of oui's > might > have to get in the business of further administering the subsequent > 4 byte octet index value in the vpn-id, to avoid collisions. it gets > messy, specially because the small network operators (driving forces > behind nats and rsip applications) now have to ask a much larger > corporation (large enough to own an oui) to allocate some vpn-id > space for them. perhaps oui's work best at the high-end, with large > corporations and ISP's. not sure they're a good easy thing to use > for smaller networks, where a DNS domain name may be simpler. > > by the way, if the idea is to use a fixed size binary representation > for a "vpn-id", did the ion working group consider > > in addition to this: > > 3 octet oui + 4 octet index value > > this?: > > 2 octet ASN (autonomous system number) + 4 octet index value > > saves you one byte, but most importantly, it reuses stuff that's > already needed as a precondition to getting on the internet. > seems like both oui and asn variations could be useful. > > regards, > > -gabriel X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Thu Mar 2 19:03:18 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01953 for ; Thu, 2 Mar 2000 19:03:18 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05972; Thu, 2 Mar 2000 16:03:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA25656; Thu, 2 Mar 2000 16:02:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e2300Nu00032 for ion-dist; Thu, 2 Mar 2000 16:00:23 -0800 (PST) Message-Id: <4.3.2.20000302134352.00b7a720@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 02 Mar 2000 13:47:32 -0600 To: Dean Willis , "Manfredi, Albert E" , enum@ietf.org From: Richard Shockey Subject: (ION) RE: [Enum] Portable unique identifiers Cc: "ION Group (E-mail)" In-Reply-To: <001501bf847a$3e2bd600$ad9423a6@mcit.com> References: <4102273CEB77D211869200805FE6F59356EE74@xch-phl-01.he.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ > >2) Attempts to define the "One True Name" tend to be fraught with peril. >Joke: Why not just make everyone in the world a US Taxpayer and use their >Taxpayer ID Number (also called Social Security Number) as their Universal >ID? But this points out the real problem -- Who will be the root source of >Universal Identity? ICANN? ICANT opps ICANN.. God forbid.... >I seem to remember proposals a while back to do a name-to-number mapping, >such that any DNS name could be represented numerically using a "tumbler" >(as coined by Ted Nelson) notation, dotted number sequences. This was >proposed as a way to simplify twelve-key entry for analog phones. Perhaps >some revival of that approach might be feasible for our needs as well? > >-- >Dean I think the place to watch for this kind of solution is ITU SG2 where there has been a ongoing debate over the ESTI-TIPHON proposal for a global unique personal or IP oriented Country Code [878] +12 digits that could be given to every man woman and child on the planet. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ------- End of Forwarded Message ------- X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Thu Mar 2 19:16:40 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02086 for ; Thu, 2 Mar 2000 19:16:40 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11757; Thu, 2 Mar 2000 16:16:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA01690; Thu, 2 Mar 2000 16:01:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e22Nxdm00023 for ion-dist; Thu, 2 Mar 2000 15:59:40 -0800 (PST) Date: Thu, 02 Mar 2000 13:05:15 -0600 From: Dean Willis Subject: (ION) RE: [Enum] Portable unique identifiers In-reply-to: <4102273CEB77D211869200805FE6F59356EE74@xch-phl-01.he.boeing.com> To: "Manfredi, Albert E" , enum@ietf.org Cc: "ION Group (E-mail)" Message-id: <001501bf847a$3e2bd600$ad9423a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ Content-Transfer-Encoding: 7bit Two points: 1) I enter domain addresses with some regularity on the 6-key pad of my Glenayre pager and the somewhat larger keypads of my Nokia cellphone and the (CLASSIFIED) sipphone on my desk at home. Seems to work OK. 2) Attempts to define the "One True Name" tend to be fraught with peril. Joke: Why not just make everyone in the world a US Taxpayer and use their Taxpayer ID Number (also called Social Security Number) as their Universal ID? But this points out the real problem -- Who will be the root source of Universal Identity? ICANN? Will any choice be acceptable to the great mass of users? We've even seen the single-root fight going on in DNS regularly . . . RFC 2486 seems to recognize that the answer to #2 is "no" -- there will be many sources of identity (domains) and many users or devices will demand multiple identities. I think that to make it really operable requires a single-root registry of domains, like DNS. I seem to remember proposals a while back to do a name-to-number mapping, such that any DNS name could be represented numerically using a "tumbler" (as coined by Ted Nelson) notation, dotted number sequences. This was proposed as a way to simplify twelve-key entry for analog phones. Perhaps some revival of that approach might be feasible for our needs as well? -- Dean > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Manfredi, Albert E > Sent: Tuesday, February 29, 2000 4:04 PM > To: 'enum@ietf.org' > Cc: ION Group (E-mail) > Subject: [Enum] Portable unique identifiers > > > A short time ago, the topic of how to formulate portable identifiers > relating to E.164 numbers was broached, and someone mentioned > using RFC 2486 > for this purpose. RFC 2486 seems appropriate at first glance, because it > addresses a similar problem, for roaming terminals. But I don't > think it is > the right approach for this application. > > RFC 2486 defines something called Network Access Identifier > (NAI), which is > a location-independent unique ID for a user. And the NAI makes use of the > same naming convention used in e-mail addressing: username@realm. This is > nice because it's a familiar and user-friendly format, but it has two > drawbacks for our purposes: > > 1. It is next to impossible to use such a scheme from a small appliance, > provided with keypad entry only (e.g. cell phone), and > > 2. The realm part of the unique ID ties the user to some service provider, > making the scheme less than totally portable. > > Instead, I propose that a number, perhaps 15 digits long, identified by a > unique prefix, would be about right. This would work with the enum scheme > already scoped out. It could even more easily work with the > existing ATM End > System Identifier (AESA) scheme defined in ATM. > > In the enum world, one might use a domain other than e164.int. > This is not, > after all, an E.164 number. > > In the AESA world, one could either define a specific Address and Format > Identifier (AFI) prefix for these AESAs, _or_ one can use the AFI for the > existing embedded E.164 format, and then make use of parts of that 20-byte > frame that are currently unused (the HO-DSP and ESI, for example). > > It seems possible to give these portable numbers some sort of > hierarchy that > is not geographically based, so as to even the load among several servers. > Not unlike what happens now with E.164. As you go down the digits, the > search is sent off to different servers. > > For fancy IP appliances that have a keyboard, RFC 2486 would still be > usable, of course. But there must also be a solution for the smaller > appliance, I think. > > Bert > albert.e.manfredi@boeing.com > > _______________________________________________ > enum mailing list > enum@ietf.org > http://www.ietf.org/mailman/listinfo/enum > ------- End of Forwarded Message ------- X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Tue Mar 7 11:23:44 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03942 for ; Tue, 7 Mar 2000 11:23:39 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18160; Tue, 7 Mar 2000 09:22:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA06751; Tue, 7 Mar 2000 08:21:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Gamma0+Sun/8.10.0.Gamma0) id e27GK2c04628 for ion-dist; Tue, 7 Mar 2000 08:20:02 -0800 (PST) Message-ID: <38C52603.40EE2E6C@ind.alcatel.com> Date: Tue, 07 Mar 2000 21:23:39 +0530 From: Dilip Pandit Reply-To: dilip.pandit@ind.alcatel.com Organization: Alcatel Internetworking Development Centre X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ion@sunroof.eng.sun.com" Subject: (ION) status of I-PNNI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ Content-Transfer-Encoding: 7bit Is anyone aware of the status of I-PNNI? Cabletron was taking the lead in bringing out the spec at ATMF. But it seems to have remained at baseline doc stage since Mid 97. And the doc is grossly incomplete! Are there any implementations of it? Or is anyone taking the initiative at all? Thanks in advance, Dilip X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Wed Mar 8 04:29:21 2000 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26584 for ; Wed, 8 Mar 2000 04:29:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA02584; Wed, 8 Mar 2000 01:25:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA26888; Wed, 8 Mar 2000 01:25:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) id e289OYh05468 for ion-dist; Wed, 8 Mar 2000 01:24:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0+Sun/8.10.0) with ESMTP id e289OOw05461 for ; Wed, 8 Mar 2000 01:24:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA26833 for ; Wed, 8 Mar 2000 01:24:22 -0800 (PST) Received: from internet-gateway.zurich.ibm.com (internet-gateway-x.zurich.ibm.com [195.212.119.253]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA00421 for ; Wed, 8 Mar 2000 02:24:21 -0700 (MST) Received: from emme.zurich.ibm.com (emme.zurich.ibm.com [9.4.9.235]) by internet-gateway.zurich.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with SMTP id KAA28288; Wed, 8 Mar 2000 10:24:20 +0100 Received: from internet-gateway.zurich.ibm.com by emme.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25894 from ; Wed, 8 Mar 2000 10:24:15 +0100 Message-Id: <38C61C5D.C4C7F814@zurich.ibm.com> Date: Wed, 08 Mar 2000 10:24:45 +0100 From: Patrick Droz Organization: IBM Research Division X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.10 i686) X-Accept-Language: en Mime-Version: 1.0 To: dilip.pandit@ind.alcatel.com Cc: "ion@sunroof.eng.sun.com" Subject: Re: (ION) status of I-PNNI References: <38C52603.40EE2E6C@ind.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ Content-Transfer-Encoding: 7bit Dilip, I-PNNI has been abandoned by the ATM Forum in particular by the RA group. There was a vote to remove it from the list of working items. On the other hand the Forum finished PAR (PNNI Augmented Routing) which can be seen as a first step into the direction of I-PNNI. Regards, Patrick Dilip Pandit wrote: > > Is anyone aware of the status of I-PNNI? Cabletron was taking the lead > in bringing out the spec at ATMF. But it seems to have remained at > baseline doc stage since Mid 97. And the doc is grossly incomplete! Are > there any implementations of it? Or is anyone taking the initiative at > all? > > Thanks in advance, > > Dilip > > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with > X-Info: 'unsubscribe ion' in the body of the message. -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-89-55 X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message. From owner-ion@sunroof.eng.sun.com Mon Mar 20 09:33:21 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25369 for ; Mon, 20 Mar 2000 09:33:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23528; Mon, 20 Mar 2000 07:23:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA01341; Mon, 20 Mar 2000 06:23:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) id e2KEM6r15576 for ion-dist; Mon, 20 Mar 2000 06:22:06 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1.Beta0+Sun/8.10.1.Beta0) with ESMTP id e2KELuN15569 for ; Mon, 20 Mar 2000 06:21:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA16671 for ; Mon, 20 Mar 2000 06:21:57 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28208 for ; Mon, 20 Mar 2000 06:21:50 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20182; Mon, 20 Mar 2000 09:21:44 -0500 (EST) Message-Id: <200003201421.JAA20182@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ion@sunroof.eng.sun.com From: The IESG Subject: (ION) Document Action: Proxy PAR to Informational Date: Mon, 20 Mar 2000 09:21:44 -0500 Sender: owner-ion@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to ion@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/ion/ The IESG has approved the Internet-Draft 'Proxy PAR' as a Informational. This document is the product of the Internetworking Over NBMA Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe ion' in the body of the message.