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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Les,

I missed your email (actually, quite some list emails). Sorry for the late response.



Juniper Business Use Only
From: Les Ginsberg (ginsberg) <[e-mail]>
Sent: Friday, October 4, 2024 6:48 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Gunter van de Velde (Nokia) <[e-mail]>; [e-mail]
Cc: BIER WG <[e-mail]>
Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05

[External Email. Be cautious of content]

Jeffrey –

Top posting…

First, there are some issues with the availability of the document.

1)It isn’t visible on the BIER WG Documents page

2)Neither the HTML nor the diff URLs provided in the announcement message for V7 work:

https://datatracker.ietf.org/doc/html/draft-ietf-bier-tether-07<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bier-tether-07__;!!NEt6yMaO-gk!Bgz6ZUryYmBVd9gXcA0qjeFgmiejG8Od1HFZ202__cMjuMcWjpZn4EqcEMGRmoNOFsVOri_wxiSsJsFb$>
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bier-tether-07<https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=draft-ietf-bier-tether-07__;!!NEt6yMaO-gk!Bgz6ZUryYmBVd9gXcA0qjeFgmiejG8Od1HFZ202__cMjuMcWjpZn4EqcEMGRmoNOFsVOri_wxi6NGjx1$>

This may be because neither the HTML nor the TXT files are available from the Datatracker page.
Hopefully you or the WG chairs can straighten this out.

Zzh> This seems to be a tooling issue. I’ll try to sort it out with the IETF support team.

As far as the ECMP discussion, I think we are not understanding each other.
The changes you have made in that section don’t address my concerns.

I am asking how an operator would decide that they prefer to use a single helper vs ECMP helpers?

Don’t tell me that is based on priority – that’s a circular argument. 😊

If we use the example of OSPF Designated Router, typically the operator doesn’t care who becomes DR. And this is easy to achieve because the preference logic guarantees a single winner even if the operator uses a default priority for all routers.
Here, you require an operator to actively manage the priorities of the helpers even when ECMP is not desired.

Zzh> I think a more appropriate analogy would be unicast ECMP. Perhaps in the old days one may need to configure whether ECMP (vs. just picking one path based on some tie-breakers) would be used when it is available, but nowadays perhaps it’s default behavior to always use it .

Maybe you have a good reason for this (i.e., you think ECMP should be preferred by default) – but nothing in the draft suggests why that should (or should not) be the case.

Zzh> Indeed, I just took it for granted to use ECMP. I can add an option to use ECMP or not based on operator’s choice (but I still can’t tell an operator how he should choose).

Apologies for belaboring a small issue – just wanted to make one more attempt to at least reach a common understanding.

Zzh> I think we’re getting close – is the above option viable?
Zzh> Thanks!
Zzh> Jeffrey

