Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Robert Raszuk <robert@raszuk.net> Wed, 10 March 2021 11:52 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA013A22BA for <lsr@ietfa.amsl.com>; Wed, 10 Mar 2021 03:52:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BB1r4orfHIbl for <lsr@ietfa.amsl.com>; Wed, 10 Mar 2021 03:52:11 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 9E21C3A22BB for <lsr@ietf.org>; Wed, 10 Mar 2021 03:52:10 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id v9so32995605lfa.1 for <lsr@ietf.org>; Wed, 10 Mar 2021 03:52:10 -0800 (PST)
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=KX6B3USj7Tc24rqGmHiEUf/AK1jUMpdgiBZWU5PHS08=; b=QM8Mt6YHszN7qfdepCKnlJOuB4TuWaOiM2ib8/mmhrjJE0XzCTFPnWfCsOxZ56lmmD jV5al34Z+G/QVvkqCAGODEhiybm7hVLS2cS76Z1tOFSmJlnfaO+zERvK4HRoSGdupGla iY3kElh47B7zPEgeUCvq/KJOKAF44TFeg3RFJMW7i8ri/L5tTYGh6SSH/ei0J/gL1G71 bRm5gsJnJxNs/WrYCc/XEM6Ly3RIM/nkbGHqExKmREfxOzPSt+H7VkPWXD7GDSGuZjJ4 k+kZQMgnnv33RFw2Uj63sZSXb9H6ONMZuGZoisCC/h7U0S9kNAWS1Serz1cSmwm+vkTQ yuUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KX6B3USj7Tc24rqGmHiEUf/AK1jUMpdgiBZWU5PHS08=; b=UC02ljlcmFKXG3D1wYXf0OGIRyJPgllfQSpVstq/LVbSgseIqMI/ns0bm0TvcDu7HM MgbPEtJcB0HHHQ2QgKPajJUYcx0Tcg/meRX/UiwAQZ27q0vnlRkMn0U8oQ82j3aYnhgJ GoywsYHpVWBpZ/bm4vgR1yLyTWEsjGzMWrUtd0CiTWb+oFyvYmSJwFoXjxInl+uZuKBz fn08vvLG6ONofvgrmQGP68YVkkyCUJW9bZrs1Gqv9xT7xXQadTylWXarlcskOzy/th1H Zz/5kd7U8K0OOmcl4tlf+QStgRlrtXC7yd6rOWH9T6txtksoalWs6X5Py00spbYmsN/r sRDw==
X-Gm-Message-State: AOAM53244RB4/0k+WsDK6S3SURbBz8h4Vpkz4bbUwLtCxyzAkBi1Gsvg 9IBPSuT8Q5rpLnOpaoEh1yMacmA4xe00/KL3PuEWXA==
X-Google-Smtp-Source: ABdhPJyuLono65z+lzSd1b6372NrFEGUs+qkWCzROFmxyh441lov/L94LWRRWDzuXIc+2sAKdT+cNrLOrSOiSYlcjko=
X-Received: by 2002:a19:d8:: with SMTP id 207mr1921815lfa.602.1615377127548; Wed, 10 Mar 2021 03:52:07 -0800 (PST)
MIME-Version: 1.0
References: <22FDE3EA-B5D1-4E4D-B698-1D79173E8637@tony.li> <6E0281D2-7755-499A-B084-CA8472949683@chinatelecom.cn> <D6B0D95F-68AD-4A18-B98C-69835E8B149B@tony.li> <018801d71499$9890feb0$c9b2fc10$@tsinghua.org.cn> <CABNhwV2SpcDcm-s-WkWPpnVLpYB2nZGz2Yv0SfZah+-k=bGx4A@mail.gmail.com> <BFB3CE24-446A-4ADA-96ED-9CF876EA6A00@tony.li> <CAOj+MMGeR4bodbgpPqDCtLZD6XmX6fkjyxLWZAKa4LC2R1tBzg@mail.gmail.com> <ecf2e8b4-fdae-def6-1a29-ec1ae37f5811@cisco.com> <CAOj+MMFSEqVkM62TDAc6yn19Hup+v-9w=kiq_q6dVn39LcOkqQ@mail.gmail.com> <fdf0e62a-21fa-67e9-811d-5aa8749bb077@cisco.com> <CAOj+MMGqab_MSeZuwu0jLpCiDoZrcjnjebScscULsvnJt4_Sgw@mail.gmail.com> <2b2e9a39-ee2d-ab1c-2d59-ff5847c943e8@cisco.com> <CAOj+MMETEOgA_QO0V_k052cu10a2ZVkf8at-1+kut7OQwf=Kug@mail.gmail.com> <14e8038e-338f-599e-3c40-fdaac247fc10@cisco.com> <CAOj+MMF4xdh2TsMWVEmw_qUxxTS-zFbtE4xK8-cL-cw3xmcrgg@mail.gmail.com> <CA+wi2hMfXNV9m2WKapLCT1L9s5odXD+imJU=YXp0SfNPdbcCtQ@mail.gmail.com>
In-Reply-To: <CA+wi2hMfXNV9m2WKapLCT1L9s5odXD+imJU=YXp0SfNPdbcCtQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 10 Mar 2021 12:51:58 +0100
Message-ID: <CAOj+MMFXekqgbbyLZz=TjtZ0V_NKM_=MCpjRQv18Vj2OPGJOHw@mail.gmail.com>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: Peter Psenak <ppsenak@cisco.com>, Gyan Mishra <hayabusagsm@gmail.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, Aijun Wang <wangaj3@chinatelecom.cn>, Tony Li <tony.li@tony.li>, lsr <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ddbabe05bd2d4b24"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/oZu9rB2cUEt_Rh2O9xHn_zCrD-M>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Mar 2021 11:52:13 -0000

