[Bier] Re: Rtgdir telechat review of draft-ietf-bier-tether-05

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

Hi Adrian,

Thanks for your review and comments. I am sorry that I somehow missed it and just realized this yesterday.

I have posted the -06 revision that addresses your, Les' and Gunter's comments.

Please see zzh> below.


Juniper Business Use Only
-----Original Message-----
From: Adrian Farrel via Datatracker <[e-mail]>
Sent: Tuesday, April 16, 2024 4:28 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Rtgdir telechat review of draft-ietf-bier-tether-05

[External Email. Be cautious of content]


Reviewer: Adrian Farrel
Review result: Has Issues

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://urldefense.com/v3/__https://wiki.ietf.org/en/group/rtg/RtgDir__;!!NEt6yMaO-gk!EY10PEUx03Jnktfcm2eY6buov5l23LifKHJKfu3KhBOaSyBDAa9u2ec91v31J_rzI5aG-pNyQGaNb0I$

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-bier-tether-05
Reviewer: Adrian Farrel
Review Date: 2024-04-14
IETF LC End Date: 2024-02-29
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved before publication.

Comments:

This is a short draft that builds on existing work to offer a small optimisation in the case of a non-BIER router being the optimal branch point for a BIER tree. It uses simple mechanisms to allow a subtended router to provide the BIER forwarding plane function and so reduce the traffic on the link to the non-BIER router.

The draft is passably well written, but would benefit from some more polish. Technically there are no major issues, but some small points of clarity need to be resolved.


Side note: Daniel needs to update his information in the Datatracker. It still uses his Movaz email address!

Three points for the AD and WG chairs:

1 I note that the IPR disclosure https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3331/__;!!NEt6yMaO-gk!EY10PEUx03Jnktfcm2eY6buov5l23LifKHJKfu3KhBOaSyBDAa9u2ec91v31J_rzI5aG-pNySd_INL0$
  was disclosed against revision -00 of the individual draft
  https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-bier-tether/__;!!NEt6yMaO-gk!EY10PEUx03Jnktfcm2eY6buov5l23LifKHJKfu3KhBOaSyBDAa9u2ec91v31J_rzI5aG-pNyPALUSHs$
  It has not been disclosed against this draft and I can't find any
  discussion on the mailing list about whether the IPR still applies and
  the disclosure is assumed to be "promoted" to this draft. The last
  call IPR poll in the working group only reveals "unaware of
  undisclosed IPR on the draft." Actually I can't find the announcement
  of the original IPR disclosure on the WG list, and I see no
  mention of the IPR disclosure throughout the process: something that
  the responsible WG chair should be careful about given his shared
  affiliation with the owner of the IPR.

Zzh> We will sort this out separately.

2 I'm a bit of a fan of implementations. It might be helpful to the
  review and approval process to know whether this specification has
  been implemented, and if so, what was learnt.

Zzh> We don't have an implementation yet, partly because of the chicken-and-egg problem with BIER. The consideration now is turn this into experimental to gain experience in implementation and deployment.

3 Have the IGP extensions in this document been shown to the WG that
  owns the relevant protocols?

Zzh> Les reviewed it and brought up some good points. I have addressed those.

== Medium ==

3.2

   To make tethering work well with BGP signaling, the following can be
   done:

   *  Configure BGP sessions between X and BFR1..N and BFRx.

   *  When X re-advertises BIER prefixes to BFRx, it does not change
      BIER Nexthop [I-D.ietf-bier-idr-extensions] in the BPA.  When X
      re-advertises BIER prefixes to BFR1..N, it does change the BIER
      Nexthop to BFRx.

   *  BFRx advertises its own BIER prefix with BPA to X, and sets the
      BIER Nexthop to itself.  X then re-advertises BFRx's BIER prefix
      to BFR1..N.

I think X is not BIER capable. There seem to be two cases:
1. X is not capable of BIER forwarding actions, but is BIER-aware in the
   control plane.
2. X is not capable of BIER and not aware of BIER.

