Subject: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 10 May 2016 14:04:44 +0100

Hi,

I posted an update to this draft after the completion of IETF last call.

We received a GenART review from Brian Carpenter and a SecDir review from
Hilarie Orman. These gave rise to some changes and some email discussion.
(Stewart's RtgDir review was handled in -05 before IETF last call started.)

I believe we have closed down all points except one from Brian about whether the
content and precise wording is consistent with the document as a BCP. At the
moment I am reluctant to change the text to make it consistent with the chosen
publication track (especially since the authors originally proposed Standards
Track not BFP) and prefer to find the correct track for the current document. My
reasoning is two-fold:

- This is the document that we (the WG) wanted to publish. Changing the
   text to suit the publication track seems to be back-to-front.

- IESG review has a likelihood of changing the publication track again or
   wanting more changes to keep it as a BCP. I would prefer to see all of
   these changes in one batch rather than trickling them in. 

The Diff will show a few more changes than expected because the layout changed
so that figures don't fall on page breaks.

Cheers,
Adrian

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of
[email-masked]
> Sent: 10 May 2016 13:56
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange-
> 06.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Traffic Engineering Architecture and
Signaling of
> the IETF.
> 
>         Title           : Problem Statement and Architecture for Information
Exchange
> Between Interconnected Traffic Engineered Networks
>         Authors         : Adrian Farrel
>                           John Drake
>                           Nabil Bitar
>                           George Swallow
>                           Daniele Ceccarelli
>                           Xian Zhang
> 	Filename        : draft-ietf-teas-interconnected-te-info-exchange-06.txt
> 	Pages           : 61
> 	Date            : 2016-05-10
> 
> Abstract:
>    In Traffic Engineered (TE) systems, it is sometimes desirable to
>    establish an end-to-end TE path with a set of constraints (such as
>    bandwidth) across one or more network from a source to a destination.
>    TE information is the data relating to nodes and TE links that is
>    used in the process of selecting a TE path.  TE information is
>    usually only available within a network.  We call such a zone of
>    visibility of TE information a domain. An example of a domain may be
>    an IGP area or an Autonomous System.
> 
>    In order to determine the potential to establish a TE path through a
>    series of connected networks, it is necessary to have available a
>    certain amount of TE information about each network.  This need not
>    be the full set of TE information available within each network, but
>    does need to express the potential of providing TE connectivity. This
>    subset of TE information is called TE reachability information.
> 
>    This document sets out the problem statement for the exchange of TE
>    information between interconnected TE networks in support of end-to-
>    end TE path establishment and describes the best current practice
>    architecture to meet this problem statement.  For reasons that are
>    explained in the document, this work is limited to simple TE
>    constraints and information that determine TE reachability.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-
> exchange/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info-
> exchange-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Lou Berger <[email-masked]>
Date: Tue, 10 May 2016 09:44:41 -0400

Adrian, Authors,
    Thank you got all the hard work to get the document to this point. 
The end objective is almost here!

Can you recap exactly what change is being proposed to address Brian's
comment?

Thank you,
Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 10 May 2016 17:15:17 +0100

Brian (as the reviewer) and Deborah (as our AD) had an exchange of ideas.

Deborah summarised the issue as:
Section 5 and section 5.4 say that minor modifications to existing protocols
would be necessary to fully satisfy this architecture, but the status of BCP
implies that you can and do do things with existing tools.

Furthermore, Deborah claims "the solution described in this document doesn't
require any modifications to the protocols. "

Deborah proposed three changes...

1. Section 6 title change from "Applicability to Optical Domains and Networks"
to "An Abstraction Solution for Optical Domains and Networks" 
2. Section 7 title change from "Modeling the User-to-Network Interface" to
"Abstraction in the User-to-Network Interface"
3. Some rewording of section 5 to preclude additional protocol work to be
consistent with the concept of a BCP.

I am pushing back on these changes. Part of this is philosophical - an
architecture tells you how to build stuff and IMHO this can be normative. I
think that makes the document Standards Track, but whatever the result of that
discussion, I think it is fine for an architecture to point out that protocol
work is still needed.

But the main push-back is to be correct!

Sections 6 and 7 describe how the architecture fits the with specific network
deployments. While those sections describe how some protocols could be applied,
they are not a solution, they are an application of the architecture. They could
be re-titled "Applicability of The Architecture Described in This Document to
Optical Domains and Networks" and "Modeling the User-to-Network Interface Using
The Architecture Described in This Document" although those seem rather
long-winded.

Section 5 possibly does not go far enough as it is! It notes some relevant
protocol work that has not been completed, but it does not build a comprehensive
list. And it does that deliberately in order to not attempt to deliver or
prejudge a solution. Mentioning that BGP-LS does not (yet) have an RFC that
describes extensions for GMPLS networks is possibly over-reaching because no-one
has said that it is a requirement to use BGP-LS to export abstractions of
optical links. In any case, it would be wrong for this document to preclude
additional protocol work.

If all of that means that this is not a BCP, that's OK. It is what it is.
If it is still the opinion of our leaders (who have to support publication) that
this is not Standards Track, that's OK too.
We may end up as Informational.

However, there is zero value in us doing either of:
- Changing the document that we wanted to publish just to make it match a
particular publication track.
- Trying to second-guess the IESG. They may say BCP is OK as written. They might
ask us to make more changes even after the ones Deborah suggests.

The former is the tail wagging the dog.
The latter is whack-a-mole.

Cheers,
Adrian
> From: Lou Berger [mailto:[email-masked]]
> Sent: 10 May 2016 14:45
> To: [email-masked]; [email-masked]
> Cc: [email-masked];
> [email-masked]; Hilarie Orman
> Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange
> 
> Adrian, Authors,
> > Track not BFP) and prefer to find the correct track for the current
document.
> My
> >> Subject: [Teas] I-D Action:
draft-ietf-teas-interconnected-te-info-exchange-
> >> There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-
> 06

