[rbridge] Critical bits for options

[Drake, John E]

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 

>-----Original Message-----
>From: Eric Gray [mailto:eric.gray at ericsson.com] 
>Sent: Monday, December 10, 2007 7:45 AM
>To: Radia Perlman; Eastlake III Donald-LDE008; rbridge at postel.org
>Subject: Re: [rbridge] Critical bits for options
>
>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
>> 
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>