Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf

Santosh P K <santosh.pallagatti@gmail.com> Mon, 11 November 2019 14:33 UTC

Return-Path: <santosh.pallagatti@gmail.com>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D12E120086 for <lsvr@ietfa.amsl.com>; Mon, 11 Nov 2019 06:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEAU9L3ZN8Bf for <lsvr@ietfa.amsl.com>; Mon, 11 Nov 2019 06:33:28 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 31BF012009C for <lsvr@ietf.org>; Mon, 11 Nov 2019 06:33:28 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id q70so13574901wme.1 for <lsvr@ietf.org>; Mon, 11 Nov 2019 06:33:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EJB4jfmhm17QG8mwvxQt1RM5bJRgGpuwAp7Dapei/1E=; b=XBe6eile0x4ZyaJ2ghqxQbLJnwBqWzD5OwSPSouhHQQjozVzCBY/wDsCje8XcbM72G b/YhvJq7LzpfhWrv5ZuZqq6F3XgvdBIAiqTUekLTWxLBPatFCKUjGOL4IHwNiWNEzz5t m9QSb2QK/nzjqE1RxVyBUdhtaXlIyEAgfKoOIhCnGicF/5Xw4lP7bgJXlvVdtprnuXYv aWyyM2/vb0IVSANJNyih09gHFcLQe4gqr7iUst5MZanCr1THBe1TEXZGPlwaBi0m5GIG qAUsf8xlHDJ+5vSCnCUrmlFlSkDm80ochhGN2SVa09VCjQuRekKEyVrdkBk3ygiSrAOT soQA==
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=EJB4jfmhm17QG8mwvxQt1RM5bJRgGpuwAp7Dapei/1E=; b=SDcPZt7cGrFB02rhLd1b3MV87zH1LBHx9xTrF7jqct/7G2ETFirK84UTSqK757T2M4 WheQHYAHZRn2OnLGSbD1rsDo1RbTc2CJJYQV2fqjm6kcs0fybTJHOwoEojCjFxNVHK9R HFhbOp1GBxkEQRYgB+fHHD9p3JnYhVEMIqLt7JYpOWkp2oJHaQwjkjOAXeV9PUQVhYwp wQnIeJTU5ZbVGJzh2iAzIt8TYKSwQ5+fgl/YvLjYEc/3CrVuWb4NsZp341DF/uURYcYm uBloLbOLaRgqVfbCAfFA6eOP/H0Qp1uXkLr1D3/qGCWoreR0vTkSDJDThacAUA26VBVW 7n7w==
X-Gm-Message-State: APjAAAUlwBuSGXSZH+i3QjnloICz8ybyHAx3QegC965rW2Owb5ZzRS4j PGsqGp9PYKVXwqo82+edM3QQ2XKzOT58M8RrYkQ=
X-Google-Smtp-Source: APXvYqxrAoNFrlVEilYO5lAEVRs0lKASqvsofgSbJmY03eTHAPKYcdCjrvw/OwaFBOfLe3sGHhHmUnzr+cUoqvzGbHU=
X-Received: by 2002:a1c:a9cb:: with SMTP id s194mr22107457wme.92.1573482806572; Mon, 11 Nov 2019 06:33:26 -0800 (PST)
MIME-Version: 1.0
References: <D2BB4EDE-97FD-4A82-A93D-45203A34A339@cisco.com> <CA0B675FC61D874D8A9EB2C7B5CEA7872B6A7E11@MISOUT7MSGUSRDG.ITServices.sbc.com> <1DBF92B2-D384-4071-9156-B20795F099AB@cisco.com> <CAEFuwki8QBRL=ZXFy46RCgTyUX4ffYvVAeRe-rFwbcqL=zLRLw@mail.gmail.com> <0A1F41E2-AC1E-4724-A8B6-DE855088FDF4@cisco.com> <1B89E943-C2D0-41C9-B8FE-17CA7F0240EA@cisco.com> <CAEFuwkg_dg2ASfjqzo1_MAfOHh+HB6jLecftFgRh0wTaYRJgYA@mail.gmail.com> <CAEFuwkhuP4J_1RHNU-JyUReE8ZTLZgendPivHL4zHGOszXkaEw@mail.gmail.com> <CACi9rduPuTWM7WJOzmi+tvFDG5gYwyDGzUO9+cSkWJi6s3fMQA@mail.gmail.com> <CAEFuwkjc2cfBk2VF7A+vKWxaXXfkd5bZaKZH5NQ33Z-y2Lgy2A@mail.gmail.com> <CAEFuwkhTEw0OC0vn6kXcMdtUC+9M96BPrq_YAcqX9hj=pgFHPQ@mail.gmail.com>
In-Reply-To: <CAEFuwkhTEw0OC0vn6kXcMdtUC+9M96BPrq_YAcqX9hj=pgFHPQ@mail.gmail.com>
From: Santosh P K <santosh.pallagatti@gmail.com>
Date: Mon, 11 Nov 2019 20:03:15 +0530
Message-ID: <CACi9rduUkGgMiAkqykUZVEyMDxUNJs8LfCWc+7Ui4G=yocETsg@mail.gmail.com>
To: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "YADLAPALLI, CHAITANYA" <cy098d@att.com>, "lsvr@ietf.org" <lsvr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000befc960597130375"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/EAihjeOGfN8sC6kE3YDapc0vXuQ>
Subject: Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 14:33:31 -0000

