Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)
RFC 9183

Thank you for the work on this document. With no previous knowledge of TRILL, I scanned the document for ART issues and did not find any. The only comment I have is the one Alvaro already brought up: I would have much preferred if the example was split from the general specification behaviour, and would encourage the authors to rephrase the text accordingly.

Francesca

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.1. , paragraph 8, nit:
-       reamins 3.) Also RB2 learns that S is attached to nickname 27 in
-          -
+       remains 3.) Also RB2 learns that S is attached to nickname 27 in
+         +

Section 3.1. , paragraph 3, nit:
> ose the egress nickname remains 3.) Also RB2 learns that S is attached to ni
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Also".

Section 3.2. , paragraph 2, nit:
> for the multi-destination packet. For a unknown-unicast packet, if the DBRB h
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2. , paragraph 4, nit:
> e of the area {2,20}, RB2 must not forwarded the packet into this area. - The
>                                    ^^^^^^^^^
The modal verb "must" requires the verb's base form.

Section 3.2. , paragraph 10, nit:
> will see one source MAC address flip flopping among multiple ingress RBridge
>                                 ^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

These URLs in the document can probably be converted to HTTPS:
 * http://www.painless-security.com

Thanks for the clearly written document -- I was able to follow it with no background in the subject.

(3.2) "However, such kind of implementations are
   out the scope of this document. By default, the border RBridge with
   the smallest nickname, considered as an unsigned integer, is elected
   DBRB."

This default seems suboptimal, as the lowest value nickname will get all the traffic. Perhaps some sort of xor with flow-based entropy (e.g. the source and destination MAC) would be a better choice here?

(4.1) Relatedly,
"Note that the value of the destination MAC
   address SHOULD be excluded from the input of this pseudorandom
   algorithm, otherwise the egress RBridge will see one source MAC
   address flip flopping among multiple ingress RBridges."

I have thought about this for a while and cannot understand this assertion. Why is it a problem for an RBridge to route different flows to different RBridges if the intent is to load balance?

Section 1:

* "Informational [RFC8243] is an educational document ..." -- I suggest removing "Informational", or replacing it with the actual title of that RFC.

Thank you to Samuel Weiler for the SECDIR review.

Thanks for the efforts on this specification. 

I would like to echo what Benjamin Kaduk had already said - I doubt the market demand of this technology even if this specification solves some tidentified TRILL issues as mentioned in the shepherd write up.

I think the section 3.2 has been a bit confusing and my IESG colleagues have already covered them - like "MUST agree
on a pseudorandom algorithm...".

I am a bit struggling with the below procedure though -

    The packet is flooded on the Level 2 tree to reach both RB3 and
      RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will
      drop the packet.

If RB3 is already selected then why do we need to flood the tree and bother sending the packet to RB30? Is the packet send just because it is a multicast packet? Why can't it switch to unicast mode?  I think I am missing something there in the description.

I would also suggest to put Appendix A in the context of the main text i.e. refer from where this is relavent.

(1) The specification of the forwarding is done by using normative language while presenting an "illustrative example" (§3).  While the example is thorough, this way of specifying behavior is not ideal and, from my point of view, can result in confusion and underspecification.

Please remove the normative language from the example and include a section where the behavior is clearly and generally specified (i.e., not specific to the example). Then, the example can, as needed, refer to the specification section.



(2) §3.2 -- the wording here is confusing:

   ...     All border RBridges of an area MUST agree on a pseudorandom
   algorithm as the tie-breaker to locally determine the DBRB. The same
   pseudorandom algorithm will be reused in Section 4 for the purpose of
   load balancing. It's also possible to implement a certain election
   protocol to elect the DBRB. However, such kind of implementations are
   out the scope of this document. By default, the border RBridge with
   the smallest nickname, considered as an unsigned integer, is elected
   DBRB.

The requirement to "agree on a pseudorandom algorithm" sounds misleading to me (pointing to the "same pseudorandom algorithm" used later) because a default is mentioned later.

Suggestion>
   By default, the border RBridge with the smallest nickname, considered 
   as an unsigned integer, is elected DBRB.  All border RBridges of an 
   area MUST agree on the mechanism used to determine the DBRB locally.  
   The use of an alternative is possible, but out of the scope of this 
   document; one such mechanism is used in Section 4 for load balancing.

