Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

Robert Raszuk <robert@raszuk.net> Tue, 21 June 2022 15:37 UTC

Return-Path: <robert@raszuk.net>
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 64F2AC15AAD1 for <idr@ietfa.amsl.com>; Tue, 21 Jun 2022 08:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjykfxCIHO6h for <idr@ietfa.amsl.com>; Tue, 21 Jun 2022 08:37:11 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A78C15AACF for <idr@ietf.org>; Tue, 21 Jun 2022 08:37:11 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id ay16so8962786ejb.6 for <idr@ietf.org>; Tue, 21 Jun 2022 08:37:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1tC078JutogJ6/M2V8s+saBqoKFa8RxIl6SUNl/LkCM=; b=G9wzYlvkqvyAVKJTVXER9vYJ1teFMYSTrPITpRqOgKllR862vgTSPxaJf+ZuxYFhXk UzsqAnNiJIYEgn+futSK87iHmPDhKLNixuonFmrpyutrB6KhXygcmar6ZY/QMqIM4Lwl Z+Ixdf7QDiecn5Zx94CFnKZtXdeI+R2/kSBok5i7OSmFijgcPjHWrximq4bwcihOOrnE +B52QSW3xwEgcX4Z+0RpvBmLtQSHHvOCEoU3xZOszA4a+nDFX5d9+lAkO0YtqP+vAnnc I2QEIJmHrPQ+/gJI6j+FaS2wGeNtyLjb/hsYczM0QJxH7j/D+pSLis2QVj68+FMl8Nfd sWjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1tC078JutogJ6/M2V8s+saBqoKFa8RxIl6SUNl/LkCM=; b=KmOHHUjxIYFdbDJN2UOUTvSHpYvON+A8U9b4IfpLg//gwhPnHxLlhpvUnZJoOETKaS GEJ2ssqjbUs4bA66IeCZLt3xi2Uj8E8I31lP/vb/NUKUu/p2Gh47gg7KnqV8PbIbMMyJ QBZheWtBUJJPXfMptgRCuiFUOvwN8Y30RLmPlgcAPBYVkyBO9/dBYwjXPDUPStOJ4Z7N au3PneiMtN2/qgZM0g7F6km0rvxLxiPfdUWpq16ZLR62OD1O0ifZkv8e/12aK2/z+3FB xy6mF3BT5DF3IrdB7JxH44dacDxbf6YUxSbXo1+bqMTFrmb/QVTmn+RkJgpN3vRG0ccI WgVg==
X-Gm-Message-State: AJIora/3349MIDkfuDosC+t6PRKtg0kCbtv5Kf1q8122gMrek7EzpLKy VuiseyJxQgz6q+A/H46E8O1XODDOaLrgyNBhMKnupfWKvzdwMA==
X-Google-Smtp-Source: AGRyM1tTv5qxY5aCdmuVIFnVczt1YihnIpw+FEpaXe8gT8UtPSf0pcZeQM2BZ3UyQ4iwCuBwv9VYcgipBx/hvyvakxs=
X-Received: by 2002:a17:906:7944:b0:6da:b834:2f3e with SMTP id l4-20020a170906794400b006dab8342f3emr27216879ejo.353.1655825829080; Tue, 21 Jun 2022 08:37:09 -0700 (PDT)
MIME-Version: 1.0
References: <BY5PR11MB4337153D1D387C125A822F12C1A59@BY5PR11MB4337.namprd11.prod.outlook.com> <BYAPR08MB487281C781BB66A00803B9ECB3A59@BYAPR08MB4872.namprd08.prod.outlook.com> <BY5PR11MB43370655CE2A2406B394C901C1A49@BY5PR11MB4337.namprd11.prod.outlook.com> <BYAPR08MB4872AB7D94218FFD4FF236D5B3A49@BYAPR08MB4872.namprd08.prod.outlook.com> <BY5PR11MB4337E9C8F39A7512FC8808DEC1A49@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMFA+_2p0jucZJzDencS1KRnSVJPwK8SryV1nqf12M7VLA@mail.gmail.com> <CA+wi2hOnDrrFcpDFJGbBs412rP8-FgJ_ga-YPj3xhRgwu_ngEA@mail.gmail.com> <CAOj+MMEejRipew3CnxG9L9iZ1yBFxy1ewuDzDe+VgJN3_YCG+w@mail.gmail.com> <CA+wi2hMHdhrAhU3dP82XHh=W71TGxnCKUXVgZJEcE61N8J-0Pg@mail.gmail.com> <CAOj+MMFjfQmX-DLxgK01OcaMHVwCp3UrmXhbFhouz_SPRMbJBw@mail.gmail.com> <YqDjcrsoiCc0Sz58@Space.Net> <CA+wi2hOHuSqh6RwTEExxZnAbSCBRkcAccSN9u7XG86G3yaz6rA@mail.gmail.com> <CAOj+MMGn-N+qBkYGPMDzUvHCPgn_cQ3xsttjhAvhmabys0nsOQ@mail.gmail.com> <CA+wi2hMDwXnT8LdDVo+xQvcD9NwXNhnNguCywxEQNXP4k+Vd3g@mail.gmail.com> <CAOj+MMFqNG03Bo3PBhyq+9LFPg9E=ExEMEnJbHeG_SGQLLj+1g@mail.gmail.com> <CA+wi2hOjaZGVVJYDLESsn6Quj-ZBk6ouGT-1Um9AOZduibRrZA@mail.gmail.com> <23807_1655124718_62A732EE_23807_213_17_3cf4e891a6fc4922b1da262e7fead11a@orange.com> <CA+wi2hN0H1e7MuvG8jNRXRQVxeTUrQPzRRDZcj9LgBUsZNrouQ@mail.gmail.com>
In-Reply-To: <CA+wi2hN0H1e7MuvG8jNRXRQVxeTUrQPzRRDZcj9LgBUsZNrouQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 21 Jun 2022 17:36:57 +0200
Message-ID: <CAOj+MMECnKYuyTGpxsjcB7e4vhTzpYSxp1pdHhPkEhP23V+dmQ@mail.gmail.com>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: Bruno Decraene <bruno.decraene@orange.com>, Susan Hares <shares@ndzh.com>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005aa69a05e1f6feba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/gtP6EJkOQhF26R98gFHgjPIjKBc>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 21 Jun 2022 15:37:15 -0000

