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
