[rbridge] {Filename?} RE: Critical bits for options

[Eric Gray]

Donald,

	It looks as if some part of your E-Mail got jettisoned
by the forwarder.  Hopefully it was nothing central to your
point in this posting.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Wednesday, December 12, 2007 12:29 AM
> To: rbridge at postel.org
> Subject: [rbridge] {Filename?} RE: Critical bits for options
> 
> Warning: This message has had one or more attachments removed
> Warning: (Drafts.xnk).
> Warning: Please read the "ISI-4-43-8-Attachment-Warning.txt" 
> attachment(s) for more information.
> 
> Hi Eric,
> 
> See below at @@@
> 
> -----Original Message-----
> From: Eric Gray [mailto:eric.gray at ericsson.com] 
> Sent: Monday, December 10, 2007 10: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.
> 
> @@@ Many options have been presented or discussed and 
>	described at many TRILL WG meetings and those 
>	presentation are in the IETF proceedings for
>	those meetings. Suggestions have included port ID 
>	(LID), flow ID, security, Customer ID, and various 
>	optimizations. See also descriptions of two of these 
>	in my previous message to John Drake.

I may want to respond to each of these on a separate thread,
but - in general - I thought these were brought up to justify
including the "options length" field in the header.  That was
a reasonable - forward-looking - compromise to satisfy those
who felt that options might become important.

The current proposals - in particular related to the concept
of a 'critical bit' (and associated handling) and the notion
of HbH verses E2E are not as generally applicable as you may
think.  In fact, the same point has been (and is conitnuing
to be) made in other currently on-going work in the IETF now.

As an example, suppose you have an option that applies to 
multicast forwarding but only needs to be acted upon by the
replication points in a multicast tree.  Is that HbH or E2E?

Also, the definition of 'critical' and corresponding handling
seems somewhat strained for general applicability.  I thought
I had been explicit enough on this point previously, but that
may not have been the case.  Is it always going to be the case
that simply discarding a frame is sufficient, or will there be
cases in which the application is critical and the device that 
inserted the option needs to know that the frame was delivered
(or, if not delivered, the point at which delivery fails)?

> 
> @@@ In any case, I think one of the largest benefits of 
>	an options feature is the ability to add options 
>	later that you can't think of to start with.

Yeah, right.  And therefore it is important - once you start
thinking about this options feature - that you include robust
"future proofing" for at least those applications you already 
can think of.

I would argue that we are not doing that and that the current
discussion appears to be more concerned about a specific set
of applications that have not been explicitly defined.  Let's
spell-out specifically the set of applications we are looking
at implementing right now to see if the current proposals are
sufficient for that purpose, and then worry about how to make
this proposal "future proof" against subsequent potential
applications.  Are you prepared to define explicit, currently
existing, requirements for this options feature?

> 
> 	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. 
> 
> @@@ We are talking about boxes that are all in the same 
>	broadcast domain and are quite often subject to 
>	coordinated management. In any case, if the boxes 
>	are fighting with each other, than can throw away 
>	data whenever they want regardless of whether any 
>	option feature or options are defined or used.
> 
> @@@ Since the options are in the TRILL header, they could 
>	be added to any frame. Whether a particular option 
>	would make sense for data and/or control (TRILL IS-IS) 
>	frames depends on the option. 

Very much so.

> @@@ (cont.)
>	Seems like adding a non-critical option to a frame 
>	would be more likely put it "in jeopardy" if some 
>	down stream Rbridges can't figure out what the 
>	situation is in terms of criticality, etc., which 
>	is why you want to specify a little more now.

This is an interesting assertion.  For one thing, it brings
up the question of whether or not the option is considered
to be more critical than the data.

My point is that we are probably not specifying enough, now,
unless we simply leave it as is (meaning we include a field
for options length in the header but don't actually define
anything else at this point).  Not knowing what the specific
applications are, how can we define 'critical', how can we
define appropriate handling and how can we even define what 
the meaning of terms - like HbH and E2E - is?

> 
> 	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').
> 
> @@@ People keep telling me that in the high end wired switch 
>	market, which is well represented in the TRILL WG, people 
>	build things to run the worst case that's still on the 
>	fast path at line speed so, for example, it is rarely 
>	useful to add an optimization unless it also helps the 
>	worst case. 

People do say the most interesting things.

> @@@ (cont.)
>	A similar consensus is why we dropped any encoding into 
>	the TRILL header of what tree pruning should be used for 
>	a frame but instead are currently forcing every Rbridge 
>	including transit RBridges, if they wish to do such 
>	pruning, to do the frame examination. 

As a matter of curiosity (because I tend to agree with this),
was this a WG consensus, or a design team consensus?

> @@@ (cont.)
>	I think such people would say that your concept of an 
>	Rbridge increasing its "sensitivity" to a critical frame 
>	because it was "congested" is bizarre and would never 
>	happen in anything they plan to build. 

Yep, heard that one before as well.  People who say things
like that are clearly assuming that no disconnect ever occurs
between what gets specified and what gets implemented, or that
people doing implementation and testing look at these things 
from the same perspective (as other people doing the same) or 
even that there has to be some degree of deliberation in 
implementation for something like this to happen.

In my mind, the likelihood that 'anti-social' behavior like 
this would occur in a specific implementation is related to
the complexity of the feature in question and the likelihood
that this feature is affected by proprietary implementation
details - rather than to any sort of maliciousness on the
part of a specific implementor.

Clearly this "options feature" is dead-center in the middle
of an area where proprietary implementation choices are very
likely to affect feature interoperability.

> @@@ (cont.)
>	I think they would also tell you that they don't plan 
>	to implement any options but if they did implement one 
>	that might commonly appear in frames, their bridges 
>	would be able to process it in the fast path for 
>	reasonable cases. 

Wow!  Imagine that!  An implementor that says their equipment
does everything fast.  Imagine my surprise (you'll need to, 
because you won't find it any other way)...

> @@@ (cont.)
>	I would expect the support of an option by an Rbridge 
>	to be reported in the link state database and be 
>	extremely stable, baring firmware updates or the like.

Ah, yes.  And this is another case that has been discussed 
relative to options before: if I think that acceptability
of an option has been established (particularly within an
implementation of protocol involving a state-machine), then
the failure of an option to be accepted as expected is an
indication of an "insane state."  Under these circumstances,
it has been argued previously, not only should the receiver
of an unexpected 'critical option' discard the associated
frame, but it should also consider the sender to be in an
insane state (and take appropriate corrective action by -
for instance - reseting the peer relationship).

Also, before we talk to much about adding this level of per
link information to be stored in the LSDB, we should call
in the Link-State routing experts to comment on the validity
of the assumption that we can do this.

> 
> 	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?
> 
> @@@ I did and I'm proud of it. There are a number of options 
>	whose inclusion, in my opinion, would not be a nightmare 
>	but would rather be sweetness and light. 

Yeah, well, as they like to say at auctions - one man's trash 
is another man's treasure.

> @@@ (cont.)
>	The inclusion of an options feature substantially improves 
>	the TRILL protocol. 

More precisely, the inclusion of the ability to later add this
feature substantially improves the future viability of TRILL.
Adding this feature explicitly at this point does nothing of
the sort.

> @@@ (cont.)
>	And, as I recall, there is a formal WG consensus 
>	determination specifying the TRILL header with Option 
>	Length field. 

Precisely.

As an analogy, you get the kid who threatens to hold his 
breath until you give him a pony.  You think, well maybe
the kid really could use a pony.  Now the kid wants to 
take the pony and join the circus.

What we have consensus on is to allow for options in the
future.  Including an options length field is sufficient
to allow for that.

> @@@ (cont.)
>	We are just discussing details of options and which 
>	of those details to include in the protocol 
>	specification now.
> 
> @@@ Are you saying that no protocol should have extensions 
>	or options?

No.

> @@@ (cont.)
>	Seems to me that many of the most successful protocols 
>	do. 

Yes, and at least some of those have never actually had much 
use of the options feature.  That would argue that - possibly
- you're getting the cart befor the horse.  Maybe successful
protocols are sometime successful in spite of the fact that 
they may include options, huh?

> @@@ (cont.)
>	See the presentation at the Thursday evening Plenary at 
>	IETF 70 which finds a correlation between flexibility 
>	and protocol success:
> 	http://www3.ietf.org/proceedings/07dec/slides/plenaryt-1.pdf. 

Thanks for providing me with an URL for a plenary presentation
for the meeting I was just at.

> @@@ (cont.)
>	And it seems to rarely if ever be the case that a simple 
>	linear sequence of versions is adequate. (I think we also 
>	have a number of other success factors listed in that 
>	presentation.)
> 
> 	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.
> 
> @@@ It's silly to think that adding an option to a frame 
>	would magically cause all downstream Rbridges to 
>	implement that option. 

It's even sillier to suppose that anyone suggested that.

> @@@ (cont.)
>	But I would agree that if an Rbridge advertises in the link 
>	state database that it supports an option, then it should do 
>	so.

And now we are assuming that this will be included in the LSDB
(as opposed to asserting that it may be)?

The statement I made above (relative to approriate responses
in this case) applies.  Failure of a device to accept what it
has previously agreed to accept represents a serious error -
for which "oh, well, maybe if I simply forget about it, it
will go away" may be a less than adequate response.

> 
> ...
> 
> 	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)?
> 
> @@@ "need" is a funny word but yes, I believe that at some 
> 	point in the future we will find that we "need" to add 
>	an option. As to why having an option feature is 
>	"desirable", which I think is a more reasonable criteria, 
>	see the presentation whose URL appears above, some of the
>	TRILL presentations in recent IETF proceedings, etc.

