Subject: [trill] DTree Questions Regarding Router Capability TLV

From: Arnel Lim <[email-masked]>
Date: Mon, 17 Dec 2012 13:50:09 -0800

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"

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."

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."

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.

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?

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?

"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."

When the RFC refers to RB2's LSP it is referring to the TREES-US-ID sub-TLV, correct?
The j potential ingress trees this section talks about would be manually configured by the user, correct?

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?

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?

________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.

---

From: Ayan Banerjee <[email-masked]>
Date: Mon, 17 Dec 2012 14:13:28 -0800

Please see in-line.

Thanks,
Ayan

On Mon, Dec 17, 2012 at 1:50 PM, Arnel Lim <[email-masked]> 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.
>

> **
>
> 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.
>
> 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.
>
> ** **
>
> 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.
>

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.”****
>
> ** **
>
> When the RFC refers to *RB2’s LSP* it is referring to the TREES-US-ID
> sub-TLV, correct?****
>
> The j potential ingress trees this section talks about would be manually
> configured by the user, correct?****
>
> ** **
>
> 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?****
>
> ** **
>
> 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? ****
>
> ** **
>
> ------------------------------
> DISCLAIMER:
> This e-mail and any attachments to it may contain confidential and
> proprietary material and is solely for the use of the intended recipient.
> Any review, use, disclosure, distribution or copying of this transmittal is
> prohibited except by or on behalf of the intended recipient. If you have
> received this transmittal in error, please notify the sender and destroy
> this e-mail and any attachments and all copies, whether electronic or
> printed.
>
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>
>

---

From: Thomas Narten <[email-masked]>
Date: Tue, 18 Dec 2012 10:09:01 -0500

> > 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.

So, are you saying that if RB doesn't announce the TLV, all other RBs
must assume that RB2 can/will ingress multi-destination packets?

If so, I understand the reasoning for why the RB should effectively
announce a TLV saying "I'm not ingressing anything". But does the spec
actually say that transit RBs SHOULD/MUST advertise a TLV with a
(presumably) empty list in this case?

Thomas

---

From: Ayan Banerjee <[email-masked]>
Date: Tue, 18 Dec 2012 09:56:47 -0800

Please see in-line.

Thanks,
Ayan

On Tue, Dec 18, 2012 at 7:09 AM, Thomas Narten <[email-masked]> wrote:

> [Ayan] Probably not. However, I would consider the presence of the
statement to be an optimization that would be nice to have - so even if it
is there, it will probably be a "SHOULD" and not a "MUST".

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 18 Dec 2012 23:46:09 -0500

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 <[email-masked]> 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
>> validation.
>> sub-TLV, correct?
>> root" priority”

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.

>> receive TREES-RT-ID sub-TLV.  This implies it's *NOT* mandatory for highest
>> priority Rbridge to send TREES-RT-ID sub-TLV, correct?
>>
>> below, then the k highest priority trees are the trees that will be computed
>> by all RBridges.”
>>
>> 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.
>>
>> ingresses a multi-destination packet.”
>>

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,

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.

>> the k  highest priority trees in the TREES-USE-ID sub-TLV. Correct?
>>
>> LSP examine the intersection of j with k?
>>
>> 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?
>>

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

>> 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.
>>
>> 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).

>> 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.

>> 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.

>> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 19 Dec 2012 00:01:34 -0500

Hi Thomas,

> must assume that RB2 can/will ingress multi-destination packets?

Yes, if an RBridge chooses to not list specific trees it might use,
then the trees it might use are determined in a default way.

> (presumably) empty list in this case?

An RBridge "not ingressing anything" can't, for example, have an SNMP
stack. While theoretically possible, will such a thing occur in the
real world?

The Number of Trees to Use field in the Trees sub-TLV says how many
trees an RBridge intends to use. And, as per RFC 6325, if that field
is zero, it is interpreted as saying that the RBridge can use any of
the trees being calculated for the campus. So there is no way for an
RBridge to say it is using zero distribution trees.

Thanks,
Donald