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

Pushpasis Sarkar <pushpasis.ietf@gmail.com> Mon, 28 October 2019 16:53 UTC

Return-Path: <pushpasis.ietf@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 61E161200F5 for <lsvr@ietfa.amsl.com>; Mon, 28 Oct 2019 09:53:27 -0700 (PDT)
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 q-Uu27wi6WPc for <lsvr@ietfa.amsl.com>; Mon, 28 Oct 2019 09:53:21 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 88A5412013A for <lsvr@ietf.org>; Mon, 28 Oct 2019 09:53:16 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id o16so8775185ilq.9 for <lsvr@ietf.org>; Mon, 28 Oct 2019 09:53:16 -0700 (PDT)
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=bipeOf6W6tBe8DGLOu0qFXacIa52nQ1iZ0RVgilYAIQ=; b=FZlLFXBzH111L/sXz10dx0JkqZ9pQCb6VBvvxTmVZj5xA8suGx4hrhpWTNbZQu7PWa 628/vK+uPCHCVzjARRIBw1E9RiQ5xi2wC/SSIkAUzZV7pC0+Guzm1+yW9YCYA7QkKc16 SDmiP8MMezYkRPvwwUMM5NrN6ccfaBY6vaUV3hrp0qEDWszjIPISv8167zvxItKpCbWk ++8bNqcNzyuS1Xj9kojy03O1jaM1o1oYHjo9UNgvXLw0N46dHqmUJbeeLpU0phNzb2ip 55Xkui9/HoAbNhzFfJyuTRV4xVvS9i8Hlu55SVLwTczSH+WXYH5eiV+PgCds5HT4ufUc U1CA==
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=bipeOf6W6tBe8DGLOu0qFXacIa52nQ1iZ0RVgilYAIQ=; b=Qa7RnRI/deTuMJHdM7AEJmfKmFj4Nxk5Kvmy3KClkwf56ZLE9o4GVDycbtD4jV9Ima QSWFWgPhwDFwAMgquehpeYudIrZaJgP2rg+Uiqqb44P2lIC1eVCsOWh0Sg3IZdpqWCEw skkS5uRlWKA3r6W1QOjTwUwfsNXiBrfYSbvRIXWJYA4hiTHauW2Lsa8JF4VNXKGFuQ8g SHzs9bHmMi8tPKYbwtXV3/ArDPizRruUgRjG90mEdthkSlth/Uzlwlja1AjoRhk1Gc1C zkg5IwSOSgWY+xVLmt0MsK0khFhwAt14BVwCauEZ3rPHOynLuJVXqVFJQ7maWaDpGIbb CFBw==
X-Gm-Message-State: APjAAAU1r7U1zi23+rsAJafhSCHw2uQg9pwCjul7rdrsJUqq8ylKLCg0 Hw3TuzxyxJTRFUSvsm5jKVgr5f+8YBvD0J2AX1k=
X-Google-Smtp-Source: APXvYqyxEESPo2bMH2kR27ljYflQhIhlR4s+ZEKNtZDlA0RJskAgv53egv19SA5GdBvlpwsG+o+Qa2tLpS7ORo1NjOA=
X-Received: by 2002:a92:d6c2:: with SMTP id z2mr20760152ilp.270.1572281595747; Mon, 28 Oct 2019 09:53:15 -0700 (PDT)
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>
In-Reply-To: <CACi9rduPuTWM7WJOzmi+tvFDG5gYwyDGzUO9+cSkWJi6s3fMQA@mail.gmail.com>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Date: Mon, 28 Oct 2019 22:23:03 +0530
Message-ID: <CAEFuwkjc2cfBk2VF7A+vKWxaXXfkd5bZaKZH5NQ33Z-y2Lgy2A@mail.gmail.com>
To: Santosh P K <santosh.pallagatti@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="00000000000000646c0595fb56eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/G1PFBj8gqm45Y522sRBESP9BGVY>
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, 28 Oct 2019 16:53:27 -0000

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
>>
>