The MPLS WG Archive

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: vrijdag 13 december 2002 16:19
> To: Wijnen, Bert (Bert)
> Cc: Mpls (E-mail)
> Subject: RE: review of draft-ietf-mpls-te-mib-09.txt
> 
> 
> At 02:49 PM 12/13/2002 +0100, Wijnen, Bert (Bert) wrote:
> >Inline
> >
> > > -----Original Message-----
> > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > > Sent: maandag 9 december 2002 17:33
> > > To: Wijnen, Bert (Bert)
> > > Cc: Mpls (E-mail)
> > > Subject: Re: review of draft-ietf-mpls-te-mib-09.txt
> > >
> 
.. snip ..


> >Hope this helps.
> >
> >For the RowStatus, Good examples are again in for example rfc3289
> >     DESCRIPTION
> >        "The status of this conceptual row. All writable objects in this
> >        row may be modified at any time."
> >But then I see that in many cases you do NOT allow changes while the
> >row is active, so then it could be something aka:
> >
> >     DESCRIPTION
> >        "The status of this conceptual row. None of the writable objects
> >        in this row may be modified when this row is 'active'."
> >
> >Or if some can and some otehrs cannot, then for example something like
> >     DESCRIPTION
> >        "The status of this conceptual row. Writable objects a and b
> >        in this row may be modified at any time, but other wrietable
> >        objects in this row may not be modified when this row is 'active'."
> >
> >Now, be carefull, because when objects are not allowed to be modified when
> >the row is 'active', and when you specify (in MODULE COMPLIANCE) that
> >one only has to support createAndGo for the WRITE-SYNTAX, then people
> >cannot (in such an implementation) set the row to notInService, and
> >so that then means that changes to the row can only be made by
> >deleting (destroy) and recreating the rows.
> >
> >Does this help?
> 
>          Yes. I think that any object in the row may be modified
> (if the implementation supports it) only once the row is taken out
> of service.

That sounds confusing to me, cause... is "ou of service" the same
as putting a row into notInService? 
I believe in many cases you have made MODULE-COMPLIANCEs that do not
require support for that.

> This may require TE parameters to be re-signaled priori
> to the tunnelEntry returning to the operational state; however.
> Is something that describes that reasonable?
> 
See above. Not sure I understand what you are saying here.

> 
> >Hope I was clear on that. If not, let me know and I can propose
> >exact text and TCs to be specified and used.
> 
>          In general, I would appreciate it if you would propose
> wherever you can. I think that way we can get to satisfying your
> comments more quickly.
> 
But based on the example in RFC3289 you shoudl be able to come
up with the text no? I believe the FTN MIB has it close to that
already.

> >Also... you have the index (indices) included too. I understand you
> >want to do that... maybe you want to mark them with an asterisk or such
> >and then explain they are index/indices and so that they are not
> >separate varBinds in the SET PDU but that they make up the
> >index part of each object in the varBinds in the SET PDU.
> >Or some such.
> 
>          Isn't it implied that the indexes are required as part of
> the SET PDU when doing createAndGo style row creation?
> I think it is pretty common knowledge that by not sending
> down the indexes (and other required objects as stated in
> DESCRIPTION) that the creation will fail.  I didn't
> realize that we needed to be specific on this (which seems
> redundant).
> 
The INDEX objects are "not-accessible. So those objects do NOT
get send. Lost of people have trouble with that. It is probably caused
by the fact that in old SMIv1 they were accessible, and when someone
has an old SMIv1 MIB that has been converted to SMIv2, then we
allow INDEX objects to be still accessible.

So... it is not easy for people to understand what you mean.
Better be clear and explicit (or so I think).

> > > >- I ownder if mplsTunnelNotiMaxRate would be better named
> > > >   mplsTunnelNotiInterval
> > > >   May want to add a UNITS clause to this object anyway
> > > >   and why is it not named mplsTunnerNotificationInterval?
> > >
> > >          Looks like a typo.
> > >
Mmm.. a typo he? Oh well... whatever.

