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

[Ketan Talaulikar <[e-mail]>]

Hi Tony,

I may not be the best judge, for this feature, of which of the ISIS sub-TLV
need to get into BGP-LS and which do not. In my limited understanding of
the feature and its deployment, the other 3 sub-TLVs would be
equally useful to get into BGP-LS. Isn't the Flood Reflection Adjacency
Sub-TLV the one that distinguishes a "normal" ISIS adjacency from a
reflector adjacency formed over the tunnel? Isn't it useful to know what
sort of tunnel encapsulation is being signaled so a discrepancy between the
two ends can be detected?

I am copying LSR WG which probably is the better group than IDR to review
and comment on this.

In any case, I am ok to go ahead and skip the inclusion of certain ISIS
sub-TLVs in BGP-LS - they can be always added later on.

But I am not ok that while the ISIS Flood Reflection TLV has support for
sub-TLVs, its corresponding BGP-LS ISIS Flood Reflection TLV does not allow
for sub-TLVs. The encoding needs to be consistent. That is a show-stopper
in my opinion.

Thanks,
Ketan


On Wed, Jun 22, 2022 at 7:29 PM Tony Przygienda <[e-mail]> wrote:

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