Subject: subnets, VCs, and the IPOA MIB

From: Paul Koning <[email-masked]>
Date: Mon, 10 Nov 1997 14:50:09 -0500

I've been working on an IPOA implementation and keep tripping over
things involving the IPOA MIB.  It seems to me the MIB design contains
an assumption that is not appropriate.

In a number of places, the IPOA MIB (draft 4) seems to use an
underlying assumption that a VC is associated with a particular
subnet.  For example, ipoaLisActiveVcs, and the indexing defined for
the ipoaVcTable.

In IPOA, a VC connects two ATM end systems (two interfaces), carrying
any IPOA traffic between those two points regardless of subnet.  If
both endpoints have multiple (common) subnets defined for their
interface, then traffic for each of those will use the single VC.

So the only way I can see of doing what the MIB asks is to make a
given VC appear multiple times in the MIB, once for each subnet for
which it can be used.  For example, if I have one VC, I might have
ipoaLisActiveVcs == 1 for multiple LIS, and there would be multiple
entries in the ipoaVcTable (differing only in the
ipNetToMediaNetAddress value).

While this is doable, it doesn't seem all that useful.  I suppose it
might add a small amount of information in the ipoaVcTable case.  But
by combining the information about active VCs (without the
ipNetToMediaNetAddress index) with the LisIfMapping table, you get
essentially the same information.

	paul

-- 
!-----------------------------------------------------------------------
! Paul Koning, NI1D, C-24183
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: [email-masked]
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859

---

From: [email-masked]
Date: Tue, 11 Nov 97 08:43:53 EST

Paul,

>subnet.  For example, ipoaLisActiveVcs, and the indexing defined for

I don't agree. The IPOA-MIB is for classic2,
<draft-ion-ipatm-classic2-03.txt. Classic2 states on page 5:

  "o   End-to-end IP routing architecture stays the same.

   o   IP addresses are resolved to ATM addresses by use of an ATMARP
       service within the LIS - ATMARPs stay within the LIS.  From a
       client's perspective, the ATMARP architecture stays faithful to
       the basic ARP model presented in [3].

   o   One IP subnet is used for many hosts and routers. Each VC
       directly connects two IP members within the same LIS."

ipoaLisActiveVcs counts the number of active VCs per LIS. The
ipoaLisTable is indexed by subnet address.

The ipoaVcTable's first two indexes are the same as
the ARP Cache's, ipNetToMediaTable. Its last two indexes are the
vpi and vci of the VC associated with the entry. ipNetToMediaNetAddress
is an ip address not a subnet address.

>interface, then traffic for each of those will use the single VC.

These end systems are not acting as routers into non-ATM clouds are
they? If not then they could be defined as two members of the same
LIS. If they were routers then either network or subnet routes
would need to be defined to flow traffic correctly. Only the
"routers" would need to be in the same LIS. If a third end-system
would need access to one of the prior systems it could be configured
to be in the same LIS or a second LIS could be configured that one of
the first two participates in.

>ipNetToMediaNetAddress value).

No. PVCs are configured in the MIB, SVC are dynamically established
as need. VCs just don't appear in the MIB. I don't think you
understand the ipoaVcTable and its relation to the ARP Cache.

>essentially the same information.

Regards, Ken

---

From: Paul Koning <[email-masked]>
Date: Tue, 11 Nov 1997 11:27:02 -0500

>>>>> "kennethw" == kennethw  <[email-masked]> writes:

 kennethw> Paul,
 >> things involving the IPOA MIB.  It seems to me the MIB design
 >> contains an assumption that is not appropriate.

 >> subnet.  For example, ipoaLisActiveVcs, and the indexing defined
 >> for the ipoaVcTable.

 kennethw> I don't agree. The IPOA-MIB is for classic2,
 kennethw> <draft-ion-ipatm-classic2-03.txt. Classic2 states on page
 kennethw> 5:

 kennethw> "o End-to-end IP routing architecture stays the same.

 kennethw> o IP addresses are resolved to ATM addresses by use of an
 kennethw> ATMARP service within the LIS - ATMARPs stay within the
 kennethw> LIS.  From a client's perspective, the ATMARP architecture
 kennethw> stays faithful to the basic ARP model presented in [3].

 kennethw> o One IP subnet is used for many hosts and routers. Each VC
 kennethw> directly connects two IP members within the same LIS."

