Subject: [rbridge] last call comment

From: "Jeff Pickering" <[email-masked]>
Date: Wed, 1 Jul 2009 10:55:21 -0700

Section 4.5.1

   "When building the tree number j, remember all possible equal cost

   parents for node N. After calculating the entire "tree" (actually,

   directed graph), for each node N, if N has "p" parents, then order

   the parents according to 7-byte ID. For tree j, choose N's parent as

   choice j mod p."

   I really dont like the idea of keeping all P parents, esp in an environment

   like fat tree where there may be dozens of upstream equal cost parents (times thousands of nodes).

      That said, we should at least say whether "order the parents" means starting with lowest or highest.

     Section 4.5.2

      "In this case, R1-R2 adjacencies are ordered as follows, with

      the one "most preferred" adjacency being the one that R1 transmits

      to R2 on, and the one that R2 accepts traffic from R1 on:"

      The way I read this, the statement is meaningless, R1 and R2 both transmit to each other. So

      either the intent is to say R1 (or R2) is the RB closer to the root. Or the intent is to say that depending

      on whether traffic is flowing towards or away for the root, you may choose a different adjacency. Whichever

      interpretation is intended should be clarified.

    Section 4.5.2

      Jeff

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

---

From: Radia Perlman <[email-masked]>
Date: Wed, 01 Jul 2009 15:02:14 -0700

Well, if we want to allow load splitting with at least p trees, then we 
have to keep p parents.

Alternatives to what is written, I think, are:

a) keep as is: while computing the tree, keep all p parents.

b) say that if p > j, then you only need to keep the top j choices of 
parent. (this
is true, and might be a good clarification to put in)

c) say that load splitting choices will never be more than, say, 5 (an 
architectural
constant we will choose now and be stuck with forever), and then say 
that the top
"5" choices of parents must be kept (so that the actual choice, for tree 
j, will
be j mod 5).

Choice b) does not affect the output-- it's just somewhat of an 
optimization for how
to compute the trees.

Would saying that be sufficient, or would you prefer that we actually 
limit the number of
potential load splitting choices?

Radia

Jeff Pickering wrote:
>       either the intent is to say R1 (or R2) is the RB closer to the 
> root. Or the intent is to say that depending
>
>       on whether traffic is flowing towards or away for the root, you 
> may choose a different adjacency. Whichever
>
> ------------------------------------------------------------------------
>

---

From: "Jeff Pickering" <[email-masked]>
Date: Thu, 2 Jul 2009 05:57:46 -0700

Radia,

Please understand that I am coming from the perspective of data center applications
where the heavily predominant architecture is one of a 3 tier fat tree with a radix
of 32, 48 or 64. In this architecture, the number of equal cost upstream paths is R/2
for approximately 60% of the RBs (assuming top tier root placement which is what
customers appear to want). I worry about the j mod p algorithm's impact on convergence 
times in this scenario. 

The algorithm provides no improvement in load sharing in this scenario either. And while
I understand that writing a spec for a particular architecture is inappropriate (just look to
What has changed since spanning-tree, ISIS etc were new), it seems to me that j mod p
is really only ensured to help load sharing in the specific case of co-located roots or 
at least located very close together. In other cases, it may actually decrease load sharing.

I understand your point that b) is no change and that it decreases at least some aspects
of the increased storage/sorting that needs to be done. However, I would still prefer c)
(5 seems realistic) because it limits the impact of optimizing for co/near located root case
while not limiting growth in other areas (eg radix 128 fat tree? still need to sort even in case b).

I someone wants to load share more than a new architectural constant, they can always do this
using root placement. Or if there is a real problem with the constant, we can always make it
configurable and place each RBs value in an LSP (we already have similar mechanisms).

Jeff

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]] 
Sent: Wednesday, July 01, 2009 6:02 PM
To: Jeff Pickering
Cc: [email-masked]
Subject: Re: [rbridge] last call comment

Radia

---

From: Radia Perlman <[email-masked]>
Date: Thu, 02 Jul 2009 20:50:52 -0700

It isn't me you have to convince. But a question...if there are that 
many paths, wouldn't people want
to load-split on most of them? If we limit it to 5, then the 5 parents 
with highest ID at the 2nd tier will
handle all the (multicast) traffic.

I'd think that most of the traffic would be unicast, so it wouldn't 
really be a problem, but I suspect
there are other people who would not be happy with a limit like 5.

Radia

---

From: jeff pickering <[email-masked]>
Date: Fri, 03 Jul 2009 14:08:52 -0700

Actually, by placing roots in differnt top tier groups, you guarantee 
that there are no overlapping paths
in any tree. So by definition, you load balance maximally.

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 15 Jul 2009 11:10:45 -0700

Why can't we limit the number of parents you pick to the number of trees 
that need to be computed ? The network topology that you state Jeff is 
not as common as you're suggesting, though it is a popular one,

Dinesh

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

---

From: Ayan Banerjee <[email-masked]>
Date: Wed, 15 Jul 2009 16:49:49 -0700

All, 

Please see attached comments on the Last Call for
draft-ietf-trill-rbridge-protocol-13.txt:

1. Section 3.7.3
The last sentence of this section seems to give the impression that
nicknames are LSP specific and node specific.
  "If it is desired for a pseudonode to be a tree root, the DRB MAY
    request one or more nicknames in the pseudonode LSP. "
