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

["Adrian Farrel" <[e-mail]>]

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
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: 10 May 2016 14:45
> To: [e-mail]; [e-mail]
> Cc: [e-mail];
> [e-mail]; Hilarie Orman
> Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange
> 
> 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
> 
> On 5/10/2016 9:04 AM, Adrian Farrel wrote:
> > 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:[e-mail]] On Behalf Of
> > [e-mail]
> >> Sent: 10 May 2016 13:56
> >> To: [e-mail]
> >> Cc: [e-mail]
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/teas
> > _______________________________________________
> > Teas mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/teas
> >