Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC from 4/13 to 4/27

Randy Bush <randy@psg.com> Sun, 03 June 2018 02:15 UTC

Return-Path: <randy@psg.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E9B1201FA; Sat, 2 Jun 2018 19:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkiAwaTT4n3c; Sat, 2 Jun 2018 19:15:35 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919701200C1; Sat, 2 Jun 2018 19:15:35 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1fPIYO-0003lQ-2g; Sun, 03 Jun 2018 02:15:32 +0000
Date: Sat, 02 Jun 2018 19:15:31 -0700
Message-ID: <m2r2loipj0.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Nick Hilliard <nick@foobar.org>
Cc: "idr@ietf. org" <idr@ietf.org>, draft-ietf-idr-rs-bfd@ietf.org, Hares Susan <shares@ndzh.com>
In-Reply-To: <4f6267d4-6759-4ed6-2869-ccbe16d9a817@foobar.org>
References: <013401d3d338$f7c74f60$e755ee20$@ndzh.com> <CACWOCC_fb1NcUC6qGrNFAA0CTBJkDOhecV4J-NgvTP7_wzWV5g@mail.gmail.com> <89466EFB-7F8F-4C5A-AB36-7E510FA3F3C6@juniper.net> <4f6267d4-6759-4ed6-2869-ccbe16d9a817@foobar.org>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-8859-7"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NtsSO4DqUiECu8MBV27zayu011c>
Subject: Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC from 4/13 to 4/27
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Jun 2018 02:15:38 -0000

excuse top post

as we left the discussion at lunch

  o this does not change bgp

  o when the router knows the link to an nlri goes down, the rs
    needs to know so it can give the router the next best path's
    nlri

randy

