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

[Saikat Ray]

The outer MAC SA should reflect the last RBridge that forwarded the packet
(and not the ingress RBridge). Otherwise, if legacy Ethernet segments
connect the RBridges (as opposed to having direct physical links), then the
MAC learning of the legacy bridges would get messed up and they _might_
start delivering packets incorrectly.

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Silvano Gai
> Sent: Monday, October 16, 2006 6:24 PM
> To: Gray, Eric; Joe Touch; Caitlin Bestler
> Cc: rbridge at postel.org; Radia Perlman
> Subject: Re: [rbridge] TTL only - was RE: New fields in shim header?
> 
> 
> 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
> > -->
> > -->
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge