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

All,
    If R-bit or H-bit functionality is being introduced then wanted to know
should you not callout for use case here? Use-cases in applicability
document does not cover this and would like to also understand how this can
be used CLOS and non-CLOS/FAT-tree topology.

Thanks
Santosh P K

On Wed, Oct 2, 2019 at 6:10 AM Acee Lindem (acee) <acee@cisco.com> wrote:

> Hi Pushpasis,
>
>
>
> *From: *Pushpasis Sarkar <pushpasis.ietf@gmail.com>
> *Date: *Tuesday, October 1, 2019 at 3:34 PM
> *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 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."
>
>
>
> 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.
>
>
>
> In this case, the current node is not unreachable as we’ve already taken
> it off the candidate list and processed the local prefixes. Optionally, the
> interface addresses on the current node have also been installed. At this
> point, we are simply not using any of the links in the SPF graph which will
> have the effect of preventing transit traffic.
>
>
>
> Thanks,
>
> Acee
>
>
>
> 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
>