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

["Gunter van de Velde (Nokia)" <[e-mail]>]

Looking into it with the tools team

From: Tony Przygienda <[e-mail]>
Sent: Monday, November 4, 2024 4:42 PM
To: Gunter van de Velde (Nokia) <[e-mail]>
Cc: [e-mail]; BIER WG <[e-mail]>
Subject: Re: [Bier] [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


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