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

[Gray, Eric]

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.

	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.

	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

--> -----Original Message-----
--> From: Joe Touch [mailto:touch at ISI.EDU] 
--> Sent: Monday, October 16, 2006 12:49 PM
--> To: Caitlin Bestler
--> Cc: Silvano Gai; Gray, Eric; rbridge at postel.org; Radia Perlman
--> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
--> 
--> 
--> 
--> Caitlin Bestler wrote:
--> > Joe Touch wrote:
--> > 
--> >> I don't think we're precluding ingress/egress filtering on
--> >> the LAN, just that it isn't needed inside the rbridge campus.
--> >> Traffic either originates inside the LAN (on an rbridge node
--> >> or host) or enters via a transit (a router). Both can be
--> >> constrained with the outer ethernet header addresses; there's
--> >> nothing magic about the ingress or egress rbridge node as far as
--> >> filtering is concerned. 
--> >>
--> > 
--> > Agreed.
--> > 
--> > More precisely, there WILL be environments with sufficient
--> > perimeter ingress control that internal checking would not
--> > be required. But if we put the extra fields in the header
--> > they will ALWAYS be there.
--> 
--> Rbridge traffic is already differentiated on a per-hop 
--> basis; what's the
--> utility in knowing the ingress? That increases - rather 
--> than decreases -
--> the state at the interior rbridge nodes.
--> 
--> > Most of the extra fields CAN be derived from other information.
--> > For example the enclosed source MAC address implies the 
--> > source RBridge. Therefore it is hard to make a case that
--> > they will provide a permanent benefit. 
--> 
--> The enclosed source MAC indicates the source rbridge at the 
--> time it was
--> encapsulated; the appropriate source rbridge for that 
--> packet may change
--> by the time the packet arrives elsewhere in the rbridge 
--> campus. That's
--> another reason it's not useful to know the source - it is 
--> ephemeral anyway.
--> 
--> Joe
--> 
-->