[Bier] AD Review of draft-ietf-bier-te-arch-10

[Alvaro Retana <[e-mail]>]

Hi!

This is a quick review of -10.  Most of the comments are minor or nits.

Thanks!

Alvaro.



[Line numbers from idnits for -10.]

...
135	1.  Overview

137	   BIER-TE is based on architecture, terminology and packet formats with
138	   BIER as described in [RFC8279] and [RFC8296].  This document
139	   describes BIER-TE in the expectation that the reader is familiar with
140	   these two documents.

[minor] s/based on architecture, terminology and packet formats with
BIER as described/based on the BIER architecture, terminology and
packet formats with as described


...
180	   o  Section 5 describes operational considerations for the BIER-TE
181	      controller, foremost how the BIER-TE controller can optimize the
182	      use of BP by using specific type of BIER-TE adjacencies for
183	      different type of topological situations, but also how to assign
184	      bits to avoid loops and duplicates (which in BIER-TE does not come
185	      for free), and finally how SI, sub-domains and BFR-ids can be
186	      managed by a BIER-TE controller, examples and summary.

[nit] s/by using specific type of BIER-TE adjacencies for different
type of topological situations/by using specific BIER-TE adjacencies
in different topological situations


188	   o  Section 6 concludes the technology specific sections of document
189	      by further relating BIER-TE to Segment Routing (SR).

[nit] s/of document/of the document


...
335	2.2.  BIER-TE Topology and adjacencies
...
342	   The BIER-TE Topology consists of the BIFTs of all the BFR and can
343	   also be expressed as a directed graph where the edges are the
344	   adjacencies between the BFR labelled with the BP used for the
345	   adjacency.  Adjacencies are naturally unidirectional.  BP can be
346	   reused across multiple adjacencies as long as this does not lead to
347	   undesired duplicates or loops as explained further down in the text.

[nit] s/between the BFR/between the BFRs


...
357	2.3.  Relationship to BIER

359	   BIER-TE is designed so that is forwarding plane is a simple extension
360	   to the BIER forwarding plane, hence allowing for it to be added to
361	   BIER deployments where it can be beneficial.

[nit] s/is forwarding/its forwarding


...
370	       1.  The fundamental purpose of per-packet signaled packet
371	           replication and delivery via a BitString.

[nit] s/per-packet signaled packet replication/per-packet signaled replication


...
376	       3.  The supportable encapsulations, [RFC8296] or other (future)
377	           encapsulations.

[nit] s/supportable encapsulations, [RFC8296]/supported encapsulations [RFC8296]


...
412	       1.  BIRTs on BFR for BIER-TE are not required when using a BIER-
413	           TE controller because the controller can directly populate
414	           the BIFTs.  In BIER, BIRTs are populated by the distributed
415	           routing protocol support for BIER, allowing BFR to populate
416	           their BIFTs locally from their BIRTs.  Other BIER-TE control
417	           plane or management plane options may introduce requirements
418	           for BIRTs for BIER-TE BFR.

[minor] Expand first occurrence of BIRT.


420	       2.  The BIER-TE layer forwarding plane does not require BFR to
421	           have a unique BP and therefore also no unique BFR-id.  See
422	           for example See Section 5.1.3.

[nit] s/require BFR/require a BFR


...
436	       1.  The BIER/BIER-TE packet header needs to allow addressing both
437	           BIER and BIER-TE BIFT.  Depending on the encapsulation
438	           option, the same SD may or may not be reusable across BIER
439	           and BIER-TE.  See Section 4.3.  In either case, a packet is
440	           always only forwarded end-to-end via BIER or via BIER-TE
441	           (ships in the nights forwarding).

[nit] s/both BIER and BIER-TE BIFT/both the BIER and BIER-TE BIFTs


443	       2.  BIER-TE deployments will have to assign BFR-ids to BFR and
444	           insert them into the BFR-id field of BIER packet headers as
445	           BIER does, whenever the deployment uses (unchanged)
446	           components developed for BIER that use BFR-id, such as
447	           multicast flow overlays or BIER layer control plane elements.
448	           See also Section 5.3.3.

[nit] s/to BFR/to BFRs


450	2.4.  Accelerated/Hardware forwarding comparison

