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

[Abhishek Chakraborty <[e-mail]>]

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
************************************