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 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 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 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 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 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* 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 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
