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

["Shawn A. Routhier" <[e-mail]>]

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
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------