Subject: ospfv3 MIB - ospfv3NbrTable

From: vj cadman <[email-masked]>
Date: Wed, 17 Sep 2003 07:24:16 -0700

Regarding the ospfv3NbrIfIndex defined in the ospfv3NbrTable for ospfv3 MIB, is it the neighbor's interface ID specified in the neighbor's hello packet?

Thanks,
Viva

---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

---

From: Acee Lindem <[email-masked]>
Date: Wed, 17 Sep 2003 10:41:55 -0400

vj cadman wrote:
> Regarding the ospfv3NbrIfIndex defined in the ospfv3NbrTable for ospfv3
> MIB, is it the neighbor's interface ID specified in the neighbor's hello
> packet?

Hi Viva,

Nope - it is your own interface ID.

     ospfv3NbrIfIndex OBJECT-TYPE
             SYNTAX          InterfaceIndex
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                 "The local link ID of the link over which the
                      ~~~~~~~~~~~~~
                  neighbor can be reached."
             ::= { ospfv3NbrEntry 1 }

>
> Thanks,
> Viva
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! SiteBuilder
> <http://us.rd.yahoo.com/evt=10469/*http://sitebuilder.yahoo.com> - Free,
> easy-to-use web site design software

--
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 17 Sep 2003 16:53:08 -0700

Group,

        I think I am dense because I have a couple of questions that
        doesn't seem to be resolved in this "work-in-progress". :)

        1) If we look at just one capability specified in this
        draft: Stub router support via bit 6. This is RFC 3137
        from June 2001.

        I will make the assumption that some routers support this
        RFC, but don't yet support the capability "work-in-progress".
        In this case, the absense of this RI Opaque LSA doesn't reflect
        the absense of this capability or in a more general sense, the
        absense of support for any of the capabilities of the specified
        bits.

        2) Once this draft becomes a RFC and future drafts add more
           capability bits, then how should one determine that
           missing capibility bits means no capability versus not
           yet specified capability in the IR LSA.

           If the LSA field were incremented from a "4" to a "5" then
           we could make the distinction. A "4" would mean that it
           may have (0 - 3) and/or 10-31 capabilities, and a "5"
           with capabilites not yet, means no capabilities.

        3) Can the LSA be specified as a DNA (Do not age) LSA?

        Mitchell Erblich

---

From: Erblichs <[email-masked]>
Date: Wed, 17 Sep 2003 17:04:45 -0700

Group,

        When given a "update packet with say 5 LSAs", and the
        1st LSA in this packet has a checksum error, should
        the rest of the LSAs in the update be attempted to be
        processed?

        Note: If we have a checksum error, this means that the
        length and the start of the next LSA COULD be wrong.

        We could assume that checking the type of the next LSA
        could be within a valid LSA type range, and still not
        have the correct begining of the 2nd or 3rd ... LSAs.

        Is this behaviour specified anywhere?

        Mitchell Erblich
        Sr Software Engineer
        --------------------

---

From: Acee Lindem <[email-masked]>
Date: Thu, 18 Sep 2003 11:22:23 -0400

Hi Mitchell,

>        absense of support for any of the capabilities of the specified
TRUE.

>           with capabilites not yet, means no capabilities.
The smoothest transition path would be for the new functions to include
specification of a
capability bit. However, we could take your suggestion into consideration.

>        3) Can the LSA be specified as a DNA (Do not age) LSA?
Sure. Keep in mind that DoNotAge only afffects LSAs that are unchanged.