>  You think Kafka here?

Nope ... I meant ZeroMQ message bus as underlaying pub-sub transport for
service related info.

Thx,
R.,


On Wed, Mar 10, 2021 at 11:41 AM Tony Przygienda <tonysietf@gmail.com>
wrote:

> ? Last time I looked @ it (and it's been a while) Open-R had nothing of
> that sort, it was basically KV playing LSDB (innovative and clever in
> itself). You think Kafka here? Which in turn needs underlying IGP however
> and is nothing but BGP problems in new clothes having looked @ their
> internal architecture and where it's goiing a while ago.
>
> -- tony
>
> On Wed, Mar 10, 2021 at 11:29 AM Robert Raszuk <robert@raszuk.net> wrote:
>
>> Peter,
>>
>> > But suddenly the DOWN event distribution is considered
>> > problematic. Not sure I follow.
>>
>> In routing and IP reachability we use p2mp distribution and flooding as
>> it is required to provide any to any connectivity.
>>
>> Such spray model no longer fits services where not every endpoint
>> participates in all services.
>>
>> So my point is that just because you have transport ready we should not
>> continue to announce neither good nor bad news in spray fashion for
>> services.
>>
>> Sure it works, but it is hardly a good design and sound architecture.
>>
>> It happened to BGP as the convenience of already having TCP sessions
>> between nodes was so great that we loaded loads of stuff to go along basic
>> routing reachability.
>>
>> And now it seems time came to do the same with IGPs :).
>>
>> I think unless we stop and define a real pub-sub messaging protocol (like
>> FB does with open-R)  we will continue this.
>>
>> And to me it is like building a tower from the cards ... the higher you
>> go the more likely your entire tower is to collapse.
>>
>> Cheers,
>> R.
>>
>> PS.
>>
>> > with MPLS loopback address of all PEs is advertised everywhere.
>>
>> Is this a feature or a day one design bug later fixed by RFC5283 ?
>>
>>
>>
>>
>> On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak <ppsenak@cisco.com> wrote:
>>
>>> Robert,
>>>
>>>
>>> On 09/03/2021 19:30, Robert Raszuk wrote:
>>> > Hi Peter,
>>> >
>>> >      > Example 1:
>>> >      >
>>> >      > If session to PE1 goes down, withdraw all RDs received from
>>> such PE.
>>> >
>>> >     still dependent on RDs and BGP specific.
>>> >
>>> >
>>> > To me this does sound like a feature ... to you I think it was rather
>>> > pejorative.
>>>
>>> not sure I understand your point with "pejorative"...
>>>
>>> There are other ways to provide services outside of BGP - think GRE,
>>> IPsec, etc. The solution should cover them all.
>>>
>>> >
>>> >     We want app independent way of
>>> >     signaling the reachability loss. At the end that's what IGPs do
>>> without
>>> >     a presence of summarization.
>>> >
>>> >
>>> > Here you go. I suppose you just drafted the first use case for OSPF
>>> > Transport Instance.
>>>
>>> you said it, not me.
>>>
>>>
>>> >
>>> > I suppose you just run new ISIS or OSPF Instance and flood info about
>>> PE
>>> > down events to all other instance nodes (hopefully just PEs and no Ps
>>> as
>>> > such plane would be OTT one).  Still you will be flooding this to 100s
>>> > of PEs which may never need this information at all which I think is
>>> the
>>> > main issue here. Such bad news IMHO should be distributed on a pub/sub
>>> > basis only. First you subscribe then you get updates ... not get
>>> > everything then keep junk till it get's removed or expires.
>>>
>>> with MPLS loopback address of all PEs is advertised everywhere. So you
>>> keep the state when the remote PE loopback is up and you get a state
>>> withdrawal when the remote PE loopback goes down.
>>>
>>> In Srv6, with summarization we can reduced the amount of UP state to
>>> minimum. But suddenly the DOWN event distribution is considered
>>> problematic. Not sure I follow.
>>>
>>> thanks,
>>> Peter
>>>
>>> >
>>> > Many thx,
>>> > Robert
>>> >
>>>
>>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>