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

[Ketan Talaulikar <[e-mail]>]

Hi Jordan,

Thanks for your response and please check inline below for what needs
further discussion.


On Tue, Jun 21, 2022 at 11:10 PM Jordan Head <[e-mail]> wrote:

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

KT> The operational IGP info is what is advertised in BGP-LS. So you are
saying that the Flood Reflection Discovery Sub-TLV is also good to get into
BGP-LS so the controller can see which devices have the capability
(+config) to participate as reflector/client?


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

KT> Isn't the tunnel advertisement and its status (i.e. whether an
adjacency is formed over it) also equally important/essential. I don't
claim to have read/followed the flood reflection work very closely, but my
high-level understanding was that if a controller needs to
understand/monitor IGP topologies with this feature enabled, it would need
to know of all of these aspects?

Thanks,
Ketan


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