Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr

From: Hans De Vleeschouwer A0 VR233 58223 <[email-masked]>
Date: Wed, 05 Jan 2000 17:58:00 +0100

Hi,

I am trying to work my way through the  the ISIS MIB defintion.

In doing so, I have a question wrt the field isisManAreaAddr in the mib
table IsisManAreaAddrEntryTable:

Does this field contain only the area address, or does it also include
the actual systemid (i.e. the full NET)?

From the description field, I would assume that only the area id is
included, however this seems to be contradicted by looking at its type
defintion (being OSINSAddress).

Any help is kindly appreciated.

Kind regards,
  hans.

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Wed, 5 Jan 2000 13:11:27 -0500

> Any help is kindly appreciated.

Hans -
	It is only the area portion.  I could add another type
parallel to the OSINSAddress, but this is the orginal form,
and it holds exactly what is needed.  

- jeff parker

isisManAreaAddr OBJECT-TYPE
    SYNTAX OSINSAddress
    MAX-ACCESS read-only
    STATUS current
    DESCRIPTION
        "A manually configured area address for this system. This
        object follows the index behaviour."
::= { isisManAreaAddrEntry 2 }

---

From: Jeff Parker <[email-masked]>
Date: Fri, 7 Jan 2000 09:42:15 -0500

> Hi Jeff,
> 
> Thanks for your reply.
> 
> I am really going through the MIB field by field now.
...
>  I am not quite sure whether I can contact you with those directly, or
> wether I should keep on posting them to the newsgroup?

Hans -
	If you think it isn't of general interest, you might
send it only to me.  I would rather see traffic to the list,
for the selfish reason that I will need at some point to 
make the case that there has been public comment on the draft.
It may also serve to keep me honest.  Thus I'm going to copy
the list on this reply.  

> In the mean time I came upon with another  question related to the
> field isisSysMaxAreaAddresses in the isisSysTable.
> 
> The MIB indicates that the value of this field ranges between 
> 0 and 254.

To be honest, this value is 3.  
It is 3 in all existing implementations, and it is 
a show stopper if two implementations don't agree.   

My ToDo list (see below) has the line

	isisSysMaxAreaAddresses should be 1..3, not 0..254

You could argue that it should be 3..3 instead.

My current ToDo list includes the following items:
I do intend to rev the draft this millennium.  

- jeff parker

isisL2SummAddrTable
    isisL2SummAddrOperState change to AdminState

    The table name should change to IsisSummAddr instead of IsisL2SummAddr
    Cisco supports summarization at level-1 also and we have
    implemented an extended OperState to add this capability

Remove isisCircManL2Only - replaced by isisCircLevel

CircOperstate should be read-only

Only isisCircISISL2HelloMultiplier - should be 2, or one, or none.

isisSysMaxAreaAddresses should be 1..3, not 0..254

What is the story with IS(2) vs L1 and L2 below?

 isisISAdjNeighSysType OBJECT-TYPE
     SYNTAX INTEGER {
         unknown(1),
         intermediateSystem(3),
         l1IntermediateSystem(4),
         l2IntermediateSystem(5)
         }
     MAX-ACCESS read-only
     STATUS current
     DESCRIPTION
         "The type of the neighboring system."
     REFERENCE "{ISIS.aoi neighbourSystemType (80)}"
 ::= { isisISAdjEntry 6 }

Don't use IP addresses as index - summary table and IP reach table

Split off optional parameters

Overload bit

Compliance - grouping

Add boolean to mark L2 to L1 leaking

Add Auth Type for MD5
    Auth key will need to be a table (Rx values)

Clarify UpTime

---

From: Jeff Parker <[email-masked]>
Date: Fri, 7 Jan 2000 15:20:30 -0500

What is at stake is the maximum -allowed- (isisSysMaxAreaAddresses)
not the number of entries in use (the size of isisManAreaAddrTable.)

While a size of 0, 1, 2, or 3 are conceivable for this table, 
I hope we can agree that we wouldn't want a router that didn't 
allow the user to include 3 Manual Areas, if the user is so foolish 
as to want that.

I did notice the following MIB variable, which suggests I was
hasty in calling this a show stopper (see isisSysMaxAreaCheck)

The conclusion I will draw from this is that existing practice
allows the variable be 3..255.  

- jeff parker

isisSysMaxAreaCheck OBJECT-TYPE
    SYNTAX TruthValue
    MAX-ACCESS read-write
    STATUS current
    DESCRIPTION
        "When on, enables checking of maximum area
        addresses per IS version of ISO10589."
    DEFVAL { 1 }
::= { isisSysEntry 36 }

[Messages edited]

> Why can't this be 0 ? Do you need at least one manual area address for
> L2-only router also?  To me, it seems that
> isisSysMaxAreaAddresses can be 0..X.
> 
> Rajesh
>  
> > > > > To be honest, [isisSysMaxAreaAddresses] is 3.
> > > > > Jeff Parker
> > > >   Just for the record, in IOS, since about a year, you 
> > > >   can configure isisSysMaxAreaAddresses 3..254. 
> > > >
> > > >   Henk Smit
> >
> > The Avici TSR supports 1..255 area addresses.
> >
> > Matt Kontoff

---

From: Jeff Parker <[email-masked]>
Date: Sun, 9 Jan 2000 13:35:52 -0500

While I don't want to claim I understand exactly what Cisco is
trying to do, and while I haven't seen any documentation of
what Avici is trying to do, I suspect the issue is supporting
multiple L1 domains on a single router, not supporting multiple
areas in a single domain.  

That is, I suspect that each of the L1 domains has a single
area address: perhaps 2 when needed, and it may wish to 
implement upto 3.  I don't think anyone is talking about
recognizing 254 different Areas in the same domain.  

I would rather capture this as different SysInstances, each
running with a different area address, which can then 
summarize the collection of routes learned into a common L2.  

I will try to clarify the language surrounding 
isisSysMaxAreaAddresses, to make clear that this is
the Maximum Area Addresses in one Domain.  A name
change may help that effort.  

- jeff parker

> At 15:42 07/01/2000 -0500, Radia Perlman - Boston Center for 
> Networking wrote:
> >The reason it's nice to allow more than one area address is 
> to be able
> >to merge or split up areas while the net's running. To merge A and B,
> >add B as an allowable address to A, and A to B, and then 
> when everyone
> >agrees on both names, then one by one turn off one of the addresses.
> >There's really no reason to need 3 -- 2 suffices but 3 seemed
> >like a good idea at the time, maybe so you could simultaneously merge
> >3 areas, or perhaps it allowed you to be lazy about removing an area
> >address for awhile, but certainly there's no reason to
> >need 107 area addresses!
> 
> It was to do with DECnet Phase IV compatibility Radia. 
> Typically an area 
> would have two area addresses, a Phaseiv compatible one, and 
> a real OSI 
> one. So that makes two. Now if you want to merge/split the 
> OSI area you 
> need another one. I think that was the argument anyway.
> 
>          Mike
> 
> ps. and yes I think a value other than 3 is silly too.

---

From: Mike Shand <[email-masked]>
Date: Mon, 10 Jan 2000 08:28:53 +0000

>areas in a single domain.

The two issues are pretty much orthogonal. The former is useful; the latter 
is not.

         Mike