Subject: [Isis-wg] FW: IS-IS MIB (metric comments)

From: Jeff Parker <[email-masked]>
Date: Wed, 9 Oct 2002 12:33:27 -0400

A question about the validity of a metric of 0
arose this morning.  Digging through old mail,
I find the following request.

I'm open to suggestions.  Current version
allows a metric of 0 for both Wide and Classic.  

- jeff parker

--- On Tue 06/04, Jeff Parker  wrote:
From: Jeff Parker [mailto: [email-masked]]
To: [email-masked]
     Cc: [email-masked]
Date: Tue 06/04
Subject: RE: IS-IS MIB (metric comments)

...
> > In version 0.8 of the ISIS MIB, you have a Textual Convention
> > for DefaultMetric which is defined as (1..63).  Should we 
> > allow zero in the range, as our passive interfaces have a 
> > metric of zero.
> > ...
> > -don
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: mike shand <[email-masked]>
Date: Wed, 09 Oct 2002 17:47:06 +0100

Zero is OK for leaves, but its dangerous for links.

         Mike

---

From: Jeff Parker <[email-masked]>
Date: Wed, 9 Oct 2002 13:48:38 -0400

> Zero is OK for leaves, but its dangerous for links.
 
The TextualConventions DefaultMetric comes up in 
4 tables

	SummaryAddress
	CircuitLevelEntry
	IsisRAEntry (reachable Entry)
	IsisIPRAEntry (Imported route)

The results for the Wide Metric TC are similar.  
	
I could use a different textual convention
for Circuit, as that is the only way we would
get distance to a Neighbor.  However, passive
links get the distance to an IP net through
this same metric.   So I don't see any easy 
way to remove the conflict: it arises from 
the two uses of the Circuit Metric: for
IP nets and neighbors on active links, 
and for IP nets on passive links.  

Options

1) Split DefaultMetric into 
	CircDefaultMetric and rest.
	(though I don;t think this makes
	 any difference)
2) Add text on isisCircLevelMetric
	saying 0 is illegal unless passive
