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

From: Radia Perlman <[email-masked]>
Date: Fri, 10 Oct 2008 15:33:44 -0700

I can't quite parse bullet 3 in section 4.4.1.1. It might be correct, 
but the wording is confusing.

It's talking about the case where RB1, designated forwarder, receives a 
packet that RB1 knows should
go to egress RBridge RB2.

Maybe this wording is clearer?

*************section 4.4.1.1 bullet 3

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.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Donald Eastlake" <[email-masked]>
Date: Fri, 10 Oct 2008 19:59:27 -0400

It certainly is a run on sentence and it should be re-worded. But now
that there is no pseudo-code in the base protocol draft, I think the
specification needs to be fairly complete here. Your suggested text
leaves out a lot of details but this bullet is in the middle of
Section 4.4 which, to my mind at least, is supposed to give the
details for handling any possible input frame.

How about:

If the destination is known by RB1 to belong to egress RBridge RB2,
then RB1 encapsulates the frame with a TRILL header and transmits the
encapsulated frame towards RB2. This TRILL header has M = 0 and
specifies the nicknames for RB1 and RB2 as the ingress and egress
RBridges respectively. The transmitted frame has RB1 as the
Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA.

Thanks,
Donald

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Dinesh G Dutt <[email-masked]>
Date: Fri, 10 Oct 2008 17:18:44 -0700

That doesn't work correctly either. You want to distinguish two separate 
cases:
- The destination Rbridge is known to be local to a link VS
- The destination Rbridge is not local to that link and RB1 is not the 
designated forwarder for that link

In the former case, you send the frame to RB2 directly (outer.MACDA is 
RB2) and in the latter case, you send it to the designated forwarder 
(outer.MACDA is RBm).

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: "Donald Eastlake" <[email-masked]>
Date: Fri, 10 Oct 2008 20:58:43 -0400

See below:

> designated forwarder for that link

I don't understand your case descriptions above.

This bullet appears after two other bullets. (By the way, you only get
to this part of the text on receipt of a native from on a port where
RB1 is the appointed forwarder for the frame's VLAN.) The first bullet
says that if the destination is known to be on the same link, the
RBridge just discards the frame because the destination has already
gotten it. The second bullet says that if the destination is on
another link out of RB1 where RB1 is appointed forwarder for the
frame's VLAN you forward the frame in native form. This is the third
bullet where the destination is on a link for which another RBridge is
appointed forwarder for the frame's VLAN so you have to encapsulate
it.

> In the former case, you send the frame to RB2 directly (outer.MACDA is RB2)
> and in the latter case, you send it to the designated forwarder (outer.MACDA
> is RBm).

If you are just trying to say the text should have four cases by
splitting the encapsulation case into one where the egress RBridge
happens to be one RBridge hop from the ingress RBridge and a
"different" case where the egress RBridge happens to be multiple hops
from the ingress RBridge, I see no need to do that. If RB1 and RB2 are
one hop apart, then the next RBridge hop towards RB2 from RB1 is RB2.

Thanks,
Donald

> We make our world significant by the courage of our questions and by the
> depth of our answers.                               - Carl Sagan
>
>

---

From: Dinesh G Dutt <[email-masked]>
Date: Fri, 10 Oct 2008 19:24:03 -0700

Hi Donald,

Consider the following figure:
                                  | --- RB3 -- B
A --- RB1 --- RB2 +|
                                  | --- RB4 -- C

If in the shared segment between RB2-RB4, if RB2 is the designated 
forwarder, and a frame is sent from C to B, according to the wording of 
bullet 3, Outer.MACDA is set to RB2 and MACSA set to RB4. This doesn't 
work for the reasons you'll see if you follow the logic through. Even if 
it did work, I dislike the frame flow. I think the Outer.MACDA must be 
set to RB3.

This is what I'm trying to say. Did I read that section wrong ?

Dinesh

---

From: "Donald Eastlake" <[email-masked]>
Date: Fri, 10 Oct 2008 22:53:14 -0400

See below...

On Fri, Oct 10, 2008 at 10:24 PM, Dinesh G Dutt <[email-masked]> wrote:
> bullet 3, Outer.MACDA is set to RB2 and MACSA set to RB4. This doesn't work
> for the reasons you'll see if you follow the logic through. Even if it did
> work, I dislike the frame flow. I think the Outer.MACDA must be set to RB3.

This bullet item concerns only native unicast frames when the
destination is know and only accessible via another RBridge than the
RBridge receiving the native frame.

Assume a native unicast frame is sent from C to B in your diagram
above. Assuming that RB4 is configured to receive this native unicast
frame and is the appointed forwarder for the frame's VLAN for the link
to C, then RB4 is the ingress RBridge. Of course, in the diagram,
there is no other RBridge that could be appointed forwarder on the
link to C, so RB4 has to be the DRB for that link and presumably
appoints itself.

Similarly, looking at the other end, RB3 must be the DRB for the link
to B and appoints itself forwarder for traffic to B. Assume RB4 has
learned that B is connected to RB3.

So, as I say above, RB4 is the ingress RBridge and encapsulates this
known unicast frame with RB3 the egress. It then sends the resulting
TRILL frame with Outer.MacSA being RB4 port on the shared link and
Outer.MacDA being the unicast address of RB3, since, in this case, RB3
is the "next hop" RBridge towards RB3.

If makes no difference to TRILL frames who is DRB or "Appointed
Forwarder" on the shared link. Appointed forwarder status has no
effect whatsoever on TRILL frames. It only affects native frame
reception and transmission.

Possibly my revised text needs further clarification....

Thanks,
Donald

>>> RB2)
>>>>> then

