[rbridge] TTL only - was RE: New fields in shim header?
Eric.Gray at marconi.com
Tue Oct 17 06:51:44 PDT 2006
It is clear at this point that you would like to include the ingress
RBridge information in the frame as it traverses the CRED. I believe it's
also clear why: you would like to perform filtering and policy enforcement
within RBridges, and you would like to be able to do this at any arbitrary
subset of deployed RBridges - for example, at specific egress RBridges to
protect the segments to which they deliver from untrusted access by other
However, there are two objections you need to overcome:
1) why do RBridges specifically need to solve this problem or provide
this capability? To do this you either have to establish that this
is covered somewhere in the existing working group charter, or you
have to convince enough people to achieve a consensus that this is
something we want to add to the existing charter.
2) is the approach you propose the one we want to adopt - i.e. - do we
have a consensus that we want to do this as a data path function in
RBridges (as opposed to in other network devices) and do we have
consensus that expanding the SHIM header is the approach we should
use to do this? To over come this objection, you must - serially -
establish that there is consensus to do this in RBridges using some
approach (as yet to be determined) and then work with the WG to get
consensus on how to do it.
In my opinion, I believe you are asserting that this is something we
must do, while some of us within the working group view it as something it
might be "nice to do." There is a significant disparity - at this point -
in what might be called "requirements levels" for this capability.
Also, again in my opinion, you are asserting that it must be done
using your approach. Assuming that we ever get agreement that this is a
thing tha RBridges should do, how they will do it remains TBD.
And yet, it does not appear to me that you have established that
is a problem RBridges have to solve.
--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com]
--> Sent: Tuesday, October 17, 2006 12:35 AM
--> To: Joe Touch
--> Cc: Caitlin Bestler; Gray, Eric; rbridge at postel.org; Radia Perlman
--> Subject: RE: [rbridge] TTL only - was RE: New fields in shim header?
--> > -----Original Message-----
--> > From: Joe Touch [mailto:touch at ISI.EDU]
--> > Sent: Monday, October 16, 2006 4:49 PM
--> > To: Silvano Gai
--> > Cc: Caitlin Bestler; Gray, Eric; rbridge at postel.org; Radia Perlman
--> > Subject: Re: [rbridge] TTL only - was RE: New fields in
--> shim header?
--> > Silvano Gai wrote:
--> > > Joe,
--> > >
--> > > .....
--> > >
--> > >> The enclosed source MAC indicates the source rbridge
--> at the time it
--> > > was
--> > >> encapsulated;
--> > >
--> > > Not true if the source MAC was spoofed by a host connected to
--> > > RBridge. Do you agree?
--> > True for all spoofing of MACs. That's not addressed by rbridges at
--> > >> the appropriate source rbridge for that packet may change
--> > >> by the time the packet arrives elsewhere in the rbridge campus.
--> > >
--> > > If you put the source RBridge address in the frame, why
--> should it
--> > > change?
--> > What might change is what the subsequent hops thinks the source
--> > be. The address in the packet wouldn't change, but would
--> be useless in
--> > that case.
--> It will tell me with certainty where the frame entered the RBridge
--> network (which RBridge did the encapsulation), which for me is
--> important, not useless.
--> -- Silvano
More information about the rbridge