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 hello
message it should not process it and perhaps raise a log correct? I agree with
sending. I just want to make sure the 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 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 join
Attribute option is supported when it is configured explicitly. 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
