Re: Deborah Brungard's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS)

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Acee,

On Feb 28, 2018 10:36, "Acee Lindem (acee)" <[e-mail]> wrote:

Hi Spencer,

We are begrudgingly discussing the inclusion of "default" values as opposed
to "example" delay values and are willing to make this concession to
resolve the issue. A couple things to note:

   1. Even the OSPF Hello and Dead intervals (which are necessary to form
an OSPF adjacency) are provided as "example" values in RFC 2328.
   2. Given the initial discussions of this RTGWG draft, it is interesting
that standard defaults have not been requested until the IESG review.


Thanks for added context. And I'm still reading ;-)

Spencer

Thanks,
Acee

On 2/28/18, 11:18 AM, "Spencer Dawkins at IETF" <
[e-mail]> wrote:

    Just to chime in ...

    I was a No-Objection for this document supporting Deborah's Discuss,
    Alvaro's Discuss, and maybe both, and the reason I was vague about that,
    was that those Discusses seemed to be headed in opposite directions -
    either the document needed to be more abstract, or it needed to be more
    precise (with recommended timer values, etc.). I could have believed
either
    assertion, but wanted to see which way the document headed before saying
    more myself.

    I see that the conversation continues, and will continue a bit more when
    Alvaro surfaces, but I wanted to say that I appreciate the exchange(s)
so
    far, and especially Bruno's most recent post, clarifying the transition
    story.

    Thank you all for that. I'm still reading ballot threads as they
develop,
    of course.

    Spencer

    On Wed, Feb 28, 2018 at 9:44 AM, <[e-mail]> wrote:

    > Hi Deborah,
    >
    > Please see inline
    >
    >  > -----Original Message-----
    >  > From: BRUNGARD, DEBORAH A [mailto:[e-mail]]
    >  > Sent: Wednesday, February 28, 2018 12:48 PM
    > >
    >  >
    >  > Hi Acee,
    >  >
    >  > I think Alvaro is on vacation this week without email access. As I
    > noted in my Discuss, I support
    >  > Alvaro's concerns on incompleteness and vagueness. I am interested
in
    > Alvaro's response on the
    >  > update if it addresses his concerns.
    >
    > 1) Regarding Alvaro's DISCUSS,
    > We have engaged the discussion on his points. Thanks for the info
that he
    > is on vacation this week. No problem, we'll obviously wait for this
return.
    >
    > 2) Regarding your DISCUSS,
    > Can we work on resolving your point and hopefully your DISCUSS even
in the
    > absence of Alvaro?
    >
    > As a reminder, your DISCUSS is the following:
    >
    > "While I agree with Alvaro's concerns, my concern is the
appropriateness
    > of this document as PS.
    > This document should have a similar status as RFC6976 (Informational)
    > which also provided a
    > mechanism that prevented transient loops saying "the mechanisms
described
    > in this
    > document are purely illustrative of the general approach and do not
    > constitute a protocol
    >
    > specification". Especially as this document compares itself to
RFC6976,
    > saying RFC6976 is a
    > "full solution".
    >
    > With a change of status to Informational, this document would be
better
    > scoped as providing guidance vs. a specification."
    >
    >
    >
    >
    > So in summary your DISCUSS is about the status of this document: STD
track
    > vs informational.
    >
    > Acee has replied on this point in the following thread, and
ultimately you
    > did not follow up. So I though the point was closed.
    > https://mailarchive.ietf.org/arch/msg/rtgwg/
pqGrmtI7MYVqU8tSNwId-QEROYs
    > So could you please follow up on this thread so that we can advance on
    > this point?
    > I'll also contribute below in this email in reply to your specific
    > comments.
    >
    > Regarding STD status, a distributed Link State IGP, requires, in
order to
    > produce consistent routing table across the network, to perfom the
same
    > computation (SPF), using the same info/database, at the same time.
    > Given that all implementations use SPF back off delay algorithms (by
    > default), in order to fulfill this routing consistency across the
network,
    > one STD SPF back off delay algo needs to be specific. By doing so,
this
    > document helps addressing the above two latest points (same time, same
    > LSDB).
    >
    > Also, in case you missed it as the email was in a different thread,
Alia
    > has also stated that this needs to be standard track.
    > https://mailarchive.ietf.org/arch/msg/rtgwg/
