[Bier] Comments on draft-ietf-bier-te-arch-03

[Dirk Trossen <[e-mail]>]

All,

As volunteered during the recent Montreal WG meeting, I've reviewed the BIER-TE draft with the following comments with the notation "pXpYlZ" to be read as "page X paragraph Y line Z" (not counting section headings as a paragraph) for easier reference in the nitpick comments below (i.e., for small corrections):

  1.  Overall, the draft is very comprehensive in description and well structured as well as detailed in the various aspects of its descriptions. Generally, I am very supportive to seeing this draft progress and I'm very curious on seeing/hearing/reading about realizations.
  2.  Content comments:
     *   The draft well motivates the use of BPs indicating forwarding adjacencies rather than BFERs for the purpose of traffic engineering with comparisons to the BIER model of forwarding in the various parts of the draft. As a possible 'external' reference, it might be useful to refer to work on path-based forwarding in SDN environments that is based on the same motivation and has similarities at the solution detail level (albeit simpler in many ways since not connected to BIER). The introduction could possibly have such link to "M. J. Reed, M. Al-Naday, N. Thomos, D. Trossen, G. Petropoulos, S. Spirou, Stateless multicast switching in software defined networks, ICC 2016, Kuala Lumpur, Maylaysia, 2016"
     *   In Section 2, there is a reference to four 'layers' but I personally find the notion of a 'BIER-TE Controller Host' as a separate layer confusing, firstly starting with the mapping of a single 'host' entity to a 'layer' but also since even the text itself outlines the 'BIER-TE Controller Host' and its connections to the BF(I/E)Rs as the 'control plane' of BIER-TE. So I wonder if 'BIER-TE control plane' would be a more adequate name?
     *   Section 2.2.3 talks about per-multicast flow and its state in the BFIR. It might be worthwhile to link this sub-section to the 'HTTP multicast overlay' draft (https://tools.ietf.org/html/draft-ietf-bier-multicast-http-response-01) where said state would be maintained in the SH. Main point here is that multicast state, in my view, can (and maybe should?) be maintained by the multicast flow overlay.
     *   In Section 2.3, i.e., p11p2s6, the sentence talks about "the BFR resets all BitPositions in the BitString of the packet to which it can create a copy". From my understanding, the BitPositions to all forwarding adjacencies to which a copy is created are reset, while I would think that the sentence above might be understood as simply resetting all BitPositions if a copy is being created. So maybe changing this into "the BFR resets all those BitPositions in the BitString of the packet of all those forwarding adjacencies to which it can create a copy" would avoid such confusion.
     *   In Section 3.4, Figure 5 shows a BIER-TE Forwarding Example. While this makes sense to me, given the flow of the document, it nevertheless duplicates similar figures in Section 1, specifically Figure 1 and 2. Either we leave this and simply have those two places of explanation, following the flow of description, or possibly simply refer in Section 3.4 back to Figures 1 and 2 in Section 1 in order to streamline the draft.
     *   In Section 7.2, i.e., p29p4l2, there is a statement on bit efficiency ("...easily be as low as 20% or as high as 80%"). I would really like to see a reference to evidence to this since I'm very interested in the numbers but it's always good to link them to something, particularly when being so specific.
     *   Section 8 compares SR and BIER-TE, which I like seeing in the draft. I would argue that the possibility for creating opportunistic multicast relations (through a simple binary OR of unicast relations) is a significant advantage over SR. Here, a possible link to the 'HTTP multicast overlay' draft (see link above) might be useful, which makes use of this capability.
  3.  Nitpicks:
     *   P4p1l1: "adjacencies" change to "adjacencies"
     *   P5p1l2: "6 BFR..." to "6 BFRs..." (with my working assumptions that an acronym is singular)
     *   P5p1l2: "All BFR..." change to "All BFRs..."
     *   P6p1l4: "...BFR1 to to send..." change to "...BFR1 to send..."
     *   P6p3l3: "...in the prior casse." change to "...in the prior case."
     *   P7p3l1: "...consists of the BIFT of all the the" change to "...consists of the BIFT of all the"
     *   P9p3l1: "During 'bring-up..." change to "During set-up..." or "During initial configuration..."
     *   P13p2l4: "The can be used" change to "They can be used"
     *   P13p6l1: "...to the BIER BIFT and are are" change to "...to the BIER BIFT and are"
     *   P17p2l6: "This Basic BIER-TE requirements make..." change to "These basic BIER-TE requirements make..."
     *   P21p1l3: "example is not mean as a likely setup" change to "example is not meant as a likely setup"
     *   P29p1l1: "which lead to" change to "which leads to"
     *   P30p6l1: "For non-leaf BFER, ..." change to "For a non-leaf BFER, ..."
     *   P30p7l1: "As explained earlier in the document, leaf BFER do..." change to "As explained earlier in the document, leaf BFERs do..."

I hope this is useful.

Best,

Dirk