> The WGLC is officially over, but not announced as over. I meant to
> comment on this ID sooner, but here are some thoughts anyway.
> 
> The IDR WG needs to take on board the Camel presentation from dnsops.
> 
> BGP is already a hugely convoluted protocol, and this convolution
> breeds both complexity and fragility.  It's not that any individual
> chunk of the protocol is especially complicated in itself: it's more
> that in order to produce a working BGP stack, it's necessary to
> transcode voluminous tomes of RFCs and then figure out all the
> implementation subtleties required for reasonable interoperability
> with other stacks.
> 
> Occasionally I get to talk to people who attempt to write new BGP
> stacks and their opinion is that it's a daunting prospect.  The sheer
> volume of features in BGP is now such that building new BGP
> implementations is prohibitively expensive, and the possibility of
> starting again with a new protocol (bgp5?) is receding further into
> the distance due to the scale of what it would take to replicate the
> bits of BGP that people need and use.
> 
> There's no doubt all these protocol developments are useful, but the
> cost of implementing them is not linear.  Probably as a working group,
> we need to take stock of this and try to decide where we want BGP to
> be in 20 years?  Tacking on more arms and legs?  Or do we ever
> envisage taking out the secateurs or a saw?
> 
> Regarding draft-ietf-idr-rs-bfd implementations, or lack thereof,
> there isn't a compelling reason why the normal guidelines for WG LC
> should be waived.  In fact, John's argument suggests the opposite -
> there have been some major protocol design changes in what's been
> suggested since the draft was first mooted, and there's still no code
> to prove that it will work well in real life situations, or that the
> spec is defined well enough that one implementation might interoperate
> with another.
> 
> Interoperability in this case is more important than usual because the
> ID is targetted at ixp route servers, which often have weird, ancient
> and tragically broken devices connected.  On AS43760, which is a small
> RS, we still have ~5% of devices not supporting the AS4
> extension. Think about what that means in terms of code rot.
> 
> Regarding the content of the ID, there are two aspects to it: bfd
> brokerage and NH reachability propagation.
> 
> The draft states that both problems need to be fixed, but do they
> really?  Is BFD brokerage not sufficient?  Putting it another way, is
> the complexity required by the NH reachability propagation really
> justified by the gain in benefit?  I am having trouble understanding
> why.  Although I can see what it does and how it works, it looks like
> it's optimising an edge case rather than dealing with the meat of the
> issue which is bfd brokerage.
> 
> It would dramatically simplify the proposal if the NH reachability
> propagation part could be stripped out.  If it's left in, then the
> overall mechanism seems to be a very complicated and very new
> departure for BGP, which gets back to the point above about the point
> at which the straw breaks the camel's back.  I really think the
> authors need to make it clear why this part of the specification
> cannot be done without.
> 
> Regarding WGLC, I can understand the desire to get this ID into the
> bag, get it on customer feature spec lists and get it out the door
> from a vendor point of view, but I query the wisdom of pushing a draft
> like this through IETF WGLC without any running code in the general
> case, and a good deal more in this specific case.
> 
> Right now, I'm inclined to think that it shouldn't proceed until there
> is consensus that the extenuating circumstances are sufficient that it
> should get special treatment, or, as John says below, whether we
> should open up a wider discussion on what part running code plays in
> protocol development.  We may also wish to discuss protocol
> over-development and the balance between complexity vs gain.
> 
> Nick
> 
> John G. Scudder wrote:
> > (As a co-author, yes, really. Maybe the co-chair would even disagree
> > with some of these points, who knows.[*])
> > 
> >> On Apr 13, 2018, at 1:31 PM, Job Snijders <job@ntt.net
> >> <mailto:job@ntt.net>> wrote:
> >> 
> >> Dear all,
> >> 
> >> Are there implementations? Is there an implemention report as per
> >> IDR tradition?
> >> 
> >> If not, I don’t support progressing this draft at this moment.
> >> 
> >> The machinery described in this draft is not entirely straight
> >> forward, without running code we should hold off on progressing.
> > 
> > For those who missed it, there is a bit more context in Job's
> > earlier note,
> > https://www.ietf.org/mail-archive/web/idr/current/msg19261.html,
> > including
> > 
> > "ps. yes, i know IDR can have WGLC without running code, but given that
> > this is a non-trivial extension to BGP; I'd really like to see multiple
> > implementations that are able to interact with each other in the correct
> > way and a report detailing the interopability."
> > 
> > In this case the authors are, exactly and without pretense,
> > requesting WGLC without running code. Which seems a funny thing
> > coming from me -- sometimes all these hats I wear get too tight and
> > give me a headache. Anyway, in this case we think it's worth doing
> > the WGLC because it indicates as clearly as we can to potential
> > implementors that the spec is "done" and will not continue to
> > mutate. As you might recall, this particular spec has changed quite
> > a lot over its history, more than many, and I wouldn't blame an
> > implementor for standing back and waiting for the dust to settle
> > before writing code.
> > 
> > As we all know (and have a history of doing, as a WG) if post-WGLC
> > implementation experience indicates a need for changes, the draft
> > can and will be updated to take them onboard, and of course if those
> > changes are substantive enough, I would expect a new WGLC would be
> > needed at that point. Other groups do this same
> > review/implementation cycle by progressing things to RFC, then
> > implementing, then bis-ing or otherwise updating the RFCs. I am not
> > (again, as a WG member) a fan of that, and I'm glad we don't do
> > things that way, although our way is also not perfect as witness
> > this discussion.
> > 
> > Fundamentally a WGLC is a way of asking the WG, "the authors think
> > this is done, do you agree?" We are asking. "We have
> > implementations" is a strong argument to support the "we are done"
> > argument, but it's neither necessary nor sufficient and so far the
> > WG has deemed it desirable but not required for WGLC. We think there
> > would be no benefit, and some harm, from letting the document sit in
> > "active WG draft" status when it's *not* in fact active and the
> > authors have moved on to other things. Moving it to "waiting for
> > implementation" status, if the results of the WGLC support that, is
> > more honest and more clear. I suppose another way of doing this
> > would be to invent some IDR pre-WGLC-WGLC that feeds into the
> > "waiting for implementation" document state, but right now we don't
> > have that.
> > 
> > Of course you and any other WG member are free to use all the facts
> > at your disposal (including the document itself, and including any
> > reported implementation) to decide if you want to support a WGLC,
> > and that's fine.
> > 
> > Finally I'd like to ask (and this *is* with the co-chair hat on)
> > that if we continue a wide-ranging philosophical discussion of the
> > IDR implementation tradition as opposed to a discussion of whether
> > the doc is ready for WGLC, that we change the subject line
> > accordingly.
> > 
> > Thanks!
> > 
> > --John
> > 
> > [*] "Do I contradict myself? Very well, then I contradict myself, I
> > am large, I contain multitudes." --Walt Whitman
> > 
> > 
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> >