Subject: [pim] Hello HoldTime and Assert questions

From: Venugopal Hemige <[email-masked]>
Date: Fri, 9 Jul 2004 11:44:41 -0700 (PDT)

I have noticed a couple of issues with the spec and need some clarification:
 
1. Hello HoldTime:
 
In section 4.3.2, neighbor.timeout is defined to be Hello_HoldTime whenever it is present in the received hello, or Default_Hello_Holdtime if the Hello message does not contain the Holdtime option.
 
In section 4.10.2 (last para of this section), it says that "Holdtime option MUST be implemented".
 
It is a bit confusing to interpret from this what the receiving router should do. Section 4.10.2 leads me to believe that the receiving router should not form an adjacency if the option is not present. Section 4.3.2 says the opposite. What is the expected behavior here?
 
2. Assert cancel received on RPF-interface.
 
If there were an assert situation on the RPF-interface, the interface will be in assert-loser state. Could-Assert would be FALSE on the RPF-interface. So our interface metric to the source will be infinite-metric. If an assert cancel is received from the assert-winner, per the current definition of inferior/preferred/acceptable metrics, it will be treated as an acceptable metric. So the RPF-interface would remain in assert-loser state and retain the wrong upstream neighbor as RPF-neighbor, while infact it should have transitioned to assert-no-info.
 
I think "inferior metric" should be defined to as a metric lower than my metric OR infinite-metric. That should take care of it. Comments?
 
Regards,
-Venu

---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim