Hi Martin, Thanks for your review. See response below.
On Mon, May 30, 2016 at 6:55 AM, Martin Vigoureux <[email protected]> wrote: > Hi, > > I have been selected as the Routing Directorate QA reviewer for this draft. > > Document: draft-ietf-trill-multi-topology-01 > Reviewer: Martin Vigoureux > Review Date: May 20, 2016 > Intended Status: Proposed Standard > > The draft is both quite well written and well structured such that I did not > have to go back and forth in the doc. > As a result also, I have only very few editorial comments and questions. Thanks. > Section 1 > If routers in the network do not agree on the topology > classification of packets or links, persistent routing loops can > occur. > It is not clear if that could happen in mt-trill or if mt-trill solves that. Multi-topology TRILL doesn't specify what kind of traffic should be classified as being in what topology. Indeed, the traffic classified as being in topology T can be arbitrarily different in different parts of the TRILL campus if there are disjoint instances of a topology T. This classification needs to be decided and configuration by network management. This is consistent with how IS-IS multi-topology is used in other applications. So, yes, routing loops can be caused by misconfiguring IS-IS mutli-topology is TRILL or IP. > Section 1.1 goes beyond defining acronyms but specifies some pieces of > technology: > By implication, an "FGL TRILL switch" does not support MT. > An MT TRILL switch MUST support FGL in the sense that it MUST be FGL > safe [RFC7172]. > Is this the right place to do this? By the way, this requirement is stated > further down in the doc. There is a similar sentence at the end of the entry for "VL". The idea is that the capabilities of an "MT TRILL switch" are a superset of the capabilities of an "FGL TRILL switch" which are in turn a superset of the capabilities of a "VL TRILL switch". This is intended to simplify things by having, at least to some extent, a linear sequence of added capabilities rather than the cross product of the presence/absence of each added capability. Sort of MT > FLG > VL. I don't see anything wrong with having these statements here as well as further down in the document. > Section 2.2 > s/and received/and receive/ OK. > Section 2.4 > Commonly, the topology of a TRILL Data packet is commonly > One superfluous occurrence of "commonly" OK. I think deleting the initial "Commonly, " would be a good solution. So the sentence would start "The topology of a TRILL Data packet is commonly ..." > Section 2.4.1 > It would be better to write "2/3" as "2 and 3" OK. > A TRILL switch advertising in a Hello on Port P support for topology > T but not advertising in those Hellos that it requires explicit > topology labeling is assumed to have the ability and configuration to > correctly classify TRILL Data packets into topology T by examination > of those TRILL Data packets and/or by using the fact that they are > arriving at port P. > Does this mean that Value 1 is default behaviour? The first paragraph of Section 2.4.1 makes it clear that the default value of the two bit field in the Port Capabilities sub-TLV is zero and this is also the value assumed if that sub-TLV is not present. I can clarify the statement you quote above but it means exactly what it says. "not advertising in those Hellos that it requires explicit topology labeling" means it is not advertising a value of 2 or 3 in the Explicit Topology capability field. The sentence you quote is already effectively included in the entry text for Explicit Topology capability field value 1. Probably the sentence you quote should be deleted and the applicable portion of should also merged into the text for Explicit Topology capability field value 0. That seems like the best way to reduce confusion. > Section 3.4.1 > s/are determine/are determined/ OK. > Section 7 > s/some links was more/some links were more/ OK. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
