Subject: Re: PIM MIB table additions

From: [email-masked] (Billy Ng)
Date: Mon, 7 Jun 1999 22:50:55 -0400

> From [email-masked] Mon Jun  7 21:58:51 1999
> 

Bill,

I think this is only useful if you know for sure that only one interface
can have assert happening.  What if you have 10 different interfaces
and more than 1 of them are doing asserts at the same time?  How useful
would this mib be without (for example) indicating the upstream neighbor
address?  or am I missing something?

--Billy

> I'd like to propose adding the two following tables to the PIM MIB:
> the pimIpMRouteTable and the pimIpMRouteNextHopTable.  The
> pimIpMRouteTable augments the ipMRouteTable and contains several
> objects:
> 
> PimIpMRouteEntry ::= SEQUENCE {
>     pimIpMRouteUpstreamAssert        TruthValue,
>     pimIpMRouteUpstreamAssertTimer   TimeTicks,
>     pimIpMRouteAssertMetric          Integer32,
>     pimIpMRouteAssertRPTBit          TruthValue,
>     pimIpMRouteAssertMetricPref      Integer32,
>     pimIpMRouteSPTBit                TruthValue,
>     pimIpMRouteRPTBit                TruthValue
> }
> 
> Whether or not an Assert changed the RPF relationship is essential
> knowledge for debugging.  The first 5 objects deal with this.
> Whether or not the SPTBit or RPTBit are set on forwarding cache
> entries is essential to understand how a router is forwarding traffic,
> thus the final two entries.
> 
> The protocol does not require that a router remember anything more
> about an Assert on an upstream interface than that it occurred and
> when it expires; in particular there's no protocol reason to remember
> the Metric, RPTBit or MetricPref from the Assert.  These values
> are already remembered by one fairly common PIM implementation
> and are available via a vendor-specific MIB, so it's clearly possible
> to make them available.  However, the question remains whether to make
> them required or optional.
> 
> The pimIpMRouteNextHopTable augments the ipMRouteNextHopTable
> and contains only a single object:
> 
> PimIpMRouteNextHopEntry ::= SEQUENCE {
>     pimIpMRouteNextHopPruneReason       INTEGER
> }
> 
> This object indicates why the downstream interface was pruned -- in
> response to a Prune or an Assert.  Once again, there is no protocol
> reason to remember this information, but it is extremely useful for
> diagnostics.
> 
> Any comments are welcome.  The full text of the suggested additions
> is attached.
> 
>   Bill
>

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Mon, 07 Jun 1999 21:22:34 -0700

> and more than 1 of them are doing asserts at the same time?  How useful

The Assert information in question is UpstreamAssert, i.e. if the
upstream router were playing the Assert game. Because there is only
one upstream interface (*), hence you don't care about more than one
interface.

> address?  or am I missing something?

The upstream nbr address anyway must be known by the router because
it has to be included inside the J/P messages. I don't see any
reason not to include that address in the MIB.

Pavlin

(*) Upstream interface = interface toward RP and/or S: because
of Bidirectional-PIM, we should be careful about the difference
between incoming interface and upstream interface ;)