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

[Tony Przygienda <[e-mail]>]

hey Ketan, since as you know ;-) BGP-LS is not really IGP 1:1 translation
we try to put into BGP-LS here only the stuff that is strictly needed for
topology discovery and understanding for advanced computation and nothing
else. And hence, since the 1:1 TLV correspondence is nowhere to be seen by
now if you look at ospf/isis encoding and what BGP-LS formats are today
your requirements are interesting but I'm not sure where they came from.

The flag indicates already whether something is client or reflector on an
adjacency. cluster ID is there as well to differentiate between different
clusters. L2 C/FR adjacencies will show up as well. good enough to
understand topology and compute AFAIS.  All this is achievable by putting
this element on the link TLV (the draft should explain it better, it just
grabs codepoints in node/link/prefix & e'thing else ;-). Yes, we could
annotate just the node assuming strict adherence to the IGP draft today but
putting the element on the link descriptor follows the IGP spec itself and
will allow to break the RFC if necessary later also in BGP-LS (by e.g.
allowing a node to be client of two different clusters or even a node being
reflector for 2 different clusters. Observe that this will not work in case
of auto-discoery since that's on node caps ;-) But those are sutble
discussions that need to be documented into the BGP-LS draft as procedures
once adopted. Those discussions are natural and necessary since BGP-LS is
NOT IGP  database but a distorted, simplified view for topology discovery.
Or at least that's how it's used in reality based on the shortcomings of
its design ;-)

As I explained, unless L1 adjacencies are being formed IMO they don't
belong into BGP-LS FR information, otherwise will show up in BGP-LS
naturally. Neither does IMO auto-discovery of FR.

As to mismatch of e.g. cluster ID/role. good observation but we don't send
IIHs in BGP-LS either to discover MTU mismatch so I don't see that's what
BGP-LS is here for

-- tony

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

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