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

[Susan Hares <[e-mail]>]

Tony P, Ketan and IDR WG:

Thank you for input on this draft.
I am closing the WG adoption call for this draft.
The IDR Chairs will discuss the results of this consensus call, and
Announce the results by July 8th.

Cheers,

Sue Hares

From: Tony Przygienda <[e-mail]>
Sent: Wednesday, June 22, 2022 12:11 PM
To: Ketan Talaulikar <[e-mail]>
Cc: Jordan Head <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]; lsr <[e-mail]>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

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 co
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzE5MTIyOGZiY2Q2NTAwZTIwYjkzYjRmMGQxMzM5Y2ExLzE2NTU5MTQyODguNzQ=#key=487ff255afe0901b5c88f247a79a612d>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 16, 2022 at 1:14 PM
To: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Thursday, June 16, 2022 11:19 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[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://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj1FPgzAUhf_KID5a2lJAmC97cBKXTeY0xvlCCm2BbcDWlsFm_O9SY-LjPV_Ol3u-7E4e7OnELrU-qimE48m44I3iTt7W8Exgmv4xRjXVkuZ7Lp2Ka-G0soCszSGTVGhQcspAxSTIiiM4KFCpSgEhx_69ZT3PdXBZ0QQUeytG68eBLvDntT5vj-8k9R76zbl7oWQRxsqv_dVu_jr0F9CnO7CMt5s4Ww4sfVpVnfg46WWCVJ90p21C3qIb-3Zi782AhuvxH4z8MIiwC1VJJVezhl3L3yF4DN1QZDkLfIS4i7KIZJ5ADBMS5RRDHPh-hD03DJ07z1i5seq2uSgzdlbUtDoYlWHMsP_k-wdyEWkB.MEYCIQDjY9WwgFHh5dWa2WUm9tVOqm6YCPki-694fz22Fg9fWAIhAKHChWA3KpRx_PIg1hwxrVlPAtfnxtcxGEYfuAWijw_O>

  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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJxFj11PgzAARf_KID4KbfkS5ssenMSFuTkT43xpylpYNwpIC90w_nepMfHx3pucnPtl911lz2f2UalWzgGYImUFqyVzD40Agw8w_tu01i5nqnCbrgSC8EqQGlRcKl4XDeC0w_jesp6XKrquycYpz1YKt48XskIfoxj27ZuPgwe9G_oX4q_iVIYiXJ-Wrxd9dTQ-OVm636V5dqH4ac374v1TZRso9UYOjejH9sa-ndlno1ozNRkgGMZRgjwgj6RjclHT8firjKbSi4v8QKMQQubBPPHzoIAU-X5yIAigKAwTFHhx7N4FhsoMVTX1VZp7i9J8MyizUbP9N98_jyhibg.MEQCIFO-ANzQLpLj9i4INIwioWVKxRIo0c0WwXEmnEBd3JalAiBLKzHCSLA2PuG39EkOQXFAISkKW4sfuQg-uSUhDI5hyw>


Juniper Business Use Only
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxFjk0OgyAUhK9iWDc8QLHgyquggJIqGKAxbdO717fqdn6-mQ955o0MDVlrPcoAcJ4nDa56mvICuwnbbiJsodQQfYJgM7k15IGN6OqV4UyqXnMBZTXZlTHa90rntAO_RKH8NNteMuYEm3Q7dZ5Z3rZ6Nhx4L6XmnVCK3jukOqTWFF8FD4wLriMKPYveX_n-ABaTOFY.MEUCIE1IGAGzFnwrp7pxEJioyzGO2Y5OlPd_nElKecNITOg3AiEA8s32M7Y4B9rqylokFQ9qqH_XOf6SHBlrvtjkhsM0Fwc>