---

From: John E Drake <[email-masked]>
Date: Tue, 10 May 2016 17:51:33 +0000

Hi,

The logic behind changing from ST, which is what the WG approved, to BCP has always escaped me and I would be happy to go back to ST before sending it to the IESG.

What we are doing now is neither wagging dogs nor whacking moles, but rather wandering at random.

Yours Irrespectively,

John

> From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, May 10, 2016 12:15 PM
> To: 'Lou Berger'; [email-masked]
> [email-masked]
> Section 5 and section 5.4 say that minor modifications to existing protocols would be
> necessary to fully satisfy this architecture, but the status of BCP implies that you can and do
> do things with existing tools.
> 
> Furthermore, Deborah claims "the solution described in this document doesn't require any
> modifications to the protocols. "
> 
> 2. Section 7 title change from "Modeling the User-to-Network Interface" to "Abstraction in
> the User-to-Network Interface"
> 3. Some rewording of section 5 to preclude additional protocol work to be consistent with
> the concept of a BCP.
> 
> I am pushing back on these changes. Part of this is philosophical - an architecture tells you
> how to build stuff and IMHO this can be normative. I think that makes the document
> Standards Track, but whatever the result of that discussion, I think it is fine for an
> architecture to point out that protocol work is still needed.
> 
> Sections 6 and 7 describe how the architecture fits the with specific network deployments.
> While those sections describe how some protocols could be applied, they are not a solution,
> they are an application of the architecture. They could be re-titled "Applicability of The
> Architecture Described in This Document to Optical Domains and Networks" and "Modeling
> the User-to-Network Interface Using The Architecture Described in This Document"
> although those seem rather long-winded.
> 
> Section 5 possibly does not go far enough as it is! It notes some relevant protocol work that
> has not been completed, but it does not build a comprehensive list. And it does that
> deliberately in order to not attempt to deliver or prejudge a solution. Mentioning that BGP-
> LS does not (yet) have an RFC that describes extensions for GMPLS networks is possibly
> over-reaching because no-one has said that it is a requirement to use BGP-LS to export
> abstractions of optical links. In any case, it would be wrong for this document to preclude
> If it is still the opinion of our leaders (who have to support publication) that this is not
> Standards Track, that's OK too.
> - Changing the document that we wanted to publish just to make it match a particular
> publication track.
> - Trying to second-guess the IESG. They may say BCP is OK as written. They might ask us to
> make more changes even after the ones Deborah suggests.
> 
> > Subject: Re: [Teas] Update to
> > draft-ietf-teas-interconnected-te-info-exchange
> >
> > Adrian, Authors,
> > > We received a GenART review from Brian Carpenter and a SecDir review
> > > from Hilarie Orman. These gave rise to some changes and some email discussion.
> > > I believe we have closed down all points except one from Brian about
> > > whether
> > the
> > > content and precise wording is consistent with the document as a
> > > BCP. At the moment I am reluctant to change the text to make it
> > > consistent with the
> > chosen
> > > The Diff will show a few more changes than expected because the
> > > layout
> > changed

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 May 2016 09:15:11 +1200