EDpT9lvKVDaBjI8g_QHznZMdTNI
    >
    >
    >
    > 3) Regarding your new additional comments below
    >
    > It's not clear to me whether they are additional points in your
DISCUSS or
    > just regular comments.
    > Reading the discuss criteria, they really likes non-blocking comments
to
    > me.
    > https://www.ietf.org/iesg/statement/discuss-criteria.html
    >
    > So you could please clarify the status of those comments?
    >
    > More below.
    >
    >  >
    >  > I don't see any changes for my noted concerns on vagueness.
    >
    > Acee replied to your email and you did not reply.
    > As previously noted, I'll also reply on your points in this email,
below.
    >
    >
    >  > The confusing sentence remains in
    >  > the introduction "Optionally, implementations may also offer
    > alternative algorithms."
    >
    > - I'm personally not sure to see what is confusing in this sentence.
    > - As Acee replied, this is just a statement about the reality of
existing
    > implementations and deployments.
    > - That being said, that sentence does not really add anything to the
    > specification. Hence if this is a blocking point to you, I've just
removed
    > it. Problem solved.
    >
    >   >And later in
    >  > section 5 saying it "describes the abstract finite state machine".
    >
    > I'm not sure to see the issue but changed to
    >
    > OLD: This section describes the abstract finite state machine (FSM)
    > NEW: This section specifies the finite state machine (FSM)
    >
    > Also changed (*3):
    > OLD: FSM abstract timer
    > NEW: FSM timer
    >
    >
    >  > So to me, it still is not clear if this document is a PS for the
    > algorithm or for the parameters
    >
    > The document is a PS for the algorithm.
    > We have initiated a discussion with Alvaro regarding the additional
    > specification of default parameters for the specific cases where they
are
    > useful.
    >
    >  > e.g. any
    >  > SPF delay algorithm that supports the IETF parameters can be used
so
    > long as it derives the same
    >  > results of the "abstract" state machine.
    >
    > I'm not sure how this question is specific to this document.
    > Personally, I'd tend to generally reply "yes". i.e., considering the
node
    > as a black box, if it's behavior conforms to the behavior defined in
the
    > IETF document, I'd say that the node is compliant with the IETF
document.
    > e.g., if the IETF document defines a timer of 3 seconds, it looks ok
for
    > me if an implementation waits for 3 consecutive 1 second timers.
    > But any general answer from the IETF works for me. It seemed to me
that
    > the IETF does not give position regarding conformance.
    >
    >  > Especially considering the deployment concerns for a new algorithm.
    >
    > I think that you are missing that the current situation is worse: if
you
    > have a multi-vendor networks, you already have inconsistent algorithms
    > forever hence you (may) have inconsistent timers values forever.
    > If/When you transition to this new algorithm, you also have
inconsistent
    > algorithms during the transition (*), but after the transition, the
problem
    > is solved.
    > (*) whether the situation is worse during the transition or not, is
very
    > dependent on the pre-existing algo.
    >
    > Also, this inconsistency is essentially the same than the transition
of
    > parameters values. And this already happen today, including in a
    > mono-vendor network. e.g.,   https://www.cisco.com/c/en/us/
    > support/docs/ip/ip-routing/211432-Change-of-Default-OSPF-
    > and-IS-IS-SPF-and.html
    > Please note that deployment section from the above document says
    > essentially the same:
    >
    > "When you deploy routers with newer Cisco IOS software that have the
new
    > default values, it is recommended to ensure that all routers have the
same
    > default values for the timers. This reduces the risk for possible
routing
    > loops.
    >
    > If you have routers that run the old default values and you upgrade
the
    > routers to the newer Cisco IOS software, it is likely that you have a
    > migration time where some routers run an older Cisco IOS software
with the
    > old default values and some routers that run newer IOS software with
the
    > new default values. This is not recommended."
    >
    >
    > Bottom line: blocking this document does not avoid a possible
transition
    > issue, but avoids solving the existing forever issue in multi-vendor
    > network.
    >
    >
    >  > As other ADs agree with me, this type of document is typically
    > informational. Maybe with
    >  > Alvaro's clarifications, it will not be so abstract.
    >
    > We are indeed working on Alvaro's comment.
    >
    >  > The naming of the algorithm is also vague.
    >
    > I guess that the discussion on the name is not a
DISCUSS/blocking-issue.
    > Is this?
    >
    >
    >  > There are only two uses of "backoff", in the title and in the
abstract