[rbridge] Critical bits for options

[Eastlake III Donald-LDE008]

Hi John,

Can you point to a specific option that has been suggested which is a
control plane function? I don't think any of them are. Let me describe
two and tell me what you think.

(In this message, I'm not arguing for or against these options or giving
much detail but just trying to give a sketch to see if you think these
are control plane functions.)

Port ID (also called Local ID or LID): The idea is to avoid the MAC
address to port look up at an Egress Rbridge for unicast traffic. It
works by supplementing the source and destination MAC with a source and
destination LID. LIDs are probably 16-bits and would be learned the same
way MAC addresses and egress Rbridge are learned, by default from data
frame observation. There would probably have to be a distinguished LID
value which means unknown but otherwise LIDs are a local matter
presumably chosen so that the LID to port mapping is trivial.
	Obviously an Rbridge that didn't support the option wouldn't
send it and would ignore it on receipt. Since support would be indicated
in the link state database, an Rbridge that supported it might still
choose not to include it in a frame to an egress Rbridge that will
ignore it. For unknown unicast, you might want to include it or not or
maybe it's configurable but this and other considerations would be part
of the more detailed design. This option is probably not useful for
control (TRILL IS-IS) frames.

Security: The idea would be to leverage any IS-IS security keying so as
to authenticate or authenticate and encrypt data frames. This would
probably require hardware assist to be practical. While you could put
such an option in a control frame, it's probably better to use the IS-IS
security features directly. A security option could be used either
hop-by-hop or ingress-to-egress but ItE probably makes more sense. But
maybe there are some high security applications where you want both or
cases where a particular physical link goes through an area subject to
less physical control and security, where it would be worth getting
Rbridges with security assist hardware in their ports just for that one
hop or the like.

Do you consider the above options to be control plane functions that are
inappropriate to include in a data frame?

Thanks,
Donald 

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Drake, John E
Sent: Monday, December 10, 2007 6:02 PM
To: rbridge at postel.org
Subject: Re: [rbridge] Critical bits for options

Eric,

I think this is a great e-mail.  Piggybacking control plane functions,
especially critical ones, on data frames seems ill-advised for the
health and well being of both the control plane and the data plane.

Thanks,
John