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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Mon, 16 Oct 2006 18:58:59 -0400

Silvano,

	It is zero or more because - in a dynamically changing network
- it is possible for an intermediate RBridge to legitimately receive 
a frame for which it has no legitimate forwarding entries.

--
Eric 

--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> Sent: Monday, October 16, 2006 5:31 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?
--> 
--> 
--> IMO the correct behavior is:
--> 
--> Rm - receives an "RBridge encapsulated frame", determines 
--> that the Outer
--> DA MAC address is its own address, 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 
--> that the Outer
--> DA MAC address is its own address, determines from the shim 
--> header that
--> it is the egress, and forwards one or more "native frame(s)."
--> 
--> I am not sure in Rm why it is "zero or more" instead of 
--> "one or more".
--> 
--> -- Silvano
--> 
--> > -----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.
--> > 
--> > 	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
--> > -->
--> > -->
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 16 Oct 2006 19:58:12 -0700

> a frame for which it has no legitimate forwarding entries.

Indeed - another good reason (default forwarding is not required in an
rbridge campus).

-------------- 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/d804264a/signature.bin