I don't believe it was ever the intent that two nodes, both having two
IP addresses defined for their ATM interface (which have different
subnet numbers) would have two VCs between them.  Certainly that's how
I understood Joel Halpern's response when I raised the question
(offline) a week or so ago.

If it were otherwise, one could make that work for the SVC case, but
the ConfigPvc table doesn't seem to provide a way to define two VCs
between a pair of nodes, one per subnet.  But I had always understood
the SVC rule to be: given an ATMARP response that reports destination
ATM address foo, look to see if you have an active VC to foo.  If yes,
use that for this destination also; if not, issue a SETUP to foo.

 kennethw> ipoaLisActiveVcs counts the number of active VCs per
 kennethw> LIS. The ipoaLisTable is indexed by subnet address.

 kennethw> The ipoaVcTable's first two indexes are the same as the ARP
 kennethw> Cache's, ipNetToMediaTable. Its last two indexes are the
 kennethw> vpi and vci of the VC associated with the
 kennethw> entry. ipNetToMediaNetAddress is an ip address not a subnet
 kennethw> address.

Ok, so what this is really saying is that the table represents ARP
cache entries and not VCs.  I guess that's ok, though in that case the
name is a bit confusing.

 >> In IPOA, a VC connects two ATM end systems (two interfaces),
 >> carrying any IPOA traffic between those two points regardless of
 >> subnet.  If both endpoints have multiple (common) subnets defined
 >> for their interface, then traffic for each of those will use the
 >> single VC.

 kennethw> These end systems are not acting as routers into non-ATM
 kennethw> clouds are they? If not then they could be defined as two
 kennethw> members of the same LIS. If they were routers then either
 kennethw> network or subnet routes would need to be defined to flow
 kennethw> traffic correctly. Only the "routers" would need to be in
 kennethw> the same LIS. If a third end-system would need access to
 kennethw> one of the prior systems it could be configured to be in
 kennethw> the same LIS or a second LIS could be configured that one
 kennethw> of the first two participates in.

