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

[Antoni Przygienda <[e-mail]>]

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
 

<[e-mail]> spake:

    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://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=
    
    
    
    ----------------------------------------------------------------------
    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://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
    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!