Subject: [Isis-wg] Some concerns with draft standard IS-IS MIB

From: Myles Dear <[email-masked]>
Date: Mon, 21 Jul 2003 11:11:36 -0400

We are implementing the IS-IS protocol on a switch, and want to allow
managers to retrieve the list of configured NET addresses on the node.
We noticed that the current draft IS-IS MIB defines isisManAreaAddrTable
as "not-accessible".  Why was this table defined as "not-accessible"?

Furthermore, the type OSINSAddress states that it can be used to
represent a 
Network Entity Title.
The object isisManAreaAddr (which has type OSINSAddress) is defined to
only carry the area address.

There is an inconsistency here, since the NET of course carries both the
area address and the system ID.

Thanks,
<Myles Dear>

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

---

From: Jeff Parker <[email-masked]>
Date: Mon, 21 Jul 2003 11:50:12 -0400

Myles -
	I will take a look at the text describing a NET.

	"not-accessible" is a term that is used by the SNMP community for
indices.  The term is confusing when you first encounter it, but does not
prevent you from seeing the values.  You may want to take a look at Perkin's
"Understanding SNMP MIBs" for a explanation of the reasoning behind the
term.  

- jeff parker
- axiowave networks

> -----Original Message-----
> From: Myles Dear [mailto:[email-masked]]
> Sent: Monday, July 21, 2003 11:12 AM
> To: [email-masked]
> Subject: [Isis-wg] Some concerns with draft standard IS-IS MIB
> 
>

---

From: Jeff Learman <[email-masked]>
Date: Mon, 21 Jul 2003 12:17:27 -0400

At 11:50 AM 7/21/2003, Jeff Parker wrote:
>> There is an inconsistency here, since the NET of course 
>> carries both the area address and the system ID.

And the N-Selector, don't forget, which should be a single
octet of zero.

Also, be wary of playing "mix and match" with manual area addresses
and system IDs and expecting all implementations to work the same
if you try to use these addresses to send data.

ISO standards specifically forbid anyone outside the network layer
to play "mix and match" with address parts.  A conformant
implementation may or may not respond when sent data to an NSAP
that consists of an area ID plus system ID plus valid NSEL for
Transport on that system.

If you're using the NET to address for addressing PDUs to be
decapsulated, the rules may be different.  I believe there are
specific rules for addressing CLNP PDUs encapsulated in CLNP
for the purpose of partition repair -- you'd need to check ISO
10589, I don't remember off the top of my head.  There also may
be specific requirements for addressing (and what addresses a
system must accept) in Philip's document for auto-encapsulation.

Other than that, I don't know of any specific requirements for
addressing the network layer itself, and playing mix-and-match
isn't guaranteed to work.  It probably will, and it's more
likely than addressing Transport, but just be forewarned.

Jeff