> > > >- mplsTunnelIndexNext
> > > >   well, same comment as to all the mplsXxxNext objects in the
> > > >   other MIB modules.
> > > >   But this one has even another strange thing, namely it is
> > > >   a Interger32 (as opposed to a Unsigned32) and it has a pretty
> > > >   limited range and for all I can tell for no good reason.
> > > >   In fact I see no reason for a upper limit.
> > >
> > >          It is supposed to match the indexing of the tunnel table.
> > >
I do not understand your answer.

> > > >- mplsTunnelEntry
> > > >   Why is there a reference to RFC1700 ??? That RFC has been
> > > >   obsoleted anyway...
> > > >- Can someone explain to me why you use the complex indexing
> > > >   scheme for the mplsTunnelTable, namely:
> > > >    INDEX {
> > > >       mplsTunnelIndexIndex,
> > > >       mplsTunnelInstance,
> > > >       mplsTunnelIngressLSRId,
> > > >       mplsTunnelEgressLSRId
> > > >    }
> > > >
> > > >   - first, I do not understand why it the 1st one is named
> > > >     mplsTunnelIndexIndex instead of just mplsTunnelIndex
> > >
> > >          Compiler complained because the type is MplsTunnelIndex.
> > >
It gave onlyh a warning I assume, this is to alert you to make sure
you did things correct.

> > > >   - 2nd, mplsTunnelIndexIndex claims to "uniquely" identify a row
> > > >     so then no more index objects seem needed
> > > >   - but mplsTunnelInstance seems to also "uniquely" identify a row??
> > > >   - and then there are yet more index objects.
> > > >   - mplsTunnelIngresLSRId, description talks about "this value".
> > > >     but the index object does not really have a value. It is part
> > > >     of the OID that identifies instances in the table.
> > > >   Why do I not understand this indexing scheme?
> > >
> > >          We went over this during the MIB meeting. This is basically
> > > just the RSVP-TE indexing required.
> > >
That is not a proper answer. I still do not understand,
I believe Marcus was asking about it too.
Pls repeat for me what we discussed/decided at the MIB meeting.
ANd probably if that explains it, some oif that text should go into
the document as MIB comments or in DESCRIPTION clauses.


> > > >   I think it would be good to include in the DESCRIPTION clause of
> > > >   either the mplsTunnleEntry or of the indices a very good explanation
> > > >   as to how the indexing works here.
> > >
> > >          Yes. We agreed to improve the description as an action
> > > from the MIB meeting.
> > >
OK, good.

> >OK, looking forward to that, hopefully I then understand.
> >Is it just me who does not understand? I doubt it in fact.
> 
>          No, the indexes have fairly thin descriptions right now
> and can be improved.
> 
Looking forward to that.

> > > >- I have trouble with the use of DisplaySTring (as mentioned half a year
> > > >   ago). These days we want people to use UTF8 based strings if the strings
> > > >   are intended for human use. So either SnmpAdminString or some other
> > > >   UTF8-based string. Several TCs have been defined to
> > > replace DisplayString
> > >
> > >          Yes, will use SnmpAdminString.
> > >
Good

