Subject: Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Wed, 17 Nov 2021 20:11:38 +0000

Hi Alvaro,
Thanks for detail comment. Please find inline response.

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wednesday, October 27, 2021 at 10:23 AM
To: The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
Alvaro Retana has entered the following ballot position for
draft-ietf-bess-evpn-igmp-mld-proxy-14: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/

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

First of all, I am surprised that a document related to IGMP/MLD was not sent
to the pim WG for review.  I can't find any mention of this draft in the pim
WG's archive.
Mankamana:  As in contributor to this document, all the procedures are very much limited to BGP overlay signaling. Not sure which aspect would be reviewed by PIM WG. This draft does not change any behavior of PIM or IGMP .

§11 says this:

   This document does not provide any detail about IGMPv1 processing.
   Multicast working group are in process of deprecating uses of IGMPv1.
   Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and
   above for IPv6.  IGMP V1 routes MUST be considered as invalid and the
   PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606].
   Initial version of document did mention use of IGMPv1 and flag had
   provision to support IGMPv1.  There may be an implementation which is
   deployed as initial version of document, to interop flag has not been
   changed.

Note that the "Multicast working group" mentioned above is in fact the pim WG.
There's no current WG to deprecate IGMPv1, but draft-ietf-pim-3376bis was
recently adopted with the intent to progress IGMPv3 to Internet Standard.  This
text is from draft-ietf-pim-3376bis (it is the same text as in rfc3376):

   IGMPv3 is backward compatible with previous versions of the IGMP
   protocol.  In order to remain backward compatible with older IGMP
   systems, IGMPv3 multicast routers MUST also implement versions 1 and
   2 of the protocol (see section Section 7).

(Section 7/draft-ietf-pim-3376bis talks about interoperability with older
versions.)

All this is to say that requiring that IGMPv1 not be used contradicts the
IGMPv3 specification, which requires the support.  The interoperation between
the different versions is already considered in rfc3376, so the extra
complexity added to this document (tracking the versions in the BGP updates) is
not needed from the router side.

I am balloting DISCUSS because this document is not in line with other
consensus documents (specifically the IGMP specification).  To clear, I will
want the document reviewed by the pim WG.

Mankamana : Do you expect it to be reviewed by PIM WG or we should remove section talking about use of V1 ? Based on current work in PIM WG, our understanding is that “v1 will become deprecated, v2 will still be proposed standard, and v3 will become internet standard.”

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

(1) The terminology section should include IGMP/MLD-related terminology or at
least a pointer to the relevant RFCs.

Also, the messages are called Membership Reports, and not "Join" or "IGMP
Reports".  Similar comment related to "IGMP Queries" and "Membership Requests"
(should be Membership Query).

[I will not make other comments below about this same point.]
Mankamana : will change IGMP join to Membership Request

(2)
[Line numbers from idnits.]

260       1.  When the first hop PE receives several IGMP Membership Reports
261           (Joins), belonging to the same IGMP version, from different
262           attached hosts for the same (*,G) or (S,G), it SHOULD send a
263           single BGP message corresponding to the very first IGMP
264           Membership Request (BGP update as soon as possible) for that
265           (*,G) or (S,G).  This is because BGP is a stateful protocol and
266           no further transmission of the same report is needed.  If the

The behavior in this rule is not required.  Under what circumstances is it ok
for the PE to not wait for several Membership Reports from multiple hosts
before sending a BGP message?

Waiting for multiple messages can clearly result in a delay for an interested
host in receiving the multicast service.  Note that rfc3376 says that
"Multicast routers need to know only that *at least one* system on an attached
network is interested..."
Mankamana :
it SHOULD send a
263           single BGP message corresponding to the very first IGMP
264           Membership Request (BGP update as soon as possible) for that
does this not mean, BGP update should be sent ASAP. It does not state to wait for many ?

(3)

269           (v2 or v3) set.  In case of IGMPv3, the exclude flag MUST also be
270           set to indicate that no source IP address must be excluded
271           (include all sources "*").  If the IGMP Join is for (S,G), then
272           besides setting multicast group address along with the version
273           flag v3, the source IP address and the IE flag MUST be set.  It

