[rbridge] Critical bits for options

Sat Dec 8 14:52:58 PST 2007

See below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of James Carlson
Sent: Thursday, December 06, 2007 5:28 PM
To: Russ White
Cc: rbridge at postel.org
Subject: Re: [rbridge] Critical bits for options

Russ White writes:
> So, the problem is--how do you signal, without looking for the
options,
> whether or not the faster switching path the packet comes in on should
> punt the packet to some slower path because of the presence of some
> option or another.

Yes.  In a particular degenerate case that appears to be of interest
to several posters here, systems that implement _no_ options at all
would like to know if any "critical" (must-comply) ones are present.
If they are, then the only thing the node can do is drop.

@@@ My personal opinion is that high end wired networks are a bit over
represented in the TRILL WG and that community dislikes options and has
no plans to implement any. And a number of people have spoken out
against a security option on the grounds that its too computation
intensive at high data rates. Design decisions might have been quite
different if wireless transport was over represented. People from the
wireless community are worried about every byte over their restricted
paths and if they dominated the TRILL WG we might already have option
bits to reversibly delete the inner Q-tag, IPv4, and IPv6 Ethertypes,
etc., inside encapsulated frames like 802.16 (Wi-Max) has for the
outside of all frames. Furthermore, because for their equipment security
hardware assist that runs at line speed (actually air speed I suppose)
is almost always included, people from the wireless community think of
adding data encryption and authentication as free.

@@@ Anyway, I'm not trying to say anything against the high end wired
applications, which are clearly important, nor saying we should define
and include options for constituencies that don't seem to be showing up
in the TRILL WG right now. What I am saying is that we should have an
option feature for flexibility, which is why I have been pushing for at
least a minimal hook for options, and we should not be surprised if for
some time the most prominent applications of TRILL are for Rbridges that
support no options at all. I also hope that TRILL will spread to a wide
variety of networks types in the future and I think that spread is
likely to motivate the specification of some options.

> 1. What are these options for? I'm a bit confused as to why there are
> such things as options (?)....

Good question.  Presumably, they'd be there to handle special
features, such as encryption in transit and labeling for security
purposes, and perhaps for debug options (trill-traceroute).  It's hard
to imagine too many _other_ purposes here, but I suppose others are
possible.

@@@ Some specific options have been mentioned at the last several
meetings, including LIDs (port IDs), Flow Tags, Security, frame
optimizations, ... See, for example, the slide on options in my
presentation on the meeting materials page at
http://www3.ietf.org/proceedings/07dec/slides/trill-4.ppt. Furthermore,
an advantage of having an options feature is that we can add options
later that we can't think of right now.

> 2. Will there be a consistent list, through time, of which options a
> given platform will switch in some faster path, and which they will
> switch in some slower path?

Almost certainly not.  The only assertion I've seen here is that some
implementations will be completely unable to support options at all.
They need to know whether to drop or pass a packet with options.

@@@ +1

> 1. It seems like if 2 is false, then there's no point in trying to put
> the options in any sort of order (?).... How can the sender know what
> some processing node in the middle can switch faster or slower?

@@@ There may also be security (i.e.,  canonicalization for
authentication) reasons to order options as well as the processing
efficiency reasons...

There's a difference between critical and non-critical hop-by-hop
options.

If there are any critical options, then all nodes on the path must
process them.  Any nodes that don't understand the option must drop
the packet.  That's the reason some are requesting a "summary" bit.

One way to resolve the whole problem is to outlaw critical hop-by-hop
options.  Maybe not the _best_ way, though.

@@@ Keep in mind that there are critical options that can be reversed
without loss of information. Almost all optimization options are of this
type. You can just de-optimize the frame and remove the option. Since
you can tell what options an Rbridge supports from the link state
database, when the preceding Rbridge sees that the next hop does not
support such a reversible critical option, it can drop the frame or it
reverse the option and then forward the frame.

> Overall, I think it might be useful to have a bit saying: "This packet
> has options you really need to process, so don't just switch it
without
> paying attention." A bit that says: "I have no options" might also be
> useful.

The latter we have -- Op-Length will be zero when there are no
options.

@@@ Right

The former we can get in one of at least two ways:

  - Summary bits (some like this, I don't)

@@@ I'll post some text I happen to have around.

  - Option ordering such that must-parse options are always first.

@@@ I think you should have a canonical ordering anyway if you might be
defining a security option later. And if you are specifying an ordering,
it might as well be such as to make processing more efficient.

@@@ Thanks,
@@@ Donald

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge