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 > >
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Nick Hilliard
- [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC fro… Susan Hares
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Randy Bush
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… John G. Scudder
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Job Snijders
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Robert Raszuk
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… John G. Scudder
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Nick Hilliard
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Randy Bush
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Robert Raszuk
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Nick Hilliard
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Robert Raszuk
- Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC… Rajiv Asati (rajiva)