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

[Gray, Eric]

Silvano,

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

	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
this
is a problem RBridges have to solve.

--
Eric

--> -----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?
--> 
--> Joe,
--> 
--> > -----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
--> another
--> > > RBridge. Do you agree?
--> > 
--> > True for all spoofing of MACs. That's not addressed by rbridges at
--> all.
--> > 
--> > >> 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
--> _should_
--> > 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
-->