Re: [Bier] Benjamin Kaduk's Discuss on draft-ietf-bier-te-arch-10: (with DISCUSS and COMMENT)

[Toerless Eckert <[e-mail]>]

Thanks, Ben

-12 should resolve your DISCUSS and all nits/comments. Detailed replies below inline.

Full diff from -11 to -12:

http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-11.txt&url2=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-12.txt

Diff with just the deltas from replies to your discuss/comments
and followup comments from Carsten Borman.

http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-11.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/8ed27af30d4da5883aeab7d63a2c427fa2922b1a/draft-ietf-bier-te-arch.txt

Thanks again for all the detailled review.

Cheers
    Toerless

On Fri, Dec 24, 2021 at 03:08:59PM -0800, Benjamin Kaduk wrote:
[...]
> The comments help a great deal, though I'm still not convinced it's quite right.
> The clearing of Packet->BitString in the second line seems okay now, but in
> the first line we are supposed to be grabbing the set of bits that were set
> in the packet and represent adjacencies relevant for this router.  I think
> that should be:
> 
>     AdjacentBits = Packet->BitString & AdjacentBits[SI];
> 
> (with no "~") so that we loop over the intended bits later on.
> 
> I'd also suggest using a different name than "AdjacentBits" for this local
> variable.  What the behavior is when a local variable has the same name as
> an array variable is unlikely to be an intuitive part of pseudocode, and
> using a different name provides a clear separation.

Yes, sincere apologies for not catching this in -11. 
I think what happened was that in 2018 i wrote this code for -01,
and i simply put the "~" into the wrong one of the two code lines, being
confused. And for -11 i didn't even check that line above concentrating
on the other line that you called out. Maximum confusion around one
character *sigh*. Thanks a lot for being persistent.

