[Bier] Roman Danyliw's No Objection on draft-ietf-bier-te-arch-10: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-bier-te-arch-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** 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.