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

[Robert Raszuk <[e-mail]>]

Hello,

I have a question ... likely to the WG chairs.

Why
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-flood-reflection-07
does not have a YANG section ? Is there a separate document for it just
like we see a separate document for BGP-LS encoding ?

Isn't the YANG section a requirement for all protocol extension
documents before they are sent for publications these days ?

The reason I am asking this is in fact in light of the other discussions we
have on IDR list where at least one mode of link state state advertisement
can be done using YANG encoding. Is YANG section optional in LSR WG
documents which define new protocol extensions and new functionality ? If
an implementation uses YANG to push LSDB how the new TLVs defined in the
draft are going to be shared across ?

Many thx,
Robert


On Wed, Jun 29, 2022 at 10:56 PM Susan Hares <[e-mail]> wrote:

> Greetings:
>
>
>
> I want to thank all the people who contributed to this WG adoption call.
>
>
>
> There are four points I pull from the adoption call:
>
>
>
> 1. IDR participants desire to discuss other potential ways to pass data
> currently past in IDR
>
>
>
> I will start a thread noted as “BGP-LS” alternative.   This thread has 2
> subjects:
>
> 1) clear problem statements on BGP-LS
>
> 2) Discussion of alternatives (e.g. Droid (draft-li-lsr-droid-00.txt)
>
>
>
> If there is enough on list discussion, IDR may hold an interim on the
> topic.
>
>
>
> 2.  Operators wish to deploy this draft
>
>
>
> I have confirmation on requests for deploying this draft.
>
> Like some other BGP features, it may not be widely deployed.
>
>
>
> 3. The WG wishes to add these features to this experimental draft.
>
>
>
> draft-ietf-idr-bgp-ls-isis-flood-reflection-00.txt
>
>
>
> Based on the call, this draft should include the changes promised on the
> call.
>
> The authors should resubmit the draft with this name.
>
>
>
> 4. The IDR + LSR chairs should review the agreements relating to
>
> BGP-LS TLVs at IETF-114 in their WG.
>
>
>
> The IDR chairs will request a time at IDR + LSR for this topic.
>
> Let  me know if a short video be better than slides.
>
> If so, we’ll post the video on YouTube before IETF and
>
> Take questions at LSR or IDR.
>
>
>
> Cheers, Sue Hares
>
>
>
> *From:* Lsr <[e-mail]> *On Behalf Of * Susan Hares
> *Sent:* Friday, June 24, 2022 9:29 AM
> *To:* Tony Przygienda <[e-mail]>; Ketan Talaulikar <
> [e-mail]>
> *Cc:* Jordan Head <[e-mail]>; [e-mail]; lsr <[e-mail]>
> *Subject:* Re: [Lsr] [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
> call (6/6 to 6/20)
>
>
>
>
>
> 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 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
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>