[trill] Alvaro Retana's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)
"Alvaro Retana" <email@example.com> Wed, 18 January 2017 18:41 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4ED5129401; Wed, 18 Jan 2017 10:41:24 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: "Alvaro Retana" <firstname.lastname@example.org>
To: "The IESG" <email@example.com>
Date: Wed, 18 Jan 2017 10:41:24 -0800
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
Subject: [trill] Alvaro Retana's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 18:41:31 -0000
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:  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...  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.  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?
- [trill] Alvaro Retana's No Objection on draft-iet… Alvaro Retana