Subject: [pim] : Follow up on draft-ietf-pim-null-register-packing-06

From: "Ananya Gopal (ananygop)" <[email-masked]>
Date: Thu, 4 Mar 2021 19:36:48 +0000

Hi WG,
Thank you for the comments. We have taken care of all editorial comments.

Some additional questions that needed a discussion: 

[Lenny] Could there ever be a case where an RP might need to send Register-stops for only a subset of the s-g pairs that were in the packet null-register message? I couldn't think of a reason, but thought I'd ask.
[AG] Yes, this depends on the register policy at RP. Earlier RP policy was applied to each packet, but now it will be applied to each record.
And only if the RP accepts the register we will send register stop.

[Zheng] Is the capability per [S,G] or all sources -groups?
[AG] This capability applies to all S,Gs. It’s not per S,G.

For Abhishek's BSR extension proposal: 
[AG] Abhishek, with respect to the comments about the BSR extension, we think that it should be a separate draft, and we can work together on that.
For this draft, we recommend only anycast RPs. We can support heterogeneous mix of RPs with that extension draft. It could be a new SubType in the PIM Register Messages.

Additional comments:
Along with the recommendation of using only Anycast RPs, to reduce the risk of losing Register Messages, the DR can send one (S,G) as unpacked, also acting like a probe, and check for Register-Stop from the RP.
With every packed register, you can send one unpacked register. Only need to probe, when we have active sources. With the probe, we can figure out if the capability is set or not, as we’ll receive a Register-Stop.
Though, there are chances that the RP doesn’t support it after the probe, so after say, 5 seconds, we can switch to unpacked Null registers and then Data registers, if there is no support for the feature.

So in summary, Any Register from RP, with no capability set, immediately downgrade. After 5 seconds of receiving no registers from RP, switch to Null registers and then data registers.

We will be presenting the additional comments in the upcoming IETF 110.

Thanks, 
Ananya