---

From: Radia Perlman <[email-masked]>
Date: Sat, 11 Oct 2008 21:07:14 -0700

I don't understand Dinesh's first comment:

Dinesh said:
 >>That doesn't work correctly either. You want to distinguish two 
separate cases:
 >>- The destination Rbridge is not local to that link and RB1 is not 
the designated forwarder for that link

 >>In the former case, you send the frame to RB2 directly (outer.MACDA 
is RB2) and in the latter case, you send it to the designated forwarder 
 >>(outer.MACDA is RBm).

Possibly because I don't know what "VS" is in "link VS" above. And 
possibly because I think the fonts messed up
Dinesh's ascii art in his followup email.

But let's say that RB1 is appointed forwarder on port a, and therefore 
receives and encpasulates a native packet received
on port a. Since RB1 has learned that RB2 is the proper egress RBridge 
for that destination, RB1 puts RB2 as
the egress RBridge in the TRILL header, and forwards towards
RB2. Once the packet is encpasulated, designated fowarders are irrelevant.

With this, as with any encapsualted data packet, RB1 looks at RB1's 
forwarding table
that tells RB1 which port and nexthop RBridge to forward the 
encapsulated packet to. Just like any already-encapsulated
packet that RB1 might receive, because RB1 happens to be on the path 
from the ingress RBridge to the egress RBridge.

I don't see anything wrong with Donald's wording, which seems to be the 
same technically as what I'd proposed, but
just a little more explicit:

 >>"If the destination is known by RB1 to belong to egress RBridge RB2,

>>Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA."

I don't see why it needed to be any more explicit than what I'd said originally
(just forward the encapsulated packet towards RB2), since once the packet
is encapsulated, there is nothing different about it, as far as I can see,
than a packet that RB1 received already encapsulated with destination RB2.

Or am I missing something?

And if you really do want to be more explicit, you could throw in that you forward
onto the port indicated as the next hop towards RB2. (in addition to what Donald
threw in, which was that you put the next hop RBridge into the outer header).

Radia

---

From: Caitlin Bestler <[email-masked]>
Date: Sun, 12 Oct 2008 22:00:23 -0700

>>>> Outer.MacSA and the next hop RBridge towards RB2 as the Outer.MacDA.

Dinish is correct that the current text incorrectly states the
target RBridge in Bullet 3. But more fundamentally, this section
should not be attempting to describe the forwarding of a TRILL
Data Frame at all.

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.

-----
Caitlin Bestler
[email-masked] -- http://www.asomi.com/CaitlinBestlerResume.pdf

---

From: Radia Perlman <[email-masked]>
Date: Mon, 13 Oct 2008 12:15:10 -0700

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

---

From: "Donald Eastlake" <[email-masked]>
Date: Tue, 21 Oct 2008 16:23:13 -0400

Since it is operationally the same either way, whether bullet 2 stays
seems like more a matter of taste to me. However, since everyone who
has posted on the subject, except me, wants it to go, I'll remove it.

Donald

On Mon, Oct 13, 2008 at 3:15 PM, Radia Perlman <[email-masked]> wrote:
> If the destination is known by RB1 to belong to egress RBridge RB2, then RB1
> encapsulates the