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

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

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

On 11/05/2016 05:51, John E Drake wrote:
> 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
>