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

[Eric Gray]

James,

	See below.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at sun.com] 
> Sent: Thursday, December 13, 2007 10:07 AM
> To: Eric Gray
> Cc: Eastlake III Donald-LDE008; rbridge at postel.org
> Subject: Re: [rbridge] {Filename?} RE: Critical bits for options
> Importance: High
> 
> Eric Gray writes:
> > 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?
> 
> Forcing that case to be HbH solves the problem.  The hops that are not
> replication points need do no work, but we don't necessarily know
> which ones these are ahead of time, so we do need each hop to handle
> it.
> 
> (I get the general point that there may be choices outside of HbH and
> E2E, but I'm not sure this example nails the problem.)

That obviously depends on what it takes to convince you that
the problem has been "nailed."  In my opinion, the argument
you make is equally valid for anything currently discussed
for the I2E (verses E2E - as Donald points out) - you could
always force any case to be HbH.

The argument that it may be unnecessary to have core RBridges
upgraded to accommodate even a 'critical' option if there is
the ability to indicate that the option only matters at the 
egress seems to apply equally well in other cases - possibly
including the multicast case (although that may be a stretch
in the general multicast case, there are applications for IP
multicast where only a certain well-defined subset of the IP
routers involved ever need to perform replication - and I am
reasonably sure that the same could apply RBridges).

In any case, if you acknowledge the general point, then you
admit that we're guessing that HbH and I2E is sufficient.

> 
> > What we have consensus on is to allow for options in the
> > future.  Including an options length field is sufficient
> > to allow for that.
> 
> It's sufficient only if we also remove the text in the current draft
> that supposes the existence of "critical" options.
> 
> With that text in place, we're in an impossible position: nodes are
> required to drop packets with uninterpreted "critical" options, but
> they have no way to determine whether any such options are present
> that might pose a problem.

And yet still this seems strange to me an I cannot see why it
does not seem equally strange to everyone else.

Consider that we're presumably talking about data frames - at
least from the perspective of the forwarding function, and for 
all frames containing what we're referring to as a 'critical 
option.'  Yet the handling described seems unprecedented in
anything I am aware of that the industry has done in the past
- except for control PDUs (frames and/or packets).

Maybe I missed it, but I don't recall seeing anything that has
indicated this would apply only to RBridge control protocols -
which I believe are all still neighbor to neighbor.  

I believe that it has already been suggested that "options" 
that might apply I2E (or any subset of "hops" that a given
class of frames will traverse) are most appropriately going
to be handled as a higher level function based on in payload 
contained in a frame - rather than on the frame as a whole.

Why is it that everyone is not asking themselves why we're
trying to solve this problem, here in TRILL and now at the
current level of protocol immaturity and inexperience?

> 
> That's why I previously suggested defining the length field, supposing
> all options are "non-critical," and then bumping the TRILL version
> field if we ever require "critical" options.

I would qualify this similarly; we can decide now whether or
not all options are critical or no options are critical in 
this version.  

It is unlikely that we'll decide every option is critical,
because doing that would make defining an option length
field silly in this version.  Simply having a non-zero
value in that field could be tantamount to inserting a 
'discard me' flag as far as any existing implementation 
is concerned.

But, if we did do that, we could still deal with critical
options in future protocol extenions - without necessarily
bumping the version number.  The proof-of-concept approach
to doing that is to include option-support advertisement
in LSAs and in the LSDB.  Then only a broken implementation
would ever insert any option in a frame due to be forwarded 
on a path including one or more hops that didn't indicate 
that they could handle that option.

This, incidentally, is what I found to be strange in what
Donald said earlier about his presumption that this would
be in the LSDB - but that we still need to indicate whether
or not any particular option is critical.  Why would you
ever need both?

On the other hand...

If we decide that no option is critical, but subsequently 
come up with a 'critical' application (forgive the play on 
words), there are ways to handle that - either in the same 
version or by bumping the version.  

Strictly as a proof of concept example, if future protocol 
extensions require some subset of all RBridges to process 
an option, then part of "processing an option" may include 
inserting a cooky to indicate that you've processed the
option - after verifying that your predecessor did so and 
before passing the cooky-containing option to a successor.

Note that - in this case - "predescessor" would be defined 
in a way that would apply for any specific future protocol 
extension in question.  That might include every hop (in
which case a simple implementation of this cooky approach
is so trivial I won't even bother describing it), or it 
may include any arbitrary subset of the hops along any
particular path (in which case the same scheme would be 
slightly more complicated). Also note that none of this 
has to be defined now.

That approach places the entire onus of dealing with the 
new protocol extension(s) on the implementations that are
required to participate (and therefore would have been 
upgraded to have the capability) - and does not require 
a bump in the version number.

And - clearly - there is always the possibility of bumping
the version number.  As others have not hesitated to use 
this argument, I will not either: several of the successful 
protocols around today have enjoyed the privilege of doing
so.  We're not, for example, currently using IPv1, nor is
the Internet meticulously stitched together using BGPv1.

> 
> > > @@@ (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.
> 
> It's actually unclear to me whether it constitutes any sort of error
> for the general case.

Let's first assume that - as is the case with IS-IS generally -
establishment of a peering relationship occurs before forwarding
is possible.

For this general case, negotiation results that MUST occur at the
time of establishing a relationship MUST be valid for the duration 
of the relationship.  Otherwise, the negotiation means nothing.
If re-negotiation is allowed for a valid existing relationship, 
things get a bit dicier (but then the first MUST above doesn't
apply); in this case, there MAY be a window of opportunity during 
which forwarding MAY occur that is inconsistent with negotiated
terms.  There are ways to avoid this, but the simplest is to avoid
re-negotiation.

But that may not be necessary.

This argument is true for general case of advertised capabilities - 
with some caveats:

o	it is likely (possibly even unavoidable) advertised
	capabilities will change,
o	advertisements do not always enjoy the deterministic
	nature of a relationship (e.g. - such as peering) and
o	windows of opportunity (where forwarding may not be
	consistent with advertised capabilities) are most 
	likely going to be unavoidable.

However, if you look at these "windows of opportunity" in both 
cases - and assume that all options are treated as if critical
- then what you get is dropped frames during the same window
of opportunity.  Since this WoO occurs as a result of changed
advertisements, I fail to see how this should alarm anyone.

> 
> The problem is that TRILL packets are forwarded based on tables at
> each hop -- they're not source-routed.  That means that the original
> sender who generated the packet and inserted those options may not
> necessarily know which nodes will actually handle the packet, and thus
> doesn't necessarily know which options can be interpreted on the path.

Actually this is not true for steady-state forwarding.  In the
absence of an ongoing transient, every link state router has 
exactly the same information as ever other link state router
and is in possession of all that it needs to know to be aware 
of the path any frame will traverse.

And - as descibed above - in the transient case - the result of
imperfect knowledge is that frames will get dropped that might
not otherwise have been dropped.  This is a characteristic of
network transients and not something to be alarmed about.

> 
> -- 
> 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
>