[rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3

[Radia Perlman]

So...is the conclusion that this wording of bullet 3 is fine?

If the destination is known by RB1 to belong to egress RBridge RB2, then 
RB1 encapsulates the
frame with TRILL header specifying RB2's nickname as egress RBridge, and 
forwards the encapsulated
frame towards RB2 as specified for TRILL data frames in 4.4.2.2.

**************

And I agree with Caitlin that we don't really need bullet 2. I don't think
it's terribly harmful, but especially since the wording now says "unless inhibited as
in section 4.2.3.3", it makes the reader think too hard and wonder what
inhibitions it might have. (I wondered). As it turns out, it's all part of
how to forward, and is covered elsewhere. The spec gets too long, and too confusing
if all details of something like "forwarding towards egress RBridge" are spelled out
in multiple places.

Basically, once RB1 encapsulates the packet, it then forwards towards the
egress RBridge (as worded at the top of this message). We could add a note,
after that bullet, such as:

Note: if RB1 is the egress RBridge for the destination, then as an optimization,
RB1 can skip the encapsulation step, and forward the unencapsulated frame to
the destination link. Note this has the same effect as having RB1 encapsulate
towards RB1, then decapsulate before forwarding onto the destination's link.

Radia





Caitlin Bestler wrote:
>
> Rather, it should describe how the native frame is encapsulated,
> and then forwarded "as specified for TRILL Data frames in 4.4.2.2".
>
> Bullet 2 describes an optimization for the degenerate case where
> the encapsulated frame is "forwarded" to the same RBridge, would
> would then decapsulate and deliver it (also as described elsewhere).
>
> Collapsing these steps into merely forwarding the native frame is
> clearly legal whether or not the document spells this out. For
> tutorial purposes, it might be better if it was made clear that
> this was an optimized handling and not truly a distinct protocol
> requirement.
>
>