> > > >- I wonder why the mplsTunnelName is ever to be equal to ifName.
> > > >   The link between an entry in the mplsTunnelTable and the ifTable is
> > > >   made by the mplsIfTunnelIndex which is the better way indeed to make
> > > >   the link.
> > >
> > >          The idea is that in cases where the tunnel is an ifEntry too,
> > > this makes sense so they are associated.
> > >
> >
> >And so when people do SET on ifName or on mplsTunnelName, then
> >the agent needs to make sure they stay in sync?
> >What if in one SET request (I will admit it is kind of stupid) one
> >send a SET for ifName of "abcd" and a SET for mplsTunnelName of "efgh"
> >I see all sorts of potential problems with this.
> >And is it the MIB who wants to presrcibe this?
> >I know thay ifName was meant for operators to use. So you are forcing
> >them to use same name for mplsTunnel, why can they not use
> >
> >   ifName :  Interface1 for MPLS
> >   mplsTunnelName : mpls Tunnel to Linschoten (this is where I live ;-))
> >
> >Oh well... I won't loose sleep over it.... I just wonder about
> >the complexities it may cause (for in mu view no good reason)
> 
>          I think it is common practice in the implementations 
> I know of
> to keep these the same.   The reason being that the ifType is
> for an mplsTunnel, so the entities are really one in the same (just
> the tunnel entry extends the ifIndex a bit).  I think that it 
> is a reasonable
> requirement that the agent SHOULD keep these values consistent.
> If it cannot, then let it be, but I think we should indicate that the
> best practice is to do so.
> 
I will leave this to teh WG

> > > >- It seems to me that mplsIfTunnelDescription could have a DEFVAL
> > > >   of the empty (zero lenght) string
> > > >- It seems to me that mplsTunnelIsIf and mplsTunnelIfIndex are overlapping.
> > > >   A value of zero in the mplsTunnelIfIndex means that this tunnel does
> > > >   not correspond to an interface. A nonzero value means that it does
> > > >   correspond to an interface. So why is mplsTunnelIsIf needed? So that
> > > >   people can have conflicting stuff that needs to be chacked and all that?
> > >
> > >          The idea is that you can quickly determine the type of
> > > tunnel. I suppose that we could eliminate this object and just
> > > state that if ifIndex = 0 that it is NOT an ifIndex.
> > >
> >Having 2 objects to represnt kind of the same thing always
> >adds complexity in terms of "what to do when they conflict"
> >or "how to make sure they stay in sync".
> >Is it just me who sees these type of concerns?
> 
>          I obviously agree that redundant objects should be
> removed.  However, after working on this document for 3 years
> it is hard to see things like this sometimes. *)  In any 
> event, I think
> this was a comment made during the MIB review meeting, and
>   I believe we agreed to remove the object.
> 
Good

> > > >- mplsTunnelSessionAttributes
> > > >   you may want to check the formatting in the DESCRIPTION clause
> > > >- mplsTunnelOwner is a read-only object and yet the description clause
> > > >   talks about that it cannot be modified when RowStatus is active.
> > > >   That seems redundant text. A read-only object can NEVER be changed
> > >
> > >          Again, this should be the same as that in the TC that we
> > > discussed (the agent sets this value).
> > >
> >Right... but pls remove the piece of text that says that it cannot
> >be changed when row is active, because that piece if nonsense and
> >confusing.
> 
>          Gotcha.
> 
Good

