Hi Martin, draft-ietf-trill-multi-topology-02, just posted, incorprates the resolutions of your comments and has a few other editorial improvements.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Fri, Jun 3, 2016 at 6:07 PM, Donald Eastlake <[email protected]> wrote: > Hi Martin, > > On Fri, Jun 3, 2016 at 6:15 AM, Martin Vigoureux > <[email protected]> wrote: >> Hi Donald, >> >> thank you. >> please see in-line for the pending points. >> >> -m >> >> Le 31/05/2016 20:11, Donald Eastlake a écrit : >>> >>> 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. >> >> Maybe it is worth clarifying that point then. > > OK. > >>>> 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. >> >> I did not say it was wrong. I find surprising to specify technology elements >> in a section the objective of which is to define acronyms. >> But I can live with it. > > OK. > >>>> 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. >> >> yes, I think this is where the misunderstanding came from. > > OK, I delete that sentence and move the relevant part of it to the > entry to field value 0. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] > >>>> 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
