Re: [Gen-art] Gen-ART Last Call review of draft-ietf-teas-interconnected-te-info-exchange-05

[Brian E Carpenter <[e-mail]>]

Hi Adrian,

Just a few comebacks in line:

On 04/05/2016 23:05, Adrian Farrel wrote:
> Hi Brian,
> 
> Thanks for the time.

Actually I read it with some interest, as I was wondering whether it
also provides a use case for the Anima WG. It probably could.

> 
>> 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. 
> 
> I will punt this question direct to the responsible AD since the authors brought the document forward as Standards Track and were "persuaded" by the WG chairs and responsible AD that it was a BCP as written. 
> 
> The only hint I will offer is that the authors would be grumpy about changing the content of the document to fit the publication track. Let's choose the track to fit the document :-)

Understood. The IETF has never been very comfortable at accommodating architecture
documents. But I don't really think the text would need changing, except for 3 words
in the Abstract. The document stands on its own merits. Anyway, that's an IESG question.

> <snip>
> 
> [except to note that the presence of normative references has nothing to do with whether a document is itself normative!]
>  
>> 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.
> 
> I disagree.
> I believe that an introduction needs to be stand-alone text without requiring reference to a terminology section that has not yet been read.
> 
> The text in the Introduction is a direct quote and cannot be modified.
> The text in 1.1.4 is as near as possible to being a copy within the rules of abbreviation expansion.
> Effectively the two definitions are identical.

Yes, but I had to re-read them both to be sure of that. Actually I faced exactly
this problem recently in a draft of my own and fixed it with a forward reference.
Up to you, this is just something that I found a bit awkward to read.

>>> 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.
> 
> It is certainly a term of art in multi-layered networks. I did not do a comprehensive search, but found it in RFCs from 2005. You may also find it used a lot in the ITU-T where they have some experience of transport networks (hoping that in your world a transport network is not a TCP network :-)

Well, yes, I came across that particular ITU-T heresy many years ago.

> 
> I think that you are saying that the description at the start of Section 2.2 (that provides as a starting point the client-server relationship between networks) is not enough. I think we can manage a very brief definition for you to go in Section 1.1. Probably something like...
> 
> Server Network
> 
> A Server Network is a network that provides connectivity for another network (the Client Network) in a client-server relationship. A Server Network is sometimes referred to as an underlay network.
> 
> Client Network
> 
> A Client Network is a network that uses the connectivity provided by a Server Network. A Client Network is sometimes referred to as an overlay network.

That would be perfect.

> 
>> 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.
> 
> Yes, this is sloppy chat. Will scrub it. Ditto "client".
> 
>>> 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.
> 
> I think this is resolved by the insertion of "...(subject to different switching capabilities applying to the links in the different networks, or to adequate address space separation)..." in the quoted text from 4.4 after "... could be piggy-backed on an existing routing protocol instance".

Sure.

Thanks,
    Brian

> 
>> Nits
>> ----
>>
>>> Figure 16 : A Network Comprising Three Peer Networks
>>
>> There's a missing | on node B2
> 
> ack
> 
>>> 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.
> 
> good catch
> 
>>> 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.
> 
> We like to demonstrate how seriously we take security by saying everything twice.
> We like to demonstrate how seriously we take security by saying everything twice.
> 
> Once again, thanks for a very detailed reading.
> 
> Adrian
> 
>