In 3.1, you effectively handle both cases together, because X does not need to be changed.

But here in 3.2 you seem to only address the first case, because X needs to support draft-ietf-bier-idr-extensions.

Perhaps some clarity on this?

Zzh> You're right. I clarified it at the end of Section 2.

== Minor ==

The Abstract is too concise even for an Abstract. It leaves the reader wondering "the handling of BIER incapable routers" by whom?

Zzh> I changed "handling" to "support". Will that help clear the wondering?

---

Introduction launches in too rapidly? Although the document is one of a set and you clearly need to understand BIER to read it, the Introduction should start off by setting the scene a bit: What is BIER?

Zzh> While I could state that "BIER is a technology that allows efficient multicast without requiring per-tree state by use of BitString ...", that still does not provide enough background for the topic in this document 😊

It should also state what this document does. That's usually the final paragraph of the introduction.

Zzh> I changed the last paragraph of Section 2. It now reads:

   This document specifies the tethering solution that addresses the
   above mentioned problems.  In the case of IGP, BFRx could advertise
   that it is X's helper and other BFRs will use BFRx (instead of X's
   children on the SPF tree) to replace X during its post-SPF processing
   as described in section 6.9 of BIER architecture specification
   [RFC8279].  X does not need to be BIER-aware at all.  In the case of
   BGP, X does need to be "slightly BIER-aware" in the control plane, as
   described in Section 4.2.

---

1.

   For BFR1 to forward BIER traffic towards BFR2...BFRn, it needs to
   tunnel individual copies through X.  This degrades to "ingress"
   replication to those BFRs.  If X's connections to BFRs are long
   distance or bandwidth limited, and n is large, it becomes very
   inefficient.

I think this is slightly wrong. The problem is the length of the connection from BFR1 to X combined with the size of n. Because, if X were BIER capable, the packets would still be sent out on all the links from X to BFR2-n.

Zzh> The text does say "long distance or bw limited, and n is large".

---

1.

   There
   could be fat and local pipes between the tethered BFRx and X, so
   ingress replication from BFRx is acceptable.

I think that "there could be fat and local pipes" is actually noting that there is a problem here depending on the size n and the volume of traffic. Rather than skip to the potential ("there could be") solution, I think you should describe the situation and call out that the links between BFRx and X must be adequate for the needs.

Zzh> I changed it to the following:

    For the ingress replication from BFRx to BFR2..n to be acceptable,
    the bandwidth between BFRx and X needs to be adequate. That should
    not be a problem with local and fat pipes between them.

---

2.

You are missing a textual description of what is contained in Figure 3.
Additionally...

OLD
  Figure 3 below is a simple case
NEW
  Figure 3 shows a simple case:
END

Zzh> Fixed.

---

2.

   This can easily be prevented if BFR1 does an SPF calculation with the
   helper BFRx as the root.  For any BFERn reached via X from BFR1, if
   BFRx's SPF path to BFERn includes BFR1 then BFR1 must not use the
   helper.  Instead, BFR1 must directly tunnel packets for BFERn to X's
   BFR (grand-)child on BFR1's SPF path to BFERn, per section 6.9 of
   [RFC8279].

This seems to say that the solution to avoid loops is to not use the tethered "helper". Which is fine except it doesn't address the problem this document is trying to solve - in this example it basically returns us to Figure 1.

Zzh> It says that we need to make sure that the helper can be used w/o causing loops. In the simplest case where a helper is a stub (Figure 1), there is no chance of looping. In other cases, a helper may be used to reach some BFRs but not for others. When it can't be used, it degrades to the original situation.
---

3.1

   At step 2, the removed node is added to an ordered list maintained
   with each child that replaces the node.  If the removed node already
   has a non-empty list maintained with itself, add the removed node to
   the tail of the list and copy the list to each child.

A bit confusing. You have:
- "added to an ordered list" which makes me wonder: added to the head,
  tail or middle?

Zzh> I clarified it is the tail.

