Subject: Re: [rbridge] Parent node ID selection for multi destination trees

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Wed, 4 Apr 2012 21:01:43 -0700

Hi Donald

Since we are still in very early days of TRILL, I think it is alright to include the proposed change in the clear correct draft.

I also support making Clear correct draft.

Thanks
Tissa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Tuesday, March 27, 2012 3:28 AM
To: Ayan Banerjee (ayabaner)
Cc: [email-masked]; Varun Shah (varshah)
Subject: Re: [rbridge] Parent node ID selection for multi destination trees

The only problem with making the change below is that it is very important that all RBridges calculate exactly the same distribution trees. Otherwise multi-destinationn traffic get dropped due to the Reverse Path Forwarding Check. The existing specification, while a bit odd, works; but an implementation of the existing specification and the proposed changed specification would have interoperability problems for multi-destination TRILL Data frame.

I'd really like to hear from other implementors as to whether they have implemented it as specified in RFC 6325 and what their feelings are about the proposed change.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Sat, Mar 17, 2012 at 2:24 PM, ayabaner <[email-masked]> wrote:
> Varun,
>
> Agree, that was the original intention. I believe that if kept as-is 
> we will have more unnecessary changes in the SPF outputs when topology changes.
>
> I believe that we should just add this into the 
> "draft-ietf-trill-clear-correct-01".
>
> Thanks,
> Ayan
>
>
>
>
> On 3/16/12 5:30 PM, "varshah" <[email-masked]> wrote:
>
> Hi,
>
> Reading section 4.5 of RFC 6325
> (http://tools.ietf.org/html/rfc6325#section-4.5) it seems that the 
> selection of a parent node  (7 byte- node ID) for a node N on a multi 
> destination tree j; should be based on j % p, where p is the number of 
> equal cost parent nodes to reach node N from root node R.
>
> The intent seems to use lowest parent node ID for tree 1, next for 
> tree 2 and so on.... And circle through if we have more possible trees 
> than parent nodes.
>
> However, the trees are numbered starting 1, and the parent node IDs 
> are indexed starting 0 to (p - 1).  So, for a node N, when the network 
> supports
> 2 trees and with two possible parent nodes,  we would use
>
> parent node indexed at 1 for tree 1, j % p --> 1 % 2 = 1 and Parent 
> node indexed at 0 for tree 2, j % p --> 2 % 2 = 0.
>
> To stay with the real intention, it would help if we had (j - 1) %p.
>
> In that case,
> parent node indexed at 0 for tree 1, (j  - 1)% p --> 0 % 2 = 0 and 
> Parent node indexed at 1 for tree 2,( j - 1) % p --> 1 % 2 = 1.
>
> Thanks,
> -Varun
> ________________________________
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge