Subject: [Bier] Warren Kumari's No Objection on draft-ietf-bier-mpls-encapsulation-11: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Oct 2017 11:34:15 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-bier-mpls-encapsulation-11: 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 IESG DISCUSS and COMMENT positions.

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

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

[ Edit: Thanks for addressing my DISCUSS - I think that the document is now
even better ]

I like the document (with Mirja's MTU issue resolution) - I went through trying
to find nit's to improve it, but came up dry!

-- Original discuss for posterity ---
I believe that there needs to be better guidance of what to do when the TTL
expires (and want to thank Al (OpsDir) for noticing this): "Of course, if the
incoming TTL is 1, the packet MUST be treated as
      a packet whose TTL has been exceeded.  The packet MUST NOT be
      forwarded, but it MAY be passed to other layers for processing
      (e.g., to cause an ICMP message to be generated, and/or to invoke
      BIER-specific traceroute procedures, and/or to invoke other OAM
      procedures.)"

I have read the response to the OpsDir review
(https://www.ietf.org/mail-archive/web/ops-dir/current/msg02897.html) -- I
fully agree that mandating a response to every packet would be bad, but I think
that "it MAY be passed to other layers for processing" is too weak. I think
SHOULD would be fine, or, even better, something about "SHOULD, with optional
implementation specific rate-limiting" or something. The current text makes it
sound like it's perfectly fine to just not bother implementing any sort of
reporting / response handing after dropping the packet. I think that this
should be an easy fix and not hold up the document (much or at all)