- "If the removed node..." "...add ... to the tail of the list" which is
  good, but leaves us asking: what if not?

Zzh> Ah. That's actually covered by the first sentence itself. The text is different now after I revised the draft to address Gunter's comments.

---

3.1

   If the above procedure finishes without finding any helper, then the
   original BFR next hop via a tunnel is used to reach the BFER.

Probably add...

  The problem posited in Section 1 is not solved, but nothing is lost
  and forwarding continues as if there were no helpers available.

Zzh> Thanks. Added.

---

3.2

  BFR1..N advertises BIER prefixes

s/advertises/advertise/

zzh> Fixed.

But why does 3.1 use "MUST" where 3.2 uses a statement of fact?

Zzh> Hmm ... I have this problem of drifting away from the normative language. What if I change the "can" to "MUST" or "SHOULD" in the following?

   the following can be done in the case of BGP (no new signaling is
   needed):

---

3.2

   There are three situations regarding X's
   involvement:

But I only see two listed and the text that follows says "In either case". Is this just a typo, of is there a third case missing?

Zzh> Fixed. Only two cases.

== Nits ==

The "Requirements Language" section should move from the document header into a section (such as 1.1) in the body of the document.

Zzh> I moved it to the "Specification" section.

---

I think the title of Figure 1 should be in the singular.

Zzh> Fixed.

---

1.

   A solution to the inefficient tunneling from BFRs is to attach
   (tether) a BFRx to X as depicted in Figure 2:

Is that s/BFRs/BFR1/

Zzh> While the example talks about BFR1, inefficient tunneling could be from any of the BFR1..n - all addressed by the tethering.

---

1.

   Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will get
   BIER packets to BFRx, who will then tunnel to BFR2, ..., BFRn.

s/directly/direct/

zzh> I think "directly" is correct?

s/who/which/

zzh> Fixed.

What does "will get BIER packets to BFRx" mean? I suspect it means...
   BFR1 will tunnel packets to BFRx

Zzh> Fixed.

---

1.

   For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to

s/need/needs/

zzh> Fixed.

---

1.

   Section 6.9 of BIER architecture specification [RFC8279] describes a

s/of/of the/

zzh> Fixed.

---

2.

OLD
   While the example shows a local connection between BFRx and X, it
   does not have to be like that.
NEW
   While the example in Section 1 shows BFRx subtended to X, other
   network configurations are possible.
END

Zzh> I struggled with the word "subtended" 😊 so I changed it to "... a direction connection between BFRx and X, other network configurations are possible".



Note: In fact, in all your examples in Section 2, BFRx is connected to X

Zzh> That's because we don't give examples of indirect BFRx-X connection 😊

---

2.

   As long as packets can arrive at BFRx
   without requiring X to do BIER forwarding, it should work.

"It should work"? I think we are looking for a little more certainty!

Zzh> Changed "it works" 😊

---

2.

s/triangle, loop/triangle, a loop/

zzh> Fixed.

---

2.

   helper is not different from sending packets to a LFA backup.

s/a LFA/an LFA/

zzh> fixed.

---

3.1

   At the end, the calculating node BFR-B would use a unicast tunnel to

This sent me looking for "BFR-B" on figures, but I see you are deep in the context of RFC8279. Perhaps...


   At the end, the calculating node (called BFR-B in [RFC8279]) uses a
   unicast tunnel to

zzh> Fixed (in a different way because the text has changed a lot to put in more details).

---

3.1

   *  Order all the helper nodes of N1 based descending (priority, BIER
      prefix).

Possibly...

   *  Order all the helper nodes of N1 in descending order based on the
      numeric values of priority and BIER prefix.

Zzh> Changed.

---

3.1

s/H1 as LFA/H1 as an LFA/

zzh> Fixed.

---

3.2 etc.

While it is certainly convenient to use "BPA", I note that draft-ietf-bier-idr-extensions doesn't.

Zzh> Good point. Perhaps we should use it in the other one - it is certainly more convenient.
Zzh> Thanks a lot!
Zzh> Jeffrey