Hi Authors, I noticed the following text about error handling in -05:
When a PE receives an EVPN SMET route for a given (*,G), it compares the received version flags from the route with its per- PE stored version flags. If the PE finds that a version flag associated with the (*,G) for the remote PE is reset, then the PE MUST generate IGMP Leave for that (*,G) toward its local interface (if any) attached to the multicast router for that multicast group. It should be noted that the received EVPN route SHOULD at least have one version flag set. If all version flags are reset, it is an error because the PE should have received an EVPN route withdraw for the last version flag. Error MUST be considered as BGP error and SHOULD be handled as per [RFC7606]. ... When a router that receives a BGP Update that contains the Selective Multicast Route flag with its Partial bit set (Not following this specification) determines that the route is malformed, the router SHOULD treat this Update as malformed . Error MUST be considered as BGP error and SHOULD be discarded as per [RFC7606]. An implementation SHOULD provide debugging facilities to permit issues caused by a malformed join sync route to be diagnosed. At a minimum, such facilities MUST include logging an error when such an route is detected. (And there are several more similar paragraphs, I won’t repeat them all.) Thank you for adding text about error handling! I have a few questions and comments about it. 1. You restrict the second quoted text to only apply when Partial is set. What is the required behavior when Partial is not set but the route is malformed? Unless you specify something else, the action would be to reset the session, but even if that’s what you want, you should say so, to be clear. 2. … But I’m confused about the Partial bit. Everything in your document relates to NLRI, carried in the existing MP_REACH_NLRI and MP_UNREACH_NLRI attributes. The encoding of these attributes doesn’t include any kind of per-NLRI Partial bit, it’s a per-path attribute thing. Since these two attributes are non-transitive, the Partial bit can never be set on them (it’s specifically excluded in RFC 4271). In short, there’s no such thing as a “Selective Multicast Route flag with its Partial bit” set OR cleared, a route doesn’t HAVE a Partial bit. 3. Come to think of it, I can’t even figure out what the “Selective Multicast Route flag” is. I confess I haven’t done a close reading of the document, but I did try to work it out, and I can’t. Is it a flag? Is it a route? Is it a typo? Inquiring minds want to know! 4. You say “discarded as per [RFC7606]” or “handled as per [RFC7606]” but 7606 doesn’t provide just a single strategy, it provides four options (https://tools.ietf.org/html/rfc7606#page-5), namely session reset, AFI/SAFI disable, treat-as-withdraw, and attribute discard. I’m guessing you mean treat-as-withdraw; in any case, you need to be specific about the behavior you want. Just as a reminder, RFC 7606, in section 3(j), points out that the NLRI need to be successfully parsed for treat-as-withdraw to work, and if the NLRI can’t be parsed, session reset still has to be used. I guess you must be assuming the NLRI could be malformed in such a way as to still allow the key to be extracted from them, otherwise there’s no way to do treat-as-withdraw to them. As far as I can tell from a skim, only a malformed flags field would qualify for this, everything else is part of the key, right? I think you’ll need to spell this out, see also point 5 below. 5. You say what to do if it’s determined a route is malformed, but for the most part you don’t say what criteria are used to make that determination. RFC 7606 section 8 (https://tools.ietf.org/html/rfc7606#page-15) asks you to please be more specific, it also provides a lot of examples of specificity in its earlier sections. Since you aren’t specifying a new attribute, the section technically doesn’t apply to you, but nonetheless I think the guidance is relevant: A document that specifies a new BGP attribute MUST provide specifics regarding what constitutes an error for that attribute and how that error is to be handled. 6. I do notice this text too: Suppose a PE receives a particular IGMP Join Synch or IGMP Leave Synch route, say R1, and suppose that R1 carries an ES-Import RT that is one of the PE's Import RTs. If R1 has no EVI-RT EC, or has more than one EVI-RT EC, the PE MUST apply the "treat-as-withdraw" procedure of [RFC7606]. This is perfect, thank you! It names a specific error handling strategy. The error condition is spelled out clearly and it’s also helpful that the error condition relates to attributes that aren’t NLRI, so we can be confident that the NLRI are well-formed, thus we can find the key to enable us to know what to withdraw. Regards, —John
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess