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