3) Add a new variable to be used only 
	for passive circuits (Now what 
	happens when we change from passive
	to active and the metrics don't match?)

I don't think that the third solution matches
what most people do here.  

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Wed, 9 Oct 2002 16:15:51 -0400

> I had suggested the change from 1 to zero, and now
> I'm agreeing that zero is not needed.  -don
 
Great.  I will have modified the metrics as below.

- jeff parker

    DefaultMetric ::= TEXTUAL-CONVENTION
        STATUS current
        DESCRIPTION
            "Integer sub-range for default metric for single hop.
             ISO 10589 provides for 4 types of metric.  Only the
             'default' metric is used in practice."
        SYNTAX Integer32 (1..63)

    WideMetric ::= TEXTUAL-CONVENTION
        STATUS current
        DESCRIPTION
            "Wide Metric for IS Neighbors.  ISO 10589 provides a 6 bit
metric.
             Traffic Engineering extensions provide 24 bit metrics."
        SYNTAX Integer32 (1..16777215)

---

From: "Tony Li" <[email-masked]>
Date: Thu, 10 Oct 2002 13:29:16 -0700

Don't we need metric zero for pseudo-nodes?

Tony

|   -----Original Message-----
|   From: Jeff Parker [mailto:[email-masked]]
|   Sent: Wednesday, October 09, 2002 10:49 AM
|   To: 'mike shand'
|   Cc: ISIS-WG (E-mail)
|   Subject: RE: [Isis-wg] FW: IS-IS MIB (metric comments)
|   
|   
|   > Zero is OK for leaves, but its dangerous for links.
|   > 
|   >          Mike
|    
|   The TextualConventions DefaultMetric comes up in 
|   4 tables
|   
|   	SummaryAddress
|   	CircuitLevelEntry
|   	IsisRAEntry (reachable Entry)
|   	IsisIPRAEntry (Imported route)
|   
|   The results for the Wide Metric TC are similar.  
|   	
|   I could use a different textual convention
|   for Circuit, as that is the only way we would
|   get distance to a Neighbor.  However, passive
|   links get the distance to an IP net through
|   this same metric.   So I don't see any easy 
|   way to remove the conflict: it arises from 
|   the two uses of the Circuit Metric: for
|   IP nets and neighbors on active links, 
|   and for IP nets on passive links.  
|   
|   Options
|   
|   1) Split DefaultMetric into 
|   	CircDefaultMetric and rest.
|   	(though I don;t think this makes
|   	 any difference)
|   2) Add text on isisCircLevelMetric
|   	saying 0 is illegal unless passive
|   3) Add a new variable to be used only 
|   	for passive circuits (Now what 
|   	happens when we change from passive
|   	to active and the metrics don't match?)
|   
|   I don't think that the third solution matches
|   what most people do here.  
|   
|   - jeff parker
|   _______________________________________________
|   Isis-wg mailing list
|   [email-masked]
|   https://www1.ietf.org/mailman/listinfo/isis-wg
|   _______________________________________________
|   Isis-wg-external mailing list
|   [email-masked]
|   http://mailist.procket.com/mailman/listinfo/isis-wg-external
|   
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Thu, 10 Oct 2002 16:36:08 -0400

> |   > Zero is OK for leaves, but its dangerous for links.
 
At issue is the "metric" command and equivalents.  
The resolution is to drop 0 from the range for this
class of parameters.  This won't prevent your 
implementation from slapping a 0 into the PN LSP:
it never consulted the circuit metric anyway.  

- jeff parker

---

From: "Tony Li" <[email-masked]>
Date: Thu, 10 Oct 2002 15:28:58 -0700

Then how does a MIB entry report the zero metric for
the pseudonode?

Tony

|   -----Original Message-----
|   From: Jeff Parker [mailto:[email-masked]]
|   Sent: Thursday, October 10, 2002 1:36 PM
|   To: Tony Li
|   Cc: ISIS-WG (E-mail)
|   Subject: RE: [Isis-wg] FW: IS-IS MIB (metric comments)
|   
|   
|    
|   > Don't we need metric zero for pseudo-nodes?
|   > 
|   > Tony
|    
|   > |   > Zero is OK for leaves, but its dangerous for links.
|   > |   > 
|   > |   >          Mike
|    
|   At issue is the "metric" command and equivalents.  
|   The resolution is to drop 0 from the range for this
|   class of parameters.  This won't prevent your 
|   implementation from slapping a 0 into the PN LSP:
|   it never consulted the circuit metric anyway.  
|   
|   - jeff parker
|   
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: stefano previdi <[email-masked]>
Date: Mon, 14 Oct 2002 18:12:18 +0200

On Monday 14 October 2002 16:37, Jeff Parker wrote:
> Stephano -
> 	I need to strike the balance between documenting
> what is there and trying to prevent people from doing 
> things which might be there, but are broken.

what I try to understand is why "reporting" a 0-metric in a mib is a problem. 
Taking the statement below:

	Since pseudonodes do not have any reachable addresses associated
	with themselves, there will be no entries in the isisRA or isisIPRA
	table with the pseudonode as an endpoint.  And since all non-
	pseudonode's will be reachable over a "transit" link that has
	a non-zero metric, all reachable addresses will have a non-zero
	metric associated with them.
	
	However, if anyone's implementation stores the metric to a 
	direct or a passive interface in either table as zero, then
	we will need zero in the range.  WG, does anyone do this?

now, I don't believe it's a problem if a passive interface has a 0-metric. 
This because we won't advertise any neighbor over a passive interface. The 
implementation I was referring to does advertise the IP prefix of passive  
interfaces with metric 0 but in no case you'll have a neighbor over it.

Also, I would tend to put into MIBs what a router allows to configure. If an 
implementation decides to allow 0-metric for neighbors, then the MIB should 
reflect this and it's under responsibility of the CLI to allow/disallow this.

s.

> 	Why don't you post your note below to the list,
> and see who pipes up.
> 
> - jeff parker
> - axiowave networks
> - Success is relative; the more success, the more relatives.
> 
>  
> 
> > -----Original Message-----
> > From: stefano previdi [mailto:[email-masked]]
> > Sent: Monday, October 14, 2002 10:35 AM
> > To: Jeff Parker
> > Subject: Re: [Isis-wg] FW: IS-IS MIB (metric comments)
> > 
> > 
> > On Monday 14 October 2002 16:23, Jeff Parker wrote:
> > > > but what is the problem of keeping 0 in range ?
> > > > 
> > > > s.
> > > 
> > > If we can advertise a neighbor as 0 distance, we can get loops.  
> > 
> > I think we're talking about MIB values, right ? 
> > So I suppose MIBs are intended to relfect the 
> > reality of something.... no matter what it is.
> > 
> > If 0-metric have been around for a while then MIBs 
> > should just ignore possible implication on algorithm 
> > outside the scope of SNMP MIBs....
> > 
> > s.
> > 
>

---

From: Jeff Parker <[email-masked]>
Date: Mon, 14 Oct 2002 12:17:35 -0400

> Taking the statement below:
 
Stephano -
	We don't split passive interfaces from other interfaces
in the MIB.  Thus, given the current design, if we allow a 0 
metric on a passive circuit, we are allowing a 0 metric on
any circuit, and thus allowing a 0-cost path to a neighbor.  
	We can add a warning that 0 should only be used when the
interface is passive, but it is not enforceable.  

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Tue, 15 Oct 2002 10:01:34 -0400

> > ] >... if we allow a 0 metric on a passive
> > ] >circuit, we are allowing a 0 metric on 
> > ] >any circuit...
> >
> > I think we should allow 0 to be inside the range.  
> >
> [I] tend to agree.... I don't think enforcing 
> strict ranges except brain-dead values buys
> much and causes trouble later  