I guess you missed my point.  I do not argue that we don't
need to leave open the possibility of having options in the
future.  I do argue that we don't know enough at this point
to say more than that about it.

You argue that we need to also include a mechanism to allow
for appropriate handling of different types of options - in
a forward-compatible context.  This is not an unreasonable
position.  However, we simply do not have enough information
to determine the level of detail in "appropriate handling"
that you want to define.

> 
> @@@ As to why its useful to distinguish HbH and ItE options 
>	and critical vs. non-critical options: If you marshal 
>	your options in a rational way, the more you can classify 
>	as ItE, the fewer might have to be looked at by a transit 
>	Rbridge that implements one or more HbH options. As for
>	criticality, TRILL is an interesting case. Since I believe 
>	the Rbridges will be required to advertise their support 
>	of options in the link state database, it will be 
>	reasonable, at least in the known unicast case, to require 
>	an Rbridge not to send any critical options to an Rbridge 
>	that won't understand them. But the multi-destination case 
>	is, as usual, more complex. By the way, I think ItE is more 
>	precise than E2E. The option isn't in the frame from 
>	end-to-end. It's in the TRILL Header from Ingress to Egress.

I think this is pretty clear, but rests on assumptions we do
not have enough information to make.

I also think that I've explained that enough in previous parts
of this message that I don't need to say more along those lines.

I will add, however, that the above seems to conflate the use
of 'critical options' with the assumption of extended LSDB 
content/negotiation as well as additional informaion assumed
on a per-forwarding entry basis.  This is a nice detail to
be making people aware of.

> 
> 	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...
> 
> @@@ Since I believe one of the primary purposes of an options 
> 	feature is to accommodate future options that have not yet 
>	been considered, it is going to be a bit hard to give you 
>	the details of such options. I believe that by consensus 
	we have an options feature with a 5 bit Options Length 
>	field and an options area whose size in bytes is four times 
>	that Length. But perhaps, as they say, the devil is in 
>	the details beyond that.

Yeah, that would be the case.  And I'm not particularly ready
for (or interested in) an interview with the devil, just yet.

> 
> @@@ Thanks,
> @@@ Donald
> 
> --
> 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
>