Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt

From: Jeff Parker <[email-masked]>
Date: Fri, 21 Dec 2001 12:20:51 -0500

> Jeff,
> 
> I had a few doubts/suggestion to make regarding the draft. 
 
Thanks.  I am forwarding to the list to keep the WG posted
on the changes you have suggested.  The letter ends with
a current list of 07 changes and my todo list.  

> 1. The isisAreaAddr description given in the overview section 
> is not clear.
> I think it should be mentioned area addresses in Level 1 
> LSP's, else first
> reading it gets confused with isisISAdjAreaAddr.

I'm not sure what you are suggesting here.  The MIB 
currently includes the following introduction

	-- The Level 1 Area Address Table

	-- The Level 1 Area Address Table contains the
	-- union of the sets of area addresses reported in all Level 1
	-- LSPs received by this Intermediate System.

Are you suggesting this is too much or too little?
If too little, could you provide suggested text?

> 2. What is the default behaviour of isisSysType?
> May be L1/L2 would be the desired default behaviour.

Good idea.  Done

> 3. Shouldn't isisSysMaxLSPGenInt be less than MaxAge(1200). 
> May be we could
> define a texual convention for this and declare for both 
> isisSysMaxLSPGenInt
> and isisMinLSPGenInt.

While MaxAge is specified in the protocol, there are vendors
who do not restrict the lifetime of the LSPs to this value.

> 4. isisSysMaxAreaAddress shouldnt a value of 0 be accepted too. It is
> regarded to be equiv to 3 right?

In a PDU on the wire MaxArea 0 means 3.  
I see no reason to preserve this behavior in the MIB.  

> 5. What abt packets dropped due to differences in authType.

I have added a new notification and a new counter

> 6. What does isisSummAddrAdminState signify(does it signify 
> from or to) ie
> when it is L1, is the table used to summarize to or from the L1?

I have added text.  See if it is clearer now.

> 7. In the isisCirc table, we have no isisCircentry9 - 13. 
> Guess its a typo?

Fixed.

> 8. What does functional multicast address mean?

You are asking about the definition of the object below.

I have no idea what this is about, and have done a quick
pass through 10589 without enlightenment.  Is there someone
out there who can shed light on this?  

     isisCircMCAddr OBJECT-TYPE
         SYNTAX INTEGER{
             group (1),
             functional (2)
             }
         MAX-ACCESS read-create
         STATUS current
         DESCRIPTION
             "Specifies which type of multicast address will
             be used for sending HELLO PDUs on this
             circuit."
         DEFVAL { group }
     ::= { isisCircEntry 16 }

> 
> 9. Wouldnt it be nice to keep a count of External routes, L1 
> routes , L2
> routes. Or may be how many of TLV 128 and how many 130? I am 
> just trying to
> draw a parallel with OSPF.

I have added to my todo list.  I won't try to add them this morning.  
 
> 10. What is the summary area-default metric. I feel thats not 
> required. If
> it matches more than one dest we can have the min cost of al 
> the dest it
> encompasses. Shldnt there be another field to tell when summ 
> area default
> metric is to be used, if thats required?

The term Default has an unusaul meaning in the protocol.  
I have removed "default" and "Def" from the names of metrics
where they appear, and added text to better describe the meaning
of "DefaultMetric" in ISIS.  The DefaultMetric TC is left as is.

> 11. What does isisSysL1state and SysL2 state OFF mean? What 
> is the relation to isisSysSetOverload?(If any)
> 
> Thanks,
> Vishwas

There is a notion of an overload bit which is used to signal
that a router is low on memory, and thus not to be trusted.

In OSPF, we don't use a router as a transit node until it has
finished the DataBase exchange.  In ISIS, some implementations
allow the administrator to bring up the router with the overload
bit set for a given time period.  This gives the router a 
chance to become synchronized.  

I have added text to the isisSysL1State and L2State definitions:
see if that makes things clearer.  

Vishwas -

I will send you a new copy of version 07, with the changes noted
below for your review.  I'm always happy to send out a current 
version of the mib for review.  

I will try to sort out the traps on Protocol Supported before
sending version 07 to the IETF.  

- jeff parker
- axiowave networks.  