1) Thanks for all the detailed updates. This is a fine document that
should certainly be published.

2) It's above my pay grade as a Gen-ART reviewer to decide the best status
for the document. I have some doubts but I'm completely happy for the IESG
to decide.

Regards
   Brian Carpenter

---

From: Lou Berger <[email-masked]>
Date: Wed, 11 May 2016 15:49:26 -0400

Authors, WG,

So, I've been doing a bit of archeology on this one.  some key aspects
from the threads (and of course without full context):

On 5/4/2016 1:25 AM, Brian E Carpenter wrote:
> 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, ...
On 5/4/2016 7:02 PM, BRUNGARD, DEBORAH A wrote:
> ...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...". 
On 5/4/2016 8:48 PM, Brian E Carpenter wrote:
> 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).

So the discussion goes on for a bit, but I think the fundamental comment
is a fair one:

** That the document needs to clearly delineate what can be done today,
and what might be useful (extensions) in the future. 

This holds even if the document were to be published as the authors
viewpoint is held to publish as PS -- which BTW is not a topic of this
message/thread.

Before getting into any details on specific changes to the document, I
think it would be good to get WG opinion/consensus on this one point,
see ** above.

Does anyone object to, or care to comment on, clarifying this one point?

Thanks,
Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 11 May 2016 20:29:14 +0000

Lou,

Snipped, comment inline

Yours Irrespectively,

John

> > 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).
> 
> So the discussion goes on for a bit, but I think the fundamental comment is a fair one:
> 
> ** That the document needs to clearly delineate what can be done today, and what might
> be useful (extensions) in the future.

[JD]  This is not my reading of what Brian said.  My reading is that  he said that if it were to 
be published as a BCP it would have to clearly state that the architecture it describes can
be completely implemented using current specifications

Your reformulation is fundamentally different and, from what Brian writes, incompatible
with the definition of a BCP  

> 
> This holds even if the document were to be published as the authors viewpoint is held to
> publish as PS -- which BTW is not a topic of this message/thread.

[JD]  From what I have read, both the above statement and your reformulation of Brian's
comment are strictly and solely your own opinion

---

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

> with the definition of a BCP  

You can include non-normative sections in a BCP or standards track document,
as long as they are clearly identified as non-normative. I don't think this would
be hard to do - it's just annotation of the existing text, not a rewrite or
any change to what I understand to be the WG consensus.

   Brian

---

From: Lou Berger <[email-masked]>
Date: Wed, 11 May 2016 16:46:30 -0400

Brian,

Thanks for the quick response.  Would addressing the following address
your objection?

** That the document needs to clearly delineate what can be done today, and what might be useful (extensions) in the future.

Thank you,
Lou

---

From: John E Drake <[email-masked]>
Date: Wed, 11 May 2016 20:49:59 +0000

Brian,

I think this is very useful advice.    

Yours Irrespectively,

John

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, May 11, 2016 4:41 PM
> To: John E Drake; Lou Berger; [email-masked]; [email-masked]
> Cc: [email-masked]
> >>> Yes. Basically it needs to be clear that the architecture can be
> >>> 100% implemented using current specifications, and that the possible
> >> ** That the document needs to clearly delineate what can be done
> >> today, and what might be useful (extensions) in the future.
> >
> >
> > [JD]  This is not my reading of what Brian said.  My reading is that
> > he said that if it were to be published as a BCP it would have to
> > clearly state that the architecture it describes can be completely
> > implemented using current specifications
> >
> > Your reformulation is fundamentally different and, from what Brian
> > writes, incompatible with the definition of a BCP
> 
> You can include non-normative sections in a BCP or standards track document, as long as
> they are clearly identified as non-normative. I don't think this would be hard to do - it's just
> annotation of the existing text, not a rewrite or any change to what I understand to be the
> WG consensus.
> 
>    Brian
> 
> >
> >
> >>
> >> viewpoint is held to publish as PS -- which BTW is not a topic of this message/thread.
> >
> >

