[rbridge] Draft problem statement

[aidan at nicta.com.au (Aidan Williams)]

Erik Nordmark wrote:
>  > I think of mobility in rbridge-style networks as host moving within a
>  > network infrastructure of bridge/routers that very rarely moves/changes.
> 
> Apart from a bridged enterprise networks with multiple 802.11 APs;
> the hosts end up moving between the APs.
> 
> In that case, if you replace the bridges with rbridges/hybrids
> (I can't decide if "rbridge" denotes a particular proposal for a solution or
> the general concept matching the problem statement, which is
> why I also use "hybrid". Wack me over the head if this is more
> confusing and we should use "rbridge" for the general concept.)
> then the result will be that the hosts might move from under one
> rbridge to under another.
> 

Sorry about the language confusion..  I wasn't intending bridge/router 
to be referring to certain types of equipment, rather I wanted to be 
descriptive.  Let me try again.

I think we are looking at networks in which:

   - There are things that connect links together.
     (bridges, routers, 802.11 APs, ...)

   - There are things that connect to links only.
     (hosts)

   - The topology of things that connect links together
     rarely changes (or if you prefer, moves) although
     we want to make it simple to connect new links.

   - The things that connect to links only are more likely
     to change their point of attachement.

If you accept this, then our design space has somewhere stable to store 
state about the network as a whole -- ie in the "things that connect 
links together".

We could use the term "ipvlx networks" to refer to the problem statement 
concept...

regards
	aidan
____
:wq!