-- Changes in version 07.
--      Added TE variables suggested by Satish Dattatri
--      Added traps culled from
--              Alarms in 10589
--              MTU Mismatch (Len G.)
--              Auth vailuer  (Vishwas)
--      Importing Inet definitions from INET-ADDRESS-MIB
--      Clarify the handling of isisManAreaAddrExistState
--      Removed isisCircLevelCircID: duplicates isisCircPtToPtCircID
--      Added UNITS clauses for timers and frame counters
--      Added default value for isisSysType
--      Added system counter isisSysAuthTypeFails
--      Revised numbering in isisCircTable
--      Removed the use of "Default" in definitions of metrics
--              To easy to confuse with the metric to be used by default
--      Added text to describe behavior of isisSysL1State and L2State

ToDo List
        Add timer between SPF computations
        The Hello Timer is measured in Milliseconds, but
                the HoldTimer for the Adjacency is measured in seconds.
                Change to milleseconds? 1
        Add trap for PLSP with no Protocol Supported TLV
        Add trap for LSP with no matching ProtSupported Flag
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Fri, 21 Dec 2001 16:00:27 -0500

> Even if today, ISIS routers tend to be L1+L2, does that mean
> we should make it the default?  Shouldn't we be encouraging
> the proper, hierarchical deployment?  Or am I missing something?

Jeff -
	Good point.  I'll accept your proposal.  

> Furthermore, MaxAge is a very reasonable default setting for this
> parameter.  Increasing it increases the load, but with the advantage
> only that certain relatively rare problems are corrected sooner.

Right.  Vishwas' suggestion was not to change the default,
but to change the permissible range.  I will leave that 
unchanged, as 

     isisSysMaxLSPGenInt OBJECT-TYPE
         SYNTAX Integer32 (1..65535)

The DEFVAL of isisSysMaxLSPGenInt has been 900 seconds all along.  
 
> It would be reasonable if we wanted a way to force 0 or 3 to be used
> in the PDUs.  This would only be valuable because of a problem in
> some router, I suppose.  I don't feel strongly on this, just my $0.02.
> 
> Regards,
> Jeff

Interesting point, but if we need this functionality, I would
rather create a new knob for this, rather than encoding it
in some behavoir that you will have to explain to folks for
the next 20 years.

Anyone who needs to control the generation of 0 vs 3 for MaxArea?

- jeff parker

---

From: Jeff Learman <[email-masked]>
Date: Fri, 21 Dec 2001 16:50:06 -0500

OK.  Agreed.

---

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 26 Dec 2001 04:52:39 -0500

Jeff,

Thanks for forwarding to the list(got useful comments there) and sorry for
the delayed response, have not checked my mails for some time. Comments
inline prefixed by a VM>.

Thanks,
Vishwas

VM> I was talking about the overview section, Section 4. At present it says

    - isisAreaAddr

       This table includes area addresses reported by peers.

    I thought it would be better if you clarifed this. It could say "area
addresses reported in Level 1 LSP's."

Regarding DEFVAL for SysType, does any vendor use any other default but
L1/L2? 

Also regarding the range for SysMaxLSPGenInt, MaxAge is given as an
architectural constant in document ISO-10589, section 7.3.21. So I guess
anyone who does not follow the MaxAge limit would not follow the new range
either(so no big deal). However setting the Max value of the range correctly
would not allow a wrong setting of SysMaxLSPGenInt in an implementation that
follows the architectural constants. Don't you think so? (A similar thing is
done in OSPF)

VM> Yes.

VM> Does it mean the value of 2, is not used at present?

VM>  Great !!! ;-)

VM> Good enough. 

> 11. What does isisSysL1state and SysL2state OFF mean? What 

VM> mmmmm.....I am still not very clear.(I understand overload bit and where
it could be used) So isisSysL1State should not be read-only then, if it is
settable. Also what do states "on"/"off"/"waiting" mean in this context?

Also I still did not understand the relation with the isisSysSetOverload
object. Aren't they related? If we set the SysL1State to say "on", wouldn't
a get on SysSetOverload state return a setL1Overload(I know the answer is
no, but i am trying to understand)? Why two diff objects?
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Thu, 27 Dec 2001 10:51:21 -0500

> The reason some vendors (correctly) use level-1/level-2 as 
> default is because a user can drop the router in any topology 
> which [and it will] work.
>
> - Naiming

Excellent point.

