[rbridge] Critical bits for options

[Eric Gray]

Radia, Donald, et al,

	The one thing I don't seem to be getting out of this
discussion is even the most general idea what the application
is (or applications are) for these 'options' we are talking
about - or even a vague idea when and where they may apply.

	I assume - because we're talking about HbH and E2E -
that we're talking about data frames.  Frankly the idea of
putting data frames in jeopardy because some implementation
downstream from the ingress doesn't understand (or chooses to
pretend not to understand) an option is an EXTREMELY powerful 
argument for NEVER using options - and certainly not any of
the 'critical options' that might provide an excuse to drop
an entire class of frames.  This is - in a very real way -
roughly the same as providing yet another discard eligibility
mechanism since any implementation could decide to discard a
frame containing a 'critical option' - and be justified in
doing so.  

	Also note that - particularly for data frames - the most
reasonable interpretation for 'discard' is 'silent discard' 
since returning an error for every dropped frame (or even on a
periodic basis while dropping frames) is going to be a problem
- especially if some subset of all implementations 'cleverly'
decides to increase their 'sensitivity' to 'critical options'
under congestion conditions (very likely, given that - under
congestion - it is very likely that implementations will not
be able to keep up with at least some processing of 'critical
options').

	If that is - in fact - a correct understanding of the 
intent, then we're wasting time even talking about it (given 
the unlikelihood of there ever being a use for such a thing).
So that makes me ask: who dreamed this nightmare up and why?

	On the other hand, at least one person seems to interpret
this 'critical  option' indicator as 'must be processed' - which
includes 'process on the slow path' if you don't support doing
so on the fast path.  The distinction - again particularly for
data frames - is minor, given that it will not take long to 
over-whelm the slow path with data frames if we start seeing a
lot of 'critical options' and it will then be the case that the
implementations not capable of fast path processing of 'critical
options' will have no choice but to discard them.

	However, this latter case makes some sense if there is an
application for 'critical options' that either never, or very
rarely - results in using 'critical options' - but only 'some
sense', given the possibility that we're relying on a behavior
that probably cannot be reliably/deterministically predicted.

	So, my apologies if I am the only one that doesn't know
the answer to this question - but - what is the point of this
discussion (i.e. why do we need options and why 'critical' vs.
'non-critical' or HbH vs. E2E)?

	Based on the discussion so far (and as I have understood
it), I cannot make an informed decision.  All sorts of issues 
come to mind in the absence of knowing why we need this...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Tuesday, December 04, 2007 10:03 PM
> To: rbridge at postel.org
> Subject: [rbridge] Critical bits for options
> 
> I'd like to make sure the decision about whether to define 
> critical bits 
> for options is made with "informed consent" of the WG. I will write
> this with no opinion -- just the tradeoffs.
> 
> Currently the TRILL spec says to ignore all options -- the only thing 
> the spec says is how to skip the options, if any.
> 
> A "critical" option (some people call it "mandatory") is an 
> option that 
> if it appears and you don't understand it, you MUST drop
> the packet. A noncritical option is one that you are allowed 
> to ignore 
> and skip over.
> 
> The way the spec is now precludes critical options, because RBridges 
> following the current spec will skip all options.
> 
> An alternative is for TRILL to define two bits at the 
> beginning of the 
> options (these bits only appear if the options length is
> greater than 0).
> 
> The two bits are:
> a) a critical hop-by-hop option exists
> b) a critical end-to-end option exists.
> 
> If we define these bits, then an egress RBridge MUST look to see if 
> either of those bits are set, and if so, parse the options.
> A transit RBridge MUST look to see if the hop-by-hop bit is 
> set, and if 
> so, MUST parse the hop-by-hop options.
> Though I suppose an RBridge that doesn't support ANY critical options 
> would know based on the presence of a critical
> option that it should drop the packet, without having to 
> parse to find 
> the critical option.
> 
> So, our choices as a WG:
> 
> Choice A: Define NOW that the first 2 bits in the option 
> portion, if the 
> option length is nonzero are those two
> critical bits. And that if you are forwarding an encapsulated data 
> packet (i.e., you are acting as a transit RBridge
> for this packet), and thost of choice first (hop-by-hop 
> critical) bit is 
> set, you MUST drop the packet. And if you are egress
> RBridge, and either of the first two bits are set, you MUST 
> drop the packet.
> 
> Choice B: Leave the spec as it is
> 
> The cost of choice A is a bit more complexity, and a bit more 
> overhead 
> of forwarding because of having the set the bit.
> The cost of choice B is that we cannot ever define critical options.
> 
> The other arguments might be
> . how likely is it that we'd ever need critical options? Can 
> we imagine 
> some examples that we'd ever really want/need?
> . we could support such things by using a new version TRILL 
> header when 
> including critical options, so we are not
> really precluding critical options.
> . we could advertise (in LSPs for end-to-end critical 
> options, in Hellos 
> for hop-by-hop critical options), support for critical
> options, and the previous hop RBridge can throw the packet away if 
> there's no way to forward it without the critical option, so
> we don't really need for the receiving RBridge to discard the packet.
> . how bad would it be for an RBridge to ignore a critical option?
> 
> So...what do people think?
> 
> Radia
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>