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

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

Hi Alvaro,
Here is the updated version and update on what changes are being incorporated (Version 16 of draft).

PIM WG Review comment :  There were only two comment received from PIM working group and both are being addressed.

  1.  Comment was to add terminology DC
  2.  Second comment was same as your about immediate leave

Apart from that there were no concern from PIM WG .

Open Question :

  1.  Statements about IGMP V1, there was no concern from PIM WG or BESS WG either. Do you want any thing specific to be mentioned in this draft ?
  2.  Later inline for flag question, I have one way to handle this. Please let me know your view and I can make the changes.


Based on your comments :

  *   IGMP join are changed to Membership Report
  *   Inline comments also handled

Some of the comment inline about accepted changes.

From: Mankamana Mishra (mankamis) <[e-mail]>
Date: Wednesday, December 8, 2021 at 3:14 PM
To: Alvaro Retana <[e-mail]>om>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>rg>, [e-mail] <[e-mail]>om>, [e-mail] <[e-mail]>rg>, [e-mail] <[e-mail]>
Subject: Re: Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
Hi Alvaro,
while i wait for PIM working group to provide and submit the next revision this Friday. I have question about one of the comment. Please let me know if these changes are something you expecting.


  *   IGMP Join changes to Membership Report
  *   IGMP Join Sync changes to Membership Report Sync
  *   All mention of Join changes to Membership Report



Since IGMP Join Sync has been terminology getting used for long with this draft, wanted to make sure this is ok before i publish the changed version.
Though i was trying to see if RFC3376 uses term Join. It looks like it does. but many places it uses Membership reports for actual packet on wire.

Mankamana

On 11/18/21 12:50 PM, Alvaro Retana wrote:

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





Mankamana:



Hi!





...

----------------------------------------------------------------------

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 .



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.







...

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.”



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.



Mankamana : Document has been reviewed by PIM WG and there were no concern towards IGMP V1 text.

...

----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------



(1) The terminology section should include IGMP/MLD-related terminology or at

least a pointer to the relevant RFCs.



Mankamana: Added text pointing to IGMP V2 and V3 RFC



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



An "IGMP join" should be a "Membership Report" (not a request).  There

are no "requests", just "Membership Queries".



Mankamana: Updated all joins and IGMP Query





(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..."









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 ?



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: Removed term “several”







(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.



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 :  Will it be ok to add more text in encoding section where

                                    IE = 0    means <XXXXX>

                                    IE = 1    means <YYYYY>



And rest other places just mention what flag IE field MUST be set ?



Please let me know if this works with you, I can make changes.

(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 ?



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: Thanks for comment, I do not think there would be any condition where this spec is configured and selective multicast route not to be sent. So made it 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.



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



Mankamana: Previous comment took case of this.



(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.



Ok



Mankamana:

·         Previous section made MUST, so its aligned with this section now .

·         There is detail text getting added in Flag definition about what does IE flag means. Since this section does not talk about specific filter (Include or Exclude), it would be good to keep it generic.

·         About comment on section 5.1 of IGMP V3 spec, this statement covers the case how to handle different membership request. Section 5.1 talks about final state to be kept as router. And what these statement means, same procedure MUST be applied at router where local membership request came and remote site as well where membership request were received over BGP.



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



Please do closer to the start of the document, to establish the

relationship early on.



Mankamana: Added familiarity in terminology section itself.



(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 ?



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



Mankamana: Did two list in same section and included text which tells first 4 rules are for originator and last 3 rules are for remote site.



...

(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.



Ok.



Mankamana: I did align it by having two list one for originator and another for remote. But I think diving these statement further may lead to confusion and I feel at current state it does provide all the meaning. If you have something specific in mind please let me know.



(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

those 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.



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.

Mankamana: After reading IGMP V3 spec again, since original spec does not define separate processing for low latency leave, rather it just provides provision. I think this section may not be needed. Since presence  low latency option (which is implementation specific) does not change BGP procedure . removing this section.



Thanks!



Alvaro.