452	   Forwarding of BIER-TE is designed to easily build/program common
453	   forwarding hardware with BIER.  The pseudocode in Section 4.4 shows
454	   how existing BIER/BIFT forwarding can be modified to support the
455	   REQUIRED BIER-TE forwarding functionality, by using BIER BIFT's
456	   "Forwarding Bit Mask" (F-BM): Only the clearing of bits to avoid
457	   duplicate packets to a BFR neighbor is skipped in BIER-TE forwarding
458	   because it is not necessary and could not be done when using BIER
459	   F-BM.

[major] s/REQUIRED BIER-TE forwarding/required BIER-TE forwarding
In context, there is no normative action, just a statement of fact.
Nonetheless, a reference to §4.6 would be nice.


...
501	3.2.  The BIER-TE Control Plane
...
509	   For BIER-TE, the control plane includes at minimum the following
510	   functionality.

[minor] It would be useful to point at the sections where each piece
of functionality is described -- even if it is at just a high-level of
granularity.


...
545	3.2.1.  The BIER-TE Controller

547	   Notwithstanding other options, this architecture describes the BIER
548	   control plane as shown in Figure 3 to consists of:

[nit] s/to consists/to consist


550	   o  A single centralized BIER-TE controller.

[minor] Perhaps remove "single centralized" which gives the impression
of single-point-of-failure/attack point -- where we all know that in
general the controller may not be a single box, etc..


552	   o  Data-models and protocols to communicate between controller and
553	      BFR in step 1, such YANG/Netconf/RestConf.

[?] Step 1?  I think that you're referring to the list in the previous
section -- please indicate there that they represent "steps".  On
second thought, it looks like only a couple of places refer back to
the list as steps; maybe find an alternate way to refer to them.

[minor] Only in "step 1"?  There is some programmability-related work
to be done in step 2.


555	   o  Protocols to communicate between controller and BFIR in step 2,
556	      such as BIER-TE extensions for [RFC5440].

[minor] Same question...only step 2?   It's not clear to me why (it
any extensions are TBD) a PCE can't be used for step 1, and viceversa.


...
567	3.2.1.1.  BIER-TE Topology discovery and creation

569	   Step 1.1 includes network topology discovery and BIER-TE topology
570	   creation.  The latter describes the process by which a Controller
571	   determines which routers are to be configured as BFR and the
572	   adjacencies between them.

[nit] s/as BFR/as BFRs


...
583	   Dynamic creation of the BIER-TE topology can be as easy as mapping
584	   the network topology 1:1 to the BIER-TE topology by assigning a BP
585	   for every network subnet adjacency.  In larger networks, it likely
586	   involves more complex policy and optimization decisions including how
587	   to minimize the number of BP required and how to assign BP across
588	   different BitStrings to minimize the number of duplicate packets
589	   across links when delivering an overlay flow to BFER using different
590	   SIs/BitStrings.  These topics are discussed in Section 5.

[nit] s/number of BP/number of BPs


[nit] s/assign BP/assign BPs


...
598	   Communications between the BIER-TE Controller and BFRs (beside
599	   topology discovery) is ideally via standardized protocols and data-
600	   models such as Netconf/RestConf/Yang/PCEP.  Vendor-specific CLI on
601	   the BFRs is also an option (as in many other SDN solutions lacking
602	   definition of standardized data model).

[nit] s/standardized data model/standardized data models


604	3.2.1.2.  Engineered Trees via BitStrings

606	   In BIER, the same set of BFER in a single sub-domain is always
607	   encoded as the same BitString.  In BIER-TE, the BitString used to
608	   reach the same set of BFER in the same sub-domain can be different
609	   for different overlay flows because the BitString encodes the paths
610	   towards the BFER, so the BitStrings from different BFIR to the same
611	   set of BFER will often be different, and the BitString from the same
612	   BFIR to the same set of BFER can different for different overlay
613	   flows for policy reasons such as shortest path trees, Steiner trees
614	   (minimum cost trees), diverse path trees for redundancy and so on.

[nit] s/can different/can be different


...
640	3.3.  The BIER-TE Forwarding Plane

642	   The BIER-TE Forwarding Plane constitutes of the following components:

[nit] s/constitutes of/is constituted by


644	   1.  On BFIR imposition of BIER header for packets from overlay flows.
645	       This is driven by a combination of state established by the BIER-
646	       TE control plane and/or the multicast flow overlay as explained
647	       in Section 3.1.

[nit] s/On BFIR/On a BFIR,


