Hi Ali, Thank you for considering my comments.
About the error handling aspects, we are happy to provide some text. About the use of leave group synch sequence number, to be honest, in order to suggest text, I would need to understand what the value of this seq number is, and what situations solves. Depending on that we should specify the right error handling in order to avoid interop issues. Can you guys elaborate here? Also, when there is a router R attached to a BD on a PE, and the PE receives an SMET route, the text mentions the PE needs to generate IGMP/MLD reports to R. But the text does not say what to do in case R only supports version x but the SMET includes version y. Sorry if we missed it. Thanks. Jorge From: "Ali Sajassi (sajassi)" <[email protected]> Date: Thursday, October 10, 2019 at 2:16 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email protected]>, "[email protected]" <[email protected]>, "Mankamana Mishra (mankamis)" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review Hi Jorge, Thanks for your comments and I agree with you that it can be improved further. With respect to your editorial comments (i.e., first two bullets and the typos), we’ll take care of them but with respect to your non-editorial comments (i.e., last two bullets), can you provide us with your proposed texts as the starting point. Cheers, Ali From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email protected]> Date: Wednesday, October 9, 2019 at 5:02 PM To: "[email protected]" <[email protected]>, "Mankamana Mishra (mankamis)" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review Resent-From: <[email protected]> Resent-To: Cisco Employee <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> Resent-Date: Wednesday, October 9, 2019 at 5:01 PM Hi Mankamana and authors, I went through version 4 of this draft. Looks much better, thanks. I still think it can be improved before it progresses further: - The abstract and introduction should already say that the procedures are valid for MLD proxy, in addition to IGMP proxy. The last paragraph in the terminology section is good, but I think it should go into the introduction IMHO. - “IGMP” join/leave synch route is still used throughout the text, whereas Multicast join/leave synch route should be used. - Error handling for routes type 6/7/8: o Can you mix source and groups of different families? I assume not, but it would be nice to be explicit o Can the originator IP be of different family than source/group? I assume yes, but it would be nice to be explicit - Multicast Leave synch route and Leave Group Synch sequence number, needs clarification, I think it is underspecified: o The PE advertising the route will increment the seq number with each leave procedure for the (x,G), but how does it have to be processed at reception? o Is a new seq number for the same [RD,esi,tag,(x,G),orig] restarting the max response time for the (x,G)? o What if the received seq number is lesser than the previous one for the same route? Any action? Typos: - Section 4.1.1 – s/the exclude flag MUST also needs to/the exclude flag MUST/ - Section 4.1.2 – s/MUST withdraws/MUST withdraw/ - Section 5.1 – s/IMGMPv3/IGMPv3/ Thank you! Jorge From: BESS <[email protected]> on behalf of "[email protected]" <[email protected]> Date: Tuesday, August 27, 2019 at 9:29 AM To: "Mankamana Mishra (mankamis)" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review Hi Mankamana, Pls find additional feedbacks inline. Brgds, Stephane From: Mankamana Mishra (mankamis) [mailto:[email protected]] Sent: Tuesday, August 27, 2019 00:38 To: LITKOWSKI Stephane OBS/OINIS; [email protected]; [email protected] Cc: Mankamana Mishra (mankamis) Subject: Re: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review Hi Stephane, Thanks for your review comment. Please find inline. Thanks Mankamana From: BESS <[email protected]> on behalf of "[email protected]" <[email protected]> Date: Tuesday, August 20, 2019 at 6:20 AM To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [bess] draft-ietf-bess-evpn-igmp-mld-proxy-03 shepherd's review Hi, There are some Nits to fix: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-evpn-igmp-mld-proxy-03.txt Here is my review of the document: Abstract & Intro: s/RFC 7432/ RFC7432. The reference should be removed from the abstract (as per IDNits). Mankamana: Will be taken care of in next revision. §2.1: It may be good to change the paragraph name to IGMP/MLD proxy and use IGMP/MLD in the paragraph. This comment could apply to various other places of the document. Mankamana: Will take care for paragraph name. Inside paragraph we have used IGMP , and start of the document we did state that all of IGMP procedure are applicable for MLD too. Is it ok ? §2.1.1: -“it only sends a single BGP message corresponding to the very first IGMP Join”. [SLI] Do we really care about the IGMP message (first or second…) used as a source to build the EVPN route ? The important point is that we do it only one time. Mankamana: changing text to “very first IGMP Join received”. Purpose of this text is to clarify that we send BGP route as soon as we process it for first time locally. Subsequent joins are not sent. [SLI2] Could you add a statement about this goal of sending the BGP update asap ? - For MLD what is the expected behavior in term of flag setting in the SMET, do we set v2 for MLDv2 or do we consider that it is equivalent to IGMPv3 and then we set v3 ? Mankamana: Have text in terminology “ This document also assumes familiarity with the terminology of [RFC7432]. Though most of the place this document uses term IGMP membership request (Joins), the text applies equally for MLD membership request too. Similarly, text for IGMPv2 applies to MLDv1 and text for IGMPv3 applies to MLDv2” I hope this covers your comment. [SLI2] It does partially, the thing that IGMPv2 is similar to MLDv1 does not explicitly say what we do it term of encoding of the version number. As the version encoding is clearly stated in §7.1, it would be better to point to this paragraph rather than giving an ambiguous/partial information there. - s/BGP is a statefull/BGP is a stateful ? Mankamana : Done. - In 1), for clarity purpose, it would be good to separate the (*,G) and (S,G) case in two separate paragraphs. At the first read, when reading “In case of IGMPv3, exclude flag…”, I thought it was always applicable for IGMPv3 which does not make sense, while it is applicable only “If the IGMP Join is for (*,G)”. Mankamana: Across document (*,G) and (S,G) processing have been written together, do you think for consistency it might be good to keep it in single paragraph ? [SLI2] They can remain in the same section, I just wanted to add an empty line just before “If the IGMP Join is for (S,G),”. - IMO, 1) 2) 3) and 4) should use normative language Mankamana: Will be taken care in next update. - Wouldn’t it be better to present the encoding of SMET before ? Because the text talks about fields set in the route while it hasn’t been presented yet. Mankamana: Do you want to move BGP encoding before this section ? [SLI2] Two options, you move the encoding before or you at least point to the section where the encoding is detailed. - 5) talks about errors that SHOULD be logged, but from a BGP perspective, is it considered as a BGP error ? What is the expected behavior per RFC7606 ? Mankamana: Would update this, and it SHOULD be considered as BGP error and should be handled as per RFC7606 - 7) is not clear about IGMPv3, the first part of the text tells that the IGMP Join must not be sent if there is no PIM router. While the end of the text tells that it is not a problem for IGMPv3. So is there a difference between IGMPv2 and IGMPv3 reports ? Mankamana: This comment is not clear. Last part of the paragraph trying to explain that what is difference in behavior for IGMPv2 and IGMPv3 . If you think text should be modified, it would be great if you could suggest expected text . [SLI2] It is not clear to me if the IGMP suppression is applicable both to IGMPv3 and IGMPv2 or only to IGMPv2 as IGMPv3 does not have the issue. The text is ambiguous on this point. §2.1.2: - You have a paragraph numbering issue “IGMP Leave Group Advertisement in BGP” should be 2.1.2 Mankamana: Done - As for §2.1.1, normative language should be used Mankamana: Taking care in next revision. - 2) I agree that there is an error when a SMET is received with all version flags unset. How does the receiver handle this ? does it consider the NLRI has withdrawn per RFC7606 from a BGP perspective ? Does it the the current state of the route and ignore the update ? Does it close the session ? Mankamana: will update the text “error MUST be considered as BGP error and should be handled as per RFC7606” - 2) “If the PE receives an EVPN SMET route withdraw, then it must remove the remote PE from the OIF list associated with that multicast group.” This text is a duplicate on 3). Mankamana: Done §2.2: s/each PE need to have/each PE MUST have/ ? Mankamana: Done §4: s/support IGMP sync procedures/support IGMP synchronization procedures/ Mankamana: Done §4.1: s/The IGMP Join Sync route carries the ES-Import RT/ The IGMP Join Sync route MUST carry the ES-Import RT/ Mankamana: Done Again, the paragraph lacks of normative language Mankamana: Done §4.3: s/procedure section(4.1)/the procedure defined in section 4.1/ s/Remote PE (PE/Remote PEs (PEs/ Mankamana: Done §5: Need to use normative language The paragraph uses IGMP Join Sync Route or Leave Sync route while §7 uses Multicast Join Synch Route. Please ensure consistency. This applies to other sections of the document. Mankamana: Done §6: Please expand “IR” in the title and add it into the acronyms section. Mankamana: Done “all of the PEs in the BD support that tunnel type and IGMP”, do you mean IGMP proxy ? Mankamana: Yes, it would be IGMP Proxy, would make the changes. §7.1 brings some clarification about MLD usage which wasn’t clear in section 2. However §2 is still confusing in version numbers between IGMP and MLD. As an example, a SMET with a source must not exist with IGMPv2/1 while it must not with MLDv1 only. Mankamana: Will add more text clarifying 1. With respect to IGMP to MLD mapping , IGMPv2 should be mapped to MLDv1. And IGMPv3 should be mapped to MLDv2 2. For flag encoding, v1 flag would carry IGMP v1 as well as MLD v1 & v2 flag would carry IGMPv2 as well as MLDv2. Looks ok ? [SLI2] Yes, it looks ok, this means that an implementation should look not only at the flags but also to the group length/source length to understand if this is MLD or IGMP. §7.1.1 “Support for this route type is optional.”. With regards to RFC7432, yes. However if an implementation supports this draft, the support of the NLRI is mandatory. Mankamana: Do you want to remove optional statement here ? or explicitly state that with respect to 7432 this is optional. But mandatory if support for this draft is claimed ? [SLI2] I propose to remove it. §7.3.1 Typo is the title: s/Multicas/Multicast/ Mankamana: Done §7.4: s/it Must set the IGMP Proxy/it MUST set the IGMP/MLD Proxy/ Could we have some device that support IGMP proxy but not MLD proxy ? Mankamana : An implementation can have partial support. But with respect to EVPN, do we really need to be address family dependent ? [SLI2] That’s an open question ! We should wonder if there is any hurt doing that in case of partial support. §9: s/RECOMENDED/RECOMMENDED Mankamana: Done §10: Does it change something to IGMP/MLD security ? Maybe this should be mentioned as well Mankamana: It should not be adding any security , and IGMP/MLD standard security aspect should be applicable here as well. I would add text mentioning that. References: I think that IGMP and MLD RFCs should be set as normative. You should add MLDv1, IGMPv2, IGMPv1 as references as well and use the references in the text. Mankamana: Done RFC7387 and 7623 are referenced but not used Mankamana: Done s/FC4541/RFC4541/ Mankamana: Done RFC7606 and 4684 should be set as normative Mankamana: Done Brgds, [Orange logo]<http://www.orange.com/> Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 06 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> NEW ! mobile: +33 6 71 63 27 50 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> NEW ! [email protected]<mailto:[email protected]> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
