Subject: [Bier] Warren Kumari's Discuss on draft-ietf-bier-mpls-encapsulation-10: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Tue, 24 Oct 2017 12:26:30 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-bier-mpls-encapsulation-10: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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)

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

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!

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 24 Oct 2017 21:29:17 +0000

Warren, as first, maybe obvious, remark, that discussion goes to a long-standing tradition started probably (at least in my time) with RFC1812. Then my further observations

A) First, I agree that if the text reads as in “don’t bother to implement anything” this is not the intention and could benefit from clarification that implementation has carefully to take into consideration what action is appropriate. 
B) Having said that, there is no single “correct” thing to do in such cases depending on device class. A small router/edge device may send something every time up to core case where sending anything (even rate limited and so on) may be a very bad thing indeed if you provide a DDoS attack vector or disclose topology information to probes crafting such packets. If the probes spoof source addresses, all interesting bets are off on top. 
C) Providing “implementation guidelines” is often missing the mark in RFCs, e.g. something along the lines of “rate-limiting” is very hard test for compliance (what if I implement something that does 1 packet per millennium ;-). Implementations have many interesting ways to deal with reality of deployments that RFCs often miss or with the best of all intentions, due to implementation recommendations, ultimately prevent. 
D) Last, I would venture that this problem is very similar to MPLS and other technologies that deal with TTL expiry. It would be ideal to be able to point to this in this draft (did encapsulation design team say anything about it ?) and  in lack thereof, putting a section into specific draft on this specific technology may contradict future BCPs so I doubt it’s the best course of action.  

--- tony

<[email-masked]> spake:

    Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=mf-x4KG0t9mPX-igM3lPJltKtGywYxZUTfLk_LTBtNQ&s=Yl13BwXoIgA2gXQ-3LzBGlh51RrMyHo62YdO-5_TOP4&e=
    for more information about IESG DISCUSS and COMMENT positions.

    The document, along with other ballot positions, can be found here:
    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dmpls-2Dencapsulation_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=mf-x4KG0t9mPX-igM3lPJltKtGywYxZUTfLk_LTBtNQ&s=7Ov3tO5ZGxAox2fREULt6vKvBwghazrqc9fNRrmttTM&e=

    
    
    (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_ops-2Ddir_current_msg02897.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=mf-x4KG0t9mPX-igM3lPJltKtGywYxZUTfLk_LTBtNQ&s=GHIWqhG0uccbkCzUgMbMGQfvm45BB_MT2bDA0aQD8Qg&e=) -- I