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
