Subject: [Isis-wg] Concerns about isisSysLevelTable in IS-IS MIB draft 16

From: Mike Bartlett <[email-masked]>
Date: Tue, 23 Nov 2004 16:06:03 -0000

Hi Jeff,

I have two concerns about the IS-IS MIB draft, revision 16.

1. I have a concern about the isisSysLevelMetricStyle object defined in the
isisSysLevelTable.

	    isisSysLevelMetricStyle OBJECT-TYPE
	        SYNTAX MetricStyle
	        MAX-ACCESS read-create
	        STATUS current
	        DESCRIPTION
	            "Which style of Metric do we generate in our LSPs
	             at this level? This object follows the
	             replaceOnlyWhileDisabled behavior."
	        DEFVAL { narrow }
	    ::= { isisSysLevelEntry 7 }

My concern is that the object follows replaceOnlyWhileDisabled behavior.
There does not seem to be any compelling reason for this behavior (which is
not shared by the related isisSysLevelSPFConsiders object), and it does not
fit well with the narrow->wide metric style migration defined as follows in
RFC3787 (section 5.1).

	   To facilitate a smooth transition between the use of narrow
metrics
	   exclusively to the use of wide metrics exclusively, the following
	   steps must be taken, in the order below.

	      (1)   All routers advertise Narrow Metrics as defined in ISO
	            10589, and consider narrow metrics only in their SPF
	            computation.

	      (2)   Each system is configured in turn to send wide metrics
as
	            well as narrow metrics.  The two metrics for the same
link
	            or IP prefix SHOULD agree.

	      (3)   When all systems are advertising wide metrics, make any
	            changes necessary on each system to consider Wide
Metrics
	            during the SPF, and change MaxPathMetric to 0xFE000000.

	      (4)   Each system is configured in turn to stop advertising
narrow
	            metrics.

	      (5)   When the network is only using wide metrics, metrics on
	            individual links may be rescaled to take advantage of
the
	            larger metric.

Taking these two documents together, every router must be deactivated and
reactivated twice (in steps 2 and 4) when migrating a network.  Even if the
routers are able to use graceful restart procedures, this seems like a large
and unnecessary overhead on the network as a whole.

I would therefore like the description for this object to say only 

			"Which style of Metric do we generate in our LSPs at
this level?".

----------------

2. I have a related (but more minor) concern about using the
replaceOnlyWhileDisabled behavior at all in object descriptions on the
isisSysLevelTable, because it does not really make sense here.  This affects
the isisSysLevelOrigLSPBuffSize object (and currently the
isisSysLevelMetricStyle object, though as stated above I hope this will
disappear anyway).

ReplaceOnlyWhileDisabled behavior is defined as follows.

			"This object may not be modified while the
corresponding table row's variable of type AdminState is in state on."

Usually the "corresponding table row" relates to the *same* MIB table
containing the object that the behavior relates to.  However, in this case,
the isisSysLevel table does not even have an AdminState variable.  While it
is fairly obvious that in this case the important variable is the AdminState
in the isisSystem table, this could probably be stated more clearly.  How
about the following text for the description of the
isisSysLevelOrigLSPBuffSize object?

			"The maximum size of LSPs and SNPs originated by
this Intermediate System at this level.  This object may not be modified
while the isisSysAdminState variable is in state 'on' for this Intermediate
System."

----------------

Please let me know what you think on these two points.

Many thanks,

Mike Bartlett

-------------------------------------------
Mike Bartlett
Network Protocols Group
Data Connection Ltd
Tel:	+44 20 8366 1177                 
Fax:	+44 20 8363 1039
Email:	[email-masked]    
Web:	http://www.dataconnection.com

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: "Parker, Jeff" <[email-masked]>
Date: Tue, 23 Nov 2004 11:32:57 -0500

Mike -
    Thanks for your note.  There have been a few other suggestions, and I
plan to respin shortly.  If anyone would like to review the changes before
they are resubmitted, I'd be happy to include them on the short list of
reviewers.  I will send out a list of deltas to the group.

- jeff parker

> fit well with the narrow->wide metric style migration defined as follows in

Depends on which bloke you choose to believe, I suppose.

I agree that there is no need to restart everything here, though there is
clearly the possibility that there will be major changes in the Route Table.

> Please let me know what you think on these two points.

I will fold in both suggestions.

- jeff parker