[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MPLS Tunnel Maximum Hops
Well, meanwhile I have talked to Adrian and explained to him why it is
required.
I definitely think that this should be configurable per tunnel. For
different tunnels I would like to limit the number of hops it may flow
through (from many reasons that I'll specify in a detailed mail next week)
and I would like to find the best route (using the CSPF) that can be
committed to this restriction. I believe that this limitation relates not
only to the LSR capability but also to the network topology and to the
tunnels constraints (for example the required latency, etc.).
Please note that even if it relates to the LSR capability, other LSRs that
have LSPs that flow via this LSR should be aware of this limitation,
otherwise we can meet many error conditions. This can be solved by
configuration.
I believe that in the multi area case, where loose nodes are involved, we
should signal this value as well, otherwise this value will not sustain any
more.
Anyway, I understand that I came with this late, and I'll have to push it in
the regular procedure.
Nurit.
-----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Thursday, November 13, 2003 01:12
To: 'Adrian Farrel'; 'Nurit Sprecher'; jcucchiara@mindspring.com;
cheenu@bloomberg.net; arunv@force10networks.com
Cc: mpls@UU.NET; ccamp@ops.ietf.org
Subject: 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.
>> >
>> >
>>
>>
>
>