[rbridge] TTL only - was RE: New fields in shim header?

[Joe Touch]

Gray, Eric wrote:
> Joe/Radia,
> 
> 	This is a point of substantial ambiguity in the currently
> available base protocol specification (dated May, 2006).
> 
> 	Section 2.6 ("Forwarding Behavior") - which is presumably
> the section that would talk about this - talks about the initial
> tunnel encapsulation in sub-section 2.6.1 ("Receipt of a Native 
> Packet"), but states that the ingress RBridge uses the next-hop
> RBridge as the MAC DA for the "outer" (tunneling) encapsulation.
> This implies router-like (or non-transparent bridging) behavior,
> which _might_ further imply that both the MAC DA and SA will be
> changed at the addressed RBridge next-hop.  But nowhere does it
> say this and - in fact - there have been people who assume that
> only the MAC DA is changed in intermediate RBridges.

Agreed. I was assuming that the SA/DA pair on the outermost header was
per-hop; that seems necessary, since otherwise a SA might appear as
sourced on by different nodes on a segment, confusing the STP used on
those (conventionally-bridged) segments.

> 	Section 2.6.2 - titled "Receipt of an In-Transit Packet", 
> and which should talk about forwarding across an intermediate 
> RBridge - does not address anything to do with MAC encapsulation 
> at an intermediate RBridge.  In fact, it doesn't actually address 
> all that much that would be interesting at an intermediate RBridge
> generally.

It should probably have an algorithmic description of the desired
behavior. The notes below should be addressed as well (mostly as stated,
but we'll confirm when we go through them in detail).

Joe

> 	Section 2.6.2.1 ("Flooded Packet") - for example - appears
> also to address behavior at the ingress RBridge only.  Reading
> this section, it appears to use "R1" exclusively in talking about
> the RBridge under discussion ("R1" was the ingress RBridge in the
> previous section) and even refers to R1 as the ingress RBridge in
> the 3rd paragraph on page 12.
> 
> 	Section 2.6.2.2 ("Unicast Packet") does say something that 
> appears to imply that both MAC DA and SA are changed, except that
> it - once again - uses the ubiquitous "R1" designation (and - in
> this case - R1 appears ambiguously to be either the ingress, the
> local or the egress Rbridge).
> 
> 	I hope this text is clearer in a soon-to-be-available new
> version of the base protocol specification.  I would suggest the
> use of a figure and new labels to make things less ambiguous.  I
> would also suggest having a distinct section to address egress
> behavior (separate from intermediate, or in-transit, behavior).
> 
> 	For example, you could add a really simple illustration - 
> 
> 	---- R1 --- --- --- Rm --- --- --- Rn ----
> 
> 	  (ingress)   (intermediate)    (egress)
> 
> - and identify what makes a particular RBridge one or another
> of these.  I think it's simple enough:
> 
> R1 - receives "native frame" (for a deifinition of "native") and
> encapsulates it using an Ethertype of "RBridge encapsulated frame". 
> 
> Rm - receives an "RBridge encapsulated frame", determines from the
> shim header that it is not the egress, and forwards another "Rbridge
> encapsulated frame" to zero or more next-hop RBridge(s).
> 
> Rn - receives an "RBridge encapsulated frame", determines from the
> shim header that it is the egress, and forwards one or more "native 
> frame(s)."
> 
> 	I also suggest being consistent in which of these RBridges 
> you're talking about in any of the sub-sections of section 2.6.
> 
> --
> Eric

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