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

[Abhishek Chakraborty <[e-mail]>]

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://tools.ietf.org/html/draft-ietf-pim-null-register-packing-06


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