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

[Toerless Eckert <[e-mail]>]

Thanks, Martin

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 Robert Sparks, Yingzhen Qu and Martin Duke.

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

Thanks again for your review.

Toerless

On Tue, Aug 17, 2021 at 12:02:40PM -0700, Martin Duke via Datatracker wrote:
> Martin Duke 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:
> ----------------------------------------------------------------------
> 
> Thanks to Tommy Pauly for the TSVART review.
> 
> (2.1) s/p1...p14/p1...p15

Fixed.

> (4.4) I had to read this section several times to understand the F-BM logic.

Yes. F-BM is the biggest trick in rfc8279 BIER logic and the challenge
here was to find the minimum change to support BIER-TE which doesn't
need the trick but may want to be implemented as easy s possible
on hardware designed for BIER.

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

replaced with:

The following points describe how the forwarding bit mask (F-BM) for each BP is configured in the BIFT and how this impacts the BitString of the packet being processed with that BIFT:

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

Replaced first two bullet points with:

  <t>The F-BMs of all BIFT BPs without an adjacency have all their bits clear. This
  will cause [3] to skip further processing of such a BP.</t>
  <t>All BIFT BPs with an adjacency (with DNC flag clear) have an F-BM
  that has only those BPs set for which this BFR does not have an adjacency.

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

Was an outdated list of references to sections describing the points of optimization
mentioned. List was not updated but removed by recommendation of another reviewer.

> (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?

The forwarding rules suggest that the local_decap({VRF}) can have something
like a VRF parameter. In that respect you could think of one local_decap()
BP per VRF, but i think that would be inefficient use of BP space. But
it might be appropriate in certain deployments. But even then could you
share those BP across all Leaf BFERs by just configuring their BIFT all
with the same e.g.: 5 bits for 5 VRFs (if they have all the same 5 type of
VRFs).

Thanks a lot for the review!

Toerless