> In any case, though, will this draft really affect how any vendor's
> implementation will default?  Perhaps the default should be unspecified,
> since there are good arguments to go either way.  (On the other hand,
> this IS a standards group!)
> 
> [Jeff L]

I've seen a number of implementations that take an SNMP MIB
as -the- description of the default for CLI, DB, Web, or
whatever means you use to administer the box.  And others
will refer to the default values we define, if only as a
starting point.  So I do think it is worth getting this right.  

Here is one argument against the suggestion of a
default value of L1.  Since there is no way to have 
a default area, if L1 is the default, the administrator
must touch this 'region' of the configuration.  

I'm happy to return to L1L2.  Other opinions?

- jeff parker
- axiowave networks

---

From: Jeff Parker <[email-masked]>
Date: Thu, 27 Dec 2001 11:36:46 -0500

Thanks for your review comments.  I'm responding to the list.  

>     I thought it would be better if you clarifed this. It 
> could say "area addresses reported in Level 1 LSP's."

I cannot find a match for the strings above in the 07 mib.  
Perhaps you could give me a line number from the mib which
I will send you offline.  

> Regarding DEFVAL for SysType, does any vendor use any other 
> default but L1/L2? 

There has been a recent discussion of this on the list.  
One contributor is suggesting a value of L1.  

> architectural constant in document ISO-10589, section 7.3.21. 

ISO 10589 is an excellent document that reflected the experience
of it's authors when it was written.  Time moves on, and things
change.  

> So I guess anyone who does not follow the MaxAge limit 
> would not follow the new range either(so no big deal). 
> However setting the Max value of the range correctly
> would not allow a wrong setting of SysMaxLSPGenInt in an 
> implementation that follows the architectural constants. 
> Don't you think so? (A similar thing is done in OSPF)

I think it is important to have a default setting that respects
MaxAge, and we meet that today.  

The value of MaxAge is not currently a variable in the
MIB, and it is not part of the negotiation phase in adjacency
bring up: it does not appear on the wire.  Since this is an 
area or domain wide context, it isn't really clear how 
negotiation of this could take place.  We could add MaxAge
to the MIB, but I think what needs to be discussed is what
the right action should be upon the receipt of an LSP that
has a larger MaxAge than you support.  

> VM> Does it mean the value of 2, is not used at present?

I confess that I still have no idea what this controls.  
If no one else does either, I will phase it out.  

> Also I still did not understand the relation with the 
> isisSysSetOverload object. Aren't they related? If 
> we set the SysL1State to say "on", wouldn't
> a get on SysSetOverload state return a setL1Overload
> (I know the answer is no, but i am trying to understand)? 
> Why two diff objects?

I think I mispoke on this topic in my earlier private 
mail this morning.   

One is a gauge, one is a knob.  You don't use the 
speedometer in your car to accelerate: you use the 
gas pedal.  And if you are rolling down hill, the
position of the gas pedal may not reflect your speed.

The isisSysL1State tells you what state the system
is in, and is thus read-only.  isisSysSetOverload
is the knob you use to try to change things.  You
may try to bring the system out of Overload by 
setting isisSysSetOverload to overloadClear when 
the system is out of memory.  In that case, you 
expect the guage to move from wait to overloaded,
and you expect to continue to originate LSPs with
the O bit set.  

     isisSysL1State OBJECT-TYPE
         SYNTAX LevelState
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
             "The state of the Level 1 database.
              The value 'overloaded' indicates a database that is
              low on an essential resource, such as memory.
              The administrator may set the state to 'wait' when
              the router is initializing by setting the object
              isisSysSetOverload.
              If the state is waiting or overloaded, we
              originate LSPs with the Overload bit set."
         REFERENCE "{ISIS.aoi l1State (17)}"
     ::= { isisSysEntry 14 }

Let me know if this is any clearer.

- jeff parker
- axiowave networks

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 27 Dec 2001 12:15:56 -0500

Jeff,

Comments inline preceded by a VM>.

Thanks,
Vishwas

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

VM> Its in the overview section(section 4), just before the definition of
the MIB section(Section 5). I will send you a private mail about the line
number.

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