[Note that even though I'm suggesting normative text in §3, see my point above about putting the specification separate from the example.]


(3) §4.1: "RBridge MAY select one area nickname"  This selection is needed to achieve per-flow load balancing, so it is not clear to me why the action is optional.

§4.2 uses the same phrase but adds a recommended action ("SHOULD choose...").  Is the action in this case recommended or optional?


(4) The Introduction says that "the nickname of an area border RBridge is used in both Level 1 (L1) and Level 2 (L2). No additional nicknames are assigned to represent L1 areas as such."  I take that to mean that there is a single nickname used for both L1 and L2.  Is that the right interpretation?

If so, then I am confused by §6 not requiring a single nickname: "RB1 SHOULD use a single area nickname for all these areas."

What am I missing?  When is it ok not to use a single nickname?


(5) Should there be a reference to the appendix form the main text?

As a general remark, it seems that the use of the set of border
nicknames to designate an L1 area means that for a degenerate case where
there are exactly two L1 areas and the L2 area consists of all the border
RBridges, we don't actually distinguish the L1 areas and so the setup is
essentially degenerate with a non-multilevel TRILL.  This doesn't seem
problematic, though, and once the L2 topology becomes more complex
(while remaining connected), uniqueness of L1 area identifiers seems
guaranteed.

It also feels a little like this draft is being progressed for sake of
completeness rather than due to specific demand -- the shepherd writeup
doesn't convey much sense of market demand (rather, it expresses a
desire from the WG to press ahead to try to get traction in the market,
even though there is IPR disclosed), and the history of the draft
includes two periods of expiration and a few years of only minimal
revision at the 6-month expiration boundary, that doesn't indicate much
urgency to complete it.  That said, the data I have at the moment isn't
really strong enough to push me over to balloting Abstain instead of No
Objection.

Section 3.1

   -  RB3, when forwarding into area {3,30}, replaces the egress
      nickname in the TRILL header with RB44's nickname (44). (The

I strongly suggest spending a few words to reiterate how RB3 knows to
replace 3 with 44 in this scenario.  (I.e., looking up based on D from
the packet contents.)

Section 3.2

           All border RBridges of an area MUST agree on a pseudorandom
   algorithm as the tie-breaker to locally determine the DBRB. The same
   pseudorandom algorithm will be reused in Section 4 for the purpose of
   load balancing. It's also possible to implement a certain election
   protocol to elect the DBRB. However, such kind of implementations are
   out the scope of this document. By default, the border RBridge with
   the smallest nickname, considered as an unsigned integer, is
   elected
   DBRB.

(Editorial) It seems a little weird to me to write this as "MUST agree
on a pseudorandom algorithm ... oh but you could use leader election
instead as well, we just don't say how to" -- the "MUST" requirement
doesn't seem to match up with the actual requirement for correct
operation.  I tried to shuffle things around to make the actual "MUST"
requirement match up, as follows, though I'm not fully confident that my
proposal is actually correct...
NEW:

All border RBridges of an area MUST agree on a procedure for
determining the DBRB for the area.  This document assumes that the
border RBridge with smallest nickname (considered as an unsigned
integer) is elected DBRB, and that there is an agreed pseudo-random
algorithm as a tie-breaker (and reuses that algorithm in Section 4
for the purpose of load balancing), but that does not preclude the
use of leader-election or similar procedures.


   -  RB3, when forwarding into area {3,30}, replaces the egress
      nickname in the TRILL header with the root RBridge nickname of a
      distribution tree of L1 area {3,30} say 30. (Here, the ingress
      nickname MAY be replaced with a different area nickname selected
      from {2,20}, the set of border RBridges to the ingress area, as
      specified in Section 4.) Now suppose that RB27 has learned the
      location of D (attached to nickname 3), but RB3 does not know
      where D is. In that case, RB3 must turn the packet into a multi-
      destination packet and floods it on the distribution tree of L1
      area {3,30}.

I think either there's a missing paragraph break here, or we need to
s/RB27/RB3/ -- RB27 is attached to S, but this part of the procedure is
discussing how RB3 is performing level transition to inject the packet
into area {3,30}.

   -  RB30, will receive the packet flooded on the L1 tree by RB3. It is
      important that RB30 does not transition this packet back to L2.
      RB30 should also examine the ingress nickname of this packet. If
      this nickname is found to be an L2 border RBridge nickname, RB30
      must not transition the packet back to L2.