On 12/19/20, 1:37 AM, "pim on behalf of Abhishek Chakraborty" <[email-masked] on behalf of cabhi=[email-masked]> wrote:

    My earlier comment regarding the extension of this null register packing capability bit advertisement in Candidate RP message to a BSR also can be considered as an attribute to decide the best router for a group-range.
    In a BSR network where multiple PIM candidate RPs advertise their candidateship to BSR, it can also set this capability bit.
    A capable candidate RP can be more preferred over a non capable RP if all other attributes of them are same.

    This capability bit can be an input to the hash function.

    Thanks and Regards,
    Abhishek

    Juniper Business Use Only

    -----Original Message-----
    From: pim <[email-masked]> On Behalf Of [email-masked]
    Sent: Friday, December 18, 2020 7:41 AM
    To: [email-masked]
    Subject: pim Digest, Vol 200, Issue 13

    [External Email. Be cautious of content]

    Send pim mailing list submissions to
            [email-masked]

    To subscribe or unsubscribe via the World Wide Web, visit
            https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHnagH4aFnMqlcCi88ELWy-pDugRfHNMtKWQ$
    or, via email, send a message with subject or body 'help' to
            [email-masked]

    You can reach the person managing the list at
            [email-masked]

    When replying, please edit your Subject line so it is more specific than "Re: Contents of pim digest..."

    Today's Topics:

       1. Re: additional extensions on
          draft-ietf-pim-null-register-packing-06 (Abhishek Chakraborty)
       2. Re: draft-ietf-pim-igmp-mld-extension WGLC (Stig Venaas)
       3. Re: draft-ietf-pim-igmp-mld-extension WGLC (Holland, Jake)

    ----------------------------------------------------------------------

    Message: 1
    Date: Thu, 17 Dec 2020 22:45:25 +0000
    From: Abhishek Chakraborty <[email-masked]>
    To: "[email-masked]" <[email-masked]>
    Subject: Re: [pim] additional extensions on
            draft-ietf-pim-null-register-packing-06
    Message-ID:
            <[email-masked]>

    Content-Type: text/plain; charset="us-ascii"

    1.
    Draft section conflicts with PIM RFC 4601 section 4.4:

    draft-ietf-pim-null-register-packing-06 tells:
    7.  PIM RP router version downgrade

       Consider a PIM RP router that supports PIM Register Packing and then
       downgrades to a software version which does not support PIM Register
       Packing.  The DR that sends the PIM Packed Register message will not
       get a PIM Register-Stop message back.  In such scenarios the DR MUST
       send an unpacked PIM Register and check the PIM Register-Stop to see
       if the capability bit (P-bit) for PIM Packed Register is set or not.
       If it is not set then the DR will continue sending unpacked PIM
       Register messages.

    PIM RFC 4601 section 4.4 tells:
    "Just before the Register-Stop Timer expires, the DR sends a Null-Register Message to the RP to allow the RP to refresh the Register-Stop information at the DR. If the Register-Stop Timer actually expires, the DR will resume encapsulating packets from the source to the RP."

    The suggestion for the extension to send the periodic PIM Null Registers to RP with special S,G or 0.0.0.0,0.0.0.0 and monitor the packing bit in RegisterSTop addresses this conflict.
    Since in this draft draft-ietf-pim-null-register-packing-06, we are going to have :
    "Type, SubType:

          The new packed Null-Register Type and SubType values TBD."

    It's better to always send a previous version of Null Register and check the P bit in RegisterStop from RP.

    2.
    Also we may need to mention in the draft that what happens when FHR doesn't receive any one of the S,G in the RegisterStop that it received from RP as a response to its packed Null Register.
    For example:
    Null Register has s1,g1, s2,g2, s3,g3 and RegisterStop has s1,g1, and s2,g2.
    Then it should start encapsulating for s3,g3.

    3.
    Also, there are use cases where FHRs can be on a LAN.
    Lets say FHR1 and FHR2 is on LAN, FHR1 is the DR and it becomes the forwarder. But FHR2 is the unicast best path towards source and thus RP sends SPT to FHR2.
    So, FHR1 will have Register States and FHR2 will have Forwarding states.
    Lets FHR1 and RP has the capability but FHR2 does not. When FHR1 goes down, FHR2 takes up DR role and sends Null Registers to RP one by one. On RP it should fall back to older version of RegisterStop.
    This is basically an FHR downgrade use case.

    Thanks and Regards,
    Abhishek

    Juniper Business Use Only

    -----Original Message-----
    From: pim <[email-masked]> On Behalf Of [email-masked]
    Sent: Thursday, December 17, 2020 4:11 PM
    To: [email-masked]
    Subject: pim Digest, Vol 200, Issue 11

    [External Email. Be cautious of content]

    Send pim mailing list submissions to
            [email-masked]

    To subscribe or unsubscribe via the World Wide Web, visit
            https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iEdjVwZ_k$
    or, via email, send a message with subject or body 'help' to
            [email-masked]

    You can reach the person managing the list at
            [email-masked]

    When replying, please edit your Subject line so it is more specific than "Re: Contents of pim digest..."

    Today's Topics:

       1. review of draft-ietf-pim-null-register-packing-06
          (Leonard Giuliano)
       2. A additional extensions on
          draft-ietf-pim-null-register-packing-06 (Abhishek Chakraborty)

    ----------------------------------------------------------------------

    Message: 1
    Date: Wed, 16 Dec 2020 12:54:52 -0800
    From: Leonard Giuliano <[email-masked]>
    To: <[email-masked]>
    Subject: [pim] review of draft-ietf-pim-null-register-packing-06
    Message-ID: <[email-masked]>
    Content-Type: text/plain; format=flowed; charset="US-ASCII"

    I reviewed the Null-Register packing draft and found it to be a well-written, concise and clear doc specifying a very simple optimization.
    Very much appreciate the brevity of this doc.  A few very minor (mostly
    editorial) nits, plus one question:

    -sect2, 1st para, last sentence: "when it learns RP is capable"
            -learns the RP

    -sect8, last sentence: "the number of records should be limited to the MTU of the outgoing interface."
            -might be more appropriate to say "limited by the MTU"

    -sect9, 2nd para, last sentence: "these messages are not required for PIM-SSM."
            -'required' implies they could be optionally used in SSM, so it might be better to say "these messages are not used in PIM-SSM."

    -sect9, 3rd para, 1st sentence: "case where a spoof Register can be sent"
            -"spoofed Register message"

    -sect9, 3rd para, 2nd sentence: "This can cause Null-Registers to not be received by the RP."
            -might be better to say "This can cause packed Null-Registers to be sent to an RP that doesnt support this packed format."

    -sect9, 3rd para, 3rd sentence: consider revising this sentence.  Maybe something like "For example, uRPF can be used to filter spoofed packets."

    -Sect6: this recommendation seems equally applicable to Anycast RP with MSDP for the same reasons as it is being recommended for Anycast RP with PIM.

    Substantive question: could there ever be a case where an RP might need to send Register-stops for only a subset of the s-g pairs that were in the packet null-register message?  I couldn't think of a reason, but thought I'd ask.

    -Lenny

    ------------------------------

    Message: 2
    Date: Thu, 17 Dec 2020 10:40:59 +0000
    From: Abhishek Chakraborty <[email-masked]>
    To: "[email-masked]" <[email-masked]>
    Subject: [pim] A additional extensions on
            draft-ietf-pim-null-register-packing-06
    Message-ID:
            <[email-masked]>

    Content-Type: text/plain; charset="us-ascii"

    Hi Experts,

    Going through the below draft, I felt we extend the same to address a heterogeneous networks (in terms of having mix of capable/non-capable RPs):

    https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-pim-null-register-packing-06__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iEZ0v0shs$

    What the draft says:

    "   To ensure compatibility with routers that do not support processing
       of the packed format, A router (DR) can decide to pack multiple Null-
       Register messages based on the capability received from the RP as
       part of Register-Stop.  Thus a DR will switch to the packed format
       only when it learns RP is capable of handling the packed Null-
       Register messages.
    "

    I would like to suggest 2 new extensions in the draft:

      1.  Once a router becomes an FHR (once data traffic hits), it uses the above mechanism to find out if the RP supports packing capability or not from RP's first RegisterStop. Later on, before sending packed NULL Registers:
         *   FHR to send a NULL Register packet to respective RPs for different group ranges, with either Group, Source 0.0.0.0, 0.0.0.0 or with a reserved Multicast group, and wait for a RegisterStop to ensure the RP still supports decoding of packed NULL Registers. So every 60 secs before sending packed Registers, we need to be sure the RP still supports this capability.
      2.  For BootStrap use cases,
         *   Candidate RP can advertise the capability bit to the BSR in the reserved bit of RFC 5059 section 4.2.
         *   The BSR can then map the best RP to its group range and can send the BSM to all the routers enabling the capability bit of each RP in the reserved bits in RFC 5059 section 4.1.
         *   When the rest of the Non RPs get the BSM, it can know in advance which RP supports capability and which doesn't.

    Advantages with the above extensions:

      1.  With above 1.a extension in the draft we can now support mix of capable/non-capable RPs in a network. This extension also addresses the dynamic upgrade/downgrade of a router in a network. Also this allows us to have a heterogeneous RP sets in Anycast RP cases (Anycast RP with MSDP and not PIM Anycast RP sets). For example:
         *   RP1 and RP2 are anycast RPs in network. RP1 is primary and RP2 is secondary in terms of best unicast reachability.
         *   RP1 supports packing capability and RP2 doesn't.
         *   FHR sends packed Null Registers to RP1 initially.
         *   Now RP1 goes down as some link in between flapped.
         *   FHR unaware of this churn. The tunnel is same for FHR.
         *   Now if FHR continues to send packed NULL registers to RP2 it breaks.
         *   So the 1.a extension (sending that extra reserved group register to RP2 before sending periodic NULL register) will make sure that RP2 is capable or not.
      2.  The BSR extension in above 2.a and 2.b let the non RPs in the network know the capabilities of the RPs.

    Please let me know your views on the above extensions.

    Thanks and Regards,
    Abhishek

    Juniper Business Use Only
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/pim/attachments/20201217/bbb35362/attachment.htm__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iE-nRgYP0$ >

    ------------------------------

    Subject: Digest Footer

    _______________________________________________
    pim mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iEdjVwZ_k$

    ------------------------------

    End of pim Digest, Vol 200, Issue 11
    ************************************

    ------------------------------

    Message: 2
    Date: Thu, 17 Dec 2020 15:25:57 -0800
    From: Stig Venaas <[email-masked]>
    To: "Jeffrey (Zhaohui) Zhang" <zzhang=[email-masked]>
    Cc: Michael McBride <[email-masked]>, "[email-masked]"
            <[email-masked]>
    Subject: Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC
    Message-ID:
            <[email-masked]>
    Content-Type: text/plain; charset="UTF-8"

    Hi Jeffrey

    I appreciate your comments, please see responses inline.

    On Tue, Dec 15, 2020 at 6:21 PM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> wrote:
    >
    > Support progressing this work.
    >
    >
    >
    > I have a couple of curiosity questions on the following:
    >
    >
    >
    >    Note that there may be additional data following this extension.  
    > The
    >
    >    Total Extension Length field would indicate where this extension
    >
    >    ends, and the additional data starts.
    >
    >
    >
    > How would you have additional data following this extension? The TLV mechanism seems to be universal/generic to handle all possible extensions, so why would you have another extension blob after this, and how would you indicate so? By another bit in the reserved field?
    >
    > Just wondering if this additional data needs to be mentioned at all.

    I agree that there should be no need for additional data for future extensions as TLVs can provide any potential extension. If the WG and co-authors agree, I'm happy to remove the additional additional data.
    We can then also simplify the length check and say that the extension length specified must be equal to the remaining payload (subtracting from packet payload length).

    >
    >   Also, there is a possibility
    >
    >    that an implementation uses the Additional Data part of IGMP/MLD
    >
    >    messages, but not according to this extension scheme.
    >
    >
    >
    > Do you mean a non-standard existing implementation? Now that you mention that, are we supposed to define the interop procedures? Are they supposed to interop with the implementations following this draft at all?

    The IGMP/MLD RFCs specify how additional data may be present and how it should be ignored. I've seen cases where implementations intentionally (or maybe by accident) have sent packets with additional data. I think it is safest to use a reserved bit to clearly indicate that this extension is in place, rather than trying to parse whatever additional data may be present.

    If we receive data from an existing implementation, the reserved bit would not be set, and we would process it exactly as before.
    If an existing implementation receives the new IGMP/MLD message, it would both ignore the reserved bit, and the additional data according to the RFCs (although if implementations tried to use additional data in some way, then they might break, but I think we have to live with that). They were not supposed to use it.

    When using the extension, one must consider interoperability with implementations that do not support the extension mechanism, as well as implementations that do not support the specified types. Not supporting the mechanism, should be equivalent to not supporting any of the types.

    I can try to add a few more details in the draft.
    >
    >
    > Also, for the following:
    >
    >
    >
    >    The extension will be part of additional data as mentioned in
    >
    >    [RFC3810] Section 5.1.12 (resp.  [RFC3376] Section 4.1.10) for 
    > query
    >
    >    messages and [RFC3810] Section 5.2.12 (resp.  [RFC3376]
    >
    >    Section 4.2.11) for report messages.
    >
    >
    >
    > 5.2.12 should be 5.2.11.

    Good catch!

    Let me know if you have any thoughts on what I wrote above, or anything else.

    Thanks,
    Stig

    >
    >
    > Jeffrey
    >
    >
    >
    > From: pim <[email-masked]> On Behalf Of Michael McBride
    > Sent: Monday, December 7, 2020 7:24 PM
    > To: [email-masked]
    > Subject: [pim] draft-ietf-pim-igmp-mld-extension WGLC
    >
    >
    >
    > [External Email. Be cautious of content]
    >
    >
    >
    > Hello all,
    >
    >
    >
    > Today begins a two week wglc for 
    > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-pim
    > -igmp-mld-extension-02__;!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHna
    > gH4aFnMqlcCi88ELWy-pDugRf9Hs5U2M$
    >
    >
    >
    > Please review (it?s a quick read) and let us know your opinion on it?s readiness to progress to the iesg.
    >
    >
    >
    > Thanks,
    >
    > mike
    >
    >
    > Juniper Business Use Only
    >
    > _______________________________________________
    > pim mailing list
    > [email-masked]
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim_
    > _;!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHnagH4aFnMqlcCi88ELWy-pDug
    > RfHNMtKWQ$

    ------------------------------

    Message: 3
    Date: Fri, 18 Dec 2020 02:10:54 +0000
    From: "Holland, Jake" <[email-masked]>
    To: Michael McBride <[email-masked]>, "[email-masked]"
            <[email-masked]>
    Subject: Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC
    Message-ID: <[email-masked]>
    Content-Type: text/plain; charset="utf-8"

    Hi PIM wg,

    I have a few minor comments on this draft.  I believe they?re readily resolvable, but I think some go beyond nits.  Overall the draft seems helpful to bier and possibly could support a few more things (e.g. population count in igmp/mld proxying might be useful if this gets any uptake).  So I support moving it forward as soon as the issues can be resolved.

    1.
    As with Jeffrey?s comments, my main technical comment regards the possibility of additional extra data beyond this extension, from the last paragraph in section 3.

    I think this possibility is confusing to handle, since if there are 2 separate uses the ordering is not clear, so if we imagine another bit indicating another kind of additional data, it would strictly have to be aware of this draft to ensure its data came afterward.

    I think using some of the reserved bits as a magic number might be a good call here, especially if we think there are existing implementations doing something with this space.  But just disallowing any other data when the E bit is set seems like also a fine choice that clears up confusion.

    2.
    I think the doc should specify the reaction if the length fields don't match up, or if anything exceeds the size of the packet or the extra space.  (Do all the TLVs get ignored, or do the apparently-good TLVs get handled an then the rest get ignored?)

    3.
    I think this draft's security considerations section is a bit light for the complexity it introduces.  It might be worth checking how they handled this in the UDP options draft, I think the first and third paragraphs might have some useful language to copy:
    https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-09*section-17__;Iw!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHnagH4aFnMqlcCi88ELWy-pDugRf7MKwpwE$

    4.
    The length fields described in section 3 should specify the units (that the lengths are given in octets).

    I also saw a few nits:
    5.
    In the 2nd paragraph of section 1, I don't know what "resp."
    means here, and it's not defined.  (From context it seems to be indicating that MLD and IGMP get the same language with different
    references?):
       The extension will be part of additional data as mentioned in
       [RFC3810] Section 5.1.12 (resp.  [RFC3376] Section 4.1.10) for query
       messages and [RFC3810] Section 5.2.12 (resp.  [RFC3376]
       Section 4.2.11) for report messages.

    6.
    2nd to last paragraph of section 4, singular "host" should be plural:
       the behavior of host and routers supporting the new types, consider

    7.
    Last paragraph of section 4 has confusing phrasing with a couple of plurality mismatche ("mechanism do not" and "nodes may send older message"), and I think it's not quite right to say that a mechanism supports a protocol, rather than that the document defines a mechanism only for certain protocol versions.  You could just fix the plurality, but I'll suggest some different text that sounds more correct to me, but please feel free to use it or not:

    OLD:
       The extension mechanism do not support IGMPv1, IGMPv2 and MLDv1.  As
       nodes may send older version message, they would also not be able to
       send messages using this extension.

    Suggested:
       This document defines an extension mechanism only for IGMPv3 and MLDv2.
       No E bit or extension mechanism is defined here for IGMPv1, IGMPv2, or
       MLDv1.

    Best regards,
    Jake

    From: Michael McBride <[email-masked]>
    Date: Monday, December 7, 2020 at 4:23 PM
    To: "[email-masked]" <[email-masked]>
    Subject: [pim] draft-ietf-pim-igmp-mld-extension WGLC

    Hello all,
    ?
    Today begins a two week wglc for https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-pim-igmp-mld-extension-02__;!!GjvTz_vk!EKc8vPWuhUwwzwkh8HXSN0mQ88VZX4J9iug9ei03YduV64M2tP9qW4Om3ngQn08$
    ?
    Please review (it?s a quick read) and let us know your opinion on it?s readiness to progress to the iesg.
    ?
    Thanks,
    mike

    ------------------------------

    Subject: Digest Footer

    _______________________________________________
    pim mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHnagH4aFnMqlcCi88ELWy-pDugRfHNMtKWQ$

    ------------------------------

    End of pim Digest, Vol 200, Issue 13
    ************************************

    _______________________________________________
    pim mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/pim

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 8 Mar 2021 14:26:21 -0800