Thanks Pushpasis.

On Fri, Nov 8, 2019 at 9:54 AM Pushpasis Sarkar <pushpasis.ietf@gmail.com>;
wrote:

> Hi Santosh,
>
> Sorry for the late reply. Please find attached the packet captures from
> our implementation of BGP-SPF.
>
> Let me know if you need any other help.
>
> Thanks and regards
> -Pushpasis
>
>
>
> On Mon, Oct 28, 2019 at 10:23 PM Pushpasis Sarkar <
> pushpasis.ietf@gmail.com>; wrote:
>
>> Hi Santosh,
>>
>> Good to know about the progress on your side. I will try to get some
>> packet captures from our implementations and send it to you at the earliest
>> possible.
>>
>> Thanks
>> -Pushpasis
>>
>> On Mon, Oct 28, 2019 at 8:32 PM Santosh P K <santosh.pallagatti@gmail.com>;
>> wrote:
>>
>>> All,
>>>    Can anyone please help me with BGP-LS-SPF packet hex dump? We have
>>> code added for encode and decode and wanted to understand if we can get
>>> some hexdump to interop.
>>>
>>> Thanks
>>> Santosh P K
>>>
>>> On Thu, Oct 10, 2019 at 12:15 PM Pushpasis Sarkar <
>>> pushpasis.ietf@gmail.com>; wrote:
>>>
>>>> *Hi Acee, *
>>>>
>>>> *Needed one more clarification  below.*
>>>>
>>>> On Wed, Oct 2, 2019 at 1:03 AM Pushpasis Sarkar <
>>>> pushpasis.ietf@gmail.com>; wrote:
>>>>
>>>>> Hi Acee,
>>>>>
>>>>> Just saw the latest version of the draft. I wanted to understand what
>>>>> is the exact difference between the values 1 and 2. Just to clarify my
>>>>> doubt let's consider a prefix P that is only originated by node N. Now what
>>>>> will be the reachability of prefix P in the two scenarios (first with SPF
>>>>> Status TLV value set to 1 vs with SPF Status TLV value set to 2). Will P be
>>>>> unreachable in both cases? My understanding is it should still be reachable
>>>>> when the value is set to 2.
>>>>>
>>>>> If my understanding is correct, then perhaps we need more
>>>>> clarifications on the following text.. especially for the case there is no
>>>>> next link from this node.
>>>>>
>>>>> "If the current Node NLRI attributes includes the SPF status
>>>>>
>>>>>           TLV (Section 4.1.2) and the status indicates that the Node
>>>>>
>>>>>           doesn't support transit, the next link for the current node
>>>>> is
>>>>>           processed."
>>>>>
>>>> *[Pushpasis] This condition applies to all the links originating from
>>>> this current node NLRI. So does it mean none of the links origination from
>>>> the current node will be processed? If so, the last statement ("the next
>>>> link for the current node is processed") part is misleading. We can perhaps
>>>> re-work to avoid processing any of the links from the current node NLRI
>>>> under such scenario in a different step between step 4 and step 5.*
>>>>
>>>> *Thanks*
>>>> *-Pushpasis*
>>>>
>>>>
>>>>> If the P is unreachable in the later case too (value set to 2), then I
>>>>> don't see what is the difference between using the values 1 and 2.
>>>>>
>>>>> Thanks
>>>>> -Pushpasis
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Sep 29, 2019 at 12:15 PM Acee Lindem (acee) <acee@cisco.com>;
>>>>> wrote:
>>>>>
>>>>>> After discussion with my co-authors and Pushpasis, we are planning on
>>>>>> defining an SPF Status TLV for the Node Attribute NLRI analogous to the one
>>>>>> defined for Links and Prefixes. However, for the Node Attribute TLV, the
>>>>>> status would have an additional value indicating the node should not be
>>>>>> used for transit traffic.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                           0 – Reserved
>>>>>>
>>>>>>                           1 – Node unreachable with respect to BGP
>>>>>> SPF
>>>>>>
>>>>>>                           2 – Node does not support transit with
>>>>>> respect to BGP SPF
>>>>>>
>>>>>>                   3-254 – Undefined
>>>>>>
>>>>>>                       255 – Reserved
>>>>>>
>>>>>>
>>>>>>
>>>>>> Comments?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Acee
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Lsvr <lsvr-bounces@ietf.org>; on behalf of Acee Lindem <
>>>>>> acee@cisco.com>;
>>>>>> *Date: *Thursday, September 26, 2019 at 10:15 AM
>>>>>> *To: *Pushpasis Sarkar <pushpasis.ietf@gmail.com>;
>>>>>> *Cc: *"YADLAPALLI, CHAITANYA" <cy098d@att.com>;, "lsvr@ietf.org"; <
>>>>>> lsvr@ietf.org>;
>>>>>> *Subject: *Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Pushpasis,
>>>>>>
>>>>>> This OSPFv3 R Bit and IS-IS O bit are basically the same
>>>>>> functionality. The node is not used for transit but is used for local
>>>>>> prefixes.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Acee
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Pushpasis Sarkar <pushpasis.ietf@gmail.com>;
>>>>>> *Date: *Thursday, September 26, 2019 at 2:53 AM
>>>>>> *To: *Acee Lindem <acee@cisco.com>;
>>>>>> *Cc: *"YADLAPALLI, CHAITANYA" <cy098d@att.com>;, "lsvr@ietf.org"; <
>>>>>> lsvr@ietf.org>;
>>>>>> *Subject: *Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Chaitanya and Acee,
>>>>>>
>>>>>>
>>>>>>
>>>>>> How about the 'O' bit in Node-Flag-Bits TLV defined in RFC 7752
>>>>>> section 3.3.1.1? I suppose the node can set the 'O' bit when it wants to
>>>>>> take itself out from all transit paths. I know the 'O' bit is more related
>>>>>> to the scenario when ISIS topology is being exported in BGP-LS. But I
>>>>>> suppose we can use that for BGP-LS-SPF as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Pushpasis
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 24, 2019 at 8:35 PM Acee Lindem (acee) <acee@cisco.com>;
>>>>>> wrote:
>>>>>>
>>>>>> Hi Chaitanya,
>>>>>>
>>>>>> I think this is a good idea and will discuss with my co-authors.
>>>>>>
>>>>>> Thanks,
>>>>>> Acee
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *"YADLAPALLI, CHAITANYA" <cy098d@att.com>;
>>>>>> *Date: *Tuesday, September 24, 2019 at 11:02 AM
>>>>>> *To: *Acee Lindem <acee@cisco.com>;, "lsvr@ietf.org"; <lsvr@ietf.org>;
>>>>>> *Subject: *RE: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>>>>>
>>>>>>
>>>>>>
>>>>>> Correct like a R-Bit.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have read this draft and I support it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Chaitanya
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This communication may contain information that is privileged, or
>>>>>> confidential.. If you are not the intended recipient, please note that any
>>>>>> dissemination, distribution or copying of this communication is strictly
>>>>>> prohibited.  Anyone who receives this message in error should notify the
>>>>>> sender immediately by telephone or by return e-mail and delete it from his
>>>>>> or her computer.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Acee Lindem (acee) <acee@cisco.com>;
>>>>>> *Sent:* Tuesday, September 24, 2019 10:42 AM
>>>>>> *To:* YADLAPALLI, CHAITANYA <cy098d@att.com>;; lsvr@ietf.org
>>>>>> *Subject:* Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Chaitanya,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Exactly what do you mean by node cost out and what use case are you
>>>>>> trying to satisfy. If a node wants to remove itself from the topology, it
>>>>>> can simply withdraw its link NLRI. However, are you looking for a mechanism
>>>>>> similar to the OSPFv3 R-Bit as a Node NLRI SPF Attribute?
>>>>>>
>>>>>>
>>>>>>
>>>>>>    R-bit
>>>>>>
>>>>>>       This bit (the `Router' bit) indicates whether the originator is
>>>>>> an
>>>>>>
>>>>>>       active router.  If the router bit is clear, then routes that
>>>>>>
>>>>>>       transit the advertising node cannot be computed.  Clearing the
>>>>>>
>>>>>>       router bit would be appropriate for a multi-homed host that
>>>>>> wants
>>>>>>
>>>>>>       to participate in routing, but does not want to forward non-
>>>>>>
>>>>>>       locally addressed packets.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Acee
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *Lsvr <lsvr-bounces@ietf.org>; on behalf of "YADLAPALLI,
>>>>>> CHAITANYA" <cy098d@att.com>;
>>>>>> *Date: *Tuesday, September 24, 2019 at 10:31 AM
>>>>>> *To: *"lsvr@ietf.org"; <lsvr@ietf.org>;
>>>>>> *Subject: *[Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Authors,
>>>>>>
>>>>>> The draft does not explicitly call out mechanisms for node cost out.
>>>>>> It would be good to call out mechanisms to cost out a node explicitly.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Chaitanya
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Chaitanya Yadlapalli*
>>>>>>
>>>>>> Network Infrastructure And Services
>>>>>>
>>>>>>
>>>>>>
>>>>>> *AT&T Services, Inc.*
>>>>>>
>>>>>> 200 S Laurel Ave, Middletown, NJ 07722
>>>>>>
>>>>>> o  732.420.7977  |  cy098d@att.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> This communication may contain information that is privileged, or
>>>>>> confidential.. If you are not the intended recipient, please note that any
>>>>>> dissemination, distribution or copying of this communication is strictly
>>>>>> prohibited.  Anyone who receives this message in error should notify the
>>>>>> sender immediately by telephone or by return e-mail and delete it from his
>>>>>> or her computer.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Lsvr mailing list
>>>>>> Lsvr@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/lsvr
>>>>>>
>>>>>> _______________________________________________
>>>> Lsvr mailing list
>>>> Lsvr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lsvr
>>>>
>>>