Tree Engineering for Bit Index Explicit Replication (BIER-TE)
draft-ietf-bier-te-arch-13

[S2.1, comment]

* "A packet from BFR1 to BFR3,BFR4 and from BFR4 to BFR uses (p1,p2,p3,p4,p6)"

  ->

  "A packet from BFR1 to BFR3,BFR4 and from BFR4 to BFR6 uses (p1,p2,p3,p4,p6)"

  ...I think.

[S4.2.2,4.3 comment]

* Both of these forward_routed() encap sections have no apparent mention
  of MTU considerations.  Maybe just drop a handy reference in one of these
  sections to the text in RFC 8296 section 3?

I had the same question about publication status that Robert did.  We appear to scan automatically for the status of a document in the same place, and subsequent status changes aren't as attention-getting as they should be.

** Section 2.3.  What is “ships in the nights forwarding”?  Is this intended to convey that packets are forwarded mutually exclusively either via BIER or BIER-TE?

** Section 4.4.  I appreciate that this is pseudocode so there isn’t a strict syntax to reference.  The following syntax of {VRF,}” wasn’t clear to me:

SendToL3(PacketCopy,{VRF,}l3-neighbor

PassTo(PacketCopy,{VRF,}Packet->NextProto); 

Is that a typo for “{VRF}?

** Section 5.1.5.  Per “This type of optimization BP could be used for example when all traffic is broadcast traffic … such as … situational awareness (SA)”, is SA some notification service (e.g., an emergency alert)?

** Section 7.  Per the Security Considerations of RFC8279, it says:

If the BIER encapsulation of a packet is
   modified (through error or malfeasance) in a way other than that
   specified in this document, the packet may be misdelivered.

In additional, relevant here and in RFC8279 would be that modification of the BIER encapsulation not only could lead to mis-delivery (noted in RFC8279) but also routing through an alternative path of the attackers choosing enabling additional inspection.

** Section 7.  
   ... communications
   between controllers and routers such as those to be considered for
   the BIER-TE controller/control-plane can and are much more commonly
   secured with those security properties, for example by using Secure
   SHell (SSH), [RFC4253] for NetConf ([RFC6241]), or via Transport
   Layer Security (TLS), such as [RFC8253] for PCEP, [RFC5440], or
   [RFC7589] for NetConf.

I wasn’t able to discern from the shepherd’s write-up if BIER-TE has implementations or is seeing deployment.  Especially, if this is a green field space, can a stronger statement be made about requiring or at least recommending a secure transport between the controller and routers?  The text seems to present ample enabling technologies to realize this more secure communication (i.e. “… for example by using Secure SHell (SSH), [RFC4253] for NetConf ([RFC6241]), or via Transport Layer Security (TLS), such as [RFC8253] for PCEP, [RFC5440], or   [RFC7589] for NetConf.”)

** Section 7.  

   In
   addition, the security considerations of [RFC4655] apply.

Section 10 (Security Considerations) of RFC4655 uses architectural concepts of like “inter and intra-domain networks”, “multi-domain network” and “non-local PCE”.  I wanted to clarify how to overlaying these concepts to the text in this document.  For example, 

-- is operating multiple “BIER sub-domains” correspond to a “multi-domain” network”?

-- what would a “non-local PCE” be in this BIER-TE architecture?


** Editorial

-- Section 2.1.  Figure 1. Editorial. s/local_decap/local_decap()/

-- Section 2.1.  Editorial.  s/The following picture shows/Figure 2 shows/

-- Section 2.3.  Editorial.  Typo. s/See for example See Section 5.1.3/See Section 5.1.3/

-- Section 4.3.  
   When a fixed mapping from BSL, SD, SI is used without specifically
   distinguishing BIER and BIER-TE, such as proposed for non-MPLS
   forwarding with [RFC8296] in [I-D.ietf-bier-non-mpls-bift-encoding]
   revision 04, section 5., then it is necessary to allocate disjoint
   SDs to BIER and BIER-TE BIFT so that both can be addressed by the
   BIFT-ids.  

(a) (Editorial) This sentence doesn’t parse.

(b) I would recommend against citing a specific version of an ID (Section 5 of -04)

-- Section 4.6.  The phrases “BFR MUST support to configure the BIFT …” and “Every BP in the BIFT MUST support to have zero …” do not parse.

Thanks for the efforts on this document. Due to lack of time on my side (apologies) I quickly read through the document and didn't find any transport related issue sticking out. I agree with TSVART reviewer (Thanks Tommy Pauly) that this seems useful to reduce duplicate packets to avoid unnecessary effects in the higher layers.

I have two clarification questions:

* Section 5.3.6.2: if there is 6 SIs in the example then why does the it loops through only 5 of them? see the text below -

    On all area edge BFR, bea in
   BIFT:SI=k|k=2...6 is populated with forward_routed(BFRka) and beb in
   BIFT:SI=k with forward_routed(BFRkb).

   For BIER-TE forwarding of a packet to a subset of BFERs across all
   areas, a BFIR would create at most 6 copies, with SI=1...SI=6, 

* This might be completely my misunderstanding, however, I understood that BIER-TE supports multiple domains and subdomains, where multiple domains may not be under same implementer. In that case, would their not be issues for BIER-TE controllers to show robust behavior if there is no default ECMP algorithm? Also the implementer is expected to document their ECMP of choice, I didn't understand in what format and to who the documentation applies. Also there is no discussions on what happens if there is no such documentation.

Thank you for the work put into this document. As I am back from vacations, I am afraid that I had only browsed quickly through this dense document, please accept my apologies for that. Please also note that I am not familiar with BIER.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
I find the statement "Co-existence of BIER and BIER-TE forwarding in the same domain is possible, for example by using separate BIER sub-domains (SDs)" quite an oxymoron as co-existence in a single domain requires splitting the domain into sub-domains. Suggest to rather mention sharing the BIFT-id address space among BIER and BIER-TE.
   
In the statement "BIER-TE can also be a good fit to support multicast path steering in Segment Routing (SR) networks" s/can also be a good fit/is shown to be a good fit/ ? Even if section 6 is really light on the topic.

-- Section 1 --
Please expand "BIFT" and "BFR" at first use as other BIER terms are expanded.

-- Section 2.4 --
The blanket/broad statement that "Forwarding of BIER-TE is designed to easily build/program common forwarding hardware with BIER." is it applicable to all hardware handling BIER ? Or is it vendor specific ?

-- Section 3.2.1 --
As BIER-TE is basically centralized in a control, "such YANG/Netconf/RestConf" is a little hand waving. Does the BIER WG have already started work on this control protocol ?

-- Section 4.2.3 --
What is the "entropy parameter" ? where is it defined ? (to repeat myself, I am not a BIER expert) if the entropy is part of the BIER header then strong suggestion to s/entropy parameter/value of the entropy field of the BIER header/.

-- Section 4.3 --
Do the authors have an idea on how to share the BIFT-id address space among BIER (which is decentralized AFAIK) and BIER-TE (which is centralized) without overlapping and keeping the separation during all operations (including when nodes/links appear/disappear) ?

-- Section 6 --
While discussing about SR, did the WG think about using RFC 8986 network programming to achieve the same results as BIER-TE ?

Unsure whether the note about "BIER itself" brings any value in this BIER-TE document.

Unsure what the last § has to do with segment routing.

To be honest, this section is really light and the document would gain by removing it.

== NITS ==

Please use the all uppercase "YANG" rather than "Yang" as it is an acronym.


-- Section 2.3 --
s/that is forwarding plane is a simple extension/that its forwarding plane is a simple extension/ ?

Thanks for the updates to address my Discuss and Comment points!

Just a handful of nits I spotted when reviewing the diff from -10 to -12:


Section 2.3

       2.  In BIER, the implied reference option for the core part of
           the BIER layer control plane are the BIER extensions for
           distributed routing protocols.  This includes ISIS/OSPF
           extensions for BIER, [RFC8401] and [RFC8444].

nit: s/option/options/

Section 4.1

   In BIER, each BIFT rows also requires a "Forwarding Bit Mask" (F-BM)

nit: s/rows/row/

Section 5.1.3

Many thanks for the additional discussion here; it really helps me
understand the intent!

   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.  [...]

nit: I would s/does indicate/indicates/ -- my brain is prompted to
autocomplete "does" to "does not", since the "does indicate" construction
is somewhat unusual and typically only used in situations where a
particular emphasis is desired, often in contrast to an alternate
scenario.

Section 5.1.7

   An ECMP() adjacency allows to use just one BP to deliver packets to
   one one of N adjacencies instead of one BP for each adjacency.  In

nit: s/one one/one/

Robert Spark's GenART review on Aug 8 flagged a long list of issues and
nits that I haven't seen a response to yet. Please respond to Robert.

Section 1. , paragraph 12, comment:
>    Bloom filters in general can support larger trees/topologies with
>    fewer addressing bits than explicit BitStrings, but they introduce
>    the heuristic risk of false positives and cannot clear bits in the
>    BitString during forwarding to avoid loops.  For these reasons, BIER-
>    TE uses explicit BitStrings like BIER.  The explicit BitStrings of
>    BIER-TE can also be seen as a special type of Bloom filter, and this
>    is how related work [ICC] describes it.

There is research work on Bloom filters without false positives, e.g.,
https://ieeexplore.ieee.org/document/8486415. Don't want to start a long
debate, but was just wondering if these newer approaches wouldn't be suitable?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:
   
 * Term "native"; alternatives might be "built-in", "fundamental",
   "ingrained", "intrinsic", "original".
   
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.3. , paragraph 2, nit:
-    BIER-TE is designed so that is forwarding plane is a simple extension
+    BIER-TE is designed so that its forwarding plane is a simple extension
+                                 +

Section 5.3.3. , paragraph 7, nit:
-    that is unique to the BFR in question.  For a BFIR this can be he
+    that is unique to the BFR in question.  For a BFIR this can be the
+                                                                   +

Section 2.1. , paragraph 15, nit:
> ies are called "forward_routed". Otherwise there is no difference in their p
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Otherwise".

Section 2.2. , paragraph 3, nit:
> The BIER forwarding plane, with the exception of how bits have to be cleared 
>                            ^^^^^^^^^^^^^^^^^^^^^
Consider using "except" or "except for".

Section 3.2.1.1. , paragraph 4, nit:
> ne The BIER-TE Forwarding Plane constitutes of the following components: 1. O
>                                 ^^^^^^^^^^^^^^
Did you mean "consists of"?

Section 4.1. , paragraph 5, nit:
> meter. The seed parameter allows to design hash functions that are easy to i
>                                  ^^^^^^^^^
Did you mean "designing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 4.4. , paragraph 6, nit:
> A DID NOT MIND ANOTHER EXAMPLE. Step by step example of basic BIER-TE forwar
>                                 ^^^^^^^^^^^^
Did you mean the adjective or adverb "Step-by-step" (spelled with hyphens)?

Section 4.4. , paragraph 23, nit:
> ER-TE forwarding functions can be implement via the same Forwarding Pseudocod
>                                   ^^^^^^^^^
The past participle is required after "can be".

Section 4.5. , paragraph 5, nit:
> re Non-Leaf BFER as shown on the right hand side, one traffic copy would be 
>                                  ^^^^^^^^^^
Did you mean the adjective "right-hand"?

Section 4.5. , paragraph 5, nit:
> hich makes BFER2 a non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forw
>                                   ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Likewise".

Section 4.5. , paragraph 5, nit:
> FER2. Note that the BFERs in the left hand picture are only guaranteed to be
>                                  ^^^^^^^^^
Did you mean the adjective "left-hand"?

Section 4.5. , paragraph 9, nit:
> BFER can be used to distinguish whether or not packets should reach the BFER.
>                                 ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 5.1.2. , paragraph 1, nit:
> h (ECMP) The ECMP adjacency allows to use just one BP per link bundle between
>                                    ^^^^^^
Did you mean "using"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 5.1.6. , paragraph 9, nit:
> ted() adjacencies can also allow to operate BIER-TE across intermediate hop 
>                                  ^^^^^^^^^^
Did you mean "operating"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 5.1.7. , paragraph 1, nit:
> that have arrived at BFR1 or BFR4 via a shortest path in the routing underlay
>                                       ^
Use "the" before the superlative.

Section 5.1.10. , paragraph 9, nit:
>  but instead that they will allow to express desirable path steering alternat
>                                   ^^^^^^^^^^
Did you mean "expressing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 5.2.1. , paragraph 10, nit:
> rlay applications to operate independently from the controller whenever it n
>                              ^^^^^^^^^^^^^^^^^^
The usual collocation for "independently" is "of", not "from". Did you mean
"independently of"?

Document references draft-ietf-bier-multicast-http-response-05, but -06 is the
latest available revision.

Document references draft-ietf-bier-non-mpls-bift-encoding-03, but -04 is the
latest available revision.

Document references draft-ietf-bier-te-yang-02, but -03 is the latest available
revision.

Document references draft-ietf-teas-rfc3272bis-11, but -12 is the latest
available revision.

These URLs in the document can probably be converted to HTTPS:
 * http://www.github.com/toerless/bier-te-arch

Thanks to Tommy Pauly for the TSVART review.

(2.1) s/p1...p14/p1...p15

(4.4) I had to read this section several times to understand the F-BM logic. Here are some suggestions to clarify it:

s/F-BM is handled as follows/F-BM is generated as follows: "handled" is similar "processed", which is not what I think you mean.

"All bits with an adjacency.. has only those bits set for which this BFR does not have an adjacency." This sentence was very confusing for me until I grasped that there were two different bitmaps here: the first reference to 'bits' is the BitString, the second reference is the F-BM, which has no direct relation to the BitString. More introductory text to specify the two bitmaps, and be clear about which bitmap each reference to 'bit' refers to, would be helpful.

(5.1) What does "(4.1, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8)" mean?

(5.1.3) Another situation where Leaf BFER's can't fully collapse into one codepoint is if there are two local_decap() interfaces. Or does this concept not logically exist?

Hi,

thank you for this work.

Does the text on Segment Routing equally apply to SR-MPLS and SRv6?
Wouldn't an Informative reference to 8402 be useful?

Couple nits most surely already found:
Expand BIFT and BFR on first use (introduction).
s/designed so that is/designed so that its/.

Thanks for your work on this document.

Discuss cleared based on Alvaro's clarification - I was misdirected by the boilerplate of the documents having the wrong status on both tools and datatracker, but the status is right on the RFC editor website and in the datatracker metadata.

I've moved the question regarding whether RFC 8296 should be a normative reference to a non-blocking comment.

I'm not an expert on the BIER technology, and I didn't have the time to properly read the core references before reviewing this document.  However, I didn't spot any obvious issues on the text, beyond the question on the document status.  But I also appreciated the detailed section on the operational considerations related to managing the bit position assignments, which I interpret not as a strict requirement of this specification, but likely to be very helpful to controller implementations and operators.

Regards,
Rob