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

[Pushpasis Sarkar <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> 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 <
>> [e-mail]> wrote:
>>
>>> *Hi Acee, *
>>>
>>> *Needed one more clarification  below.*
>>>
>>> On Wed, Oct 2, 2019 at 1:03 AM Pushpasis Sarkar <
>>> [e-mail]> 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) <[e-mail]>
>>>> 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 <[e-mail]> on behalf of Acee Lindem <
>>>>> [e-mail]>
>>>>> *Date: *Thursday, September 26, 2019 at 10:15 AM
>>>>> *To: *Pushpasis Sarkar <[e-mail]>
>>>>> *Cc: *"YADLAPALLI, CHAITANYA" <[e-mail]>, "[e-mail]" <
>>>>> [e-mail]>
>>>>> *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 <[e-mail]>
>>>>> *Date: *Thursday, September 26, 2019 at 2:53 AM
>>>>> *To: *Acee Lindem <[e-mail]>
>>>>> *Cc: *"YADLAPALLI, CHAITANYA" <[e-mail]>, "[e-mail]" <
>>>>> [e-mail]>
>>>>> *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) <[e-mail]>
>>>>> wrote:
>>>>>
>>>>> Hi Chaitanya,
>>>>>
>>>>> I think this is a good idea and will discuss with my co-authors.
>>>>>
>>>>> Thanks,
>>>>> Acee
>>>>>
>>>>>
>>>>>
>>>>> *From: *"YADLAPALLI, CHAITANYA" <[e-mail]>
>>>>> *Date: *Tuesday, September 24, 2019 at 11:02 AM
>>>>> *To: *Acee Lindem <[e-mail]>, "[e-mail]" <[e-mail]>
>>>>> *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) <[e-mail]>
>>>>> *Sent:* Tuesday, September 24, 2019 10:42 AM
>>>>> *To:* YADLAPALLI, CHAITANYA <[e-mail]>; [e-mail]
>>>>> *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 <[e-mail]> on behalf of "YADLAPALLI,
>>>>> CHAITANYA" <[e-mail]>
>>>>> *Date: *Tuesday, September 24, 2019 at 10:31 AM
>>>>> *To: *"[e-mail]" <[e-mail]>
>>>>> *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  |  [e-mail]
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/lsvr
>>>>>
>>>>> _______________________________________________
>>> Lsvr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsvr
>>>
>>