> 
> > > >- I see mplsTunnelHopTableIndex to be read-create while
> > > >   mplsTunnelARHopTableIndex and mplsTunnelCHopTableIndex are read-only
> > > >   Is that not strange?
> > >
> > >          Nope. The actual route hop table is what is spit out
> > > by the CSPF computation; not operator programmable.
> > >
> >Got you. Maybe say something about how it gets filled in,
> >and then people (like myself) might not need to wonder as much
> >Not everyone is an MPLS expert on all these things (think about
> >the (generic) apps developers we talked about in Atlanta. They
> >want to quickly understand it too.
> 
>          Okay, I will try to improve.
> 
Thanks

> > > >- I do not understand mplsTunnelPrimaryInstance, but that is
> > > >  probably linked to me not understanding the indexing scheme.
> > > >- mplsTunnelPathChanges
> > > >   s/paths has changed/path has changed/ or
> > > >   s/path has changed/paths have changed/ ??
> > > >- mplsTunnelTotalUptime
> > > >   so is this an aggregate value of multiple entries in this table?
> > >
> > >          This is the up time of all LSP instances of the tunnel.
> > >
> >That is not a clear answer to my question
> >My interpreation of your answer is that the answer is: YES
> 
>          Is this more clear: This is the uptime of all instances of
> the tunnel since its creation?  Perhaps an example might help.
> If the tunnel head creates an LSP at time T and it runs until
> T+n. At time T+n+2 a new LSP is signaled and lasts
> until T+n+5. This object would then be counted
> as (T+n) + ((T+n+5) - (T+n+2)).
> 
That helps. And so my question is, would the same value occur in
multiple entries. Again, I think the answer is YES, but you keep
giving other answers. 

> > > >   and if so of how many? Is that of all entries with the same
> > > >   mplsTunnelIndexIndex, or what?
> > >
> > >          Yes, the same group of tunnel instances (the same primary
> > > tunnel index).
> > >
> >First of all, it would be good to make that very clear in the
> >DESCRIPTION clauses. One can kind of conclude that, but it is
> >a very strange thing to see in a MIB table, so make it clear
> >that it is intentional.
> >
> >But it seems BAD to me.
> 
>          Why? During the meeting we had concluded that this was
> not a bad idea -- that it was pretty nice in fact. The only suggestion
> that came out of the meeting was that we make the indexing
> style/interpretation mandatory so that there was no confusion
> about grouping of tunnel heads with their instances.
> 
I guess I am still confused then. I will await the new rev to see
if the DESCRIPTION clauses help me understand.

> 
> > > >   And then... if there are 4 entries aggregated, do all 4 entries then
> > > >   have the same value?
> > > >   And what is the upTime of each entry?
> > >
> > >          mplsTunnelPrimaryTimeUp shows the time of the primary
> > > instance that this tunnel
> > >
> > >          mplsTunnelTotalUpTime is the aggregate time of all
> > > instances of this tunnel (head).
> > >
> > >          mplsTunnelInstanceUpTime is the time this instance has
> > > been up.
> > >
> >So you are again not answering my first question: do all 4
> >entries have the same value? And if so that looks BAD to me.
> >But maybe it is just me. Any other opinions?
> 
>          They have the same value on the tunnelEntry with
> instance = 0 (i.e.: the tunnel head). On other instances of
> the tunnel, primaryTimeUp/TotalUpTime might be set to
> that of the head entry (if possible).   TunnelInstanceUpTime
> will be different if more than one LSP has been used for
> the tunnel head.  If no instances exist, only the head does,
> and so those variables will only exist on the head entry.
> 
I guess I should give up.
If no one in the WG sees this as a problem or being bad,
then I will accept it is just me.

> > > >   I am confused here as to what the purpose of this object
> > > is and how
> > > >   it is computed. Under what circumstances would it "not be
> > > available"?
> > >
> > >          It might not be available if no instances exist for
> > > the tunnel. I suppose it might be simpler to just remove this
> > > text, but the thinking was that we specified an initial value
> > > for when no tunnel instances (other than 0) existed.
> > >
> >Or add the explanation as to when the condition can occur.
> >In general, whenever a independent (that is someone who was
> >not involved in the devlopment of the protocol and/or the MIB)
> >reviewer has a question in the form of "how does that work?" or
> >"Do I understand this and that (in)correctly?", then that often
> >indicates that it is a good idea to add explanatory text in
> >some of the DESCRIPTION clauses. So that not every new reader
> >needs to go to the mailing lists to ask the same questions
> 
>          Agreed. On the other hand, it is also a requirement in my
> mind that independents as you call them, read the protocol
> specifications to understand what they are going to manage
> using the MIBs.  I agree with you in this case, but
> in general, I think that people using the MIBs should be
> up to speed with how the protocol works so that when the
> MIB refers to a term like "tunnel head" that the MIB not
> need to define its meaning.  The MIB should not be a tutorial
> on how the protocol works that it is managing.
> 
Correct, but once should also not assume that people writing management
apps and people using the MIB modules will be as intimate with the
protocols as you are.

>          --Tom
> 
Bert