IETF Logo Mail Archive

Re: [Idr] Opsdir last call review of draft-ietf-idr-rfc7752bis-13

Gyan Mishra <hayabusagsm@gmail.com> Wed, 23 November 2022 04:00 UTC

Return-Path: <hayabusagsm@gmail.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 5A58BC14F728; Tue, 22 Nov 2022 20:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.084
X-Spam-Level:
X-Spam-Status: No, score=-7.084 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 L-5ievsMa4Lh; Tue, 22 Nov 2022 20:00:05 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 42542C14CE2C; Tue, 22 Nov 2022 20:00:05 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id a27so10573402qtw.10; Tue, 22 Nov 2022 20:00:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TEeVWiccy6imuP92RQAMxq6gHr/P2In//nrNydRzjSA=; b=BUeotTBlyoRLStUUMWWQT76/UbzdmQuatomf1ILf0cYWAnJgW5XWE7JI7spqmHPa5J b/zcf0ZBFIbHcm2fwZTdTIQigkxeTaOqU/NaxLAz0eGqWujYonmYEI6X9Dr8qoa/2jYC kik2A5/sJL4m55EeiIyMBsLdqyRcuJs6pRSIkEKsGDS3NFyacdkQ/Em5zhGOnCVFQCxv JRXIpQxWanpAjQhDw+5z1/j52YLfmY74KJiGJFl+X6/uJP1h9Aznv5cz0vRuadic/jcA 9sh9P2UQ1v1cxyT0+LVaodDLrsJpT/BzhnAPvan/NvfuInfjgTPotQjTprk1zzVSP1cr rAeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TEeVWiccy6imuP92RQAMxq6gHr/P2In//nrNydRzjSA=; b=TzPFa+tb+geq41ipfymF2g7MxmspQGFltfSR/+YIAqYlmxiLm7UR5W+NKYrZESJl4b u39wj7Jkd8ptGgwU8Oft/zoEBgUPez3eBDV2JDltRtagdd4/HdLUsjnLGecfoBKhQ0E7 zXwPQTBcnIx3dygW8iNo8vvffboqaFcBYgG0sI19IGp6BeCeeyLAP/kcvbECrlwPwhzs 2EfP9jYgDCekMANl5ElsWuCTZo3cAcX/SbccBBibaJbvLnZekSDkoZk9fIGdSzqpvO9g Xz3pNo3yzKu6yezEASLnDvJSnrj7FJ377LmKTz9KaY6lL2iHaM+QxWNnDr8pms4Db9Fr QR7g==
X-Gm-Message-State: ANoB5pmh+Ek8qMqBY5tXhsRqvaEXRXmnsAms73bGWTKIT0qdjV5mAp9c RJzKNNIJ4m04L+jedgZSDQJLK+ziq3Gi6xIcB0I=
X-Google-Smtp-Source: AA0mqf6ckuSHHDuN+VP26o8bd/i2ZRWUHdvbTTz1HTrjTGxl39864Yw2HkTcMcNdZyRaXAGw0/bLXTvXykK7Dx6VBII=
X-Received: by 2002:ac8:5441:0:b0:3a5:50ba:b20c with SMTP id d1-20020ac85441000000b003a550bab20cmr25354590qtq.588.1669176003891; Tue, 22 Nov 2022 20:00:03 -0800 (PST)
MIME-Version: 1.0
References: <166853127826.27308.14883176524823344383@ietfa.amsl.com> <CAH6gdPw6z21yPEVweMqtazTceLE2arRtHZT_tf0to-w-+F7nHQ@mail.gmail.com> <CABNhwV3wwJA+ckKYnCaD0vr+7hce65QSeqbt9tnaSHPbvPtm7A@mail.gmail.com> <CAH6gdPzaOSLDZVXe2AxMrSFSxphgLFbXQhTH0e89r9GYRybFsw@mail.gmail.com> <CABNhwV2iLjzcoOPnCwjOGW8XMQHZaqvSQAMts+D7QKLUWbP=Zg@mail.gmail.com> <CAH6gdPxWDfYT8tzk94vyeM46KH5KUSjg5h8aV6rmKMz6tbzTDg@mail.gmail.com> <CABNhwV3r6Eh70UP661GrXsCjCp_5fpNW7X6wiP+jTpvpbtWB8g@mail.gmail.com> <CAH6gdPxeqgpofECxHUU=weZjFRojL68UfnAWfsMaVJOki7HHYA@mail.gmail.com> <CABNhwV2PQK1b+ihFdX32f3K_KA2yMg+LFwx1MHD31g8zg7dG5w@mail.gmail.com> <CAH6gdPx6cw8Jchx9JMZPg6ZRAEBo9GV3=ud=VczRYBmhMTmSoA@mail.gmail.com>
In-Reply-To: <CAH6gdPx6cw8Jchx9JMZPg6ZRAEBo9GV3=ud=VczRYBmhMTmSoA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 22 Nov 2022 22:59:52 -0500
Message-ID: <CABNhwV0STB7z02PU=nmG=gJ1i2FdadDAYf7LoaoUX+De0kCWGA@mail.gmail.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: draft-ietf-idr-rfc7752bis.all@ietf.org, idr@ietf.org, last-call@ietf.org, ops-dir@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c7943005ee1b5260"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/MNnV6mInO7bCHTCY1quBjH-ybfU>
Subject: Re: [Idr] Opsdir last call review of draft-ietf-idr-rfc7752bis-13
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: Wed, 23 Nov 2022 04:00:09 -0000

On Mon, Nov 21, 2022 at 7:45 AM Ketan Talaulikar <ketant.ietf@gmail.com>
wrote:

> Hi Gyan,
>
> Please check inline below for response.
>
>
> On Sat, Nov 19, 2022 at 10:23 PM Gyan Mishra <hayabusagsm@gmail.com>
> wrote:
>
>> Hi Ketan
>>
>> You are very welcome!
>>
>> One final suggestion related to the use of RR versus the variety of ways
>> you can setup the BGP-LS AFI/SAFI peering to collect the link state from
>> the BGP-LS producer PEs, and BGP-LS can be very memory and CPU intensive
>> with messaging on the RR.
>>
>
> KT> I do not agree that BGP-LS functionality is CPU intensive on the RR
> (as opposed to other AFI/SAFI). I do agree that depending on the scale, the
> memory requirements may be higher given the amount of information carried
> in BGP-LS.
>

    Gyan> Agreed CPU

>
>
>> My thoughts are maybe a sentence on an possible optimization  is to
>> decouple the BGP-LS producer function off the RR and put it on a dedicated
>> stub RS separate AS eBGP multihop loop to loop peering to two producers per
>> core AS.  This way there heavy processing overhead does not impact the
>> production RRs.
>>
>
> KT> We already have text in Sec 8.1.1 recommending that BGP-LS use
> separate RRs.
>

   Gyan> Agreed I see the dedicated RR recommendation

>
>
>>
>> In Figure 1 it shows BGP-LS producer with peering directly to BGP-LS
>> consumer application.  Is that in cases where an RR is not utilized?
>>
>
> KT> Yes.
>
>
>> If so maybe some wording to explain that direct peering to BGP-LS
>> consumer.
>>
>
> KT> I don't know what to explain here beyond what is already in  Sec 3
> given that the interface to the BGP-LS consumer is out of scope.
>

    Gyan> I think what you have is sufficient then given the BGP-LS is out
of scope

>
> Thanks,
> Ketan
>
>
>> Many Thanks
>>
>> Gyan
>>
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*

v2.23.0 | Report a Bug | By Email