Early Review of draft-ietf-teas-interconnected-te-info-exchange-04
review-ietf-teas-interconnected-te-info-exchange-04-genart-early-carpenter-2016-05-04-00

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.