I have changed the minimum on DefaultMetric
and WideMetric back to 0.  

I will be submitting the current version,
which has undergone many changes in the 
last 2 months, at the end of the week.
Drop me a line if you have the time and
interest in reviewing it.  Change log
below.  

- jeff parker

--  Changes in version 10
--      Add text to description of isisISAdjUsage
--      Change default on throttle for Neal Castagnoli
--      Rip out L1 and L2 objects from System and created SystemLevelTable
--          Numerous changes in text accompany this
--      Added isisIPRASourceType
--      Restore min of 0 to Metric Textual Conventions
--      Added SystemInstance variable to all notifications
--      Rerordered objects in notifications to be more predictable
--      Numerous edits from Dan Goodspeed
--          Added 0 to ISPriority range
--          Changed encoding of 'none' in ISLevel to 0, rather than 3
--          Replaced UpTime syntax with TimeTicks
--              Rewrote descriptions of CircUpTime and AdjUpTime
--              Rename variables to CircLastUpTime, AdjLastUpTime
--          Removed comments about deprecated groups
--          Edited description of isisCircEntry
--          Added References for MeshGroup and MeshGroupEnabled
--              Updated description
--          Remove L1 from isisSysStatLSPDbaseOloads description
--          Added isisCircNumAdj to count adjacencies on circuit
--          Added isisPacketCountUnknown
--          Removed LSPSize from isisAreaMismatch
--          Added isisPDUFragment to isisRejectedAdjacency
--              Updated description
--          Remove isisRAFullMetric
--          Changed indexing for isisIPRATable
--              Replaced SNPA in index with IPNextHop
--          Split isisISAdjNeighSysID into SysID and AdjExtendedCircID
--          Added boolean isisCirc3WayEnabled
--          Added isisISAdj3WayState, reordered enums in isisISAdjState
--          Drop range on isisSysMaxAge from 1200 to 350
--          Added isisSysSetOverloadUntil object
--          Added Adjacency Change notification
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg