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

[Tony Przygienda <[e-mail]>]

Ketan, AFAIS tunnel status is not part of IGP state and should be derived
from alternate mechanisms just like interface up/down state on the node. We
don't carry interface up/down in BGP-LS today and should not (observe that
I really mean admin/phy up/down and not IGP adj up/down here).  And then,
those L1 tunnels either form IGP adjacencies on them in which case you'll
get them in BGP-LS as neighbors or they use something alternate like e.g.
BFD (or nothing at all possibly) and at this point it will become really
weird to carry in BGP-LS an L1 tunnel which does not have IGP adjacency on
it ...

open to suggestions but AFAIS the FR/client L2 adjacencies are in BGP-LS
already per normal procedures (and the fact that you see client/reflector
flag on both nodes & cluster ID allows you to derive the property of the
adjacency) but the L1 mesh (if used) has no business in BGP-LS unless it
forms IGP L1 adjacencies.

-- tony

On Wed, Jun 22, 2022 at 3:26 PM Ketan Talaulikar <[e-mail]>
wrote:

> 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
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>