[trill] Alvaro Retana's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)

["Alvaro Retana" <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-directory-assist-mechanisms-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I would like to see some more information related to the overall
operation of the network, including guidance on how/when to use different
mechanisms and their location.  Specifically, I think this document
should include more information in these cases:

[1] Server Learning and Advertisement of information in ESADI [RFC7357]
using the Reachable MAC Addresses TLV [RFC6165].

I don't think it is explicit in the document, but I'm assuming that the
Servers (for both Push and Pull) learn using the mechanisms in Section
4.8.1. (Learning End-Station Addresses) of RFC6325.  One of those
mechanisms is to use ESADI...Section 2.5 (Additional Push Details)
says:

   TRILL switches, whether or not they are a Push Directory server, MAY
   continue to advertise any locally learned MAC attachment information
   in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165].
   However, if a Data Label is being served by complete Push Directory
   servers, advertising such locally learned MAC attachment generally
   SHOULD NOT be done as it would not add anything and would just waste
   bandwidth and ESADI link state space. An exception might be when a
   TRILL switch learns local MAC connectivity and that information
   appears to be missing from the directory mapping.

It seems to me that a switch advertising information in ESADI using the
Reachable MAC Addresses TLV is independent of whether Push or Pull is
being used on the network (or for a specific Data Label), so I think my
questions/comments below apply to both.

I understand why using the information in the Reachable MAC Addresses TLV
may be redundant, but as the text points out, there are cases where it
may be a good thing.  I would like to see guidelines or suggestions on
the use of "traditional" ESADI learning (RFC7357) in Section 4.
(Directory Use Strategies and Push-Pull Hybrids).  This section already
talks about what a TRILL switch may do if it doesn't have complete
information, but it doesn't talk about what a Directory Server could
do.

Related to the above, if ESADI [RFC7357] using the Reachable MAC
Addresses TLV [RFC6165] does't really add anything to the Push Directory
service, then it seems to me that they would be equivalent (the outcome
is the same) -- when should one be used over the other?  Are there cases
where the centralized service may not scale and is better to adopt a
distributed strategy?  It seems to me than the options in Section 4.
(Directory Use Strategies and Push-Pull Hybrids) may not be just between
Pull and Push...


[2] Location and Priority of Push Directory Servers

Section 2.2 (Push Directory Servers) talks about PushDirPriority, but
there are no guidelines as to how it should be set by an operator.  I
suspect that a higher priority may want to be assigned to Directory
Servers with a higher density of connected high-use stations...or maybe
not, which is why I would like you to provide some guidance.


[3] Location and Number of Requests for Pull Directory Servers

Section 3.(Pull Model Directory Assistance Mechanisms) reads:

   If multiple data reachable TRILL switches indicate in the link state
   database that they are Pull Directory Servers for a particular Data
   Label, pull requests can be sent to any one or more of them but it
is
   RECOMMENDED that pull requests be preferentially sent to the server
   or servers that are lowest cost from the requesting TRILL switch.

Are there guidelines related to the location (and number) of these
servers?

When would a switch not send a request to the server(s) with the lowest
cost?  IOW, why "RECOMMENDED" and not "MUST"?

How many servers should the request be sent to?  For the Push case, a
default of 2 copies is specified -- should 2 requests be enough?  Are
there cases where more are needed?