---

From: John E Drake <[email-masked]>
Date: Wed, 11 May 2016 20:56:30 +0000

Lou,

What I thought Brian said was to mark sections as either normative or non-normative and this seems clear to me.  Your reformulation does not seem either clear nor bounded in terms of effort. 

Yours Irrespectively,

John

> Sent: Wednesday, May 11, 2016 4:47 PM
> To: Brian E Carpenter; John E Drake; [email-masked]; [email-masked]
> Thanks for the quick response.  Would addressing the following address your objection?
> 
> >>>> 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).
> > You can include non-normative sections in a BCP or standards track
> > document, as long as they are clearly identified as non-normative. I
> > don't think this would be hard to do - it's just annotation of the
> > existing text, not a rewrite or any change to what I understand to be the WG consensus.
> >
> >    Brian
> >
> >>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 May 2016 22:38:16 +0100

This document is not describing a protocol solution. I don't think architectures
do that (applicability statements, or frameworks might).

I continue to want to find the right track on which to publish *this* document,
not to try to massage the document to fit one track or another. Whether those
massages are considered technical or editorial is not relevant for me, they
would be changing the document purely for reasons of process.

*If* someone wants to do some analysis of how to "solve" this architecture with
existing protocols, or wishes to produce requirements for new protocols or
protocol extensions, that would be a fine idea. They might limit that to
specific deployment scenarios or attempt a broad solution.

Anyway...
I *think* the WG consensus on this I-D was called, and (judging by the presence
of the document on an IESG telechat agenda) the IETF consensus was also called. 

Adrian

> Sent: 11 May 2016 21:47
> ** That the document needs to clearly delineate what can be done today, and
> what might be useful (extensions) in the future.
> 
> 
> Thank you,
> Lou
> 
is a
> fair one:
> >> [JD]  This is not my reading of what Brian said.  My reading is that  he
said that
> if it were to
> >> be published as a BCP it would have to clearly state that the architecture
it
> describes can
> viewpoint is held to

---

From: Lou Berger <[email-masked]>
Date: Wed, 11 May 2016 17:47:51 -0400

John,

On 5/11/2016 4:56 PM, John E Drake wrote:
> Lou,
>
> What I thought Brian said was to mark sections as either normative or non-normative and this seems clear to me.  

This works for me (and seems to me to be a way to address the objection
I thought was being raised - but we don't need to argue this further).

Can you propose specific changes to address this comment?

Lou

> Your reformulation does not seem either clear nor bounded in terms of effort. 
>
> Yours Irrespectively,
>
> John
>

---

From: John E Drake <[email-masked]>
Date: Wed, 11 May 2016 22:11:30 +0000

Lou,

I think this entire discussion has been OBE because the IESG is scheduled to discuss it next week;  i.e., they will be looking at the document in its current form so there is no point in changing it.

If they have similar objections, then Brian's suggestion can be proposed by the authors.

Yours Irrespectively,

John

> Sent: Wednesday, May 11, 2016 5:48 PM
> To: John E Drake; Brian E Carpenter; [email-masked]; [email-masked]
> This works for me (and seems to me to be a way to address the objection I thought was
> being raised - but we don't need to argue this further).
> 
> >>>> [JD]  This is not my reading of what Brian said.  My reading is
> >>>> that he said that if it were to be published as a BCP it would have
> >>>> to clearly state that the architecture it describes can be
> >>>> completely implemented using current specifications
> >>>>
> >>>>> This holds even if the document were to be published as the
> >>>>> authors viewpoint is held to publish as PS -- which BTW is not a topic of this
> message/thread.
> >>>> [JD]  From what I have read, both the above statement and your
> >>>> reformulation of Brian's comment are strictly and solely your own
> >>>> opinion
> >>>>
> >>>>
> >>>>

---

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

I agree. Either the IESG has the same question that I do, which (IMHO)
would lead to very mild editing, or they are happy with it as-is.

(Copying Jari as the AD who receives Gen-ART reviews - there has been
quite a long off-list thread but no clear agreement on whether changes
are needed to identify which sections are the actual BCP and which
sections are not.)

Regards
   Brian