Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[Jordan Head <[e-mail]>]

Hi Ketan,

Thanks for reading the draft and taking the time to comment.

[Ketan]
1) The status of this should also be experimental so it is aligned with the IGP spec.

                [Jordan]
As Sue said, good catch, I’ll update this draft to align with the other draft.

[Ketan]
2) Though not strictly required, I would suggest adding some text that covers the description/motivation for adding this into BGP-LS - perhaps a use case or scenario. Normally, the TE use cases are obvious but I am unable to understand the motivation in this case. As an example, we don't have an equivalent of OSPFv2 Type 4 LSA information being signaled into BGP-LS - just because there was no pressing need for it. There are a few other such IGP extensions not exposed to BGP-LS ... but I don't want to give more ideas ;-)

                [Jordan]
I see your point, my answers to #5 and #6 should hopefully make things more obvious.

[Ketan]
3) Reference to RFC8714 is required in addition to RFC2119.

                [Jordan]
I assume you mean RFC8174. Good catch, I’ll add it.

[Ketan]
4) It would be more appropriate to name this TLV as IS-IS Flood Reflection TLV, unless there was some plan to introduce similar for OSPF.

                [Jordan]
Sure, I’ll update it accordingly.

[Ketan]
5) The IS-IS TLV has sub-TLVs but that has not been defined for BGP-LS. Why?

6) Why just this one TLV and not the others from the IS-IS spec? Perhaps the use case (my comment (2)) below can help justify why only this one is required and not the others? Another reason why, IMHO, it is better to keep this extension in the fridge until someone really needs it as an ingredient to cook a deployment solution.

                [Jordan]
                #5 and #6 seem quite similar, so I’ll combine my answers.

The other TLVs are for auto-discovery signal that a node is capable of FR and to signal a potential desire to automatically create tunnels between nodes. An operator may choose to use that functionality or simply configure things manually. Regardless of which option is used, we need to be able to describe the operational IGP state rather than desired state as the two may not necessarily align.

The existing BGP-LS descriptors along with what’s being proposed in the draft should suffice for describing IS-IS Flood Reflection information in a way that’s useful for a controller. For example, which nodes belong to which Flood Reflection cluster and their role within that cluster (Reflector or Client). From this, the controller can derive what’s relevant for TE-paths on top of the Flood Reflection topology.

Thank you
Jordan Head

From: Idr <[e-mail]> on behalf of Susan Hares <[e-mail]>
Date: Thursday, June 16, 2022 at 1:14 PM
To: Ketan Talaulikar <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

[External Email. Be cautious of content]

Ketan:

I encouraged the authors to add this to the LSR document –
since a short LSR+IDR WG LC would be less efforts.
The authors may still consider this pathway to RFC.

Thank you for mention the experimental status, and your
References.

Sue

From: Ketan Talaulikar <[e-mail]>
Sent: Thursday, June 16, 2022 11:19 AM
To: Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)


Hi Sue,

To begin with, I would very much prefer that the authors consider folding this (and other such IGP extensions) into the LSR document into a section that covers BGP-LS. I understand that the LSR document is past WGLC but it still has a way to go through review cycles and it would be simpler and more efficient to just add BGP-LS encoding to it, then do a short LSR+IDR WGLC review and get it off to the IESG.

Either way, the document perhaps needs some updates before considering adoption, and please see the comments below.

1) The status of this should also be experimental so it is aligned with the IGP spec.

2) Though not strictly required, I would suggest adding some text that covers the description/motivation for adding this into BGP-LS - perhaps a use case or scenario. Normally, the TE use cases are obvious but I am unable to understand the motivation in this case. As an example, we don't have an equivalent of OSPFv2 Type 4 LSA information being signaled into BGP-LS - just because there was no pressing need for it. There are a few other such IGP extensions not exposed to BGP-LS ... but I don't want to give more ideas ;-)

3) Reference to RFC8714 is required in addition to RFC2119.

4) It would be more appropriate to name this TLV as IS-IS Flood Reflection TLV, unless there was some plan to introduce similar for OSPF.

5) The IS-IS TLV has sub-TLVs but that has not been defined for BGP-LS. Why?

6) Why just this one TLV and not the others from the IS-IS spec? Perhaps the use case (my comment (2)) below can help justify why only this one is required and not the others? Another reason why, IMHO, it is better to keep this extension in the fridge until someone really needs it as an ingredient to cook a deployment solution.

Thanks,
Ketan


On Tue, Jun 7, 2022 at 2:58 AM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
This begins a 2 week WG adoption call for draft-head-idr-bgp-ls-isis-fr-01.txt

https://datatracker.ietf.org/doc/draft-head-idr-bgp-ls-isis-fr/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-head-idr-bgp-ls-isis-fr/__;!!NEt6yMaO-gk!G0PFxaJ1ZzmvYpV3_4DwRvuQa3J8Gs5m5MjESxwy-w_j-LGYRGbLxd_IMiufXqtLO0swOuqYO3T9$>

  This document defines one new BGP-LS (BGP Link-State) TLV for
   Flood Reflection to match the ISIS TLV for flood reduction.

   The draft is short (5 total pages).

Since this BGP-LS feature has been adopted by IS-IS,
Please consider


  1.  Is there any technical difficulty with adding this to the BGP-LS code points?
2.   Is this draft ready for publication?
3.   Does this addition help operational networks.

Cheers, Sue Hares


_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!G0PFxaJ1ZzmvYpV3_4DwRvuQa3J8Gs5m5MjESxwy-w_j-LGYRGbLxd_IMiufXqtLO0swOsvomuzp$>


Juniper Business Use Only