[rbridge] Critical bits for options

[Drake, John E]

Radia,

The customer ID listed in your e-mail, below, makes no sense to me.  How
would the ingress discover this information and what would the egress do
with it?  

I'm not sure there is any value in compression or encryption, for the
reasons I listed in the reply I just sent Donald, but if compression
and/or encryption were to be performed, wouldn't it be done on all
packets between ingress and egress, and wouldn't there need to be a
negotiation between ingress and egress on the specifics of the
compresssion and/or encryption protocol to be used?

If so, then the options field is totally useless because the ingress and
egress will know exactly how to perform packet processing without it.
It also  means that these types of functions can be implemented without
being specified in any Rbridge spec.

Thanks,

John 

>-----Original Message-----
>From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com] 
>Sent: Tuesday, December 11, 2007 7:46 PM
>To: Eric Gray
>Cc: rbridge at postel.org
>Subject: Re: [rbridge] Critical bits for options
>
>(using a "please limit your internet to 10 minutes" machine at 
>the conference, so hopefully I've not misinterpreted the email).
>
>Eric -- I very much sympathize with your email. In an earlier 
>version of the spec, Don had a couple of pages defining 
>options formats, and I thought it was just too complicated, 
>since I didn't think we'd ever use options, and I've never 
>liked "critical" options.
>
>However, he did tell me some examples of options. We could 
>always not have options, and only allow them with the next 
>version header, but here are some examples:
>a) a "customer ID" that you want transit RBridges to just 
>ignore, but will be useful for ingress and egress RBridges.
>b) a way of compressing the data packet, that you should be 
>careful that your upstream guy knows how to do before you send 
>it, but it's safer to make it critical so in case you 
>accidentally send it to him he won't misparse it
>c) cryptographic protection (again, should be critical so 
>someone doesn't try to interpret an encrypted packet).
>
>So he won me over and convinced me that at some point we might 
>want to allow all 4 types of options (critical/not, EtE, ItE).
>
>Radia
>
>----- Original Message -----
>From: Eric Gray <eric.gray at ericsson.com>
>Date: Monday, December 10, 2007 11:44 pm
>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
>> > [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
>> 
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://mailman.postel.org/mailman/listinfo/rbridge
>