[nit] s/of BIER header/of the BIER header


649	   2.  On BFR (including BFIR and BFER), forwarding/replication of BIER
650	       packets according to their BitString as explained below and
651	       optionally Entropy.  Processing of other BIER header fields such
652	       as DSCP is outside the scope of this document.

[nit] s/On BFR/On a BFR


[minor] "as explained below"   A specific reference would be nice.


[major] "Processing of other BIER header fields such as DSCP is
outside the scope of this document."   Better wording might be that it
is unchanged.  Is that the intent?


654	   3.  On BFER removal of BIER header and dispatching of the payload
655	       according to state created by the BIER-TE control plane and/or
656	       overlay layer.

[nit] s/On BFER/On a BFER,


...
746	4.1.  The Bit Index Forwarding Table (BIFT)
...
756	   In [RFC8279], Figure 2, indices into the BIFT are both SI:BitString
757	   and BFR-id, where BitString is indicating a BP: BFR-id = SI * 2^BSL +
758	   BP.  As shown in Figure 4, in BIER-TE, only SI:BP are used as indices
759	   into a BIFT because they identify adjacencies and not BFR.

[minor] I think that the formula makes things sound more complicated.

Suggestion>
   Figure 2 of [rfc8279] uses both SI:BitString and BFR-id as indices into
   the BIFT.  As shown in Figure 4 (below), in BIER-TE only SI:BP are used
   as indices into a BIFT because they identify adjacencies and not BFR.


...
835	4.2.3.  ECMP
...
840	   A BIER-TE "Equal Cost Multipath" (ECMP) adjacency has a list of two
841	   or more non-ECMP adjacencies and a seed parameter.  When a BIER-TE
842	   packet is copied onto such an ECMP adjacency, an implementation
843	   specific so-called hash function will select one out of the lists
844	   adjacencies to which the packet is forwarded.  This ECMP hash
845	   function MUST select the same adjacency from that list for all
846	   packets with the same entropy parameter.  The seed parameter allows
847	   to design hash functions that are easy to implement at high speed
848	   without running into polarization issues across multiple consecutive
849	   ECMP hops.  See Section 5.1.7 for more explanations.

[minor] s/non-ECMP/ECMP


...
861	4.3.  Encapsulation / Co-existence with BIER
...
881	   With MPLS, it is also possible to reuse the same SD space for both
882	   BIER-TE and BIER, so that the same SD has both a BIER BIFT and
883	   according range of BIFT-ids and a disjoint BIER-TE BIFT and non-
884	   overlapping range of BIFT-ids.

[minor] s/and according range of BIFT-ids/with a corresponding range
of BIFT-ids,


[nit] s/and non-overlapping/and a non-overlapping


886	   When a fixed mapping from BSL, SD, SI is used without specifically
887	   distinguishing BIER and BIER-TE, such as proposed for non-MPLS
888	   forwarding with [RFC8296] in [I-D.ietf-bier-non-mpls-bift-encoding]
889	   revision 04, section 5., then it is necessary to allocate disjoint
890	   SDs to BIER and BIER-TE BIFT so that both can be addressed by the
891	   BIFT-ids.  The encoding proposed in section 6. of the same document
892	   does not statically encode BSL or SD into the BIFT-id, but allows for
893	   a mapping, and hence could provide for the same freedom as when MPLS
894	   is being used (same or different SD for BIER/BIER-TE).

[nit] s/5.,/5,


[nit] s/BIER and BIER-TE BIFT/BIER and BIER-TE BIFTs


...
908	4.4.  BIER-TE Forwarding Pseudocode
...
914	      void ForwardBitMaskPacket_withTE (Packet)
915	      {
916	          SI=GetPacketSI(Packet);
917	          Offset=SI*BitStringLength;
918	          for (Index = GetFirstbit position(Packet->BitString); Index ;
919	               Index = GetNextbit position(Packet->BitString, Index)) {
920	              F-BM = BIFT[Index+Offset]->F-BM;
921	              if (!F-BM) continue;                            [3]
922	              BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
923	              PacketCopy = Copy(Packet);
924	              PacketCopy->BitString &= F-BM;                  [2]
925	              PacketSend(PacketCopy, BFR-NBR);
926	              // The following must not be done for BIER-TE:
927	              // Packet->BitString &= ~F-BM;                  [1]
928	          }
929	      }

