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

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 2 Oct 2019 01:03:49 +0530

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.

Thanks
-Pushpasis

On Sun, Sep 29, 2019 at 12:15 PM Acee Lindem (acee) <[email-masked]> 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 <[email-masked]> on behalf of Acee Lindem <
> [email-masked]>
> *Date: *Thursday, September 26, 2019 at 10:15 AM
> *To: *Pushpasis Sarkar <[email-masked]>
> *Cc: *"YADLAPALLI, CHAITANYA" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *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 <[email-masked]>
> *Date: *Thursday, September 26, 2019 at 2:53 AM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *"YADLAPALLI, CHAITANYA" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *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) <[email-masked]> wrote:
>
> Hi Chaitanya,
>
> I think this is a good idea and will discuss with my co-authors.
>
> Thanks,
> Acee
>
>
>
> *From: *"YADLAPALLI, CHAITANYA" <[email-masked]>
> *Date: *Tuesday, September 24, 2019 at 11:02 AM
> *To: *Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
> *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) <[email-masked]>
> *Sent:* Tuesday, September 24, 2019 10:42 AM
> *To:* YADLAPALLI, CHAITANYA <[email-masked]>; [email-masked]
> *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 <[email-masked]> on behalf of "YADLAPALLI, CHAITANYA"
> <[email-masked]>
> *Date: *Tuesday, September 24, 2019 at 10:31 AM
> *To: *"[email-masked]" <[email-masked]>
> *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  |  [email-masked]
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsvr
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 2 Oct 2019 00:40:37 +0000

Hi Pushpasis,

From: Pushpasis Sarkar <[email-masked]>
Date: Tuesday, October 1, 2019 at 3:34 PM
To: Acee Lindem <[email-masked]>
Cc: "YADLAPALLI, CHAITANYA" <[email-masked]>, "[email-masked]" <[email-masked]>
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 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) <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> on behalf of Acee Lindem <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 26, 2019 at 10:15 AM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>
Cc: "YADLAPALLI, CHAITANYA" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 26, 2019 at 2:53 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "YADLAPALLI, CHAITANYA" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chaitanya,
I think this is a good idea and will discuss with my co-authors.
Thanks,
Acee

From: "YADLAPALLI, CHAITANYA" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 24, 2019 at 11:02 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf

Correct like a R-Bit.

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) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, September 24, 2019 10:42 AM
To: YADLAPALLI, CHAITANYA <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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

Thanks,
Acee

From: Lsvr <[email-masked]<mailto:[email-masked]>> on behalf of "YADLAPALLI, CHAITANYA" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 24, 2019 at 10:31 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

AT&T Services, Inc.
200 S Laurel Ave, Middletown, NJ 07722
o  732.420.7977  |  [email-masked]<mailto:[email-masked]>

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsvr

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 2 Oct 2019 12:11:40 +0530

Hi Acee,

Thanks for the clarification. Looks good to me.

Best regards,
-Pushpasis

On Wed, Oct 2, 2019 at 6:10 AM Acee Lindem (acee) <[email-masked]> wrote:

> *Date: *Tuesday, October 1, 2019 at 3:34 PM
> 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.
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Santosh P K <[email-masked]>
Date: Thu, 3 Oct 2019 20:15:29 +0530

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

---

From: Keyur Patel <[email-masked]>
Date: Thu, 3 Oct 2019 17:18:48 +0000

Hi Santosh,

We can add the use case in the applicability draft. This bit could be used when you have a RR/Controller based peering model in CLOS (where RR/Controllers are not in the forwarding path). You may want RR/Controller to announce its reachability using H-bit so that they are not being used as a transit.

Regards,
Keyur

From: Lsvr <[email-masked]> on behalf of Santosh P K <[email-masked]>
Date: Thursday, October 3, 2019 at 7:46 AM
To: "Acee Lindem (acee)" <[email-masked]>
Cc: Pushpasis Sarkar <[email-masked]>, "YADLAPALLI, CHAITANYA" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf
Resent-From: <[email-masked]>

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pushpasis,