Code is now:

  // Determine adjacent bits in the Packets BitString
  PktAdjacentBits = Packet->BitString & AdjacentBits[SI];

  // Clear adjacent bits in Packet header to avoid loops
  Packet->BitString &= ~AdjacentBits[SI];

  // Loop over PktAdjacentBits to create packet copies 
  for (Index = GetFirstBitPosition(PktAdjacentBits); Index ;

> (I also note that Carsten had some more comments on the pseudocode, which
> seem worth thinking about; the criteria I used in my original review
> wouldn't have made such items Discuss-worthy, so from my perspective they
> are non-blocking comments.)

Ack. I made some smaller fixes on behalf of Carstens feedback and those
are included in the diff for your review.

[...]

> > not forward_connected(), so it could only impact a packet that
> > was encapsulated for forward_routed by some other BFR with destination
> > being BFER2, and this packet passes unexpectedly via BFR1. But it doesn't
> > matter which routers/BFR it passes through, the BIER header will not
> > be examined there, its just unicast routed.
> > 
> > > Even worse, if DNC is not set, it seems that the copy that
> > > leaves BFR1 and makes its way to BFR2 will have the bit cleared that's
> > > used to indicate "leaf BFER".  So, either I'm confused about how this
> > > works (something that's quite plausible!), or there's some other
> > > undocumented constraints here either on the topology or the use of DNC.
> > 
> > The BitString is intended to express a delivery tree. Only nodes that
> > will always be leaves in any tree (because of their location in the topolocy)
> > will have a share Leaf BFR bit set. The fact that they clear this
> > bit when they process the packet does thereofre not hurt further
> > BIER forwarding of the packet, because by being leaf there is the implication
> > that no BitString will be built in which they need to forward a receive
> > BIER-TE pto a further BFR.
> > 
> > > Reading forward to the summary in §5.1.10, perhaps my assumption about
> > > indicating "send along this adjacency" was incorrect.  Still, I
> > > shouldn't need to read the later section in order to understand the
> > > earlier one, so adding a few more words here may be in order.
> > 
> > I wouldn't know what to write to clear up this confusion.
> > If i managed correctly guess what you where confused about,
> > maybe you want to suggest text ?
> 
> I am still a little uncertain whether I understand correctly, though less
> so than when I wrote the original comment.
> 
> When you say that "nodes ... will have a share Leaf BFR bit set", is this
> referring to when "the BIER-TE Controller then pushes the
> BitPositions/adjacenties to the BIFT of the BFRs" (to quote §3.2.1.1),
> which would (roughly?) correspond to having a bit set in the local BIFT for
> a given adjacency?

I think so.

> Assuming that it is, then when I transition to the context of how a packet
> where that bit is set gets propagated, that seems to imply that the "share
> Leaf BFR bit" is not relevant to the processing that BFR1 does in my
> original example.  Going all the way back to my phrasing with a split into
> "send along this adjacency" and "local_decap when it gets here", that was
> intended to refer to BFR1 performing the "send along this adjacency"
> function, and in light of the subsequent discussion I no longer think that
> the single shared bit would perform that function.
> 
> I think the source of my confusion is the sentence "All leaf-BFERs in a
> BIER-TE domain can share a single bit position", in that I can read that
> sentence as saying either/both of "single bit position for 'send this
> packet out the interface that exits the BIER-TE domain'" and "single bit
> position for 'a packet should get sent to this BFER'".  It sounds like only
> the former is the intent, so maybe adding a few words to this sentence
> would help, e.g., "All leaf-BFERs in a BIER-TE domain can share a single
> bit position to indicate that a packet should be processed and sent onwards
> out of the BIER-TE domain".

I am still trying to write myself up to the terse but still easily understandable
language of other rfcs, but i continue to fail i guess. Maybe/hopefully, the
issues i am describing actually are so complex that the text is not too verbose.

I did replace the two paragraphs starting with the sentence you did not like
as follows. This got a bit longer because i had to refine several things,
starting with the fact that one can obviously not share a single bit position
across all BFER in a BIER-TE domain, but only across all leaf-BFER that
can be addressed via a single BitString (a BIER-TE domain using RFC8296
encapsulation will have multiple BitStrings differentiated by SD, SI, BSL
or BIFT-id, so each of those BIFT would just require one leaf-BFER bit positions.
And then the text about not being able to combine this shared bit position with
LAN/Hub&Spoke optimizations also needed to be refined. So three paragraphs now.

<t>In most situations, leaf-BFER that are to be addressed via the same BitString can share a single bit position for their local_decap() adjacency in that BitString and therefore save bit positions. On a non-leaf BFER, a received BIER-TE packet may only need to transit the BFER or it may need to also be decapsulated. Whether or not to decapsulate the packet therefore needs to be indicated by a unique bit position populated only on the BIFT of this BFER with a local_decap() adjacency. On a leaf-BFER, packets never need to pass through; any packet received is therefore usually intended to be decapsulated. This can be expressed by a single, shared bit position that is populated with a local_decap() adjacency on all leaf-BFER addressed by the BitString.</t>

<t>The possible exception from this leaf-BFER bit position optimization can be cases where the bit position on the prior BIER-TE BFR (which created the packet copy for the leaf-BFER in question) is populated with multiple adjacencies as an optimization, such as in <xref target="LAN"/> or <xref target="hubnspoke"/>. With either of these two optimizations, the sender of the packet could only control explicitly whether or not the packet was to be decapsulated on the leaf-BFER in question, if the leaf-BFER has a unique bit position for its local_decap() adjacency.</t>

<t>However, if the bit position is shared across leaf-BFER, and packets are therefore decapsulated potentially unnecessarily, this may still be appropriate if the decapsulated payload of the BIER-TE packet does indicate whether or not the packet needs to be further processed/received. This is typically true for example if the payload is IP multicast because IP multicast on a BFER would know the membership state of the IP multicast paylod and be able to discard it if the packet was delivered unnecessarily by the BIER-TE layer. If the payload has no such membership indication, and the BFIR wants to have explicit control about which BFER are to receive and decapsulate a packet, then these two optimizations can not be used together with shared bit positions optimization for leaf-BFER.</t>

> > In BIER-TE we do not necessarily have a single BP designated
> > to a BFER, so the controller has various options of how he
> > assigns unambiguous bift-ids to BFER, and this text explains
> > one option that would make it closests to (non-te) BIER.
> 
> I think the "equally be determined" was what tripped me up, as it implies
> that there is some other (unstated) primary way to determine the BFR-id,
> which is equivalent to this procedure.  Maybe "equally" is not quite the
> right word, or we should say "can be determined using the same procedure as
> in [(non-TE)] BIER"?

Ack. changed.

> > | BIER-TE controllers SHOULD use security equal to or better than these mechanisms.
> > 
> > I am only using SHOULD because i dont see a risk of getting less security
> > in any "IT" network (service provider, enterprise, data-center), TLS is
> > the obviouos choice, and if somebody uses something different from the above
> > list like SSH, then the deployment has some more fundamental ops challenges.
> > 
> > But with MUST, we might create an inappropriate burden for "OT" networks
> > (inside trains, planes, automobiles, to repeat my prior example). 
> > In many cases you might have physically removed "provisioning ports".
> > 
> > Think of hidden i2c ports on devices through which you configure the
> > device, then you remove and never touch again. Aka: physical security.
> >  Is that equal or better than TLS ? 
> 
> It might depend on what attacker capabilities are in the threat model you
> care about.  If you only care about some attacker far away on the internet
> ... probably.

I guess i should have added "blow a fuse" that also does not allow you to
locally re-configure the device once its validated to be configured correcty
for production (One Time Programmable).

> Which is to say, I will not argue about the SHOULD, here.

Thanks. My primary concern is that its difficult to compare security levels
of end-to-end with infrastructure. E.g.: obviously, i'd be happy to
sell cert based security like in ANIMA into OT environments to protect
the infrastructure component and hence the system, e.g.: you can reprogram
with credentials (maybe still only locally) and you can reset devices,
but loose credentials etc. pp. 

> And all the other stuff (above and below) seems okay; no further comments.
> Thanks again for the updates and explanations,

Thanks a lot!

Toerless

> Ben
> 
> > > Section 11.2
> > > 
> > > If "it is expected that the reader be familiar with" RFC 8296, it should
> > > probably be classified as normative.
> > 
> > Done.
> > 
> > > NITS
> > > 
> > > By no means an exhaustive collection, but hopefully they will help.
> > > 
> > > Section 2.2
> > > 
> > >    may be called an "overlay" BIER-TE topology.  A BIER-TE topology will
> > >    both "forward_connected" and "forward_routed" adjacencies may be
> > >    called a "hybrid" BIER-TE topology.
> > > 
> > > s/will/with/
> > 
> > Ack.
> > 
> > > Section 2.3
> > > 
> > >                                                                 In BIER-
> > >            TE, bits in the BitString of a BIER packet header indicate an
> > >            adjacency in the BIER-TE topology, and only the BFRs that are
> > >            upstream of this adjacency have this bit populated with the
> > >            adjacency in their BIFT.
> > > 
> > > I think that s/are upstream/are the upstream endpoint/ would greatly aid
> > > readability.
> > 
> > Ack.
> > 
> > > 
> > >        2.  In BIER, the implied reference option for the core part of
> > >            the BIER layer control plane is the BIER extension to
> > >            distributed routing protocol, such as standardized in ISIS/
> > >            OSPF extensions for BIER, [RFC8401] and [RFC8444].  [...]
> > > 
> > > There seems to be some singular/plural mismatch(es) going on here.
> > > Maybe "are the BIER extensions to distributed routing protocols, such as
> > > those standardized in"?
> > 
> > yes.
> > 
> > >    3.  The following element/functions described in the BIER
> > >        architecture are not required by the BIER-TE architecture:
> > > 
> > > Probably best to use "elements/functions" to match plurality.
> > 
> > ack.
> > 
> > >        1.  BIRTs on BFR for BIER-TE are not required when using a BIER-
> > > 
> > > I think "BFRs" plural.  (Probably the plural is best for the next few
> > > instances of "BFR" (not "BFR-id") in this section, but I will not try to
> > > note them all explicitly.)
> > 
> > ack
> > 
> > > Section 3.2
> > > 
> > > I think s/BFIR/BFIRs/ in all cases in this section (excluding
> > > subsections) other than item 2.3, and possibly 2.1 if the intent is "for
> > > each multicast overlay flow".
> > 
> > sounds right.
> > > 
> > >        3.  Install state on the BFIR to imposition the desired BIER
> > >            packet header(s) for packets of the overlay flow.
> > > 
> > > s/imposition/impose/
> > 
> > ack.
> > 
> > > Section 3.2.1
> > 
> > >    o  Data-models and protocols to communicate between controller and
> > >       BFR in step 1, such YANG/Netconf/RestConf.
> > > 
> > > probably s/BFR/BFRs/ and s/such/such as/.
> > 
> > ack.
> > 
> > > Section 3.2.1.1
> > > 
> > >    When the topology is determined, the BIER-TE Controller then pushes
> > >    the BitPositions/adjacencies to the BIFT of the BFRs, populating only
> > >    those SI:BitPositions to the BIFT of each BFR to which that BFR
> > >    should be able to send packets to - adjacencies connecting to this
> > >    BFR.
> > > 
> > > This sentence should probably be rewritten and split up; it may have
> > > multiple valid parse trees but regardless is pretty hard to parse.
> > > Having separate terms for "the BFR receiving BIFT updates" and "the BFR
> > > to which a given bit says to send a packet" would help a lot.
> > 
> > Yeah, weird complex. simplified now:
> > 
> > <t>When the BIER-TE topology is determined, the BIER-TE Controller then pushes
> > the BitPositions/adjacencies to the BIFT of the BFRs. On each BFR only those SI:BitPositions
> > are populated that are adjacencies to other BFRs in the BIER-TE topology.</t>
> > 
> > > Section 3.2.1.2
> > > 
> > >    encoded as the same BitString.  In BIER-TE, the BitString used to
> > >    reach the same set of BFER in the same sub-domain can be different
> > >    for different overlay flows because the BitString encodes the paths
> > >    towards the BFER, so the BitStrings from different BFIR to the same
> > >    set of BFER will often be different, and the BitString from the same
> > >    BFIR to the same set of BFER can different for different overlay
> > >    flows for policy reasons such as shortest path trees, Steiner trees
> > >    (minimum cost trees), diverse path trees for redundancy and so on.
> > > 
> > > I suggest breaking the sentence before "and the BitString from the same
> > > BFIR".
> > 
> > ack
> > > 
> > > Also, s/can different/can be different/
> > 
> > ack
> > > 
> > >    See also [I-D.ietf-bier-multicast-http-response] for a solution
> > >    describing this interaction.
> > > 
> > > I'm not sure that "solution" is the best word here ("solution to which
> > > problem?").
> > 
> > See also <xref target="I-D.ietf-bier-multicast-http-response"/> for an application  
> > leveraging BIER-TE engineered trees.
> > 
> > > Section 3.2.1.4
> > > 
> > >    When link or nodes fail or recover in the topology, BIER-TE could
> > >    quickly respond with out-of-scope FRR procedures such as
> > >    [I-D.eckert-bier-te-frr].  [...]
> > > 
> > > Is the intent to say "could quickly respond with FRR procedures [...]
> > > the details of which are out of scope for this document"?
> > 
> > ack.
> > 
> > > Section 3.3
> > > 
> > >    1.  On BFIR imposition of BIER header for packets from overlay flows.
> > > 
> > > comma after BFIR
> > 
> > ack
> > > 
> > >    3.  On BFER removal of BIER header and dispatching of the payload
> > > 
> > > comma after BFER
> > 
> > ack
> > > 
> > > Section 3.5
> > > 
> > >    available at each BFR and for each BP when it is providing congestion
> > >    loss free services such as Rate Controlled Service Disciplines
> > > 
> > > hyphenate "congestion-loss-free"
> > 
> > ack
> > > 
> > >    control protocol such as Netconf or any other protocol commonly used
> > >    by a PCE to understand the resources of the network it operates on.
> > > 
> > > I think s/PCE/Controller/ since this is the only instance of "PCE"
> > > that's not part of "PCEP", in this document.
> > 
> > Ack.
> > 
> > >    the BIER-TE defined steering of packets.  This includes allocation of
> > >    buffers to guarantee the worst case requirements of admitted RCSD
> > >    traffic and potential policing and/or rate-shaping mechanisms,
> > > 
> > > I'm not sure, but possibly s/potential/potentially/
> > 
> > yes.
> > 
> > > Section 4.2.1
> > > 
> > >    for copies of the packet made towards other adjacencies.  This can be
> > >    used for example in ring topologies as explained below.
> > > 
> > > "Below" could become a reference to §5.1.6 as was done in §4.1.
> > 
> > ack.
> > 
> > > Section 4.2.3
> > > 
> > >    packet is copied onto such an ECMP adjacency, an implementation
> > >    specific so-called hash function will select one out of the lists
> > >    adjacencies to which the packet is forwarded.  This ECMP hash
> > > 
> > > s/lists/list's/
> > 
> > ack
> > 
> > > Section 4.2.4
> > > 
> > >    packets.  Local_decap() adjacencies require the BFER to support
> > >    routing or switching for NextProto to determine how to further
> > >    process the packet.
> > > 
> > > I'm not finding a protocol element to map to "NextProto" in this
> > > context, so maybe writing out in long form something like "the next
> > > protocol layer" would be preferred.
> > 
> > Resolved by introducing term in prior sentence:
> > 
> > A "local_decap" adjacency passes a copy of the payload of
> > the BIER-TE packet to the protocol ("NextProto") within the BFR (IPv4/IPv6, Ethernet,...) responsible for
> > that payload
> > 
> > NextProto is also used in the Pseudocode.
> > 
> > > Section 4.3
> > > 
> > >    With MPLS, it is also possible to reuse the same SD space for both
> > >    BIER-TE and BIER, so that the same SD has both a BIER BIFT and
> > >    according range of BIFT-ids and a disjoint BIER-TE BIFT and non-
> > >    overlapping range of BIFT-ids.
> > > 
> > > I think s/according/corresponding/
> > 
> > ack.
> > 
> > >    "forward_routed" requires an encapsulation permitting to unicast
> > >    BIER-TE packets to a specific interface address on a target BFR.
> > > 
> > > "encapsulation that permits directing unicast BIER-TE packets"
> > 
> > ack.
> > 
> > > Section 4.4
> > > 
> > >       void ForwardBitMaskPacket_withTE (Packet)
> > >       {
> > >           SI=GetPacketSI(Packet);
> > >           Offset=SI*BitStringLength;
> > >           for (Index = GetFirstbit position(Packet->BitString); Index ;
> > >                Index = GetNextbit position(Packet->BitString, Index)) {
> > >               F-BM = BIFT[Index+Offset]->F-BM;
> > >               if (!F-BM) continue;                            [3]
> > >               BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
> > >               PacketCopy = Copy(Packet);
> > >               PacketCopy->BitString &= F-BM;                  [2]
> > >               PacketSend(PacketCopy, BFR-NBR);
> > >               // The following must not be done for BIER-TE:
> > >               // Packet->BitString &= ~F-BM;                  [1]
> > >           }
> > >       }
> > > 
> > > GetFirstBitPosition and GetNextBitPosition are the spellings used in the
> > > RFC 8279 pseudocode; I don't see reason to diverge from them.  (The same
> > > comment applies to the pseudocode in Figure 6 as well.)
> > 
> > Indeed. strange. fixed.
> > 
> > >    To solve both [1] and [2] for BIER, the F-BM of each bit needs to
> > >    have all bits set that this BFR wants to route across BFR-NBR. [2]
> > > 
> > > Expanded out, "the F-BM of each bit needs to have" doesn't seem to make
> > > much sense; would s/bit/bit index/ make more sense?
> > 
> > Yes.
> > 
> > >       *  The packets BitString is masked with those AdjacentBits before
> > >          the loop to avoid doing this repeatedly for every PacketCopy.
> > > 
> > > s/packets/packet's/
> > 
> > ack
> > 
> > >                     case forward_routed({VRF},neighbor):
> > >                         SendToL3(PacketCopy,{VRF,}l3-neighbor);
> > > 
> > > Should the first line use "l3-neighbor" as well as the second one?
> > 
> > yes.
> > 
> > > Section 4.5
> > > 
> > >    BFR3 sees a BitString of p5,p7,p8,p10,p11,p12.  For those BPs, it has
> > >    only adjacencies for p7,p8.  It creates a copy of the packet to BFER1
> > >    (due to p7) and one to BFR4 (due to p8).  It clears p7, p8 before
> > >    sending.
> > > 
> > > I think "clears both p7 and p8 in both copies before sending" is more
> > > clear.
> > 
> > ack.
> > 
> > > Section 4.6
> > > 
> > >    clear DNC flag, forward_routed() and local_decap.  As explained in
> > >    Section 4.4, these REQUIRED BIER-TE forwarding functions can be
> > >    implement via the same Forwarding Pseudocode as BIER forwarding
> > > 
> > > s/implement/implemented/
> > > 
> > > Section 5.1.4
> > > 
> > >    opposite LANs.  Adjacencies of such BFRs into their LAN still need a
> > >    separate bit position.
> > > 
> > > Is this something like "such multi-homed BFRs"?
> > 
> > That is name calling, and i usually hear the term only in
> > conjunction with hosts, not routers, so i think it would not be helpfull.
> > 
> > > Section 5.1.9
> > > 
> > >                           Figure 17: Reuse of BP
> > > 
> > >    Reuse may also save BPs in larger topologies.  Consider the topology
> > >    shown in Figure 20.  A BFIR/sender (e.g.: video headend) is attached
> > > 
> > > I suspect that s/20/17/ is intended.
> > 
> > Yes.
> > 
> > > Section 5.1.10
> > > 
> > >    o  BP can generally be reused across nodes that do not need to be
> > >       consecutive in paths, but depending on scenario, this may limit
> > > 
> > > "consecutive in paths" might imply "directly one after the other" to
> > > some readers.  Perhaps "where it can be guaranteed that no path will
> > > ever need to traverse more than one node of the set"?
> > 
> > Right. thanks.
> > 
> > > Section 5.3.3
> > > 
> > >    BIER-TE forwarding does not use the BFR-id, not does it require for
> > > 
> > > s/not does/nor does/
> > 
> > fixed.
> > 
> > > Section 5.3.6.2
> > > 
> > >    In addition, we use 4 bits in each SI: bia, bib, bea, beb: bit
> > >    ingress a, bit ingress b, bit egress a, bit egress b.  These bits
> > > 
> > > It's probably worth spending a few more words to connect these "a" and
> > > "b" back to the 6 different BFR1a/BFR1b through BFR6a/BFR6b of Figure
> > > 20.  (Figure 20, which appears in §5.3.6.1, is not mentioned at all from
> > > this section at present.)
> > 
> > Added reference to picture, highlighted how abbreviations are derived:
> > 
> >     In addition, we use 4 bits in each SI: bia, bib, bea, beb: (b)it (i)ngress (a),
> >     (b)it (i)ngress (b), (b)it (e)gress (a), (b)it (e)gress (b).
> > > 
> > >    legs: 1) BFIR to ingress are edge and 2) core to egress area edge.
> > > 
> > > s/are edge/area edge/
> > 
> > Ack.
> > 
> > > Section 6
> > > 
> > >    hop to each destination Node-SID.  What BIER does not allow is to
> > >    indicate intermediate hops, or terms of SR the ability to indicate a
> > > 
> > > s/terms of SR/in terms of SR/
> > 
> > ack
> > 
> > > Section 7
> > > 
> > >    In BIER, the standardized methods for the routing underlays as well
> > >    as to distribute BFR-ids and BFR-prefixes are IGPs such as specified
> > >    in [RFC8401] for IS-IS and in [RFC8444] for OSPF.  Attacking the
> > > 
> > > I can't make a parse tree for this sentence.  I think it's just trying
> > > to say that RFCs 8401 and 8444 specify how to distribute BFR-ids and
> > > BFR-prefixes over the respective IGP, and the respective IGP inherently
> > > distributes information needed for routing underlays, but I could be
> > > wrong.
> > 
> > 
> > <t>In BIER, the standardized methods for the routing underlays are IGPs with extensions to distribute BFR-ids and BFR-prefixes.  <xref target="RFC8401"/> specifies the extensions for IS-IS and <xref target="RFC8444"/> specifies the extensions for OSPF.
> > > 
> > >    against the results of the routing protocol, enabling DoS attacks
> > >    against paths or addressing (BFR-id, BFR-prefixes) used by BIER.
> > > 
> > > I think s/addressing/the addressing/
> > 
> > ack.
> > > 
> > >    adjacencies, then this is still an attack vector as in BIER, but only
> > >    for BIER-TE forward_routed() adjacencies, and no other adjacencies.
> > > 
> > > s/and no/and not/
> > 
> > ack
> > 
> > >    the BIER-TE controller/control-plane can and are much more commonly
> > > 
> > > s/can/can be/
> > 
> > ack
> > > 
> > >    forwarding rules are defined to be as strict in clearing bits as they
> > >    are.  The clearing of all bits with an adjacency on a BFR prohibits
> > > 
> > > I think just "defined to be as strict in clearing bits as possible" --
> > > "defined to be as <anything> as they are" is basically a tautology.
> > 
> > true. fixed.
> > 
> > >    that a looping packet creates additional packet amplification through
> > >    the misconfigured loop on the packets second or further times around
> > > 
> > > s/packets/packet's/
> > 
> > fixed.
> > > 
> > >    Deployments especially where BIER-TE would likely be beneficial may
> > >    include operational models where actual configuration changes from
> > > 
> > > This "especially" seems out of place (I think the sentence would work if
> > > it's just dropped, though maybe moving it is preferred).
> > 
> > hmm.. dropped it.
> > > 
> > >    the controller are only required during non-productive phases of the
> > > 
> > > Maybe s/productive/production/?
> > 
> > yes.
> > > 
> > >    networks life-cycle, such as in embedded networks or in manufacturing
> > > 
> > > s/networks/network's/ (just the first one)
> > 
> > ack
> > 
> > >    reverting the network/installation into non-productive state.  Such
> > > 
> > > ("production" again)
> > > 
> > > 
> > 
> > -- 
> > ---
> > [e-mail]