From owner-bgmp@catarina.usc.edu Tue Feb 15 00:32:35 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06744 for ; Tue, 15 Feb 2000 00:32:34 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id VAA05575 for bgmp-list; Mon, 14 Feb 2000 21:20:23 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from mail.rdc1.va.home.com (imail@ha1.rdc1.va.home.com [24.2.32.66]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id VAA05570; Mon, 14 Feb 2000 21:20:20 -0800 (PST) From: jimstew@home.com Received: from cr604783-a ([24.113.88.250]) by mail.rdc1.va.home.com (InterMail v4.01.01.00 201-229-111) with SMTP id <20000215052010.FQCM21114.mail.rdc1.va.home.com@cr604783-a>; Mon, 14 Feb 2000 21:20:10 -0800 To: Rosemary.Whiteside@bus.utexas.edu Subject: The Jassen.com ChemMall Reply-To: jimstew@home.com Message-Id: <20000215052010.FQCM21114.mail.rdc1.va.home.com@cr604783-a> Date: Mon, 14 Feb 2000 21:20:11 -0800 Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Information as requested: "The Jassen.com ChemMall enables you to search, locate and instantly order the specialty chemical cleaning and maintenance products you need directly from our associates online stores." http://www.jassen.com/index.htm mailto:info@jassen.com From owner-bgmp@catarina.usc.edu Wed Feb 16 17:10:31 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16321 for ; Wed, 16 Feb 2000 17:10:24 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id NAA19748 for bgmp-list; Wed, 16 Feb 2000 13:33:50 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from dthaler.microsoft.com ([131.107.152.20]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id NAA19743 for ; Wed, 16 Feb 2000 13:33:47 -0800 (PST) Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id PAA18257; Wed, 16 Feb 2000 15:10:49 -0800 (PST) (envelope-from dthaler) From: Dave Thaler Message-Id: <200002162310.PAA18257@dthaler.microsoft.com> Subject: BGMP Identifier To: bgmp@catarina.usc.edu Date: Wed, 16 Feb 2000 15:10:46 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit The description of "BGMP Identifier" in the OPEN message format states: > This 4-octet unsigned integer indicates the BGMP Identifier of > the sender. A given BGMP speaker sets the value of its BGMP > Identifier to a globally-unique value assigned to that BGMP > speaker (e.g., an IPv4 address). The value of the BGMP Identifier > is determined on startup and is the same for every BGMP session opened. Actually it turns out that the value need not be globally-unique, as long as it is unique among peers (i.e. no one peers with two different speakers that have the same BGMP Identifier). I'd like to ask for comments on how this should be handed in IPv6. Option A) Require using a 4-byte unique identifier of the IPv6 router (not an IPv6 address). Is it safe to assume that all BGMP speakers will have an IPv4 address that meets the uniqueness criteria above? Option B) Change the BGMP Identifier to be 16 bytes long in all cases. An IPv4 speaker can pad the first 12 bytes with 0's (same technique as an IPv4-compatible v6 address). Option C) There's a Reserved byte in the header which could be used to fill in an AddrFamily number which applies to the BGMP Identifier. This raises a potential issue in that you couldn't use the same BGMP Identifier to talk to v6 peers as you do for v4 peers. This might be okay. Option D) Make the BGMP Identifier variable length, based on whether the TCP connection is over IPv4 or IPv6. Same issue as (C) about having to use different local Identifiers for v4 vs v6. Comments? -Dave From owner-bgmp@catarina.usc.edu Thu Feb 17 00:30:07 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24156 for ; Thu, 17 Feb 2000 00:30:03 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id VAA21869 for bgmp-list; Wed, 16 Feb 2000 21:20:49 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id VAA21864; Wed, 16 Feb 2000 21:20:48 -0800 (PST) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id VAA31531; Wed, 16 Feb 2000 21:20:46 -0800 (PST) Message-Id: <200002170520.VAA31531@rumi.usc.edu> To: Dave Thaler cc: bgmp@catarina.usc.edu Subject: Re: BGMP Identifier In-reply-to: Your message of "Wed, 16 Feb 2000 15:10:46 PST." <200002162310.PAA18257@dthaler.microsoft.com> Date: Wed, 16 Feb 2000 21:20:46 -0800 From: Pavlin Ivanov Radoslavov Sender: owner-bgmp@catarina.usc.edu Precedence: bulk > The description of "BGMP Identifier" in the OPEN message format states: > > This 4-octet unsigned integer indicates the BGMP Identifier of > > the sender. A given BGMP speaker sets the value of its BGMP > > Identifier to a globally-unique value assigned to that BGMP > > speaker (e.g., an IPv4 address). The value of the BGMP Identifier > > is determined on startup and is the same for every BGMP session opened. > > Actually it turns out that the value need not be globally-unique, > as long as it is unique among peers (i.e. no one peers with two > different speakers that have the same BGMP Identifier). > > I'd like to ask for comments on how this should be handed in IPv6. > > Option A) Require using a 4-byte unique identifier of the IPv6 > router (not an IPv6 address). Is it safe to assume that > all BGMP speakers will have an IPv4 address that meets > the uniqueness criteria above? In the near future probably yes, but after X years the IPv4 addresses may have stock-market value :) > Option B) Change the BGMP Identifier to be 16 bytes long in all cases. > An IPv4 speaker can pad the first 12 bytes with 0's > (same technique as an IPv4-compatible v6 address). Is the BGMP ID used for anything else except in the OPEN message to resolve connection collision? Seems that the answer is "no" according to the I-D. Then I think that Option B is probably the easiest and cleanest solution without any negative impact or overhead. BTW, according to RFC2373 Section 2.5.4 there are two types of Embedded IPv4 addresses: * IPv4-compatible IPv6 addresses (used to represent the IPv4 addresses of nodes that understand IPv6). Those addresses have all zeros in front of the IPv4 address. * IPv4-mapped IPv6 addresses (used to represent the IPv4 addresses of nodes that do NOT understand IPv6). Those addresses have FFFF in front of the IPv4 address, and then 80 zeroes in front. You may want to use this convention in Option B. Pavlin > > Option C) There's a Reserved byte in the header which could be used > to fill in an AddrFamily number which applies to the > BGMP Identifier. This raises a potential issue in that > you couldn't use the same BGMP Identifier to talk to > v6 peers as you do for v4 peers. This might be okay. > > Option D) Make the BGMP Identifier variable length, based on > whether the TCP connection is over IPv4 or IPv6. > Same issue as (C) about having to use different > local Identifiers for v4 vs v6. > > Comments? > > -Dave From owner-bgmp@catarina.usc.edu Thu Feb 17 07:43:52 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10528 for ; Thu, 17 Feb 2000 07:43:51 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id EAA38602 for bgmp-list; Thu, 17 Feb 2000 04:29:50 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id EAA38596; Thu, 17 Feb 2000 04:29:48 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Thu, 17 Feb 2000 06:29:22 -0600 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1TWF9SYA; Thu, 17 Feb 2000 06:28:35 -0600 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DJLA24ZF; Thu, 17 Feb 2000 07:28:35 -0500 Message-ID: <38ABE90E.B87094E7@nortelnetworks.com> Date: Thu, 17 Feb 2000 07:26:54 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Pavlin Ivanov Radoslavov CC: Dave Thaler , bgmp@catarina.usc.edu Subject: Re: BGMP Identifier References: <200002170520.VAA31531@rumi.usc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pavlin Ivanov Radoslavov wrote: > > Option A) Require using a 4-byte unique identifier of the IPv6 > > router (not an IPv6 address). Is it safe to assume that > > all BGMP speakers will have an IPv4 address that meets > > the uniqueness criteria above? > > In the near future probably yes, but after X years the IPv4 > addresses may have stock-market value :) I don't like the idea of forcing an IPv6 node into having to generate a random 32 bit number for use as an identifier. I seems clunky. > > > > Option B) Change the BGMP Identifier to be 16 bytes long in all cases. > > An IPv4 speaker can pad the first 12 bytes with 0's > > (same technique as an IPv4-compatible v6 address). > > Is the BGMP ID used for anything else except in the OPEN message to > resolve connection collision? Seems that the answer is "no" > according to the I-D. Then I think that Option B is probably the > easiest and cleanest solution without any negative impact or > overhead. > > BTW, according to RFC2373 Section 2.5.4 there are two types of > Embedded IPv4 addresses: > * IPv4-compatible IPv6 addresses (used to represent the IPv4 > addresses of nodes that understand IPv6). Those addresses > have all zeros in front of the IPv4 address. > * IPv4-mapped IPv6 addresses (used to represent the IPv4 addresses > of nodes that do NOT understand IPv6). Those addresses have FFFF in > front of the IPv4 address, and then 80 zeroes in front. Would there be a reason to identify whether or not an IPv4 node knows how to speak IPv6 in BGMP? It also forces the IPv4 BGMP to know about the IPv6 stack. > > > > > Option C) There's a Reserved byte in the header which could be used > > to fill in an AddrFamily number which applies to the > > BGMP Identifier. This raises a potential issue in that > > you couldn't use the same BGMP Identifier to talk to > > v6 peers as you do for v4 peers. This might be okay. This approach allows you to use the same transport protocol independence that is in PIM. It would allow BGMP to support other protocols in addition to the IP protocols. It does increase the processing complexity since you have to parse the AddFamily field first in order to correctly process the identifier. > > > > > Option D) Make the BGMP Identifier variable length, based on > > whether the TCP connection is over IPv4 or IPv6. > > Same issue as (C) about having to use different > > local Identifiers for v4 vs v6. Kind of messy. What if you wanted to carry IPv6 BGMP over an IPv4 transport? Brian From owner-bgmp@catarina.usc.edu Thu Feb 24 12:21:22 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06344 for ; Thu, 24 Feb 2000 12:21:21 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id JAA29463 for bgmp-list; Thu, 24 Feb 2000 09:04:39 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id JAA29458 for ; Thu, 24 Feb 2000 09:04:38 -0800 (PST) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id JAA18985; Thu, 24 Feb 2000 09:02:07 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id JAA24931; Thu, 24 Feb 2000 09:02:05 -0800 (PST) Received: from baynetworks.com ([192.32.235.105]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id MAA03120; Thu, 24 Feb 2000 12:03:29 -0500 for Message-ID: <38B564A0.26BB56CD@baynetworks.com> Date: Thu, 24 Feb 2000 12:04:32 -0500 From: Brad Cain Reply-To: bcain@nortelnetworks.com Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: bgmp@catarina.usc.edu Subject: Re: BGMP Identifier References: <200002162310.PAA18257@dthaler.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave Thaler wrote: > > The description of "BGMP Identifier" in the OPEN message format states: > > This 4-octet unsigned integer indicates the BGMP Identifier of > > the sender. A given BGMP speaker sets the value of its BGMP > > Identifier to a globally-unique value assigned to that BGMP > > speaker (e.g., an IPv4 address). The value of the BGMP Identifier > > is determined on startup and is the same for every BGMP session opened. > > Actually it turns out that the value need not be globally-unique, > as long as it is unique among peers (i.e. no one peers with two > different speakers that have the same BGMP Identifier). > > I'd like to ask for comments on how this should be handed in IPv6. FYI This is from draft-ietf-ospf-ospfv3-stdreport-00.txt "(1) OSPF Router IDs, Area IDs and LSA Link State IDs remain at the IPv4 size of 32-bits. This was done in order to keep the size of LSAs small. As a result, OSPF for IPv6 Router IDs cannot be assigned as one of the router's IPv6 addresses -- IPv4 addresses may be assigned to routers implementing OSPF for IPv6 solely for the purpose of obtaining OSPF Router IDs." From owner-bgmp@catarina.usc.edu Tue Feb 29 17:53:13 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04510 for ; Tue, 29 Feb 2000 17:53:12 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA94445 for bgmp-list; Tue, 29 Feb 2000 14:20:17 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-bgmp@catarina.usc.edu using -f Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA94440 for ; Tue, 29 Feb 2000 14:20:16 -0800 (PST) Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA23445; Tue, 29 Feb 2000 14:18:25 -0800 Message-Id: <3.0.5.32.20000229141821.009eaaf0@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 29 Feb 2000 14:18:21 -0800 To: Marty Bickford From: Marty Bickford Subject: Call for Presentations: iBAND4 June 11-14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-bgmp@catarina.usc.edu Precedence: bulk Call for Papers - http://www.stardust.com/iband4/conference.htm --------------- iBAND4 - Advancing the Technology of Internet Bandwidth Management and Traffic Engineering Technical Conference - June 11-13 Workshops with DMTF - June 14 iBAND4 is the fourth in a series of events focused on innovation in the areas of bandwidth management and traffic engineering. iBAND5 will be co-located and run together with ISPCON. The goal of iBAND is to help IP network professionals at ISP's and enterprise's understand the direction of work being done by standards groups and vendors. These events have also become a meeting place for the folks driving innovation in the areas of bandwidth management and traffic engineering. iBAND attendees include IP network engineers, network architects, engineering and business executives, MIS and IT professionals, product and development managers, researchers and other innovators. You are invited to submit a presentation proposal. To aid you in submitting a proposal, please visit http://www.stardust.com/iband4/conference.htm If you do not wish to present, we hope you will mark your calendar to attend this fun and innovative conference. Email or call me with any questions. Sincerely, Marty --- Marty Bickford - 408.879.8080 (8081-fax) Stardust.com - http://www.stardust.com