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

[Ketan Talaulikar <[e-mail]>]

Hi Tony,

Please check inline below.

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

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

KT> I don't agree with the "nothing else".  At least I can't claim to have
the full knowledge of all the solutions being designed and deployed using
BGP-LS.


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

KT> Not everything from OSPF/ISIS is in BGP-LS, but whatever we've put
follows closely the semantics and encoding (with due consideration for
normalization across the IGPs). So I don't support the design of BGP-LS
encodings that are different from the underlying IGPs without strong
justification.


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

KT> So you see the scope for adding some more of the sub-TLVs from the ISIS
flood-reflection draft into this BGP-LS document? If so, great - we can
always extend on a need basis.


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

KT> The main sticking point for me here is that you have not allowed for
the BGP-LS Flood Reflection TLV to have support for sub-TLVs as is the case
with its underlying ISIS Flood Reflection TLV. It is a very minor thing
that can be easily fixed and I am unable to understand why this cannot or
should not be done. Anyway, I rest my case :-)

Thanks,
Ketan


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