[rbridge] Critical Bits Text

[Radia.Perlman@sun.com]

I'm OK with that text. I'm not convinced about the text after =====, which is just a note in the email to the WG
I assume, and not proposed as going into the protocol spec.

I assume what you are thinking about is if the top bit of each option was
the "critical bit", then it would naturally appear as the first bit there anyway.
Howevder, I'd assume that we'd need first a "length of HbH options" header, and
the critical ItE bit would certainly not naturally appear as the 2nd bit if we were really to
define all the options at this point. It's a "summary" bit. So I can imagine some people arguing instead
to completely define the options at this point.

If we leave it as having the two bits where you said, then we might wind up ultimately with a different
format than if we really thought through EtE and ItE critical and noncritical options, but I'm fine with
having the summary bits upfront. It does certainly optimize processing for RBridges that support no options.

Radia


----- Original Message -----
From: Eastlake III Donald-LDE008 <Donald.Eastlake at motorola.com>
Date: Sunday, December 9, 2007 6:59 am
Subject: [rbridge] Critical Bits Text

> Here is an example of some text on critical summary bits cut and 
> pastedfrom an internal version of the protocol document that was 
> never posted:
> 
> In the subpart of Section 3 on options:
> 
> 
> =======================================================================
>   To ensure backward compatible safe operation, when Op-Length is 
> non-
>   zero, indicating that options are present, the top two bits of the
>   first byte of the options area are specified as follows:
> 
>                      +-----+-----+---+---+---+---+---+---+
>                      | HbH | ItE |       Reserved        |
>                      +-----+-----+---+---+---+---+---+---+
> 
>                 Figure 6. Options Area Initial Flags Byte
> 
>   If the HbH bit is one, one or more critical hop-by-hop options are
>   present so, for example, transit RBridges that support no options
>   MUST drop the frame. If the HbH bit is zero, the frame is safe, 
> from   the point of view of options, for a transit RBridge. A transit
>   RBridge that supports no options and forwards a frame MUST
>   transparently forward the options present.
> 
>   If the ItE bit is a one, one or more critical ingress-to-egress
>   options are present. If it is zero, no such options are 
> present.  If
>   either HbH or ItE is non-zero, egress RBridges that support no
>   options MUST drop the frame.  If both HbH and ItE are zero, the 
> frame   is safe, from the point of view of options, for any egress 
> RBridge to
>   process.
> 
> 
> =======================================================================
> It is the case the if the options format is definite so that the 
> top bit
> of the first byte of the option indicates it is a critical hop-by-hop
> option and the options are ordered so that such options have to appear
> first, then at least transit Rbridges that support no options 
> would be
> checking exactly the same bit regardless of whether these summary bits
> were present or not.
> 
> Thanks,
> Donald
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>