[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MPLS Tunnel Maximum Hops
>I am unclear why this object should be writeable.
I agree.
>As you imply, it is either something that you wish to control
>for each individual CSPF
>calculation (in which case it is a per tunnel instance
>configuration parameter) or it is a
>quality of the entire LSR and is applied to all LSPs.
>
>The current object was intended to reflect the capabilities of
>the LSR, not an operational
>requirement. Thus it cannot be changed by the operator.
>
>It would be a different thing if you want to change the LSR's
>CSPF behavior (compared with
>stating the LSR's capabilities).
>
>So *if* this was to advance I would say that it should either be:
>- a per tunnel instance object
>- a configuration parameter for CSPF.
>Personally, I do not see the requirement for the former, and
>the latter is clearly out of
>scope of the MPLS MIB modules.
>
>Note that there is an edge condition where you need to limit
>the size of ERO on some
>interfaces but not on others. In my view, this is a property
>of the interface which should
>be reported to CSPF direct, and not configured through the MPLS MIBs.
I agree. The only possible option would be to add
another object to reflect the configured value.
--Tom
>
>Cheers,
>Adrian
>
>----- Original Message -----
>From: "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>
>To: <jcucchiara@mindspring.com>; "Nurit Sprecher"
><nurit.sprecher@SeabridgeNetworks.com>;
><tnadeau@cisco.com>; <cheenu@bloomberg.net>;
><arunv@force10networks.com>
>Cc: <mpls@UU.NET>; <ccamp@ops.ietf.org>
>Sent: Wednesday, November 12, 2003 7:52 PM
>Subject: RE: MPLS Tunnel Maximum Hops
>
>
>> Hi Joan,
>> Thanks for the response.
>> 1. What is the procedure to push it to the standard right
>now when the draft
>> is in a last call?
>> 2. Do you agree that this should be configurable? Otherwise
>how can you
>> determine on the value?
>> 3. Do you agree that it may be required also to configure it
>per tunnel (but
>> have a default value)?
>> Until now I have just got e-mails on the procedure but not
>on the idea
>> itself.
>> I'll appreciate your response, Nurit.
>>
>>
>> -----Original Message-----
>> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
>> Sent: Wednesday, November 12, 2003 19:32
>> To: Nurit Sprecher; 'tnadeau@cisco.com'; Nurit Sprecher;
>> cheenu@bloomberg.net; arunv@force10networks.com
>> Cc: mpls@UU.NET; ccamp@ops.ietf.org
>> Subject: RE: MPLS Tunnel Maximum Hops
>>
>>
>> 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.
>> >
>> >
>>
>>
>
>