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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 May 2016 17:25:53 +1200

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 4 May 2016 12:05:15 +0100

Hi Brian,

Thanks for the time.

> 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 :-)

<snip>

[except to note that the presence of normative references has nothing to do with whether a document is itself normative!]
 
> Minor issues:

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.

> 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 :-)

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.

> is all a bit inconsistent.

Yes, this is sloppy chat. Will scrub it. Ditto "client".

> Address mapping plus piggy-backed routing seems like a recipe

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".

> There's a missing | on node B2

ack

> The first sentence of this paragraph is truncated.

good catch

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 May 2016 08:06:07 +1200

Hi Adrian,

Just a few comebacks in line:

> 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.

> 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.

> 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.

> 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 exper…

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

> 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.

> 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 qu…

Sure.

Thanks,
    Brian

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 4 May 2016 23:02:18 +0000

Hi Brian,

Yes, much thanks for your careful read. I can understand your confusion on our chosen track as we (authors, chairs, myself) went back and forth on it though we debated if it should be standards track or BCP (or Applicability Statement).
https://mailarchive.ietf.org/arch/msg/teas/YEv-68nB0LwBCOa3PcJR970pYhg

Looking at your review, your question on why this is a BCP was based on a sentence in section 5 which says that existing protocols <to be immediately suitable> would need "some protocol extensions". Whereas in section 5.4, it says this document will show how the existing protocols can be combined to provide a solution with only minor modifications.

So putting these sentences together one concludes the solution requires minor modifications to the protocols. But the solution described in this document doesn't require any modifications to the protocols. The solution is based on abstracting information - section 6 uses abstraction combined with the 3rd model for GMPLS networks, same for section 7 and section 8.

The document was first proposed as standards track because it is a solution. After discussion, it was agreed it really is a BCP as it is describing the agreed best current approach for solving this problem, e.g. in section 6, it is using RFC6827's (RFC6827 is a Proposed Standard) exchange of information between different ASON architecture levels (not protocol exchanges). So it is either standards track or a BCP as it is the WG's best solution for this problem at this time.

To help the reader, I'd say section 6's and section 7's headers should be more clearly labelled "An Abstraction Solution for Optical Domains and Networks" and for section 7 "Abstraction in the User-to-Network Interface". And these titles will align better with Section 8 "Abstraction in L3VPN...".

Would that help?

Deborah

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, May 04, 2016 4:06 PM
To: [email-masked]; [email-masked]; 'General Area Review Team' <[email-masked]>
Subject: Re: Gen-ART Last Call review of draft-ietf-teas-interconnected-te-info-exchange-05

Hi Adrian,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 May 2016 12:48:12 +1200

Hi Deborah,

> To help the reader, I'd say section 6's and section 7's headers should be more clearly labelled "An Abstraction Solution for Optical Domains and Networks" and for section 7 "Abstraction in the User…

Yes. Basically it needs to be clear that the architecture can be 100%
implemented using current specifications, and that the possible extensions
are not required for this (and are therefore not really part of the core of
the BCP).

Regards
   Brian

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 May 2016 16:45:51 -0400

Thanks for the review, Brian.

I tend to agree with this:

> are not required for this (and are therefore not really part of the core of

Jari