Re: [trill] DTree Questions Regarding Router Capability TLV

[Donald Eastlake <[e-mail]>]

Hi,

You should note that the "TRILL: Clarifications, Corrections, and
Updates" draft, particularly Section 3, affects some of the issues you
are asking about. That's draft-ietf-trill-clear-correct-06.txt, which
is fully approved and in the RFC Editor's queue.

On Mon, Dec 17, 2012 at 5:13 PM, Ayan Banerjee <[e-mail]> wrote:
> Please see in-line.
>
> Thanks,
> Ayan
>
> On Mon, Dec 17, 2012 at 1:50 PM, Arnel Lim <[e-mail]> wrote:
>>
>> I have some questions about the sending and processing of the TREES-RT-ID
>> and TREES-USE-ID sub-TLV in the Router Capability TLV.  I need a little
>> clarification with respect to when these sub-TLVs are sent and who sends
>> them.  I’ve outlined how I interpreted parts of the Distribution Tree
>> section RFC632 with respect to these sub-TLVs, but I need a little
>> validation.
>>
>>
>> Note, the quoted items are taken directly from RFC6325.
>>
>>
>>
>> 1) Only the highest priority Rbridge needs to send out TREES-RT-ID
>> sub-TLV, correct?
>>
>> “The number of trees, k, that are computed for the campus is the number
>> wanted by the RBridge RB1, which has the nickname with the highest "tree
>> root" priority”
>>
>> [Ayan] Yes, this is accurate.

While accurate, it may not be wise. What if the RBridge holding the
highest priority tree root nickname dies or the network partitions or
something? This is typically a pretty small sub-TLV. I would think
that, in a well configured campus, if you are using this sub-TLV to
specify your tree roots rather than just doing it by priority, then
many of the RBridges with higher priority tree root nicknames would
advertise this sub-TLV.

>> 2) Rbridges will calculate the highest priority k trees if they don't
>> receive TREES-RT-ID sub-TLV.  This implies it's *NOT* mandatory for highest
>> priority Rbridge to send TREES-RT-ID sub-TLV, correct?
>>
>> “If RB1 does not specify the specific distribution tree roots as described
>> below, then the k highest priority trees are the trees that will be computed
>> by all RBridges.”
>>
>>   [Ayan] Yes, this is accurate.
>>
>> 3) ALL Rbridges, RB2, that ingress native traffic MUST send TREES-USE-ID
>> sub-TLV, correct?   This is required for RPF check used by adjacent
>> RBridges.
>>
>> “each RBridge RB2 MUST announce which trees RB2 may choose when RB2
>> ingresses a multi-destination packet.”
>>
>> [Ayan] No, this is not accurate. If ingress nodes use this TLV, it may
>> help other nodes to be more strict in accepting packets from the relevant
>> multi-destination trees. If it does not send out this TLV, then it implies
>> that a node may use all multi-destination trees.

Ayan is right. The "MUST" there really means that the RB2 has to
announce information from which, along with information from the
RBridge holding the highest priority tree root nickname, other
RBridges can derive the distribution trees that RB2 might use. As
stated in RFC 6325, the primary reason for this is to reduce the
amount of RPF state if every RBridge cannot ingress multi-destination
to every tree being computed for the campus..

>> 4) Transit-only RBridges do NOT need to send TREES-USE-ID sub-TLV,
>> correct?  Since TREES-USE-ID indicates what trees a RBridge may use for
>> ingressing native traffic, Transit-only RBridges have nothing to advertise.
>>
>> [Ayan] See answer to (3) above.

I don't think there is any way an RBridge can indicate it is transit
only. Usually switches have an internal virtual end station and at
least end up effectively ingressing frames from this virtual end
station. If some RBridge will do little or no ingressing of
multi-destination frames, it should probably just use one distribution
tree. If it is going to use the highest priority tree, I believe all
it needs to do is announce the Trees sub-TLV with Number of Trees Used
equal to one. If it wants to use some different single tree, then it
should also announce the nickname of that tree in a Trees Used
Identifiers sub-TLV.

