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

[Toerless Eckert <[e-mail]>]

Thanks, Roman

Detailed replies for your comments below inline.
It should resolve all your concerns.
These have been integrated into draft rev -12
which the authors feel is ready for RFC editor.

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 for comments by Ines Robles, Roman Danilyv

http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/toerless/bier-te-arch/ca1c4ec15302e5287c0bd60b9f14d2c58428e50f/draft-ietf-bier-te-arch.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/32d75563d07b8f7559bc2a88e80f113e228ad21a/draft-ietf-bier-te-arch.txt

Thanks again for your review.

Toerless

On Wed, Aug 25, 2021 at 11:59:09AM -0700, Roman Danyliw via Datatracker wrote:
> 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?

Yes. 

> ** 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}?

No, the idea was that {VRF,} is ABNF style to indicate that a VRF parameter is optional,
e.g.: only required when a BFER has VRFs and you have payloads that can not distinguish
the VRF by itself, but would require BIER to do it.

> ** 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)?

https://en.wikipedia.org/wiki/Situation_awareness

I first heard the term in conjunction with IP multicast in ca. 2000 from defense
customers. So yes, primarily many-to-many telemetry such as in battlefield
scenarios. The wikipedia article makes it sound as if the term has been adopted by
a range of civilian sector applications as well.

Changed to:

such as live-TV or many-to-many telemetry including situation-awareness (SA).

(i am not sure i should add wikipedia URLs, that seems like the most logical
 known way to look up terms, readers may not be familiar with...).

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

True, but i don't think this document (or for thart matter RFC8279) would be
a good place to authoritatively make statements about this given how that
problem exists for any hop-by-hop packet processing/forwarding protocol.
Including to now 40 year old rfc791. And i am not sure about any elaboration
about this issue in any IP unicast RFC. If there was such an RFC, i'd
be happy to refer to it. But as a blank statement it is just an invitation
for a blackhole debate.

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

By listing all these options and putting a SHOULD to them, the BIER-TE
architecture already goes far beyond what i have seen in any other
forwarding plane architecture documents including rfc3031 or rfc8279.

Remember that the BIER-TE controller may not need to comunicate with BFR
continuously, in some deployments, such as industrial, i can easily see
those situations where everything is statically provisioned initially in a
physical secured environment often relying on trusted human actors. So i
am somewhat concerned about enforcing specific mandatory cryptographic operational
models (as implied by the realities of any explicitly listed protocols
crypto options) against any type of infrastructure management instance.

I am saying this also given how we do know those complex chains of operational
dependencies especially in long-term key management. Industrial deployments may
have multi-decade expectancy of operations for which they still struggle
with key management / crypto agility / software maintenance. 

> ** 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”?

No. BIER sub-domains are just a part of the structured destination address in
the BIER headers: (Subdomain, SI, BSR, BitString).

Aka: it is just an addressing element to structure functionality within an
individual administrative BIER domain.

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

The network wide single "BIER-TE controller" used as a reference
model in document is a "non-local PCE". 

In the classical RSVP-TE model, the ingres router (LSR) acted as both
PCC and PCE. That is i think what rfc4655 would call the local PCE case:
PCE co-located in the same node as the PCC. 

That option could of course also be done for BIER-TE.

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

Fixed

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

Fixed.

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

Fixed.

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

Hopefully better now:

When a fixed mapping from BSL, SD and SI to BIFT-id is used which does
not explicitly partition the BIFT-id space between BIER and BIER-TE, 
such as proposed for non-MPLS forwarding with <xref target="RFC8296"/> encapsulation
in <xref target="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.

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

I am hoping it is rather prudent to do exactly this in the face of possible
changes to the draft in further revisions and given how this is an
informational reference so it won't become RFC (i think) by the time bier-te
draft hopefully becomes one.

I remember a time when we had to document to customers how different versions
of the router software implementated different versions of a MIB draft because
of such changes through thre lifetime of the draft.

> -- Section 4.6.  The phrases “BFR MUST support to configure the BIFT …”

Fixed to:

BFR that support BIER-TE and BIER MUST support configuration that enables 
BIER-TE instead of (non-TE) BIER forwarding rules for all BIFT of one or more 
BIER sub-domains.

> and  “Every BP in the BIFT MUST support to have zero …” do not parse.

Not sure how to change that. Seems ok. to me.