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://www.rfc-editor.org/authors/rfc9739-auth48diff.html. - 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://www.rfc-editor.org/authors/rfc9739.xml Updated output files: https://www.rfc-editor.org/authors/rfc9739.txt https://www.rfc-editor.org/authors/rfc9739.pdf https://www.rfc-editor.org/authors/rfc9739.html Diff file showing changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9739-auth48diff.html https://www.rfc-editor.org/authors/rfc9739-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9739-diff.html https://www.rfc-editor.org/authors/rfc9739-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9739-alt-diff.html (shows changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9739 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 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 reader >> HB> 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 that >> HB> 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
