Subject: Re: [rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

From: Donald Eastlake <[email-masked]>
Date: Mon, 2 Mar 2009 16:07:11 -0500

Hi Ayan,
Thinking about this a bit more, I guess I wasn't thinking too clearly about
the distinction between known unicast and multi-destination. I hope you
would agree, there is no problem at all with known unicast frames, which
should act the way I described.
The possible problem is with multi-destination frames would primarily be
with the Reverse Path Forwarding Check. It may make that check a bit easier
if multi-destination frames are sent over only one of two or more parallel
one hop links between RBridges.

It seems confusing to refer to these additional factors (circuit ids) as
tree tie-breakers. I suppose it is an implementation detail but to my mind
these parallel one-hop links are only visible locally and appear as a single
connection in the topology and in any tree being built. In any case, it
seems better to call them "local decision criteria" or the like. Presumably
they would be used by the sending RBridge to choose which of the parallel
link to send multi-destination TRILL data frames on. And when setting up the
RPF check filters, you could assume that decision at the send and then
discard multi-destination frames arriving on the "wrong" links out of the
set of parallel links.

A couple of questions:
     Does this really make the RPF check significantly easier to calculate
or perform?
     If one is a P2P link and other is LAN, is it actually guaranteed that
you couldn't have an extended circuit id that was equal to a lan circuit id?
Maybe the tie breaker should be to favor P2P links, which presumably are
less likely to have conflicting traffic, and then use id as the next level
of tie breaker?

Thanks,
Donald

On Wed, Feb 25, 2009 at 9:18 PM, Donald Eastlake <[email-masked]> wrote:

> Hi Ayan,
>
> It looks like we are essentially in agreement on your first two
> points. See below on your third point.
>
> On Wed, Feb 25, 2009 at 1:46 PM, Ayan Banerjee <[email-masked]> wrote:
> > Donald,
> >
> > ...
> >
> > On 2/19/09 7:58 AM, "Donald Eastlake" <[email-masked]> wrote:
> >> Hi Ayan,
> >>
> >> See below...
> >>
> >> On Tue, Jan 13, 2009 at 5:56 PM, Ayan Banerjee <[email-masked]>
> wrote:
> >>> Radia and Donald,
> >>>
> >>> ...
> >>>
> >>> Parallel links between rbridges:
> >>> We need information in the draft that states that we break ties using
> (a)
> >>> extended circuit id on P2P links (makes 3-way handshake mandatory) and
> (b)
> >>> in a LAN, use lan circuit id.
> >>
> >> I'm confused by what you say. Assume we have RBridges 1 and 2 such
> >> that there is, say, a point to point link between port A on RB1 and
> >> port A on RB2 and also between port B on RB1 and port B on RB2. There
> >> are two points of view depending on whether you are one of these two
> >> RBridges or some other RBridge in the campus:
> >>
> >> Assume you are some other RBridge, RB3. Do you even see both the A and
> >> B adjacencies in the link state? I would think not and that this
> >> should be reported as only a single adjacency in the RB1 and RB2 LSPs.
> >> If, for some reason, you do see it as two adjacencies, why would you
> >> care? As long as you know there is connectivity between RB1 and RB2
> >> you can use that in SPF calculations. I suppose you need a way of
> >> determining the cost from the two costs you would see but you could
> >> just use the minimum of the two or something. And if for some really
> >> bizarre reason, even though you are remote from RB1 and RB2 you not
> >> only see the two parallel paths in the link state but you actually
> >> care which path is taken, there is no space in the LSP TLVs to encode
> >> any tie breaking information such as you suggest. So I don't see any
> >> need for a tiebreaker here.
> >>
> >> Assume the other case, that you are either RB1 or RB2. I don't see any
> >> difficulty here either. You should accept TRILL traffic on both
> >> connections and we should say that as a clarification. (You wouldn't
> >> want the Reverse Path Forwarding Check or something causing TRILL
> >> frames on one of the parallel connections to be discarded.) And you
> >> can send traffic on either connection. Or can do Equal Cost MultiPath
> >> on both. But if you send over only one of them then, assuming they are
> >> equal cost, it seems like a purely local decision which one and I
> >> don't see why we need to specify a tie breaker.
> >
> > When you have two parallel links and only one of them becomes a member of
> > the tree, then RPF as you have pointed out will fail on the other. If the
> > parallel links are part of a bundle, we do not need this. However, if the
> > user has specifically made them distinct, we need a method to ensure that
> > tree is computed along only one of them.
>
> What does it mean when you say "only one of them becomes a member of
> the tree"? How does that happen? As I say above, remotely from the
> RBridges with these two (or more) between them, I don't think you
> should be able to tell that there is more than one connection. And if
> you could, you shouldn't care whether one or the other is used or
> traffic is split across them. The topology is still the same
> regardless of which of these happens. And if you did care, there is no
> place in the LSP to add tie breaking info.
>
> And locally (that is, you are one of the two multiply connected
> RBridges), it's should just a local choice how to send, and you should
> have to be able to receive on any of the parallel links.
>
> Apparently the problem you see is just with the Reverse Path
> Forwarding Check at the receiving end of two or more parallel links
> between the same pair of RBridges.
>
> I responded above on that point by saying "You should accept TRILL
> traffic on both connections and we should say that [in the protocol
> specification] as a clarification. (You wouldn't want the Reverse Path
> Forwarding Check or something causing TRILL frames on one of the
> parallel connections to be discarded.)" Isn't that a satisfactory
> answer? (Maybe I shouldn't have said "both" because there could be
> more than two...) Why should the local RBridges be forced to tie break
> and leave all but one of there parallel point-to-point links idle?
>
> Thanks,
> Donald
>
> >>> Thanks,
> >>> Ayan
> >>>
> >>> ...
> >>>
> >>
> >> Thanks,
> >> Donald
>
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  [email-masked]
>

-- 
=============================
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: Ayan Banerjee <[email-masked]>
Date: Mon, 02 Mar 2009 14:26:15 -0800

Donald,

I agree that this is required for multi-destination frames only.  I am fine
with giving preference to P2P links and then to LAN etc.

Thanks,
Ayan

On 3/2/09 1:07 PM, "Donald Eastlake" <[email-masked]> wrote:

> the distinction between known unicast and multi-destination. I hope you would
> agree, there is no problem at all with known unicast frames, which should act
> the way I described.
> 
> The possible problem is with multi-destination frames would primarily be with
> the Reverse Path Forwarding Check. It may make that check a bit easier if
> multi-destination frames are sent over only one of two or more parallel one
> hop links between RBridges.
> 
> It seems confusing to refer to these additional factors (circuit ids) as tree
> tie-breakers. I suppose it is an implementation detail but to my mind these
> parallel one-hop links are only visible locally and appear as a single
> connection in the topology and in any tree being built. In any case, it seems
> better to call them "local decision criteria" or the like. Presumably they
> would be used by the sending RBridge to choose which of the parallel link to
> send multi-destination TRILL data frames on. And when setting up the RPF check
> filters, you could assume that decision at the send and then discard
> multi-destination frames arriving on the "wrong" links out of the set of
> parallel links.
> 
> A couple of questions:
>      Does this really make the RPF check significantly easier to calculate or
> perform?
>      If one is a P2P link and other is LAN, is it actually guaranteed that you
> couldn't have an extended circuit id that was equal to a lan circuit id? Maybe
> the tie breaker should be to favor P2P links, which presumably are less likely
> to have conflicting traffic, and then use id as the next level of tie breaker?
> 
> Thanks,
> Donald
> 
(a)
(b)