Re: [Idr] [draft-ietf-idr-rfc7752bis] Question on explicit withdrawal of BGP-LS NLRI

Nandan Saha <nandan@arista.com> Fri, 15 November 2019 09:30 UTC

Return-Path: <nandan@arista.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 B9B7F1201B7 for <idr@ietfa.amsl.com>; Fri, 15 Nov 2019 01:30:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=arista.com
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 GhGclyaS0KZj for <idr@ietfa.amsl.com>; Fri, 15 Nov 2019 01:30:05 -0800 (PST)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 CFDAB120137 for <idr@ietf.org>; Fri, 15 Nov 2019 01:30:05 -0800 (PST)
Received: by mail-oi1-x235.google.com with SMTP id y194so8084134oie.4 for <idr@ietf.org>; Fri, 15 Nov 2019 01:30:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oaTvbxa1eQDp43RXBJGFBb3AQczpUDoMm/32S4PonNE=; b=gEgpNtevLuzVo4Shm/dR/x4BRFCH2Zp1miNEqnznCzakIToMFRZpzBtYXLCMmw7jVX OgTiPw6zN6ApRit1rFLR8yhm/W37F/AueVLdChdOZ22RFqQ9XGSojetj2r4sLMnZoagt GwlhEPDHWqAugFmyzUgNLLze5a0B9uD92ds5UHU745CXt1GFQyo0VCQTE99g6B3lZO5Z 5sY8QeJhZ9EbqUnUbw1a5/SHflywNhivdmtdNE9EOisRgm9Y68yiKiX/1+BWzqAUdeVs pr/WW3UQkZePCLU8TtyAcE3xiog8sRF8HneGKJPZFieFqlyVc2K2UazXEaXv4u0DEQmL zEtg==
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:content-transfer-encoding; bh=oaTvbxa1eQDp43RXBJGFBb3AQczpUDoMm/32S4PonNE=; b=UFZLK6bb2CauXtSgjbKcouhgiYaBM9ExyecWLZk+dIa0XWvcxIS0AUTAicUGovRwL+ C4oMILChcEeQuJYNFcxXlYuqavvwfvR9CfxnxUL02/k78X8v3huvorSDJ8EXxc1QMZYa DJdJ11hCfA9CXBeQwbrYq3RDOkpY/py7woEeOBJf3ExPnuhIOniOOOjUxgD8Do1vhxR1 USGTFtnpvYpsJmKtqaZZvXp/Hl/FPjarKvhjA3s7Ub9UqqdWz3jFyuf4EcZ99/qfufVu mBn4C/jcZdnrvU+GpeFdxn8XWen4bsvCn9TPSjhL/Cu2U4wBSaylt0cgy44M1jzpLtTf lopw==
X-Gm-Message-State: APjAAAVQA1JcnO6ltyDC1rjwqoIEDsNvqJ65PNWSORCutrUXRF3clUTC pK7fM37v7f1fIlGGRE+gMz6SEjMzIzTQ8HM37REL8w==
X-Google-Smtp-Source: APXvYqynk+wxszX12MwQfdHTESN8lbC5PpHMeH6SNiDQuVdNL7x5nqeHeFOxR3R+S0AyXj5kFM2yoISYYKHLCg1T/b0=
X-Received: by 2002:aca:1c18:: with SMTP id c24mr6858587oic.48.1573810204827; Fri, 15 Nov 2019 01:30:04 -0800 (PST)
MIME-Version: 1.0
References: <CAE+itjeAoU9tXxoZg2sOYYOA94pCrRviUGeoQ43jvTzQhhwOnQ@mail.gmail.com> <MWHPR11MB1552FB3F517C66D05B5E7037C1700@MWHPR11MB1552.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB1552FB3F517C66D05B5E7037C1700@MWHPR11MB1552.namprd11.prod.outlook.com>
From: Nandan Saha <nandan@arista.com>
Date: Fri, 15 Nov 2019 14:59:53 +0530
Message-ID: <CAE+itjenLcUWTSOb-M58c=6KQ5KgC3ZEON9=KA9a+PFPjDrdQQ@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "draft-ietf-idr-rfc7752bis@ietf.org" <draft-ietf-idr-rfc7752bis@ietf.org>, "idr@ietf.org" <idr@ietf.org>, Prakash Badrinarayanan <prakash@arista.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wjSPkIk7HyLehBfaLosUnz67PsM>
Subject: Re: [Idr] [draft-ietf-idr-rfc7752bis] Question on explicit withdrawal of BGP-LS NLRI
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 15 Nov 2019 09:30:09 -0000

Thanks for prompt response Ketan! Makes sense.

On Fri, Nov 15, 2019 at 2:57 PM Ketan Talaulikar (ketant)
<ketant@cisco.com> wrote:
>
> Hi Nandan,
>
> Please check inline below.
>
> -----Original Message-----
> From: Nandan Saha <nandan@arista.com>
> Sent: 15 November 2019 14:25
> To: draft-ietf-idr-rfc7752bis@ietf.org; idr@ietf.org
> Cc: Prakash Badrinarayanan <prakash@arista.com>om>; Ketan Talaulikar (ketant) <ketant@cisco.com>
> Subject: [draft-ietf-idr-rfc7752bis] Question on explicit withdrawal of BGP-LS NLRI
>
> Hi folks,
>
>  I'm trying to understand what the following text is actually mandating:
> >>>>
>  When adding, removing or modifying a TLV/sub-TLV from a Link-State  NLRI, the BGP-LS Producer MUST withdraw the old NLRI by including it in the MP_UNREACH_NLRI.  Not doing so can result in duplicate and in- consistent link-state objects hanging around in the BGP-LS table <<<<
>
> Is it simply about ensuring that the previous incarnation of the NLRI is withdrawn
> [KT] Yes
>   (or)
> is it also mandating some ordering requirements between when the old incarnation is withdrawn and the new one advertised.
> [KT] No
>
> For example, if there's a link nlri say NLRI1 = {  local node descriptor {
>    asn = 100
>    igp router ID = 1111.1111.1111
>  }
>  remote node descriptor {
>    asn = 100
>    igp router ID = 2222.2222.2222
>  }
>  link descriptor {
>    ipv4 Intf address = 1.1.1.1
>    ipv4 neighbor address = 1.1.1.2
> }
> }
>
> Which say subsequently changes such that NLR12 = {  local node descriptor {
>    asn = 100
>    igp router ID = 1111.1111.1111
>  }
>  remote node descriptor {
>    asn = 100
>    igp router ID = 2222.2222.2222
>  }
>  link descriptor {
>    ipv4 Intf address = 4.4.4.4
>    ipv4 neighbor address = 4.4.4.5
>  }
> }
>
> Note that the interface address changed above in NLRI2
>
> In this case, is it sufficient to ensure that a MP_REACH_NLRI is sent with NLRI1 and an MP_UNREACH_NLRI is sent with NLRI1 in _any_ order or is that text mandating something stricter?
> [KT] The text does not talk about order - just about sending MP_UNREACH_NLRI for the old incarnation.
>
> Do both MP_REACH_NLRI=NLRI2 and MP_UNREACH_NLRI=NLRI1 need to be sent in the same UPDATE message or the MP_UNREACH_NLRI has to be sent before the MP_REACH_NLRI if sent in different UPDATE messages?
> [KT] They are separate NLRIs and how to send is implementation aspect. Regardless of how one sends, the receiver would need to handle updates in any order. Note that there may be an RR in the propagation path and so one cannot assume whether the two NLRIs are packed in the same or different update msg.
>
> Thanks,
> Ketan
>
> Thanks,
> Nandan