[nit] s/GetFirstbit position/GetFirstbitPosition


[nit] s/GetNextbit position/GetNextbitPosition


...
974	   This Forwarding Pseudocode can support the REQUIRED BIER-TE
975	   forwarding functions (see Section 4.6), forward_connected,
976	   forward_routed() and local decap, but not the RECOMMENDED functions
977	   DNC flag and multiple adjacencies per bit nor the OPTIONAL function,
978	   ECMP adjacencies.  The DNC flag cannot be supported when using only
979	   [1] to mask bits.

[major] s/REQUIRED...RECOMMENDED...OPTIONAL/required...recommended...optional
This text is not normative, just a description.


...
1144	4.6.  BFR Requirements for BIER-TE forwarding

1146	   BFR MUST support to configure the BIFT of sub-domains so that they
1147	   use BIER-TE forwarding rules instead of BIER forwarding rules.  Every
1148	   BP in the BIFT MUST support to have zero or one adjacency.
1149	   Forwarding MUST support the adjacency types forward_connected() with
1150	   clear DNC flag, forward_routed() and local_decap.  As explained in
1151	   Section 4.4, these REQUIRED BIER-TE forwarding functions can be
1152	   implement via the same Forwarding Pseudocode as BIER forwarding
1153	   except for one modification (skipping one masking with F-BM).

[minor] s/support to configure/support configuring


[nit] s/clear DNC flag/a clear DNC flag


[major] s/REQUIRED/required
Not a normative statement.


...
1159	   BIER-TE forwarding SHOULD support more than one adjacency on a bit.
1160	   This allows to save bits in hub&spoke scenarios (see Section 5.1.5).

[nit] s/hub&spoke/hub and spoke


1162	   BIER-TE forwarding MAY support ECMP adjacencies to save bits in ECMP
1163	   scenarios, see Section 5.1.7 for an example.  This is a MAY
1164	   requirement, because the deployment importance of ECMP adjacencies
1165	   for BIER-TE is unclear as one can also leverage ECMP of the routing
1166	   underlay via forwarded_routed adjacencies and/or might prefer to have
1167	   more explicit control of the path chosen via explicit BP/adjacencies
1168	   for each ECMP path alternative.

[major] s/a MAY requirement/an optional requirement


[minor] s/the deployment importance of ECMP adjacencies for BIER-TE is
unclear as/for ECMP deployments using BIER-TE


...
1183	5.1.1.  P2P Links

1185	   On a P2P link that connects two BFR, the same bit position can be
1186	   used on both BFR for the adjacency to the neighboring BFR.  A P2P
1187	   link requires therefore only one bit position.

[nit] s/two BFR/two BFRs


[nit] s/both BFR/both BFRs


...
1194	5.1.3.  Leaf BFERs
...
1209	   A leaf BFERs is one where incoming BIER-TE packets never need to be
1210	   forwarded to another BFR but are only sent to the BFER to exit the
1211	   BIER-TE domain.  For example, in networks where Provider Edge (PE)
1212	   router are spokes connected to Provider (P) routers, those PEs are
1213	   Leaf BFERs unless there is a U-turn between two PEs.

[nit] s/A leaf BFERs/A leaf BFER


...
1492	5.1.9.  Reuse of bit positions (without DNC)
...
1544	                          Figure 17: Reuse of BP

1546	   Reuse may also save BPs in larger topologies.  Consider the topology
1547	   shown in Figure 20.  A BFIR/sender (e.g.: video headend) is attached
1548	   to area 1, and area 2...6 contain receivers/BFER.  Assume each area
1549	   had a distribution ring, each with two BPs to indicate the direction
1550	   (as explained before).  These two BPs could be reused across the 5
1551	   areas.  Packets would be replicated through other BPs for the Core to
1552	   the desired subset of areas, and once a packet copy reaches the ring
1553	   of the area, the two ring BPs come into play.  This reuse is a case
1554	   of (B), but it limits the topology choices: Packets can only flow
1555	   around the same direction in the rings of all areas.  This may or may
1556	   not be acceptable based on the desired path steering options: If
1557	   resilient transmission is the path engineering goal, then it is
1558	   likely a good optimization, if the bandwidth of each ring was to be
1559	   optimized separately, it would not be a good limitation.

[minor] s/Figure 20/Figure 17


