The MPLS WG Archive

[jcucchiara@mindspring.com]

Hi Nurit,

I can understand you wanting this change, but that is why
we had working group last calls in June and an IETF last
call in Aug/Sep.  That is the opportunity for
folks to give their comments,  knowing that the MIB can only
have minor edits after that.   

The most minimal way I see to make this change (and this is
just my opinion) is:

* change the mplsTunnelMaxHops object to read-write
* agree upon a DEFVAL (default value upon startup, which can
   be set to a different value by an operator)
* add to the conformance statement that this may be supported
   as a read-only

So, in addition to making the object read-write, think it needs a 
DEFVAL, and this would need to be discussed and agreed upon by
the working group.   This is more than minor editing in my opinion.
I am in agreement with Loa and Tom and would like to see
the MIBs move forward.

  -Thanks, 
    -Joan

-----Original Message-----
From: Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>
Sent: Nov 12, 2003 11:25 AM
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, 
	Nurit Sprecher <nurit.sprecher@SeabridgeNetworks.com>, 
	cheenu@bloomberg.net, arunv@force10networks.com
Cc: mpls@UU.NET, ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops

Thanks Tom for responding me.
I understand that this is in a last call state, but this issue should be
addressed somehow? 
I am surprised that such an attribute that is provided to the CSPF algorithm
is not configurable. How can you determine its value? Hard-coded? Doesn't it
have to do with network topology?
I think it should be configurable and we should see how we could add it to
the draft.
Nurit.

-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Wednesday, November 12, 2003 18:14
To: 'Nurit Sprecher'; cheenu@bloomberg.net; arunv@force10networks.com
Cc: mpls@uu.net; ccamp@ops.ietf.org
Subject: RE: MPLS Tunnel Maximum Hops


>Any response to the bellow?

        The MIB is well past IETF last call, so
I don't believe we can make any further changes
at this time.

        --Tom



>Hi,
>I have a question  regarding the mplsTunnelMaxHops scalar that
>indicates the
>maximum number of hops that can be specified on each tunnel
>supported by the
>LSR.
>This scalar is a read only attribute but I can find it very
>useful to let
>configure it as well.
>One of the CSPF constraints is the maximum number of hops the
>LSP may follow
>through. The limitation on the maximum number for example can
>result from
>the maximum packet size when fragmentation is not supported.
>In such a case
>the maximum number of hops can depend on the network nature
>(numbered/unnumbered). Instead of hard coding it with the
>worst case number,
>let the network administrator, that is aware  of the network nature,
>configure it.
>Moreover, I think that the maximum hops should be configurable
>per tunnel.
>Thanks, Nurit.
>
>