>> 5) Ingress RBridges, RB2, can specify, via user config, a set of j trees
>> to use.   If NO trees in the set of j trees intersect with the k highest
>> priority  trees advertised by the Rbridge with highest root priority, NONE
>> of the  j trees are advertised.  Ingress RBridges, RB2, will then advertise
>> the k  highest priority trees in the TREES-USE-ID sub-TLV. Correct?
>>
>> OR, does RB2 advertise whatever it wishes, and the RBridge receiving the
>> LSP examine the intersection of j with k?
>>
>> [Ayan] It is the latter - others make use with the TREES-USE-ID TLV. What
>> a local nodes announces with user configured "j" trees is a local decision.
>>
>> If no set of j trees is explicitly configured, will RB2 advertise the k
>> highest priority trees in the TREES-USE-ID sub-TLV, or none at all.  What’s
>> not clear is if in the special case of j==0, do we still have to include the
>> sub-TLV in the LSP?  I would think the neighboring RBridge can assume if the
>> TREES-USE-ID sub-TLV is not present, that means j==0 and RB2 will use the k
>> highest priority trees.   Seems explicitily advertisine the k highest trees
>> may be the “safe” thing to do for interoperability, but is it the “right”
>> thing to do?
>>
>> [Ayan] Sure a node can announce the "K" trees, but that is also implicit.

Right. If no set of j trees is explicitly configured, then it is implicit.
(see more below)

> Thanks,
> Ayan
>
>>
>> “The information to determine which trees RB2 might choose is included in
>> RB2’s LSP. Similarly to how the highest priority RBridge RB1 specifies the k
>> trees that will be computed by all RBridges, RB2 specifies a number j, which
>> is the total number of different trees RB2 might specify, and the specific
>> trees RB2 might specify are a combination of specified trees and trees
>> selected from highest priority trees. If RB2 specifies any trees that are
>> not in the k trees as specified by RB1, they are ignored.
>>
>> The j potential ingress trees for RB2 are the ones with nicknames that RB2
>> has explicitly specified in "specified ingress tree nicknames" (and that are
>> included in the k campus-wide trees selected by highest priority RBridge
>> RB1), with the remainder (up to the maximum of {j,k}) being the highest
>> priority of the k campus-wide trees.”

As specified by an Errata filed against RFC 6325 and
draft-ietf-trill-clear-correct-06.txt:
   In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the
   parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052].
   It should read "(up to k if j is zero or the minimum of (j, k) if j
   is non-zero)".

>> When the RFC refers to RB2’s LSP it is referring to the TREES-US-ID
>> sub-TLV, correct?

The LSP (Link State PDU) for RB2 includes all of the Trees, Tree
Identifiers, and Trees Used Identifiers sub-TLVs that RB2 chooses to
advertise. (Tree Identifiers will not have any effect unless RB2 holds
the nickname that is the highest priority tree root).

>> The j potential ingress trees this section talks about would be manually
>> configured by the user, correct?

Well, there is a default that will happen without configuration but
normally the network manager will configure things to get the
distribution tree use they want.

>> If no j trees are specified, does RB2 default to sending out the k trees
>> in the TREES-USE-ID sub-TLV, an empty TREES-USE-ID sub-TLV, or RB2 does not
>> send any TREES-USE-ID sub-TLV at all?

Whose j are you talking about, RB2's j or the j of the RBridge holding
the nickname that is highest priority to be a tree root? There is no
reason for RB2 to waste LSP space by sending out a Trees Used
Identifiers sub-TLV if it might use any of the trees being computed
for the campus. I also don't see any reason for it to send out an
empty Trees Used Identifiers sub-TLV. Neither provides other RBridges
with any information.

>> If j >= k and no tree in j intersects k, all j trees are ignored.  Does
>> this imply neighbors should not expect dTree traffic from RB2?

No. For the campus to work correctly, it is normally necessary for
every RBridge to be able to send on a distribution tree. To the extent
that the Trees Used Identifiers sub-TLV for an RBridge lists trees not
being calculated for a campus, those entries are ignored. If all
entries are ignored, it still uses a number of trees determined by the
Number of Trees to Use entry in its Trees sub-TLV and the number of
trees being computed for the campus.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]