Re: [pim] : additional extensions on draft-ietf-pim-null-register-packing-06

[Abhishek Chakraborty <[e-mail]>]

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 <[e-mail]> On Behalf Of [e-mail]
Sent: Friday, December 18, 2020 7:41 AM
To: [e-mail]
Subject: pim Digest, Vol 200, Issue 13

[External Email. Be cautious of content]


Send pim mailing list submissions to
        [e-mail]

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
        [e-mail]

You can reach the person managing the list at
        [e-mail]

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 <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: [pim] additional extensions on
        draft-ietf-pim-null-register-packing-06
Message-ID:
        <[e-mail]>

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 <[e-mail]> On Behalf Of [e-mail]
Sent: Thursday, December 17, 2020 4:11 PM
To: [e-mail]
Subject: pim Digest, Vol 200, Issue 11

[External Email. Be cautious of content]


Send pim mailing list submissions to
        [e-mail]

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
        [e-mail]

You can reach the person managing the list at
        [e-mail]

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 <[e-mail]>
To: <[e-mail]>
Subject: [pim] review of draft-ietf-pim-null-register-packing-06
Message-ID: <[e-mail]>
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 <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: [pim] A additional extensions on
        draft-ietf-pim-null-register-packing-06
Message-ID:
        <[e-mail]>

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
[e-mail]
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 <[e-mail]>
To: "Jeffrey (Zhaohui) Zhang" <zzhang=[e-mail]>
Cc: Michael McBride <[e-mail]>, "[e-mail]"
        <[e-mail]>
Subject: Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC
Message-ID:
        <[e-mail]>
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=[e-mail]> 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 <[e-mail]> On Behalf Of Michael McBride
> Sent: Monday, December 7, 2020 7:24 PM
> To: [e-mail]
> 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
> [e-mail]
> 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" <[e-mail]>
To: Michael McBride <[e-mail]>, "[e-mail]"
        <[e-mail]>
Subject: Re: [pim] draft-ietf-pim-igmp-mld-extension WGLC
Message-ID: <[e-mail]>
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 <[e-mail]>
Date: Monday, December 7, 2020 at 4:23 PM
To: "[e-mail]" <[e-mail]>
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
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!V7BUycOSmUNXAk4dnxFMZR95wJTPHnagH4aFnMqlcCi88ELWy-pDugRfHNMtKWQ$


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

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