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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739.xml__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAILhNP5RA$ > > Updated output files: > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739.txt__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIXk2-JOk$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739.pdf__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIGUB6A2Y$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739.html__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIHqP02K8$ > > Diff file showing changes made during AUTH48: > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739-auth48diff.html__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIp6WEj_U$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739-auth48rfcdiff.html__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIhNQens4$ > (side by side) > > Diff files showing all changes: > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739-diff.html__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIr4YLawg$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739-rfcdiff.html__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIdTjA5JU$ > (side by side) > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9739-alt-diff.html__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAI6sfegbs$ > (shows changes where text is moved or deleted) > > For the AUTH48 status of this document, please see: > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9739__;!!NEt6yMaO-gk!H8MCgC9q7K9gmvhSZgQtuEgbsx2aN0GRs1km2jdCV6zDoCZ2tby1ylXTZgZmk_stK-yfbbw22s2LPQPxBNneuzAIsc3ikMo$ > > 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 liberal >>> Zzh3> 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 (either >>> Zzh3> 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 received >>> Zzh2> 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 read >>> Zzh2> 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