Ananya- can you address my comment on section 6.  Shouldn't that 
recommendation also apply to Anycast RP with MSDP (RFC3446)?  For example, 
what if the nearest Anycast RP to whom a DR was sending its packed 
null-regs goes down and those null-regs get sent to the next closest 
Anycast RP?  Or would that restart the process since that RP doesn't have 
register state?

Also, did you see my subsequent question in:
https://mailarchive.ietf.org/arch/msg/pim/Ir8YFfEJFm3B97YakNAEj0s7_BI/

In sect 7 (and elsewhere in the doc), can one assume that "PIM Register" 
messages referred to in the doc are data-encapped, while "Null-Registers" 
always refers to registers without data-encap?

-Lenny

On Thu, 4 Mar 2021, Ananya Gopal (ananygop) wrote:

| 
| 
| Hi WG,
| Thank you for the comments. We have taken care of all editorial comments.
| 
| Some additional questions that needed a discussion:
| 
| [Lenny] Could there ever be a case where an RP might need to send Register-stops for only a subset of the s-g pairs that were in the packet null-register message? I couldn't think of a reason, but thought I'd ask.
| [AG] Yes, this depends on the register policy at RP. Earlier RP policy was applied to each packet, but now it will be applied to each record.
| And only if the RP accepts the register we will send register stop.
| 
| [Zheng] Is the capability per [S,G] or all sources -groups?
| [AG] This capability applies to all S,Gs. It?s not per S,G.
| 
| For Abhishek's BSR extension proposal:
| [AG] Abhishek, with respect to the comments about the BSR extension, we think that it should be a separate draft, and we can work together on that.
| For this draft, we recommend only anycast RPs. We can support heterogeneous mix of RPs with that extension draft. It could be a new SubType in the PIM Register Messages.
| 
| Additional comments:
| Along with the recommendation of using only Anycast RPs, to reduce the risk of losing Register Messages, the DR can send one (S,G) as unpacked, also acting like a probe, and check for Register-Stop from the RP.
| With every packed register, you can send one unpacked register. Only need to probe, when we have active sources. With the probe, we can figure out if the capability is set or not, as we?ll receive a Register-Stop.
| Though, there are chances that the RP doesn?t support it after the probe, so after say, 5 seconds, we can switch to unpacked Null registers and then Data registers, if there is no support for the feature.
| 
| So in summary, Any Register from RP, with no capability set, immediately downgrade. After 5 seconds of receiving no registers from RP, switch to Null registers and then data registers.
| 
| We will be presenting the additional comments in the upcoming IETF 110.
| 
| Thanks,
| Ananya
| 
| On 12/19/20, 1:37 AM, "pim on behalf of Abhishek Chakraborty" <[email-masked] on behalf of cabhi=[email-masked]> wrote:
| 
|     My earlier comment regarding the extension of this null register packing capability bit advertisement in Candidate RP message to a BSR also can be considered as an attribute to decide the best router for a group-range.
|     In a BSR network where multiple PIM candidate RPs advertise their candidateship to BSR, it can also set this capability bit.
|     A capable candidate RP can be more preferred over a non capable RP if all other attributes of them are same.
| 
|     This capability bit can be an input to the hash function.
| 
|     Thanks and Regards,
|     Abhishek
| 
| 
|     Juniper Business Use Only
| 
|     -----Original Message-----
|     From: pim <[email-masked]> On Behalf Of [email-masked]
|     Sent: Friday, December 18, 2020 7:41 AM
|     To: [email-masked]
|     Subject: pim Digest, Vol 200, Issue 13
| 
|     [External Email. Be cautious of content]
| 
| 
|     Send pim mailing list submissions to
|             [email-masked]
| 
|     To subscribe or unsubscribe via the World Wide Web, visit
|             https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHnagH4aFnMqlcCi88ELWy-pDugRfHNMtKWQ$
|     or, via email, send a message with subject or body 'help' to
|             [email-masked]
| 
|     You can reach the person managing the list at
|             [email-masked]
| 
|     When replying, please edit your Subject line so it is more specific than "Re: Contents of pim digest..."
| 
| 
|     Today's Topics:
| 
|        1. Re: additional extensions on
|           draft-ietf-pim-null-register-packing-06 (Abhishek Chakraborty)
|        2. Re: draft-ietf-pim-igmp-mld-extension WGLC (Stig Venaas)
|        3. Re: draft-ietf-pim-igmp-mld-extension WGLC (Holland, Jake)
| 
| 
|     ----------------------------------------------------------------------
| 
|     Message: 1
|     Date: Thu, 17 Dec 2020 22:45:25 +0000
|     From: Abhishek Chakraborty <[email-masked]>
|     To: "[email-masked]" <[email-masked]>
|     Subject: Re: [pim] additional extensions on
|             draft-ietf-pim-null-register-packing-06
|     Message-ID:
|             <[email-masked]>
| 
|     Content-Type: text/plain; charset="us-ascii"
| 
|     1.
|     Draft section conflicts with PIM RFC 4601 section 4.4:
| 
|     draft-ietf-pim-null-register-packing-06 tells:
|     7.  PIM RP router version downgrade
| 
|        Consider a PIM RP router that supports PIM Register Packing and then
|        downgrades to a software version which does not support PIM Register
|        Packing.  The DR that sends the PIM Packed Register message will not
|        get a PIM Register-Stop message back.  In such scenarios the DR MUST
|        send an unpacked PIM Register and check the PIM Register-Stop to see
|        if the capability bit (P-bit) for PIM Packed Register is set or not.
|        If it is not set then the DR will continue sending unpacked PIM
|        Register messages.
| 
|     PIM RFC 4601 section 4.4 tells:
|     "Just before the Register-Stop Timer expires, the DR sends a Null-Register Message to the RP to allow the RP to refresh the Register-Stop information at the DR. If the Register-Stop Timer actually expires, the DR will resume encapsulating packets from the source to the RP."
| 
|     The suggestion for the extension to send the periodic PIM Null Registers to RP with special S,G or 0.0.0.0,0.0.0.0 and monitor the packing bit in RegisterSTop addresses this conflict.
|     Since in this draft draft-ietf-pim-null-register-packing-06, we are going to have :
|     "Type, SubType:
| 
|           The new packed Null-Register Type and SubType values TBD."
| 
|     It's better to always send a previous version of Null Register and check the P bit in RegisterStop from RP.
| 
|     2.
|     Also we may need to mention in the draft that what happens when FHR doesn't receive any one of the S,G in the RegisterStop that it received from RP as a response to its packed Null Register.
|     For example:
|     Null Register has s1,g1, s2,g2, s3,g3 and RegisterStop has s1,g1, and s2,g2.
|     Then it should start encapsulating for s3,g3.
| 
|     3.
|     Also, there are use cases where FHRs can be on a LAN.
|     Lets say FHR1 and FHR2 is on LAN, FHR1 is the DR and it becomes the forwarder. But FHR2 is the unicast best path towards source and thus RP sends SPT to FHR2.
|     So, FHR1 will have Register States and FHR2 will have Forwarding states.
|     Lets FHR1 and RP has the capability but FHR2 does not. When FHR1 goes down, FHR2 takes up DR role and sends Null Registers to RP one by one. On RP it should fall back to older version of RegisterStop.
|     This is basically an FHR downgrade use case.
| 
|     Thanks and Regards,
|     Abhishek
| 
| 
| 
|     Juniper Business Use Only
| 
|     -----Original Message-----
|     From: pim <[email-masked]> On Behalf Of [email-masked]
|     Sent: Thursday, December 17, 2020 4:11 PM
|     To: [email-masked]
|     Subject: pim Digest, Vol 200, Issue 11
| 
|     [External Email. Be cautious of content]
| 
| 
|     Send pim mailing list submissions to
|             [email-masked]
| 
|     To subscribe or unsubscribe via the World Wide Web, visit
|             https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iEdjVwZ_k$
|     or, via email, send a message with subject or body 'help' to
|             [email-masked]
| 
|     You can reach the person managing the list at
|             [email-masked]
| 
|     When replying, please edit your Subject line so it is more specific than "Re: Contents of pim digest..."
| 
| 
|     Today's Topics:
| 
|        1. review of draft-ietf-pim-null-register-packing-06
|           (Leonard Giuliano)
|        2. A additional extensions on
|           draft-ietf-pim-null-register-packing-06 (Abhishek Chakraborty)
| 
| 
|     ----------------------------------------------------------------------
| 
|     Message: 1
|     Date: Wed, 16 Dec 2020 12:54:52 -0800
|     From: Leonard Giuliano <[email-masked]>
|     To: <[email-masked]>
|     Subject: [pim] review of draft-ietf-pim-null-register-packing-06
|     Message-ID: <[email-masked]>
|     Content-Type: text/plain; format=flowed; charset="US-ASCII"
| 
| 
|     I reviewed the Null-Register packing draft and found it to be a well-written, concise and clear doc specifying a very simple optimization.
|     Very much appreciate the brevity of this doc.  A few very minor (mostly
|     editorial) nits, plus one question:
| 
|     -sect2, 1st para, last sentence: "when it learns RP is capable"
|             -learns the RP
| 
|     -sect8, last sentence: "the number of records should be limited to the MTU of the outgoing interface."
|             -might be more appropriate to say "limited by the MTU"
| 
|     -sect9, 2nd para, last sentence: "these messages are not required for PIM-SSM."
|             -'required' implies they could be optionally used in SSM, so it might be better to say "these messages are not used in PIM-SSM."
| 
|     -sect9, 3rd para, 1st sentence: "case where a spoof Register can be sent"
|             -"spoofed Register message"
| 
| 
|     -sect9, 3rd para, 2nd sentence: "This can cause Null-Registers to not be received by the RP."
|             -might be better to say "This can cause packed Null-Registers to be sent to an RP that doesnt support this packed format."
| 
|     -sect9, 3rd para, 3rd sentence: consider revising this sentence.  Maybe something like "For example, uRPF can be used to filter spoofed packets."
| 
|     -Sect6: this recommendation seems equally applicable to Anycast RP with MSDP for the same reasons as it is being recommended for Anycast RP with PIM.
| 
|     Substantive question: could there ever be a case where an RP might need to send Register-stops for only a subset of the s-g pairs that were in the packet null-register message?  I couldn't think of a reason, but thought I'd ask.
| 
|     -Lenny
| 
| 
| 
|     ------------------------------
| 
|     Message: 2
|     Date: Thu, 17 Dec 2020 10:40:59 +0000
|     From: Abhishek Chakraborty <[email-masked]>
|     To: "[email-masked]" <[email-masked]>
|     Subject: [pim] A additional extensions on
|             draft-ietf-pim-null-register-packing-06
|     Message-ID:
|             <[email-masked]>
| 
|     Content-Type: text/plain; charset="us-ascii"
| 
|     Hi Experts,
| 
|     Going through the below draft, I felt we extend the same to address a heterogeneous networks (in terms of having mix of capable/non-capable RPs):
| 
|     https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-pim-null-register-packing-06__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iEZ0v0shs$
| 
| 
|     What the draft says:
| 
|     "   To ensure compatibility with routers that do not support processing
|        of the packed format, A router (DR) can decide to pack multiple Null-
|        Register messages based on the capability received from the RP as
|        part of Register-Stop.  Thus a DR will switch to the packed format
|        only when it learns RP is capable of handling the packed Null-
|        Register messages.
|     "
| 
|     I would like to suggest 2 new extensions in the draft:
| 
|       1.  Once a router becomes an FHR (once data traffic hits), it uses the above mechanism to find out if the RP supports packing capability or not from RP's first RegisterStop. Later on, before sending packed NULL Registers:
|          *   FHR to send a NULL Register packet to respective RPs for different group ranges, with either Group, Source 0.0.0.0, 0.0.0.0 or with a reserved Multicast group, and wait for a RegisterStop to ensure the RP still supports decoding of packed NULL Registers. So every 60 secs before sending packed Registers, we need to be sure the RP still supports this capability.
|       2.  For BootStrap use cases,
|          *   Candidate RP can advertise the capability bit to the BSR in the reserved bit of RFC 5059 section 4.2.
|          *   The BSR can then map the best RP to its group range and can send the BSM to all the routers enabling the capability bit of each RP in the reserved bits in RFC 5059 section 4.1.
|          *   When the rest of the Non RPs get the BSM, it can know in advance which RP supports capability and which doesn't.
| 
|     Advantages with the above extensions:
| 
|       1.  With above 1.a extension in the draft we can now support mix of capable/non-capable RPs in a network. This extension also addresses the dynamic upgrade/downgrade of a router in a network. Also this allows us to have a heterogeneous RP sets in Anycast RP cases (Anycast RP with MSDP and not PIM Anycast RP sets). For example:
|          *   RP1 and RP2 are anycast RPs in network. RP1 is primary and RP2 is secondary in terms of best unicast reachability.
|          *   RP1 supports packing capability and RP2 doesn't.
|          *   FHR sends packed Null Registers to RP1 initially.
|          *   Now RP1 goes down as some link in between flapped.
|          *   FHR unaware of this churn. The tunnel is same for FHR.
|          *   Now if FHR continues to send packed NULL registers to RP2 it breaks.
|          *   So the 1.a extension (sending that extra reserved group register to RP2 before sending periodic NULL register) will make sure that RP2 is capable or not.
|       2.  The BSR extension in above 2.a and 2.b let the non RPs in the network know the capabilities of the RPs.
| 
|     Please let me know your views on the above extensions.
| 
|     Thanks and Regards,
|     Abhishek
| 
| 
| 
|     Juniper Business Use Only
|     -------------- next part --------------
|     An HTML attachment was scrubbed...
|     URL: <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/pim/attachments/20201217/bbb35362/attachment.htm__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iE-nRgYP0$ >
| 
|     ------------------------------
| 
|     Subject: Digest Footer
| 
|     _______________________________________________
|     pim mailing list
|     [email-masked]
|     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Ta0gfrXWQyKFH3P-GzIGRAs54hcd4hEU9PQn3UceXNwxLiKQYHmqe9iEdjVwZ_k$
| 
| 
|     ------------------------------
| 
|     End of pim Digest, Vol 200, Issue 11
|     ************************************
| 
| 
| 
|     ------------------------------
| 
|     Message: 2
|     Date: Thu, 17 Dec 2020 15:25:57 -0800
|     From: Stig Venaas <[email-masked]>
|     To: "Jeffrey (Zhaohui) Zhang" <zzhang=[email-masked]>
|     Cc: Michael McBride <[email-masked]>, "[email-masked]"
|             <[email-masked]>
|     Subject: Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC
|     Message-ID:
|             <[email-masked]>
|     Content-Type: text/plain; charset="UTF-8"
| 
|     Hi Jeffrey
| 
|     I appreciate your comments, please see responses inline.
| 
|     On Tue, Dec 15, 2020 at 6:21 PM Jeffrey (Zhaohui) Zhang <zzhang=[email-masked]> wrote:
|     >
|     > Support progressing this work.
|     >
|     >
|     >
|     > I have a couple of curiosity questions on the following:
|     >
|     >
|     >
|     >    Note that there may be additional data following this extension.
|     > The
|     >
|     >    Total Extension Length field would indicate where this extension
|     >
|     >    ends, and the additional data starts.
|     >
|     >
|     >
|     > How would you have additional data following this extension? The TLV mechanism seems to be universal/generic to handle all possible extensions, so why would you have another extension blob after this, and how would you indicate so? By another bit in the reserved field?
|     >
|     > Just wondering if this additional data needs to be mentioned at all.
| 
|     I agree that there should be no need for additional data for future extensions as TLVs can provide any potential extension. If the WG and co-authors agree, I'm happy to remove the additional additional data.
|     We can then also simplify the length check and say that the extension length specified must be equal to the remaining payload (subtracting from packet payload length).
| 
|     >
|     >   Also, there is a possibility
|     >
|     >    that an implementation uses the Additional Data part of IGMP/MLD
|     >
|     >    messages, but not according to this extension scheme.
|     >
|     >
|     >
|     > Do you mean a non-standard existing implementation? Now that you mention that, are we supposed to define the interop procedures? Are they supposed to interop with the implementations following this draft at all?
| 
|     The IGMP/MLD RFCs specify how additional data may be present and how it should be ignored. I've seen cases where implementations intentionally (or maybe by accident) have sent packets with additional data. I think it is safest to use a reserved bit to clearly indicate that this extension is in place, rather than trying to parse whatever additional data may be present.
| 
|     If we receive data from an existing implementation, the reserved bit would not be set, and we would process it exactly as before.
|     If an existing implementation receives the new IGMP/MLD message, it would both ignore the reserved bit, and the additional data according to the RFCs (although if implementations tried to use additional data in some way, then they might break, but I think we have to live with that). They were not supposed to use it.
| 
|     When using the extension, one must consider interoperability with implementations that do not support the extension mechanism, as well as implementations that do not support the specified types. Not supporting the mechanism, should be equivalent to not supporting any of the types.
| 
|     I can try to add a few more details in the draft.
|     >
|     >
|     > Also, for the following:
|     >
|     >
|     >
|     >    The extension will be part of additional data as mentioned in
|     >
|     >    [RFC3810] Section 5.1.12 (resp.  [RFC3376] Section 4.1.10) for
|     > query
|     >
|     >    messages and [RFC3810] Section 5.2.12 (resp.  [RFC3376]
|     >
|     >    Section 4.2.11) for report messages.
|     >
|     >
|     >
|     > 5.2.12 should be 5.2.11.
| 
|     Good catch!
| 
|     Let me know if you have any thoughts on what I wrote above, or anything else.
| 
|     Thanks,
|     Stig
| 
|     >
|     >
|     > Jeffrey
|     >
|     >
|     >
|     > From: pim <[email-masked]> On Behalf Of Michael McBride
|     > Sent: Monday, December 7, 2020 7:24 PM
|     > To: [email-masked]
|     > Subject: [pim] draft-ietf-pim-igmp-mld-extension WGLC
|     >
|     >
|     >
|     > [External Email. Be cautious of content]
|     >
|     >
|     >
|     > Hello all,
|     >
|     >
|     >
|     > Today begins a two week wglc for
|     > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-pim
|     > -igmp-mld-extension-02__;!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHna
|     > gH4aFnMqlcCi88ELWy-pDugRf9Hs5U2M$
|     >
|     >
|     >
|     > Please review (it?s a quick read) and let us know your opinion on it?s readiness to progress to the iesg.
|     >
|     >
|     >
|     > Thanks,
|     >
|     > mike
|     >
|     >
|     > Juniper Business Use Only
|     >
|     > _______________________________________________
|     > pim mailing list
|     > [email-masked]
|     > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim_
|     > _;!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHnagH4aFnMqlcCi88ELWy-pDug
|     > RfHNMtKWQ$
| 
| 
| 
|     ------------------------------
| 
|     Message: 3
|     Date: Fri, 18 Dec 2020 02:10:54 +0000
|     From: "Holland, Jake" <[email-masked]>
|     To: Michael McBride <[email-masked]>, "[email-masked]"
|             <[email-masked]>
|     Subject: Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC
|     Message-ID: <[email-masked]>
|     Content-Type: text/plain; charset="utf-8"
| 
|     Hi PIM wg,
| 
|     I have a few minor comments on this draft.  I believe they?re readily resolvable, but I think some go beyond nits.  Overall the draft seems helpful to bier and possibly could support a few more things (e.g. population count in igmp/mld proxying might be useful if this gets any uptake).  So I support moving it forward as soon as the issues can be resolved.
| 
|     1.
|     As with Jeffrey?s comments, my main technical comment regards the possibility of additional extra data beyond this extension, from the last paragraph in section 3.
| 
|     I think this possibility is confusing to handle, since if there are 2 separate uses the ordering is not clear, so if we imagine another bit indicating another kind of additional data, it would strictly have to be aware of this draft to ensure its data came afterward.
| 
|     I think using some of the reserved bits as a magic number might be a good call here, especially if we think there are existing implementations doing something with this space.  But just disallowing any other data when the E bit is set seems like also a fine choice that clears up confusion.
| 
|     2.
|     I think the doc should specify the reaction if the length fields don't match up, or if anything exceeds the size of the packet or the extra space.  (Do all the TLVs get ignored, or do the apparently-good TLVs get handled an then the rest get ignored?)
| 
|     3.
|     I think this draft's security considerations section is a bit light for the complexity it introduces.  It might be worth checking how they handled this in the UDP options draft, I think the first and third paragraphs might have some useful language to copy:
|     https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-09*section-17__;Iw!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHnagH4aFnMqlcCi88ELWy-pDugRf7MKwpwE$
| 
|     4.
|     The length fields described in section 3 should specify the units (that the lengths are given in octets).
| 
|     I also saw a few nits:
|     5.
|     In the 2nd paragraph of section 1, I don't know what "resp."
|     means here, and it's not defined.  (From context it seems to be indicating that MLD and IGMP get the same language with different
|     references?):
|        The extension will be part of additional data as mentioned in
|        [RFC3810] Section 5.1.12 (resp.  [RFC3376] Section 4.1.10) for query
|        messages and [RFC3810] Section 5.2.12 (resp.  [RFC3376]
|        Section 4.2.11) for report messages.
| 
|     6.
|     2nd to last paragraph of section 4, singular "host" should be plural:
|        the behavior of host and routers supporting the new types, consider
| 
|     7.
|     Last paragraph of section 4 has confusing phrasing with a couple of plurality mismatche ("mechanism do not" and "nodes may send older message"), and I think it's not quite right to say that a mechanism supports a protocol, rather than that the document defines a mechanism only for certain protocol versions.  You could just fix the plurality, but I'll suggest some different text that sounds more correct to me, but please feel free to use it or not:
| 
|     OLD:
|        The extension mechanism do not support IGMPv1, IGMPv2 and MLDv1.  As
|        nodes may send older version message, they would also not be able to
|        send messages using this extension.
| 
|     Suggested:
|        This document defines an extension mechanism only for IGMPv3 and MLDv2.
|        No E bit or extension mechanism is defined here for IGMPv1, IGMPv2, or
|        MLDv1.
| 
| 
|     Best regards,
|     Jake
| 
| 
|     From: Michael McBride <[email-masked]>
|     Date: Monday, December 7, 2020 at 4:23 PM
|     To: "[email-masked]" <[email-masked]>
|     Subject: [pim] draft-ietf-pim-igmp-mld-extension WGLC
| 
|     Hello all,
|     ?
|     Today begins a two week wglc for https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-pim-igmp-mld-extension-02__;!!GjvTz_vk!EKc8vPWuhUwwzwkh8HXSN0mQ88VZX4J9iug9ei03YduV64M2tP9qW4Om3ngQn08$
|     ?
|     Please review (it?s a quick read) and let us know your opinion on it?s readiness to progress to the iesg.
|     ?
|     Thanks,
|     mike
| 
| 
|     ------------------------------
| 
|     Subject: Digest Footer
| 
|     _______________________________________________
|     pim mailing list
|     [email-masked]
|     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHnagH4aFnMqlcCi88ELWy-pDugRfHNMtKWQ$
| 
| 
|     ------------------------------
| 
|     End of pim Digest, Vol 200, Issue 13
|     ************************************
| 
|     _______________________________________________
|     pim mailing list
|     [email-masked]
|     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!UV7fbVGsXkGjlzDNyHG5jvR4lYP4SkHMukiyvh4pzOU97tSR3AyspIkKirdla7o$
| 
| _______________________________________________
| pim mailing list
| [email-masked]
| https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!UV7fbVGsXkGjlzDNyHG5jvR4lYP4SkHMukiyvh4pzOU97tSR3AyspIkKirdla7o$
|

---

From: "Ananya Gopal (ananygop)" <[email-masked]>
Date: Tue, 9 Mar 2021 15:13:16 +0000

Hello Lenny, 

Looks like I missed two of your comments. Apologies.

1. PIM Null-Register packing will treat both Anycast RP or Anycast RP with MSDP [RFC446] the same. For both mechanisms, we should enable Null-Register packing only if all Anycast-RPs in the RP set support it.

2. Thank you for bringing the ambiguity in the usage of "PIM Register" and "Null-registers" in the draft. It is my understanding that when one says register, it could be either, data-registers or null-registers. In the latest draft, we will clear that up, and strictly use "PIM Packed Null-Registers" to refer to registers without data-encap, and will specify "Data Register messages", wherever data encap present. 

Thanks, 
Ananya

On 3/8/21, 2:23 PM, "Leonard Giuliano" <[email-masked]> wrote:

    -Lenny

    | 
    | 
    | Hi WG,