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

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
>