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

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