Subject: [rbridge] Developing a hybrid router/bridge.

From: Konrad.Roeder at T-Mobile.com (Roeder, Konrad)
Date: Thu May 6 12:47:48 2004

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:    425-748-3050
12920 SE 38th Street
Bellevue, WA  98006

e-mail: [email-masked]

Message: 3
Date: Thu, 06 May 2004 09:39:56 -0700
From: Joe Touch <[email-masked]>
Subject: Re: [rbridge] RE: rbridge Digest, Vol 1, Issue 2
To: "Developing a hybrid router/bridge." <[email-masked]>
Message-ID: <[email-masked]>
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
[email-masked]
http://www.postel.org/mailman/listinfo/rbridge

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu May 6 13:45:18 2004

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

-------------- 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/df618480/signature.bin

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri May 7 14:10:30 2004

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri May 7 14:16:31 2004

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:

>> I agree with Joe that MPLS switches are L2 devices with a special L2.5 
>> 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 
>>> 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
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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
>> 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).
>>
>> (see draft-ietf-pilc-link-design for details - notably the broadcast 
>> and multicast sections, which I was responsible for).
>>
>> Joe
>> Url : 
>> http://www.postel.org/pipermail/rbridge/attachments/20040506/38070885/signature-0001.bin 
>>
>>
-------------- 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/20040507/bb2cf6e5/signature.bin

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri May 7 14:19:26 2004

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

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri May 7 14:36:11 2004

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:

> 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

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri May 7 14:52:30 2004

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

-------------- 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/20040507/279d0bc4/signature-0001.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri May 7 15:01:53 2004

> 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.

-------------- 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/20040507/759d2ac2/signature.bin

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri May 7 15:20:27 2004

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:

>> a) if it's non-IP, forward based on the inner layer 2 header 
>> destination address
>> The reason for making c) be a different case was so that two IP nodes 
>> on the same campus,
> 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
>------------------------------------------------------------------------
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri May 7 15:45:40 2004

> 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

-------------- 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/20040507/e691a0f0/signature.bin

---

From: aidan at nicta.com.au (Aidan Williams)
Date: Sun May 9 22:30:33 2004

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

---

From: Erik.Nordmark at sun.com (Erik Nordmark)
Date: Tue May 11 10:24:36 2004

> 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

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Tue May 11 11:04:39 2004

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

---

From: loa at pi.se (Loa Andersson)
Date: Tue May 11 12:26:38 2004

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:

>>> 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

-- 

Loa Andersson

mobile +46 739 81 21 64

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Tue May 11 23:04:49 2004

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).

 >    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

>>>> it won't loop while it is travelling across the campus, but after 
>>>> the egress RBridge decapsulates it,
>>>> were, at that point, to think it should forward the packet across 
>>>> the campus, then we'll have

---

From: loa at pi.se (Loa Andersson)
Date: Tue May 11 23:47:43 2004

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

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 +46 739 81 21 64

---

From: loa at pi.se (Loa Andersson)
Date: Wed May 12 01:32:40 2004

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 
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:

>>>>> there's no long an RBridge hop count, and the packet's IP TTL 
>>>>> hasn't changed. If another RBridge

-- 

Loa Andersson

mobile +46 739 81 21 64

---

From: loa at pi.se (Loa Andersson)
Date: Wed May 12 01:38:41 2004

> . 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

> RBridge will not get in the way of traffic between A and B.

swell, again we might want to state this

/Loa

-- 

Loa Andersson

mobile +46 739 81 21 64

---

From: ftemplin at iprg.nokia.com (Fred Templin)
Date: Wed May 12 13:11:44 2004

Hello Radia,

> 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
[email-masked]

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Wed May 12 13:23:44 2004

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

---

From: margaret at thingmagic.com (Margaret Wasserman)
Date: Thu May 13 10:26:49 2004

Speaking only as an individual...

>"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

---

From: margaret at thingmagic.com (Margaret Wasserman)
Date: Thu May 13 10:37:48 2004

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

Hybrid Bridge/Router BOF (hybridge)?

Margaret

---

From: alper.yegin at samsung.com (Alper Yegin)
Date: Fri May 14 16:42:56 2004

> 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

---

From: alper.yegin at samsung.com (Alper Yegin)
Date: Fri May 14 16:54:18 2004

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: [email-masked] [mailto:[email-masked]]
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

---

From: aidan at nicta.com.au (Aidan Williams)
Date: Fri May 14 16:59:55 2004

> investigating how we can achieve this while closely watching its cost on

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

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Fri May 14 17:05:55 2004

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
>  
>
>>address in the layer 2 header to be X. The rule will be that an
>>    
>>
>RBridge
>  
>

---

From: alper.yegin at samsung.com (Alper Yegin)
Date: Fri May 14 17:17:57 2004

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

On
> Behalf Of Radia Perlman
> Sent: Friday, May 14, 2004 5:06 PM
> Subject: Re: [rbridge] Developing a hybrid router/bridge.
>

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Sat May 15 17:35:03 2004

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

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Sat May 15 17:55:04 2004

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

>>>  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
>  
>
>>>  receives an ARP Request in which the target IP address is this
>>>      
>>>
>care-
>  
>
>>>  Note also that, when transmitting a Registration Request on a
>>>      
>>>
>foreign
>  
>
>>>  foreign agent by storing the address as it is received from the
>>>      
>>>
>Agent
>  
>