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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
