[Bier] Re: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05

[Tony Przygienda <[e-mail]>]

BTW the draft seems to have vanished in the BIER WG document tracker for some reason 

> On 9 Apr 2024, at 12:32, Gunter van de Velde (Nokia) <gunter.van_de_velde=[e-mail]> wrote:
> 
> # Gunter Van de Velde, RTG AD, comments for draft-ietf-bier-tether-05
>  
> In the absence of an earlier shepherding AD review pertaining to the
> draft-ietf-bier-tether document, please find my review comments for 
> discussion. These comments are shared prior to the document being
> considered for IESG Telechat.
>  
> In reviewing this document, I start with a broad overview of its
> current status, followed by a detailed discussion of critical technical
> points. I conclude with an analysis performed by idnits, which
> includes annotations for both [minor] and [major] comments. This
> structured approach helps to ensure that all aspects of the document
> are thoroughly examined and addressed.
>  
> Summary:
> ========
> The abstract of this document reads:
>    This document specifies optional procedures to optimize the handling
>    of Bit Index Explicit Replication (BIER) incapable routers, by
>    attaching (tethering) a BIER router to a BIER incapable router.
>  
> The document is not overly long and appears not
> overly complex. However the document reads relative light on formal 
> specification. Additional strict formal usage using BCP14 language
> to prescribing operations, the code points and the spf modification
> will provide better specification.
>  
> The shepherd writeup (4 July 2022) suggest document shepherd
> reviewed draft-ietf-bier-tether-01.
>  
> Implementations: no existing and known future Implementations.
> idnits: no substantial issues shown
>  
> Looking at the email archive, only very few discussions about this
> document happened on the list
>  
> Many thanks to Dan Romascanu (OPSDIR), Wes Hardaker (SECDIR) and Joel
> Halpern (GENART) reviews. I encourage the document authors to
> consider the feedbacks and observations provided.
>  
> Key Technical Issues:
> =====================
>  
> Due to no existing or known future implementations would
> experimental not be more appropriate IETF track then "proposed standard"?
>  
> The comments on the email list from Les about encodings has significant impact:
> https://mailarchive.ietf.org/arch/msg/last-call/tUy5jdA2z62BmvpP-TC-_k-rIws/
> In general there is ongoing effort to be conservative about any IGP
> encoding, however especially with ISIS are TLV resources often constrained.
>  
> IANA code points: why are early code points not considered? It would help to grow experience
> with the solution before requesting final code point allocations. It seems especially when
> encoding descriptions seem not fully firm at the moment.
>  
> Operational guidelines: light specification details about troubleshooting and 
> network behaviour due to diverged paths between multicast and unicast.
> For example, what is the impact on ping/traceroute and other multicast 
> operational tools, convergence impact expectations? What addresses should 
> be used as the helped address? is it possible that unicast SPF has race
> condition with the BIER topology SPF? etc. if BGP is used, any risks for the
> recursive lookups to go wrong?
>  
> Security implications: As indicated in the security directorate review
> it would help the document to add proof points why there are no
> additional security concerns compared to BIER architecture and OSPF/ISIS/BGP
> extensions for BIER signaling. (it is for example possible to insert the TLV on
> a rogue node and add all loopback addresses of the router in the area)
>  
> What is the impact of technologies as LFA/BFD/ECMP impact BIER Tether topology?
>  
> Please find in next section a set of review comments [minor] and [major]
>  
> Detailed review using the idnits rendering of the draft:
> ========================================================
>  
> 17             This document specifies optional procedures to optimize the handling
> 18             of Bit Index Explicit Replication (BIER) incapable routers, by
> 19             attaching (tethering) a BIER router to a BIER incapable router.
>  
> [major] this is incorrect. The draft specifies in addition to operational
> procedures a few IGP TLVs (code points and IGP encodings).
>  
> 76             Consider the scenario in Figure 1 where router X does not support
> 77             BIER.
>  
> [minor] It will be more clear if it is more explicit that this paragraph is
> the explanation of the observed problem space. A few paragraphs later the
> term solution is used. For readability it woul de nice to first get
> description of the problem space, followed by the naturally by the solutin discussion.
>  
> 94             A solution to the inefficient tunneling from BFRs is to attach
> 95             (tether) a BFRx to X as depicted in Figure 2:
>  
> [major] The wording "A solution" implies that there are other solutions to
> the problem possible. However, these are not discussed in the document.
> In the email archives there have been comments questioning why
> draft-ietf-bier-tether solution is better as placing for example
> a BIER router in the forwarding path close to the helped BFR?
> The 'why' is tethering better as the other solutions is unclear
> and undocumented. 
>  
> 111           For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to
> 112           be announced in Interior Gateway Protocol (IGP) as a forwarding
> 113           adjacency so that BFRx will appear on the Shortest Path First (SPF)
> 114           tree.  This needs to happen in a BIER specific topology so that
> 115           unicast traffic would not be tunneled to BFRx.  Obviously this is
> 116           operationally cumbersome.
>  
> [minor] an alternative is to place the BFRx into the IGP forwarding path?
> Is the multicast traffoc expected of lesser valume as the unicast traffic?
> Maybe the unicast traffic volume can be neglected compared to the multicast traffic?
>  
> 118           Section 6.9 of BIER architecture specification [RFC8279] describes a
> 119           method that tunnels BIER packets through incapable routers without
> 120           the need to announce tunnels.  However that does not work here,
> 121           because BFRx will not appear on the SPF tree of BFR1.
>  
> [minor] style rewrite: 
> "Section 6.9 of the BIER architecture specification [RFC8279] delineates a
> methodology for tunneling BIER packets through incapable routers without
> the need to explicitely announce tunnels. Nonetheless, this method is
> inapplicable in the current context, as BFRx is not a node in the SPF
> tree rooted at BFR1.
>  
> 123           There is a simple solution to the problem though.  BFRx could
> 124           advertise that it is X's helper and other BFRs will use BFRx (instead
> 125           of X's children on the SPF tree) to replace X during its post-SPF
> 126           processing as described in section 6.9 of BIER architecture
> 127           specification [RFC8279].
>  
> [major] simple is subjective language. The need for code points,
> IGP signalling, usage of multicast only router (=unicast stealth router)
> and topological BIFT abstraction is not that simple. This section is an
> opportunity to present and defend that the tether solution is the most
> optimal solution for the presented use-case.
>  
> 131           While the example shows a local connection between BFRx and X, it
> 132           does not have to be like that.  As long as packets can arrive at BFRx
> 133           without requiring X to do BIER forwarding, it should work.
>  
> [minor] what example is being referenced. From a style perspective it
> is unclear what 'should work' means in a proposed standard document.
> Maybe more formal writing is appropriate? Does "should work" mean it behaves
> as architected or does not behave as architected. What are the conditions
> it would not work as intended?
>  
> 129        2.  Additional Considerations
>  
> [minor] this is odd titled section. The section title is "Additional
> Considerations", but there is no section about "Considerations"?
>  
> 135           Additionally, the helper BRFx can be a transit helper, i.e., it has
>  
> [minor] s/BRFx/BFRx/
>  
> 137           connected to X), as long as BFRx won't send BIER packets tunneled to
> 138           it back towards the tunnel ingress.  Figure 3 below is a simple case:
>  
> [minor] a use-case or a network topology? a little more context helps
> readability on how expected multicast flows wil be steered through
> the topology. How would this impact security and operational implications?
>  
> 151           In the example of Figure 4, there is a connection between BFR1 and
> 152           BFRx.  If the link metrics are all 1 on the three sides of
> 153           BFR1-X-BFRx triangle, loop won't happen but if the BFRx-X metric is 3
> 154           while other two sides of the triangle has metric 1 then BFRx will
> 155           send BIER packets tunneled to it from BFR1 back to BFR1, causing a
> 156           loop.
>  
> [major] This description truely provides an indication that when tether is
> used, that there is divergence between unicast and multicast topologies. How would
> LFA and other fast convergence race conditions impact during instabity?
>  
> 174           Notice that this SPF calculation on BFR1 with BFRx as the root is not
>  
> [minor] unsure what "this spf" referes towards. more formal language will
> help to understand the example better 
>  
> 174           Notice that this SPF calculation on BFR1 with BFRx as the root is not
> 175           different from the SPF done for a neighbor as part of Loop-Free
> 176           Alternate (LFA) calculation.  In fact, BFR1 tunneling packets to X's
> 177           helper is not different from sending packets to a LFA backup.
>  
> [minor] What is the point that is being proved with the comparison to LFA style SPF calculation?
>  
> 179           Also notice that, instead of a dedicated helper BFRx, any one or
> 180           multiple ones of BFR2..N can also be the helper (as long as the
>  
> [minor] upper or lower case n vs N? seems that there is disreptency between
> diagram and text
>  
> 185           highest priority among those satisfying the loop-free condition
> 186           described above.  When there are multiple helpers advertising the
> 187           same priority and satisfying the loop-free condition, any one or
> 188           multiple ones could be used solely at the discretion of BFR1.
>  
> [major] The node BFR1 silently implies that it is the upstream node of the BIER uncapable router (the helped node).
> This is nowhere defined or specified.
>  
> 192           The situation in Figure 5 where a helper BFRxy helps two different
> 193           non-BFRs X and Y also works.  It's just a special situation of a
> 194           transit helper.
>  
> [minor] what does "also works" exactly mean? formal description of the outcome will helps
>  
> 192           The situation in Figure 5 where a helper BFRxy helps two different
> 193           non-BFRs X and Y also works.  It's just a special situation of a
> 194           transit helper.
>  
> [minor] THis is becoming very complex and no longer simple. What are the operational
> implications and how to troubleshoot this now that unicast and multicast
> topology are looking vastly different.
>  
> 214           The procedures in this document apply when a BFRx is tethered to a
> 215           BIER incapable router X as X's helper for BIER forwarding.
>  
> [minor] It would help to formally give the BIER incapable router a name to refer to from documentation perspective.
>  
> 219           Suppose that the BIER domain uses BIER signaling extensions to ISIS
> 220           [RFC8401] or OSPF [RFC8444].  The helper node (BFRx) MUST advertise
> 221           one or more BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in
> 222           the case of ISIS or BIER Helped Node sub-TLVs in the BIER sub-TLV in
> 223           the case of OSPF, one for each helped node:
>  
> [minor] s/suppose/when/
>  
> [major] referencing to the comments from Les.
> In addition, having explicit sections for ISIS and OSPF and OSPFv3 will be beter to formalize and document the code-points and associated TLV descriptions.
>  
> [minor] no figure number is provided?
>  
> 225                0                   1                   2                   3
> 226                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 227               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 228               |    Type       |   Length      |    Priority   |   Reserved    |
> 229               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 230               |              Address of the Helped Node                       |
> 231               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  
> [major] WHat is this address of the helped node? is that a interface address? is
> that a loopback? is it a router id? does it have to be a stable address? does
> the address have to exists on the router? must the address be UP and ENABLED
> and PINGABLE on the router? What if multiple helped node addresses are added all over the network (for an attach for example)?
>  
> 243           At step 2, the removed node is added to an ordered list maintained
> 244           with each child that replaces the node.  If the removed node already
> 245           has a non-empty list maintained with itself, add the removed node to
> 246           the tail of the list and copy the list to each child.
>  
> [major] The text at section 6.9 is written formally. if the intent is to
> change the step 2 with alternate logic prescribing when and how to insert the BIER helper
> node. Most correct would be to rewrite using formal BCP14 language the complete 'step 2'
> for the tether use case.
>  
>     (RFC8279 section6.9)
>    2.  If one of the child nodes does not support BIER, BFR-B removes
>        that node from the tree.  The child nodes of the node that has
>        just been removed are then re-parented on the tree, so that BFR-B
>        now becomes their parent.
>  
> 268           If the above procedure finishes without finding any helper, then the
> 269           original BFR next hop via a tunnel is used to reach the BFER.
>  
> [minor] Is this statement also not part of the process that tether modifies the BIER-SPF?
>  
> 273           Suppose that the BIER domain uses BGP signaling
> 274           [I-D.ietf-bier-idr-extensions] instead of IGP.  BFR1..N advertises
>  
> [minor] s/suppose/when/
>  
> 271        3.2.  BGP Signaling
>  
> [major] Can BGP signaling not be seen as another ecoding in addition to the IGP encodings?
>  
> 273           Suppose that the BIER domain uses BGP signaling
> 274           [I-D.ietf-bier-idr-extensions] instead of IGP.  BFR1..N advertises
> 275           BIER prefixes that are reachable through them, with BIER Path
> 276           Attributes (BPA) attached.  There are three situations regarding X's
> 277           involvement:
>  
> [minor] what does "them" reference? 
> [minor] not sure what the BIER prefix is. Is that a special NLRI used for signalling BIER BitString?
> [minor] three situations are mentioned, but only 2 follow?
>  
> 286           To make tethering work well with BGP signalling, the following can be
> 287           done:
>  
> [major] what does "work well" mean? please explain using BCP14 langue how the technology and encodings will work.
> [minor] is there any impact upon how the BIER-SPF is modified using the received BGP derived BIER information.
> [major] are there no BGP code points or encodings specified?
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> _______________________________________________
> BIER mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/bier