Subject: Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 3 Feb 2003 13:51:28 +0100

>>>>> C M Heard writes:

Mike> I saw that when I went through the archived e-mail.  Do you
Mike> think that having an OCTET STRING-based policy selector (in
Mike> addition to destination prefix/prefix length and next hop) as I
Mike> suggested can provide the required flexibility?  As far as I can
Mike> see it does, although it might not be the most convenient way.

Since forwarding architectures tend to look pretty different, I guess
we can't do more than using some opaque identifier - whether that is
an OBJECT IDENTIFIER, an INTEGER will some smart numbering scheme
(similar to SnmpSecurityModel), or an OCTET STRING does not really
make a big difference to me. The problem is that mgmt applications
either understand the semantics of a particular implementation or they
will have to guess or ignore some rows. So from an interoperability
point of view, all this is only little better than not having such an
index component.

Perhaps we really need a "remote operations" MIB where you just send a
fragment of an IP header and you get back the next hop. ;-)

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 3 Feb 2003 19:30:58 -0800 (PST)

On Mon, 3 Feb 2003, Juergen Schoenwaelder wrote:
> make a big difference to me.

In principle any one of those could be made to work, yes.

> The problem is that mgmt applications either understand the
> semantics of a particular implementation or they will have to
> guess or ignore some rows.

I undestand that a management application may not have full
understanding of route table entries without understanding
the nature of the opaque identifier.  But I don't follow
why that implies that a management application has to ignore
some rows -- at least if all it's doing is inspecting rather
than modifying the rows.  The proposed index components are
destination prefix, opaque identifier, and next hop.  I can
still determine how many routes to a given destination via
a particular next hop exist (and query their other properties)
even if I don't know what the opaque identifier is.  [Note that
the order given for the indices may not be the optimal one --
probably the opaque identifier should be last -- but that does
not affect the information content.]

> So from an interoperability point of view, all this is only
> little better than not having such an index component.

I don't think I agree.  It's much better, because I can at least
represent a forwarding architecture that permits multiple routes to
a destination via the same next hop.  Without the opaque identifier
I could not do that.  More generally, without the opaque identifier
I could not map the table to an arbitrary forwarding architecture.  
It is true that it's best to split as much common stuff out of
the opaque identifier as possible.  If you can identify some
additional generic candidate index components beside destination
prefix and next hop please say so.

//cmh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Feb 2003 09:41:21 +0100

>> semantics of a particular implementation or they will have to guess
>> or ignore some rows.

Mike> I undestand that a management application may not have full
Mike> understanding of route table entries without understanding the
Mike> nature of the opaque identifier.  But I don't follow why that
Mike> implies that a management application has to ignore some rows --
Mike> at least if all it's doing is inspecting rather than modifying
Mike> the rows.  The proposed index components are destination prefix,
Mike> opaque identifier, and next hop.  I can still determine how many
Mike> routes to a given destination via a particular next hop exist
Mike> (and query their other properties) even if I don't know what the
Mike> opaque identifier is.

Well, it depends what you expect from a management application. If
your manager is a MIB brower which just shows the data to a human,
things are fine. If however the management application want to reason
about the data (e.g. which route will a packet with destination A
take), then a totally opaque value basically means that the
application can not answer this question.

/js