"the exclude flag MUST also be set"  I think you meant to reference the Exclude
Group and the IE field in the flags.  Note that the second part ("IE flag MUST
be set") also refers to the same field, but for a different condition.  Please
be consistent and call things (the IE field, in this case) by a single name.

The definitions in §9.* are not consistent either.
Mankamana :  will IE (Include or Exclude) in terminology be enough ? First part of statement talks about (*,G) join where only Exclude flag would be set. Where for (S,G) Include or Exclude either can be set.

(4)

277       2.  When the first hop PE receives an IGMPv3 Join for (S,G) on a
278           given BD, it SHOULD advertise the corresponding EVPN Selective
279           Multicast Ethernet Tag (SMET) route regardless of whether the
280           source (S) is attached to itself or not in order to facilitate
281           the source move in the future.

When is it ok for the SMET route not to be advertised?  IOW, why is it a
recommendation and not a requirement?
Mankamana : changing  SHOULD to MUST ?

(5)

283       3.  When the first hop PE receives an IGMP version-X Join first for
284           (*,G) and then later it receives an IGMP version-Y Join for the
285           same (*,G), then it MUST re-advertise the same EVPN SMET route
286           with flag for version-Y set in addition to any previously-set
287           version flag(s).  In other words, the first hop PE MUST NOT
288           withdraw the EVPN route before sending the new route because the
289           flag field is not part of BGP route key processing.

The requirement (MUST) to re-advertise the same SMET route assumes that there
was an advertisement done already, but rule 2 doesn’t require that.
Mankamana : Changing previous one to MUST should fix this comment too.

(6)

291       4.  When the first hop PE receives an IGMP version-X Join first for
292           (*,G) and then later it receives an IGMPv3 Join for the same
293           multicast group address but for a specific source address S, then
294           the PE MUST advertise a new EVPN SMET route with v3 flag set (and
295           v2 reset).  The IE flag also need to be set accordingly.  Since
296           source IP address is used as part of BGP route key processing it
297           is considered as a new BGP route advertisement.  When different
298           version of IGMP join are received, final state MUST be as per
299           section 5.1 of [RFC3376].  At the end of route processing local
300           and remote group record state MUST be as per section 5.1 of
301           [RFC3376].

Receiving an IGMPv3 Membership Report for the first time, as described here, is
equivalent to the case in rule 2,  However, the normative language is
different: sending an SMET route is required here, but only recommended in rule
2.  I fail to see why the conditions are different.

Also, this rule mentions that the “ IE flag also need[s] to be set accordingly”
while rule 1 requires a specific setting.

This section is talking about the actions of a PE when it receives IGMP
messages — this is what rfc3376 refers to as a multicast router.  §5.1/rfc3376
refers to the host function (group members).  Both statements (which seems
redundant to me) requiring compliance with rfc3376 are misplaced.
Mankamana : Sending you diff soon for your review.

BTW, these are the only references (in the specification part of the text) to
rfc3376.  Given that this document is about IGMP/MLD Proxy, there should be
other references that make clear the normative relationship.  The same comment
applies to the other versions of IGMP mentioned as well as MLD.
Mankamana : Will add reference to IGMP and MLD RFC

(7)

§4.1.1: The set of rules in this section (IGMP/MLD Membership Report
Advertisement in BGP) is preceded with:

256        When a PE wants to advertise an IGMP Membership Report (Join) using
257        the BGP EVPN route, it follows the following rules (BGP encoding
258        stated in Section 9):

But rules 5-7 are about the actions related to the SMET route being received,
not advertising it.  Perhaps divide the list of rules so that it is clear when
they apply.
Mankamana :  making it two section ? one who advertising the route and other for who receiving it ?

(8)

§4.1.1: Rule 7 talks about listening to PIM Hellos.  Please add a Normative
reference to rfc7761.
Mankamana : Added

(9)
§4.1.2: Rules 2-3 are about the actions after the SMET route is received, which
doesn't match with the preface to the rules.  Perhaps divide the list of
rules...

Mankamana : making some changes and sending new text soon.

(10)

1269       IGMP MAY be configured with immediate leave option.  This allows the
1270       device to remove the group entry from the multicast routing table
1271       immediately upon receiving a IGMP leave message for (x,G).  In case
1272       of all active multi-homing while synchronizing the IGMP Leave state
1273       to redundancy peers, Maximum Response Time MAY be filled in as Zero.
1274       Implementations SHOULD have identical configuration across multi-
1275       homed peers.  In case IGMP Leave Synch route is received with Maximum
1276       Response Time Zero, irrespective of local IGMP configuration it MAY
1277       be processed as an immediate leave.

By "immediate leave" I assume you're referring to "low leave latency"
(rfc2236/rfc3376), is that right?   There is no "immediate leave" mentioned in
whose documents.

"IGMP MAY be configured with immediate leave option."  This "MAY" seems to just
be stating a fact. s/MAY/may

When is it ok for implementations to not have the same configuration?  IOW, why
is that a recommendation and not a requirement?

Mankamana: Yes immediate leave is “low leave latency”. Since its optional functionality, its not hard requirement. An implementation may or may not support this functionality.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 18 Nov 2021 12:50:37 -0800

On November 17, 2021 at 3:11:49 PM, Mankamana Mishra wrote:

Mankamana:

Hi!

...
> Mankamana: As in contributor to this document, all the procedures are very
> much limited to BGP overlay signaling. Not sure which aspect would be
> reviewed by PIM WG. This draft does not change any behavior of PIM or IGMP .

This document is about proxying IGMP/MLD through an EVPN domain to
"reduce the flooding of IGMP messages", which implies that the
messages are received and recreated [*] based on the BGP information.
The routers are them acting as both a multicast router and group
member -- this behavior, including the operation of multiple versions
of IGMP on the same link has already bee specified in rfc3376.  The
mechanism described in this document don't seem to be in line with
that -- starting with the requirement to consider IGMPv1 as invalid.

So, yes, there are no changes to the protocols, but the behavior
specified is not in line with the existing standards.  That is what I
want the pim to look at.

[*] That is part of Eric's DISCUSS.

...
> Mankamana : Do you expect it to be reviewed by PIM WG or we should remove
> section talking about use of V1 ? Based on current work in PIM WG, our
> understanding is that “v1 will become deprecated, v2 will still be proposed
> standard, and v3 will become internet standard.”

I expect the document to be reviewed by pim.

As I mentioned before, the current work in pim is to move rfc3376 to
Internet Standard, which would still be backwards compatible with
IGMPv1.

...

An "IGMP join" should be a "Membership Report" (not a request).  There
are no "requests", just "Membership Queries".

> does this not mean, BGP update should be sent ASAP. It does not state to wait

The first part of that sentence says: "When the first hop PE receives
several IGMP Membership Reports..."  The action is predicated (in the
text) by receiving multiple messages -- after that you're right, the
message would be send ASAP.

