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 23:44 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 4DD75C14F749 for <idr@ietfa.amsl.com>; Tue, 21 Jun 2022 16:44:02 -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=ham 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 NXcAZrEuoscX for <idr@ietfa.amsl.com>; Tue, 21 Jun 2022 16:43:58 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 B8507C14F72A for <idr@ietf.org>; Tue, 21 Jun 2022 16:43:58 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id cf14so11750156edb.8 for <idr@ietf.org>; Tue, 21 Jun 2022 16:43:58 -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=IFyZnBezPj2ftSRYMPtNxe6MRiar6EQ07WMTt2QmxE8=; b=bQHztf4BMfig8G72FA/BFk2LkJMKtG874Vb0WE1WoZ0MNBZf9hUMjBJl96/EgXVkS1 1CnsosZ/X2xhgKu+48WTXtlDuy8CIh3rRlDPvxDHZ4XU06LdJ6pAQIu0POHisuER0Iku O1eXWchiUeLrW4GnqZoLNHssqgG6x9fXcbIs5pYwpFBCogUKilI70dq32bfvfOIjzQiH K11GXZfjXmO2cS4x2aaSY27hpu4RV+mjtrt4mNe7gfZuWuWuK+BwuhPV0GSEaFvYvOC7 hAIq7uXGYgEB4cP1j33GOaQE9vbvjVjASvLxsYIhW848i10zunnHBav5WP5n+gB2IdSy 0pNw==
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=IFyZnBezPj2ftSRYMPtNxe6MRiar6EQ07WMTt2QmxE8=; b=etiPHqoG1eYtV7IylEK/z6oWZ0s41bT8z5AvIUWGGM6I2FppihTOIhz46qbA0vaZB6 sGypIVlNoVjBqn1qVwZoOoB/sC4XjoRPy3VcdEwnpYlttBB8kefDypBx4UUHstz8jPLc eXG75ZvLd+Zuh0HJGN9PPbOeUK8lCoeo7C4xVjhl3bGysEzON/WG3Yn6UhqniiHya0C/ +LalW7hNboNQx/dTGzOuLvbgN3DX+RuE22dCZAh5a2YvpZ2g3hmCiBjweaS4fwe84se1 vYs85xBuZohv4sVeUw4ekGvVtyFcRWf+9/cGb0/IOY+4Hieqqm7pqb1nvqib55++u40G fh/A==
X-Gm-Message-State: AJIora+NXZo3E+56UHtrorOP/I6hVy8o6JJJDjTTLoGFbXGOsjemCDUk Jt7nePUFMnaCAk/RIxUfLADprFUf9m8aRk5V7e4vTPtmf3o=
X-Google-Smtp-Source: AGRyM1sW3RUF6Bx5cug7qozYiPTm9dfkn+7te17+bYGw4+P70Jn88AOaUiPA654F/9gK/QbS9U7L7mGY5f6SL1oZsFA=
X-Received: by 2002:a05:6402:11d2:b0:42d:e68a:eae0 with SMTP id j18-20020a05640211d200b0042de68aeae0mr725018edw.111.1655855036743; Tue, 21 Jun 2022 16:43:56 -0700 (PDT)
MIME-Version: 1.0
References: <A7C54708-0C2D-45B2-B433-A27A34B3656C@cisco.com> <BYAPR08MB4872D048E710FDC448F5C75AB3B39@BYAPR08MB4872.namprd08.prod.outlook.com> <2AAD304E-36D6-4536-854C-71F97D2FA9D5@pfrc.org> <BY5PR11MB4337C1704EE6D3A9F889798CC1B39@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMEnuKQu_Hf8jgNzhzgizL9syNuPL9qHPeJDvdR2Av86Nw@mail.gmail.com> <0E6D4C59-FE40-490C-9B5E-6584BA53C8BC@cisco.com>
In-Reply-To: <0E6D4C59-FE40-490C-9B5E-6584BA53C8BC@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 22 Jun 2022 01:43:45 +0200
Message-ID: <CAOj+MMEHeOD0WnD2P_08d2QPKxF7=oiR5eyYkxcCnatkxJDHVg@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "idr@ietf.org" <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="00000000000043d6ec05e1fdcbd2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BDC0E2Y379UpuMVlrdRfMa-wqcs>
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 23:44:02 -0000

Hi Acee,

I am afraid the OSPF transport instance draft you quote serves a completely
different purpose.

IMP (IGP Monitoring Protocol) I suggested would be an analogy to BMP (BGP
Monitoring Protocol) unicasting either received flooded LSPs or LSAs or
content of LSDB over TCP or QUIC to some central oracle.

I am not aware such a proposal was ever discussed in LSR WG or its
predecessors WGs.

Many thx,
Robert

PS. And there were and are many real world use cases for such. Till now
folks who needed to listen to link state flooding were always asked to set
up a passive session. But we do see this is not flexible enough. A p2p
protocol is needed. BGP-LS is a living proof of it. In fact IMP could
leverage the exact same encoding as currently sent over BGP-LS SAFI.






On Wed, Jun 22, 2022 at 1:35 AM Acee Lindem (acee) <acee@cisco.com> wrote:

>
>
>
>
> *From: *Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <
> robert@raszuk.net>
> *Date: *Tuesday, June 21, 2022 at 7:23 PM
> *To: *"Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
> *Cc: *IDR List <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)
>
>
>
> Dear Les,
>
>
>
> I have two final questions on this:
>
>
>
> on such a mundane topic.
>
>
>
> Would IDR keeping their WG policy in place and mandating two interoperable
> implementations and decent industry support make this topic a little bit
> less *mundane* ?
>
>
>
> If someone actually has an alternative proposal with some detail – that
> would be interesting.
>
>
>
> This proposal to send LSDB across N nodes should come from and within LSR
> WG as we are talking about LSR protocols. Why IDR is even cc-ed and LSR WG
> is not beats me.
>
>
>
> Why can't LSR WG not come with IMP - IGP Monitoring Protocol ?
>
>
>
> We already have the capability in OSPF – See section 3.3 of
> https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-transport-instance-02.txt
>  We just need more support…
>
>
>
> Thanks,
> Acee
>
>
>
>
>
>
>
> Thx,
> R.
>
>
>
> PS. Actually the way I read Jeff's note was very positive and extended
> help to LSR WG to make the process seamless. But it seems some folks
> apparently think this is all done - do not waste our time - You IDR-ers
> take what we produce in ISIS and OSPF to BGP forever. That's pretty cool
> indeed :)  And another LSR WG member and ex-chair says if you do not take
> it we will squat codepoints and do it anyway ... so you have no choice.
> Bravo !
>
>
>