Subject: [Isis-wg] ISIS MIB - costs of notifications

From: "Parker, Jeff" <[email-masked]>
Date: Tue, 05 Oct 2004 16:00:54 -0400

Edited version of mail unintentionally sent privately to Joan

On 10/5/04 1:58 PM, "[email-masked]" <[email-masked]>
wrote:

> At 01:52 PM 10/4/04 +0000, Parker, Jeff wrote:
>> 
>>>>>   - isisIDLenMismatch
>>>>>   - isisMaxAreaAddressesMismatch
>>>>>   - isisAuthenticationTypeFailure
>>>>>   - isisAuthenticationFailure
>>>>>   - isisVersionSkew
>>>>>   - isisAreaMismatch
>>>>>   - isisRejectedAdjacency
>>>>>   - isisLSPTooLargeToPropagate
>>>>>   - isisOrigLSPBuffSizeMismatch
>>>>>   - isisProtocolsSupportedMismatch
>>>> 
>>>> These are packets that the protocol needs to verify.
>>>> My intent is not that we keep track of every instance of these errors: the
>>>> MIB specifies only that we keep track of the first such error per
> interface.
>>> 
>>> According to what ISIS specification?
>> 
>> Joan -
>>    This is pretty standard error checking for all but one of these.  I
>> agree tha BufferSizeMismatch is not required, but everything else must be
>> checked on every packet.  So there is no extra processing required: just
>> extra storage per circuit.
>>    What the MIB specifies is that you keep a bit mask of 10 bits per
>> interface, and that you send an event when you get your first error.  A
>> number of vendors have debug options that let you see this kind of check in
>> real time, and the operators I have talked to find it essential in brining
>> up links between different versions of the protocol.
> 
> The description that you are giving here is far from what is in the current
> MIB.  It sounds like you are suggesting that these notifications are going to
> be changed to a single notification which returns a BITs object to say
> what the problem might be if an adjacency can't be set up.  Is this what you
> are saying?
> 
> Also, if I understand you correctly, then operators can also disable this
> checking and turn it on if they see that an adjacency is not being set up,
> is this correct? 
> 
> I still don't completely understand your comment about "bringing up links
> between different versions of the protocol"  Isn't there only 1 version?

Joan -

    In the most recent public version, from this June, I had changed a
number of the notifications to be "once per circuit" in direct response to
your comments.  Here is a sample below.

    I am not suggesting sending BITS: I am suggesting sending one
notification the first time you see each of these events on a circuit.  The
different events have different footprints.  You keep a bit map per
interface recording these events, and send a notification when the bit map
changes.  Since a dropped packet is going to be resent, we need someway to
keep a system from banging out an en stream of these notifications.

    If this is useful, the vendor will find some way to clear the bits.  I
know of at least one implementation that does this when the packet counts
for an interface are cleared.  I'm not sure how much of this belongs in the
MIB.  

    I do not anticipate people turning off this kind of checking.  When I
get a packet, there is some basic validation that I perform.  Does it think
the ID length is 6?  Does it think max area is 3?  Is the version 1?  If the
answer to any of these is no, I really don't want to process this packet.  I
assume that you do the same.

    These notifications simply provide a way to notify an administrator that
something is wrong.  I do not expect to see a lot of ID Length problems: if
they do arrive, it is probably due to an encapsulation problem.  However,
issues such as Auth failure might be very common when rolling out a change
in that dimension.  But I want to know about either error: they represent
something that the operator needs to see.

    While there is only one version of IS-IS, there are different
implementations, and sometimes they disagree about a feature.  These
notifications provide an alternative to silently dropping packets: noisely
dropping (the first such) packet on an interface.

Internet Engineering Task Force                      Jeff Parker, Editor
INTERNET DRAFT                                         Axiowave Networks
Expiration Date: January 2005                               July 6, 2004

                 Management Information Base for IS-IS
                    <draft-ietf-isis-wg-mib-16.txt>
....

    isisAuthenticationTypeFailure NOTIFICATION-TYPE
        OBJECTS {
            isisSysLevelIndex,
            isisCircIfIndex,
            isisPduFragment
        }
        STATUS current
        DESCRIPTION
            "A notification sent when we receive a PDU
             with the wrong authentication type field.
             This notification includes the header of the
             packet, which may help a network manager
             identify the source of the confusion.

             This should be an edge-triggered notification.
             We should not send a second notification about
             PDUs received from the same circuit."

    ::= { isisTrapPrefix 9 }

- jeff parker

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