Tony,

The main problem here is that you are not proposing a better alternative in
LSR WG. You keep riding on a hijacked train purely for convenience. And
till you are no longer allowed to board it no other alternative will
surface.

Yes the sooner you start with a different solution to send LSDB to the
controller the smoother the switch will be for your customers. So now let's
see how much you care about "customers with deep pockets".

Best,
R.

On Tue, Jun 21, 2022 at 5:14 PM Tony Przygienda <tonysietf@gmail.com> wrote:

> no, it's not a valid argument. it's just a fact of life like bees and
> birds when customers with deep pockets need their stuff working. and no
> better alternative meeting their needs is available or rather they went
> down the slope of something like BPG-LS IETF sent them barrelling down so
> they just need mo' stuff in it to make new stuff they use work. And to be
> mildly cynical here, BGP-LS at time of creation got the warnings about
> re-encoding and being always behind the IGP curve ultimately and ignored it
> so BGP-LS gets to live it down now ...
>
> Jeff H. can sing an opera about the squatting and how to address it via
> temporary/experimental etc ... ;-)
>
> -- tony
>
> On Mon, Jun 13, 2022 at 2:51 PM <bruno.decraene@orange.com> wrote:
>
>>
>>
>>
>>
>> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of *Tony Przygienda
>> *Sent:* Wednesday, June 8, 2022 10:32 PM
>> *To:* Robert Raszuk <robert@raszuk.net>
>> *Cc:* Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>;
>> idr@ietf.org; Susan Hares <shares@ndzh.com>
>> *Subject:* Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call
>> (6/6 to 6/20)
>>
>>
>>
>> Don't blame me for BGP-LS, read the RFC authors' list and go from there
>> ;-)  I didn't sell it as "don't need a parser, it's secure, it's inter-AS,
>> it's singing & dancing" ... And I was vocal if BGP is abused to carry IGP
>> topology it should be a raw data conduit and about other problems it will
>> cause down the road.
>>
>>
>>
>> And the answer for questions below is yes and many times over many, many
>> years. actually before BGP-LS customers were running passive sessions and
>> such things as lots of IGP folks now and actually, some customers who got
>> disillusioned by BGP-LS I raw-streaming IGP via gRPC (whereas I think redis
>> or some such thing is possibly a better choice but it's a deeply technical
>> discussion for high performance IGP coders and realistic boundaries of
>> automation code to consume IGP speed feeds) ... But few and far inbetween
>> ;-)
>>
>>
>>
>> So, can we now go back and make sure we have a standardized version of
>> this draft/technology in BGP-LS before we end up building it sideways stuff
>> or have to squat points ?
>>
>>
>>
>> I don’t think that the threat to squat on codepoints is a valid argument.
>> (Although it has already been used in the IETF/LSR WG to push for the
>> adoption of the corresponding IS-IS draft [1].)
>>
>>
>>
>> More generally, there is a number of BGP attributes which have been
>> squatted recently [2]. Are we fine with this? (e.g. yes, this is allowed
>> for a couple of companies) If not, what could we do to improve on this?  (More
>> code points reserved for development?  Name and shame in the IANA
>> registry (e.g. Squatted by Foobar)?...
>>
>> Speaking for myself, I’m not fine with this. This hurts interop [2],
>> sometimes networks [2], fairness…
>>
>>
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/lsr/pNBoc30jIPx5op_s3gzlIsDfPMc/
>>
>> [2] https://www.rfc-editor.org/rfc/rfc8093.html
>>
>>
>>
>> Regards,
>>
>> --Bruno
>>
>>
>>
>> And you may observe we kept the stuff hre to super/duper minimum (just
>> cluster ID) rather than stuffing things like client/FR/tunnel stuff into it
>> since only the boundary is of interest really and correlation L1/L2 BGP-LS
>> feed can happen with that minimum already in place.  Unless I hear
>> opinions that we should put more stuff in.
>>
>>
>>
>> chiming out ...
>>
>>
>>
>> -- tony
>>
>>
>>
>> On Wed, Jun 8, 2022 at 10:22 PM Robert Raszuk <robert@raszuk.net> wrote:
>>
>> Tony,
>>
>>
>>
>> Yes - let's keep adding to BGP stuff which does not belong there and
>> continue to keep crying how BGP is slow and how BGP  interdomain
>> convergence takes minutes for full table.
>>
>>
>>
>> Why do we need the Internet at all ? After all - you never sold anything
>> to "The Internet".
>>
>>
>>
>> Let me ask you a question - Did you ever presented to customers an
>> alternative to BGP-LS ? Did you demo it ? Did you discuss pros and cons?
>>
>>
>>
>> With such myopic view we can sit and watch how this train which left
>> years ago goes slower and slower ..
>>
>>
>>
>> Or maybe this is after all good news ... I am sure inventors of SCION can
>> be super happy to see such growing abuse of BGP to be happening in IETF
>> over and over again.
>>
>>
>>
>> Cheers,
>>
>> R.
>>
>>
>>
>> On Wed, Jun 8, 2022 at 10:05 PM Tony Przygienda <tonysietf@gmail.com>
>> wrote:
>>
>>
>>
>>
>>
>> On Wed, Jun 8, 2022 at 8:47 PM Robert Raszuk <robert@raszuk.net> wrote:
>>
>>
>>
>> train left the station ages ago pushed by original authors who dissipated
>> leaving us with this contraption ...
>>
>>
>>
>> So perhaps time to cut this car out of the locomotive ? Before it causes
>> the entire train to derail damaging fun and joy for many ?
>>
>>
>>
>> Robert, good luck with that then ... Let me know how it goes after you
>> talked to a bunch of really large customers having lots automation built
>> around it already ;-) Ooops, I forgot you're fortunate enough these days to
>> not be with a vendor running a large part of the planet.
>>
>>
>>
>>
>>
>>
>>
>> genuinely funny that this 5 pages tiny TLV draft is causing such a deep
>> soul searrching in IDR ;-)
>>
>>
>>
>> For one this is not about this draft but any new IGP protocol extension
>> seen in ISIS or OSPF messages to go to BGP-LS -- as it turns out this is
>> really what it is.
>>
>>
>>
>> For this very draft irrespective if this is a separate document or you
>> copy and paste it into the main ISIS reflection spec - I am still not
>> seeing the need to send it anywhere by BGP.
>>
>>
>>
>>
>>
>> first, IGP draft is in publication already
>>
>>
>>
>> second, BGP-LS is IDR domain  unless there are plans to move it into LSR
>> charter ?
>>
>>
>>
>> yes, I'm just mildly acerbic/flippant but please, let's stay real here
>> though I know you go to arbitrary lengths often to get a laugh/raised
>> eyebrows ;-)
>>
>>
>>
>> -- tony
>>
>>
>>
>> Orange Restricted
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>>