Subject: [pim] Some questions/suggestions on draft-kurapati-dynamicrp-bgpmvpn

From: Bharat Joshi <[email-masked]>
Date: Sat, 15 Jun 2013 09:10:11 +0000

Hi,

     I read through this draft and have some questions/suggestions on the same.

Regards,
Bharat

• In BGP-MVPN RFC 6513, it says BSR messages may be transmitted over any PMSI. The only requirement is that it should be delivered to all the other PEs in that MVPN. Now the abstract of this draft says, it can be done using either I-PMSI or S-PMSI. I am not sure how it can be done using S-PMSI. Is the selective PMSI is for ALL-PIM-ROUTERs IP address here.

• In Abstract, can we replace 'this information' by 'BSR messages'? Its mentioned at couple of places and I think it brings in more clarity.

• In Introduction, "can access this RP information" -> "can access this Group-to-RP mapping information". Or reword the sentence if it meant something else.

• In sentence, "However, carrying control messages like BSR in the data tunnels is not always desirable", can we justify why it is not always desirable?

• In Introduction, we just mention Group-to-RP mapping information messages. Should we call this Bootstrap Messages?

• In terminology, for existing terms, is not it better to refer to the RFC where they are actually defined instead of defining them here again?

• What is the need of passing BSR priority in BSR parameters?

• There is one advantage PMSI has over using BGP is that PEs need not create the whole BSR messages received from other PEs. Right?

• The disadvantage of using BGP could be that any PIM extension would need an update of how this new extension is handled in MVPN. Right?

• Will it make sense to pass PIM native messages in some encapsulation so that any current messages and future extensions are automatically taken care of.

• In section 4.2, 'Group prefix', would not we need a subnet-mask as well because a specific group-to-RP mapping may cover a range of group address?

• In all the sections, can all the parameters are clearly defined and how they are populated? For example: in section 4.3, RP priority is not mentioned.

• Can we rename BSR-BGP path attribute to BGP-PIM-BSR path attribute?

• A small typo "receiver of BSM MUlticast"

• In section 5, "carry BSR through BGP" -> "carry BSR messages through BGP"

• Please define BSM before the first usage?

• Both BSR messages and BSM has been used. If possible, please use only one of them.

• "information carried in BSR is" -> "information carried in BSM is"

• Please reword the following sentence:

This document only describes how the information carried in BSR is redistributed into BGP at the ingress PEs, and how the remote PEs redistribute this information from BGP back into BSR.

'redistribute' does not look like the right word for this. Also BSR should be BSM.

• In section 5, it is mentioned that a PE could be a C-RP or BSR. How is this possible? PE is not part of a customer network so why can this be a C-RP or C-BSR?

• "configured as C-RP or BSR for" -> "configured as C-RP or C-BSR for"

• "configured as BSR for a specific" -> "configured as C-BSR for a specific"

• Should not we mention that for how long a PE wait for all fragmented BSMs for a specific group-range has been received? There should be a timer running and these fragments should be discarded if all the packets are not received by this time. If PE does not do this, someone can attack the PE by sending fragmented BSMs and not sending all the fragments.

• In section 5.1.3, I am not sure if the statement "The peer to the ingress PE can be a BGP route reflector." seems at the right place.

• In section 5.1.3, what does "BSM Group-to-RP mapping calculation" means? What kind of calculation the egress PE does?

• In section 5.2, "dynamic RP group-range-to-RP mappings" -> "dynamic Group-to-RP mappings"

• In section 5.4, what does 'Dynamic RP advertisements' mean?

• In section 5.4, in following sentence:

BSR relies on variations of Reverse Path Forwarding (RPF) to ensure that advertisement messages do not loop through the network.

What does 'variations of RPF' means?

• In section 5.5, what is the need of passing the BGR message information using BGP if it anyway needs to send them natively using PMSI? Also, how will a BGP route reflector handle such a case? So does not this mean BGP method should be used only when all the PEs support it?

• In section 6.1, small typo in "boundary is at at group prefix"

• In section 6.2.1, at the end of first para, its not clear what needs to be communicated via BGP. Is it that a RP is no more available for a group-prefix when the next BSR comes or when the RP expires, that this RP is no more available for a group-prefix?

• In section 6.2.3, in following sentence:

When an originating PE's local bootstrap module elects a new BSR, all the old Group-to-RP mapping entries advertised by the previous BSR MUST be withdrawn.

Why does PE needs to withdraw the Group-to-RP mapping, won't it be automatically taken care when new BSMs are sent out? If some mappings are not available with new Elected BSR then they will anyway timeout as it would happen in other routers?

• Should not 'Inter-operation with other methods" be explained in greater details in section 6.

• In Security Consideration, I think there should be some text which talks about egress PE not receiving all the fragments and keeping the fragments for some time.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***