> Mankamana : will IE (Include or Exclude) in terminology be enough ? First
> part of statement talks about (*,G) join where only Exclude flag would be
> set. Where for (S,G) Include or Exclude either can be set.

No -- please be consistent throughout.

Note that the flag is called IE (in §9.1) and defined as a single bit,
so talking about how "Include or Exclude either can be set" is
confusing: the bit is either set or it isn't -- these are not
independent flags.

> Mankamana : changing SHOULD to MUST ?

That's the question! :-)

It seems to be that the SMET route should be advertised always
(required = MUST), but I'm asking why you chose to allow for it to not
be advertised sometimes (recommended = SHOULD)?

> Mankamana : Changing previous one to MUST should fix this comment too.

Yes, if that is the right thing to do there.

> Receiving an IGMPv3 Membership Report for the first time, as described here,
> is equivalent to the case in rule 2, However, the normative language is
> different: sending an SMET route is required here, but only recommended in
> rule 2. I fail to see why the conditions are different.
>
> Also, this rule mentions that the “IE flag also need[s] to be set
> accordingly” while rule 1 requires a specific setting.
>

Ok

> Mankamana : Will add reference to IGMP and MLD RFC

Please do closer to the start of the document, to establish the
relationship early on.

> Mankamana : making it two section ? one who advertising the route and other

Two sections is ok -- or simply two lists in the same section.  Up to you.

...
> (9)
> §4.1.2: Rules 2-3 are about the actions after the SMET route is received,
> which doesn't match with the preface to the rules. Perhaps divide the list
> of rules...
>
>
>

Ok.

> those documents.
> Mankamana: Yes immediate leave is “low leave latency”. Since its optional
> functionality, its not hard requirement. An implementation may or may not
> support this functionality.

Ok.  Let me ask a different question: what is the effect of not having
the same configuration?  Just from the leave latency point of view, it
looks like the behavior may be inconsistent.

Thanks!

Alvaro.