Subject: RE: [pim] FW: [Pim-mib] PIM-DM

From: "Nicholas, Jonathan - ACD " <[email-masked]>
Date: Mon, 14 Nov 2005 13:16:41 -0500

To answer in order:

DM-only fields in a separate conformance group is OK with me.

I altered field numbering from the current draft (-04) as I was editing
to see what was needed for PIM-DM and neglected to changed them back.
Hindsight indicates I shouldn't have changed them at all - if it helps
you, I can resend with original numbering.  I tried to keep changes to a
minimum.  To be honest, I could have included a PIM-DM reference to a
largish number of other objects that have the same functionality in both
SM and DM (e.g. the entire neighbor table), but decided that could be
discussed later.

I am sure these are all the changes needed for RFC 3973.  You've done a
great job and most of the interface table, neighbor table, SG table and
SGI table can be used without any changes beyond a possible DM
reference.  I do have some minor issues that relate to a "choose A or B"
that I want to discuss if we go forward with these additional items more
or less as is.  I don't particularly care about the answer, but thought
they should be brought up in case someone did care.

Jonathan Nicholas

> -----Original Message-----
> From: David McWalter [mailto:[email-masked]] 
> Sent: Monday, November 14, 2005 11:52 AM
> To: Nicholas, Jonathan - ACD 
> Cc: [email-masked]
> Subject: RE: [pim] FW: [Pim-mib] PIM-DM
> 
> 
> Jonathan,
> 
> Thanks for being so clear.
> 
> I have three remaining worries about including DM in PIM MIB.
> -  Causing confusion by adding DM fields and text.
> -  Review/feedback on DM fields holding up PIM MIB standardization.
> -  IESG process hassles (normative reference to experimental 
> RFC not usually allowed).
> 
> Thinking about these in turn:
> 
> -  I can put the DM-only fields in a separate conformance 
> group, so not much burden on other PIM implementers.
> 
> -  Your text looks good and clear, but your field numbering 
> doesn't fit with pim-mib-v2-03 or pim-mib-v2-04.  It's not a 
> problem for me to merge it, but I wonder whether you've 
> looked at the most recent draft?  Might any of the new -04 
> objects cause problems for DM, or require additional DM text?
> 
> -  Bill Fenner answered the third point at IETF 63 - we can 
> work around this if DM requires only a small set of changes.  
> So it comes down to the same question: Are you sure that 
> these changes are all we need for DM?
> 
> 
> If anyone else has concerns about including DM in PIM MIB, 
> please let me know.
> 
> David McW.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Nicholas, Jonathan - ACD 
> Sent: 14 November 2005 06:39
> To: [email-masked]
> Subject: [pim] FW: [Pim-mib] PIM-DM
> 
> 
> 
> All,
> 
> Below are the thirteen objects in the PIM MIB I think would 
> need to be added/modified to accomodate PIM-DM.  Given that 
> only 13 objects are needed I think they should go in the PIM 
> MIB rather than have a separate MIB for PIM-DM.
> 
> pimKeepalivePeriod OBJECT-TYPE
>     SYNTAX     Unsigned32 (0..65535)
>     UNITS      "seconds"
>     MAX-ACCESS read-write
>     STATUS     current
>     DESCRIPTION
>             "The duration of the Keepalive Timer.  This is the period
>             during which the PIM router will maintain (S,G) 
> state in the
>             absence of explicit (S,G) local membership or (S,G) join
>             messages received to maintain it.  This timer period is
>             called the Keepalive_Period in the PIM-SM specification.
>             It is called the SourceLifetime in the PIM-DM 
> specification."
>     REFERENCE "I-D.ietf-pim-sm-v2-new section 4.11"
>     DEFVAL { 210 }
>     ::= { pim 14 }
> 
> pimRefreshInterval OBJECT-TYPE
>     SYNTAX     Unsigned32 (0..65535)
>     UNITS      "seconds"
>     MAX-ACCESS read-write
>     STATUS     current
>     DESCRIPTION
>             "The interval between successive State Refresh 
> messages sent
>             by an Originator.  This timer period is called the
> 
>             RefreshInterval in the PIM-DM specification."
>     REFERENCE "RFC 3973 section 4.8"
>     DEFVAL { 60 }
>     ::= { pim 16 }
> 
> pimInterfacePruneLimitInterval OBJECT-TYPE
>     SYNTAX     Unsigned32 (0..65535)
>     UNITS      "seconds"
>     MAX-ACCESS read-create
>     STATUS     current
>     DESCRIPTION
>             "The minimum interval that must transpire between two
>             successive Prunes sent by a router.  This object 
> corresponds to
>             the 't_limit' timer value defined in the PIM-DM
>             specification."
>     REFERENCE "RFC 3973 section 4.8"
>     DEFVAL { 60 }
>     ::= { pimInterfaceEntry 9 }
> 
> pimInterfaceGraftRetryInterval OBJECT-TYPE
>     SYNTAX     Unsigned32 (0..65535)
>     UNITS      "seconds"
>     MAX-ACCESS read-create
>     STATUS     current
>     DESCRIPTION
>             "The minimum interval that must transpire between two
>             successive Grafts sent by a router.  This object 
> corresponds to
>             the 'Graft_Retry_Period' timer value defined in the PIM-DM
>             specification."
>     REFERENCE "RFC 3973 section 4.8"
>     DEFVAL { 3 }
>     ::= { pimInterfaceEntry 10 }
> 
> pimInterfaceJoinPruneHoldtime OBJECT-TYPE
>     SYNTAX     Unsigned32 (0..65535)
>     UNITS      "seconds"
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "The value inserted into the Holdtime field of a PIM
>             Join/Prune message sent on this interface.  A 
> value of 65535
>             represents an 'infinite' holdtime.  PIM-SM 
> implementations are
>             recommended to use a holdtime that is 3.5 times 
> the value of
>             pimInterfaceJoinPruneInterval, or 65535 if
>             pimInterfaceJoinPruneInterval is set to zero.  PIM-DM
>             implementations are recommended to use the value of
>             pimInterfacePruneLimitInterval."
>     DEFVAL { 210 }
>     ::= { pimInterfaceEntry 13 }
> 
> pimInterfaceSRPriorityEnabled OBJECT-TYPE
>     SYNTAX     TruthValue
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "Evaluates to TRUE if all routers on this interface are
>             using the State Refresh option."
>     ::= { pimInterfaceEntry 24 }
> 
> pimNeighborSRCapable OBJECT-TYPE
>     SYNTAX     TruthValue
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "Evaluates to TRUE if this neighbor is using the
>             State Refresh Capable option."
>     ::= { pimNeighborEntry 15 }
> 
> pimSGUpstreamPruneState OBJECT-TYPE
>     SYNTAX     INTEGER {
>                   forwarding (1),
>                   ackpending (2),
>                   pruned (3)
>                }
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "Whether the local router has pruned itself from 
> the tree. This
>             corresponds to the state of the upstream prune 
> (S,G) state machine
>             in the PIM-DM specification."
>     REFERENCE "RFC 3973 section 4.4.1"
>     ::= { pimSGEntry 7 }
> 
> pimSGUpstreamPruneLimitTimer OBJECT-TYPE
>     SYNTAX     TimeTicks
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "The time remaining before the local router may send a
>             (S,G) Prune message on pimSGRPFIfIndex.  This timer
>             is called the (S,G) Prune Limit Timer in the PIM-DM
>             specification.  This object is zero if the timer is not
>             running."
>     REFERENCE "RFC 2973 section 4.8"
>     ::= { pimSGEntry 9 }
> 
> pimSGOriginatorState OBJECT-TYPE
>     SYNTAX     INTEGER {
>                   notOriginator (1),
>                   originator (2)
>                }
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "Whether the router is an originator for an (S,G) 
> message flow. 
> 
>             This corresponds to the state of the per-(S,G) 
> Originator state
>             machine in the PIM-DM specification."
>     REFERENCE "RFC 3973 section 4.5.2"
>     ::= { pimSGEntry 25 }
> 
> pimSGSourceActiveTimer OBJECT-TYPE
>     SYNTAX     TimeTicks
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "If pimSGOriginatorState is 'originator', this is the time
>             remaining before the local router reverts to a 
> notOriginator
>             state.  Otherwise, this is zero.  This timer is called
>             the Source Active Timer in the PIM-DM specification."
>     REFERENCE "RFC 3973 section 4.8"
>     ::= { pimSGEntry 26 }
> 
> pimSGStateRefreshTimer OBJECT-TYPE
>     SYNTAX     TimeTicks
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "If pimSGOriginatorState is 'originator', this is the time
>             remaining before the local router sends a State Refresh
>             message.  Otherwise, this is zero.  This timer is called
>             the State Refresh Timer in the PIM-DM specification."
>     REFERENCE "RFC 3973 section 4.8"
>     ::= { pimSGEntry 27 }
> 
> pimSGIJoinPruneState OBJECT-TYPE
>     SYNTAX     INTEGER {
>                   noInfo (1),
>                   join (2),
>                   prunePending (3),
>                   pruned (4)
>                }
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "The state resulting from (S,G) Join/Prune messages
>             received on this interface.  This corresponds to the state
>             of the downstream per-interface (S,G) state machine in the
>             PIM-SM and PIM-DM specifications."
>     REFERENCE "I-D.ietf-pim-sm-v2-new section 4.5.3 and RFC 
> 3973 section 4.4.2"
>     ::= { pimSGIEntry 4 }
> 
> pimSGIJoinPruneExpiryTimer OBJECT-TYPE
>     SYNTAX     TimeTicks
>     MAX-ACCESS read-only
>     STATUS     current
>     DESCRIPTION
>             "The time remaining before (S,G) Join or Prune 
> state for this
>             interface expires.  This timer is called the (S,G) Join
>             Expiry Timer in the PIM-SM specification.  It is 
> called the
> 
>             (S,G) Prune Timer in the PIM-DM specification.  
> This object is
>             zero if the timer is not running.  A value of 'FFFFFFFF'h
>             indicates an infinite expiry time."
>     REFERENCE "I-D.ietf-pim-sm-v2-new section 4.10 and RFC 
> 3973 section 4.8"
>     ::= { pimSGIEntry 6 }
> 
> 
> -----Original Message-----
> From: Nicholas, Jonathan - ACD
> 
> Sent: Friday, November 11, 2005 2:39 PM
> To: 'Tom Pusateri'; [email-masked]
> Subject: RE: [Pim-mib] PIM-DM
> 
> 
> Hello,
> 
> A half hour too late...
> 
> I have gone through the PIM MIB looking to add objects needed 
> for dense mode.
> 
> I found three objects that could be used by DM with slight 
> revision and added ten other objects.
> 
> That's it.  I don't think this really needs a seperate PIM DM MIB.
> 
> I have attached a redlined copy of what I think is needed as 
> a quick look.
> 
> Let me know if this is acceptable, or if people think a 
> seperate PIM DM MIB is really needed.
> 
> Jonathan Nicholas
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> 
> > [mailto:[email-masked]] On Behalf Of Tom Pusateri
> > Sent: Friday, November 11, 2005 2:07 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [Pim-mib] PIM-MIB mailing list closing down
> >
> 
> >
> 
> > We've come a long way since we started reworking the MIB and I think
> 
> > at this point, most of the discussion should include the 
> whole working
> 
> > group. Therefore, its time to close down the pim-mib mailing list.
> >
> 
> > All further discussion about the PIM MIB should take place 
> on the PIM
> 
> > mailing list ([email-masked]).
> >
> 
> > The archives will remain available for a long while in case anyone
> 
> > wants to peruse them. They can be found at:
> >
> 
http://www.mountain2sea.com/pipermail/pim-mib/

Thanks,
Tom
_______________________________________________
Pim-mib mailing list
[email-masked]
http://www.mountain2sea.com/mailman/listinfo/pim-mib

************************************
This e-mail and any files transmitted with it are proprietary and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail in error please notify the
sender. Please note that any views or opinions presented in this e-mail
are solely those of the author and do not necessarily represent those of
ITT Industries, Inc. The recipient should check this e-mail and any
attachments for the presence of viruses. ITT Industries accepts no
liability for any damage caused by any virus transmitted by this e-mail.
************************************

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

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

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 15 Nov 2005 08:05:54 +0530

Hi Jonathan,

    I think, some time back, we had decided to create another draft for
PIM-DM MIB. This was decided because we wanted to speed up the PIM MIB
standardization. This was the reason why we moved BSR stuff also out of
PIM MIB.

    But if we are sure that there won't be any more new objects coming
up other than what you mentioned in your mail, we can try to merge it
with current PIM MIB. But if there could be some more, we should create
another draft for this MIB.

    Lets find out what others have to say about it.

Thanks & Regards,
Bharat

> http://www.mountain2sea.com/pipermail/pim-mib/

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