Subject: RE: REVISED Last Call: 'Management Information Base for the Internet Protocol (IP)' to Proposed Standard

From: "Shawn A. Routhier" <[email-masked]>
Date: Mon, 08 Dec 2003 16:29:06 -0800

At 10:30 AM 11/24/03 -0800, Dave Thaler wrote:

I've snipped the sections I agree with and don't have questions about
I will update the specification to match them if there are no other
comments or discussion.

>I just started implementing draft-ietf-ipv6-rfc2011-update-04.txt
>and have the following comments:
>
>
>4)
>> ipSystemStatsInTruncatedPkts OBJECT-TYPE
>[...]
>>   "The number of input IP datagrams discarded because datagram
>>    frame didn't carry enough data.
>
>This is unclear.  If the frame didn't carry enough data to hold an IP
>header,
>is this counter incremented or ipSystemStatsInHdrErrors, or both?
>As the case diagram implies, I think this counter should only be
>incremented
>if the IP header is valid.

I think this would make the most sense and will make this update if there
are no complaints.

I'll point out that at least one current implementation doesn't operate
in this fashion.  It lumps frames that are too short for the header in 
with frames that are too short for the packet.  

>5) Are all three of InForwDatagrams, InNoRoutes, and OutForwDatagrams
>needed?  Per the case diagram, is it always the case that
>    InForwDatagrams = InNoRoutes + OutForwDatagrams
>or it it legal for InDiscards or OutDiscards to be incremented
>in between InForwDatagrams and OutForwDatagrams?

I believe it is possible that inDiscards or outDiscards could be incremented.

Also in note that in the interface specific case the interface may have changed.
The ipIfStatsOutForwDatagrams counts packets on the outbound interface, while
the ipIfStatsInForwDatagrams counts packets on the inbound interface.

Potentially we could try and remove one of these objects from the system group
but it doesn't seem worthwhile to do so.

ipIfStatsOutForwDatagrams OBJECT-TYPE
    SYNTAX     Counter32
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
           "The number of datagrams which this entity received and for
            which it was successful in finding a path to their final
            destination.  In entities which do not act as IP routers,
            this counter will include only those datagrams which were
            Source-Routed via this entity, and the Source-Route
            processing was successful.

            When tracking interface statistics the counter of the
            outgoing interface is incremented for a successfully
            forwarded datagram.

>There's currently the note
>"(2) The discard counters may increment at any time in the processing
>path."
>but it isn't clear which processing path.  Obviously it should not be
>legal for InDiscards to be incremented in the send path, or for
>OutDiscards to be incremented in the receive path.  But with the
>forward path line, it's not clear where the legal "InDiscards" section
>ends and the legal "OutDiscards" section begins.
>
>One simple fix would be to just specify that InDiscards applies anywhere
>left of the InNoRoutes junction, and OutDiscards applies anywhere
>right of it.

That was my intention.  I'll update the text.

><snip>
>7) the ip6Forwarding object is described as
>>   "The indication of whether this entity is acting as an IPv6
>>   router in respect to the forwarding of datagrams received
>>   by, but not addressed to, this entity.  IPv6 routers forward
>>   datagrams.  [...]
>
>However, forwarding is actually a per-interface attribute in general.
>If a device is acting as a router on some interfaces and as a host
>on others, what value should it report here?  In my opinion it should
>report true here (if this object is kept at all) and there should be 
>a per-interface Forwarding object.

I agree with setting the object to TRUE if it is performing routing on
any interfaces.

I don't have an opinion on having a per-interface forwarding object.  Any
comments from the mailing list?

Note: if we do add a per-interface forwarding object I'd suggest that the system
forwarding object (ip6Forwarding) override the per-interface objects.  So
I could configure the interfaces properly and then toggle the device to forward
or not based on a single object.

>8) ipv6InterfacePhysicalAddress OBJECT-TYPE
>
>If this object is needed (as opposed to just using ifPhysAddress)
>why does the same reason not apply to IPv4 also?

There was some discussion on this object and the result was a belief that it
was useful for v6.  I suppose the same arguments could be made for v4, but I
haven't heard anybody make them.  Possibly people felt that it was useful enough
to include in new (v6) code but not worthwhile to add to already existing v4
code?

Any comments from the list?

>10) ipv6InterfaceRetransmitTime OBJECT-TYPE
>Is there a reason this doesn't apply to IPv4?
>RFC 1122 says regarding ARP:
>>  [...]  The recommended maximum rate is 1 per second per
>>  destination.

Again, I suppose we could add it.  I think this also falls into the category above,
it might be useful to implement for new code but may not be worth retrofitting old
code.  (And do remember that this object refers to suggested times and not max times.)

>It would seem that all objects in the ipv{4,6}InterfaceTables 
>should be the same except for ipv6InterfaceIdentifier.  
>Is there a reason they are not merged as was done with the
>ipSystemStatsTable?

As I recall my general assumptions were that the two tables would have different
objects and might have new different objects added in the future.  We could collapse
the two tables and simply define appropriate not available values or suggest that an
agent return no such instance.

><snip>
>12) The ipDefaultRouterTable is indexed as
>>   INDEX {ipDefaultRouterAFType, ipDefaultRouterAddress}
>
>The current indexing requires the agent to report only one row when 
>the link zone id is the same for both interfaces (i.e. indicating 
>multiple interfaces are attached to the same physical link) and
>the same router is reachable on both interfaces.

That seems to be correct.