Thanx.

    Les




Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Sent: Friday, October 4, 2024 2:30 PM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Gunter van de Velde (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05

Hi Les,

Please see zzh> below. I have posted the -07 revision.



Juniper Business Use Only
From: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, October 2, 2024 5:51 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Gunter van de Velde (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05

[External Email. Be cautious of content]

(BTW, is there a reason why this draft does not appear on the WG Documents page???  https://datatracker.ietf.org/wg/bier/documents/<https://urldefense.com/v3/__https:/datatracker.ietf.org/wg/bier/documents/__;!!NEt6yMaO-gk!HjREalKmNQ2Ao7PVrowxL0y2p12uHXYmTo8s9fmMp5QuqAtiqNTr6zOD-09GyEEuAmecmrp2mYQ59DDV$> )


Jeffrey –

Thanx for the response and the kind words.

One additional(not urgent) comment from me.
As regards ECMP, what I find strange is the inconsistency between the equal priority cases and the unequal priority cases.
As there is no guidance as to how the helper would choose a priority value, I am left to wonder how a node would make the choice between advertising a high priority (and thereby make it likely that ECMP would NOT be used) versus advertising some arbitrary value which might be likely to be the same on all routers.
Is there some advantage in your mind to using/not using ECMP?

Zzh> It is just like using or not using ECMP in regular routing – there are pros and cons and a router may choose to make use all the ECMP paths or just some of them.
Zzh> I noticed that I already have the following text in Section 3:

   .. To allow multiple
   helpers to help the same non-BFR, the "I am X's helper" advertisement
   carries a priority.  BFR1 will choose the helper advertising the
   highest priority among those satisfying the loop-free condition
   described above.  When there are multiple helpers advertising the
   same priority and satisfying the loop-free condition, any one or
   multiple ones could be used solely at the discretion of BFR1.

Zzh> I also updated relevant text in Section 4.1:

   If there
   are multiple helpers advertising the same highest priority, ECMP
   through some or all of those equal-priority helpers MAY be used.
   Alternatively, any one of them MAY be used.

Zzh> For the priority consideration, the red text above should provide a clue, but now I have added the following to the operational consideration section:

   In the case of using multiple helpers for one helped node, the
   helpers may be provisioned with the same or different priorities,
   depending on which one should be preferred.

Your analogy to routing isn’t fully appropriate.
IN case of routing, there is a metric value (based on some link attribute such as bandwidth) which determines the preference.
Here, there is nothing equivalent.

Zzh> To me, the priority is equivalent to the metric 😊

I’d like to see more determinism here.

Zzh> The priority is the first order, and then one can use ECMP or not – just like in the unicast routing case, the metric is the first order and then ECMP (through some or all paths) may or may not be used.

Zzh> Thanks.
Zzh> Jeffrey

   Les




Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, October 2, 2024 11:43 AM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; Gunter van de Velde (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05

Hi Les,



Juniper Business Use Only
From: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 1, 2024 12:06 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Gunter van de Velde (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05

[External Email. Be cautious of content]

Jeffrey –

Thanx for he updated version.

In regards to Section 4.1 IGP Signaling, you have addressed my comments – but I note that you say:

“When there are more than one helper nodes for a helped non-BFR node, the helper advertising a higher priority MUST be preferred. If there are multiple helpers advertising the same priority, ECMP through those equal-priority helpers MAY be used.”

In the equal priority case, ECMP is one way of handling this – but I find it logically inconsistent with how you handle the different priority case – where you require ONLY the higher priority helpers to be used.
A more consistent approach would be to use the system id/router id as a tiebreaker – where typically the higher value is preferred.

Zzh> If two have the same highest priority, either ECMP through both or pick one based on a tie-breaker or just pick a random one can all be practical approaches. The draft chooses ECMP but that does not conflict with using the highest priority one – just like in the normal routing case you always pick the best path but when you have equally best paths you can do ECMP or just pick one.
Zzh> I will add the option of using one of the helpers.

As you provide no guidance as to how the helper assigns a priority value, it seems likely that equal priority case would be the most common result – which means most of the time ECMP would be used.
Is this really what you want?

I have previously expressed concern as to whether this functionality has been implemented. That concern was also expressed by Adrian.
Is there any implementation experience?
If not, I repeat my concern – I do not understand why the document needs to go forward before implementation experience is gained.
That decision is, of course, up to the WG.

Zzh> As of now there is no implementation. I can wait since it is obviously a concern, but I am glad that we went through the process – in which I got good suggestions from experts like you.
Zzh> Thanks.
Zzh> Jeffrey

   Les



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, September 26, 2024 5:54 AM
To: Gunter van de Velde (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05

Hi Gunter,

I realized that I had not posted the revision that I shared back in May.
I also realized that I completely missed Adrian’s review.

Sorry for dropping the ball. I have posted the -06 revision that I believe addressed all the issues.

Thanks.
Jeffrey



Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang
Sent: Wednesday, May 15, 2024 10:56 PM
To: Gunter van de Velde (Nokia) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'Les Ginsberg (ginsberg)' <[e-mail]<mailto:[e-mail]>>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05

Hi Gunter,

Thanks for your thorough review and detailed report. It took me a while to catch up all the work that piled up after some business/vacation travel since IETF119 – pardon my late response.

Please see zzh> below and the attached diff/draft (not posted yet). I will reply to Les separately and copy you on some points mentioned below.

From: Gunter van de Velde (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 9, 2024 7:32 AM
To: [e-mail]<mailto:[e-mail]>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05

[External Email. Be cautious of content]

# 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"?

Zzh> Lack of existing implementations should not lead to the experimental track.

Zzh> BIER deployment has been hindered by the chicken-and-egg problem: the requirement of new or programmable ASIC (at least for important replication points) causes operators to back off their demand, which in turn throttles back vendor’s implementation pace.
Zzh> Nonetheless vendors and the BIER WG have continued their investment in this multicast technology breakthrough (which sticks to the #1 principle of Segment Routing), and its prime time is actually coming (BIER hardware and software implementations from multiple major vendors have demonstrated interoperability).
Zzh> With that, more and more BIER features including brownfield deployment features like this one, will be implemented and they will further help the deployment of BIER. I can say confidently that there will be future implementations coming.

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/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/last-call/tUy5jdA2z62BmvpP-TC-_k-rIws/__;!!NEt6yMaO-gk!BbtrDwXln23VzkcWBkS5a12kcq45c_jKug1tMCeg_PLOurdSu6ZeoxMbXKqapvG-rzShdsEHz3R9luw8rOjhZwuDrhc$>
In general there is ongoing effort to be conservative about any IGP
encoding, however especially with ISIS are TLV resources often constrained.

Zzh> I acknowledge that Les has a good point in the encoding efficiency. However, one helper helping multiple non-BFRs should not be common so the problem is not too bad. Still, I can fix that per Les’ suggestion.

Zzh> BTW, sometimes it takes formal LCs/reviews to get critical reviews like Les’ and  yours, but I am confident that the solution is sound (it follows the same TI-LFA principles).

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.

Zzh> That’s probably because there are no implementations yet.

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?

Zzh> BIER ping/traceroute will follow BIER paths – independent of unicast ping/traceroute. I did not think of discussing this, and an operator who deploys tether should not be surprised to see BIER ping/traceroute taking a different path. Traditional multicast ping/traceroute is (s,g)-based at the flow overlay and not applicable here.

Zzh> More about some other points above in the responses below.

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)

zzh> I can add that; but if there is a rogue node, it can do all kinds of damages, right? Other than preventing rogue nodes, what protection do we have?

What is the impact of technologies as LFA/BFD/ECMP impact BIER Tether topology?

Zzh> BFD/ECMP are agnostic here. BIER Tether is essentially doing TI-LFA for BIER packets as stated in the document:

   … In fact, BFR1 tunneling packets to X's
   helper is not different from sending packets to a LFA backup.


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).

Zzh> You’re right; fixed.

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.

Zzh> That’s exactly how the paragraphs are structured. The first two paragraphs point out the problem (inefficiency if BFR1 tunnels to BFR2/3/4/n directly), and the third paragraph (starting with “A solution”) describes a better solution (“tethering”).

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.

Zzh> There may be other solutions but I am not aware of one. Even if there were, they are outside the scope of this document, and I thought starting with “A solution” would be fine.

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.

Zzh> The three paragraphs after Figure 2 are there to explain why tethering is the better solution: instead of BFR1 tunneling many copies to BFR2..n, it tunnels one copy to BFX which is local to X with a fat pipe.

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?

Zzh> In the Figure 2, BFR2 is inline between BFR1 and BFER2, BFR3 is inline between BFR1 and BFER3, and so on so forth. But as the 2nd paragraph in section 1 explained, that would require BFR1 to tunnel three copies through X, which may not be good (the BFR1-X link could be limited/expensive). In this case, tethering a BFFx to X with a local fat pipe helps. You can think of BFRx being a BIER line card on X but they are actually separate nodes with separate control planes.
Zzh> It could be that router X cannot be replaced for some reasons, and the accumulative tunneled BIER traffic through the BFR1-X link is not acceptable, so tethering a small BFR to X is a good alternative here.

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.

Zzh> Done.

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.

Zzh> When the out-of-path BFRx is desired to help the BIER-incapable X, the only alternative way to get it to work is advertise BFR1-BRFx Forwarding Adjacency *for multicast purposes only*. That is explained in the following paragraph:

   For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to
   be announced in Interior Gateway Protocol (IGP) as a forwarding
   adjacency so that BFRx will appear on the Shortest Path First (SPF)
   tree.  This needs to happen in a BIER specific topology so that
   unicast traffic would not be tunneled to BFRx.  Obviously this is
   operationally cumbersome.

Zzh> The tethering solution simplifies that.

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?

Zzh> The example in Figure 1. I updated it to “The scenario in Figure 1”.
Zzh> I meant the tethering concept/mechanism/solution works. Please see if the new text is fine.

129        2.  Additional Considerations

[minor] this is odd titled section. The section title is "Additional
Considerations", but there is no section about "Considerations"?

Zzh> The previous section “considers” the simple scenario 😊 It was implicit “considerations” and this section considers more scenarios.

135           Additionally, the helper BRFx can be a transit helper, i.e., it has

[minor] s/BRFx/BFRx/

Zzh> Fixed.

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?

Zzh> I changed it to “example topology” and added a short paragraph after the figure. Please see the new text below.

   Additionally, the helper BFRx can be a transit helper, i.e., it has
   other connections (instead of being a stub helper that is only
   connected to X), as long as BFRx won't send BIER packets tunneled to
   it back towards the tunnel ingress.  Figure 3 below is an example
   topology:

                                 ------ BFR2 ------- BFER2
                                /
         BFER1 ---  BFR1 ---- X ------- BFR3 ------- BFER3
                              |
                              |
                            BFRx ------ BFR4 ------- BFER4
                                \
                                 ------ BFR5 ------- BFER5

                      Figure 3: A Safe Transit Helper

   BFR1 will tunnel one copy to BFRx, who will tunnel to BFR2/BFR3 and
   send natively to BFR4/BFR5 respectively.

Zzh> BTW, here BFRx is an inline helper of X wrt BFR4/5 but not wrt BFR2/3.
Zzh> There should be no security/operational impact.

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?

Zzh> When there are BIER incapable routers in the network and you don’t want to tunnel to their downstream BFRs directly, divergence is unavoidable.
Zzh> There is no race condition here – the BIER route calculation is an additional step after the unicast route calculation.

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

Zzh> It refers to the SPF mentioned in the short paragraph immediately preceding this sentence.

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?

Zzh> The point is that the SPF (rooted at BFRx) will avoid loops, and that is the same way how LFA avoids loops.
Zzh> I changed the last sentence slightly to be more specific.

176           … BFR1 tunneling BIER packets to X's
177           helper BFRx is like tunneling unicast packets to an LFA backup.


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

zzh> Fixed.

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.

Zzh> I now clarified it as the very beginning of the document.

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

Zzh> I mean the mechanism works for the situation where a single helper helps two different non-BFRs. I updated the text.

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.

Zzh> It’s actually not complicated – it is nothing special compared to the base case and does not need additional/special code to handle it.
Zzh> After BFR1 finishes the SPF calculation, it finds that the two children X and Y do not support BIER and they have a helper BFRxy. It first replaces X with BFRxy on the SPF tree. Then it replaces Y with BFRxy (which is already on the tree) – the replacement of Y with BFRxy is no different from replacing it with different helper.

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.

Zzh> X is the name 😊 I could change it to R1, but I don’t see a difference between X and R1, and I’d need to use BFRr1 or BFR_R1 to indicate its helper which is not as clean.

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/

Zzh> “Suppose” seems to be better? I see it is used in extensively in other documents. I can change it to “Consider”. “When” does not read well here.

[major] referencing to the comments from Les.

Zzh> I will reply separately to Les and copy you.

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.

Zzh> The BIER Helped Node sub-TLV format is identical for ISIS/OSPF/OSPFv3. In my view, it is better to just do it once instead of repeating three times.

[minor] no figure number is provided?

Zzh> Fixed.

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)?

Zzh> A routable address or router/system-id on the helped node. There are some details involving IPv4/IPv6 and ISIS system-ID. Let me check with Les (I’ll copy you).

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.

Zzh> Please see if the new text is fine.

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?

Zzh> Please see the new text.

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/

Zzh> Please see earlier response.

271        3.2.  BGP Signaling

[major] Can BGP signaling not be seen as another ecoding in addition to the IGP encodings?

Zzh> No “helped node” signaling is used. Please see updated text.

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?

Zzh> It refers to BFR1..n. I changed “advertises” to “advertise”.

[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?

Zzh> I changed them to BFR-Prefix (a term in RFC8279), and expanded the terminology section.
Zzh> Changed  “three” to “two”.

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.

Zzh> Please see the new text.

[minor] is there any impact upon how the BIER-SPF is modified using the received BGP derived BIER information.

Zzh> There is no SPF here. It’s BGP and relies on each hop to update BPA.

[major] are there no BGP code points or encodings specified?

Zzh> There is no need. I updated the procedures to make it clearer.
Zzh> Thanks!
Zzh> Jeffrey