BIER Penultimate Hop Popping
draft-ietf-bier-php-16

Thanks for the quick action to make the changes to allow me to clear my discuss. 

I have no objection to publication of this draft.

# Éric Vyncke, INT AD, comments for draft-ietf-bier-php-13

Thank you for the work put into this document.

Please find some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Xiao Min for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 1

I wonder why the MVPN/EVPN examples are given in this document, wouldn't be it enough to say (like in the abstract) "PHP enables the removal of the BIER header by the penultimate router, thereby reducing the processing burden on the final router in the delivery path" ? The text would then be easier to read.

## Section 2.1

What is `A BIER-incapable router` ? Does a router with the BIER code but without BIER configured qualified ? Is it per interface ?

Section 4, paragraph 1
>    BIER PHP can only be used when the conditions specified in Section 2
>    are met.  The BIER OAM functionality is not available on the BIER-
>    incapable flow overlay routers, but using PHP when the conditions are
>    met is simpler than the alternative of using BIER to send to some
>    whereas using non-BIER tunnels to send to other flow overlay routers.

Thanks to Jen Linkova for his OPSDIR review.

He had one minor comment in his review, that I would like to see a response to, if not consider an update to the draft based on the comment.

DOWNREF [I-D.ietf-bier-lsr-non-mpls-extensions] from this Proposed Standard to
draft-ietf-bier-lsr-non-mpls-extensions of unknown standards level. (For IESG
discussion. It seems this DOWNREF was not mentioned in the Last Call and also
seems to not appear in the DOWNREF registry.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "his"; alternatives might be "they", "them", "their"

Thank you to Lars Eggert for the GENART review.

Thanks for the well-written document. I have just a couple of minor comments about the Introduction.

### Section 1, BFR

It seems relatively obvious that "BFR" must mean "BIER Forwarding Router" but please expand it on first use.

### Section 1, directly or indirectly?

   A potential solution to this issue is the use of Penultimate Hop
   Popping (PHP), whereby the upstream BFR pops the BIER header
   [RFC8296] and transmits the payload directly.  This transmission can
   occur either directly or indirectly through any type of tunnel to the
   PE.
   
The end of the first sentence ("transmits the payload directly") conflicts with the beginning of the next ("can occur [...] indirectly"). I think I get what you mean but it's still jarring. Maybe something like "... and transmits the payload without BIER encapsulation"?

NIT:

There is a mention of RFC8279 that is broken (eg it is only written in regular text)

[ Was DISCUSS ]

Thank you for addressing my DISCUSS comment (based on Jen Linkova's OpsDir review (https://datatracker.ietf.org/doc/review-ietf-bier-php-12-opsdir-lc-linkova-2024-09-30/))

I've cleared my DISCUSS.