VM>Well as far as I know Jeff L. does not work on ISIS in his company(and
his views in his own words dont necessarily represent Cisco, which uses as
default L1/L2(or so their documents say)) ;-)

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

    
VM> This is exactly the reason why MaxAge needs to be same in all routers in
the domain. It also is an anomaly, where at one place we say MaxAge is arch.
constant and so not configurable, and other place we say it is not a
constant. 

Treating any LSP with age above Maxage could be done as if age was MaxAge.
May be we need to recommend that all routers in a domain have the same
Maxage(and the value of MaxLSPGenInt should be less than the value of the
smallest value of MaxAge in any router in the domain)value for things to
work ok(and then we can treat all LSP's with age greater than MaxAge as
MaxAge), we could raise a trap on getting an LSP with age greater than
MaxAge.
 
--------------------------------------

VM> Ok, though I am sure someone will have an idea.

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

VM> Yes, now it is clearer and I thought some thing like this though. ;-)
However I am not sure how the administrator could set the state to "wait".
Its a read only object(as pointed out in the private mail).

---

From: Jeff Parker <[email-masked]>
Date: Thu, 27 Dec 2001 12:16:17 -0500

I'm replying to the list.  I'd like to expose the requests
for change, so that others can react.  Witness the recent
discussion on the appropriate default system type.

> Also one more doubt. If you do go in for adding a table or 
> object for the
> number of TLV's of type 128 and 130. I guess we could also 
> have a couter for
> the number of TLV's with up/down bit set to 0 and same thing for 1.

I will add to the todo list.

> Also how about keeping a counter/trap when we get a mismatch in the
> configured MeshGroupEnabled i.e. getting an LSP even when the 
> circuit state is blocked.
> 
> Vishwas

Vishwas -
	One of the limitations of the mesh group idea is that
there is no way to check that the configuration makes sense,
and no way to know what configuration the far end has.  
So anything that would help catch errors would be welcome.  
But mesh state is not symetric.  You may be told not to speak,
but that doesn't mean you shouldn't listen.  As noted above, you
really don't know what state the other side is in.  

- jeff parker
- axiowave networks

---

From: Jeff Parker <[email-masked]>
Date: Thu, 27 Dec 2001 12:29:58 -0500

> VM>Well as far as I know Jeff L. does not work on ISIS in his 
> company(and his views in his own words dont necessarily 
> represent Cisco, which uses as default L1/L2(or so their 
> documents say)) ;-)

Jeff L. has presented arguments in favor of his position.
I think we need to read and respond to them, independent
of where he works and what his company does.   

> > The value of MaxAge is not currently ... in the MIB
 
> VM> This is exactly the reason why MaxAge needs to be same in 
> all routers in the domain. It also is an anomaly, where at 
> one place we say MaxAge is arch. constant and so not 
> configurable, and other place we say it is not a constant. 

The idea of a variable constant always makes me laugh.
I could add a value parallel to isisSysOrigL1LSPBuffSize.
However, I don't think we have really sorted out how such a
variable should be used.  I think dropping LSPs that are
larger than this has an adverse impact.  It could be used
as the largest value used on originated packets.  

> > One is a gauge, one is a knob.   
> 
> VM> Yes, now it is clearer and I thought some thing like this 
> though. ;-)  However I am not sure how the administrator 
> could set the state to "wait".  Its a read only object(as 
>pointed out in the private mail).

The administrator does not touch the gauge.  The administrator
touches the knob, setting isisSysSetOverload.  Please suggest
text changes that would make the following passages clearer on
this point.  

Your speedometer is read-only: the gas pedal is not.  

     isisSysL2State OBJECT-TYPE
         SYNTAX LevelState
         MAX-ACCESS read-only
         STATUS current
         DESCRIPTION
             "The state of the Level 2 database.
              The value 'overloaded' indicates a database that is
              low on an essential resource, such as memory.
              The administrator may set the state to 'wait' when
              the router is initializing by setting the object
              isisSysSetOverload.
              If the state is waiting or overloaded, we
              originate LSPs with the Overload bit set."
         REFERENCE "{ISIS.aoi l2State (28)}"
     ::= { isisSysEntry 24 }

