Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks
draft-ietf-bier-mpls-encapsulation-12

[ 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)

The definition of BSL indicates:

      Note: When parsing the BIER header, a BFR MUST infer the length of
      the BitString from the BIFT-id, and MUST NOT infer it from the
      value of this field.

It then goes on to say:

      The value of this field MUST NOT be set to any value other than
      those listed above.  A received packet containing another value in
      this field SHOULD be discarded, and an error logged.

The expectation that the router is auditing the value of this field raises the question of whether the router should check if the length indicated by the BFR field is different than the BFR that corresponds to this packet's BIFT-id.

My suggestion would be to make this consistent: either routers always ignore the value of this field (even if it is out of range), or routers verify not just that the value is valid, but that it is in fact accurate.

----------------------------------------------------------------------

I don't see any information in the ballot or the shepherd's write-up discussing the rationale for having more than five authors on this document. Has this been discussed with the authors, contributors, and working group already?

Just a couple of minor comments and nits:

- Shouldn’t the example in 2.1.1.1 result in 16 potential labels, and not just 12?  Maybe I'm just missing something obvious...

- From 2.1.1.2: “The BFR MUST perform the MPLS TTL processing correctly.”  Sure, but what does correctly mean?  If the TTL field is “usual MPLS "Time to Live" field ([RFC3032])”, then I think that it is redundant (and not necessary) to repeat the processing here — just the exceptions.  Are there any?

- From 2.1.2: “OAM:…The use of these bits in other than the default manner is OPTIONAL.  Specification of the non-default use or uses of these bits is outside the scope of this document.”  Using Normative language without an actual specification (because it is out of scope) just doesn’t fit: s/OPTIONAL/optional

- Nit: Please include the explanation of the fields (in 2.1.1.2/2.2.1.2) in the same order as the appear on the Header.

- Please add some text describing the nature of the experiment, even if that is simply "to get more implementation and deployment experience".

- 2.1.2, "Ver": " The value 0xF is reserved for experimental use; that value MUST
      NOT be assigned by any future IETF document or by IANA."

Isn't the entire document experimental? It seems odd to define an experimental version code.

Thanks for addressing my prior discuss.

Thanks for addressing my discuss on MTU discovery/fragmentation!

I agree with Mirja's Discuss position, and with the proposed resolution. Thanks to the authors for that.