Subject: RE: [pim] Hello HoldTime and Assert questions

From: James Lingard <[email-masked]>
Date: Thu, 14 Oct 2004 20:33:43 +0100

All,

This post made to the mailing list in July seems never to have had any
responses; my thoughts are inline below.

I think that Venu has pointed out a genuine problem with infinite Assert
metrics, which ought to be addressed in the draft.  Does anyone else have
any thoughts on this?

Regards,
James.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Venugopal Hemige
Sent: 09 July 2004 19:45
To: [email-masked]
Subject: [pim] Hello HoldTime and Assert questions

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

My interpretation of this is that if a received Hello message contains the
Holdtime option, the receiving router MUST recognize and use the Holdtime
from that option, as described in section 4.3.2.  However, I don't think the
router should be prevented from forming an adjacency just because the Hello
message it receives doesn't contain the Holdtime option.

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

I agree with you that there is a problem here.  In addition, the definition
of Preferred and Acceptable metrics would need to exclude any infinite
metrics.

> Regards,
> -Venu

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