Hi Stig I am ok with your suggestions.
With regards to the security note, I think you are right as the old PIM SSM RFC spells out that SSM does not introduce new security considerations for IP multicast. Thanks Hooman -----Original Message----- From: Stig Venaas (svenaas) <sven...@cisco.com> Sent: Tuesday, February 11, 2025 7:16 PM To: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com>; rfc-edi...@rfc-editor.org; s...@cisco.com; Mankamana Mishra (mankamis) <manka...@cisco.com>; zzh...@juniper.com; michael.mcbr...@futurewei.com Cc: pim-...@ietf.org; pim-cha...@ietf.org; zhang.zh...@zte.com.cn; Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; auth48archive@rfc-editor.org Subject: RE: 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 RFC Editor and Hooman Please see my comments inline. > -----Original Message----- > From: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com> > Sent: Tuesday, February 11, 2025 3:10 PM > To: rfc-edi...@rfc-editor.org; s...@cisco.com; Mankamana Mishra > (mankamis) <manka...@cisco.com>; zzh...@juniper.com; > michael.mcbr...@futurewei.com > Cc: pim-...@ietf.org; pim-cha...@ietf.org; zhang.zh...@zte.com.cn; > Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; > auth48archive@rfc- editor.org > Subject: RE: AUTH48: RFC-to-be 9739 <draft-ietf-pim-light-11> for your > review > Importance: High > > Hi All > > My comments Inline, thanks for detail suggestions! > Co-authors any comments on my suggestions pls? > > Do I need to submit a version 12 of draft with the changes? > > Thanks > Hooman > > > -----Original Message----- > From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > Sent: Monday, February 10, 2025 11:45 PM > To: Hooman Bidgoli (Nokia) <hooman.bidg...@nokia.com>; s...@cisco.com; > manka...@cisco.com; zzh...@juniper.com; michael.mcbr...@futurewei.com > Cc: rfc-edi...@rfc-editor.org; pim-...@ietf.org; pim-cha...@ietf.org; > zhang.zh...@zte.com.cn; Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com>; auth48archive@rfc-editor.org > Subject: Re: 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. > > > > Authors, > > While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the XML file. > > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear > in the > title) for use on https://www.rfc-editor.org/search. --> > > > 2) <!-- [rfced] Abstract > > a) We updated the text starting with "which does not..." as follows to > improve readability; please review and let us know any concerns. > > Original: > This document specifies Protocol Independent Multicast Light (PIM > Light) and PIM Light Interface (PLI) which does not need PIM Hello > message to accept PIM Join/Prune messages. PLI can signal multicast > states over networks that can not support full PIM neighbor > discovery, as an example BIER networks that are connecting two or > more PIM domains. > > Perhaps: > This document specifies Protocol Independent Multicast Light (PIM Light) > and the PIM Light Interface (PLI). A PLI does not need a PIM Hello > message to accept PIM Join/Prune messages, and it can signal multicast > states over networks that cannot support full PIM neighbor > discovery, such as Bit Index Explicit Replication (BIER) networks > that connect two or > more PIM domains. > > HB> ok with this. > > > b) Should "protocol and procedures" be updated to just "procedures" as > in the Introduction? > > Original: > This document outlines the PIM > Light protocol and procedures to ensure loop-free multicast traffic > between two or more PIM Light routers. > > Perhaps: > This document outlines PIM > Light procedures to ensure loop-free multicast traffic > between two or more PIM Light routers. > HB> my vote is to keep it as protocol and procedures. The doc talks > HB> about > both. > --> > > > 3) <!-- [rfced] This is a sentence fragment. How may we update to make > a complete sentence? Also, please confirm that "network" is intended > here; elsewhere in the document, we see "BIER domain" rather than > "BIER network". > > Original: > For example, in a Bit Index Explicit > Replication (BIER) [RFC8279] networks connecting multiple PIM > domains, where PIM Join/Prune messages are tunneled via BIER as > specified in [draft-ietf-bier-pim-signaling]. > > Perhaps: > An example is a Bit Index Explicit > Replication (BIER) [RFC8279] network connecting multiple PIM > domains, where PIM Join/Prune messages are tunneled via BIER as > specified in [BIER-PIM]. > > HB> This text looks good. > > Or: > For example, in a Bit Index Explicit > Replication (BIER) [RFC8279] network connecting multiple PIM > domains, PIM Join/Prune messages are tunneled via BIER as > specified in [draft-ietf-bier-pim-signaling]. > --> > > > 4) <!-- [rfced] Please clarify the text starting with "to ensure...". > Also, is "reviver" correct? Or is "receiver" or something else intended? > > Original: > As an example > the implementation should ensure that DR election is done on upstream > Redundant PIM routers that are at the edge of the PIM Light Domain to > ensure a single Designated Router to forward the PIM Join message > from reviver to the Source. > > Perhaps: > As an example, > the implementation should ensure that DR election is done on upstream > redundant PIM routers that are at the edge of the PIM Light domain to > ensure that a single DR forwards the PIM Join message > from the receiver to the source. > HB> looks good. > --> > > > 5) <!-- [rfced] FYI - We reordered the list in Section 3.1 by type > number as only one was out of order. > --> > > > 6) <!-- [rfced] Is the text starting with "from the..." needed here? > Other entries in the list do not have such notes, and in the IANA > registry (linked to in the text introducing this list), RFC 7761 is > listed as a reference for type 3. See > https://www.iana.org/assignments/pim-parameters/. > > Original: > 1. type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed > in [RFC7761]. > > Current: > * type 3 (Join/Prune) (Note that this type is from the ALL-PIM- > ROUTERS message types listed in [RFC7761].) > > Perhaps: > * type 3 (Join/Prune) > > HB> I agree I am not sure why we are saying "from the ALL-PIM-ROUTERS" > HB> as > that is a multicast address. > HB> I am ok with type 3 (Join/Prune). Unless there is a counter thought. > --> > > > 7) <!-- [rfced] FYI - We updated "13" to "13.0" to match the registry > at https://www.iana.org/assignments/pim-parameters/. > > Original: > type 13 (PIM Packed Null-Register) > > Updated: > type 13.0 (PIM Packed Null-Register) > HB> ok > --> This really must be 13.0 but it still says 13 in the new version and diffs provided. > > 8) <!-- [rfced] Is "unicast destination IP" correct here, or should it > be "unicast destination IP addresses" (with "addresses")? > > Original: > 7. Any future PIM message types that use unicast destination IP. > > Perhaps: > * Any future PIM message types that use unicast destination IP addresses. > HB> ok with this suggestion. > --> A given message will have only a single destination, so it seems a bit odd to me to use plural here. Maybe it can says "Any future PIM message types where the destination is a unicast IP address"? > 9) <!-- [rfced] Will readers know what both instances of "it" refer to > in the text "it SHOULD NOT process a join message containing it"? > > Original: > As such, PIM Light is unaware of its neighbor's > capability to process join attributes and it SHOULD NOT process a > join message containing it. > > Perhaps: > 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. > HB> ok with suggestion > --> > > > 10) <!-- [rfced] We note that the sentence below in Section 3.2.2 uses > "PIM networks" but the figure uses "PIM domain". Are any updates needed? > > Original: > For instance, in a BIER domain connecting two PIM networks, a PLI can > be used between BIER edge routers solely for multicast state > communication and transmit only PIM Join/Prune messages. > > Perhaps: > For instance, in a BIER domain connecting two PIM domains, a PLI can > be used between BIER edge routers solely for multicast state > communication and transmit only PIM Join/Prune messages. > HB> ok with suggestions > --> > > > 11) <!-- [rfced] Please clarify "An example DR election could be DR election". > > Original: > An example DR election could be DR election between router D and F in > above figure. > > Perhaps: > For example, DR election could be between router D and F in > above figure. > HB> ok with suggestion > --> > > > 12) <!-- [rfced] In Sections 3.2.2 and 3.4, we recommend including > text to introduce figure. > > In Section 3.2.2, perhaps the second paragraph can be moved before the > figure and first sentence of that paragraph updated in one of the > following ways. > > Original: > For instance, in a BIER domain connecting two PIM networks, a PLI can > be used between BIER edge routers solely for multicast state > communication and transmit only PIM Join/Prune messages. > > Perhaps (add "as in the figure below"): > For instance, in a BIER domain connecting two PIM networks as > in the figure below, a PLI can > be used between BIER edge routers solely for multicast state > communication and transmit only PIM Join/Prune messages. > > Or (use two sentences): > For instance, the figure below depicts a BIER domain connecting > two PIM networks. A PLI can > be used between BIER edge routers solely for multicast state > communication and transmit only PIM Join/Prune messages. > HB> I can see how it is better to have both paragraphs after each > HB> other > followed by the figure. > HB> I suggest: > HB> For instance, in a BIER domain connecting two PIM domains as > in the figure below, a PLI can > be used between BIER edge routers solely for multicast state > communication and transmit only PIM Join/Prune messages. > > In Section 3.4, perhaps the last paragraph can be moved before the > figure and updated as follows. > > Original: > In another example, where the PLI is configured automatically between > the BIER Edge Routers (BER), when the downstream BIER Edge Router > (DBER) is no longer reachable on the upstream BIER Edge Router > (UBER), the UBER which is also a PIM Light Router can prune the <S,G> > advertised toward the source on the PIM domain to stop the > transmission of the multicast stream. > > Perhaps: > In another example, the PLI is configured automatically between > the BIER Edge Routers (BERs) as in the figure below. When the > downstream BIER Edge Router > (DBER) is no longer reachable on the upstream BIER Edge Router > (UBER), the UBER (which is also a PIM Light router) can prune the <S,G> > advertised toward the source on the PIM domain to stop the > transmission of the multicast stream. > > HB> following the previous example ok with this suggestion. > --> > > > 13) <!-- [rfced] May we move the text "to prevent multicast stream > duplication" as follows to improve readability? > > Original: > If there > are redundant PIM routers at the edge of the BIER domain, to prevent > multicast stream duplication, they MUST establish PIM adjacency as > per [RFC7761] to ensure DR election at the edge of BIER domain. > > Perhaps: > If there > are redundant PIM routers at the edge of the BIER domain, they MUST > establish PIM adjacency as per [RFC7761] to prevent multicast stream > duplication and to ensure DR election at the edge of the BIER domain. > > HB> ok with suggestion. > --> > > > 14) <!-- [rfced] We updated this sentence as follows; please review > and let us know any concerns. > > Original: > If a router > supports PIM Light, only when PLI is enabled on an interface, > arriving Join/Prune messages MUST be processed, otherwise they MUST > be dropped. > > Updated: > If a router supports PIM Light, arriving Join/Prune messages MUST be > processed only when a PLI is enabled on an interface; otherwise, they MUST > be dropped. > > HB> Ok > --> > > > 15) <!-- [rfced] This sentence does not parse. We updated as follows. > Let us know any concerns. > > Original: > While on some logical interfaces PLI maybe enabled > automatically or via an underlying mechanism, as an example the > logical interface connecting two or more BIER edge routers in a BIER > subdomain [draft-ietf-bier-pim-signaling]. > > Updated: > PLI may be enabled automatically or via an underlying mechanism on some > logical interfaces (for example, the logical interface connecting two or > more BIER edge routers in a BIER subdomain [BIER-PIM]). > > HB> I suggest the following > > In some cases, PKI maybe enabled automatically via an underlying > mechanisms on some logical interface. For example, in a BIER domain a > logical interface can connect two or more BIER edge routers as per > [draft-ietf-bier- pim-signaling]. > --> I think this should be: In some cases, PLI maybe enabled automatically via an underlying mechanism on a logical interface. For example, in a BIER domain, a logical interface can connect two or more BIER edge routers as per [draft-ietf-bier- pim-signaling]. > 16) <!-- [rfced] We confirmed that port 8471 is correct in this > sentence per the registry at > https://www.iana.org/assignments/service-names-port-numbers. > In the registry, we see that port 8471 is also for PORT with SCTP as > the transport protocol. This sentence just mentions TCP, though SCTP > is mentioned in the next sentence. Are any updates needed? > > Original: > For TCP, PIM over reliable transport (PORT) uses port 8471 > which is assigned by IANA. > --> > > > 17) <!-- [rfced] The first sentence below uses "MUST", but the second > uses "must" > (although it says "the same is true"). Please review and let us know > if any updates are needed. > > Original: > [RFC6559] mentions that when a > router is configured to use PIM over TCP on a given interface, it > MUST include the PIM-over-TCP-Capable Hello Option in its Hello > messages for that interface. The same is true for SCTP and the > router must include PIM-over-SCTP-Capable Hello Option in its Hello > message on that interface. > > Perhaps: > [RFC6559] mentions that when a > router is configured to use PIM over TCP on a given interface, it > MUST include the PIM-over-TCP-Capable Hello Option in its Hello > messages for that interface. The same is true for SCTP; the > router MUST include the PIM-over-SCTP-Capable Hello Option in its Hello > message on that interface. > > HB> here is a new suggestion for 16 and 17 > [RFC6559] defines a reliable transport mechanism called PIM over > reliable transport (PORT) for PIM transmission > of Join/Prune messages, using either TCP or SCTP as transport > protocol. Both TCP and SCTP use destination port number of 8471. > SCTP is explained in [RFC9260], and it is > used as a second option for PORT. [RFC6559] mentions that when a > router is configured to use PIM over TCP on a given interface, it > MUST include the PIM-over-TCP-Capable Hello Option in its Hello > messages for that interface. The same is true for SCTP and the > router MUST include PIM-over-SCTP-Capable Hello Option in its Hello > message on that interface. > --> > > > 18) <!-- [rfced] Will readers understand "Connection ID IP address > comparison"? > What is being compared? > > Original: > When the router is using SCTP, the Connection ID IP address > comparison need not be done since the SCTP can handle call > collision. > > HB> here is suggestion for better read > > These Hello options contain a Connection ID which is an IPv4 or IPv6 > address used to establish the SCTP or TCP connection. For PORT using > TCP, the connection ID is used for determining which peer is doing an > active transport open to the neighbor and which peer is doing passive > transport open, as per section 4 of [RFC6559. When the router is using > SCTP, > the Connection ID is not used to determine the active and passive > peer since the SCTP protocol can handle call > collision. > --> > > > 19) <!-- [rfced] This sentence in Section 3.5 explains that a > Connection ID is an > IPv4 or IPv6 address used to establish the SCTP or TCP connection: > > Original > These Hello options contain a Connection ID which is an IPv4 or IPv6 > address used to establish the SCTP or TCP connection. > > The sentence below appears in the next paragraph. Should the text > starting with "Connection ID IPv4 or IPv6 addresses..." be updated for > consistency with the previous text? > > Original: > PIM Light lacks Hello messages, the PLI can be configured with the > Connection ID IPv4 or IPv6 addresses used to establish the SCTP or > TCP connection. > > Perhaps: > Because PIM Light lacks Hello messages, the PLI can be configured with the > Connection ID (i.e., the IPv4 or IPv6 address used to establish the SCTP or > TCP connection). > HB> ok with this option. > > Or: > Because PIM Light lacks Hello messages, the PLI can be configured with the > Connection ID. > --> > > > 20) <!-- [rfced] Should "Source-Specific and Sparse Mode Join/Prune > messages" here be updated to "PIM-SSM and PIM-SM Join/Prune messages"? > > Original: > Furthermore, because PIM Light can be used for signaling Source- > Specific and Sparse Mode Join/Prune messages, the security > considerations outlined in [RFC7761] and [RFC4607] SHOULD be > considered where appropriate. > > Perhaps: > Furthermore, because PIM Light can be used for signaling PIM-SSM > and PIM-SM Join/Prune messages, the security > considerations outlined in [RFC7761] and [RFC4607] SHOULD be > considered where appropriate. > HB> ok with this I think we should remove "PIM-SSM and" here. PIM-SM Join/Prune messages are also used both for SSM and not SSM and the security implications are the same. Hence, I think it should just say: Furthermore, because PIM Light can be used for signaling PIM-SM Join/Prune messages, the security considerations outlined in [RFC7761] and [RFC4607] SHOULD be considered where appropriate. Hooman/authors, do you see any specific implications to SSM? I don't see any, but if you do, I suggest adding that in a separate sentence. That is my last comment. I'm fine with all the suggested changes and Hooman's comments otherwise. Thanks, Stig > --> > > > 21) <!-- [rfced] Terminology > > a) These terms are used inconsistently throughout the text. Should > these be uniform? If so, please let us know which form is preferred. > > DR Election vs. DR election > <S,G> vs. (S,G) > > HB> thanks! They should be (S,G) every where. > > b) We also note inconsistencies in the terms listed below. We chose > the form on the right. Please let us know any objections. > > PIM Light Router vs. PIM Light router > PIM Light Domain vs. PIM Light domain > connection ID vs Connection ID > Source vs. source > join message vs. Join message > join/prune message vs. Join/Prune message > > HB> agreed thanks! > > c) Should "join attribute" be capitalized per usage in RFC 5384? > > HB> yes it should. > > d) Article usage (e.g., "a" and "the") with "PIM Light Interface" and "PLI" > was mixed. We added articles in some instances. Please review for correctness. > > --> > > > 22) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide > <https://www/ > .rfc-%2F&data=05%7C02%7Chooman.bidgoli%40nokia.com%7C8ef05603108d4cb02 > 19308dd4afa6ed2%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638749162 > 122677027%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C& > sdata=Ro3%2Fvaz4wAG3kyB3i1%2FjaIzM%2FlVrx%2FjDo8m4IA1J%2FcY%3D&reserve > d=0 editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this > should still be reviewed as a best practice. > --> > > > Thank you. > > RFC Editor/rv > > > > On Feb 10, 2025, at 8:38 PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2025/02/10 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing your > approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- > 4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that > seem beyond editorial in nature, e.g., addition of new text, deletion > of text, and technical changes. Information about stream managers can > be found in the FAQ. Editorial changes do not require approval from a stream > manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email > stating that you approve this RFC for publication. Please use ‘REPLY > ALL’, as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9739.xml > https://www.rfc-editor.org/authors/rfc9739.html > https://www.rfc-editor.org/authors/rfc9739.pdf > https://www.rfc-editor.org/authors/rfc9739.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9739-diff.html > https://www.rfc-editor.org/authors/rfc9739-rfcdiff.html (side by > side) > > Alt-diff of the text (allows you to more easily view changes where > text has been deleted or moved): > https://www.rfc-editor.org/authors/rfc9739-alt-diff.html > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9739-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9739 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9739 (draft-ietf-pim-light-11) > > Title : Protocol Independent Multicast Light (PIM Light) > Author(s) : H. Bidgoli, S. Venaas, M. Mishra, Z. Zhang, M. McBride > WG Chair(s) : Stig Venaas, Mike McBride > > Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