and

     isisSysSetOverload OBJECT-TYPE
         SYNTAX INTEGER
                 {
                   setL1Overload(1),
                   setL2Overload(2),
                   setL1L2Overload(3),
                   overloadClear(4)
                 }
         MAX-ACCESS read-create
         STATUS current
         DESCRIPTION
             "Administratively set the overload bit for each level.
              The overload bit will continue to be set if the
              implementation runs out of memory, independent of
              this variable"
         DEFVAL {overloadClear }
     ::= { isisSysEntry 35 }

- jeff parker
- axiowave networks

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 27 Dec 2001 12:42:19 -0500

Jeff,

VM> I did not question the validity of the argument. The following was what
my initial question was. Does any vendor support a value other than L1/L2 as
DEFVAL?(May be I did not make myself too clear)

VM> Oops, sorry my fault now(I did not read carefully), the latest version
you sent is clear enough.

Thanks,
Vishwas

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 27 Dec 2001 12:45:56 -0500

Jeff,

Agreed, there is no way to negotiate the two ends configuration(we could
always add a TLV???). But doesn't Section 3a) RFC2973 mean that we prefer
mesh states are same at both ends. If we get an LSP via a blocked circuit,
doesn't it mean there is some config mismatch? Would it ever be required to
have a mismatch in the mesh states?

Also what should be done in case we get an LSP on a circuit C, where the
meshGroupEnabled attribute is blocked. Should we treat it similar to
meshGroupEnabled inactive state? 

Thanks,
Vishwas

---

From: Les Ginsberg <[email-masked]>
Date: Thu, 27 Dec 2001 13:00:33 -0800

> MaxAge), we could raise a trap on getting an LSP with age greater than

The change from an architectural constant to a configurable value was
presumably made based on customer demand. To require, or even suggest, that
an implementation treat an LSP received with a lifetime > the architectural
constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do.
Routers which did this could end up purging an LSP from their database
before the originating router's MaxLSPGenInt timer fired, which would cause
unnecessary flapping. If you want to argue that the current "de facto
standard" of making LSP lifetime configurable should be made invalid you
will at least be addressing the issue directly - though I suspect you will
get little support. Circumventing the issue by pretending the value is not
configurable is unwise.

It is also worth noting that, as you suggest, there is a necessary
relationship between LSP lifetime and MaxLSPGenInt, namely:

1)MaxLSPGenInt must be less than LSPlifetime
2)(LSPlifetime - MaxLSPGenInt) should be large enough to allow propagation
of the LSP throughout the area/domain before the old LSP ages out

If LSP lifetime is modified from the "default" value of 1200 seconds, it
makes sense to change MaxLSPGenInt in a like manner.

   Les

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 27 Dec 2001 23:15:28 -0500

Les,

I meant "remaining lifetime" field in the LSP and not age(wrong use of
terminology on my part).

So this is what I meant:-

1. If the remaining Lifetime is > MaxAge value in the router, treat the
remaining lifetime as if it was MaxAge.
2. MaxLSPGenInt should be less than min value of MaxAge for all routers in
the domain.
3. The difference(as pointed out) should be at least enough so that the LSP
is propagated thruout the domain(so that no one purges the LSP before the
new version reaches it).

Thanks,
Vishwas

-----Original Message-----
From: Les Ginsberg [mailto:[email-masked]]
Sent: Friday, December 28, 2001 2:31 AM
To: 'Manral, Vishwas'; 'Jeff Parker'
Cc: IS-IS-WG (E-mail)
Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt

   Les

---

From: Les Ginsberg <[email-masked]>
Date: Thu, 27 Dec 2001 20:59:12 -0800

Vishwas -

Makes no difference. From the point of view of the receiver of an LSP, it
has no way of knowing what the value of LSP lifetime may be on the
originating IS since the remaining lifetime field gets modified, based on
elapsed time, prior to flooding. All the receiver can say is that the
originating IS has a value for LSP lifetime which is >= the original
received remaining lifetime.

If an IS arbitrarily decreases the remaining lifetime of an LSP it has
received, then it is quite possible that the LSP will age out of the local
database before the originating router regenerates that LSP. The protocol
will eventually recover, but in order to do so the LSP will first be purged,
causing an SPF to be run on all routers (or many of them anyway) with this
LSP absent, and then the originating router will, on seeing the purged
version, regenerate that LSP, flood it, and a second SPF will be run on
every router. Reachability advertised in this LSP will temporarily disappear
from the forwarding databases throughout the area/domain and then be
restored. This is highly undesirable.

  Les