Subject: [pim] Few questions/suggestion on DR Load Balancing draft

From: Bharat Joshi <[email-masked]>
Date: Fri, 28 Jun 2013 10:39:40 +0000

Hi,

       I just read through the DR Load Balancing draft. I have few questions/suggestion below.

Regards,
Bharat

• In Abstract, s/as an Ethernet/as Ethernet/g. This seems to be at couple of places.

• Are 'first hop network' or 'last hop LAN' a well known term? Will it be easy for people to understand that this is being talked from multicast source perspective? Can we call them directly connected LAN in both the cases?

• In Abstract, s/is operated in PIM SM/is operating in PIM SM/g. This is at least at two places.

• In Abstract, in following sentence:

On the last hop network, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operated in PIM SM/SSM/DM.

Should we mentioning BIDIR-PIM as well in this list? Or such a group is treated differently?

• In Abstract, s/can be distributed to and handled among these/can be distributed among these/

• In GDR definition, it talks about that GDR is responsible for a group. Does this mean that a single GDR will be responsible for all channels (S,G) for a given group but different sources?

• s/process received new PIM Hello/process new PIM Hello/

• In Introduction, in following sentence:

According to [RFC4601], R1 will be responsible for forwarding to the last hop LAN.

       Can we replace this sentence by something similar to a sentence from RFC 4601, section 6.1.1 point 2. The sentence is as follows:

The designated router on a LAN is (in the absence of asserts) responsible for forwarding traffic to that LAN on behalf of any local members.

• There may be a mix of local hosts as well as downstream routers in a network scenario. Do we still call this the last hop LAN? I guess yes and I think there can still be GDR candidate and this draft can apply. Right? I think this is not coming out well in the draft. So please add/update some text to reflect this.

• In section 3, I did not get what 'load balancing' are we talking about in case of 'first hop routers'? 

• In section 3, I also did not understand how ECMP helps in this load balancing. If there are multiple routers on a LAN in which the source also sits, as per PIM, its the DR who is to send the register messages to the RP. So I am not sure how ECMP helps here in making other router on this LAN to do this instead of the DR?

• As per RFC 4601, PIM DR is elected for any type of networks so there is no need to mention that PIM DR election is done in a multi-access network.

• In section 4, in sentence "The PIM DR is responsible for sending Join/Prune messages to the RP or source.", I think we should mention that this is done for the local host's join/leave.

• In section 4, para 1, I think it should be enough if the text suggest that PIM DR election is done as per RFC 4601 instead of describing the algorithm here.

• s/routers support this specification/routers which support this specification/

• In section 4, can we reword the following sentence:

Last hop routers who are with the new LBC TLV and with the same DR priority as the PIM DR are GDR Candidates.

to

Last hop routers which supports the 'Load Balancing Capability' PIM hello option and uses the same DR priority as the PIM DR, are considered to be GDR Candidates.

• In section 4, last para, can we clearly mention that we are referring to groups joined by local members only.

• I think section 4.2 should be divided into two, one that defined hash mask and another that defines the hash function.

• Apart from the hash value/function, cannot an administrator configure the mapping statically? This way, an administrator will have more control on which channel is registered by which DR and also, he won't need these new hello options. I agree that such a thing will work only if all vendors provide such a mean to the administrators.

• In section 4.3, its not clear what will be the contents of first PIM hello message of a router coming up? Will it contain LB GDR option or not? At that time, it may not know whether its a DR or not. Actually, it will assume that its the DR until it receives a hello message from a higher DR priority router. 

• In section 5.2, should we be using encoded format defined in RFC 4601 for GDR addresses or using it in native format is fine?

• What is the idea of sending the masks from PIM DR to other routers? Why cannot they be configured in all the routers?

• s/When an IGMP join is received/When an IGMP/MLD join is received/

• s/a neighbor Hello with/a PIM Hello with/

• What happens when a PIM router supporting this new options times out in PIM DR router?

• Does PIM DR insert its own address as well in the neighbor's address into the LBGRD TLV list?

• In section 6.2, first para talks about router R1. Is it referring to figure 1?

• In section 6.2, should not we mention what a GDR candidate does when a PIM hello from PIM DR is received? I think few last paras at the end of this section should be in the front. Please check.

• s/from a non-DR PIM router/from a PIM router which is not DR/

• In section 6.2, its not clear if the hash is calculated only for 'X' or for all the GDR available in the list. I think it needs to be calculated for all of them and then if hash is highest for 'X', its selected, otherwise not.

• In section 6.3, in case of PIM assert, should not we override the existing Assert algorithm completely and suggest that the winner should be selected based on the currently selected GDR?

• What happens when a new router comes up which becomes the DR but does not support this new PIM hello option?

• What is the need of sending out the list of GDR by PIM DR to other routers? Other routers can anyway figure this out because they also receive the PIM hello from other routers. Right?

• In section 8, "PIM DR Load Balancing Hello message", does not look right.

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