Received: from miews.localhost ([129.94.138.139]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4UMr5J01560 for <[e-mail]>; Sun, 30 May 2004 15:53:06 -0700 (PDT)
Received: from nicta.com.au (localhost [127.0.0.1]) by miews.localhost (Postfix) with ESMTP id 9EEB987234; Mon, 31 May 2004 08:52:47 +1000 (EST)
Message-ID: <[e-mail]>
Date: Mon, 31 May 2004 08:52:47 +1000
From: Aidan Williams <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 30 May 2004 22:53:56 -0000
Status: RO
Content-Length: 1648

Erik Nordmark wrote:
>  > I think of mobility in rbridge-style networks as host moving within a
>  > network infrastructure of bridge/routers that very rarely moves/changes.
> 
> Apart from a bridged enterprise networks with multiple 802.11 APs;
> the hosts end up moving between the APs.
> 
> In that case, if you replace the bridges with rbridges/hybrids
> (I can't decide if "rbridge" denotes a particular proposal for a solution or
> the general concept matching the problem statement, which is
> why I also use "hybrid". Wack me over the head if this is more
> confusing and we should use "rbridge" for the general concept.)
> then the result will be that the hosts might move from under one
> rbridge to under another.
> 

Sorry about the language confusion..  I wasn't intending bridge/router 
to be referring to certain types of equipment, rather I wanted to be 
descriptive.  Let me try again.

I think we are looking at networks in which:

   - There are things that connect links together.
     (bridges, routers, 802.11 APs, ...)

   - There are things that connect to links only.
     (hosts)

   - The topology of things that connect links together
     rarely changes (or if you prefer, moves) although
     we want to make it simple to connect new links.

   - The things that connect to links only are more likely
     to change their point of attachement.

If you accept this, then our design space has somewhere stable to store 
state about the network as a whole -- ie in the "things that connect 
links together".

We could use the term "ipvlx networks" to refer to the problem statement 
concept...

regards
	aidan
____
:wq!



Received: from WAPRDMSIMC03.gsm1900.org (wabod01s01.t-mobile.com [65.161.188.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4S3tvJ25477 for <[e-mail]>; Thu, 27 May 2004 20:55:57 -0700 (PDT)
Received: by waprdmsimc03.gsm1900.org with Internet Mail Service (5.5.2653.19) id <LW60LPT8>; Thu, 27 May 2004 20:55:51 -0700
Message-ID: <[e-mail]>
From: "Roeder, Konrad" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
Date: Thu, 27 May 2004 20:55:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2004 03:57:46 -0000
Status: RO
Content-Length: 3509

Message: 5
Date: Wed, 26 May 2004 17:27:24 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
To: "Developing a hybrid router/bridge." <[e-mail]>
Cc: Erik Nordmark <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed

>> 
>> I have a small question on this one. Suppose you have a rather large
>> campus with a rather large number of nodes moving around, and
>> you want to manage the whole thing as a single logical IP subnet.
>> 
>> If all the hybrid router/bridges in such a campus engaged in a
>> link-state routing protocol to keep track of the mobile nodes,
>> wouldn't there be a state and/or traffic scaling issue?
>> 
>I don't think state would be a problem. The database to keep
>track of endnodes would be no larger than if the RBridges were
>actual bridges. And this is very similar to CLNP, which for
>"level 1 routing" kept track of all the endnodes, and I believe
>fairly large level 1 areas were built (does anyone have any numbers?)
>
>But the other issue you bring up I think might be more important.
>I assume by "traffic scaling" you're not talking about
>data traffic, but instead the amount of link state information
>necessary to keep all the routers up-to-date about the
>location of all the endnodes.

>Hopefully the endnodes aren't *that* mobile. It's not being
>designed for mobile ad-hoc networking, but for
>wired networks. So endnode movement won't be
>very frequent. We just want it to be plug-and-play when it
>does happen.

It would be very limiting to state that this protocol is limited
to hard-wired networks only.  Many offices, hospitals, corporate
campusses, etc. are becoming unwired. 

Currently, many 802.11 wireless networks use one large subnet and
rely on a side effect of the protocol to "roam" (or hand-off) from 
one access point to another.  It's just like pulling the ethernet 
plug from a port in your office and walking down the hall and 
plugging back in again as long as the new port still serves up
the same subnet as before.

In wireless networks like airports or hotels, most subscribers
are in one place - at a certain gate or room.  A very small subset
may move from one access point to another.  I don't see why 
RBridge could not be implemented in wireless access points
(which currently are bridges) or in the access layer bridges
switches that the access points connect to.

>But on the other hand, endnodes might get powered down a lot.

In wireless 802.11 networks, this happens a lot too.  People 
simply walk off without closing their sessions.  They expect
that all accounting stops when they turn off their laptops.

>So the question is, how responsive should an RBridge be
>about declaring that it no longer owns an endnode?

>I'd suggest that as soon as an Rbridge discover a new
>neighbor endnode, it should announce it
>in its link state info. However, when it's down, unless it
>see some other RBridge claiming it in its
>link state info, there would be no harm
>in not telling anyone it is down, at least for awhile. If it
>has moved, the RBridge should immediately relinquish it so traffic goes
>to its new home. But if it has just powered down, it might be
>a problem in terms of traffic to let everyone know that.

So what do we do when a link goes down or is shut down?  Do we depend
on link-state age to wait for the link to come back up?  When do we 
advertise the change in the route?

>Radia

Konrad




Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4S0LqJ13512 for <[e-mail]>; Thu, 27 May 2004 17:21:52 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4S0Ll92008928;  Thu, 27 May 2004 18:21:49 -0600 (MDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4S0LiQ29956; Fri, 28 May 2004 02:21:45 +0200 (MEST)
Date: Thu, 27 May 2004 17:21:45 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
To: Aidan Williams <[e-mail]>
In-Reply-To: "Your message with ID" <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, [e-mail], Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2004 00:23:47 -0000
Status: RO
Content-Length: 688

> I think of mobility in rbridge-style networks as host moving within a 
> network infrastructure of bridge/routers that very rarely moves/changes.

Apart from a bridged enterprise networks with multiple 802.11 APs;
the hosts end up moving between the APs.

In that case, if you replace the bridges with rbridges/hybrids 
(I can't decide if "rbridge" denotes a particular proposal for a solution or
the general concept matching the problem statement, which is
why I also use "hybrid". Wack me over the head if this is more
confusing and we should use "rbridge" for the general concept.)
then the result will be that the hosts might move from under one
rbridge to under another.

  Erik




Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4S0I4J12443 for <[e-mail]>; Thu, 27 May 2004 17:18:04 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4S0HtoE006417;  Thu, 27 May 2004 17:17:55 -0700 (PDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4S0HpQ29877; Fri, 28 May 2004 02:17:51 +0200 (MEST)
Date: Thu, 27 May 2004 17:17:52 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
To: Aidan Williams <[e-mail]>
In-Reply-To: "Your message with ID" <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, [e-mail], Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2004 00:18:47 -0000
Status: RO
Content-Length: 2342

> It was the thinking that was going on around (perhaps prior) to the 
> ND-proxy-based multilink subnet work.
> 
> I think (expired) drafts
>    draft-thaler-ipngwg-multilink-subnets-0[012].txt
> are worth a read because they list some design goals and three 
> approaches to a solution.

I'm aware of that draft. That problem statement is slightly different
in that it makes a distinction between link-local and subnet-local
traffic. For instance, link-local doesn't see its ttl decrement but 
subnet-local traffic would see the ttl decremented by each router.

I think with that approach the interaction between the new hybrid
bridge/routers and the existing routers is different than in the case when the
single link spans the hybrids.

If we assume that the hybrids would not participate in the site's routing
protocol (neither listening or injecting routes) then the hybrids are
limited to learning the default routers from the router advertisements.
But the existing router advertisements are not sufficient since
they can't be used to tell the difference between a router and a hybrid.
Once you address this you have the optimality and redirect issue:

	Router 1                Router 2
	   |                       |
	   -------------------------
	   |                       |
	Hybrid 1                Hybrid 2
	   |                       |
	   -------------------------
	                |
			Host

The host is sending packets to hybrid1 as the next-hop.
If this packet makes it to Router one but the optimal router is R2,
then you need to get both the host and the hybrids in the network to
heed the redirect.

> I think supporting differing MAC address formats is a worthwhile design 
> goal.  If we had IP bridging we could bridge IP datagrams directly to 
> Bluetooth devices, Firewire, IRDA, [insert new L2] and avoid the 
> redundant ppp or ethernet encapsulation cruft that gets added.  Having 
> worked in the home networking space in my previous job, I think it would 
> be a boon.

Assuming it can be done, which is far from clear to me.

> Because the home is an environment where people will plug stuff together 
> in wierd ways, robust loop prevention is very important.  Having some 
> things that do ND-proxy/ARP-proxy without loop detection/prevention 
> feels like a disaster waiting to happen.

Agree 100%.

  Erik



Received: from miews.localhost ([129.94.138.139]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4RNQhJ01411 for <[e-mail]>; Thu, 27 May 2004 16:26:43 -0700 (PDT)
Received: from nicta.com.au (localhost [127.0.0.1]) by miews.localhost (Postfix) with ESMTP id 4060185FD9; Fri, 28 May 2004 09:26:37 +1000 (EST)
Message-ID: <[e-mail]>
Date: Fri, 28 May 2004 09:26:36 +1000
From: Aidan Williams <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 23:27:46 -0000
Status: RO
Content-Length: 923

Erik Nordmark wrote:
> I think Manet is looking at cases when everything moves (including routers
> in the sense that nodes relay packets for other nodes). At that end
> of the scale if you propagate all movement information to everybody
> you might end up using more bandwidth for the routing updates than
> data traffic (especially if each host/node does not generate much traffic).
> Hence it makes sense to look at propagating information in limited scopes
> and/or being able to find a node on demand when there is a packet
> for that node.
> If you instead start off at the end of the scale where almost nothing moves,
> then it makes sense optimizing the data path by propagating information
> about movement everywhere whether or not there is data traffic.
> 

I think of mobility in rbridge-style networks as host moving within a 
network infrastructure of bridge/routers that very rarely moves/changes.

- aidan



Received: from miews.localhost ([129.94.138.139]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4RNM9J00405 for <[e-mail]>; Thu, 27 May 2004 16:22:13 -0700 (PDT)
Received: from nicta.com.au (localhost [127.0.0.1]) by miews.localhost (Postfix) with ESMTP id 1A20385FD6; Fri, 28 May 2004 09:22:03 +1000 (EST)
Message-ID: <[e-mail]>
Date: Fri, 28 May 2004 09:22:02 +1000
From: Aidan Williams <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 23:22:46 -0000
Status: RO
Content-Length: 2398

Erik Nordmark wrote:
>  >   The "multilink" proposal at the time had scope to become more than an
>  > ARP/ND proxy.  It was heading toward "IP bridging".  Work had been done
>  > looking at IS-IS as the underlying routing mechanism ("host routes") and
>  > on getting DHCP to work.
> 
> Was this the ND-proxy-based multilink subnet work, or was there
> some other body of work that you are thinking of?
> 

It was the thinking that was going on around (perhaps prior) to the 
ND-proxy-based multilink subnet work.

I think (expired) drafts
   draft-thaler-ipngwg-multilink-subnets-0[012].txt
are worth a read because they list some design goals and three 
approaches to a solution.

What ended up being pushed forward in the ipv6 wg was the ND-proxy approach.

>  > On the other hand, an "IP-bridging" solution would better handle
>  > incompatible L2 links (ie links with different MAC address formats and
>  > MTUs).
> 
> I suspect that there can be many potential requirements here.
> While I haven't thought much about it, it might be that one can
> come up with robust solutions that provide 2 out of 3 (but not all 3 of):
>  - handle different MAC address formats
>  - invisible to the hosts e.g. not decrementing the IP ttl
>  - not restricted to sending data packets along a spanning tree
> 
> I certainly haven't seem something which claims to handle all 3, which is
> why I think we should be careful about not overconstraining the problem.
> 

I agree that there are many potential requirements.
I'm still thinking about the "not decrementing IP ttl" requirement.

> Personally I think that working across L2 links with different MAC address
> formats is lower priority than the other two above, but I'm interested in what
> others think about this.
> 

I think supporting differing MAC address formats is a worthwhile design 
goal.  If we had IP bridging we could bridge IP datagrams directly to 
Bluetooth devices, Firewire, IRDA, [insert new L2] and avoid the 
redundant ppp or ethernet encapsulation cruft that gets added.  Having 
worked in the home networking space in my previous job, I think it would 
be a boon.

Because the home is an environment where people will plug stuff together 
in wierd ways, robust loop prevention is very important.  Having some 
things that do ND-proxy/ARP-proxy without loop detection/prevention 
feels like a disaster waiting to happen.

- aidan


Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4RLtMJ09982 for <[e-mail]>; Thu, 27 May 2004 14:55:22 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4RLtGZ06578; Thu, 27 May 2004 14:55:16 -0700
X-mProtect: <200405272155> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdaMdhGX; Thu, 27 May 2004 14:55:14 PDT
Message-ID: <[e-mail]>
Date: Thu, 27 May 2004 14:55:29 -0700
From: Fred Templin <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Name that BoF
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 21:55:45 -0000
Status: RO
Content-Length: 274

All silliness aside, I think that if we want to use IP Virtual Link 
eXtension
we should simply list the acronym as all lower-case (i.e., 'ipvlx') and say
nothing at all about suggested pronounciations or roman numeral 
coincidences.

Thanks - Fred
[e-mail]



Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4RLaPJ04825 for <[e-mail]>; Thu, 27 May 2004 14:36:25 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4RLaJl18838; Thu, 27 May 2004 14:36:19 -0700
X-mProtect: <200405272136> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4KwpCo; Thu, 27 May 2004 14:36:17 PDT
Message-ID: <[e-mail]>
Date: Thu, 27 May 2004 14:36:31 -0700
From: Fred Templin <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Name that BoF
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 21:36:48 -0000
Status: RO
Content-Length: 899

Erik Nordmark wrote:

>>I wasn't going to mention this, but the pronounciation you are
>>suggesting seems a bit awkward and unnatural - at least from
>>the perspective of a native american-english speaker.
>>    
>>
>
>Point taken.
>
>What I wanted to make sure is that we don't use the roman numeral
>observation as a pronounciation guide - I think pronouncing IPVLX
>as IPv60 would add so much confusion that it wouldn't be funny.
>

Agreed that we don't want to give rise to this kind  of confusion.
Still, the roman numerals present an interesting opportunity for
T-shirt slogans, etc.:

  "IPvLX: X times better than IPvVI"

>Apart from that, I don't care how it is pronounced.
>

Same here.

Thanks - Fred
[e-mail]

>
>   Erik
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>




Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4RLW6J03473 for <[e-mail]>; Thu, 27 May 2004 14:32:06 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4RLUUFT011960;  Thu, 27 May 2004 15:30:31 -0600 (MDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4RLW1Q20351; Thu, 27 May 2004 23:32:02 +0200 (MEST)
Date: Thu, 27 May 2004 14:32:01 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
Subject: RE: [rbridge] Draft problem statement
To: Alper Yegin <[e-mail]>
In-Reply-To: "Your message with ID" <001901c44387$7bac4570$[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "'Developing a hybrid router/bridge.'" <[e-mail]>, [e-mail], 'Erik Nordmark' <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 21:32:46 -0000
Status: RO
Content-Length: 2211

> But it is so tempting to use this for mobile ad-hoc networks, localized
> (or micro-) mobility management, etc :) And I think it is hard to
> prevent that. We should eventually have some understanding on the
> scalability characteristics, and maybe have some appropriate warning
> signs...

At an abstract level I think there are some traffic observations and
assumptions that drive for different approaches when you take movement into
account.

I think Manet is looking at cases when everything moves (including routers
in the sense that nodes relay packets for other nodes). At that end
of the scale if you propagate all movement information to everybody
you might end up using more bandwidth for the routing updates than
data traffic (especially if each host/node does not generate much traffic).
Hence it makes sense to look at propagating information in limited scopes
and/or being able to find a node on demand when there is a packet
for that node.
If you instead start off at the end of the scale where almost nothing moves,
then it makes sense optimizing the data path by propagating information
about movement everywhere whether or not there is data traffic.

For localized mobility management there might be (unstated?) assumtions
as well. For instance, and I'm speculating here, if you assume that
there is little or no local traffic between the mobile nodes i.e., almost 
all the traffic is to/from hosts outside the local part of the network,
then there isn't much use in propagating information above movement throughout
the network; it does make sense to propagate this information
so that packets arriving from the outside can be forwarded efficiently
towards the moving host.

If the rate of movement is low one can presumably live without any
optimizations based on the above assumptions, but the higher the rate of
movement the more suboptimal things would be compared to a solution that
explicitly optimizes for some movement pattern and traffic pattern.

It makes sense to me to first work out how a solution could work
assuming a low rate of movement and later look at how it behaves 
with a high rate of movement; otherwise I think the tradeoffs would be
way to complicated.

   Erik



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4RLIrJ00333 for <[e-mail]>; Thu, 27 May 2004 14:18:53 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4RLIm92022350;  Thu, 27 May 2004 15:18:49 -0600 (MDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4RLIkQ19653; Thu, 27 May 2004 23:18:46 +0200 (MEST)
Date: Thu, 27 May 2004 14:18:46 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
To: Aidan Williams <[e-mail]>
In-Reply-To: "Your message with ID" <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, [e-mail], Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 21:19:45 -0000
Status: RO
Content-Length: 1222

>   The "multilink" proposal at the time had scope to become more than an 
> ARP/ND proxy.  It was heading toward "IP bridging".  Work had been done 
> looking at IS-IS as the underlying routing mechanism ("host routes") and 
> on getting DHCP to work.

Was this the ND-proxy-based multilink subnet work, or was there
some other body of work that you are thinking of?

> On the other hand, an "IP-bridging" solution would better handle 
> incompatible L2 links (ie links with different MAC address formats and 
> MTUs).

I suspect that there can be many potential requirements here.
While I haven't thought much about it, it might be that one can
come up with robust solutions that provide 2 out of 3 (but not all 3 of):
 - handle different MAC address formats
 - invisible to the hosts e.g. not decrementing the IP ttl
 - not restricted to sending data packets along a spanning tree

I certainly haven't seem something which claims to handle all 3, which is
why I think we should be careful about not overconstraining the problem.

Personally I think that working across L2 links with different MAC address 
formats is lower priority than the other two above, but I'm interested in what
others think about this.

  Erik



Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4RLHKJ29876 for <[e-mail]>; Thu, 27 May 2004 14:17:20 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4RLHDw2016957 for <[e-mail]>; Thu, 27 May 2004 14:17:14 -0700 (PDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4RLHAQ19421; Thu, 27 May 2004 23:17:10 +0200 (MEST)
Date: Thu, 27 May 2004 14:17:10 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Name that BoF
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: "Your message with ID" <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail], Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 21:17:45 -0000
Status: RO
Content-Length: 458

> I wasn't going to mention this, but the pronounciation you are
> suggesting seems a bit awkward and unnatural - at least from
> the perspective of a native american-english speaker.

Point taken.

What I wanted to make sure is that we don't use the roman numeral
observation as a pronounciation guide - I think pronouncing IPVLX
as IPv60 would add so much confusion that it wouldn't be funny.

Apart from that, I don't care how it is pronounced.

   Erik



Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4RLAJJ28058 for <[e-mail]>; Thu, 27 May 2004 14:10:19 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4RL9ooE011618;  Thu, 27 May 2004 14:09:51 -0700 (PDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4RL9mQ18958; Thu, 27 May 2004 23:09:48 +0200 (MEST)
Date: Thu, 27 May 2004 14:09:48 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
To: Aidan Williams <[e-mail]>
In-Reply-To: "Your message with ID" <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 21:10:45 -0000
Status: RO
Content-Length: 772

> This paragraph doesn't make sense to me as written.  We are going to 
> develop mechanism that could be deployed in routers, bridges or hosts 
> and that would therefore change them.
> 
> Perhaps what is intended is some kind of backwards compatibility statement?
> 
> Perhaps:
> "The BoF will explore combining benefits of bridges and routers in a way 
> that will co-exist with existing hosts, IP routers and bridges.  The 
> design should support both IPv4 and IPv6."

Yes, your text is better. The original text makes sense if you assume there
will be some new type of device which is neither a host, bridge, or router
but it is just as likely that existing bridges and/or routers would have
new functionality added to do whatever solution we come up with.

  Erik



Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4RGXwJ04171 for <[e-mail]>; Thu, 27 May 2004 09:33:58 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4RGXpV11946; Thu, 27 May 2004 09:33:51 -0700
X-mProtect: <200405271633> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmNOPDe; Thu, 27 May 2004 09:33:49 PDT
Message-ID: <[e-mail]>
Date: Thu, 27 May 2004 09:34:03 -0700
From: Fred Templin <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Name that BoF
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 16:34:45 -0000
Status: RO
Content-Length: 995

Erik,

Erik Nordmark wrote:

>I'd expect this to be pronounced i-p-v-lex.
>  
>

I wasn't going to mention this, but the pronounciation you are
suggesting seems a bit awkward and unnatural - at least from
the perspective of a native american-english speaker.

Why not just pronounce it: 'i-p-v-l-x', i.e., as it is spelled? The
way you are suggesting ('i-p-v-lex') seems like it would require
a large amount of overhead in training the general populous for
no apparent gain, i.e., unless the trailing syllable 'lex' has some
particular significance to you?

Perhaps the better alternative in this case is to not suggest any
particular pronounciation at all and see what emerges in common
speech. For example, I know of at least one technical term ('ioctl')
that is frequently pronounced any one of at least three different
ways ('i-o-c-t-l', 'i-octal', 'i-o-cuttle') - even though the term has
been around in common use for most of the past half-century.

Thanks - Fred
[e-mail]



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4R1WGJ21950 for <[e-mail]>; Wed, 26 May 2004 18:32:16 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4R1UhFT019845 for <[e-mail]>; Wed, 26 May 2004 19:30:43 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 26 May 2004 21:32:15 -0400 (EDT)
Received: from Sun.COM (sr1-umpk-15.SFBay.Sun.COM [129.146.11.193]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 26 May 2004 21:32:15 -0400 (EDT)
Date: Wed, 26 May 2004 18:32:14 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
In-reply-to: <001901c44387$7bac4570$[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414
References: <001901c44387$7bac4570$[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 01:32:43 -0000
Status: RO
Content-Length: 1563

Yeah, I'm not saying that any particular solution would not
work in that case (lots of nodes, very mobile).
It might be nice to know how mobile
things can be, and how many nodes can be supported. I'm sure there
isn't an exact number ("this design supports up to 1437 endnodes,
and will break with 1438"), but things will gradually degrade. Nothing
scales infinitely.

My manager at Digital always insisted that numbers get put into
specs, and that they be conservative (if you build anything bigger
than that, it's not our fault). So DECnet phase 3 claimed to
be able to support networks up to 32 nodes! (luckily nobody
knew that, and built quite large networks). Likewise, the 7 hop
limit for bridges was basically picked out of the air.

I suspect if we're reasonably careful about the protocol (for instance,
not reporting nodes when they go down unless they appear elsewhere in
the net, and batching information), we could support a fairly large and 
fairly mobile population.

Radia




Alper Yegin wrote:
>>Hopefully the endnodes aren't *that* mobile. It's not being
>>designed for mobile ad-hoc networking, but for
>>wired networks. So endnode movement won't be
>>very frequent. We just want it to be plug-and-play when it
>>does happen.
> 
> 
> But it is so tempting to use this for mobile ad-hoc networks, localized
> (or micro-) mobility management, etc :) And I think it is hard to
> prevent that. We should eventually have some understanding on the
> scalability characteristics, and maybe have some appropriate warning
> signs...
> 
> Alper
>  
> 




Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4R1CdJ18479 for <[e-mail]>; Wed, 26 May 2004 18:12:40 -0700 (PDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <[e-mail]> for [e-mail]; Thu, 27 May 2004 10:12:22 +0900 (KST)
Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 27 May 2004 10:11:05 +0900 (KST)
Received: from Alperyegin ([105.144.29.157]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 27 May 2004 10:11:05 +0900 (KST)
Date: Wed, 26 May 2004 18:11:02 -0700
From: Alper Yegin <[e-mail]>
Subject: RE: [rbridge] Draft problem statement
In-reply-to: <[e-mail]>
To: [e-mail], "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <001901c44387$7bac4570$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 'Erik Nordmark' <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 01:13:36 -0000
Status: RO
Content-Length: 527

> Hopefully the endnodes aren't *that* mobile. It's not being
> designed for mobile ad-hoc networking, but for
> wired networks. So endnode movement won't be
> very frequent. We just want it to be plug-and-play when it
> does happen.

But it is so tempting to use this for mobile ad-hoc networks, localized
(or micro-) mobility management, etc :) And I think it is hard to
prevent that. We should eventually have some understanding on the
scalability characteristics, and maybe have some appropriate warning
signs...

Alper
 



Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4R0qkJ15011 for <[e-mail]>; Wed, 26 May 2004 17:52:46 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4R0qev04450; Wed, 26 May 2004 17:52:40 -0700
X-mProtect: <200405270052> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgvMGNQ; Wed, 26 May 2004 17:52:38 PDT
Message-ID: <[e-mail]>
Date: Wed, 26 May 2004 17:52:48 -0700
From: Fred Templin <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
References: <[e-mail]>	<[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 00:53:36 -0000
Status: RO
Content-Length: 1058

Radia Perlman wrote:

> But the other issue you bring up I think might be more important.
> I assume by "traffic scaling" you're not talking about
> data traffic, but instead the amount of link state information
> necessary to keep all the routers up-to-date about the
> location of all the endnodes.


Yes, this is what I was referring to.

> Hopefully the endnodes aren't *that* mobile. It's not being
> designed for mobile ad-hoc networking, but for
> wired networks. So endnode movement won't be
> very frequent. We just want it to be plug-and-play when it
> does happen.


OK, but then qualifying remarks should probably be added to
Erik's draft problem statement. Right now, it just says: "where
endnodes can move around without changing their IP addresses"
and doesn't mention any constraints like wired vs. wireless,
highly-mobile vs. relatively static, etc.

I would prefer seeing as few constraints as possible in the design,
i.e., leave Erik's problem statement as-is and see what solutions
can be found.

Thanks - Fred
[e-mail]



Received: from muse.localhost ([129.94.183.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4R0aSJ11258 for <[e-mail]>; Wed, 26 May 2004 17:36:28 -0700 (PDT)
Received: from nicta.com.au (localhost [127.0.0.1]) by muse.localhost (Postfix) with ESMTP id 349C59C897; Thu, 27 May 2004 10:36:21 +1000 (EST)
Message-ID: <[e-mail]>
Date: Thu, 27 May 2004 10:36:20 +1000
From: Aidan Williams <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 00:36:35 -0000
Status: RO
Content-Length: 682

Erik Nordmark wrote:
> The BoF will explore combining the benefits of bridges and routers without
> requiring any changes on any of the hosts, IP routers, or bridges.
> The design should support both IPv4 and IPv6.
> 

This paragraph doesn't make sense to me as written.  We are going to 
develop mechanism that could be deployed in routers, bridges or hosts 
and that would therefore change them.

Perhaps what is intended is some kind of backwards compatibility statement?

Perhaps:
"The BoF will explore combining benefits of bridges and routers in a way 
that will co-exist with existing hosts, IP routers and bridges.  The 
design should support both IPv4 and IPv6."

- aidan



Received: from muse.localhost ([129.94.183.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4R0S8J09394 for <[e-mail]>; Wed, 26 May 2004 17:28:08 -0700 (PDT)
Received: from nicta.com.au (localhost [127.0.0.1]) by muse.localhost (Postfix) with ESMTP id 3E55A9C88E; Thu, 27 May 2004 10:28:01 +1000 (EST)
Message-ID: <[e-mail]>
Date: Thu, 27 May 2004 10:28:00 +1000
From: Aidan Williams <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 00:28:35 -0000
Status: RO
Content-Length: 1355

Radia Perlman wrote:
> Someone asked about one of the zerouter proposals, and how that would 
> fit in here.
> 
> The proposal involved handing a campus a block of IP addresses, and
> the routers figure out how to automatically number the links within
> that prefix.
> 

There were a number of proposals...  and you are correct that most of 
them in some way attacked the problem via automatic subnet number 
assignment to links.

But there was one proposal that did not try to allocate subnet numbers. 
  The "multilink" proposal at the time had scope to become more than an 
ARP/ND proxy.  It was heading toward "IP bridging".  Work had been done 
looking at IS-IS as the underlying routing mechanism ("host routes") and 
on getting DHCP to work.

> This achieves some of the objectives, like zero configuration, optimal
> pair-wise routing, and safe transition behavior. But it does not do
> as well as the Rbridge solution on the piece of the problem statement
> above, in that since IP addresses are link-specific, you'd have to change
> your IP address if you moved to a different link. And unless
> every link was exactly fully populated, you'd waste IP addresses.
> 

True.

On the other hand, an "IP-bridging" solution would better handle 
incompatible L2 links (ie links with different MAC address formats and 
MTUs).

regards
	aidan
____
:wq!



Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4R0RVJ09282 for <[e-mail]>; Wed, 26 May 2004 17:27:31 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4R0RPw2026143 for <[e-mail]>; Wed, 26 May 2004 17:27:26 -0700 (PDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 26 May 2004 20:27:25 -0400 (EDT)
Received: from Sun.COM (sr1-umpk-15.SFBay.Sun.COM [129.146.11.193]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 26 May 2004 20:27:25 -0400 (EDT)
Date: Wed, 26 May 2004 17:27:24 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414
References: <[e-mail]> <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 00:27:35 -0000
Status: RO
Content-Length: 1881

> 
> I have a small question on this one. Suppose you have a rather large
> campus with a rather large number of nodes moving around, and
> you want to manage the whole thing as a single logical IP subnet.
> 
> If all the hybrid router/bridges in such a campus engaged in a
> link-state routing protocol to keep track of the mobile nodes,
> wouldn't there be a state and/or traffic scaling issue?
> 
I don't think state would be a problem. The database to keep
track of endnodes would be no larger than if the RBridges were
actual bridges. And this is very similar to CLNP, which for
"level 1 routing" kept track of all the endnodes, and I believe
fairly large level 1 areas were built (does anyone have any numbers?)

But the other issue you bring up I think might be more important.
I assume by "traffic scaling" you're not talking about
data traffic, but instead the amount of link state information
necessary to keep all the routers up-to-date about the
location of all the endnodes.

Hopefully the endnodes aren't *that* mobile. It's not being
designed for mobile ad-hoc networking, but for
wired networks. So endnode movement won't be
very frequent. We just want it to be plug-and-play when it
does happen.

But on the other hand, endnodes might get powered down a lot.
So the question is, how responsive should an RBridge be
about declaring that it no longer owns an endnode?

I'd suggest that as soon as an Rbridge discover a new
neighbor endnode, it should announce it
in its link state info. However, when it's down, unless it
see some other RBridge claiming it in its
link state info, there would be no harm
in not telling anyone it is down, at least for awhile. If it
has moved, the RBridge should immediately relinquish it so traffic goes
to its new home. But if it has just powered down, it might be
a problem in terms of traffic to let everyone know that.

Radia




Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4R05DJ04299 for <[e-mail]>; Wed, 26 May 2004 17:05:13 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4R056h27994; Wed, 26 May 2004 17:05:06 -0700
X-mProtect: <200405270005> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSSbbV7; Wed, 26 May 2004 17:05:04 PDT
Message-ID: <[e-mail]>
Date: Wed, 26 May 2004 17:05:14 -0700
From: Fred Templin <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 00:05:35 -0000
Status: RO
Content-Length: 527

Erik et al,

Erik Nordmark wrote:

>where endnodes can move around without changing their IP addresses,
>

I have a small question on this one. Suppose you have a rather large
campus with a rather large number of nodes moving around, and
you want to manage the whole thing as a single logical IP subnet.

If all the hybrid router/bridges in such a campus engaged in a
link-state routing protocol to keep track of the mobile nodes,
wouldn't there be a state and/or traffic scaling issue?

Thanks - Fred
[e-mail]



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4R02XJ03813 for <[e-mail]>; Wed, 26 May 2004 17:02:33 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4R02W92028937 for <[e-mail]>; Wed, 26 May 2004 18:02:32 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Wed, 26 May 2004 20:02:32 -0400 (EDT)
Received: from Sun.COM (sr1-umpk-15.SFBay.Sun.COM [129.146.11.193]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 26 May 2004 20:02:32 -0400 (EDT)
Date: Wed, 26 May 2004 17:02:31 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Draft problem statement
In-reply-to: <[e-mail]>
To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414
References: <[e-mail]>
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2004 00:03:55 -0000
Status: RO
Content-Length: 1041

> 
> Routers on the other hand avoid those disadvatages but have their own
> disadvantages: IP addresses are link specific so a host that moves must
> change its IP address, the routers must be configured with unique link prefixes
> for each of the attached links, and the block of IP address space can not be
> fully utilized because it must be partitioned across the different links.

Someone asked about one of the zerouter proposals, and how that would 
fit in here.

The proposal involved handing a campus a block of IP addresses, and
the routers figure out how to automatically number the links within
that prefix.

This achieves some of the objectives, like zero configuration, optimal
pair-wise routing, and safe transition behavior. But it does not do
as well as the Rbridge solution on the piece of the problem statement
above, in that since IP addresses are link-specific, you'd have to change
your IP address if you moved to a different link. And unless
every link was exactly fully populated, you'd waste IP addresses.

Radia



Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4QMlWJ12401 for <[e-mail]>; Wed, 26 May 2004 15:47:32 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4QMlPw2016526 for <[e-mail]>; Wed, 26 May 2004 15:47:26 -0700 (PDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL, v2.2) with SMTP id i4QMlNQ11641 for <[e-mail]>; Thu, 27 May 2004 00:47:24 +0200 (MEST)
Date: Wed, 26 May 2004 15:47:24 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Draft problem statement
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2004 22:47:36 -0000
Status: RO
Content-Length: 1615

Comments please.

  Erik

---

It is desirable for an organization to have a fairly large campus
with a single IP address prefix, a rich physical topology,
where the network elements do not need to be configured,
where endnodes can move around without changing their IP addresses,
and where ARP and Neighbor Discovery traffic can be confined.

This functionality is often provided by bridges. 
However, bridges have disadvantages: routing
is confined to a spanning tree (precluding pair-wise shortest paths),
ARP and Neighbor Discovery packets must be carried across all the links,
the header on which the spanning tree forwards has no hop count,
spanning tree forwarding in the presence of temporary loops spawns
exponential copies of packets, nodes can have only a single point of
attachment, the spanning tree, in order to avoid temporary loops,
is slow to start forwarding on new ports, and it is not possible to take
advantage of the rich physical topology for capacity since the packet flows
are restricted to following the spanning tree.

Routers on the other hand avoid those disadvatages but have their own
disadvantages: IP addresses are link specific so a host that moves must
change its IP address, the routers must be configured with unique link prefixes
for each of the attached links, and the block of IP address space can not be
fully utilized because it must be partitioned across the different links.

The BoF will explore combining the benefits of bridges and routers without
requiring any changes on any of the hosts, IP routers, or bridges.
The design should support both IPv4 and IPv6.

---



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4QMjhJ11975 for <[e-mail]>; Wed, 26 May 2004 15:45:44 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4QMi7FT014630;  Wed, 26 May 2004 16:44:08 -0600 (MDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4QMjbQ11594; Thu, 27 May 2004 00:45:37 +0200 (MEST)
Date: Wed, 26 May 2004 15:45:37 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
Subject: [rbridge] Name that BoF
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2004 22:46:59 -0000
Status: RO
Content-Length: 252

We've picked the winning name for the BoF:
  IP Virtual Link eXtension (ipvlx)

I'd expect this to be pronounced i-p-v-lex.
If anyone objects strongly, now is the time to speak.

If not, we can proceed with getting the BoF scheduled.

  Erik & Radia



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4G0skJ14413 for <[e-mail]>; Sat, 15 May 2004 17:54:46 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4G0skhs002255 for <[e-mail]>; Sat, 15 May 2004 18:54:46 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Sat, 15 May 2004 20:54:45 -0400 (EDT)
Received: from sun.com (vpn-129-147-154-133.Central.Sun.COM [129.147.154.133]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 15 May 2004 20:54:45 -0400 (EDT)
Date: Sat, 15 May 2004 17:54:44 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
In-reply-to: <009a01c43a11$ff5a2790$[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
References: <009a01c43a11$ff5a2790$[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 16 May 2004 00:55:02 -0000
Status: RO
Content-Length: 3553

Thanks for clarifying, Alper. You quoted a large enough section of
RFC3344 that I didn't notice the relevant text. I think the
relevant text is:

>>Note also that, when transmitting a Registration
>>Request on a foreign network, a mobile node may
>>discover the link-layer address of a
>>foreign agent by storing the address as it is received
>>from the Agent Advertisement from that foreign agent


The question is, is there some way that an RBridge can
distinguish a Registration Request from a regular
IP data message? From a quick reading of the spec, it
looks to me like an Agent Advertisement is an ICMP
message. It would be easy for RBridges to be careful
to preserve the layer 2 address in ICMP message (IP
protocol type field="ICMP"). It looks though like
the Registration Request is on top of UDP, so that
looks like it might be a bit harder.

3344 says "may" (in lower case...not sure whether
that is significant). Are there implementations that
read the layer 2 address from packets that have
type UDP or TCP? Signalling in the layer 2 source
is a safety thing in a super-rare case, but if we
can do it, it would allow us not to have to be conservative
about a node taking over as DR. I don't think it's
a problem if ICMP messages occasionally loop in rare
temporary cases. But it would be nice to avoid it
for IP data packets.

Is there something else in the layer 2 header that
can be used to signal "this was handled by an RBridge?
I think not...there's only source, destination, and
protocol type...and I'm sure IP nodes would be upset
if the protocol type or destination changed. But
thought I'd ask in case someone else can think of a way.

Radia



>>>This would break RFC3344:
>>>
>>>  While the mobile node is away from home, it MUST NOT transmit any
>>>  broadcast ARP Request or ARP Reply messages.  Finally, while the
>>>  mobile node is away from home, it MUST NOT reply to ARP Requests
>>>      
>>>
>in
>  
>
>>>  which the target IP address is its own home address, unless the
>>>      
>>>
>ARP
>  
>
>>>  Request is unicast by a foreign agent with which the mobile node
>>>      
>>>
>is
>  
>
>>>  attempting to register or a foreign agent with which the mobile
>>>      
>>>
>node
>  
>
>>>  has an unexpired registration.  In the latter case, the mobile
>>>      
>>>
>node
>  
>
>>>  MUST use a unicast ARP Reply to respond to the foreign agent.
>>>      
>>>
>Note
>  
>
>>>  that if the mobile node is using a co-located care-of address and
>>>  receives an ARP Request in which the target IP address is this
>>>      
>>>
>care-
>  
>
>>>  of address, then the mobile node SHOULD reply to this ARP Request.
>>>  Note also that, when transmitting a Registration Request on a
>>>      
>>>
>foreign
>  
>
>>>  network, a mobile node may discover the link-layer address of a
>>>  foreign agent by storing the address as it is received from the
>>>      
>>>
>Agent
>  
>
>>>  Advertisement from that foreign agent, but not by transmitting a
>>>  broadcast ARP Request message.
>>>
>>>But I'm not sure who deserves the blame :)
>>>
>>>Alper
>>>
>>>
>>>_______________________________________________
>>>rbridge mailing list
>>>[e-mail]
>>>http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>rbridge mailing list
>>[e-mail]
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>




Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4G0YBJ11492 for <[e-mail]>; Sat, 15 May 2004 17:34:11 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4G0Y66b024174 for <[e-mail]>; Sat, 15 May 2004 17:34:06 -0700 (PDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Sat, 15 May 2004 20:34:05 -0400 (EDT)
Received: from sun.com (vpn-129-147-154-133.Central.Sun.COM [129.147.154.133]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 15 May 2004 20:34:05 -0400 (EDT)
Date: Sat, 15 May 2004 17:34:04 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] What's in a name...
In-reply-to: <p06020403bcc95fb3222e@[10.0.1.23]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p06020403bcc95fb3222e@[10.0.1.23]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 16 May 2004 00:35:01 -0000
Status: RO
Content-Length: 199

Thinking more about IPvLX, I'm worried people will think it has something to
do with IPv8.

How about IPSET (IP Subnets Extended Transparently)

It might be nice to come up with a name soon,

Radia



Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4F0HZJ18942 for <[e-mail]>; Fri, 14 May 2004 17:17:36 -0700 (PDT)
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <[e-mail]> for [e-mail]; Sat, 15 May 2004 09:17:28 +0900 (KST)
Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 15 May 2004 09:17:28 +0900 (KST)
Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 15 May 2004 09:17:28 +0900 (KST)
Date: Fri, 14 May 2004 17:17:22 -0700
From: Alper Yegin <[e-mail]>
Subject: RE: [rbridge] Developing a hybrid router/bridge.
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <009a01c43a11$ff5a2790$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 15 May 2004 00:17:57 -0000
Status: RO
Content-Length: 3955

Mobile node (the host) and the foreign agent (mobile node's first-hop
router) rely on parsing the L2 header on the IP packets sent between the
two, in order to learn the L2 address of the other, rather than using
ARP.

If you are setting the L2 source address on the original L2 header to X,
this causes problem.

Am I missing something?

Alper








> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Radia Perlman
> Sent: Friday, May 14, 2004 5:06 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Developing a hybrid router/bridge.
> 
> I'm confused. I don't see what that text from mobileIP has to do with
> this proposal.
> I think my proposal has nothing to do with ARP. I'm just proposing
> something that
> would make it impossible for an IP packet that had been forwarded
across
> the campus
> by one RBridge to be accidentally re-sent over the campus by another
> one. I was
> marking a data packet in a way that would be (hopefully) ignored by
all
> IP nodes,
> both v4 and v6, and IP routers as well.
> 
> The suggestion is that a packet that has been handled by an RBridge on
> this virtual subnet
> have a dummy layer 2 source address. Other RBridges, would notice the
> layer 2
> source address and not ever forward such a packet across the same
> virtual subnet.
> 
> I thought it would work, and I asked Erik Nordmark whether in all
cases
> IP nodes
> ignore the layer 2 source address on received packets and he said yes.
> 
> I could imagine uses of the layer 2 source address. An obvious
potential
> use for it is
> to refresh an ARP cache. DECnet certainly did that sort of thing. It's
> not inconceivable
> that some IP implementation might do that even though it's not
mentioned
> in any spec.
> But from asking around, nobody has told of a case in which this would
be
> a problem.
> 
> So hopefully, Alper, you just misunderstood my suggestion.
> 
> Radia
> 
> 
> Alper Yegin wrote:
> 
> >>How about having a specific, constant MAC address, say "X",  that
> >>
> >>
> >means
> >
> >
> >>"transmitted by an RBridge".
> >>When an RBridge decapsulates an IP packet onto the destination LAN,
it
> >>can set the source
> >>address in the layer 2 header to be X. The rule will be that an
> >>
> >>
> >RBridge
> >
> >
> >>is not allowed to forward a packet that has layer 2 source
address=X.
> >>
> >>
> >
> >This would break RFC3344:
> >
> >   While the mobile node is away from home, it MUST NOT transmit any
> >   broadcast ARP Request or ARP Reply messages.  Finally, while the
> >   mobile node is away from home, it MUST NOT reply to ARP Requests
in
> >   which the target IP address is its own home address, unless the
ARP
> >   Request is unicast by a foreign agent with which the mobile node
is
> >   attempting to register or a foreign agent with which the mobile
node
> >   has an unexpired registration.  In the latter case, the mobile
node
> >   MUST use a unicast ARP Reply to respond to the foreign agent.
Note
> >   that if the mobile node is using a co-located care-of address and
> >   receives an ARP Request in which the target IP address is this
care-
> >   of address, then the mobile node SHOULD reply to this ARP Request.
> >   Note also that, when transmitting a Registration Request on a
foreign
> >   network, a mobile node may discover the link-layer address of a
> >   foreign agent by storing the address as it is received from the
Agent
> >   Advertisement from that foreign agent, but not by transmitting a
> >   broadcast ARP Request message.
> >
> >But I'm not sure who deserves the blame :)
> >
> >Alper
> >
> >
> >_______________________________________________
> >rbridge mailing list
> >[e-mail]
> >http://www.postel.org/mailman/listinfo/rbridge
> >
> >
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4F05fJ16536 for <[e-mail]>; Fri, 14 May 2004 17:05:41 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4F05ehs005341 for <[e-mail]>; Fri, 14 May 2004 18:05:41 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Fri, 14 May 2004 20:05:40 -0400 (EDT)
Received: from sun.com (vpn-129-147-154-133.Central.Sun.COM [129.147.154.133]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 14 May 2004 20:05:40 -0400 (EDT)
Date: Fri, 14 May 2004 17:05:39 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
In-reply-to: <009301c43a0d$0633cb20$[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
References: <009301c43a0d$0633cb20$[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 15 May 2004 00:05:54 -0000
Status: RO
Content-Length: 3039

I'm confused. I don't see what that text from mobileIP has to do with 
this proposal.
I think my proposal has nothing to do with ARP. I'm just proposing 
something that
would make it impossible for an IP packet that had been forwarded across 
the campus
by one RBridge to be accidentally re-sent over the campus by another 
one. I was
marking a data packet in a way that would be (hopefully) ignored by all 
IP nodes,
both v4 and v6, and IP routers as well.

The suggestion is that a packet that has been handled by an RBridge on 
this virtual subnet
have a dummy layer 2 source address. Other RBridges, would notice the 
layer 2
source address and not ever forward such a packet across the same 
virtual subnet.

I thought it would work, and I asked Erik Nordmark whether in all cases 
IP nodes
ignore the layer 2 source address on received packets and he said yes.

I could imagine uses of the layer 2 source address. An obvious potential 
use for it is
to refresh an ARP cache. DECnet certainly did that sort of thing. It's 
not inconceivable
that some IP implementation might do that even though it's not mentioned 
in any spec.
But from asking around, nobody has told of a case in which this would be 
a problem.

So hopefully, Alper, you just misunderstood my suggestion.

Radia


Alper Yegin wrote:

>>How about having a specific, constant MAC address, say "X",  that
>>    
>>
>means
>  
>
>>"transmitted by an RBridge".
>>When an RBridge decapsulates an IP packet onto the destination LAN, it
>>can set the source
>>address in the layer 2 header to be X. The rule will be that an
>>    
>>
>RBridge
>  
>
>>is not allowed to forward a packet that has layer 2 source address=X.
>>    
>>
>
>This would break RFC3344:
>
>   While the mobile node is away from home, it MUST NOT transmit any
>   broadcast ARP Request or ARP Reply messages.  Finally, while the
>   mobile node is away from home, it MUST NOT reply to ARP Requests in
>   which the target IP address is its own home address, unless the ARP
>   Request is unicast by a foreign agent with which the mobile node is
>   attempting to register or a foreign agent with which the mobile node
>   has an unexpired registration.  In the latter case, the mobile node
>   MUST use a unicast ARP Reply to respond to the foreign agent.  Note
>   that if the mobile node is using a co-located care-of address and
>   receives an ARP Request in which the target IP address is this care-
>   of address, then the mobile node SHOULD reply to this ARP Request.
>   Note also that, when transmitting a Registration Request on a foreign
>   network, a mobile node may discover the link-layer address of a
>   foreign agent by storing the address as it is received from the Agent
>   Advertisement from that foreign agent, but not by transmitting a
>   broadcast ARP Request message.
>
>But I'm not sure who deserves the blame :)
>
>Alper
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>




Received: from muse.localhost ([129.94.183.100]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4ENxoJ15088 for <[e-mail]>; Fri, 14 May 2004 16:59:50 -0700 (PDT)
Received: from nicta.com.au (localhost [127.0.0.1]) by muse.localhost (Postfix) with ESMTP id DB60598F12 for <[e-mail]>; Sat, 15 May 2004 09:59:40 +1000 (EST)
Message-ID: <[e-mail]>
Date: Sat, 15 May 2004 09:59:40 +1000
From: Aidan Williams <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding based on layer 3 vs layer 2 destination
References: <009601c43a0e$874892d0$[e-mail]>
In-Reply-To: <009601c43a0e$874892d0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2004 23:59:54 -0000
Status: RO
Content-Length: 300

Alper Yegin wrote:
> I think home networking is a likely place to have mixed L2s, and
> absolutely where we want to utilize Rbridging. I think it's worth
> investigating how we can achieve this while closely watching its cost on
> the design.

Well said.  This is where I'm coming from too.
- aidan



Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4ENqrJ13736 for <[e-mail]>; Fri, 14 May 2004 16:52:53 -0700 (PDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <[e-mail]> for [e-mail]; Sat, 15 May 2004 08:52:45 +0900 (KST)
Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 15 May 2004 08:52:38 +0900 (KST)
Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 15 May 2004 08:52:38 +0900 (KST)
Date: Fri, 14 May 2004 16:52:32 -0700
From: Alper Yegin <[e-mail]>
Subject: RE: [rbridge] Forwarding based on layer 3 vs layer 2 destination
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <009601c43a0e$874892d0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2004 23:54:16 -0000
Status: RO
Content-Length: 2057

I think home networking is a likely place to have mixed L2s, and
absolutely where we want to utilize Rbridging. I think it's worth
investigating how we can achieve this while closely watching its cost on
the design.

Alper


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Aidan Williams
> Sent: Sunday, May 09, 2004 10:30 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Forwarding based on layer 3 vs layer 2
destination
> 
> Radia Perlman wrote:
> > It can work, but first I'd like to know if it's important to make
> > this case work. Some people I passed RBridge by awhile ago seemed
> > enthusiastic about making a campus with incompatible layer 2
> > addresses work. I've forgotten who they are, though, or else I could
> > ask them directly which particular layer 2 technologies they had in
> > mind.
> >
> 
> Firewire springs to mind as a non-EUI48 addressed media over which
> people run IP packets.  Incompatible layer 2 addressing is only part
of
> the story though, different ethernet flavours can have incompatible
MTU
> sizes (e.g. 9k for gigabit).
> 
> I'm uneasy about encapsulating 1500-byte ethernet packets because the
> resulting >1500 byte packet might not be passed transparently through
> existing switches.  I have been bitten by this a few years ago trying
to
> deploy 802.1q (which adds 4 bytes to the packet header).  Maybe
someone
> can reassure me that this isn't a problem anymore and would not be a
> showstopper for an L2 rbridge solution.
> 
> "Bridging at the IP layer" has some advantages in that it copes with
> differing link layers, supports fragmentation and you get the usual
> router behaviours supporting MTU discovery and shortest paths.
> 
> I'm not particularly keen on combining the L2 and L3 approach.  I
think
> it might result in a whole pile of added confusion.
> 
> - aidan
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge



Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4ENgQJ10712 for <[e-mail]>; Fri, 14 May 2004 16:42:27 -0700 (PDT)
Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <[e-mail]> for [e-mail]; Sat, 15 May 2004 08:42:20 +0900 (KST)
Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 15 May 2004 08:41:52 +0900 (KST)
Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 15 May 2004 08:41:52 +0900 (KST)
Date: Fri, 14 May 2004 16:41:46 -0700
From: Alper Yegin <[e-mail]>
Subject: RE: [rbridge] Developing a hybrid router/bridge.
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <009301c43a0d$0633cb20$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2004 23:42:54 -0000
Status: RO
Content-Length: 1516

> How about having a specific, constant MAC address, say "X",  that
means
> "transmitted by an RBridge".
> When an RBridge decapsulates an IP packet onto the destination LAN, it
> can set the source
> address in the layer 2 header to be X. The rule will be that an
RBridge
> is not allowed to forward a packet that has layer 2 source address=X.

This would break RFC3344:

   While the mobile node is away from home, it MUST NOT transmit any
   broadcast ARP Request or ARP Reply messages.  Finally, while the
   mobile node is away from home, it MUST NOT reply to ARP Requests in
   which the target IP address is its own home address, unless the ARP
   Request is unicast by a foreign agent with which the mobile node is
   attempting to register or a foreign agent with which the mobile node
   has an unexpired registration.  In the latter case, the mobile node
   MUST use a unicast ARP Reply to respond to the foreign agent.  Note
   that if the mobile node is using a co-located care-of address and
   receives an ARP Request in which the target IP address is this care-
   of address, then the mobile node SHOULD reply to this ARP Request.
   Note also that, when transmitting a Registration Request on a foreign
   network, a mobile node may discover the link-layer address of a
   foreign agent by storing the address as it is received from the Agent
   Advertisement from that foreign agent, but not by transmitting a
   broadcast ARP Request message.

But I'm not sure who deserves the blame :)

Alper




Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4EN7iJ02592 for <[e-mail]>; Fri, 14 May 2004 16:07:44 -0700 (PDT)
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <[e-mail]> for [e-mail]; Sat, 15 May 2004 08:07:35 +0900 (KST)
Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <[e-mail]> for [e-mail]; Sat, 15 May 2004 08:07:34 +0900 (KST)
Received: from Alperyegin ([105.144.29.153]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Sat, 15 May 2004 08:07:34 +0900 (KST)
Date: Fri, 14 May 2004 16:07:29 -0700
From: Alper Yegin <[e-mail]>
Subject: RE: [rbridge] RE: rbridge Digest, Vol 1, Issue 2
In-reply-to: <[e-mail]>
To: "'Developing a hybrid router/bridge.'" <[e-mail]>
Message-id: <009201c43a08$3bd041f0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.2627
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2004 23:07:54 -0000
Status: RO
Content-Length: 610

> ARP and ND are interesting cases because they are L3 protocols that
use
> L2 information, i.e., they are 'glue' layers of a sort. They must be
> interfaced to the edge of a campus of rbridges carefully, but I don't
> see any showstoppers.

Mobile IPv4 has its ARP-like side: The foreign agent (the first hop
router to the mobile node) is advised to parse the L2 headers to learn
the L2 address of the node.

> > Someone privately told me there are certain IP protocols that will
not
> > work if the TTL
> > gets decremented, like "local broadcast".

Mobile IPv4, router discovery are some examples.

Alper




Received: from av3-1-sn3.vrr.skanova.net (av3-1-sn3.vrr.skanova.net [81.228.9.109]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4EIJ1J13824 for <[e-mail]>; Fri, 14 May 2004 11:19:01 -0700 (PDT)
Received: by av3-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 6F6C537F3E; Fri, 14 May 2004 20:18:55 +0200 (CEST)
Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 6223637E56; Fri, 14 May 2004 20:18:55 +0200 (CEST)
Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 452A238011; Fri, 14 May 2004 20:18:55 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 14 May 2004 20:18:36 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2004 18:19:54 -0000
Status: RO
Content-Length: 1623

All,

guess that what we need is one ADs that is willing to sponsor this,
don't really matter who it is for the BoF, though it good to be
approximately right to start with.

We could come up with arguments for OPS, Routing and Internet, and
equally valid arguments for not any of those areas.

personally I would need to avoid mpls and l2vpn, and would like to
not conflict with pwe3, ccamp and l3vpn.

/Loa

Erik Nordmark wrote:
>>Seems like this isn't Internet unless it provides L3; since it provides 
>>L2, this might formerly be sub-IP, but currently might map better to 
>>Operations & Management.
> 
> 
> I assume the IESG will figure out the best area and AD; Radia has been
> talking to Margaret which is why we sent it to her/internet.
> 
> 
>>>    c. CONFLICTS you wish to avoid, please be as specific as possible:
>>>
>>>VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops
>>
>>L2VPN is the most specific I can imagine (it's not clear why that's in 
>>the Internet area either, IMO) that is active right now.
>>
>>Zeroconf overlaps a little.
> 
> 
> The conflicts are meeting scheduling conflicts to avoid; I don't
> think zeroconf will meet.
> The list above is my and Radia's swag. If there are folks that really
> want to contribute to this BoF but have to be in other WGs (due to
> being co-chairs, presenting/leading discussions, etc) let me
> know and I will update the conflicts list.
> 
>   Erik
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
> 
> 

-- 

Loa Andersson

mobile [phone]



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4EHP3J29805 for <[e-mail]>; Fri, 14 May 2004 10:25:03 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4EHP0hs022233;  Fri, 14 May 2004 11:25:01 -0600 (MDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4EHOwQ23690; Fri, 14 May 2004 19:24:58 +0200 (MEST)
Date: Fri, 14 May 2004 10:25:02 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
To: Joe Touch <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>, Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2004 17:26:15 -0000
Status: RO
Content-Length: 969

> Seems like this isn't Internet unless it provides L3; since it provides 
> L2, this might formerly be sub-IP, but currently might map better to 
> Operations & Management.

I assume the IESG will figure out the best area and AD; Radia has been
talking to Margaret which is why we sent it to her/internet.

> > 
> >     c. CONFLICTS you wish to avoid, please be as specific as possible:
> > 
> > VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops
> 
> L2VPN is the most specific I can imagine (it's not clear why that's in 
> the Internet area either, IMO) that is active right now.
> 
> Zeroconf overlaps a little.

The conflicts are meeting scheduling conflicts to avoid; I don't
think zeroconf will meet.
The list above is my and Radia's swag. If there are folks that really
want to contribute to this BoF but have to be in other WGs (due to
being co-chairs, presenting/leading discussions, etc) let me
know and I will update the conflicts list.

  Erik



Received: from tm2.ca.alcatel.com (kanfw1.ottawa.alcatel.ca [192.75.23.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4E3VAJ22239 for <[e-mail]>; Thu, 13 May 2004 20:31:10 -0700 (PDT)
Received: from camail03.ca.alcatel.com (localhost [127.0.0.1]) by tm2.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id i4E3V8Rh020950 for <[e-mail]>; Thu, 13 May 2004 23:31:09 -0400 (EDT)
Received: from alcatel.com ([138.120.234.17]) by camail03.ca.alcatel.com (Netscape Messaging Server 4.15) with ESMTP id HXOPRV00.QAG; Thu, 13 May 2004 23:31:07 -0400 
Message-ID: <[e-mail]>
Date: Thu, 13 May 2004 23:28:20 -0400
From: Cheng-Yin Lee <[e-mail]>
X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2004 03:32:55 -0000
Status: RO
Content-Length: 6599

My interpretation of the draft is - a better bridge, with optimization
for IP traffic.
It is perhaps captured better by Margaret Wasserman's suggestion,
HyBridge or a hybrid bridge/router (incidentally the name of this
mailing list too). 
If the work is going to be on bridging IP traffic or IP subnet only,
then IP Subnet EXtensions sounds fine. Would the group then consider IP
Subnet EXtensions for different types of access networks (I know this is
not easy) ?
I have to admit Fred Templin's suggestion is tempting ;-)

Regards
Cheng-Yin

Radia Perlman wrote:
> 
> Hmmm. If we went with IP Subnet EXtensions, we might
> get larger attendance at the BOF.
> 
> Though I do like Fred's suggestion of IPvLX (IP Virtual Link eXtension),
> with his explanation:
> 
>  >>which (treating the final two characters as roman numerals)
>  >>could allow for a claim that the new working group would
>  >>be an order-of-magnitude better than some others...
> 
> Radia
> 
> Fred Templin wrote:
> > Radia Perlman wrote:
> >
> >> I like vlx. Though perhaps it's not clear what
> >> a "virtual link" is. So perhaps "extended IP Subnet",
> >> which might have a pronouncable acronym of EXIPS
> >> (EXtended IP Subnets)
> >
> >
> >
> > Would be better than "IP Subnet Extensions", which
> > would have an unfortunate acronym and pronounciation.
> >
> > Fred
> > [e-mail]
> >
> >> Radia
> >>
> >>
> >> Fred Templin wrote:
> >>
> >>> Hello Erik,
> >>>
> >>> As to names for the prospective WG, how about:
> >>>
> >>>  Virtual Link eXtension (vlx)
> >>>
> >>> or, if the above sounds too layer-2 centric:
> >>>
> >>>  IP Virtual Link eXtension (ipvlx)
> >>>
> >>> Fred
> >>> [e-mail]
> >>>
> >>>
> >>> Erik Nordmark wrote:
> >>>
> >>>> We needed to request a BoF fairly quickly to make sure the IESG has
> >>>> time
> >>>> to review it, so I've submitted a draft BoF request (see below).
> >>>>
> >>>> I expect the details to change, especially the name :-)
> >>>>
> >>>> Comments on the problem statement and suggestions for a better name
> >>>> are especially welcome.
> >>>>
> >>>> The authors of the rbridge internet-draft asked me if I would chair the
> >>>> BoF which is fine with me. This does not mean I would necessarily be a
> >>>> WG chair if a WG is formed as a result of the BoF.
> >>>>
> >>>>   Erik
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> ----- Begin Included Message -----<
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Date: Wed, 12 May 2004 15:26:19 -0700 (PDT)
> >>>> From: "Erik Nordmark" <[e-mail]>
> >>>> Subject: BOF request: ISITFUN
> >>>> To: [e-mail], [e-mail], [e-mail]
> >>>> Cc: [e-mail], [e-mail]
> >>>>
> >>>>    a. Working Group or BOF full name with acronym in brackets:
> >>>>
> >>>> IP Subnets In Topologies which are Flexible, Universal, and Nice
> >>>> [ISITFUN]
> >>>>
> >>>> Note: we will almost certainly come up with a better name than this
> >>>>
> >>>>    b. AREA under which Working Group or BOF appears:
> >>>>
> >>>> Internet
> >>>>
> >>>>    c. CONFLICTS you wish to avoid, please be as specific as possible:
> >>>>
> >>>> VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops
> >>>>
> >>>>    d. Expected Attendance (figures from the previous IETF are sent when
> >>>>       WG/BOF scheduling opens)
> >>>>    e. Special requests (i.e. multicast):
> >>>>    f. Number of slots:
> >>>>
> >>>> one
> >>>>
> >>>>    g. Length of slot:
> >>>>
> >>>> two hours
> >>>>
> >>>>       - 1 hour
> >>>>       - 2 hours
> >>>>       - 2 1/2 hours
> >>>>
> >>>> Proposed BoF meeting chair: Erik Nordmark
> >>>>
> >>>> Web page (which has a reference to the mailing list, archives, papers
> >>>> and presentations with proposed solutions):
> >>>>
> >>>>     http://www.postel.org/rbridge/
> >>>>
> >>>> Problem statement:
> >>>>   It is desirable for an organization to have a fairly large campus
> >>>> with a single IP address prefix, a rich physical topology,
> >>>> where the network elements do not need to be configured,
> >>>> where endnodes can move around without changing their IP addresses,
> >>>> and where ARP and Neighbor Discovery traffic can be confined.
> >>>>
> >>>> This functionality is often provided by bridges. However, bridges
> >>>> have disadvantages: routing
> >>>> is confined to a spanning tree (precluding pair-wise shortest paths),
> >>>> ARP and Neighbor Discovery packets must be carried across all the
> >>>> links,
> >>>> the header on which the spanning tree forwards has no hop count,
> >>>> spanning tree forwarding in the presence of temporary loops spawns
> >>>> exponential copies of packets, nodes can have only a single point of
> >>>> attachment, the spanning tree, in order to avoid temporary loops,
> >>>> is slow to start forwarding on new ports, and it is not possible to
> >>>> take
> >>>> advantage of the rich physical topology for capacity since the
> >>>> packet flows
> >>>> are restricted to following the spanning tree.
> >>>>
> >>>> Routers on the other hand avoid those disadvatages but have their own
> >>>> disadvantages: IP addresses are link specific so a host that moves must
> >>>> change its IP address, the routers must be configured with unique
> >>>> link prefixes
> >>>> for each of the attached links, and the block of IP address space
> >>>> can not be
> >>>> fully utilized because it must be partitioned across the different
> >>>> links.
> >>>>
> >>>> The BoF will explore combining the benefits of bridges and routers
> >>>> without
> >>>> requiring any changes on any of the hosts, IP routers, or bridges.
> >>>> The design should support both IPv4 and IPv6.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> ----- End Included Message -----<
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> rbridge mailing list
> >>>> [e-mail]
> >>>> http://www.postel.org/mailman/listinfo/rbridge
> >>>>
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> rbridge mailing list
> >>> [e-mail]
> >>> http://www.postel.org/mailman/listinfo/rbridge
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [e-mail]
> >> http://www.postel.org/mailman/listinfo/rbridge
> >
> >
> >
> >
> > _______________________________________________
> > rbridge mailing list
> > [e-mail]
> > http://www.postel.org/mailman/listinfo/rbridge
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4E0OiJ13522 for <[e-mail]>; Thu, 13 May 2004 17:24:44 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4E0NKhO026512 for <[e-mail]>; Thu, 13 May 2004 18:23:21 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Thu, 13 May 2004 20:24:43 -0400 (EDT)
Received: from Sun.COM (sr-sml-4.Eng.Sun.COM [152.70.20.54]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 13 May 2004 20:24:43 -0400 (EDT)
Date: Thu, 13 May 2004 17:24:42 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 14 May 2004 00:25:04 -0000
Status: RO
Content-Length: 5542

Hmmm. If we went with IP Subnet EXtensions, we might
get larger attendance at the BOF.

Though I do like Fred's suggestion of IPvLX (IP Virtual Link eXtension), 
with his explanation:

 >>which (treating the final two characters as roman numerals)
 >>could allow for a claim that the new working group would
 >>be an order-of-magnitude better than some others...

Radia


Fred Templin wrote:
> Radia Perlman wrote:
> 
>> I like vlx. Though perhaps it's not clear what
>> a "virtual link" is. So perhaps "extended IP Subnet",
>> which might have a pronouncable acronym of EXIPS
>> (EXtended IP Subnets)
> 
> 
> 
> Would be better than "IP Subnet Extensions", which
> would have an unfortunate acronym and pronounciation.
> 
> Fred
> [e-mail]
> 
>> Radia
>>
>>
>> Fred Templin wrote:
>>
>>> Hello Erik,
>>>
>>> As to names for the prospective WG, how about:
>>>
>>>  Virtual Link eXtension (vlx)
>>>
>>> or, if the above sounds too layer-2 centric:
>>>
>>>  IP Virtual Link eXtension (ipvlx)
>>>
>>> Fred
>>> [e-mail]
>>>
>>>
>>> Erik Nordmark wrote:
>>>
>>>> We needed to request a BoF fairly quickly to make sure the IESG has 
>>>> time
>>>> to review it, so I've submitted a draft BoF request (see below).
>>>>
>>>> I expect the details to change, especially the name :-)
>>>>
>>>> Comments on the problem statement and suggestions for a better name
>>>> are especially welcome.
>>>>
>>>> The authors of the rbridge internet-draft asked me if I would chair the
>>>> BoF which is fine with me. This does not mean I would necessarily be a
>>>> WG chair if a WG is formed as a result of the BoF.
>>>>
>>>>   Erik
>>>>
>>>>
>>>>  
>>>>
>>>>> ----- Begin Included Message -----<
>>>>>   
>>>>
>>>>
>>>>
>>>>
>>>> Date: Wed, 12 May 2004 15:26:19 -0700 (PDT)
>>>> From: "Erik Nordmark" <[e-mail]>
>>>> Subject: BOF request: ISITFUN
>>>> To: [e-mail], [e-mail], [e-mail]
>>>> Cc: [e-mail], [e-mail]
>>>>
>>>>    a. Working Group or BOF full name with acronym in brackets:
>>>>
>>>> IP Subnets In Topologies which are Flexible, Universal, and Nice 
>>>> [ISITFUN]
>>>>
>>>> Note: we will almost certainly come up with a better name than this
>>>>
>>>>    b. AREA under which Working Group or BOF appears:
>>>>
>>>> Internet
>>>>
>>>>    c. CONFLICTS you wish to avoid, please be as specific as possible:
>>>>
>>>> VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops
>>>>
>>>>    d. Expected Attendance (figures from the previous IETF are sent when
>>>>       WG/BOF scheduling opens)
>>>>    e. Special requests (i.e. multicast):
>>>>    f. Number of slots:
>>>>
>>>> one
>>>>
>>>>    g. Length of slot:
>>>>
>>>> two hours
>>>>
>>>>       - 1 hour
>>>>       - 2 hours
>>>>       - 2 1/2 hours
>>>>
>>>> Proposed BoF meeting chair: Erik Nordmark
>>>>
>>>> Web page (which has a reference to the mailing list, archives, papers
>>>> and presentations with proposed solutions):
>>>>
>>>>     http://www.postel.org/rbridge/
>>>>
>>>> Problem statement:
>>>>   It is desirable for an organization to have a fairly large campus
>>>> with a single IP address prefix, a rich physical topology,
>>>> where the network elements do not need to be configured,
>>>> where endnodes can move around without changing their IP addresses,
>>>> and where ARP and Neighbor Discovery traffic can be confined.
>>>>
>>>> This functionality is often provided by bridges. However, bridges 
>>>> have disadvantages: routing
>>>> is confined to a spanning tree (precluding pair-wise shortest paths),
>>>> ARP and Neighbor Discovery packets must be carried across all the 
>>>> links,
>>>> the header on which the spanning tree forwards has no hop count,
>>>> spanning tree forwarding in the presence of temporary loops spawns
>>>> exponential copies of packets, nodes can have only a single point of
>>>> attachment, the spanning tree, in order to avoid temporary loops,
>>>> is slow to start forwarding on new ports, and it is not possible to 
>>>> take
>>>> advantage of the rich physical topology for capacity since the 
>>>> packet flows
>>>> are restricted to following the spanning tree.
>>>>
>>>> Routers on the other hand avoid those disadvatages but have their own
>>>> disadvantages: IP addresses are link specific so a host that moves must
>>>> change its IP address, the routers must be configured with unique 
>>>> link prefixes
>>>> for each of the attached links, and the block of IP address space 
>>>> can not be
>>>> fully utilized because it must be partitioned across the different 
>>>> links.
>>>>
>>>> The BoF will explore combining the benefits of bridges and routers 
>>>> without
>>>> requiring any changes on any of the hosts, IP routers, or bridges.
>>>> The design should support both IPv4 and IPv6.
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>> ----- End Included Message -----<
>>>>>   
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://www.postel.org/mailman/listinfo/rbridge
>>>>  
>>>>
>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://www.postel.org/mailman/listinfo/rbridge
>>
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge




Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4DJmOJ00142 for <[e-mail]>; Thu, 13 May 2004 12:48:24 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4DJmIu29220; Thu, 13 May 2004 12:48:18 -0700
X-mProtect: <200405131948> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5b9wyx; Thu, 13 May 2004 12:48:16 PDT
Message-ID: <[e-mail]>
Date: Thu, 13 May 2004 12:48:29 -0700
From: Fred Templin <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: Erik Nordmark <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2004 19:48:47 -0000
Status: RO
Content-Length: 384

Fred Templin wrote:

> IP Virtual Link eXtension (ipvlx)


Not intending to push my own proposal, but I just noticed that
strategic capitalization of this acronym would give: 'IPvLX'
which (treating the final two characters as roman numerals)
could allow for a claim that the new working group would
be an order-of-magnitude better than some others...

Fred
[e-mail]




Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4DJAKJ19395 for <[e-mail]>; Thu, 13 May 2004 12:10:20 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4DJABl23153; Thu, 13 May 2004 12:10:11 -0700
X-mProtect: <200405131910> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6pJK4r; Thu, 13 May 2004 12:10:08 PDT
Message-ID: <[e-mail]>
Date: Thu, 13 May 2004 12:10:22 -0700
From: Fred Templin <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
References: <[e-mail]>	<[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2004 19:10:50 -0000
Status: RO
Content-Length: 4805

Radia Perlman wrote:

> I like vlx. Though perhaps it's not clear what
> a "virtual link" is. So perhaps "extended IP Subnet",
> which might have a pronouncable acronym of EXIPS
> (EXtended IP Subnets)


Would be better than "IP Subnet Extensions", which
would have an unfortunate acronym and pronounciation.

Fred
[e-mail]

> Radia
>
>
> Fred Templin wrote:
>
>> Hello Erik,
>>
>> As to names for the prospective WG, how about:
>>
>>  Virtual Link eXtension (vlx)
>>
>> or, if the above sounds too layer-2 centric:
>>
>>  IP Virtual Link eXtension (ipvlx)
>>
>> Fred
>> [e-mail]
>>
>>
>> Erik Nordmark wrote:
>>
>>> We needed to request a BoF fairly quickly to make sure the IESG has 
>>> time
>>> to review it, so I've submitted a draft BoF request (see below).
>>>
>>> I expect the details to change, especially the name :-)
>>>
>>> Comments on the problem statement and suggestions for a better name
>>> are especially welcome.
>>>
>>> The authors of the rbridge internet-draft asked me if I would chair the
>>> BoF which is fine with me. This does not mean I would necessarily be a
>>> WG chair if a WG is formed as a result of the BoF.
>>>
>>>   Erik
>>>
>>>
>>>  
>>>
>>>> ----- Begin Included Message -----<
>>>>   
>>>
>>>
>>>
>>> Date: Wed, 12 May 2004 15:26:19 -0700 (PDT)
>>> From: "Erik Nordmark" <[e-mail]>
>>> Subject: BOF request: ISITFUN
>>> To: [e-mail], [e-mail], [e-mail]
>>> Cc: [e-mail], [e-mail]
>>>
>>>    a. Working Group or BOF full name with acronym in brackets:
>>>
>>> IP Subnets In Topologies which are Flexible, Universal, and Nice 
>>> [ISITFUN]
>>>
>>> Note: we will almost certainly come up with a better name than this
>>>
>>>    b. AREA under which Working Group or BOF appears:
>>>
>>> Internet
>>>
>>>    c. CONFLICTS you wish to avoid, please be as specific as possible:
>>>
>>> VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops
>>>
>>>    d. Expected Attendance (figures from the previous IETF are sent when
>>>       WG/BOF scheduling opens)
>>>    e. Special requests (i.e. multicast):
>>>    f. Number of slots:
>>>
>>> one
>>>
>>>    g. Length of slot:
>>>
>>> two hours
>>>
>>>       - 1 hour
>>>       - 2 hours
>>>       - 2 1/2 hours
>>>
>>> Proposed BoF meeting chair: Erik Nordmark
>>>
>>> Web page (which has a reference to the mailing list, archives, papers
>>> and presentations with proposed solutions):
>>>
>>>     http://www.postel.org/rbridge/
>>>
>>> Problem statement:
>>>   It is desirable for an organization to have a fairly large campus
>>> with a single IP address prefix, a rich physical topology,
>>> where the network elements do not need to be configured,
>>> where endnodes can move around without changing their IP addresses,
>>> and where ARP and Neighbor Discovery traffic can be confined.
>>>
>>> This functionality is often provided by bridges. However, bridges 
>>> have disadvantages: routing
>>> is confined to a spanning tree (precluding pair-wise shortest paths),
>>> ARP and Neighbor Discovery packets must be carried across all the 
>>> links,
>>> the header on which the spanning tree forwards has no hop count,
>>> spanning tree forwarding in the presence of temporary loops spawns
>>> exponential copies of packets, nodes can have only a single point of
>>> attachment, the spanning tree, in order to avoid temporary loops,
>>> is slow to start forwarding on new ports, and it is not possible to 
>>> take
>>> advantage of the rich physical topology for capacity since the 
>>> packet flows
>>> are restricted to following the spanning tree.
>>>
>>> Routers on the other hand avoid those disadvatages but have their own
>>> disadvantages: IP addresses are link specific so a host that moves must
>>> change its IP address, the routers must be configured with unique 
>>> link prefixes
>>> for each of the attached links, and the block of IP address space 
>>> can not be
>>> fully utilized because it must be partitioned across the different 
>>> links.
>>>
>>> The BoF will explore combining the benefits of bridges and routers 
>>> without
>>> requiring any changes on any of the hosts, IP routers, or bridges.
>>> The design should support both IPv4 and IPv6.
>>>
>>>
>>>
>>>  
>>>
>>>> ----- End Included Message -----<
>>>>   
>>>
>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://www.postel.org/mailman/listinfo/rbridge
>>>  
>>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>
>
>
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge





Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4DIq1J14843 for <[e-mail]>; Thu, 13 May 2004 11:52:01 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4DIq0hs008799 for <[e-mail]>; Thu, 13 May 2004 12:52:00 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Thu, 13 May 2004 14:52:00 -0400 (EDT)
Received: from Sun.COM (sr-sml-4.Eng.Sun.COM [152.70.20.54]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 13 May 2004 14:52:00 -0400 (EDT)
Date: Thu, 13 May 2004 11:51:55 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414
References: <[e-mail]> <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2004 18:52:46 -0000
Status: RO
Content-Length: 4329

I like vlx. Though perhaps it's not clear what
a "virtual link" is. So perhaps "extended IP Subnet",
which might have a pronouncable acronym of EXIPS
(EXtended IP Subnets)

Radia


Fred Templin wrote:
> Hello Erik,
> 
> As to names for the prospective WG, how about:
> 
>  Virtual Link eXtension (vlx)
> 
> or, if the above sounds too layer-2 centric:
> 
>  IP Virtual Link eXtension (ipvlx)
> 
> Fred
> [e-mail]
> 
> 
> Erik Nordmark wrote:
> 
>> We needed to request a BoF fairly quickly to make sure the IESG has time
>> to review it, so I've submitted a draft BoF request (see below).
>>
>> I expect the details to change, especially the name :-)
>>
>> Comments on the problem statement and suggestions for a better name
>> are especially welcome.
>>
>> The authors of the rbridge internet-draft asked me if I would chair the
>> BoF which is fine with me. This does not mean I would necessarily be a
>> WG chair if a WG is formed as a result of the BoF.
>>
>>   Erik
>>
>>
>>  
>>
>>> ----- Begin Included Message -----<
>>>   
>>
>>
>> Date: Wed, 12 May 2004 15:26:19 -0700 (PDT)
>> From: "Erik Nordmark" <[e-mail]>
>> Subject: BOF request: ISITFUN
>> To: [e-mail], [e-mail], [e-mail]
>> Cc: [e-mail], [e-mail]
>>
>>    a. Working Group or BOF full name with acronym in brackets:
>>
>> IP Subnets In Topologies which are Flexible, Universal, and Nice 
>> [ISITFUN]
>>
>> Note: we will almost certainly come up with a better name than this
>>
>>    b. AREA under which Working Group or BOF appears:
>>
>> Internet
>>
>>    c. CONFLICTS you wish to avoid, please be as specific as possible:
>>
>> VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops
>>
>>    d. Expected Attendance (figures from the previous IETF are sent when
>>       WG/BOF scheduling opens)
>>    e. Special requests (i.e. multicast):
>>    f. Number of slots:
>>
>> one
>>
>>    g. Length of slot:
>>
>> two hours
>>
>>       - 1 hour
>>       - 2 hours
>>       - 2 1/2 hours
>>
>> Proposed BoF meeting chair: Erik Nordmark
>>
>> Web page (which has a reference to the mailing list, archives, papers
>> and presentations with proposed solutions):
>>
>>     http://www.postel.org/rbridge/
>>
>> Problem statement:
>>   It is desirable for an organization to have a fairly large campus
>> with a single IP address prefix, a rich physical topology,
>> where the network elements do not need to be configured,
>> where endnodes can move around without changing their IP addresses,
>> and where ARP and Neighbor Discovery traffic can be confined.
>>
>> This functionality is often provided by bridges. However, bridges have 
>> disadvantages: routing
>> is confined to a spanning tree (precluding pair-wise shortest paths),
>> ARP and Neighbor Discovery packets must be carried across all the links,
>> the header on which the spanning tree forwards has no hop count,
>> spanning tree forwarding in the presence of temporary loops spawns
>> exponential copies of packets, nodes can have only a single point of
>> attachment, the spanning tree, in order to avoid temporary loops,
>> is slow to start forwarding on new ports, and it is not possible to take
>> advantage of the rich physical topology for capacity since the packet 
>> flows
>> are restricted to following the spanning tree.
>>
>> Routers on the other hand avoid those disadvatages but have their own
>> disadvantages: IP addresses are link specific so a host that moves must
>> change its IP address, the routers must be configured with unique link 
>> prefixes
>> for each of the attached links, and the block of IP address space can 
>> not be
>> fully utilized because it must be partitioned across the different links.
>>
>> The BoF will explore combining the benefits of bridges and routers 
>> without
>> requiring any changes on any of the hosts, IP routers, or bridges.
>> The design should support both IPv4 and IPv6.
>>
>>
>>
>>  
>>
>>> ----- End Included Message -----<
>>>   
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>>  
>>
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge




Received: from thingmagic.com (mail.thingmagic.com [207.31.248.245]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4DHalJ20445 for <[e-mail]>; Thu, 13 May 2004 10:36:47 -0700 (PDT)
Received: from [193.147.232.246] (account margaret HELO [10.0.1.23]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 74863; Thu, 13 May 2004 13:35:58 -0400
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020405bcc9627bc902@[10.0.1.23]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 13 May 2004 13:36:30 -0400
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
From: Margaret Wasserman <[e-mail]>
Subject: Re: [rbridge] What's in a name...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2004 17:37:47 -0000
Status: RO
Content-Length: 96

Or, playing on the word "hybrid", how about:

Hybrid Bridge/Router BOF (hybridge)?

Margaret



Received: from thingmagic.com (mail.thingmagic.com [207.31.248.245]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4DHQ5J17331 for <[e-mail]>; Thu, 13 May 2004 10:26:05 -0700 (PDT)
Received: from [193.147.232.246] (account margaret HELO [10.0.1.23]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 74856; Thu, 13 May 2004 13:25:13 -0400
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020403bcc95fb3222e@[10.0.1.23]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 13 May 2004 13:25:48 -0400
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
From: Margaret Wasserman <[e-mail]>
Subject: Re: [rbridge] What's in a name...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2004 17:26:48 -0000
Status: RO
Content-Length: 1426

Speaking only as an individual...

At 1:23 PM -0700 5/12/04, Radia Perlman wrote:
>Which...we should ask for a BOF in San Diego. Any ideas for
>a WG name? I'll toss one into the ring, not that I like it,
>but it might cause someone to come up with something better:
>"Multilink IP Subnets", with the acronym MIPS.

Since the term "multi-link subnets" was commonly used in the IPv6 
community to refer to something else (ND Proxy-based multiple link 
subnets), I think it might cause some confusion to use this name.

How about somthing like:

Layer Three Bridging (L3B)?

Not sexy, I know...

Margaret


>
>*Surely* someone can think of something better...
>
>Radia
>
>
>Fred Templin wrote:
>>  Hello Radia,
>>  Radia Perlman wrote:
>>
>>>  produce more drafts. For instance, I came up with the word "RBridge",
>>>  but I don't particularly like it. I'd be happy to hear a better one.
>>
>>  During my Digital Equipment Corporation days (back in the late 80's
>>  when I believe you were also there) I recall the term "brouter" (for
>>  "bridge/router") being used by the people in Littleton, MA. Was
>>  this another term that you had coined? And, would it be possible
>>  to revive it for use in the context of these discussions?
>>  Thanks - Fred
>>  [e-mail]
>>
>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge



Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4DGTWJ29374 for <[e-mail]>; Thu, 13 May 2004 09:29:32 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4DGTLB09004; Thu, 13 May 2004 09:29:21 -0700
X-mProtect: <200405131629> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdl8Wplm; Thu, 13 May 2004 09:29:17 PDT
Message-ID: <[e-mail]>
Date: Thu, 13 May 2004 09:29:29 -0700
From: Fred Templin <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: "Developing a hybrid router/bridge." <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2004 16:29:54 -0000
Status: RO
Content-Length: 3773

Hello Erik,

As to names for the prospective WG, how about:

  Virtual Link eXtension (vlx)

or, if the above sounds too layer-2 centric:

  IP Virtual Link eXtension (ipvlx)

Fred
[e-mail]


Erik Nordmark wrote:

>We needed to request a BoF fairly quickly to make sure the IESG has time
>to review it, so I've submitted a draft BoF request (see below).
>
>I expect the details to change, especially the name :-)
>
>Comments on the problem statement and suggestions for a better name
>are especially welcome.
>
>The authors of the rbridge internet-draft asked me if I would chair the
>BoF which is fine with me. This does not mean I would necessarily be a
>WG chair if a WG is formed as a result of the BoF.
>
>   Erik
>
>
>  
>
>>----- Begin Included Message -----<
>>    
>>
>
>Date: Wed, 12 May 2004 15:26:19 -0700 (PDT)
>From: "Erik Nordmark" <[e-mail]>
>Subject: BOF request: ISITFUN
>To: [e-mail], [e-mail], [e-mail]
>Cc: [e-mail], [e-mail]
>
>    a. Working Group or BOF full name with acronym in brackets:
>
>IP Subnets In Topologies which are Flexible, Universal, and Nice [ISITFUN]
>
>Note: we will almost certainly come up with a better name than this
>
>    b. AREA under which Working Group or BOF appears:
>
>Internet
>
>    c. CONFLICTS you wish to avoid, please be as specific as possible:
>
>VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops
>
>    d. Expected Attendance (figures from the previous IETF are sent when
>       WG/BOF scheduling opens)
>    e. Special requests (i.e. multicast):
>    f. Number of slots:
>
>one
>
>    g. Length of slot:
>
>two hours
>
>       - 1 hour
>       - 2 hours
>       - 2 1/2 hours
>
>Proposed BoF meeting chair: Erik Nordmark
>
>Web page (which has a reference to the mailing list, archives, papers
>and presentations with proposed solutions):
>
>	http://www.postel.org/rbridge/
>
>Problem statement:
>   
>It is desirable for an organization to have a fairly large campus
>with a single IP address prefix, a rich physical topology,
>where the network elements do not need to be configured,
>where endnodes can move around without changing their IP addresses,
>and where ARP and Neighbor Discovery traffic can be confined.
>
>This functionality is often provided by bridges. 
>However, bridges have disadvantages: routing
>is confined to a spanning tree (precluding pair-wise shortest paths),
>ARP and Neighbor Discovery packets must be carried across all the links,
>the header on which the spanning tree forwards has no hop count,
>spanning tree forwarding in the presence of temporary loops spawns
>exponential copies of packets, nodes can have only a single point of
>attachment, the spanning tree, in order to avoid temporary loops,
>is slow to start forwarding on new ports, and it is not possible to take
>advantage of the rich physical topology for capacity since the packet flows
>are restricted to following the spanning tree.
>
>Routers on the other hand avoid those disadvatages but have their own
>disadvantages: IP addresses are link specific so a host that moves must
>change its IP address, the routers must be configured with unique link prefixes
>for each of the attached links, and the block of IP address space can not be
>fully utilized because it must be partitioned across the different links.
>
>The BoF will explore combining the benefits of bridges and routers without
>requiring any changes on any of the hosts, IP routers, or bridges.
>The design should support both IPv4 and IPv6.
>
>
>
>  
>
>>----- End Included Message -----<
>>    
>>
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>




Received: from isi.edu (lsanca1-ar42-4-61-173-069.lsanca1.dsl-verizon.net [4.61.173.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4D067J14664; Wed, 12 May 2004 17:06:07 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 17:06:07 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6CAE0559420A9AE6FEF2D1AF"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2004 00:06:45 -0000
Status: RO
Content-Length: 5355

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6CAE0559420A9AE6FEF2D1AF
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Erik Nordmark wrote:

> We needed to request a BoF fairly quickly to make sure the IESG has time
> to review it, so I've submitted a draft BoF request (see below).
> 
> I expect the details to change, especially the name :-)
> 
> Comments on the problem statement and suggestions for a better name
> are especially welcome.
> 
> The authors of the rbridge internet-draft asked me if I would chair the
> BoF which is fine with me. This does not mean I would necessarily be a
> WG chair if a WG is formed as a result of the BoF.
> 
>    Erik
> 
> 
> 
>>----- Begin Included Message -----<
> 
> 
> Date: Wed, 12 May 2004 15:26:19 -0700 (PDT)
> From: "Erik Nordmark" <[e-mail]>
> Subject: BOF request: ISITFUN
> To: [e-mail], [e-mail], [e-mail]
> Cc: [e-mail], [e-mail]
> 
>     a. Working Group or BOF full name with acronym in brackets:
> 
> IP Subnets In Topologies which are Flexible, Universal, and Nice [ISITFUN]
> 
> Note: we will almost certainly come up with a better name than this
> 
>     b. AREA under which Working Group or BOF appears:
> 
> Internet

Seems like this isn't Internet unless it provides L3; since it provides 
L2, this might formerly be sub-IP, but currently might map better to 
Operations & Management.

> 
>     c. CONFLICTS you wish to avoid, please be as specific as possible:
> 
> VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops

L2VPN is the most specific I can imagine (it's not clear why that's in 
the Internet area either, IMO) that is active right now.

Zeroconf overlaps a little.

If there isn't a more specific place where NBMA subnets are covered, the 
general routing area might apply, though as you point out they might 
overlap with IPv6, Multi6 and v6ops (unlikely, but at least covers the 
bases). FWIW, the most relevant former group would (IMO) be ion in this 
regard, and certainly ion and its former precursor rolc are places to 
fish for participants ;-)

I don't see IPsec as relevant (it's ended anyway), or SAAG for that 
matter. There may be L2 security issues, or interesting uses of L3 
security inside the Rbridge, but unless we need modifications of those 
capabilities (not likely at the present at least), this is just a use of 
that technology.

>     d. Expected Attendance (figures from the previous IETF are sent when
>        WG/BOF scheduling opens)
>     e. Special requests (i.e. multicast):
>     f. Number of slots:
> 
> one
> 
>     g. Length of slot:
> 
> two hours
> 
>        - 1 hour
>        - 2 hours
>        - 2 1/2 hours
> 
> Proposed BoF meeting chair: Erik Nordmark
> 
> Web page (which has a reference to the mailing list, archives, papers
> and presentations with proposed solutions):
> 
> 	http://www.postel.org/rbridge/
> 
> Problem statement:
>    
> It is desirable for an organization to have a fairly large campus
> with a single IP address prefix, a rich physical topology,
> where the network elements do not need to be configured,
> where endnodes can move around without changing their IP addresses,
> and where ARP and Neighbor Discovery traffic can be confined.
> 
> This functionality is often provided by bridges. 
> However, bridges have disadvantages: routing
> is confined to a spanning tree (precluding pair-wise shortest paths),
> ARP and Neighbor Discovery packets must be carried across all the links,
> the header on which the spanning tree forwards has no hop count,
> spanning tree forwarding in the presence of temporary loops spawns
> exponential copies of packets, nodes can have only a single point of
> attachment, the spanning tree, in order to avoid temporary loops,
> is slow to start forwarding on new ports, and it is not possible to take
> advantage of the rich physical topology for capacity since the packet flows
> are restricted to following the spanning tree.
> 
> Routers on the other hand avoid those disadvatages but have their own
> disadvantages: IP addresses are link specific so a host that moves must
> change its IP address, the routers must be configured with unique link prefixes
> for each of the attached links, and the block of IP address space can not be
> fully utilized because it must be partitioned across the different links.
> 
> The BoF will explore combining the benefits of bridges and routers without
> requiring any changes on any of the hosts, IP routers, or bridges.
> The design should support both IPv4 and IPv6.
> 
> 
> 
> 
>>----- End Included Message -----<
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enig6CAE0559420A9AE6FEF2D1AF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAorvvE5f5cImnZrsRAiBxAKCUDmOnNS/p8v9MKOpPwc7TCVQFOQCg+qn3
yshoS7GNqPg1ojiprZd5whA=
=zxrW
-----END PGP SIGNATURE-----

--------------enig6CAE0559420A9AE6FEF2D1AF--


Received: from isi.edu (lsanca1-ar42-4-61-173-069.lsanca1.dsl-verizon.net [4.61.173.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4D03bJ14244; Wed, 12 May 2004 17:03:37 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 17:03:32 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Initial cut at BoF request
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig106FC0329A59A5DAE10C3660"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2004 00:04:43 -0000
Status: RO
Content-Length: 5355

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig106FC0329A59A5DAE10C3660
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Erik Nordmark wrote:

> We needed to request a BoF fairly quickly to make sure the IESG has time
> to review it, so I've submitted a draft BoF request (see below).
> 
> I expect the details to change, especially the name :-)
> 
> Comments on the problem statement and suggestions for a better name
> are especially welcome.
> 
> The authors of the rbridge internet-draft asked me if I would chair the
> BoF which is fine with me. This does not mean I would necessarily be a
> WG chair if a WG is formed as a result of the BoF.
> 
>    Erik
> 
> 
> 
>>----- Begin Included Message -----<
> 
> 
> Date: Wed, 12 May 2004 15:26:19 -0700 (PDT)
> From: "Erik Nordmark" <[e-mail]>
> Subject: BOF request: ISITFUN
> To: [e-mail], [e-mail], [e-mail]
> Cc: [e-mail], [e-mail]
> 
>     a. Working Group or BOF full name with acronym in brackets:
> 
> IP Subnets In Topologies which are Flexible, Universal, and Nice [ISITFUN]
> 
> Note: we will almost certainly come up with a better name than this
> 
>     b. AREA under which Working Group or BOF appears:
> 
> Internet

Seems like this isn't Internet unless it provides L3; since it provides 
L2, this might formerly be sub-IP, but currently might map better to 
Operations & Management.

> 
>     c. CONFLICTS you wish to avoid, please be as specific as possible:
> 
> VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops

L2VPN is the most specific I can imagine (it's not clear why that's in 
the Internet area either, IMO) that is active right now.

Zeroconf overlaps a little.

If there isn't a more specific place where NBMA subnets are covered, the 
general routing area might apply, though as you point out they might 
overlap with IPv6, Multi6 and v6ops (unlikely, but at least covers the 
bases). FWIW, the most relevant former group would (IMO) be ion in this 
regard, and certainly ion and its former precursor rolc are places to 
fish for participants ;-)

I don't see IPsec as relevant (it's ended anyway), or SAAG for that 
matter. There may be L2 security issues, or interesting uses of L3 
security inside the Rbridge, but unless we need modifications of those 
capabilities (not likely at the present at least), this is just a use of 
that technology.

>     d. Expected Attendance (figures from the previous IETF are sent when
>        WG/BOF scheduling opens)
>     e. Special requests (i.e. multicast):
>     f. Number of slots:
> 
> one
> 
>     g. Length of slot:
> 
> two hours
> 
>        - 1 hour
>        - 2 hours
>        - 2 1/2 hours
> 
> Proposed BoF meeting chair: Erik Nordmark
> 
> Web page (which has a reference to the mailing list, archives, papers
> and presentations with proposed solutions):
> 
> 	http://www.postel.org/rbridge/
> 
> Problem statement:
>    
> It is desirable for an organization to have a fairly large campus
> with a single IP address prefix, a rich physical topology,
> where the network elements do not need to be configured,
> where endnodes can move around without changing their IP addresses,
> and where ARP and Neighbor Discovery traffic can be confined.
> 
> This functionality is often provided by bridges. 
> However, bridges have disadvantages: routing
> is confined to a spanning tree (precluding pair-wise shortest paths),
> ARP and Neighbor Discovery packets must be carried across all the links,
> the header on which the spanning tree forwards has no hop count,
> spanning tree forwarding in the presence of temporary loops spawns
> exponential copies of packets, nodes can have only a single point of
> attachment, the spanning tree, in order to avoid temporary loops,
> is slow to start forwarding on new ports, and it is not possible to take
> advantage of the rich physical topology for capacity since the packet flows
> are restricted to following the spanning tree.
> 
> Routers on the other hand avoid those disadvatages but have their own
> disadvantages: IP addresses are link specific so a host that moves must
> change its IP address, the routers must be configured with unique link prefixes
> for each of the attached links, and the block of IP address space can not be
> fully utilized because it must be partitioned across the different links.
> 
> The BoF will explore combining the benefits of bridges and routers without
> requiring any changes on any of the hosts, IP routers, or bridges.
> The design should support both IPv4 and IPv6.
> 
> 
> 
> 
>>----- End Included Message -----<
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enig106FC0329A59A5DAE10C3660
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAortYE5f5cImnZrsRAgrFAJ4xHSdfx0OhVtSnf2brfbQBA0QuWQCg88Pr
yVVyx3TQwqkwdpfEjuKhWgQ=
=XCIF
-----END PGP SIGNATURE-----

--------------enig106FC0329A59A5DAE10C3660--


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4CMW3J22596 for <[e-mail]>; Wed, 12 May 2004 15:32:03 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4CMW1hs005311 for <[e-mail]>; Wed, 12 May 2004 16:32:02 -0600 (MDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i4CMVxQ06689; Thu, 13 May 2004 00:31:59 +0200 (MEST)
Date: Wed, 12 May 2004 15:32:04 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
Subject: [rbridge] Initial cut at BoF request
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 22:32:44 -0000
Status: RO
Content-Length: 3273

We needed to request a BoF fairly quickly to make sure the IESG has time
to review it, so I've submitted a draft BoF request (see below).

I expect the details to change, especially the name :-)

Comments on the problem statement and suggestions for a better name
are especially welcome.

The authors of the rbridge internet-draft asked me if I would chair the
BoF which is fine with me. This does not mean I would necessarily be a
WG chair if a WG is formed as a result of the BoF.

   Erik


>----- Begin Included Message -----<

Date: Wed, 12 May 2004 15:26:19 -0700 (PDT)
From: "Erik Nordmark" <[e-mail]>
Subject: BOF request: ISITFUN
To: [e-mail], [e-mail], [e-mail]
Cc: [e-mail], [e-mail]

    a. Working Group or BOF full name with acronym in brackets:

IP Subnets In Topologies which are Flexible, Universal, and Nice [ISITFUN]

Note: we will almost certainly come up with a better name than this

    b. AREA under which Working Group or BOF appears:

Internet

    c. CONFLICTS you wish to avoid, please be as specific as possible:

VRRP, routing area meeting, SAAG, IPsec, IPv6, Multi6, v6ops

    d. Expected Attendance (figures from the previous IETF are sent when
       WG/BOF scheduling opens)
    e. Special requests (i.e. multicast):
    f. Number of slots:

one

    g. Length of slot:

two hours

       - 1 hour
       - 2 hours
       - 2 1/2 hours

Proposed BoF meeting chair: Erik Nordmark

Web page (which has a reference to the mailing list, archives, papers
and presentations with proposed solutions):

	http://www.postel.org/rbridge/

Problem statement:
   
It is desirable for an organization to have a fairly large campus
with a single IP address prefix, a rich physical topology,
where the network elements do not need to be configured,
where endnodes can move around without changing their IP addresses,
and where ARP and Neighbor Discovery traffic can be confined.

This functionality is often provided by bridges. 
However, bridges have disadvantages: routing
is confined to a spanning tree (precluding pair-wise shortest paths),
ARP and Neighbor Discovery packets must be carried across all the links,
the header on which the spanning tree forwards has no hop count,
spanning tree forwarding in the presence of temporary loops spawns
exponential copies of packets, nodes can have only a single point of
attachment, the spanning tree, in order to avoid temporary loops,
is slow to start forwarding on new ports, and it is not possible to take
advantage of the rich physical topology for capacity since the packet flows
are restricted to following the spanning tree.

Routers on the other hand avoid those disadvatages but have their own
disadvantages: IP addresses are link specific so a host that moves must
change its IP address, the routers must be configured with unique link prefixes
for each of the attached links, and the block of IP address space can not be
fully utilized because it must be partitioned across the different links.

The BoF will explore combining the benefits of bridges and routers without
requiring any changes on any of the hosts, IP routers, or bridges.
The design should support both IPv4 and IPv6.



>----- End Included Message -----<



Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4CKNXJ18292 for <[e-mail]>; Wed, 12 May 2004 13:23:33 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4CKM8hO003378 for <[e-mail]>; Wed, 12 May 2004 14:22:08 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Wed, 12 May 2004 16:23:31 -0400 (EDT)
Received: from Sun.COM (sr1-umpk-11.SFBay.Sun.COM [129.146.11.181]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 12 May 2004 16:23:31 -0400 (EDT)
Date: Wed, 12 May 2004 13:23:30 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030711
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] What's in a name...
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 20:23:42 -0000
Status: RO
Content-Length: 1522

I think I didn't coin the term "brouter", but since it is somewhat in
use, and for a different thing, I don't think we should use it.
A brouter is something that acts as both a bridge and a router.
When it sees a packet it looks at the layer 2 protocol type field.
If it is a layer 3 protocol it knows how to route, it acts like
a router. If it is any other protocol, it bridges it.

So that's very different from this proposal, and it would create
confusion if we used it.

Perhaps if we did something like they do on these morning news
shows when the local zoo has a new baby giraffe...run a contest for
"name this protocol".

Which...we should ask for a BOF in San Diego. Any ideas for
a WG name? I'll toss one into the ring, not that I like it,
but it might cause someone to come up with something better:
"Multilink IP Subnets", with the acronym MIPS.

*Surely* someone can think of something better...

Radia


Fred Templin wrote:
> Hello Radia,
> 
> Radia Perlman wrote:
> 
>> produce more drafts. For instance, I came up with the word "RBridge",
>> but I don't particularly like it. I'd be happy to hear a better one.
> 
> 
> 
> During my Digital Equipment Corporation days (back in the late 80's
> when I believe you were also there) I recall the term "brouter" (for
> "bridge/router") being used by the people in Littleton, MA. Was
> this another term that you had coined? And, would it be possible
> to revive it for use in the context of these discussions?
> 
> Thanks - Fred
> [e-mail]
> 
> 




Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4CKBJJ14894 for <[e-mail]>; Wed, 12 May 2004 13:11:19 -0700 (PDT)
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i4CKB9726178; Wed, 12 May 2004 13:11:09 -0700
X-mProtect: <200405122011> Nokia Silicon Valley Messaging Protection
Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6SivgP; Wed, 12 May 2004 13:11:06 PDT
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 13:11:13 -0700
From: Fred Templin <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 20:11:42 -0000
Status: RO
Content-Length: 546

Hello Radia,

Radia Perlman wrote:

> produce more drafts. For instance, I came up with the word "RBridge",
> but I don't particularly like it. I'd be happy to hear a better one.


During my Digital Equipment Corporation days (back in the late 80's
when I believe you were also there) I recall the term "brouter" (for
"bridge/router") being used by the people in Littleton, MA. Was
this another term that you had coined? And, would it be possible
to revive it for use in the context of these discussions?

Thanks - Fred
[e-mail]




Received: from isi.edu (lsanca1-ar42-4-61-173-069.lsanca1.dsl-verizon.net [4.61.173.69]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4CGHvJ03930; Wed, 12 May 2004 09:17:57 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 09:17:57 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Re: IP and MPLS TTL
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5FB16BDE8BA1785A731DAD03"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 16:19:05 -0000
Status: RO
Content-Length: 2196

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5FB16BDE8BA1785A731DAD03
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Loa Andersson wrote:

> this one too
> 
> /Loa
> 
> Loa Andersson wrote:
> 
>> All,
>>
>> on the TTL discussion - and I'm not sure if I want to
>> decrement the TTL or not yet - there is one mpls aspect that
>> needs to be considered.
>>
>> On any given link in a MPLS enabled IP network ther might be
>> a mix of "pure" IP-packets and packets encapsulated with a mpls
>> shim header. Now, if there are any mpls shim header, and we want
>> to decremetn the TLL the rbridge needs to understand to decrement
>> the TTL in the shime header, but not in the IP header.
>>
>> If the rbridge is the pen ultimate mpls node it should "pop" the
>> mpls shim header and re-write the IP TLL based on a set of rules
>> (RFC3443) - butif we go down this route the rbridge becomes very
>> close to an LSR.
>>
>> /Loa

This goes to my note prior note about MPLS. I agree that this might not 
be what some consider a layer, though many do. The ways in which it 
modifies other layers violates those layers, and results in 
inconsistencies. This is perhaps one of them.

I.e., I put MPLS and NATs in the same "use at your own risk" bin in this 
regard. So long as an rbridge presents a consistent, strictly layer-2 
service (it presents L2 to the periphery, regardless of what it tunnels 
over internally), then it should be equivalent to other strictly-L2 
boxes, like l2 switches.

The catch is that many L2 switches aren't L2; they snoop IGMP, etc. I'm 
not sure if MPLS falls into that category...

Joe

--------------enig5FB16BDE8BA1785A731DAD03
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAok41E5f5cImnZrsRAjd9AJ9MfV9AfTZtAuPgNKlEzwC3U+9JBACfYiZY
OZJVo0mSofJY7eaVjFZloP4=
=o8zw
-----END PGP SIGNATURE-----

--------------enig5FB16BDE8BA1785A731DAD03--


Received: from av3-2-sn3.vrr.skanova.net (av3-2-sn3.vrr.skanova.net [81.228.9.110]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4C8xmJ18199 for <[e-mail]>; Wed, 12 May 2004 01:59:49 -0700 (PDT)
Received: by av3-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 63D5237F3F; Wed, 12 May 2004 10:59:42 +0200 (CEST)
Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 5692C37E7A for <[e-mail]>; Wed, 12 May 2004 10:59:42 +0200 (CEST)
Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 2EB053801F for <[e-mail]>; Wed, 12 May 2004 10:59:42 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 10:59:36 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Re: IP and MPLS TTL
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 09:00:39 -0000
Status: RO
Content-Length: 800

this one too

/Loa

Loa Andersson wrote:

> All,
> 
> on the TTL discussion - and I'm not sure if I want to
> decrement the TTL or not yet - there is one mpls aspect that
> needs to be considered.
> 
> On any given link in a MPLS enabled IP network ther might be
> a mix of "pure" IP-packets and packets encapsulated with a mpls
> shim header. Now, if there are any mpls shim header, and we want
> to decremetn the TLL the rbridge needs to understand to decrement
> the TTL in the shime header, but not in the IP header.
> 
> If the rbridge is the pen ultimate mpls node it should "pop" the
> mpls shim header and re-write the IP TLL based on a set of rules
> (RFC3443) - butif we go down this route the rbridge becomes very
> close to an LSR.
> 
> /Loa

-- 

Loa Andersson

mobile [phone]



Received: from av5-1-sn3.vrr.skanova.net (av5-1-sn3.vrr.skanova.net [81.228.9.113]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4C8x4J18016 for <[e-mail]>; Wed, 12 May 2004 01:59:04 -0700 (PDT)
Received: by av5-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 52BC337F26; Wed, 12 May 2004 10:58:58 +0200 (CEST)
Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av5-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4142B37E45; Wed, 12 May 2004 10:58:58 +0200 (CEST)
Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 1688D38010; Wed, 12 May 2004 10:58:58 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 10:58:54 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], Dimitri Papadimitriou <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
Subject: [rbridge] Re: rbridge and gmpls
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 08:59:39 -0000
Status: RO
Content-Length: 611

:(, managed to send to the wrong list (rbridge-request)

Loa Andersson wrote:

> All,
> 
> the more I think about it there might be an overlap between
> what is done on this  list and what is done in GMPLS for Ethernet.
> Currently I don't see a competetion, but the rbridge might be
> just the L2-switch we need for enabling what is discussed in
> GMPLS. cc'ed Dimitri to bring this to bive him a heads up.
> 
> Dimitri,
> 
> I've copied you on this - if you are interest, you'll find
> information about it aty:
> 
> 
> http://www.postel.org/rbridge
> 
> /Loa
> 

-- 

Loa Andersson

mobile [phone]



Received: from av7-2-sn1.fre.skanova.net (av7-2-sn1.fre.skanova.net [81.228.11.114]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4C8b3J13399 for <[e-mail]>; Wed, 12 May 2004 01:37:03 -0700 (PDT)
Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id DF6E437F1B; Wed, 12 May 2004 10:36:56 +0200 (CEST)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id C7D6637E50; Wed, 12 May 2004 10:36:56 +0200 (CEST)
Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id 9364737E4C; Wed, 12 May 2004 10:36:56 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 10:36:53 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [rbridge] Developing a hybrid router/bridge.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 08:38:40 -0000
Status: RO
Content-Length: 6178

Radia Perlman wrote:

> Replying to Loa:

> 
> 4) > a. if we have multiple rbridges on a link, does that mean that
>  >    thraffic from a non-DR needs to traverse the link twice?
> 
> as designed currently, the answer is yes, there can be a suboptimal
> hop in both the forward and reverse direction. There are several
> answers we could make to this:
> 
> . an extra hop or two doesn't matter

no, that is true - but what I was thinking about is that if a
high number of packet traverse the same link twice that might matter

> . this will be rare, because mostly there is no shared media anymore...

yeah, I can buy that - I've deployed such WAN's, but we probably should
be explicit about it

> an endnode will be on a single port to an RBridge, so there is no
> "other RBridge" on that link. If an endnode wants redundancy, it
> will be connected to two separate RBridges on each of its two ports.
> To counter this argument, one could point out that if the first switch
> the endnode is connected to is a regular bridge, and there are
> multiple RBridges connected to bridges connected to the endnode, then
> it will look like a shared medium. And there might be extra hops (at
> most 2 total). An answer to that is "make sure the first device is
> an RBridge rather than a bridge".
> . if this is a concern, and this is a plausible topology, we can perhaps
> be clever and eliminate the extra hops. I'll send a separate note about
> how I think this can be done, at least in one direction (so this
> note won't be too long, and perhaps so I can think about it a bit more
> before bothering the list with too underdone an idea).
> 
>  > b. will end nodes learn membership, or do they have to forward
>  >    traffic for other end nodes on the same link via the rbridge?
> 
> If A and B are on the same local link, then when A does an ARP, it
> will get an ARP reply from B, and will talk directly to B. The
> RBridge will not get in the way of traffic between A and B.

swell, again we might want to state this

/Loa
> 
> Radia
> 
> 
> 
>> Radia,
>>
>> I've tried to catch up on the rbridge mails, but I'm not sure
>> I've captured everything, also reading your paper from the IEEE
>> conference.
>>
>> First - I think this is an idea that is very interesting. I guess
>> we need to understand how it fits in with what Dimitri is doing with
>> GMPLS-based Ethernet.
>>
>> Second - I'm a bit concerned about some of the assumptions on
>> MPLS on this mailing list, but that is probably something I've to
>> live with.
>>
>> Third - I'm not happy about the the L2.5 terminology, it is at
>> best just not explaining anything and at worst is misleading.
>> Model-wise the de?stinctions between the layers is clear,
>> specification-wise we sometimes specifies L2 and L3 functionality in
>> the same doc. Implementation-wise we implement boxes tht only
>> have a subset of L2 or L3 functionality, but that don't make
>> the a Layer 2.5, they are just boxes there some functions are
>> are distributed. But guess that this is close to religion anyway ...
>>
>> One other question I've is on the DR - in your paper you say that
>> the Dr is the only rbridge that will learn membership of end nodes
>> on a link and is allowed to forward traffic to end nodes on that
>> link.
>>
>> a. if we have multiple rbridges on a link, does that mean that
>>    thraffic from a non-DR needs to traverse the link twice?
>> b. will end nodes learn membership, or do they have to forward
>>    traffic for other end nodes on the same link via the rbridge?
>>
>> /loa
>>
>>
>>
>> Radia Perlman wrote:
>>
>>> Actually, a bridge forwarding from a link across the virtual subnet
>>> would not decrement the TTL, and if an RBridge is supposed to
>>> "look like a bridge", it wouldn't either.
>>>
>>> If there was a link where an IP endnode S
>>> is trying to send the packet to a neighbor D on that subnet, if the 
>>> Rbridge
>>> is to be transparent when forwarding it, the TTL
>>> would be the same when received by D as sent by S.
>>>
>>> It would be nice if the 2nd RBridge (in the example I gave in
>>> the previous email),
>>> that forwarded it across the virtual
>>> subnet knew that it already had been forwarded across the subnet, but
>>> in that weird temporary case, it might think the packet originated 
>>> locally, and therefore forward it across the virtual link.
>>>
>>> I think we can fix this case without any cost, by flagging "this was
>>> already forwarded across this virtual link by an RBridge" by using the
>>> source address in the layer 2 header of the decapsulated packet
>>> (since I think IP nodes won't care what's there).
>>>
>>> Radia
>>>
>>>
>>>
>>> Erik Nordmark wrote:
>>>
>>>>> I was worried that a temporary loop in the campus (with the example 
>>>>> that I gave being that
>>>>> a repeater suddenly connects to LANs) would lead to looping packets 
>>>>> that were not
>>>>> detected as looping due to any hop count. If the first RBridge 
>>>>> encapsulates it with a hop count,
>>>>> it won't loop while it is travelling across the campus, but after 
>>>>> the egress RBridge decapsulates it,
>>>>> there's no long an RBridge hop count, and the packet's IP TTL 
>>>>> hasn't changed. If another RBridge
>>>>> were, at that point, to think it should forward the packet across 
>>>>> the campus, then we'll have
>>>>> a loop uncorrected by any hop count.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> As long as the Rbridge, that decapsulates a packet and passes it on,
>>>> decrements the IP ttl by one as part of this process you still know 
>>>> the packet
>>>> can't loop forever.
>>>>
>>>> This is analogous to an IP router which forwards a packet back out the
>>>> same interface on which the packet arrived; in that case the TTL is
>>>> decremented.
>>>>
>>>>   Erik
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>
> 
> 
> 
> 

-- 

Loa Andersson

mobile [phone]



Received: from av3-1-sn4.m-sp.skanova.net (av3-1-sn4.m-sp.skanova.net [81.228.10.114]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4C8WTJ12425 for <[e-mail]>; Wed, 12 May 2004 01:32:29 -0700 (PDT)
Received: by av3-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 265FC37F1A; Wed, 12 May 2004 10:32:23 +0200 (CEST)
Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av3-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 15C0737F18; Wed, 12 May 2004 10:32:23 +0200 (CEST)
Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id D444E37E57; Wed, 12 May 2004 10:32:22 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 10:32:18 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [rbridge] Developing a hybrid router/bridge.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 08:32:40 -0000
Status: RO
Content-Length: 8749

Radia,

wasn't pointing fingers at you, actually we never discussed
mpls and the differnt view of mpls in detail, maybe we should
do that sometime.

Here are a couple of statements I ws thinking about:

from Joe Touch:

"Other more complex cases would be MPLS and other so-called layer 2.5 
protocols. I confess they never made much sense in that regard to me; 
IMO, MPLS is just a different L2 protocol that is layered over other L2 
protocols."

and from Konrad Roeder:

"I agree with Joe that MPLS switches are L2 devices with a special L2.5 
shim layer.  As part of their behavior, MPLS switches do/can decrement 
TTL.  So there is precedence here in L2 (L2.5?) devices meddling with 
TTL.  I believe that RBridges could decrement TTL to prevent loops, 
although doing so is not "a clean L2 implementation" because 
decrementing TTL indicates either a second of time went away or that a 
router was traversed."

As I said - but not sure this is the place for this debate - is that I'm
not impressed but this use of "layering". If you look at MPLS it does 
not as a technology meet requirements of to be a layer

layer 2 technologies has a coomon MAC
layer 3 technologies has a common network addressing

neither is true for mpls, or for that matter gmpls, in my mind mpls
is an addition to the IP-prtocol suite, in the sam right as gre, dns,
ipsec or whatever.

what is "special" with (g)mpls is that it support a ip networks or
application on ip networks by means of "tweaking" any of the
infrastructure layer- I tend to view mpls as a multi purpose tool
box.

/Loa

Radia Perlman wrote:

> Replying to Loa:
> 
> Sigh. My machine hung when I said "send" after I'd typed in a reply.
> I haven't seen my reply posted, so I'll type a new one, and if it's
> duplicative, sorry about that...
> 
> 1) Can you give a pointer to "what Dimitri is doing with GMPLS-based 
> Ethernet"?
> 
> 2) Can you tell us what assumptions there have been made about MPLS
> on this mailing list that worry you? No reason you have to "live with
> them". If I have any misconceptions about MPLS I really want to know.
> 
> 3) terminology: right now we mostly need to agree on what the proper
> behavior of the device should be. What are the packet formats? What
> does it do? I don't think terminology is important right now. However,
> if we can improve the terminology that would be great for when we
> produce more drafts. For instance, I came up with the word "RBridge",
> but I don't particularly like it. I'd be happy to hear a better one.
> As for "layer 2.5". I think layers are very confusing, even when one
> just talks about integers. I agree that calling it "layer 2.5" or "layer
> 2+" is likely to be confusing. So we can, in parallel, try to think
> of clearer ways of explaining things, but for now I think the most
> important thing is figuring out the proper on-the-wire behavior of
> this box.
> 
> 4) > a. if we have multiple rbridges on a link, does that mean that
>  >    thraffic from a non-DR needs to traverse the link twice?
> 
> as designed currently, the answer is yes, there can be a suboptimal
> hop in both the forward and reverse direction. There are several
> answers we could make to this:
> 
> . an extra hop or two doesn't matter
> . this will be rare, because mostly there is no shared media anymore...
> an endnode will be on a single port to an RBridge, so there is no
> "other RBridge" on that link. If an endnode wants redundancy, it
> will be connected to two separate RBridges on each of its two ports.
> To counter this argument, one could point out that if the first switch
> the endnode is connected to is a regular bridge, and there are
> multiple RBridges connected to bridges connected to the endnode, then
> it will look like a shared medium. And there might be extra hops (at
> most 2 total). An answer to that is "make sure the first device is
> an RBridge rather than a bridge".
> . if this is a concern, and this is a plausible topology, we can perhaps
> be clever and eliminate the extra hops. I'll send a separate note about
> how I think this can be done, at least in one direction (so this
> note won't be too long, and perhaps so I can think about it a bit more
> before bothering the list with too underdone an idea).
> 
>  > b. will end nodes learn membership, or do they have to forward
>  >    traffic for other end nodes on the same link via the rbridge?
> 
> If A and B are on the same local link, then when A does an ARP, it
> will get an ARP reply from B, and will talk directly to B. The
> RBridge will not get in the way of traffic between A and B.
> 
> Radia
> 
> 
> 
>> Radia,
>>
>> I've tried to catch up on the rbridge mails, but I'm not sure
>> I've captured everything, also reading your paper from the IEEE
>> conference.
>>
>> First - I think this is an idea that is very interesting. I guess
>> we need to understand how it fits in with what Dimitri is doing with
>> GMPLS-based Ethernet.
>>
>> Second - I'm a bit concerned about some of the assumptions on
>> MPLS on this mailing list, but that is probably something I've to
>> live with.
>>
>> Third - I'm not happy about the the L2.5 terminology, it is at
>> best just not explaining anything and at worst is misleading.
>> Model-wise the de?stinctions between the layers is clear,
>> specification-wise we sometimes specifies L2 and L3 functionality in
>> the same doc. Implementation-wise we implement boxes tht only
>> have a subset of L2 or L3 functionality, but that don't make
>> the a Layer 2.5, they are just boxes there some functions are
>> are distributed. But guess that this is close to religion anyway ...
>>
>> One other question I've is on the DR - in your paper you say that
>> the Dr is the only rbridge that will learn membership of end nodes
>> on a link and is allowed to forward traffic to end nodes on that
>> link.
>>
>> a. if we have multiple rbridges on a link, does that mean that
>>    thraffic from a non-DR needs to traverse the link twice?
>> b. will end nodes learn membership, or do they have to forward
>>    traffic for other end nodes on the same link via the rbridge?
>>
>> /loa
>>
>>
>>
>> Radia Perlman wrote:
>>
>>> Actually, a bridge forwarding from a link across the virtual subnet
>>> would not decrement the TTL, and if an RBridge is supposed to
>>> "look like a bridge", it wouldn't either.
>>>
>>> If there was a link where an IP endnode S
>>> is trying to send the packet to a neighbor D on that subnet, if the 
>>> Rbridge
>>> is to be transparent when forwarding it, the TTL
>>> would be the same when received by D as sent by S.
>>>
>>> It would be nice if the 2nd RBridge (in the example I gave in
>>> the previous email),
>>> that forwarded it across the virtual
>>> subnet knew that it already had been forwarded across the subnet, but
>>> in that weird temporary case, it might think the packet originated 
>>> locally, and therefore forward it across the virtual link.
>>>
>>> I think we can fix this case without any cost, by flagging "this was
>>> already forwarded across this virtual link by an RBridge" by using the
>>> source address in the layer 2 header of the decapsulated packet
>>> (since I think IP nodes won't care what's there).
>>>
>>> Radia
>>>
>>>
>>>
>>> Erik Nordmark wrote:
>>>
>>>>> I was worried that a temporary loop in the campus (with the example 
>>>>> that I gave being that
>>>>> a repeater suddenly connects to LANs) would lead to looping packets 
>>>>> that were not
>>>>> detected as looping due to any hop count. If the first RBridge 
>>>>> encapsulates it with a hop count,
>>>>> it won't loop while it is travelling across the campus, but after 
>>>>> the egress RBridge decapsulates it,
>>>>> there's no long an RBridge hop count, and the packet's IP TTL 
>>>>> hasn't changed. If another RBridge
>>>>> were, at that point, to think it should forward the packet across 
>>>>> the campus, then we'll have
>>>>> a loop uncorrected by any hop count.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> As long as the Rbridge, that decapsulates a packet and passes it on,
>>>> decrements the IP ttl by one as part of this process you still know 
>>>> the packet
>>>> can't loop forever.
>>>>
>>>> This is analogous to an IP router which forwards a packet back out the
>>>> same interface on which the packet arrived; in that case the TTL is
>>>> decremented.
>>>>
>>>>   Erik
>>>>
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [e-mail]
>>>> http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://www.postel.org/mailman/listinfo/rbridge
>>>
>>>
>>
> 
> 
> 
> 

-- 

Loa Andersson

mobile [phone]



Received: from av1-2-sn3.vrr.skanova.net (av1-2-sn3.vrr.skanova.net [81.228.9.106]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4C6lQJ20319 for <[e-mail]>; Tue, 11 May 2004 23:47:26 -0700 (PDT)
Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 8D4EA37E4A; Wed, 12 May 2004 08:47:20 +0200 (CEST)
Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7D18B37E43; Wed, 12 May 2004 08:47:20 +0200 (CEST)
Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 499F838020; Wed, 12 May 2004 08:47:19 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 08:47:16 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [rbridge] Developing a hybrid router/bridge - l2sc in gmpls
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 06:47:39 -0000
Status: RO
Content-Length: 342

Radia Perlman wrote:

> Replying to Loa:

> 1) Can you give a pointer to "what Dimitri is doing with GMPLS-based 
> Ethernet"?
> 

The draft-papadimitriou-ccamp-gmpls-l2sc-lsp-01.txt is probably
the best starting point. But I really thought that there should
be a -02 version out by now.

/Loa

-- 

Loa Andersson

mobile [phone]



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4C63xJ11034 for <[e-mail]>; Tue, 11 May 2004 23:03:59 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4C63vhu014044 for <[e-mail]>; Wed, 12 May 2004 00:03:58 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Wed, 12 May 2004 02:03:57 -0400 (EDT)
Received: from Sun.COM (sr1-umpk-11.SFBay.Sun.COM [129.146.11.181]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]>; Wed, 12 May 2004 02:03:57 -0400 (EDT)
Date: Tue, 11 May 2004 23:03:52 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
In-reply-to: <[e-mail]>
To: Loa Andersson <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030711
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by boreas.isi.edu id i4C63xJ11034
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2004 06:04:47 -0000
Status: RO
Content-Length: 6870

Replying to Loa:

Sigh. My machine hung when I said "send" after I'd typed in a reply.
I haven't seen my reply posted, so I'll type a new one, and if it's
duplicative, sorry about that...

1) Can you give a pointer to "what Dimitri is doing with GMPLS-based 
Ethernet"?

2) Can you tell us what assumptions there have been made about MPLS
on this mailing list that worry you? No reason you have to "live with
them". If I have any misconceptions about MPLS I really want to know.

3) terminology: right now we mostly need to agree on what the proper
behavior of the device should be. What are the packet formats? What
does it do? I don't think terminology is important right now. However,
if we can improve the terminology that would be great for when we
produce more drafts. For instance, I came up with the word "RBridge",
but I don't particularly like it. I'd be happy to hear a better one.
As for "layer 2.5". I think layers are very confusing, even when one
just talks about integers. I agree that calling it "layer 2.5" or "layer
2+" is likely to be confusing. So we can, in parallel, try to think
of clearer ways of explaining things, but for now I think the most
important thing is figuring out the proper on-the-wire behavior of
this box.

4) > a. if we have multiple rbridges on a link, does that mean that
 >    thraffic from a non-DR needs to traverse the link twice?

as designed currently, the answer is yes, there can be a suboptimal
hop in both the forward and reverse direction. There are several
answers we could make to this:

. an extra hop or two doesn't matter
. this will be rare, because mostly there is no shared media anymore...
an endnode will be on a single port to an RBridge, so there is no
"other RBridge" on that link. If an endnode wants redundancy, it
will be connected to two separate RBridges on each of its two ports.
To counter this argument, one could point out that if the first switch
the endnode is connected to is a regular bridge, and there are
multiple RBridges connected to bridges connected to the endnode, then
it will look like a shared medium. And there might be extra hops (at
most 2 total). An answer to that is "make sure the first device is
an RBridge rather than a bridge".
. if this is a concern, and this is a plausible topology, we can perhaps
be clever and eliminate the extra hops. I'll send a separate note about
how I think this can be done, at least in one direction (so this
note won't be too long, and perhaps so I can think about it a bit more
before bothering the list with too underdone an idea).

 > b. will end nodes learn membership, or do they have to forward
 >    traffic for other end nodes on the same link via the rbridge?

If A and B are on the same local link, then when A does an ARP, it
will get an ARP reply from B, and will talk directly to B. The
RBridge will not get in the way of traffic between A and B.

Radia



> Radia,
> 
> I've tried to catch up on the rbridge mails, but I'm not sure
> I've captured everything, also reading your paper from the IEEE
> conference.
> 
> First - I think this is an idea that is very interesting. I guess
> we need to understand how it fits in with what Dimitri is doing with
> GMPLS-based Ethernet.
> 
> Second - I'm a bit concerned about some of the assumptions on
> MPLS on this mailing list, but that is probably something I've to
> live with.
> 
> Third - I'm not happy about the the L2.5 terminology, it is at
> best just not explaining anything and at worst is misleading.
> Model-wise the de?stinctions between the layers is clear,
> specification-wise we sometimes specifies L2 and L3 functionality in
> the same doc. Implementation-wise we implement boxes tht only
> have a subset of L2 or L3 functionality, but that don't make
> the a Layer 2.5, they are just boxes there some functions are
> are distributed. But guess that this is close to religion anyway ...
> 
> One other question I've is on the DR - in your paper you say that
> the Dr is the only rbridge that will learn membership of end nodes
> on a link and is allowed to forward traffic to end nodes on that
> link.
> 
> a. if we have multiple rbridges on a link, does that mean that
>    thraffic from a non-DR needs to traverse the link twice?
> b. will end nodes learn membership, or do they have to forward
>    traffic for other end nodes on the same link via the rbridge?
> 
> /loa
> 
> 
> 
> Radia Perlman wrote:
> 
>> Actually, a bridge forwarding from a link across the virtual subnet
>> would not decrement the TTL, and if an RBridge is supposed to
>> "look like a bridge", it wouldn't either.
>>
>> If there was a link where an IP endnode S
>> is trying to send the packet to a neighbor D on that subnet, if the 
>> Rbridge
>> is to be transparent when forwarding it, the TTL
>> would be the same when received by D as sent by S.
>>
>> It would be nice if the 2nd RBridge (in the example I gave in
>> the previous email),
>> that forwarded it across the virtual
>> subnet knew that it already had been forwarded across the subnet, but
>> in that weird temporary case, it might think the packet originated 
>> locally, and therefore forward it across the virtual link.
>>
>> I think we can fix this case without any cost, by flagging "this was
>> already forwarded across this virtual link by an RBridge" by using the
>> source address in the layer 2 header of the decapsulated packet
>> (since I think IP nodes won't care what's there).
>>
>> Radia
>>
>>
>>
>> Erik Nordmark wrote:
>>
>>>> I was worried that a temporary loop in the campus (with the example 
>>>> that I gave being that
>>>> a repeater suddenly connects to LANs) would lead to looping packets 
>>>> that were not
>>>> detected as looping due to any hop count. If the first RBridge 
>>>> encapsulates it with a hop count,
>>>> it won't loop while it is travelling across the campus, but after 
>>>> the egress RBridge decapsulates it,
>>>> there's no long an RBridge hop count, and the packet's IP TTL hasn't 
>>>> changed. If another RBridge
>>>> were, at that point, to think it should forward the packet across 
>>>> the campus, then we'll have
>>>> a loop uncorrected by any hop count.
>>>
>>>
>>>
>>>
>>> As long as the Rbridge, that decapsulates a packet and passes it on,
>>> decrements the IP ttl by one as part of this process you still know 
>>> the packet
>>> can't loop forever.
>>>
>>> This is analogous to an IP router which forwards a packet back out the
>>> same interface on which the packet arrived; in that case the TTL is
>>> decremented.
>>>
>>>   Erik
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://www.postel.org/mailman/listinfo/rbridge
>>
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>>
>>
> 




Received: from av1-2-sn4.m-sp.skanova.net (av1-2-sn4.m-sp.skanova.net [81.228.10.115]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4BJPlJ22083 for <[e-mail]>; Tue, 11 May 2004 12:25:47 -0700 (PDT)
Received: by av1-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 1B22C37ED2; Tue, 11 May 2004 21:25:41 +0200 (CEST)
Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av1-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 0AD9D37E42; Tue, 11 May 2004 21:25:41 +0200 (CEST)
Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id D86FF37E68; Tue, 11 May 2004 21:25:40 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 11 May 2004 21:25:37 +0200
From: Loa Andersson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Re: [rbridge] Developing a hybrid router/bridge.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Cc: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2004 19:26:36 -0000
Status: RO
Content-Length: 3870

Radia,

I've tried to catch up on the rbridge mails, but I'm not sure
I've captured everything, also reading your paper from the IEEE
conference.

First - I think this is an idea that is very interesting. I guess
we need to understand how it fits in with what Dimitri is doing with
GMPLS-based Ethernet.

Second - I'm a bit concerned about some of the assumptions on
MPLS on this mailing list, but that is probably something I've to
live with.

Third - I'm not happy about the the L2.5 terminology, it is at
best just not explaining anything and at worst is misleading.
Model-wise the de?stinctions between the layers is clear,
specification-wise we sometimes specifies L2 and L3 functionality in
the same doc. Implementation-wise we implement boxes tht only
have a subset of L2 or L3 functionality, but that don't make
the a Layer 2.5, they are just boxes there some functions are
are distributed. But guess that this is close to religion anyway ...

One other question I've is on the DR - in your paper you say that
the Dr is the only rbridge that will learn membership of end nodes
on a link and is allowed to forward traffic to end nodes on that
link.

a. if we have multiple rbridges on a link, does that mean that
    thraffic from a non-DR needs to traverse the link twice?
b. will end nodes learn membership, or do they have to forward
    traffic for other end nodes on the same link via the rbridge?

/loa



Radia Perlman wrote:

> Actually, a bridge forwarding from a link across the virtual subnet
> would not decrement the TTL, and if an RBridge is supposed to
> "look like a bridge", it wouldn't either.
> 
> If there was a link where an IP endnode S
> is trying to send the packet to a neighbor D on that subnet, if the Rbridge
> is to be transparent when forwarding it, the TTL
> would be the same when received by D as sent by S.
> 
> It would be nice if the 2nd RBridge (in the example I gave in
> the previous email),
> that forwarded it across the virtual
> subnet knew that it already had been forwarded across the subnet, but
> in that weird temporary case, it might think the packet originated 
> locally, and therefore forward it across the virtual link.
> 
> I think we can fix this case without any cost, by flagging "this was
> already forwarded across this virtual link by an RBridge" by using the
> source address in the layer 2 header of the decapsulated packet
> (since I think IP nodes won't care what's there).
> 
> Radia
> 
> 
> 
> Erik Nordmark wrote:
> 
>>> I was worried that a temporary loop in the campus (with the example 
>>> that I gave being that
>>> a repeater suddenly connects to LANs) would lead to looping packets 
>>> that were not
>>> detected as looping due to any hop count. If the first RBridge 
>>> encapsulates it with a hop count,
>>> it won't loop while it is travelling across the campus, but after the 
>>> egress RBridge decapsulates it,
>>> there's no long an RBridge hop count, and the packet's IP TTL hasn't 
>>> changed. If another RBridge
>>> were, at that point, to think it should forward the packet across the 
>>> campus, then we'll have
>>> a loop uncorrected by any hop count.
>>
>>
>>
>> As long as the Rbridge, that decapsulates a packet and passes it on,
>> decrements the IP ttl by one as part of this process you still know 
>> the packet
>> can't loop forever.
>>
>> This is analogous to an IP router which forwards a packet back out the
>> same interface on which the packet arrived; in that case the TTL is
>> decremented.
>>
>>   Erik
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
> 
> 

-- 

Loa Andersson

mobile [phone]



Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4BI3mJ29895 for <[e-mail]>; Tue, 11 May 2004 11:03:48 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i4BI3lhs029909 for <[e-mail]>; Tue, 11 May 2004 12:03:47 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Tue, 11 May 2004 14:03:47 -0400 (EDT)
Received: from Sun.COM (sr1-umpk-11.SFBay.Sun.COM [129.146.11.181]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 11 May 2004 14:03:47 -0400 (EDT)
Date: Tue, 11 May 2004 11:03:46 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2.1) Gecko/20030711
References: <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [e-mail], "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2004 18:04:37 -0000
Status: RO
Content-Length: 2128

Actually, a bridge forwarding from a link across the virtual subnet
would not decrement the TTL, and if an RBridge is supposed to
"look like a bridge", it wouldn't either.

If there was a link where an IP endnode S
is trying to send the packet to a neighbor D on that subnet, if the Rbridge
is to be transparent when forwarding it, the TTL
would be the same when received by D as sent by S.

It would be nice if the 2nd RBridge (in the example I gave in
the previous email),
that forwarded it across the virtual
subnet knew that it already had been forwarded across the subnet, but
in that weird temporary case, it might think the packet originated 
locally, and therefore forward it across the virtual link.

I think we can fix this case without any cost, by flagging "this was
already forwarded across this virtual link by an RBridge" by using the
source address in the layer 2 header of the decapsulated packet
(since I think IP nodes won't care what's there).

Radia



Erik Nordmark wrote:
>>I was worried that a temporary loop in the campus (with the example that 
>>I gave being that
>>a repeater suddenly connects to LANs) would lead to looping packets that 
>>were not
>>detected as looping due to any hop count. If the first RBridge 
>>encapsulates it with a hop count,
>>it won't loop while it is travelling across the campus, but after the 
>>egress RBridge decapsulates it,
>>there's no long an RBridge hop count, and the packet's IP TTL hasn't 
>>changed. If another RBridge
>>were, at that point, to think it should forward the packet across the 
>>campus, then we'll have
>>a loop uncorrected by any hop count.
> 
> 
> As long as the Rbridge, that decapsulates a packet and passes it on,
> decrements the IP ttl by one as part of this process you still know the packet
> can't loop forever.
> 
> This is analogous to an IP router which forwards a packet back out the
> same interface on which the packet arrived; in that case the TTL is
> decremented.
> 
>   Erik
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge




Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4BHODJ18465 for <[e-mail]>; Tue, 11 May 2004 10:24:13 -0700 (PDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4BHO6ms016248 for <[e-mail]>; Tue, 11 May 2004 10:24:07 -0700 (PDT)
Received: from blixten (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL, v2.2) with SMTP id i4BHO5Q22057 for <[e-mail]>; Tue, 11 May 2004 19:24:05 +0200 (MEST)
Date: Tue, 11 May 2004 10:24:10 -0700 (PDT)
From: Erik Nordmark <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
To: "Developing a hybrid router/bridge." <[e-mail]>
In-Reply-To: "Your message with ID" <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Erik Nordmark <[e-mail]>, "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2004 17:24:35 -0000
Status: RO
Content-Length: 963

> I was worried that a temporary loop in the campus (with the example that 
> I gave being that
> a repeater suddenly connects to LANs) would lead to looping packets that 
> were not
> detected as looping due to any hop count. If the first RBridge 
> encapsulates it with a hop count,
> it won't loop while it is travelling across the campus, but after the 
> egress RBridge decapsulates it,
> there's no long an RBridge hop count, and the packet's IP TTL hasn't 
> changed. If another RBridge
> were, at that point, to think it should forward the packet across the 
> campus, then we'll have
> a loop uncorrected by any hop count.

As long as the Rbridge, that decapsulates a packet and passes it on,
decrements the IP ttl by one as part of this process you still know the packet
can't loop forever.

This is analogous to an IP router which forwards a packet back out the
same interface on which the packet arrived; in that case the TTL is
decremented.

  Erik



Received: from miews.localhost ([129.94.138.139]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4A5ULJ23745 for <[e-mail]>; Sun, 9 May 2004 22:30:23 -0700 (PDT)
Received: from nicta.com.au (localhost [127.0.0.1]) by miews.localhost (Postfix) with ESMTP id AE1B7805D3 for <[e-mail]>; Mon, 10 May 2004 15:30:14 +1000 (EST)
Message-ID: <[e-mail]>
Date: Mon, 10 May 2004 15:30:14 +1000
From: Aidan Williams <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding based on layer 3 vs layer 2 destination
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2004 05:30:32 -0000
Status: RO
Content-Length: 1354

Radia Perlman wrote:
> It can work, but first I'd like to know if it's important to make
> this case work. Some people I passed RBridge by awhile ago seemed
> enthusiastic about making a campus with incompatible layer 2
> addresses work. I've forgotten who they are, though, or else I could
> ask them directly which particular layer 2 technologies they had in
> mind.
> 

Firewire springs to mind as a non-EUI48 addressed media over which 
people run IP packets.  Incompatible layer 2 addressing is only part of 
the story though, different ethernet flavours can have incompatible MTU 
sizes (e.g. 9k for gigabit).

I'm uneasy about encapsulating 1500-byte ethernet packets because the 
resulting >1500 byte packet might not be passed transparently through 
existing switches.  I have been bitten by this a few years ago trying to 
deploy 802.1q (which adds 4 bytes to the packet header).  Maybe someone 
can reassure me that this isn't a problem anymore and would not be a 
showstopper for an L2 rbridge solution.

"Bridging at the IP layer" has some advantages in that it copes with 
differing link layers, supports fragmentation and you get the usual 
router behaviours supporting MTU discovery and shortest paths.

I'm not particularly keen on combining the L2 and L3 approach.  I think 
it might result in a whole pile of added confusion.

- aidan


Received: from WAPRDMSIMC04.gsm1900.org (wabod01s01.t-mobile.com [65.161.188.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47NfhJ28904 for <[e-mail]>; Fri, 7 May 2004 16:41:43 -0700 (PDT)
Received: by waprdmsimc04.gsm1900.org with Internet Mail Service (5.5.2653.19) id <KPT10D6W>; Fri, 7 May 2004 16:41:25 -0700
Message-ID: <[e-mail]>
From: "Roeder, Konrad" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Fri, 7 May 2004 16:41:25 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] RE: rbridge Digest, Vol 1, Issue 4
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 23:42:26 -0000
Status: RO
Content-Length: 2335

Joe,
my comments inside yours... // //



Roeder, Konrad wrote:

> I agree with Joe that MPLS switches are L2 devices with a special
> L2.5
> shim layer. As part of their behavior, MPLS switches do/can decrement
> TTL. So there is precedence here in L2 (L2.5?) devices meddling with
> TTL. I believe that RBridges could decrement TTL to prevent loops,
> although doing so is not "a clean L2 implementation" because
> decrementing TTL indicates either a second of time went away or that a
> router was traversed.

The difference is that MPLS isn't trying to be an L2. Rbridge is.

//I agree//

If we relax that constraint, and allow rbridges to do what MPLS is, 
there's certainly precedent. And a very large and deep can of worms 
awaiting, IMO ;-)

//Ditto//

> Another point to bring up: Do we want the rbridge to behave
> differently depending on what protocol is carried in L3? If it's IP it
> uses TTL, if it's not it's decrementing a hop counter in its
> encapsulation. Do we really want to add this complexity?

I can't answer whether it's wanted, but it would certainly need to be
sensitive to the L3 protocol if the TTL were decremented.

Perhaps that's another good reason not to decrement the TTL? :-)
I.e., it makes rbridge a true L2 system, which is compatible
with - and independent of - the protocol carried therin (at the edge).

//Ditto. //

> Going back briefly to the subject of the traceroute kludge... if TTL
> gets decremented from 1 to 0, does an Rbridge send an ICMP Timeout
> message? Doing so would make an RBridge appear on a traceroute. Not
> doing so, would make an RBridge appear as a *. I suppose this is an
> implementation detail, but it might be worthwhile specifying the
> interaction. (traceroute is a nice debugging tool)

IMO, anything that decrements the TTL is a router; that means RFC1812 
applies.
RFC2003 points this out with respect to tunnels - wherever TTL is 
decremented, there is the possibility of a zero and thus the need for 
ICMP TTL exceeded messages.

//Since RBridge is a Layer 2 device, it **SHOULD NOT** be meddling with TTL.  I think it's a bad idea due to the fact that there are loads of interactions that I don't think we are ready to deal with.  This means that we should only rely on encapsulation.  Furthermore, this renders the traceroute question a moot point.//

Joe


Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47MiqJ19173; Fri, 7 May 2004 15:44:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 07 May 2004 15:44:48 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding based on layer 3 vs layer 2 destination
References: <[e-mail]>	<[e-mail]> <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig068CDF28B448957C8D7CFD7F"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 22:45:39 -0000
Status: RO
Content-Length: 3857

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig068CDF28B448957C8D7CFD7F
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Radia Perlman wrote:
> The question is...should we support the following scenario:
> 
> IP nodes A and B both think they are in the same IP subnet (based on IP 
> prefix). However,
> they sit on incompatible layer 2 technologies.

IMO, no ;-)

At least not at L2, by definition.

We can put them on different L3 subnets and put up another virtual 
network that makes them all look like they're on a single L3 subnet 
eventually, but bridging different L2's is almost the definition of an 
L3 device to me.

Granted, it sounds like I'm being a religious zealout about some of 
these questions, but my experience is that such religions are at the 
core of clean architectures.

joe

> If A does an ARP, should it get an ARP reply? (it better, since in this 
> scenario A will not have
> any other way of communicating the B). What would the ARP reply contain?
> 
> Presumably the layer 2 address of some RBridge, since it will be 
> necessary for RBridges
> to make this work.
> 
> And how will an RBridge forward the packet? If they are forwarding based 
> on the layer 3
> header, it doesn't matter what the layer 2 header looks like. If they 
> are forwarding based on
> layer 2, then RBridges need to have forwarding tables that look like:
> (layer 2 address family type, address).
> 
> It can work, but first I'd like to know if it's important to make this 
> case work. Some people
> I passed RBridge by awhile ago seemed enthusiastic about making a campus 
> with incompatible
> layer 2 addresses work. I've forgotten who they are, though, or else I 
> could ask them directly which particular layer 2 technologies they had 
> in mind.
> 
> Radia
> 
> 
> Joe Touch wrote:
> 
>>
>>
>> Radia Perlman wrote:
>>
>>> Currently the rules for forwarding a packet in the internet draft are:
>>>
>>> a) if it's non-IP, forward based on the inner layer 2 header 
>>> destination address
>>> b) if it's off-campus IP, forward based on the inner layer 2 header 
>>> destination address
>>> c) if it's on-campus IP, forward based on the inner layer 3 header 
>>> destination address
>>>
>>> The reason for making c) be a different case was so that two IP nodes 
>>> on the same campus,
>>> but connected via incompatible layer 2 protocols, could talk.
>>
>>
>>
>> that's providing L3 routing; it seems like that ought to be caught by 
>> a router, not an rbridge.
>>
>>> Question: What kind of incompatible layer 2 protocols might there be? 
>>> Do we want to
>>> support this case? Clearly it would be simpler to always forward 
>>> based on the layer 2 destination
>>> address as put in by the source.
>>>
>>> Radia
>>>
>>> _______________________________________________
>>> rbridge mailing list
>>> [e-mail]
>>> http://www.postel.org/mailman/listinfo/rbridge
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>>  
>>
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enig068CDF28B448957C8D7CFD7F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAnBFkE5f5cImnZrsRAsRoAKDaUs5n/1W3KJ6HBqe/ykd6yay/7ACfbSR+
Gf61xFmekzWlHQBCyS6nTi8=
=RUYm
-----END PGP SIGNATURE-----

--------------enig068CDF28B448957C8D7CFD7F--


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47MgnJ18838 for <[e-mail]>; Fri, 7 May 2004 15:42:49 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i47MghQG003173 for <[e-mail]>; Fri, 7 May 2004 18:42:43 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA05332 for <[e-mail]>; Fri, 7 May 2004 18:42:43 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <J6HSYWD6>; Fri, 7 May 2004 18:42:42 -0400
Message-ID: <[e-mail]>
From: "Naidu, Venkata" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Fri, 7 May 2004 18:42:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] RBridge Spanning Tree Comments
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 22:44:29 -0000
Status: RO
Content-Length: 2129

-> 2.2  Spanning Tree
->
->   There will be cases when RBridges will need to send packets to all
->   links.  These cases include:

  The above sentence needs correction.
   
  If spanning tree is used to flood packets, every router will get 
  the packet. Not every link. If we want every link to see a packet
  then the only way is to flood, as in link-state IGPs.

->   o  layer 2 multicast or broadcast packets
->
->   o  distributed RBridge layer 3 address location query
->
->   In this case the packets must be sent through a spanning tree.
->   However, there is no need to implement a separate spanning tree
->   protocol in addition to the link state protocol. Instead, the link
->   state information can be used to create a single spanning tree
->   throughout the campus. This is done by choosing the RBridge with
->   lowest ID, and calculating the Dijkstra tree with that RBridge as
->   Root.

  There is a problem with this. 


  1. Dijkstra tree? Dijkstra single source shortest path tree?!
     Yes. SPT is an spanning tree (not necessarily an MST). 
     Why SPF ? Why not Spanning Tree algorithms (like prim etc).

  2. Here, we choose not to build a dynamic distributed spanning 
     tree. Rather an offline spanning tree using distributed
     link-state information. 

     Distributed algorithms perspective, having a *unique* spanning 
     tree reduces lot of communication complexity. Building a 
     off-line spanning tree doesn't solve f-failure termination. 
     When a process or link fails, then every node has to 
     re-compute the spanning tree. This will lead to loops when 
     some routers get link-state information ahead of other routers.

  3. The above paragraph says "This is done by choosing the RBridge 
     with lowest ID....". How do we choose the lowest ID. When the 
     routers come up, routers run some leader-election algorithm or
     use link-state information ? If routers use link-state
     information, when should routers start build the spanning tree ?
  
  I am wondering, why can't IGPs use the spanning tree to reduce
  communication complexity ?

Venkata. 


Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47Mh8J18892 for <[e-mail]>; Fri, 7 May 2004 15:43:09 -0700 (PDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i47Mh3QG003183 for <[e-mail]>; Fri, 7 May 2004 18:43:03 -0400 (EDT)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA05362 for <[e-mail]>; Fri, 7 May 2004 18:43:03 -0400 (EDT)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <J6HSYW11>; Fri, 7 May 2004 18:43:02 -0400
Message-ID: <[e-mail]>
From: "Naidu, Venkata" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Fri, 7 May 2004 18:42:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] RBridge Link-State Protocol comments
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 22:44:25 -0000
Status: RO
Content-Length: 1833

-> 2.1  Link State Protocol
->
-> Running a link state protocol among RBridges is straightforward. It
-> is the same as running a level 1 routing protocol in an area. IS-IS
-> is a more appropriate choice than OSPF in this case because it is
-> easy in IS-IS to define new TLVs for carrying new information.
-> However, the instance of IS-IS that RBridges will implement will be
-> separate from any routing protocol that IP routers will implement,
-> just as the spanning tree messages are not implemented by IP routers.
->
-> To keep the instances separate, RBridge routing messages should be
-> sent to a different layer 2 multicast address than IS-IS routing
-> messages.  Alternatively, they can be differentiated by having a
-> different "area address", where, in order to keep RBridges
-> configuration-free, the RBridge area address would be a constant for
-> all RBridges, and would not be one that would ever appear as a real
-> IS-IS area address.

  Here are few comments w.r.t reuse of IGPs for RBridges:

  1. If we plan to augment ISIS by adding new TLVs, why there is a
     need to assign a different layer 2 multicast address. We could
     as well use draft-ietf-isis-wg-multi-topology extensions
     to achieve the same goal.

  2. It seems we are trying to reuse the existing IGPs, because, they 
     are stable, proven and 99% of the features what Rbridges wants 
     comes for free from link-state IGPs. By putting some restrictions
     on area addresses and assigning new multicast addresses would 
     make it look like a new protocol. In such a case, it is better 
     to write a new protocol, (let it look almost same as ISIS)
     But, it is still distinguishable because it solve a different
     problem/purpose.

  Can't we make make RBridge-ISIS work with out above new requirements?

Venkata.


Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47MK7J13699 for <[e-mail]>; Fri, 7 May 2004 15:20:07 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i47MK1ms027552 for <[e-mail]>; Fri, 7 May 2004 15:20:02 -0700 (PDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Fri, 07 May 2004 18:20:01 -0400 (EDT)
Received: from sun.com (vpn-129-147-155-70.Central.Sun.COM [129.147.155.70]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 07 May 2004 18:20:01 -0400 (EDT)
Date: Fri, 07 May 2004 15:20:02 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Forwarding based on layer 3 vs layer 2 destination
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 22:20:25 -0000
Status: RO
Content-Length: 2417

The question is...should we support the following scenario:

IP nodes A and B both think they are in the same IP subnet (based on IP 
prefix). However,
they sit on incompatible layer 2 technologies.

If A does an ARP, should it get an ARP reply? (it better, since in this 
scenario A will not have
any other way of communicating the B). What would the ARP reply contain?

Presumably the layer 2 address of some RBridge, since it will be 
necessary for RBridges
to make this work.

And how will an RBridge forward the packet? If they are forwarding based 
on the layer 3
header, it doesn't matter what the layer 2 header looks like. If they 
are forwarding based on
layer 2, then RBridges need to have forwarding tables that look like:
(layer 2 address family type, address).

It can work, but first I'd like to know if it's important to make this 
case work. Some people
I passed RBridge by awhile ago seemed enthusiastic about making a campus 
with incompatible
layer 2 addresses work. I've forgotten who they are, though, or else I 
could ask them directly which particular layer 2 technologies they had 
in mind.

Radia


Joe Touch wrote:

>
>
> Radia Perlman wrote:
>
>> Currently the rules for forwarding a packet in the internet draft are:
>>
>> a) if it's non-IP, forward based on the inner layer 2 header 
>> destination address
>> b) if it's off-campus IP, forward based on the inner layer 2 header 
>> destination address
>> c) if it's on-campus IP, forward based on the inner layer 3 header 
>> destination address
>>
>> The reason for making c) be a different case was so that two IP nodes 
>> on the same campus,
>> but connected via incompatible layer 2 protocols, could talk.
>
>
> that's providing L3 routing; it seems like that ought to be caught by 
> a router, not an rbridge.
>
>> Question: What kind of incompatible layer 2 protocols might there be? 
>> Do we want to
>> support this case? Clearly it would be simpler to always forward 
>> based on the layer 2 destination
>> address as put in by the source.
>>
>> Radia
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>
>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>




Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47M11J10116; Fri, 7 May 2004 15:01:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 07 May 2004 15:01:00 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Forwarding based on layer 3 vs layer 2 destination
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6FEE4DC60BE25E13E4525881"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 22:01:51 -0000
Status: RO
Content-Length: 1716

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6FEE4DC60BE25E13E4525881
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Radia Perlman wrote:
> Currently the rules for forwarding a packet in the internet draft are:
> 
> a) if it's non-IP, forward based on the inner layer 2 header destination 
> address
> b) if it's off-campus IP, forward based on the inner layer 2 header 
> destination address
> c) if it's on-campus IP, forward based on the inner layer 3 header 
> destination address
> 
> The reason for making c) be a different case was so that two IP nodes on 
> the same campus,
> but connected via incompatible layer 2 protocols, could talk.

that's providing L3 routing; it seems like that ought to be caught by a 
router, not an rbridge.

> Question: What kind of incompatible layer 2 protocols might there be? Do 
> we want to
> support this case? Clearly it would be simpler to always forward based 
> on the layer 2 destination
> address as put in by the source.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enig6FEE4DC60BE25E13E4525881
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAnAccE5f5cImnZrsRAlNLAJsEBHbjbnZBLt4H3a/bOZWXgIBq7gCdElMI
OUMgG0QX3Svjn+lnmfYn3mA=
=t1KG
-----END PGP SIGNATURE-----

--------------enig6FEE4DC60BE25E13E4525881--


Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47LpkJ07788; Fri, 7 May 2004 14:51:46 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 07 May 2004 14:51:45 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
References: <[e-mail]>	<[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD8C39C752BF5C401BEDC6F20"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 21:52:28 -0000
Status: RO
Content-Length: 2959

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD8C39C752BF5C401BEDC6F20
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

In that case, the loop should be avoided by the rest of the L2 system, 
e.g., using spanning tree ;-)

I.e., Rbridge is responsible (IMO) for avoiding loops in an enclave 
surrounded by rbridges (whether the interior is all rbridges or also 
includes conventional bridges).

[this may warrant revisiting the 'campus' definition].

I.e., there are only two places for loops:

	1) inside the enclave
		avoided by encapsulation TTL

	2) between the encaves (revisiting a single
	enclave multiple times)
		avoided by the protocol outside the
		enclave, i.e., the spanning tree of the L2
		environment in which th enclave resides

Joe


Radia Perlman wrote:

> You're right that an IP router can't detect a global Internet loop. But 
> the IP header's TTL
> will, inexorably, get decremented to 0 and eventually the packet will go 
> away.
> 
> I was worried that a temporary loop in the campus (with the example that 
> I gave being that
> a repeater suddenly connects to LANs) would lead to looping packets that 
> were not
> detected as looping due to any hop count. If the first RBridge 
> encapsulates it with a hop count,
> it won't loop while it is travelling across the campus, but after the 
> egress RBridge decapsulates it,
> there's no long an RBridge hop count, and the packet's IP TTL hasn't 
> changed. If another RBridge
> were, at that point, to think it should forward the packet across the 
> campus, then we'll have
> a loop uncorrected by any hop count.
> 
> This is an unlikely scenario I admit, but I think that by using the 
> layer 2 source address "X", we can
> make sure that this never occurs with IP packets being forwarded across 
> an RBridged campus.
> 
> Radia
> 
> 
> Joe Touch wrote:
> 
>> I guess a larger question to this issue is:
>>
>>     why is an Rbridge worried about forwarding a packet twice?
>>
>> The loop isn't create by the campus; it's external. That's like a 
>> single Internet router detecting a loop in the Internet as a whole. I 
>> don't think it is reasonable to assume a router can do that. That's 
>> for Internet routing to avoid, IMO...
>>
>> Joe
> 
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enigD8C39C752BF5C401BEDC6F20
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAnATxE5f5cImnZrsRAjUaAJ0f0NGX0h/DQZmIReNNesioHbNGNACfUOc+
Bs9dCqZtB+U4QG5IzZt+TSY=
=jv6B
-----END PGP SIGNATURE-----

--------------enigD8C39C752BF5C401BEDC6F20--


Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47LZ1J03842 for <[e-mail]>; Fri, 7 May 2004 14:35:01 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i47LZ04U008335 for <[e-mail]>; Fri, 7 May 2004 15:35:01 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Fri, 07 May 2004 17:35:00 -0400 (EDT)
Received: from sun.com (vpn-129-147-155-70.Central.Sun.COM [129.147.155.70]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 07 May 2004 17:35:00 -0400 (EDT)
Date: Fri, 07 May 2004 14:35:01 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 21:36:10 -0000
Status: RO
Content-Length: 1384

You're right that an IP router can't detect a global Internet loop. But 
the IP header's TTL
will, inexorably, get decremented to 0 and eventually the packet will go 
away.

I was worried that a temporary loop in the campus (with the example that 
I gave being that
a repeater suddenly connects to LANs) would lead to looping packets that 
were not
detected as looping due to any hop count. If the first RBridge 
encapsulates it with a hop count,
it won't loop while it is travelling across the campus, but after the 
egress RBridge decapsulates it,
there's no long an RBridge hop count, and the packet's IP TTL hasn't 
changed. If another RBridge
were, at that point, to think it should forward the packet across the 
campus, then we'll have
a loop uncorrected by any hop count.

This is an unlikely scenario I admit, but I think that by using the 
layer 2 source address "X", we can
make sure that this never occurs with IP packets being forwarded across 
an RBridged campus.

Radia


Joe Touch wrote:

> I guess a larger question to this issue is:
>
>     why is an Rbridge worried about forwarding a packet twice?
>
> The loop isn't create by the campus; it's external. That's like a 
> single Internet router detecting a loop in the Internet as a whole. I 
> don't think it is reasonable to assume a router can do that. That's 
> for Internet routing to avoid, IMO...
>
> Joe





Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47LIvJ00481 for <[e-mail]>; Fri, 7 May 2004 14:18:57 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i47LIu4U002047 for <[e-mail]>; Fri, 7 May 2004 15:18:56 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Fri, 07 May 2004 17:18:56 -0400 (EDT)
Received: from sun.com (vpn-129-147-155-70.Central.Sun.COM [129.147.155.70]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 07 May 2004 17:18:56 -0400 (EDT)
Date: Fri, 07 May 2004 14:18:57 -0700
From: Radia Perlman <[e-mail]>
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
References: <[e-mail]> <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Forwarding based on layer 3 vs layer 2 destination
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 21:19:25 -0000
Status: RO
Content-Length: 711

Currently the rules for forwarding a packet in the internet draft are:

a) if it's non-IP, forward based on the inner layer 2 header destination 
address
b) if it's off-campus IP, forward based on the inner layer 2 header 
destination address
c) if it's on-campus IP, forward based on the inner layer 3 header 
destination address

The reason for making c) be a different case was so that two IP nodes on 
the same campus,
but connected via incompatible layer 2 protocols, could talk.

Question: What kind of incompatible layer 2 protocols might there be? Do 
we want to
support this case? Clearly it would be simpler to always forward based 
on the layer 2 destination
address as put in by the source.

Radia



Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47LFmJ29827; Fri, 7 May 2004 14:15:48 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 07 May 2004 14:15:48 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB43C90FBF607BC0F2A4F7286"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 21:16:30 -0000
Status: RO
Content-Length: 9204

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB43C90FBF607BC0F2A4F7286
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I guess a larger question to this issue is:

	why is an Rbridge worried about forwarding a packet twice?

The loop isn't create by the campus; it's external. That's like a single 
Internet router detecting a loop in the Internet as a whole. I don't 
think it is reasonable to assume a router can do that. That's for 
Internet routing to avoid, IMO...

Joe

Radia Perlman wrote:

> To answer Konrad's question about traceroute, I think it's pretty clear 
> that *if* Rbridges
> decrement TTL, then they'd need to send ICMP messages when TTL expires, and
> therefore appear as a hop in traceroute.
> 
> However, I agree with Joe that if we are making IP think this is one 
> subnet, then we can't
> decrement the IP TTL.
> 
> There was a case that I was concerned about, but I was having trouble 
> finding a remotely
> plausible example to explain it with. I think I have one now, and 
> luckily also I think I have
> a solution that will allay my paranoid fantasies.
> 
> I was kind of worried about a packet EVER not being protected by a hop 
> count. Is it possible
> for a packet to be encapsulated across the RBridged campus, 
> decapsulated, and then reintroduced.
> 
> The answer is yes, in a weird temporary case.
> 
> The temporary case is where there are two DRs on a LAN. This would be a 
> temporary situation (but temporary bridge loops can be quite devastating).
> 
> Let's say it happened because R1's LAN and R2's LAN suddenly got 
> connected by a bridge coming up. Let's say that endnode D is on R2's LAN 
> and S is on R1's LAN. Let's say that S sends a packet for D. R1 might 
> encapsulate it, send it across the campus, where it might be received by 
> R2 (since there is still a route across the campus to R2...routing 
> hasn't yet coped with the merging of the two LANs, say), and 
> decapsulated. Then R1 would pick it up again, ...
> 
> If multiple LANs got merged simultaneously this way then theoretically 
> not only could you have (temporary) looping, but proliferation.
> 
> So that was why I was kind of hoping that RBridges would decrement the 
> IP TTL.
> 
> But I have a proposal for solving this problem without introducing a lot 
> of complexity (since I suspect people will not have sufficient sympathy 
> with my paranoid fantasies to be willing to
> introduce a lot of complexity to solve them).
> 
> What I want to do is have it be possible for R2 to recognize when a 
> packet is being sent by an endnode and when it was decapsulated by 
> another RBridge. This is not possible for non-IP packets, since they 
> have to be "transparent"...there are no bits to safely play with.
> 
> However, with IP, we can play with the layer 2 header. IP nodes don't 
> (as far as I know...anyone know any different), care what the source 
> address in the layer 2 header looks like when an IP packet is received.
> 
> How about having a specific, constant MAC address, say "X",  that means 
> "transmitted by an RBridge".
> When an RBridge decapsulates an IP packet onto the destination LAN, it 
> can set the source
> address in the layer 2 header to be X. The rule will be that an RBridge 
> is not allowed to forward a packet that has layer 2 source address=X.
> 
> This won't solve the potential problem with non-IP packets, but we're 
> really trying to just make sure this works for IP packets.
> 
> Comments?
> 
> Radia
> 
> 
> Roeder, Konrad wrote:
> 
>> I agree with Joe that MPLS switches are L2 devices with a special L2.5 
>> shim layer.  As part of their behavior, MPLS switches do/can decrement 
>> TTL.  So there is precedence here in L2 (L2.5?) devices meddling with 
>> TTL.  I believe that RBridges could decrement TTL to prevent loops, 
>> although doing so is not "a clean L2 implementation" because 
>> decrementing TTL indicates either a second of time went away or that a 
>> router was traversed.
>>
>> Another point to bring up: Do we want the rbridge to behave 
>> differently depending on what protocol is carried in L3?  If it's IP 
>> it uses TTL, if it's not it's decrementing a hop counter in its 
>> encapsulation.  Do we really want to add this complexity?
>> Going back briefly to the subject of the traceroute kludge... if TTL 
>> gets decremented from 1 to 0, does an Rbridge send an ICMP Timeout 
>> message?  Doing so would make an RBridge appear on a traceroute.  Not 
>> doing so, would make an RBridge appear as a *.  I suppose this is an 
>> implementation detail, but it might be worthwhile specifying the 
>> interaction.  (traceroute is a nice debugging tool)
>>
>> Konrad
>>
>> Konrad Roeder
>> Broadband Wireless Network Engineer
>>
>> T-Mobile USA, Inc.
>> Office:  425-748-2381
>> PCS:   425-444-2076
>> FAX:    [phone]
>> 12920 SE 38th Street
>> Bellevue, WA  98006
>>
>> e-mail: [e-mail]
>>
>>
>> Message: 3
>> Date: Thu, 06 May 2004 09:39:56 -0700
>> From: Joe Touch <[e-mail]>
>> Subject: Re: [rbridge] RE: rbridge Digest, Vol 1, Issue 2
>> To: "Developing a hybrid router/bridge." <[e-mail]>
>> Message-ID: <[e-mail]>
>> Content-Type: text/plain; charset="us-ascii"
>>
>>
>>
>> Radia Perlman wrote:
>>  
>>
>>> I'm not sure it's useful to try to answer a philosophical question 
>>> like whether RBridge is
>>> layer 2 or layer 3. I don't think there's any agreed-upon definition, 
>>> or whether it's too useful
>>> to categorize. One might say it is layer 3 because it participates in 
>>> some layer 3 protocols
>>> (like ARP and ND).
>>>   
>>
>>
>> It may be useful to distinguish between what is provided to the 
>> outside of an rbridge (i.e., what it emulates) and how it operates 
>> internally.
>>
>> An rbridge (at least to me) emulates an L2 bridge - in which case the 
>> TTL would not be decremented at all.
>>
>> When such a device emulates an L3 router, it is closer (IMO) to 
>> Virtual Routers (see the draft; this was developed in the X-Bone project
>> for recursive Internets) - which are VERY closely related, but each 
>> [L2 and L3] present unique issues. This draft focuses on the 
>> L2-providing device.
>>
>> Internally, either may be implemented with L2 encapsulation, L3 
>> encapsulation, or carrier pidgeon ;-)
>>
>> ARP and ND are interesting cases because they are L3 protocols that 
>> use L2 information, i.e., they are 'glue' layers of a sort. They must 
>> be interfaced to the edge of a campus of rbridges carefully, but I 
>> don't see any showstoppers.
>>
>> Other more complex cases would be MPLS and other so-called layer 2.5 
>> protocols. I confess they never made much sense in that regard to me; 
>> IMO, MPLS is just a different L2 protocol that is layered over other 
>> L2 protocols.
>>
>>  
>>
>>> Someone privately told me there are certain IP protocols that will 
>>> not work if the TTL
>>> gets decremented, like "local broadcast".
>>>   
>>
>>
>> RFC1812 talks specifically about how to process all-1's broadcast 
>> (local broadcast), and how it MUST NOT be forwarded if the TTL is 
>> decremented. There are other cases, e.g., subnet broadcast, which 
>> SHOULD NOT me forwarded (although described as permitted in 1812, this 
>> is depricated in RFC2644).
>>
>> In many ways, the definition of an IP subnet is "that in which the IP 
>> TTL is not decremented".
>>
>> I agree with Radia that this is more important for things like:
>>     - broadcast
>>     - multicast
>>
>> which would affect:
>>     - ARP/RARP
>>     - DHCP
>>     - BOOTP
>>     - IGMP
>>     - ICMP
>>     etc...
>>
>> (see draft-ietf-pilc-link-design for details - notably the broadcast 
>> and multicast sections, which I was responsible for).
>>
>> Joe
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 250 bytes
>> Desc: OpenPGP digital signature
>> Url : 
>> http://www.postel.org/pipermail/rbridge/attachments/20040506/38070885/signature-0001.bin 
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>>
>>
>> End of rbridge Digest, Vol 1, Issue 3
>> *************************************
>> _______________________________________________
>> rbridge mailing list
>> [e-mail]
>> http://www.postel.org/mailman/listinfo/rbridge
>>  
>>
> 
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enigB43C90FBF607BC0F2A4F7286
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAm/yEE5f5cImnZrsRAqiCAJ9NcFEbkyXjjL1J/+uYoNj1CLGW7ACg1bK7
YRKJxRrLexegbE81o8Ui+DU=
=k+wg
-----END PGP SIGNATURE-----

--------------enigB43C90FBF607BC0F2A4F7286--


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i47L9pJ28813 for <[e-mail]>; Fri, 7 May 2004 14:09:51 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i47L8VsT002360 for <[e-mail]>; Fri, 7 May 2004 15:08:31 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Fri, 07 May 2004 17:09:50 -0400 (EDT)
Received: from sun.com (vpn-129-147-155-70.Central.Sun.COM [129.147.155.70]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 07 May 2004 17:09:50 -0400 (EDT)
Date: Fri, 07 May 2004 14:09:51 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
References: <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2004 21:10:28 -0000
Status: RO
Content-Length: 7539

To answer Konrad's question about traceroute, I think it's pretty clear 
that *if* Rbridges
decrement TTL, then they'd need to send ICMP messages when TTL expires, and
therefore appear as a hop in traceroute.

However, I agree with Joe that if we are making IP think this is one 
subnet, then we can't
decrement the IP TTL.

There was a case that I was concerned about, but I was having trouble 
finding a remotely
plausible example to explain it with. I think I have one now, and 
luckily also I think I have
a solution that will allay my paranoid fantasies.

I was kind of worried about a packet EVER not being protected by a hop 
count. Is it possible
for a packet to be encapsulated across the RBridged campus, 
decapsulated, and then reintroduced.

The answer is yes, in a weird temporary case.

The temporary case is where there are two DRs on a LAN. This would be a 
temporary situation (but temporary bridge loops can be quite devastating).

Let's say it happened because R1's LAN and R2's LAN suddenly got 
connected by a bridge coming up. Let's say that endnode D is on R2's LAN 
and S is on R1's LAN. Let's say that S sends a packet for D. R1 might 
encapsulate it, send it across the campus, where it might be received by 
R2 (since there is still a route across the campus to R2...routing 
hasn't yet coped with the merging of the two LANs, say), and 
decapsulated. Then R1 would pick it up again, ...

If multiple LANs got merged simultaneously this way then theoretically 
not only could you have (temporary) looping, but proliferation.

So that was why I was kind of hoping that RBridges would decrement the 
IP TTL.

But I have a proposal for solving this problem without introducing a lot 
of complexity (since I suspect people will not have sufficient sympathy 
with my paranoid fantasies to be willing to
introduce a lot of complexity to solve them).

What I want to do is have it be possible for R2 to recognize when a 
packet is being sent by an endnode and when it was decapsulated by 
another RBridge. This is not possible for non-IP packets, since they 
have to be "transparent"...there are no bits to safely play with.

However, with IP, we can play with the layer 2 header. IP nodes don't 
(as far as I know...anyone know any different), care what the source 
address in the layer 2 header looks like when an IP packet is received.

How about having a specific, constant MAC address, say "X",  that means 
"transmitted by an RBridge".
When an RBridge decapsulates an IP packet onto the destination LAN, it 
can set the source
address in the layer 2 header to be X. The rule will be that an RBridge 
is not allowed to forward a packet that has layer 2 source address=X.

This won't solve the potential problem with non-IP packets, but we're 
really trying to just make sure this works for IP packets.

Comments?

Radia


Roeder, Konrad wrote:

>I agree with Joe that MPLS switches are L2 devices with a special L2.5 shim layer.  As part of their behavior, MPLS switches do/can decrement TTL.  So there is precedence here in L2 (L2.5?) devices meddling with TTL.  I believe that RBridges could decrement TTL to prevent loops, although doing so is not "a clean L2 implementation" because decrementing TTL indicates either a second of time went away or that a router was traversed.
>
>Another point to bring up: Do we want the rbridge to behave differently depending on what protocol is carried in L3?  If it's IP it uses TTL, if it's not it's decrementing a hop counter in its encapsulation.  Do we really want to add this complexity? 
>
>Going back briefly to the subject of the traceroute kludge... if TTL gets decremented from 1 to 0, does an Rbridge send an ICMP Timeout message?  Doing so would make an RBridge appear on a traceroute.  Not doing so, would make an RBridge appear as a *.  I suppose this is an implementation detail, but it might be worthwhile specifying the interaction.  (traceroute is a nice debugging tool)
>
>Konrad
>
>Konrad Roeder
>Broadband Wireless Network Engineer
>
>T-Mobile USA, Inc.
>Office:  425-748-2381
>PCS:   425-444-2076
>FAX:    [phone]
>12920 SE 38th Street
>Bellevue, WA  98006
>
>e-mail: [e-mail]
>
>
>Message: 3
>Date: Thu, 06 May 2004 09:39:56 -0700
>From: Joe Touch <[e-mail]>
>Subject: Re: [rbridge] RE: rbridge Digest, Vol 1, Issue 2
>To: "Developing a hybrid router/bridge." <[e-mail]>
>Message-ID: <[e-mail]>
>Content-Type: text/plain; charset="us-ascii"
>
>
>
>Radia Perlman wrote:
>  
>
>>I'm not sure it's useful to try to answer a philosophical question like 
>>whether RBridge is
>>layer 2 or layer 3. I don't think there's any agreed-upon definition, or 
>>whether it's too useful
>>to categorize. One might say it is layer 3 because it participates in 
>>some layer 3 protocols
>>(like ARP and ND).
>>    
>>
>
>It may be useful to distinguish between what is provided to the outside 
>of an rbridge (i.e., what it emulates) and how it operates internally.
>
>An rbridge (at least to me) emulates an L2 bridge - in which case the 
>TTL would not be decremented at all.
>
>When such a device emulates an L3 router, it is closer (IMO) to Virtual 
>Routers (see the draft; this was developed in the X-Bone project
>for recursive Internets) - which are VERY closely related, but each [L2 
>and L3] present unique issues. This draft focuses on the L2-providing 
>device.
>
>Internally, either may be implemented with L2 encapsulation, L3 
>encapsulation, or carrier pidgeon ;-)
>
>ARP and ND are interesting cases because they are L3 protocols that use 
>L2 information, i.e., they are 'glue' layers of a sort. They must be 
>interfaced to the edge of a campus of rbridges carefully, but I don't 
>see any showstoppers.
>
>Other more complex cases would be MPLS and other so-called layer 2.5 
>protocols. I confess they never made much sense in that regard to me; 
>IMO, MPLS is just a different L2 protocol that is layered over other L2 
>protocols.
>
>  
>
>>Someone privately told me there are certain IP protocols that will not 
>>work if the TTL
>>gets decremented, like "local broadcast".
>>    
>>
>
>RFC1812 talks specifically about how to process all-1's broadcast (local 
>broadcast), and how it MUST NOT be forwarded if the TTL is decremented. 
>There are other cases, e.g., subnet broadcast, which SHOULD NOT me 
>forwarded (although described as permitted in 1812, this is depricated 
>in RFC2644).
>
>In many ways, the definition of an IP subnet is "that in which the IP 
>TTL is not decremented".
>
>I agree with Radia that this is more important for things like:
>	- broadcast
>	- multicast
>
>which would affect:
>	- ARP/RARP
>	- DHCP
>	- BOOTP
>	- IGMP
>	- ICMP
>	etc...
>
>(see draft-ietf-pilc-link-design for details - notably the broadcast and 
>multicast sections, which I was responsible for).
>
>Joe
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: signature.asc
>Type: application/pgp-signature
>Size: 250 bytes
>Desc: OpenPGP digital signature
>Url : http://www.postel.org/pipermail/rbridge/attachments/20040506/38070885/signature-0001.bin
>
>------------------------------
>
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>
>
>End of rbridge Digest, Vol 1, Issue 3
>*************************************
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>




Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46KhdJ18936; Thu, 6 May 2004 13:43:39 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 06 May 2004 13:45:47 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Developing a hybrid router/bridge.
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA88C5AABF706EE2C056E4A9E"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2004 20:45:16 -0000
Status: RO
Content-Length: 6293

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA88C5AABF706EE2C056E4A9E
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Roeder, Konrad wrote:

> I agree with Joe that MPLS switches are L2 devices with a special
> L2.5
> shim layer. As part of their behavior, MPLS switches do/can decrement
> TTL. So there is precedence here in L2 (L2.5?) devices meddling with
> TTL. I believe that RBridges could decrement TTL to prevent loops,
> although doing so is not "a clean L2 implementation" because
> decrementing TTL indicates either a second of time went away or that a
> router was traversed.

The difference is that MPLS isn't trying to be an L2. Rbridge is.

If we relax that constraint, and allow rbridges to do what MPLS is, 
there's certainly precedent. And a very large and deep can of worms 
awaiting, IMO ;-)

> Another point to bring up: Do we want the rbridge to behave
> differently depending on what protocol is carried in L3? If it's IP it
> uses TTL, if it's not it's decrementing a hop counter in its
> encapsulation. Do we really want to add this complexity?

I can't answer whether it's wanted, but it would certainly need to be
sensitive to the L3 protocol if the TTL were decremented.

Perhaps that's another good reason not to decrement the TTL? :-)
I.e., it makes rbridge a true L2 system, which is compatible
with - and independent of - the protocol carried therin (at the edge).

> Going back briefly to the subject of the traceroute kludge... if TTL
> gets decremented from 1 to 0, does an Rbridge send an ICMP Timeout
> message? Doing so would make an RBridge appear on a traceroute. Not
> doing so, would make an RBridge appear as a *. I suppose this is an
> implementation detail, but it might be worthwhile specifying the
> interaction. (traceroute is a nice debugging tool)

IMO, anything that decrements the TTL is a router; that means RFC1812 
applies.
RFC2003 points this out with respect to tunnels - wherever TTL is 
decremented, there is the possibility of a zero and thus the need for 
ICMP TTL exceeded messages.

Joe

> 
> Konrad
> 
> Konrad Roeder
> Broadband Wireless Network Engineer
> 
> T-Mobile USA, Inc.
> Office:  425-748-2381
> PCS:   425-444-2076
> FAX:    [phone]
> 12920 SE 38th Street
> Bellevue, WA  98006
> 
> e-mail: [e-mail]
> 
> 
> Message: 3
> Date: Thu, 06 May 2004 09:39:56 -0700
> From: Joe Touch <[e-mail]>
> Subject: Re: [rbridge] RE: rbridge Digest, Vol 1, Issue 2
> To: "Developing a hybrid router/bridge." <[e-mail]>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> 
> Radia Perlman wrote:
> 
>>I'm not sure it's useful to try to answer a philosophical question like 
>>whether RBridge is
>>layer 2 or layer 3. I don't think there's any agreed-upon definition, or 
>>whether it's too useful
>>to categorize. One might say it is layer 3 because it participates in 
>>some layer 3 protocols
>>(like ARP and ND).
> 
> 
> It may be useful to distinguish between what is provided to the outside 
> of an rbridge (i.e., what it emulates) and how it operates internally.
> 
> An rbridge (at least to me) emulates an L2 bridge - in which case the 
> TTL would not be decremented at all.
> 
> When such a device emulates an L3 router, it is closer (IMO) to Virtual 
> Routers (see the draft; this was developed in the X-Bone project
> for recursive Internets) - which are VERY closely related, but each [L2 
> and L3] present unique issues. This draft focuses on the L2-providing 
> device.
> 
> Internally, either may be implemented with L2 encapsulation, L3 
> encapsulation, or carrier pidgeon ;-)
> 
> ARP and ND are interesting cases because they are L3 protocols that use 
> L2 information, i.e., they are 'glue' layers of a sort. They must be 
> interfaced to the edge of a campus of rbridges carefully, but I don't 
> see any showstoppers.
> 
> Other more complex cases would be MPLS and other so-called layer 2.5 
> protocols. I confess they never made much sense in that regard to me; 
> IMO, MPLS is just a different L2 protocol that is layered over other L2 
> protocols.
> 
> 
>>Someone privately told me there are certain IP protocols that will not 
>>work if the TTL
>>gets decremented, like "local broadcast".
> 
> 
> RFC1812 talks specifically about how to process all-1's broadcast (local 
> broadcast), and how it MUST NOT be forwarded if the TTL is decremented. 
> There are other cases, e.g., subnet broadcast, which SHOULD NOT me 
> forwarded (although described as permitted in 1812, this is depricated 
> in RFC2644).
> 
> In many ways, the definition of an IP subnet is "that in which the IP 
> TTL is not decremented".
> 
> I agree with Radia that this is more important for things like:
> 	- broadcast
> 	- multicast
> 
> which would affect:
> 	- ARP/RARP
> 	- DHCP
> 	- BOOTP
> 	- IGMP
> 	- ICMP
> 	etc...
> 
> (see draft-ietf-pilc-link-design for details - notably the broadcast and 
> multicast sections, which I was responsible for).
> 
> Joe
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 250 bytes
> Desc: OpenPGP digital signature
> Url : http://www.postel.org/pipermail/rbridge/attachments/20040506/38070885/signature-0001.bin
> 
> ------------------------------
> 
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
> 
> 
> End of rbridge Digest, Vol 1, Issue 3
> *************************************
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge

--------------enigA88C5AABF706EE2C056E4A9E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAmqP7E5f5cImnZrsRArbSAKDeSQ70ozxT2poLalF7oYWTOYmo4gCgx59T
hwpsBvJFY2cJslzDlP58Oi4=
=k1Q6
-----END PGP SIGNATURE-----

--------------enigA88C5AABF706EE2C056E4A9E--


Received: from WAPRDMSIMC03.gsm1900.org (wabod01s01.t-mobile.com [65.161.188.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46JlKJ06985 for <[e-mail]>; Thu, 6 May 2004 12:47:20 -0700 (PDT)
Received: by waprdmsimc03.gsm1900.org with Internet Mail Service (5.5.2653.19) id <KLLDR99X>; Thu, 6 May 2004 12:45:51 -0700
Message-ID: <[e-mail]>
From: "Roeder, Konrad" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Thu, 6 May 2004 12:45:50 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Developing a hybrid router/bridge.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2004 19:47:47 -0000
Status: RO
Content-Length: 4388

I agree with Joe that MPLS switches are L2 devices with a special L2.5 shim layer.  As part of their behavior, MPLS switches do/can decrement TTL.  So there is precedence here in L2 (L2.5?) devices meddling with TTL.  I believe that RBridges could decrement TTL to prevent loops, although doing so is not "a clean L2 implementation" because decrementing TTL indicates either a second of time went away or that a router was traversed.

Another point to bring up: Do we want the rbridge to behave differently depending on what protocol is carried in L3?  If it's IP it uses TTL, if it's not it's decrementing a hop counter in its encapsulation.  Do we really want to add this complexity? 

Going back briefly to the subject of the traceroute kludge... if TTL gets decremented from 1 to 0, does an Rbridge send an ICMP Timeout message?  Doing so would make an RBridge appear on a traceroute.  Not doing so, would make an RBridge appear as a *.  I suppose this is an implementation detail, but it might be worthwhile specifying the interaction.  (traceroute is a nice debugging tool)

Konrad

Konrad Roeder
Broadband Wireless Network Engineer

T-Mobile USA, Inc.
Office:  425-748-2381
PCS:   425-444-2076
FAX:    [phone]
12920 SE 38th Street
Bellevue, WA  98006

e-mail: [e-mail]


Message: 3
Date: Thu, 06 May 2004 09:39:56 -0700
From: Joe Touch <[e-mail]>
Subject: Re: [rbridge] RE: rbridge Digest, Vol 1, Issue 2
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"



Radia Perlman wrote:
> I'm not sure it's useful to try to answer a philosophical question like 
> whether RBridge is
> layer 2 or layer 3. I don't think there's any agreed-upon definition, or 
> whether it's too useful
> to categorize. One might say it is layer 3 because it participates in 
> some layer 3 protocols
> (like ARP and ND).

It may be useful to distinguish between what is provided to the outside 
of an rbridge (i.e., what it emulates) and how it operates internally.

An rbridge (at least to me) emulates an L2 bridge - in which case the 
TTL would not be decremented at all.

When such a device emulates an L3 router, it is closer (IMO) to Virtual 
Routers (see the draft; this was developed in the X-Bone project
for recursive Internets) - which are VERY closely related, but each [L2 
and L3] present unique issues. This draft focuses on the L2-providing 
device.

Internally, either may be implemented with L2 encapsulation, L3 
encapsulation, or carrier pidgeon ;-)

ARP and ND are interesting cases because they are L3 protocols that use 
L2 information, i.e., they are 'glue' layers of a sort. They must be 
interfaced to the edge of a campus of rbridges carefully, but I don't 
see any showstoppers.

Other more complex cases would be MPLS and other so-called layer 2.5 
protocols. I confess they never made much sense in that regard to me; 
IMO, MPLS is just a different L2 protocol that is layered over other L2 
protocols.

> Someone privately told me there are certain IP protocols that will not 
> work if the TTL
> gets decremented, like "local broadcast".

RFC1812 talks specifically about how to process all-1's broadcast (local 
broadcast), and how it MUST NOT be forwarded if the TTL is decremented. 
There are other cases, e.g., subnet broadcast, which SHOULD NOT me 
forwarded (although described as permitted in 1812, this is depricated 
in RFC2644).

In many ways, the definition of an IP subnet is "that in which the IP 
TTL is not decremented".

I agree with Radia that this is more important for things like:
	- broadcast
	- multicast

which would affect:
	- ARP/RARP
	- DHCP
	- BOOTP
	- IGMP
	- ICMP
	etc...

(see draft-ietf-pilc-link-design for details - notably the broadcast and 
multicast sections, which I was responsible for).

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20040506/38070885/signature-0001.bin

------------------------------

_______________________________________________
rbridge mailing list
[e-mail]
http://www.postel.org/mailman/listinfo/rbridge


End of rbridge Digest, Vol 1, Issue 3
*************************************


Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46GbmJ19305; Thu, 6 May 2004 09:37:48 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 06 May 2004 09:39:56 -0700
From: Joe Touch <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] RE: rbridge Digest, Vol 1, Issue 2
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.83.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA3B24D961F45BC0EA431CF95"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2004 16:38:58 -0000
Status: RO
Content-Length: 2983

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA3B24D961F45BC0EA431CF95
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Radia Perlman wrote:
> I'm not sure it's useful to try to answer a philosophical question like 
> whether RBridge is
> layer 2 or layer 3. I don't think there's any agreed-upon definition, or 
> whether it's too useful
> to categorize. One might say it is layer 3 because it participates in 
> some layer 3 protocols
> (like ARP and ND).

It may be useful to distinguish between what is provided to the outside 
of an rbridge (i.e., what it emulates) and how it operates internally.

An rbridge (at least to me) emulates an L2 bridge - in which case the 
TTL would not be decremented at all.

When such a device emulates an L3 router, it is closer (IMO) to Virtual 
Routers (see the draft; this was developed in the X-Bone project
for recursive Internets) - which are VERY closely related, but each [L2 
and L3] present unique issues. This draft focuses on the L2-providing 
device.

Internally, either may be implemented with L2 encapsulation, L3 
encapsulation, or carrier pidgeon ;-)

ARP and ND are interesting cases because they are L3 protocols that use 
L2 information, i.e., they are 'glue' layers of a sort. They must be 
interfaced to the edge of a campus of rbridges carefully, but I don't 
see any showstoppers.

Other more complex cases would be MPLS and other so-called layer 2.5 
protocols. I confess they never made much sense in that regard to me; 
IMO, MPLS is just a different L2 protocol that is layered over other L2 
protocols.

> Someone privately told me there are certain IP protocols that will not 
> work if the TTL
> gets decremented, like "local broadcast".

RFC1812 talks specifically about how to process all-1's broadcast (local 
broadcast), and how it MUST NOT be forwarded if the TTL is decremented. 
There are other cases, e.g., subnet broadcast, which SHOULD NOT me 
forwarded (although described as permitted in 1812, this is depricated 
in RFC2644).

In many ways, the definition of an IP subnet is "that in which the IP 
TTL is not decremented".

I agree with Radia that this is more important for things like:
	- broadcast
	- multicast

which would affect:
	- ARP/RARP
	- DHCP
	- BOOTP
	- IGMP
	- ICMP
	etc...

(see draft-ietf-pilc-link-design for details - notably the broadcast and 
multicast sections, which I was responsible for).

Joe

--------------enigA3B24D961F45BC0EA431CF95
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAmmpcE5f5cImnZrsRAgPsAJ9zaZ2nVeHGSY7Q76lk6mm3wc7L4ACfZkih
+Imvvo9/kwCyRC0CK6IJ09A=
=xxLI
-----END PGP SIGNATURE-----

--------------enigA3B24D961F45BC0EA431CF95--


Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i46GKYJ14834 for <[e-mail]>; Thu, 6 May 2004 09:20:47 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i46GHosT028015 for <[e-mail]>; Thu, 6 May 2004 10:18:52 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Thu, 06 May 2004 12:19:08 -0400 (EDT)
Received: from sun.com (vpn-129-147-153-4.Central.Sun.COM [129.147.153.4]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 06 May 2004 12:19:08 -0400 (EDT)
Date: Thu, 06 May 2004 09:19:08 -0700
From: Radia Perlman <[e-mail]>
Subject: Re: [rbridge] RE: rbridge Digest, Vol 1, Issue 2
In-reply-to: <[e-mail]>
To: "Developing a hybrid router/bridge." <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
References: <[e-mail]>
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2004 16:21:46 -0000
Status: RO
Content-Length: 3145

I'm not sure it's useful to try to answer a philosophical question like 
whether RBridge is
layer 2 or layer 3. I don't think there's any agreed-upon definition, or 
whether it's too useful
to categorize. One might say it is layer 3 because it participates in 
some layer 3 protocols
(like ARP and ND).

Someone privately told me there are certain IP protocols that will not 
work if the TTL
gets decremented, like "local broadcast". Not sure which protocols that, 
but that indeed would
answer the question. It is essential that RBridge not break any existing 
IPv4 or v6 behavior.
RBridges are presenting the campus as a single IP subnet, and any 
protocols the IP wants to
use on a single IP subnet should still work if you replace bridges with 
RBridges.

I have less sympathy with traceroute, since this is just a perception 
thing...there will be more
visible hops than there were before, but a hop is when something is 
being forwarded, so not
sure why people wouldn't want to see the bridge hops as well as the 
layer 3 hops.

But that's irrelevant. If there are IP protocols that would *break* if 
the TTL is decremented (and
it looks like there are), then we shouldn't decrement the TTL.

This means that all packets (IP on-campus, IP off-campus, and non-IP) 
will have an RBridge
encapsulation header that includes a hop count.

There are another couple of interesting issues with this direction, 
which I"ll bring up in another note.

If there are people that would like to see RBridges use the layer 3 TTL, 
please speak up.

Radia




Roeder, Konrad wrote:

>Radia,
>You wrote...
>
>  
>
>>One of the variations on the RBridge theme has the RBridge use the TTL 
>>in the IP header when forwarding IP packets. This avoids extra encapsulation overhead.
>>I think the tradeoffs are:
>>
>>in favor of using TTL: no extra bytes of overhead in the case of an on-campus IP packet, 
>>but there will still need to be encapsulation (to preserve the layer 2 
>>address) in the case of off-campus IP packet.
>>
>>against: the TTL will be decrementing, making the fact that there are internal hops visible.
>>
>>Opinions?
>>
>>Radia
>>    
>>
>
>I think it gets down to a fundamental question is RBridge a Layer 2 or Layer 3 protocol? (Or both?)
>
>If the RBridges decrements the IP header's TTL, then how do we handle the interaction with Traceroute?  Does RBridge reply as if it were a router (correctly sends back an ICMP message when TTL goes from 1 to 0) or a bridge (ignores traceroute)?  Will this break traceroute?  Does an RBridge have an IP address to provide in the ICMP message?
>
>If RBridge is a Layer 2 protocol, then it probably should not meddle with TTL.
>If RBridge is a Layer 3 protocol, then it should behave like a router and decrement TTL.
>
>Konrad
>
>Konrad Roeder
>Broadband Wireless Network Engineer
>
>T-Mobile USA, Inc.
>Office:  425-748-2381
>PCS:   425-444-2076
>FAX:    [phone]
>12920 SE 38th Street
>Bellevue, WA  98006
>
>e-mail: [e-mail]
>_______________________________________________
>rbridge mailing list
>[e-mail]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>




Received: from WAPRDMSIMC03.gsm1900.org (wabod01s01.t-mobile.com [65.161.188.9]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i461dqU09021 for <[e-mail]>; Wed, 5 May 2004 18:39:53 -0700 (PDT)
Received: by waprdmsimc03.gsm1900.org with Internet Mail Service (5.5.2653.19) id <KLLDQ92R>; Wed, 5 May 2004 18:39:35 -0700
Message-ID: <[e-mail]>
From: "Roeder, Konrad" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Date: Wed, 5 May 2004 18:39:46 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] RE: rbridge Digest, Vol 1, Issue 2
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2004 01:40:38 -0000
Status: RO
Content-Length: 1373

Radia,
You wrote...

>One of the variations on the RBridge theme has the RBridge use the TTL 
>in the IP header when forwarding IP packets. This avoids extra encapsulation overhead.
>I think the tradeoffs are:
>
>in favor of using TTL: no extra bytes of overhead in the case of an on-campus IP packet, 
>but there will still need to be encapsulation (to preserve the layer 2 
>address) in the case of off-campus IP packet.
>
>against: the TTL will be decrementing, making the fact that there are internal hops visible.
>
>Opinions?
>
>Radia

I think it gets down to a fundamental question is RBridge a Layer 2 or Layer 3 protocol? (Or both?)

If the RBridges decrements the IP header's TTL, then how do we handle the interaction with Traceroute?  Does RBridge reply as if it were a router (correctly sends back an ICMP message when TTL goes from 1 to 0) or a bridge (ignores traceroute)?  Will this break traceroute?  Does an RBridge have an IP address to provide in the ICMP message?

If RBridge is a Layer 2 protocol, then it probably should not meddle with TTL.
If RBridge is a Layer 3 protocol, then it should behave like a router and decrement TTL.

Konrad

Konrad Roeder
Broadband Wireless Network Engineer

T-Mobile USA, Inc.
Office:  425-748-2381
PCS:   425-444-2076
FAX:    [phone]
12920 SE 38th Street
Bellevue, WA  98006

e-mail: [e-mail]


Received: from muse.localhost ([129.94.183.99]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4593SU02109 for <[e-mail]>; Wed, 5 May 2004 02:03:28 -0700 (PDT)
Received: from nicta.com.au (localhost [127.0.0.1]) by muse.localhost (Postfix) with ESMTP id 51D2E94C4B for <[e-mail]>; Wed,  5 May 2004 19:03:20 +1000 (EST)
Message-ID: <[e-mail]>
Date: Wed, 05 May 2004 19:02:05 +1000
From: Aidan Williams <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Developing a hybrid router/bridge." <[e-mail]>
Subject: Re: [rbridge] Should RBridges decrement the IP TTL?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2004 09:04:30 -0000
Status: RO
Content-Length: 1846

Radia Perlman wrote:
> One of the variations on the RBridge theme has the RBridge use the 
> TTL in the IP header when forwarding IP packets. This avoids extra 
> encapsulation overhead. I think the tradeoffs are:
> 
> in favor of using TTL: no extra bytes of overhead in the case of an 
> on-campus IP packet, but there will still need to be encapsulation 
> (to preserve the layer 2 address) in the case of off-campus IP 
> packet.
> 

An un-encapsulated variant of rbridge would avoid the issue of
fragmentation resulting from the encapsulation overhead as well.

A bare IP packet approach could be done if rbridges used the destination 
IP address rather than the MAC address to make forwarding decisions. 
The next hop for IP destinations outside the campus would be resolved 
using the same information that hosts have (e.g. a default route).  The 
default route could be propagated to all rbridges using the link state 
routing protocol already in use.

> against: the TTL will be decrementing, making the fact that there are
>  internal hops visible.
> 
> Opinions?

Various link-local protocols use the TTL to detect and drop packets that 
have been forwarded.  A sender sets the TTL to the maximum allowable 
value and the receiver drops packets with TTL != max.  Messing with the 
TTL will affect these protocols.

This is not an insuperable problem if link-local is defined to be 
"really local to this link" rather than "heard by all the hosts in my 
subnet" as has been suggested in Dave Thaler's multilink draft. 
Unfortunately, the "really local to this link" definition makes sense 
for some protocols in an rbridge-style network (e.g. IPv6 neighbour 
discovery, IGMP) but not others (e.g. service discovery, multicast DNS).

Not decrementing the TTL re-introduces the problem of loops
.. but you knew that already. ;-)

- aidan


Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i454ZlU13137 for <[e-mail]>; Tue, 4 May 2004 21:35:47 -0700 (PDT)
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i454Zfms023588 for <[e-mail]>; Tue, 4 May 2004 21:35:42 -0700 (PDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Wed, 05 May 2004 00:35:41 -0400 (EDT)
Received: from sun.com (vpn-129-147-152-37.Central.Sun.COM [129.147.152.37]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 05 May 2004 00:35:41 -0400 (EDT)
Date: Tue, 04 May 2004 21:35:41 -0700
From: Radia Perlman <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-ISI-4-28-6-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Subject: [rbridge] Should RBridges decrement the IP TTL?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: "Developing a hybrid router/bridge." <[e-mail]>
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.postel.org/pipermail/rbridge>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.postel.org/mailman/listinfo/rbridge>, <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2004 04:36:01 -0000
Status: RO
Content-Length: 509

One of the variations on the RBridge theme has the RBridge use the TTL 
in the IP
header when forwarding IP packets. This avoids extra encapsulation overhead.
I think the tradeoffs are:

in favor of using TTL: no extra bytes of overhead in the case of an 
on-campus IP packet,
but there will still need to be encapsulation (to preserve the layer 2 
address) in the case of
off-campus IP packet.

against: the TTL will be decrementing, making the fact that there are 
internal hops visible.

Opinions?

Radia