[auth48] Re: [AD] AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for your review

["Gunter van de Velde (Nokia)" <[e-mail]>]

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 <[e-mail]>
Sent: Thursday, February 27, 2025 11:27 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Hooman Bidgoli (Nokia) <[e-mail]>; Stig Venaas (svenaas) <[e-mail]>; Gunter van de Velde (Nokia) <[e-mail]>; Mankamana Mishra (mankamis) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; RFC Editor <[e-mail]>; [e-mail]; [e-mail] <[e-mail]>; [e-mail]
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 <[e-mail]> wrote:
>
> Hi Rebecca,
>
> I approve the changes.
>
> Thanks!
> Jeffrey
>
>
> Juniper Business Use Only
> -----Original Message-----
> From: Rebecca VanRheenen <[e-mail]>
> Sent: Thursday, February 27, 2025 5:17 PM
> To: Hooman Bidgoli (Nokia) <[e-mail]>; Stig Venaas
> (svenaas) <[e-mail]>; Jeffrey (Zhaohui) Zhang
> <[e-mail]>; Gunter van de Velde (Nokia)
> <[e-mail]>; Mankamana Mishra (mankamis)
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]; RFC Editor <[e-mail]>;
> [e-mail]; [e-mail]
> <[e-mail]>; [e-mail]
> 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) <[e-mail]> 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) ; [e-mail]; [e-mail];
>> [e-mail]
>> Cc: [e-mail]; RFC Editor ; [e-mail];
>> [e-mail] ; [e-mail]
>> 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) ; [e-mail]; [e-mail];
>> [e-mail]
>> Cc: [e-mail]; RFC Editor ; [e-mail];
>> [e-mail] ; [e-mail]
>> 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) ;
>>> [e-mail]; [e-mail]; [e-mail]
>>> Cc: [e-mail]; RFC Editor ; [e-mail]; EXT-
>>> [e-mail] ; [e-mail]
>>> 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) ;
>>> [e-mail]; [e-mail]; [e-mail]
>>> Cc: [e-mail]; RFC Editor ; [e-mail]; EXT-
>>> [e-mail] ; [e-mail]
>>> 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) ;
>>> [e-mail]; [e-mail]; [e-mail]
>>> Cc: [e-mail]; RFC Editor ; [e-mail]; EXT-
>>> [e-mail] ; [e-mail]
>>> 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) ;
>>> [e-mail]; [e-mail]; [e-mail]
>>> Cc: [e-mail]; RFC Editor ; [e-mail]; EXT-
>>> [e-mail] ; [e-mail]
>>> 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) <[e-mail]>
>>> Sent: Monday, February 24, 2025 4:35 AM
>>> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Rebecca VanRheenen
>>> <[e-mail]>; Gunter van de Velde (Nokia)
>>> <[e-mail]>; Mankamana Mishra (mankamis)
>>> <[e-mail]>; Stig Venaas (svenaas) <[e-mail]>;
>>> [e-mail]; [e-mail]; [e-mail]
>>> Cc: [e-mail]; RFC Editor <[e-mail]>; pim-
>>> [e-mail]; [e-mail]
>>> <[e-mail]>; [e-mail]
>>> 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 <[e-mail]>
>>> Sent: Thursday, February 20, 2025 10:44 PM
>>> To: Rebecca VanRheenen <[e-mail]>; Gunter
>>> van de Velde (Nokia) <[e-mail]>; Mankamana
>>> Mishra
>>> (mankamis) <[e-mail]>; Hooman Bidgoli (Nokia)
>>> <[e-mail]>; Stig Venaas (svenaas)
>>> <[e-mail]>; [e-mail]; [e-mail];
>>> [e-mail]
>>> Cc: [e-mail]; RFC Editor <[e-mail]>; pim-
>>> [e-mail]; [e-mail]
>>> <[e-mail]>; [e-mail]
>>> 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
>