Re: [bess] [Idr] Error handling in draft-ietf-bess-evpn-igmp-mld-proxy-05

["Mankamana Mishra (mankamis)" <[e-mail]>]

Hi John,
Wanted to check if you are ok with current version of draft,
https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-06

we have addressed all of your comment. Before short WGLC , I would be addressing some more comments. If there is still any concern I can take care of it in coming version. Please let me know.

Mankamana

From: Idr <[e-mail]> on behalf of John Scudder <jgs=[e-mail]>
Date: Friday, May 29, 2020 at 6:39 PM
To: "[e-mail]" <[e-mail]>
Cc: "idr@ietf. org" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [Idr] Error handling in draft-ietf-bess-evpn-igmp-mld-proxy-05

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