Hi Gunter and authors, We have now received all necessary approvals and consider AUTH48 complete:
https://www.rfc-editor.org/auth48/rfc9739 Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time. Best regards, RFC Editor/rv > On Mar 3, 2025, at 3:22 AM, Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com> wrote: > > Hi Rebecca, > > Please find my approval. > Thank you. I looked at the changes in the diff file.. > > Kind Regards, > G/ > > -----Original Message----- > From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> > Sent: Thursday, February 27, 2025 11:27 PM > To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Hooman Bidgoli (Nokia) > <hooman.bidg...@nokia.com>; Stig Venaas (svenaas) <sven...@cisco.com>; Gunter > van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; Mankamana Mishra > (mankamis) <manka...@cisco.com>; s...@cisco.com; zzh...@juniper.com; > michael.mcbr...@futurewei.com > Cc: pim-...@ietf.org; RFC Editor <rfc-edi...@rfc-editor.org>; > pim-cha...@ietf.org; ext-zhang.zh...@zte.com.cn <zhang.zh...@zte.com.cn>; > auth48archive@rfc-editor.org > Subject: Re: [AD] AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for your > review > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > Hi Jeffrey, > > Thanks for the super quick reply! I marked your approval on the AUTH48 status > page for this document (see https://www.rfc-editor.org/auth48/rfc9739). > > Once we receive approval from Gunter, we can move this document forward. > > Thank you, > RFC Editor/rv > > > >> On Feb 27, 2025, at 2:23 PM, Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> >> wrote: >> >> Hi Rebecca, >> >> I approve the changes. >> >> Thanks! >> Jeffrey >> >> >> Juniper Business Use Only >> -----Original Message----- >> From: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org> >> Sent: Thursday, February 27, 2025 5:17 PM >> To: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com>; Stig Venaas >> (svenaas) <sven...@cisco.com>; Jeffrey (Zhaohui) Zhang >> <zzh...@juniper.net>; Gunter van de Velde (Nokia) >> <gunter.van_de_ve...@nokia.com>; Mankamana Mishra (mankamis) >> <manka...@cisco.com>; s...@cisco.com; zzh...@juniper.com; >> michael.mcbr...@futurewei.com >> Cc: pim-...@ietf.org; RFC Editor <rfc-edi...@rfc-editor.org>; >> pim-cha...@ietf.org; ext-zhang.zh...@zte.com.cn >> <zhang.zh...@zte.com.cn>; auth48archive@rfc-editor.org >> Subject: Re: [AD] AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for >> your review >> >> [External Email. Be cautious of content] >> >> >> Hello authors and Gunter*, >> >> Authors - We updated the files per the recent discussion and also updated >> Jeffrey’s email address. Please review and let us know any concerns. >> >> We still need Jeffrey’s approval; we have received approval from all other >> authors. Jeffrey, let us know if you approve the document in its current >> form. >> >> *Gunter, as AD, please review and approve the following changes, which are >> “above editorial”. These are best viewed in this diff file: >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739-auth48diff.html__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIp6WEj_U$ >> . >> >> - Deletion of "adjacent Layer 3” in second paragraph of Section 3 >> (author comment: We should remove the "adjacent layer 3" wording from >> the above. The very use case that led to this document involves >> routers *indirectly* connected by a BIER domain (which are composed of >> layer 3 routers) - we want to signal PIM states among non-adjacent >> routers over this PLI.) >> - Changes in Section 3.2.1, including removal of [IANA-PIM-Attr-Types] >> (if needed, see author emails on 24 February) >> - Change to second sentence in Section 3.3 (if needed, see author >> emails on 24 February) >> >> — FILES (please refresh) — >> >> Updated XML file: >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc97 >> 39.xml__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDo >> CZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAILhNP5RA%24&data=05%7C02%7Cg >> unter.van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508dd577deafd%7C5d >> 4717519675428d917b70f44f9630b0%7C0%7C0%7C638762920526835789%7CUnknown% >> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z >> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TyGQy%2FYO6RcE >> WoXYIgrQip15DoQXyMlN%2F7vWWmyaQGw%3D&reserved=0 >> >> Updated output files: >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc97 >> 39.txt__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDo >> CZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIXk2-JOk%24&data=05%7C02%7Cg >> unter.van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508dd577deafd%7C5d >> 4717519675428d917b70f44f9630b0%7C0%7C0%7C638762920526848269%7CUnknown% >> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z >> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Xr%2BKeadnx7KA >> YQT5UCc3aEWRVczkEq1Kn2DRSwwjeb8%3D&reserved=0 >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc97 >> 39.pdf__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDo >> CZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIGUB6A2Y%24&data=05%7C02%7Cg >> unter.van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508dd577deafd%7C5d >> 4717519675428d917b70f44f9630b0%7C0%7C0%7C638762920526859080%7CUnknown% >> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z >> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D9lY37ZxI3aJ7A >> GZV%2B0aCpW5p53bz6iUB8hGMu1MPlg%3D&reserved=0 >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc97 >> 39.html__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zD >> oCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIHqP02K8%24&data=05%7C02%7C >> gunter.van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508dd577deafd%7C5 >> d4717519675428d917b70f44f9630b0%7C0%7C0%7C638762920526869811%7CUnknown >> %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4 >> zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HFtnaEpTnO7up >> EUGQTEfaIYCwsTzCcFUE72rH%2F06R48%3D&reserved=0 >> >> Diff file showing changes made during AUTH48: >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc97 >> 39-auth48diff.html__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs >> 1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIp6WEj_U%24&data >> =05%7C02%7Cgunter.van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508dd5 >> 77deafd%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C63876292052688062 >> 1%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIs >> IlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iM >> y0SEU2oXR9tWVNLfNN9sf00b34n9UkFCJriWJ39mY%3D&reserved=0 >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc97 >> 39-auth48rfcdiff.html__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0 >> GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIhNQens4%24&d >> ata=05%7C02%7Cgunter.van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508 >> dd577deafd%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C63876292052689 >> 1421%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM >> CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata >> =uZMzZvX%2Fef7kyqILuswD%2FoNUwT5PIKZzc1aN%2Br80yiU%3D&reserved=0 >> (side by side) >> >> Diff files showing all changes: >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc97 >> 39-diff.html__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jd >> CV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIr4YLawg%24&data=05%7C >> 02%7Cgunter.van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508dd577deaf >> d%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638762920526902082%7CUn >> known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi >> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NqL0N9Q5 >> OQGd%2FlHFs0z8EcXzIv2uRbTkTpZPOeSikXk%3D&reserved=0 >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc97 >> 39-rfcdiff.html__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km >> 2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIdTjA5JU%24&data=05 >> %7C02%7Cgunter.van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508dd577d >> eafd%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638762920526912835%7 >> CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA >> iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ElZjs >> fiN1NjgErLgJMxk%2FQ7NCvH8Qs%2FwFhDGYJxrmHk%3D&reserved=0 (side by >> side) >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc97 >> 39-alt-diff.html__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1k >> m2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAI6sfegbs%24&data=0 >> 5%7C02%7Cgunter.van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508dd577 >> deafd%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638762920526923381% >> 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl >> AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=944e >> x3jVLrqhVW9e4ePA7kh0gh16A7GzbZaPIIVnzFM%3D&reserved=0 (shows changes >> where text is moved or deleted) >> >> For the AUTH48 status of this document, please see: >> https://urld/ >> efense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc973 >> 9__%3B!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tb >> y1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIsc3ikMo%24&data=05%7C02%7Cgunter >> .van_de_velde%40nokia.com%7C5a40245c4a6e4b7dcaf508dd577deafd%7C5d47175 >> 19675428d917b70f44f9630b0%7C0%7C0%7C638762920526934157%7CUnknown%7CTWF >> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=15vbCtQmp2ZDHh9wz5M >> WtvMA%2Bkp%2BeFYvVcp7KMzBccU%3D&reserved=0 >> >> Thank you, >> >> RFC Editor/rv >> >> >> >>> On Feb 26, 2025, at 8:43 AM, Hooman Bidgoli (Nokia) >>> <hooman.bidg...@nokia.com> wrote: >>> >>> Hi Rebecca >>> >>> Just to close the loop can you please update as per below and then I >>> think the thread is closed >>> >>> Thanks >>> Hooman >>> >>> >>> -----Original Message----- >>> From: Hooman Bidgoli (Nokia) >>> Sent: Monday, February 24, 2025 10:49 AM >>> To: Stig Venaas (svenaas) ; Jeffrey (Zhaohui) Zhang ; Rebecca >>> VanRheenen ; Gunter van de Velde (Nokia) ; Mankamana Mishra >>> (mankamis) ; s...@cisco.com; zzh...@juniper.com; >>> michael.mcbr...@futurewei.com >>> Cc: pim-...@ietf.org; RFC Editor ; pim-cha...@ietf.org; >>> ext-zhang.zh...@zte.com.cn ; auth48archive@rfc-editor.org >>> Subject: RE: [AD] AUTH48: RFC-to-be 9739 for your review >>> >>> I am good with this thanks Jeffery/Stig! >>> >>> -----Original Message----- >>> From: Stig Venaas (svenaas) >>> Sent: Monday, February 24, 2025 10:42 AM >>> To: Hooman Bidgoli (Nokia) ; Jeffrey (Zhaohui) Zhang ; Rebecca >>> VanRheenen ; Gunter van de Velde (Nokia) ; Mankamana Mishra >>> (mankamis) ; s...@cisco.com; zzh...@juniper.com; >>> michael.mcbr...@futurewei.com >>> Cc: pim-...@ietf.org; RFC Editor ; pim-cha...@ietf.org; >>> ext-zhang.zh...@zte.com.cn ; auth48archive@rfc-editor.org >>> Subject: RE: [AD] AUTH48: RFC-to-be 9739 for your review >>> >>> >>> CAUTION: This is an external email. Please be very careful when clicking >>> links or opening attachments. See the URL nok.it/ext for additional >>> information. >>> >>> >>> >>> Hi all >>> >>> Thanks Jeffrey for good comments. >>> >>> We want to be able to use join attributes with PLI in some cases, in >>> particular for BIER we have specified a BIER specific join-attribute that >>> we really want to use! >>> >>> However, we cannot rely on pim hellos to know whether neighbor supports >>> join attributes or which attributes it supports, hence it must be by >>> configuration. I think the pim over BIER draft can specify that all pim >>> over BIER implementations need to support the one join attribute in that >>> draft though, so that does not have to be configured. This is covered by >>> the last bullet in 3.2.1. >>> >>> I think we need to replace "process" with "use"/"send", replacing OLD: >>> >>> Since a PLI does not process PIM Hello messages, it also does not >>> support the Join Attribute option in PIM Hello as specified in >>> [RFC5384]. As such, PIM Light is unaware of its neighbor's >>> capability to process Join Attributes and SHOULD NOT process a Join >>> message containing a Join Attribute. >>> >>> With NEW: >>> >>> Since PLI does not use PIM Hello messages, it also does not support >>> the Join Attribute option in PIM Hello as specified in [RFC5384]. >>> As such, PIM Light is unaware of its neighbor's capability to >>> process Join Attributes and SHOULD NOT send a Join message >>> containing a Join Attribute. >>> >>> I'm fine replacing OLD: >>> >>> The Join Attribute must be configured with an appropriate Join Attribute >>> type that the PLI is capable of processing as per the "PIM Join Attribute >>> Types" registry [IANA-PIM-Attr-Types]. >>> >>> With NEW: >>> The neighbors on the PLI are known via configuration to be capable of >>> processing the attribute. >>> >>> We still have the second bullet that allows it for specific PLI use-cases >>> if defined in draft/RFC. >>> >>> Thanks, >>> Stig >>> >>>> -----Original Message----- >>>> From: Hooman Bidgoli (Nokia) >>>> Sent: Monday, February 24, 2025 6:57 AM >>>> To: Jeffrey (Zhaohui) Zhang ; Rebecca VanRheenen ; Gunter van de >>>> Velde >>>> (Nokia) ; Mankamana Mishra (mankamis) ; Stig Venaas (svenaas) ; >>>> s...@cisco.com; zzh...@juniper.com; michael.mcbr...@futurewei.com >>>> Cc: pim-...@ietf.org; RFC Editor ; pim-cha...@ietf.org; EXT- >>>> zhang.zh...@zte.com.cn ; auth48archive@rfc-editor.org >>>> Subject: RE: [AD] AUTH48: RFC-to-be 9739 for your review >>>> Importance: High >>>> >>>> I let Stig comment >>>> >>>> but the just of it is, since PLI does not support PIM Hello then >>>> natively it can't process join attribute unless it is configured >>>> explicitly or the application forces a specific join attribute type for >>>> the PLI which both end understand. >>>> >>>> I don't care how we want to say this as long as the idea is >>>> communicated in some way. >>>> >>>> Thanks >>>> Hooman >>>> >>>> -----Original Message----- >>>> From: Jeffrey (Zhaohui) Zhang >>>> Sent: Monday, February 24, 2025 9:38 AM >>>> To: Hooman Bidgoli (Nokia) ; Rebecca VanRheenen ; Gunter van de >>>> Velde >>>> (Nokia) ; Mankamana Mishra (mankamis) ; Stig Venaas (svenaas) ; >>>> s...@cisco.com; zzh...@juniper.com; michael.mcbr...@futurewei.com >>>> Cc: pim-...@ietf.org; RFC Editor ; pim-cha...@ietf.org; EXT- >>>> zhang.zh...@zte.com.cn ; auth48archive@rfc-editor.org >>>> Subject: RE: [AD] AUTH48: RFC-to-be 9739 for your review >>>> >>>> >>>> CAUTION: This is an external email. Please be very careful when >>>> clicking links or opening attachments. See the URL nok.it/ext for >>>> additional information. >>>> >>>> >>>> >>>> Please see zzh3> below. >>>> >>>> >>>> Juniper Business Use Only >>>> -----Original Message----- >>>> From: Hooman Bidgoli (Nokia) >>>> Sent: Monday, February 24, 2025 9:07 AM >>>> To: Jeffrey (Zhaohui) Zhang ; Rebecca VanRheenen ; Gunter van de >>>> Velde >>>> (Nokia) ; Mankamana Mishra (mankamis) ; Stig Venaas (svenaas) ; >>>> s...@cisco.com; zzh...@juniper.com; michael.mcbr...@futurewei.com >>>> Cc: pim-...@ietf.org; RFC Editor ; pim-cha...@ietf.org; EXT- >>>> zhang.zh...@zte.com.cn ; auth48archive@rfc-editor.org >>>> Subject: RE: [AD] AUTH48: RFC-to-be 9739 for your review >>>> >>>> [External Email. Be cautious of content] >>>> >>>> >>>> HI Jeffrey >>>> >>>> 1. on the hello, PLI should not send it, but if it receives it then >>>> what? It should drop it correct? Doesn't that mean that PLI should not >>>> process a PIM hello? >>>> We need a text that describes the behavior when PLI gets a Hello. >>>> >>>> Zzh3> The context there is NOT ABOUT HELLO handling, but about the >>>> handling of join message with Join attributes. My suggestion is >>>> about the text for join messages with join attributes. >>>> Zzh3> If we want to *add* text about hello messages, that's a >>>> Zzh3> separate >>>> paragraph. >>>> >>>> 2. on join attribute we are both saying the same thing I think. PLI >>>> should not send a join attribute but if it receives it then what? >>>> Will the PLI accept the Join <S,G> and not process the join >>>> attribute or do we drop the entire join message? >>>> >>>> Zzh3> With the principle of "be conservative when sending and >>>> Zzh3> liberal when >>>> receiving", I think we can process the join attribute and the message. >>>> >>>> a. in addition if a specific join attribute is configure against >>>> PLI or the >>>> application using PLI is known to support a specific join attribute >>>> type then the PLI should process the attribute. Do we agree? >>>> >>>> Zzh3> Agree - just that I believe my suggested text is better >>>> Zzh3> (either the original >>>> version "via means outside the scope of this document" or the new >>>> version ("via configuration"). >>>> Zzh3> If we agree that we can always process the received join >>>> Zzh3> attributes, then >>>> my original suggestions should be taken (except that "via means >>>> outside the scope of this document" can be replaced by "via >>>> configuration"). >>>> Zzh3> Jeffrey >>>> >>>> Thanks >>>> Hooman >>>> >>>> >>>> Juniper Business Use Only >>>> -----Original Message----- >>>> From: Jeffrey (Zhaohui) Zhang >>>> Sent: Monday, February 24, 2025 8:50 AM >>>> To: Hooman Bidgoli (Nokia) ; Rebecca VanRheenen ; Gunter van de >>>> Velde >>>> (Nokia) ; Mankamana Mishra (mankamis) ; Stig Venaas (svenaas) ; >>>> s...@cisco.com; zzh...@juniper.com; michael.mcbr...@futurewei.com >>>> Cc: pim-...@ietf.org; RFC Editor ; pim-cha...@ietf.org; EXT- >>>> zhang.zh...@zte.com.cn ; auth48archive@rfc-editor.org >>>> Subject: RE: [AD] AUTH48: RFC-to-be 9739 for your review >>>> >>>> >>>> CAUTION: This is an external email. Please be very careful when >>>> clicking links or opening attachments. See the URL nok.it/ext for >>>> additional information. >>>> >>>> >>>> >>>> Hi Hooman, Stig, >>>> >>>> Please see zzh2> below. >>>> >>>> >>>> Juniper Business Use Only >>>> -----Original Message----- >>>> From: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com> >>>> Sent: Monday, February 24, 2025 4:35 AM >>>> To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Rebecca VanRheenen >>>> <rvanrhee...@staff.rfc-editor.org>; Gunter van de Velde (Nokia) >>>> <gunter.van_de_ve...@nokia.com>; Mankamana Mishra (mankamis) >>>> <manka...@cisco.com>; Stig Venaas (svenaas) <sven...@cisco.com>; >>>> s...@cisco.com; zzh...@juniper.com; michael.mcbr...@futurewei.com >>>> Cc: pim-...@ietf.org; RFC Editor <rfc-edi...@rfc-editor.org>; pim- >>>> cha...@ietf.org; ext-zhang.zh...@zte.com.cn >>>> <zhang.zh...@zte.com.cn>; auth48archive@rfc-editor.org >>>> Subject: RE: [AD] AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> >>>> for your review >>>> >>>> [External Email. Be cautious of content] >>>> >>>> >>>> Hi Jeffrey et al >>>> >>>> Jeffrey thanks for input, I have some minor comments Jeffrey, could >>>> you please read inline @Stig Venaas (svenaas) what do you think >>>> about the comments please. >>>> >>>> Thanks >>>> Hooman >>>> >>>> >>>> >>>> Juniper Business Use Only >>>> -----Original Message----- >>>> From: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net> >>>> Sent: Thursday, February 20, 2025 10:44 PM >>>> To: Rebecca VanRheenen <rvanrhee...@staff.rfc-editor.org>; Gunter >>>> van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; Mankamana >>>> Mishra >>>> (mankamis) <manka...@cisco.com>; Hooman Bidgoli (Nokia) >>>> <hooman.bidg...@nokia.com>; Stig Venaas (svenaas) >>>> <sven...@cisco.com>; s...@cisco.com; zzh...@juniper.com; >>>> michael.mcbr...@futurewei.com >>>> Cc: pim-...@ietf.org; RFC Editor <rfc-edi...@rfc-editor.org>; pim- >>>> cha...@ietf.org; ext-zhang.zh...@zte.com.cn >>>> <zhang.zh...@zte.com.cn>; auth48archive@rfc-editor.org >>>> Subject: RE: [AD] AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> >>>> for your review >>>> >>>> >>>> CAUTION: This is an external email. Please be very careful when >>>> clicking links or opening attachments. See the URL nok.it/ext for >>>> additional information. >>>> >>>> >>>> >>>> I somehow cannot find any traces of this email thread in my Outlook >>>> hence the late response. Thanks to Gunter for forwarding me this email. >>>> >>>> A few nits: >>>> >>>> In certain scenarios, it is desirable to establish multicast states >>>> between two adjacent Layer 3 routers without forming a PIM >>>> neighborship. >>>> >>>> We should remove the "adjacent layer 3" wording from the above. The >>>> very use case that led to this document involves routers >>>> *indirectly* connected by a BIER domain (which are composed of layer >>>> 3 routers) - we want to signal PIM states among non-adjacent routers over >>>> this PLI. >>>> >>>> HB> Ok, so lets go with >>>> In certain scenarios, it is desirable to establish multicast states >>>> between two routers without forming a PIM neighborship. >>>> >>>> For the following: >>>> >>>> Since a PLI does not process PIM Hello messages, it also does not >>>> support the Join Attribute option in PIM Hello as specified in >>>> [RFC5384]. As such, PIM Light is unaware of its neighbor's >>>> capability to process Join Attributes and SHOULD NOT process a Join >>>> message containing a Join Attribute. >>>> >>>> "process" is more on the receiving side. I think we're only talking >>>> about "sending" here, so should change the second "process" to "send". >>>> >>>> HB> I think this is send and process Jeffrey, lets say if PLI gets a >>>> HB> hello message it should not process it and perhaps raise a log >>>> HB> correct? I agree with sending. I just want to make sure the >>>> HB> reader understands that PLI doesn't process Hellos. How about >>>> "Since a PLI does not 'support' PIM Hello messages, it also does >>>> not support the Join Attribute option in PIM Hello as specified in >>>> [RFC5384]. As such, PIM Light is unaware of its neighbor's >>>> capability to process Join Attributes and SHOULD NOT process a Join >>>> message containing a Join Attribute." >>>> >>>> zzh2> It's not about "process a hello message" that is received. The >>>> zzh2> context is >>>> that is you don't know the capability of the receivers (due to lack >>>> of >>>> hello) so you should not *send join* messages with Join Attributes. >>>> Zzh2> If the intention is that one should even not process a >>>> Zzh2> received join >>>> message with the join attribute, then the text should be: >>>> >>>> Since a PLI does not use PIM Hello messages, which contains the >>>> Join Attribute option in PIM Hello as specified in [RFC5384], PIM >>>> Light is unaware of its neighbor's capability to process Join >>>> Attributes and SHOULD NOT *send and >>>> process* a Join >>>> message containing a Join Attribute. >>>> >>>> zzh2> I think that is clearer (the key change is *send and process* >>>> zzh2> which would >>>> match the following). But if it is ok to process received the join >>>> messages with join attributes, then my two original suggestions are better. >>>> >>>> There are two cases in which a PLI can send and process a Join >>>> Attribute: >>>> >>>> Remove "and process"? >>>> >>>> HB> how about >>>> "For a PLI to support Join Attributes there can be two cases:" >>>> >>>> HB> @Stig Venaas (svenaas) what do you think? >>>> >>>> * The Join Attribute must be configured with an appropriate Join >>>> Attribute type that the PLI is capable of processing as per the >>>> "PIM Join Attribute Types" registry [IANA-PIM-Attr-Types]. >>>> >>>> The above bullet does not read well. Perhaps change it to the following? >>>> >>>> * The neighbors on the PLI are known, by means outside of the scope >>>> of this document, to be capable of processing the attribute. >>>> >>>> HB> I don't think we need change this as this is needed to stress >>>> HB> that join Attribute option is supported when it is configured >>>> explicitly. >>>> HB> We can change it to the following for better read >>>> "The Join Attribute type as per "PIM Join Attribute Types" registry >>>> [IANA-PIM- Attr-Types] must be explicitly configured against the PLI >>>> to enable the support of Join Attribute for PIM Light." >>>> >>>> Zzh2> Neither the original text and your new text above does not >>>> Zzh2> read well. I >>>> know what you mean - the routers need to know that the join >>>> attribute is supported and that can be achieved via configuration. >>>> My suggested text simply says as long as it is known to be supported it is >>>> fine. >>>> If we want to limit it to configuration, the following is better: >>>> >>>> * The neighbors on the PLI are known via configuration to be >>>> capable of processing the attribute. >>>> >>>> Zzh2> Thanks. >>>> Zzh2> Jeffrey >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
