[rbridge] New shim header proposal---without F-tag field

[Gray, Eric]

Radia,

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

--
Eric

--> -----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?
--> 
--> Radia
--> 
--> 
--> 
--> 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...
--> >
--> >--
--> >Eric
--> >
--> >  
--> >
-->