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

[Silvano Gai]

Joe/Radia,

inline

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Monday, October 16, 2006 10:49 AM
> To: Joe Touch; 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?
> 
> 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.

Can you clarify which is the proposed behavior for the outer MAC SA?

Thanks

-- Silvano


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