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 <tonysi...@gmail.com> 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 <ketant.i...@gmail.com> > 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 <jh...@juniper.net> 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 <idr-boun...@ietf.org> on behalf of Susan Hares < >>> sha...@ndzh.com> >>> *Date: *Thursday, June 16, 2022 at 1:14 PM >>> *To: *Ketan Talaulikar <ketant.i...@gmail.com> >>> *Cc: *"i...@ietf.org" <i...@ietf.org> >>> *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 <ketant.i...@gmail.com> >>> *Sent:* Thursday, June 16, 2022 11:19 AM >>> *To:* Susan Hares <sha...@ndzh.com> >>> *Cc:* i...@ietf.org >>> *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 <sha...@ndzh.com> 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 >>> i...@ietf.org >>> 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 >> i...@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
