Re: [pim] Query about scoped Bootstrap Message
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pim] Query about scoped Bootstrap Message



sumanta seal wrote:
Hi,

I have some confusion about one statement in the draft "draft-ietf-pim-sm-bsr-09". In section 3.3 (page 21), the draft says the following --
"RP mappings may be included in the first group range of a BSM, just as for any other group range. After this group range, other group ranges for which there are RP mappings appear in any order ".


Suppose a situation where the BSR is configured with one scope, say G and it becomes the elected BSR for that scope. At the same time it is receiving one C-RP-Adv message for the same scope (i.e . another router wants to be the candidate RP for the same multicast group range G) with address X. Now when the BSR will send BSM, G will always present in the first group-rp-set of the BSM (with Z bit 1). But will it include the RP address X in the first group-rp-set or it will add another group-rp-set with group address G ( Z bit 0) where it will include the RP address X.

You must only have each group range once with all the RPs for the range. So if you have multiple RPs in the RP-set for G, you should include them all there. If G is the scope, then you put G first in the BSM with Z bit set as you wrote.

Stig


Please let me know if more information is required.

Thanks and regards,
Sumanta

------------------------------------------------------------------------
Here’s a new way to find what you're looking for - Yahoo! Answers <http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/>



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

_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim



_______________________________________________ pim mailing list pim at ietf.org https://www1.ietf.org/mailman/listinfo/pim




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.