[rbridge] New shim header proposal---without F-tag field
Eric.Gray at marconi.com
Tue Oct 31 14:00:08 PST 2006
If we keep it, then the specification needs to say that the
value is copied from the corresponding bit in a native encapsulated
frame at the ingress RBBridge and that (should anyone discover it
is not) any frame where that is not the case whould be treated as
a corrupted frame when received by any egress RBridge.
As it is now, there are too many ways to over-load such a
bit and that is practically guaranteed to produce interoperability
--> -----Original Message-----
--> From: Radia Perlman [mailto:Radia.Perlman at sun.com]
--> Sent: Tuesday, October 31, 2006 4:49 PM
--> To: Gray, Eric
--> Cc: Dinesh G Dutt; rbridge at postel.org
--> Subject: Re: [rbridge] New shim header proposal---without
--> F-tag field
--> Re: Eric Gray asked: Why a multicast bit:
--> I'm not sure we do need it, now that you mention it. Let's
--> work through the cases.
--> There is a field in the shim indicating what we've been
--> calling "egress
--> RBridge". Let's say
--> the value of that field is "X".
--> An RBridge has to know whether
--> to forward via unicast to X, or to forward
--> along the bidirectional tree rooted at X.
--> The ingress RBridge will fill in the field as:
--> a) the nickname of the egress RBridge, if the destination
--> is unicast and
--> the location is known
--> b) the nickname of the root of the selected tree (usually
--> itself) in the
--> case of multicast
--> c) some reserved value (probably "0") in the case of
--> unicast where the
--> destination is unknown. (I'm
--> assuming nobody wants to multipath *these* types of packets
--> to select a
--> different tree than the
--> one rooted at the ingress RBridge).
--> With a multicast bit, that would determine in. But suppose
--> there wasn't
--> a multicast bit?
--> If the destination address in the original frame is multicast, then
--> forward along the bidirectional tree rooted at X.
--> Otherwise, if "X"=0, then forward along the tree rooted at "ingress
--> RBridge". Otherwise, forward
--> unicast towards X.
--> And if an RBridge R in the middle was ambitious, and knew
--> where D was,
--> it could replace "0"
--> with the egress RBridge.
--> Ordinarily I don't like seeing multiple ways of specifying
--> something in
--> a header, because then
--> you have to say what happens if they disagree. But if having the
--> multicast bit makes forwarding
--> much simpler (since RBridges wouldn't have to look inside at the
--> original frame), then maybe
--> people would prefer it.
--> So technically, I think ERic is right and it's not needed.
--> But does it
--> make things a lot more convenient?
--> Gray, Eric wrote:
--> >Why do you need/want a multicast bit?
--> >If we're going to have both RBridge IDs in the SHIM, we don't
--> >need to consume a bit for multicast/unicast discrimination...
More information about the rbridge