>Per RFC 2461:
>> Router list entries point to entries in the
>> Neighbor Cache; [...]
>
>The inetNetToMediaTable instruments the neighbor cache and contains 
>the ifIndex in the INDEX.  As a result, the MIB does not follow the 
>RFC 2461 model.  To be consistent, ipDefaultRouterIfIndex must be
>in the INDEX clause to allow an entry to point to a specific
>inetNetToMediaEntry.

I would think that to be consistent I would actually need to
point the router list entries to inetnetToMediaTable entries.
However I don't like that at all and find adding ipDefaultRouterIfIndex
to the indexing to be better.  

An alternative is to decide that the router list shouldn't contain the
IF contact information at all and should simply be a list of the default
routers.  

As I think the IF information is useful I intend to leave it in and add
it to the index.

>16) The case diagram accounts for the case where the IF changes on the
>    receive path, but what about on the send path?  The same thing
>happens
>    in the weak host model.  
>
>    Similarly, on a router, a packet could be forwarded and then be
>    locally destined.  Or it could be locally sourced and then
>    forwarded.  In these cases, should InForwDatagrams and
>OutForwDatagrams
>    be incremented?  I would say yes, although the case diagram doesn't
>    allow for it.  It would be nice to add a note to at least add a note
>    to this effect.

I think I understand your first example (forwarded and then locally destined)
I don't think I understand your second.  Can you elaborate somewhat?
Also in the first example I could see this being treated as being sent out one
interface and received on another even if the packet never went to the wire.  In
this scheme I believe the counters would be correct, however I don't know if
that's what you have in mind.

I'm willing to add text as necessary but need some more specifics to understand
what you think I should add (and where).

>    
>
>Missing references
>------------------
>
>> ipv6RouteTable) has been removed from this MIB.  The replacements or
>> updates for this information is in the update to the IP Forwarding
>Table
>> MIB.
>
>add a reference to that document so the reader can find them

I think this should be informative, do you agree?

>>   REFERENCE "draft-ietf-ipv6-router-selection-02.txt, section 2.1"
>
>The reference is missing from the References section.

I think this one needs to be normative, do you agree?

><snip typos>
>-Dave

Thanks Dave

Shawn A. Routhier
SMTS 
Wind River Networks Business Unit
510 749 2095 office 
510 749 2560 fax
www.windriver.com

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 8 Dec 2003 18:51:25 -0800

> with frames that are too short for the packet.

I agree that would be a valid implementation.
Not sure how to express that in the case diagram though.
I think I'd just add a note at the bottom of it.

> Also in note that in the interface specific case the interface may
have
> changed.
> The ipIfStatsOutForwDatagrams counts packets on the outbound
interface,
> while
> Potentially we could try and remove one of these objects from the
system
> group

Agree.

[...]
> comments from the mailing list?

We could add it but not make it mandatory.

> Note: if we do add a per-interface forwarding object I'd suggest that
the
> system
> I could configure the interfaces properly and then toggle the device
to
> forward

Agree, that is what I implemented.

> There was some discussion on this object and the result was a belief
that
> it
> was useful for v6.  I suppose the same arguments could be made for v4,
but
> I
> haven't heard anybody make them.  Possibly people felt that it was
useful
> enough
> to include in new (v6) code but not worthwhile to add to already
existing
> v4

I am unhappy with its existence for IPv6 only.
I would like to see it either removed, or made available for both v4 and
v6.
The v4 version may be optional though so as to not cause a burden on
prior implementations.

My reasoning is that I don't want to have separate code for IPv4 and
IPv6
if I can help it.

> code.  (And do remember that this object refers to suggested times and
not
> max times.)

Making the v4 object optional would be fine with me.

> agent return no such instance.

Yes collapsing them would be my preference, for code simplicity.

> As I think the IF information is useful I intend to leave it in and
add

Agree.

> I don't think I understand your second.  Can you elaborate somewhat?

The second example would be where you are running an app on a machine
with either forwarding enabled, or that implements the weak host model.
The app chooses a specific source address (e.g. with a bind) and then
sends a packet to a specific destination address.  The routing table
lookup decides the packet should go out another interface than the
one the source address is on.  Because forwarding is enabled, this
is allowed.  The packets come down from the app, logically go through
a forwarding path, and then go out the outgoing interface.

There are multiple ways to implement this, but the one I have in mind
is the one where the interface context changes as you go down the send
path (just like how note (3) says the interface can change on the
receive path). So OutRequests is incremented on the address's interface
and OutTransmits is incremented on the outgoing interface.  The current
description of InForwDatagrams implies it would be incremented,
since it says nothing about whether the packet was locally- or
remotely-originated.  The current description of OutForwDatagrams
implies it would not be incremented since it says "received".
I believe the wording should not be different.

So either both should say "received" or both should say
"attempted to forward".  At this point, I have no strong 
preference either way.

> Also in the first example I could see this being treated as being sent
out
> one
> this scheme I believe the counters would be correct, however I don't
know
> if

I think we should not try to make the case diagram any more complicated,

but I think the DESCRIPTION clauses should be updated as noted above,
and it would be good to add a note under the case diagram which depends 
on the answer to whether In/OutForwDatagrams should be incremented.

> I think this should be informative, do you agree?

Agree.

> I think this one needs to be normative, do you agree?

Agree.

-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 9 Dec 2003 10:31:33 -0800

One more comment on #8...

> > that it was useful 
[...]

It would be helpful to implementers to state why this object is needed.
I.e., when could it be different from ifPhysAddress?  (Is it just
if manually configured otherwise?)  Also, is it required that
the value of this object be in the ifRcvAddressTable?
It seems like that ought to be a requirement.

-Dave