1561	5.1.10.  Summary of BP optimizations
...
1603	   Note that the described list of optimizations is not exhaustive.
1604	   Especially when the set of required path steering choices is limited
1605	   and the set of possible subsets of BFERs that should be able to
1606	   receive traffic is limited, further optimizations of BP are possible.
1607	   The hub & spoke optimization is a simple example of such traffic
1608	   pattern dependent optimizations.

[nit] s/hub & spoke/hub and spoke


...
1757	5.3.3.  Assigning BFR-id with BIER-TE

1759	   BIER-TE forwarding does not use the BFR-id, not does it require for
1760	   the BFR-id field of the BIER header to be set to a particular value.
1761	   However, other parts of a BIER-TE deployment may need a BFR-id,
1762	   specifically overlay signaling, and in that case BFR need to also
1763	   have BFR-ids for BIER-TE SDs.

[nit] s/BFR need/BFRs need


1765	   For example, for BIER overlay signaling, BFIR need to have a BFR-id,
1766	   because this BFIR BFR-id is carried in the BFR-id field of the BIER
1767	   header to indicate to the overlay signaling on the receiving BFER
1768	   which BFIR originated the packet.

[nit] s/BFIR need/BFIRs need


...
1781	   As explained in Section 5.1.3, leaf BFERs do not need such a unique
1782	   local_decap() adjacency, likewise, BFIR who are not also BFER may not
1783	   have a unique local_decap() adjacency either.  For all those BFIR and
1784	   (leaf) BFER, the controller needs to determine unique BFR-ids that do
1785	   not collide with the BFR-ids derived from the non-leaf BFER
1786	   local_decap() BPs.

[nit] s/BFIR who are not also BFER/BFIRs that are not also BFERs


[nit] s/BFIR and (leaf) BFER/BFIRs and (leaf) BFERs


1788	   While this document defines no requirements how to allocate such BFR-
1789	   id, a simple option is to derive it from the (SI,BP) of an adjacency
1790	   that is unique to the BFR in question.  For a BFIR this can be he
1791	   first adjacency only populated on this BFIR, for a leaf-BFER, this
1792	   could be the first BP with an adjacency towards that BFER.

[nit] s/requirements how/requirements on how


[nit] s/can be he/can be the


1794	5.3.4.  Mapping from BFR to BitStrings with BIER-TE

1796	   In BIER, applications of the flow overlay on a BFIR can calculate the
1797	   (SI,BP) of a BFER from the BFR-id of the BFER and can therefore
1798	   easily determine the BitStrings for a BIER packet to a set of BFER
1799	   with known BFR-ids.

[nit] s/set of BFER/set of BFERs


...
1817	   If "independent branches" are used, the BIER-TE Controller can signal
1818	   to the BFIR flow overlay for every BFER an SI:BitString that
1819	   represents the branch to that BFER.  The flow overlay on the BIFR can
1820	   then independently of the controller calculate the SI:BitString for
1821	   all desired BFER by OR'ing their BitStrings.  This allows for flow
1822	   overlay applications to operate independently from the controller
1823	   whenever it needs to determine which subset of BFERs need to receive
1824	   a particular packet.


[nit] s/all desired BFER/all desired BFERs


...
1838	   Communications between BFIR flow overlay and BIER-TE controller
1839	   requires some way to identify BFER.  If BFR-ids are used in the
1840	   deployment, as outlined in Section 5.3.3, then those are the natural
1841	   BFR identifier.  If BFR-ids are not used, then any other unique
1842	   identifier, such as the BFR-prefix of the BFR as of [RFC8279] could
1843	   be used.

[nit] s/BIER-TE controller/the BIER-TE controller


[nit] s/identify BFER/identify the BFER


[minor] s/BFR-prefix of the BFR as of [RFC8279]/BFR-prefix of the BFR [RFC8279]


...
2031	7.  Security Considerations
...
2046	   The reference model for the BIER-TE layer control plane is a BIER-TE
2047	   controller.  When such a controller is used, impairment of individual
2048	   BFR in a domain causes no impairment of the BIER-TE control plane on
2049	   other BFR.  If a routing protocol is used to support forward_routed()
2050	   adjacencies, then this is still an attack vector as in BIER, but only
2051	   for BIER-TE forward_routed() adjacencies, and no other adjacencies.

[nit] s/of individual/of an individual


[nit] s/other BFR/other BFRs

[EoR -10]