Hi Acee,

Thanks,
Acee

Thanks
-Pushpasis

                          0 – Reserved

Comments?

Thanks,
Acee

Hi Pushpasis,

Hi Chaitanya and Acee,

Thanks
-Pushpasis

Correct like a R-Bit.

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.

Hi Chaitanya,

   R-bit

Thanks,
Acee

Hi Authors,

Thanks,
Chaitanya

Chaitanya Yadlapalli

AT&T Services, Inc.

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: Jeff Tantsura <[email-masked]>
Date: Thu, 3 Oct 2019 10:57:09 -0700

Keyur,

RR (or route server in eBGP case) don't reset the NH so if they are not in the forwarding path, traffic will never go through them anyway (and you don’t want inconsistent connectivity graph just because you happen to run RR on one of the devices in path).
Much more realistic use case would be traffic draining, where, before you go into maintenance, you’d like to divert as much traffic as possible (all transit).

Cheers,
Jeff
On Oct 3, 2019, 10:19 AM -0700, Keyur Patel <[email-masked]>, wrote:
> > > From: Lsvr <[email-masked]> on behalf of Acee Lindem <[email-masked]>
> > > To: Pushpasis Sarkar <[email-masked]>
> > > > From: "YADLAPALLI, CHAITANYA" <[email-masked]>
> > > > To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
> > > > From: Acee Lindem (acee) <[email-masked]>
> > > > To: YADLAPALLI, CHAITANYA <[email-masked]>; [email-masked]
> > > > From: Lsvr <[email-masked]> on behalf of "YADLAPALLI, CHAITANYA" <[email-masked]>
> > > > To: "[email-masked]" <[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 7 Oct 2019 19:41:28 +0000

Agreed. There could be cases where you have multi-homed leaf switches that you never want used for transit traffic.

From: Jeff Tantsura <[email-masked]>
Date: Thursday, October 3, 2019 at 1:57 PM
To: Santosh P K <[email-masked]>, Acee Lindem <[email-masked]>, Keyur Patel <[email-masked]>
Cc: Pushpasis Sarkar <[email-masked]>, "YADLAPALLI, CHAITANYA" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsvr] Mail regarding draft-ietf-lsvr-bgp-spf

Keyur,

Cheers,
Jeff

Hi Santosh,

Regards,
Keyur

All,

Thanks
Santosh P K

Hi Acee,

Thanks,
Acee

Thanks
-Pushpasis

                          0 – Reserved

Comments?

Thanks,
Acee

Hi Pushpasis,

Hi Chaitanya and Acee,

Thanks
-Pushpasis

Correct like a R-Bit.

Thanks,
Chaitanya

Hi Chaitanya,

   R-bit

Thanks,
Acee

Hi Authors,

Thanks,
Chaitanya

Chaitanya Yadlapalli

AT&T Services, Inc.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 10 Oct 2019 12:15:24 +0530

*Hi Acee, *

*Needed one more clarification  below.*

>           doesn't support transit, the next link for the current node is
*[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*

>> 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
>> *From: *Lsvr <[email-masked]> on behalf of "YADLAPALLI,
>> CHAITANYA" <[email-masked]>

---

From: Santosh P K <[email-masked]>
Date: Mon, 28 Oct 2019 20:32:44 +0530

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 <[email-masked]>
wrote:

>>> confidential.. If you are not the intended recipient, please note that any
>>> confidential.. If you are not the intended recipient, please note that any

---

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 28 Oct 2019 22:23:03 +0530

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 <[email-masked]>
wrote:

> On Thu, Oct 10, 2019 at 12:15 PM Pushpasis Sarkar <
> [email-masked]> wrote:
>
>> *Hi Acee, *
>>
>> *[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