Re: [RTG-DIR] Rtgdir telechat review of draft-ietf-bier-te-arch-10

[Toerless Eckert <[e-mail]>]

Thanks, Ines

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 Tue, Aug 24, 2021 at 11:16:55AM -0700, Ines Robles via Datatracker wrote:
> Reviewer: Ines Robles
> Review result: Has Nits
> 
> Hello,
> 
> I have been selected as the Routing reviewer for this draft. The Routing
> Directorate seeks to review all routing or routing-related drafts as they pass
> through IETF last call and IESG review, and sometimes on special request. The
> purpose of the review is to provide assistance to the Routing ADs. For more
> information about the Routing Directorate, please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> It would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through discussion
> or by updating the draft.
> 
> Document: draft-ietf-bier-te-arch-10
> Reviewer: Maria Ines Robles
> Review Date: 2021-08-24
> IETF LC End Date: 2021-08-24
> Intended Status: Standards Track
> 
> Summary:
> 
> This document describes per-packet stateless strict and loose path steered
> replication and forwarding for Bit Index Explicit Replication packets
> (RFC8279), BIER Tree Engineering (BIER-TE), intended to be used as the path
> steering mechanism for Traffic Engineering with BIER. BIER-TE introduces a new
> semantic for bit positions (BP) that indicate adjacencies.
> 
> This document is basically ready for publication. I have some minor
> questions/comments.
> 
> Major Issues: No major issues found.
> 
> Minor Issues: No minor issues found.
> 
> Nits/Comments/Questions:
> 
> - Expand SI at first use --> Set Identifier (SI)?
> - Expand SD at first use --> Sub Domain (SD)?

Fixed.

> Page 7: Question, in the sentence: "...to send in addition to BFR6 via BFR4
> also a copy to BFR3, the BitString needs to be (p2,p5,p8,p10,p12,p13)..." --> 
> should it be added p15 as well, (p2,p5,p8,p10,p12,p13,P15) ?

Fixed.

> Page 7: " many of which are based on assumptions..." --> it would be nice if
> you could state examples of the assumptions, which assumptions?

Changed to:

based on out-of-band knowledge about the required multicast traffic
paths and bandwidth consumption in the network, such as from pre-deployment planning

> Page 8: "BFR4 and from BFR4 to BFR uses (p1,p2,p3,p4,p6).  -->  BFR4 and from
> BFR4 to BFR6 uses (p1,p2,p3,p4,p6).

Fixed (already by another review).

> Page 8: Question, in Figure 2,  You have p6 as forward_routed() to BFR6, and as
> local_decap. Is this correct? Is this reuse of bit positions case?

Great catch. That reuse of the same bit would only work if
the prior hops BFR3 or BFR4 would not reset BP p5 or p6 with DNC.
But this demo was meant to be simple, so i forgot adding p9 on
BFR6 to local_decap() the packet there. Fixed in text and picture.

> Page 9: "...undesired duplicates or loops as explained further down in the
> text."  --> (nice to reference the section where it is explained, Section 5.2)

Fixed.

> Page 10: "See for example See Section 5.1.3...." --> delete the second See

Fixed already by other reviewer.

> Question: Is there specific security considerations when having overlay BIER-TE
> topology?

Excellent point. Added the following paragraph:

<t>BIER-TE forwarding explicitly supports unicast "tunneling" of BIER packets via forward_routed()
adjacencies. The BIER security model is defined by a subsets of interfaces on a BFR
that connect to other BFR of the same BIER domain. For BIER-TE, this security model equally applies
to such unicast "tunneled" BIER packets. This does not only include the need to filter
received unicast "tunneled" BIER packets to prohibit injection of such "tunneled" BIER
packets from outside the BIER domain, but also prohibiting forward_routed() adjacencies
to leak BIER packets from the BIER domain. It SHOULD be possible to configure
interfaces to be part of a BIER domain solely for sending and receiving of unicast
"tunneled" BIER packets even if the interface can not send/receive BIER encapsulated packets.</t>

> 
> Thank you for this document,

Thank you very much for the review!

Toerless

> Ines.