[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)

[Silvano Gai]

Erik,

> -----Original Message-----
> From: Erik Nordmark [mailto:erik.nordmark at sun.com]
> Sent: Wednesday, October 18, 2006 9:47 AM
> To: Silvano Gai
> Cc: Gray, Eric; Radia Perlman; Caitlin Bestler; rbridge at postel.org
> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> Silvano Gai wrote:
> > Eric,
> >
> > The fact that the network is under a single administrative domain
and
> > the fact that different part of the network have different
> > users/security are not in contradiction.
> >
> > Let's take a University, a single backbone interconnecting many
networks
> > (Departments, Labs, Administration, External) and many users (Profs,
> > Students, Admin). Firewall, Routers and 5-Tuple ACLs are probably
used
> > for security, but it is also important to guarantee that firewalls
and
> > routers are not bypassed. Therefore it is possible to think that a
> > network administrator may want to disallow the RBdridges connecting
the
> > Labs to talk directly with the Rbridges connecting the
administrations
> > and so on.
> 
> Silvano,
> 
> That sounds like a good argument for using VLANs.

It is, VLANs have been used extensively to solve this problem.
 
> 
> But I have a more fundamental question. Are people accomplishing what
> you are requesting of RBridges using 802.1D bridges today?
> If so, how are they doing it?

I used to work for a large switch company for many years and one of the
requests I got consistently from customers was: "tell me with certainty
where the frame entered the network". You cannot do that in IEEE 802.1D.
When the network is under attack this is a great feature to have. It
also allows building additional ACLs, as I explained in previous emails.

> 
> There is nothing in the 802.1D data plan which indicates the first
> bridge that forwarded a frame.

Agreed.

> 
> The reason I'm asking is because I see a big difference between asking
> RBridges to provide some new degree of filtering/security, and making
> sure it isn't any worse than a bridged network.
> 

Understood, but a new standard is also a good place to improve.
If you buy my argument that having 32 bits of TRILL shim is not hardware
friendly, while 48 is, and you want to limit to the minimum the TRILL
shim, then let's go with Dinesh proposal:

Ddutt> I'd like to reiterate that I share the concern of protocol
overhead Ddutt> with the others, but methinks the overhead of 16 bits
(16-bit ingress Ddutt> ID, 16-bit egress ID, 16-bit TTL/FTAG maybe
sufficient) is worth the
Ddutt>  bits.

i.e.

   
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                      | FTag              | Hop Limit | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |  Ingress RBridge Address      |  Egress RBridge Address       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 
It is simple, clean and HW friendly

-- Silvano



> 
> > In addition to ACLs, I have read that having the two RBridge
addresses
> > can be useful for:
> > - Policy based forwarding
> > - Network Troubleshooting
> > - Hardware based learning
> >
> > I think this WG should seriously consider inserting both addresses
in
> > the shim header
> 
> I think the WG is; that's why there are all these emails ;-)
> 
> Regards,
>     Erik