I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-teas-interconnected-te-info-exchange-05.txt Reviewer: Brian Carpenter Review Date: 2016-05-04 IETF LC End Date: 2016-05-10 IESG Telechat date: Summary: Almost ready -------- Major issues: ------------- > 5. Building on Existing Protocols I find it hard to read the introduction to this section and understand why the draft is proposed for BCP rather than Informational. For example, > It is recognized, however, that existing protocols are unlikely to be > immediately suitable to this problem space without some protocol > extensions. And again: > 5.4. Notes on a Solution ... > This section is not intended to be prescriptive or dictate the > protocol solutions that may be used to satisfy the architecture > described in this document, but it does show how the existing > protocols listed in the previous sections can be combined to provide > a solution with only minor modifications. And I could give more examples from: > 9. Scoping Future Work Note, I think this is very valuable work: it just doesn't describe a normative current practice (and it has no normative references as a result). Minor issues: ------------- > 1. Introduction ... > Such networks > are often referred to as Domains [RFC4726] and we adopt that > definition in this document: viz. > > For the purposes of this document, a domain is considered to be any > collection of network elements within a common sphere of address > management or path computational responsibility. Examples of such > domains include IGP areas and Autonomous Systems. Section 1.1.4. (Domain) repeats the definition in different words. I think it would be better to fold the text from the Introduction into 1.1.4. > 2.2. Client-Server Networks It may be considered a term of art in TE, but I found the phrase "server network" very confusing at first. In my world, it means "a network containing servers" but here it appears to mean "underlay network" or possibly "service network". Anyway, if you want to use this phrase, I suggest defining it precisely before using it. Also, the text switches to "server domain" and uses "server layer". Then in Figs 4, 5 and 6 the server domain has become "core domain". This terminology is all a bit inconsistent. > 4.4. Requirements for Advertising Links and Nodes ... > This requires a routing protocol running between the nodes in the > abstraction layer network. Note that this routing information > exchange could be piggy-backed on an existing routing protocol > instance, or use a new instance (or even a new protocol). It isn't obvious to me that it could be piggy-backed on an existing instance in the general case; wouldn't that sometimes lead to duplicate or ambiguous routes? A sentence in section 4.5 seems to suggest that ambiguity is very possible: > That is, one address may mean one thing in the > client network, yet the same address may have a different meaning in > the abstraction layer network or the server network. Address mapping plus piggy-backed routing seems like a recipe for disaster. Nits ---- > Figure 16 : A Network Comprising Three Peer Networks There's a missing | on node B2 > 10.3. Managing Interactions of Abstraction Layer and Server Networks ... > The abstraction layer network needs a mechanism to tell the server > This mechanism could also include the ability to request additional > connectivity from the server layer, ... The first sentence of this paragraph is truncated. > 12. Security Considerations ... > Thus, the mechanisms in this document for > inter-domain exchange of control plane messages and information > naturally raise additional questions of security. > > In this context, additional security considerations arising from this > document relate to the exchange of control plane information between > domains. Those two sentences seem to say exactly the same thing.