[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPLS Tunnel Maximum Hops

Nurit,

with my wg chair hat on :) - the way to push things to
standard  now is to write down the proposal in an ID
and have the wg to discuss it.

"Now" is a point in time when the other option - commenting
on a draft and have editors/authors change the ID, because
we have a set of mib modules in review and we don't want to
delay this review longer than necessary. To have the documents
out represents much more "good", than an update that would
respin the doc back into wg last call, especially since the
documents in review is heavily dependent on each other.

/Loa

Nurit Sprecher wrote:

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.