[rbridge] Last Call comments on draft-ietf-trill-rbridge-protocol-13.txt

[Ayan Banerjee]

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