Can we please remove this sentence from this section?

2. Section 4.3.1 
The default choice of 1470 bytes. If a host is connected to a Rbridge port,
is this choice acceptable?

3. Section 4.4
I am hoping on some clarification of the design - say there are 3 Rbridges
on the same "lan" with vlans enabled on them being Rbridge-A (Vlans 1, 2),
Rbridge-B (Vlans 1, 3), Rbridge-C (Vlans 1, 2, and 3). If Rbridge-A becomes
the DRB, then vlan-3 is isolated - is this accurate? In essence, whoever
becomes the DRB decides on which vlans in the "lan" is active.
Alternatively, let us assume there are number of nodes with vlans 1, 2, and
a new node with enabled vlans 2, 3 got introduced that will become the DRB
in the "lan";  will traffic that was flowing for vlan-1 be isolated - i.e.,
can the new-DRB appoint other nodes to be AF for vlan 1 - a vlan on which it
is not enabled? It would be nice to have a small bring-up scenario (possibly
in the appendix) to show the up down transitions from adjacencies, DRBs etc
as and when the above scenario or any other scenario occurs.

4. Section 4.5.1
The number of trees to compute is based on what the root node states. If I
understand this accurately, Rbridge-A will say say it wants 4 trees in the
domain if it becomes root. Say it eventually, becomes the root, but there is
a Rbridge-B that wants to compute no more than 2 trees. This number will now
drop down to 2 - accurate? Also, if Rbridge-B is the only node that wants 2
trees and all others want 4 trees, this number will keep on oscillating if
the adjacency to Rbridge-B keeps on flapping. It seems to me that we will be
creating/deleting a number of trees in this scenario.

5. Section 4.9.1 
This will not achieve what is being desired (transit traffic functionality,
I presume) using IS-IS rules at this time. Can this paragraph be deleted?

      "In some cases even though the DRB has the "access port" flag set,
      the DRB MAY choose to create a pseudonode for the access port. In
      this case, the other RBridges report connectivity to the
      pseudonode in their LSP, but the DRB sets the "overload" flag in
      the pseudonode LSP."

Thanks,
Ayan

---

From: Radia Perlman <[email-masked]>
Date: Wed, 15 Jul 2009 22:24:06 -0700

> Can we please remove this sentence from this section?

Why remove it? There are cases where it is useful for a pseudonode to 
have a nickname.
Are you just objecting to wording?
> the DRB, then vlan-3 is isolated - is this accurate?
I don't think so. It shouldn't be necessary for the DRB to be able to 
handle VLAN 3 -- it should be
able to appoint RBC as designated forwarder for VLAN 3.
> In essence, whoever

I think it only decides what is the designated VLAN, and decides who to 
appoint designated forwarder
for other VLANs.
> as and when the above scenario or any other scenario occurs.

I think this is the same case you just talked about. I'm pretty sure 
that the DRB can appoint a designated
forwarder for a VLAN that the DRB itself does not support. But an 
RBridge that can't talk on the designated
VLAN will be isolated.

> creating/deleting a number of trees in this scenario.

Yeah it's kind of ugly to have RBridges that can't support the number of 
trees the DRB would like. Not
sure how to fix it though.
>       pseudonode in their LSP, but the DRB sets the "overload" flag in

This is an obscure case that is indeed useful. I don't quite remember 
the example, but it has to do with
bridges that do multilinking through two upstream nodes.

Radia

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 16 Jul 2009 09:43:58 -0700

> Are you just objecting to wording?
What cases ?

Dinesh

---

From: Radia Perlman <[email-masked]>
Date: Thu, 16 Jul 2009 12:18:37 -0700

It had to do with two RBridges, R1, and R2, connected to the same edge 
cloud via a bridge B,
where B has some weird feature where it has 3 ports say, one each to R1 
and R2, and the other to
a cloud of endnodes. B forwards traffic from the endnodes to *only one* 
of R1 and R2.
B *never* forwards between
R1 and R2. R1 and R2 know that this is going on (they've been configured).

So the idea is that if the pseudonode associated with that cloud is 
given a nickname, then both R1
and R2 can act as encapsulator/decapsulators, and set the ingress 
nickname as the pseudonode.
Then return traffic can go shortest path to either R1 or R2 since the 
actual egress is the LAN itself.
But even though in the topology both R1 and R2 are connected to that 
LAN, they can't forward to
each other, so luckily the IS-IS "overload" feature, which is already 
there, handles that case perfectly.

There might have been other reasons why someone was asking for it to be 
optional to ask for
a nickname for a pseudonode. Certainly seems easy not to go out of our 
way to preclude it.

Radia

---

From: Radia Perlman <[email-masked]>
Date: Thu, 16 Jul 2009 13:18:14 -0700

Oh right. There was a much simpler reason for asking for a pseudonode to 
optionally be able to have a nickname -- that
was because in some topologies a pseudonode might make a good tree root.

Radia

---

From: jeff pickering <[email-masked]>
Date: Sat, 18 Jul 2009 06:48:29 -0700

Dinesh,

After thinking about this some more, Ive decided I can live with the 
spec as is.
Ive been able to come up with some spf optimizations that make life not 
quite so
bad.

Jeff