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

[John E Drake <[e-mail]>]

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

> -----Original Message-----
> From: Teas [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Tuesday, May 10, 2016 12:15 PM
> To: 'Lou Berger'; [e-mail]
> Cc: [e-mail];
> [e-mail]
> Subject: Re: [Teas] Update to draft-ietf-teas-interconnected-te-info-exchange
> 
> 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
> > >
> 
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas