[rbridge] base protocol minor rewording issue -- 4.4.1.1 bullet 3
Radia Perlman
Radia.Perlman at sun.com
Sat Oct 11 21:07:14 PDT 2008
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 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).
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,
>>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."
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
Donald Eastlake wrote:
> See below...
>
> On Fri, Oct 10, 2008 at 10:24 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
>
>> 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 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
>
>
>> This is what I'm trying to say. Did I read that section wrong ?
>>
>> Dinesh
>> Donald Eastlake wrote:
>>
>>> See below:
>>>
>>> On Fri, Oct 10, 2008 at 8:18 PM, Dinesh G Dutt <ddutt at cisco.com> wrote:
>>>
>>>
>>>> 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
>>>>
>>>>
>>> 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
>>>
>>>
>>>
>>>> Dinesh
>>>> Donald Eastlake wrote:
>>>>
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> On Fri, Oct 10, 2008 at 6:33 PM, Radia Perlman <Radia.Perlman at sun.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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
>>>>>> rbridge at postel.org
>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> We make our world significant by the courage of our questions and by the
>>>> depth of our answers. - Carl Sagan
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> --
>> We make our world significant by the courage of our questions and by the
>> depth of our answers. - Carl Sagan
>>
>>
>>
>
>
>
>
More information about the rbridge
mailing list