Hi all, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. In summary, I think this document is ready with nits (largely editorial). The main point of the document is to allow for source nodes to request path diversity in new LSPs being created, in the case where the source node does not have full knowledge of the relevant topology. (The case where the source node does have such knowledge is already handled via eXclude Route Objects and Explicit Exclusion Route Subobjects.) My understanding is that the main reason to request such path diversity is to introduce redundancy and improve the system functionality in the case of (localized) outages, but this does not really seem to be emphasized in the Introduction -- maybe it should? Path diversity is effected by the use of a "reference path" that already exists between a source and destination, and requesting that the new path is diverse with respect to that reference path. Similarly to the above, it may be helpful to explictly introduce the notion of a reference path instead of introducing it implicitly, in passing. The security considerations largely refer to/include by reference RFCs 5920, 2205, 3209, 3473, and 4874, though not all of these are listed as normative references. (I'm not sure whether there is a convention for such cases.) Of those, RFC 3473 also refers to RFC 2747, and there may (or may not) be value in flattening the chain of references by explicitly mentioning RFC 2747 here as well. To a large extent, those references do seem to cover the relevant security considerations for this document, as there is little that is conceptually new in this document. The final paragraph of the security considerations calls out an exception to the rule from RFC 4874 that XRO could/should be removed from the Path message to avoid leaking internal information, because the diversity subobject needs to be preserved in order to perform its function. One could potentially claim that even the diversity subobject is leaking some information about the internal network in some cases, but since the "leaked" information is essentially an opaque identifier, the usual case would generally be that it is worth the minor leak in order to obtain path diversity, as this document states. Whenever new identifiers are issued, the corresponding privacy considerations should also be considered. Given that the role of a core network is probably (?) considered to be just transit, I am not very concerned about path identifiers leaking information (or correlations) about what physical path a given set of data traverses. I suppose one could consider potential security/privacy issues inherent in path diversity as well, which seems mostly limited to the case where only a subset of nodes/links are compromised in some fashion (monitored or subject to traffic injection). In that case, someone knowing that a reference path is not subject to attack could try to create a new (diverse) path in an attempt to have the new path traverse the compromised equipment. But that seems quite far-fetched as an attack, especially in the context of the RFC 5920 model where the core is considered to be equally/globally trusted. I'm also possibly confused at the requirements introduced in section 2.3 (page 19) for the node performing path computation to take action when a previously unknown (excluded) path becomes known, or when LSPs (?) change so that a requested exclusion is no longer satisfied. This seems to require that the PCE store all XRO subobjects along with the path state, so as to be able to do this processing upon (all!) LSP changes. Is the extra storage and/or computation likely to be a significant burden on the PCE that might lead to resource-exhaustion and denial of service? There is also some minor risk in section 1.3 (page 8) where PAS assignment and distribution is left as out of scope for this document -- certain assignment schemes could leak information or allow outside parties to guess "new" values that would be treated as valid by the core network. But it's hard to see this leading to a concrete attack, especially when the PAS number space is only 32 bits wide. I'll mention a few of the more significant editorial issues here, and defer the really nitty-gritty stuff to a later message with narrower scope, in the interest of expediency (as this document is scheduled for this week's telechat). It may be worth double-checking that acronyms not listed as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt are expanded at first use; UNI-N and RRO are a couple that I noticed while reviewing. In the abstract: [...] Three different mechanisms are supported how LSP diversity can be accomplished in the provider or core network: the signaled diversity type, indicates whether diversity is based on client, path computation engine (PCE), or network assigned identifiers. am I correct to infer that "indicates whether diversity is based on client" is supposed to clarify what "signaled diversity type" means, so that the rest of the sentence is a three-element list corresponding to the three diversity identifiers introduced by this document? If so, it's probably better to put it inside parentheses than offset by commas, or even to reword it entirely to just be something like "a client-initiated method". The next sentence could also be made smoother, something about assuming that LSPs are created at a slow rate and exist for a long time, so that it is reasonable to assume that a given (reference) path currently existing, with a well-known identifier, will continue to exist and can be used as a reference when creating the new path. At the top of page 4, "exemplified" should probably be something like "illustrated" (this particular diagram is not really the epitome of path exclusion). In page 4, a "single-homed UNI" is referred to. My understanding was that the UNI was akin to an edge in the topology graph, and that "single-homed" would more commonly apply to an EN (but maybe my understanding is incorrect). Page 5, first complete paragraph, does "across the UNI boundary" just mean in the CN to EN direction? At the end of section 1 (just before section 1.1), the listing "client-initiated, allocated by the (core) network or managed by a PCE" should probably have the last two swapped, to match the ordering used in the rest of the document. At the bottom of page 5 (last line), should "LSP IS = L1" be "LSP ID = L2" (S-->D and 1-->2)? Also, the previous line has "LSP-IDENTIFIER12" which probably is meant to just be the '2'. Page 8, third paragraph, "included for exclusion" is a little awkward of a phrasing; "[i]f a PAS identifier is used as an exclusion identifier" might be better. Page 11 just lists the three diversity identifier types created by this document; should there be consideration of (text for) how to allocate additional types in the future? The string "IPv4/ IPv6" appears many times in the text; I believe it's more conventionally written without the space, as "IPv4/IPv6". Crossing from page 16 to page 16, "sends [...] request from ingress node to egress node including diversity constraints to a PCE" is potentially confusing about what is being sent where, since it's the request for a path [from ingress node to egress node] that is sent to the PCE. So, "path computation request for a path from ingress node to egress node" might be better, or even reordering things more drastically. The last two sentences of the Security Considerations are a little hard to read; I might reword them, potentially as: However, when the diversity subobjects specified in this document are used, removing at the administrative boundary an XRO containing these diversity subobjects would result in the request for diversity being dropped at the boundary, and path computation would be unlikely to produce the requested divers path. As such, diversity subobjects MUST be retained in an XRO crossing an administrative boundary, even if other subobjects are removed. -Ben