Subject: [pim] Some questions and suggestions on PIM-PORT draft

From: Bharat Joshi <[email-masked]>
Date: Mon, 28 Feb 2011 10:46:34 +0530

Hi Stig,

    I finally managed to squeeze some time to look at the updated draft. I have got some more questions on this below:

Regards,
Bharat

• You may want to add 'mechanism' in the following sentence: "if and only if both have reliable transport enabled." -> "if and only if both have reliable transport mechanism enabled.

• Can we just use the full-form when an acronyms used first time? I am sure it will be asked when IESG review happens. For example: RPF neighbor. Another useful thing would be to add such acronyms in terminology or a reference to other RFC.

• In section 3.1, section number is missing in:

'All Hello messages containing the PIM-over-TCP Capable hello option,   MUST also contain the Interface ID hello option, see section ."

• In section 3.1, should we use 'It is RECOMMENDED that' instead of "We RECOMMEND that".

• The above two issues in section 3.2 as well.

• In section 4, the paragraph starting with "It is possible that a router starts" interchangeably uses ID or IDs. We start describing things in ID but later start using IDs. Can we keep this consistent?

• In section 4, it is described that a full-table update happens when connection is established and any state received during datagram is left to expire. Can we be explicit on what to do with timer of each group for which the update has been received? I think we need to stop that timer when we move from datagram to PORT mode and for which the update has been received. Right?

• In section 4, also, do we start the timer for each state if the PORT connection goes down? What do we do with this timer when the connection is reestablished and an update is received. So in affect, the same functionality as asked in the previous question?

• Small typo "One can quicker detect that" -> "One can quickly detect that"

• Small typo in "since the the previous"

• In section 4.2, most of the test in para 2 and 3 are repetitive. Can we cut down to keep it more straight forward?

• In para 2 of section 4.2,  draft says 'We RECOMMEND	this to be optional" and in para 4, it says 'Implementations SHOULD support Keep-Alive messages'.

• In following text:

It is possible that a router receives Join/Prune messages for an interface/link that is down. As long as the neighbor has not expired, we RECOMMEND processing those messages as usual.

I am not sure how the hello timer is still running if the interface is down. Also how this message has come in, if the link itself is down? (I am assuming that the link here means the port).

• In last para of section 4.2, in following text:

However, if  the connection is shared by multiple interfaces and the GenID changes only for one of them, then there was not a full restart, and one may simply send a full update similar to other cases when a GenID changes for an upstream neighbor.

Can we change this to:

However, if  the connection is shared by multiple interfaces and the GenID changes only for one of them, PORT neighbor SHOULD simply send a full update similar to other cases when a GenID changes for an upstream neighbor.

• "no more PIM neighborships using it" -> "no more PIM neighbors using it"

• Small typo in "rules for connestion"

• J/P_HoldTime -> JP_HoldTime

• Typo "message message format"

• "Each PORT message will have the below Type/Length/Value format" -> "Each PORT message will have the Type/Length/Value format"

• In section 5, can we change the following text:

 If any parsing errors occur in a Join/Prune message, it is skipped, and we proceed processing any following PORT messages.

to

 If any parsing errors occur in a PORT message, it is skipped, and we proceed to any following PORT messages.

• In section 5.1, in following text:

As can be seen from the packet format diagram, multiple Join/Prune messages can go into one TCP/SCTP stream from the same or different Interface IDs.

How is it possible to use different interface-id in the same message? Interface-id is not repeating in the message after each Option buffer.

• The message length calculation is using '4*n', is this for interface-id? If so then the figure needs to be updated to show interface-id before next PORT option type.

• Small typo in "are not sent of the desired frequency".

• I was thinking that keep-alive message will just have a hold-time value but it seems to bee have PORT Option type as well. The reason of generating keep-alive message was that we do not have any PORT messages to send so what will we fill in PORT Option type in keep-alive message.

• In keep-alive message, can we correct the calculation of message length? It uses 4*n in the calculation which I think is not correct. Also why it uses 6 as the starting length, should not this be 8.

• Should we define mux/demux term somewhere? Can it be interpreted in the right context?

• Should not we register the new hello option 'TCP-Capable' with IANA?

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