The way this condition is written ("to be an L2 border RBridge
nickname", with no restriction to the area in which it's received) seems
to imply an assumption that any given border RBridge is in exactly one
level 1 area.  Since §6 of this document says that a given border
RBridge can connect multiple L1 areas, I think we should examine more
carefully the situation here when a given border RBridge uses multiple
nicknames for different L1 areas.  As written, this procedure might
result in failing to flood some packets to L2 at all.

Section 6

   RBridge's nickname.  For a multicast packet: either RB1 is not the
   DBRB and RB1 will not transition the packet or RB1 is the DBRB. If
   RB1 is the DBRB, RB1 follows the following rules:

We write "the DBRB" as if there is a single distinguished one.  But when
there are multiple L1 areas in play, IIUC each area can have a distinct
DBRB.  Should we specify which area RB1 needs to be the DBRB in in order
to trigger these procedures (or whether it must do so if it is a DBRB in
*any* area)?

      dropped by RB1. It recognizes such packets by their ingress
      nickname being the nickname of one of the border RBridges of an L1
      area to which the receiving border RBridge is attached.

Similarly, if RB1 is not the DBRB for an area, the earlier requirement
to drop draffic from L2 and not pass it to that area, regardless of the
ingress nickname in use, seems to take priority.  So perhaps this should
be "of an L1 area for which the receiving border RBridge is the DBRB"?

Section 8

Is there anything useful to say about the transient behavior as
information about a partition/repair propagates to the border RBridges
of the area?

   If an L1 Border RBridge Nickname is configured at an RBridge and that
   [...]
   nickname multilevel do not support the configuration of an L2 Border
   RBridge Nickname.  [...]

Just to confirm, the distinction between "L1 Border RBridge Nickname"
and "L2 Border RBridge Nickname" is correct and as intended?  I think I
see one or two other instances of the "L2" form in the document, but
this one leaves me most uncertain of the group.

   If there are multiple border RBridges between an L1 area and L2 and
   one or more of them only support or are only configured for unique
   nickname multilevel ([RFC8397]), any of these border RBridges that
   are configured to used single nickname multilevel as specified in
   this document MUST support [RFC8397] and fall back to behaving as a
   unique nickname border RBridge for that L1 area.  [...]

Since this condition is predicated on the deployment environment, not
the local implementation, it seems to be a de facto requirement on all
implementations of this document to also support RFC 8397 and the
fallback.  Perhaps it's better to frame it that way.

I think we should also say something about how an implementation will
detect that there are other border RBridges in a given area that are
using unique nickname multilevel.

Section 9

   The newly defined TRILL APPsub-TLVs in Section 5 are transported in
   IS-IS PDUs whose authenticity can be enforced using regular IS-IS
   security mechanism [IS-IS] [RFC5310]. This document raises no new
   security issues for IS-IS.

Thanks for mentioning that IS-IS has a mechanism for authenticating PDUs
(and the corresponding implication that it's not the default behavior).
That said, I'm not sure that "raises no new security issues" is quite
correct, and would propose to adopt a formulation similar to what RFC
8397 uses.  E.g., "malicious devices may fake the [sub-TLVs] to [attract
traffic, partition areas, induce excessive state on L2 RBridges, etc.].
For this reason, RBridges SHOULD be configured to use the IS-IS
Authenticaiton TLV (10) in the IS-IS PDUs, particularly those containing
[sub-TLVs], so that IS-IS security [RFC5310] can be used to authenticate
those PDUs and discard them if they are forged."

   Using a variation of aggregated nicknames, and the resulting possible
   duplication of nicknames between areas, increases the possibility of
   a TRILL Data packet being delivered to the wrong egress RBridge if

Increases compared to what baseline?

   areas are unexpectedly merged. However, in many cases the data would
   be discarded at that egress RBridge because it would not match a
   known end station data label/MAC address.

Is that true for broadcast/multicast or just unicast?

Section 11.2

It seems that [IS-IS] ought to be a normative reference.

NITS

Section 4.1, 4.2

   nickname. The selection is simply based on a pseudorandom algorithm
   as defined in Section 5.3 of [RFC7357]. With the random ingress

Pedantically, the referenced document gives an example of a PRF, but
does not definitively define "a pseudorandom algorithm".  So "described"
or "discussed" might be more appropriate than "defined".

Section 8

   Other than the manageability considerations specified above, the
   manageability specifications in [RFC6325] still apply.

Is this an "other than" or an "in addition to"?