The system at my end is an ATM end system that is also an IP router.
IPOA doesn't care whether the systems it connects are IP routers or IP
hosts, as far as I can tell.  My question applies in either case, so
long as there exists a pair of IP nodes that have multiple addresses
assigned to their ATM interface such that these addresses belong to
different subnets (and hence to different LIS).

 >> given VC appear multiple times in the MIB, once for each subnet
 >> for which it can be used.  For example, if I have one VC, I might
 >> have ipoaLisActiveVcs == 1 for multiple LIS, and there would be
 >> multiple entries in the ipoaVcTable (differing only in the

 kennethw> No. PVCs are configured in the MIB, SVC are dynamically
 kennethw> established as need. VCs just don't appear in the MIB. I
 kennethw> don't think you understand the ipoaVcTable and its relation
 kennethw> to the ARP Cache.

I assumed that the ipoaVcTable was meant to represent VCs.  Certainly
the indexing suggests that it represents ARP cache entries instead,
and I can certainly make it do that.

	paul

---

From: Bryan Gleeson <[email-masked]>
Date: Tue, 11 Nov 1997 11:01:08 -0800 (PST)

Paul, Ken,

>(offline) a week or so ago.

Yes, there is no requirement that a VCC belong exclusively to a single 
LIS. A node is allowed to advertise the same, or different, ATM 
addresses for each LIS it is in, and so force separation, or allow 
aggregation, of traffic in different LISs.

If using one ATM address for multiple LISs, there is the issue of how 
to determine the LIS that a packet arrived on. If all you want to do 
is forward / receive a packet then you probably don't care. A host 
can figure out the incoming LIS by looking at the destination IP 
address in the incoming packet.  A router can't do this and so must 
use a different ATM address if it actually cares (e.g. is doing 
access lists or traffic engineering of some sort). An ATM ARP server 
can use one ATM address for all LISs, and figure out the LIS associated 
with an incoming request by looking at the source protocol address field.

>But I had always understood

A transmitting station is allowed to always do this, and is also
allowed to setup multiple VCCs between the same ATM address pair
(with different QoS for example). RFC1755 explicitly allows multiple
VCCs between the same ATM addresses.

Thus you can have one VCC used by multiple LISs, and multiple VCCs
used by the same LIS, between two endpoints. 

Bryan

---

From: [email-masked]
Date: Wed, 12 Nov 97 11:16:49 EST

Thanks Bryan for your note on this topic.

Paul,
   The IPOA-MIB doesn't prevent VCs from being shared. Please
indicated where you think this limitation is implied in the MIB.

Ken

---

From: Paul Koning <[email-masked]>
Date: Wed, 12 Nov 1997 11:38:36 -0500

>>>>> "kennethw" == kennethw  <[email-masked]> writes:

 kennethw> ...  Paul, The
 kennethw> IPOA-MIB doesn't prevent VCs from being shared. Please
 kennethw> indicated where you think this limitation is implied in the
 kennethw> MIB.

There were two things that triggered my concern; both may be cases of
reading too much into the text.

First one: LIS -- which is indexed by subnet -- has a count of active
VCs (implying "active VCs for this subnet").  With shared VCs, the VC
isn't "for a subnet".  So it's not clear what to do about that count.

A node doesn't necessarily know in advance what subnets can use an
SVC, so it doesn't help to say "count the VC once for each LIS it is
used for".  For PVCs you can tell (from InARP messages) but for SVCs
-- as far as I can tell from Classic2 -- the normal address resolution
mechanism is ONLY ATMARP messages to the server, and those are sent
only when you have traffic.  (There is a case mentioned where you send
InARPs on an SVC, but only if you're doing revalidation of an ARP
cache entry and the server doesn't answer.)  So the two endpoints of
the SVC may have 3 LIS in common but not know about this, depending on
what traffic is offered.

It's not clear to me what purpose the LIS VC counter serves and I
would rather see it go away.  Alternatively, it could be provided by
implementations that have per-LIS VCs but omitted by those that use
shared VCs.  The third possibility is to count the VC for each LIS for
which you know that the VC can be used -- but in that case it becomes
somewhat of a random number because the presence of traffic for a
given LIS will affect whether the VC is counted for that LIS or not.

Second one: I took the name "ipoaVcTable" to mean that the table
describes VCs, and the fact that an IP address indexes the table rows
then implies an assumption that a VC has associated with it one IP
address.  In fact, that table doesn't describe VCs but rather ARP
cache entries, which makes the issue go away.  (Would it be possible
to rename it to make this more explicit?  I think customers would
appreciate having object names be suggestive of the thing being
reported.)

	paul

---

From: [email-masked]
Date: Thu, 13 Nov 97 09:03:05 EST

Paul,

>kennethw> ipoaLisActiveVcs is the number of active SVCs per LIS. The
>kennethw> entire ipoaLisTable doesn't apply to PVCs. I recommend that
>kennethw> ipoaLisActiveVcs be incremented when either a SVC is being
>kennethw> create or reused for for traffic in a particular LIS. This
>kennethw> object was useful in one of our implementations is finding
>kennethw> an error where we were creating too many SVCs. If you feel
>kennethw> that in your implementation that this object has little
>kennethw> value then you can always take an exception in your agent
>kennethw> capabilities statement and not implement it.

>Ok, that's always a possibility.

>Your explanation does trigger a general issue.  As Ken Virgile
>mentioned (in a slightly different context) a few days ago, MIB
>objects are for management, not for debugging.  If the justification
>for an object is that it was useful to track down a coding error, my
>conclusion would be that this explanation justifies its deletion.

>Frankly, there are far too many MIB objects already, and many have no
>valid reason for existing.  I would rather apply pressure to cut back
>on the quantity of new objects being defined.

I agree that MIB objects should not exist for the purposes of
debugging code. The purpose of ipoaLisActiveVcs is to provide
management applications with a rough indication of the SVC load on a
LIS.

Ken