Subject: Re: router LSA with unknown link type

From: Vishwas Manral <[email-masked]>
Date: Tue, 30 Nov 2004 08:57:26 -0800

Hi Mitchell,
 
Good to hear from you and thanks for the comments. The basic idea is that the flooding happens normally, as is(we do not check if we understand a link type before flooding forward). This allows new link-types.
 
The change done is to explicitly state that while doing the routing table calculations the link needs to be ignored. Maybe I will change the text to further clarify this.
 
Thanks,
Vishwas

________________________________

From: Mailing List on behalf of Erblichs
Sent: Tue 11/30/2004 8:43 AM
To: [email-masked]
Subject: Re: router LSA with unknown link type

Vishwas & Acee,

        Are we viewing a area that has a mix of routers
        that understand some link-types beyond 4 and some
        routers that don't understand them????

        In the perfect world shouldn't all the routers
        within a area treat anything beyond 4 the same way?

        If this is the case, some option must be created
        that is communicated that identifies the area's
        link-types attributes. However... that seemed to
        be mentioned and dropped..

        I aggree the non-stated default should be "ignore".
        1) However, should the adj be dropped upon receipt of
        recv a unknown LSA? This would remove inconsistencies
        within a area vs allowing the issue to exist in later
        implimentations.

        2) "silently ignored" ; Else should a log entry be present
         that a LSDB inconsistency exists within the LSDB? To
        prevent a circular buffer from potentially filling with
        this msg type, only every so X entries be logged. So, I
        question what is ment by "silently ignored" and why? IMO,
        "silently ignore" is probably not appropriate due to the
        reasons for not knowing why routing Loops can/are existing
        in the selected routes.

        3) should it be mentioned that a DR/BDR be always fully
        aware of a super-set of link-types, and thus accept
        them? If not then only the subset will be communicated
        to "others".

        Mitchell Erblich
        -----------------

Vishwas Manral wrote:
>
> Hi Acee,
>
> I am attaching the document where I have added, exactly what you have
> stated.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
> Lindem
> Sent: Tuesday, November 30, 2004 6:30 PM
> To: [email-masked]
> Subject: Re: router LSA with unknown link type
>
> Vishwas Manral wrote:
>
> > Hi Acee,
> >
> > Here goes the link: -
> >
> http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown
> -type-00.txt
> >
> > Do let me know your views?
>
> Hi Vishwas,
>
> I feel we should move forward with support for the "silently ignore"
> option. I think
> that you should add a section with a caveat that states that the
> addition of new link types
> will still have compatibility implications since there is the potential
> for routing loops if
> some routers in the area support the new types and others ignore them.
> However,
> the situation is better than what we have today.
>
> Thanks,
> Acee
>
> >
> > Thanks,
> > Vishwas
> >
> >
> ------------------------------------------------------------------------
> > *From:* Mailing List on behalf of Vishwas Manral
> > *Sent:* Thu 11/25/2004 9:48 PM
> > *To:* [email-masked]
> > *Subject:* Re: router LSA with unknown link type
> >
> > Hi Acee,
> >
> > I think we must not forget there can be malicious violations of the
> > protocol too, as Tony rightly specified we need to specify the
> behavior
> > when unexpected or corrupt data is received.
> >
> > As you stated, I intend to post a short draft on this soon.
> >
> > Thanks,
> > Vishwas
> > -----Original Message-----
> > From: Mailing List [mailto:[email-masked]] On Behalf Of
> Acee
> > Lindem
> > Sent: Thursday, November 25, 2004 10:44 PM
> > To: [email-masked]
> > Subject: Re: router LSA with unknown link type
> >
> > All,
> > While it would have been better if RFC 2328 did precisely specify what
> > to do with unknown link types the fact of the matter is that it
> doesn't.
> > IMHO,
> > we'd need a short draft in order to formally specify this (or
> concensus
> > and inclusion
> > in the RFC 2740 respin). At this point, the implementation(s) that
> > generate(s)
> > the unknown link types is/are the ones in violation of the protocol.
> >
> > Speaking as a WG member, I really don't like the idea of extending the
> > protocol
> > using unknown link types UNLESS the new types are in fact a different
> > type of
> > intra-area topological edge in the SPF graph. Once we open it up I can
> > envision people
> > trying to cram all sorts of non-link data in the router LSA. If we
> want
> > to extend the
> > protocol past what it does today there are cleaner ways of doing it
> > (e.g., new LSA types
> > supporting TLVs).
> >
> > Thanks,
> > Acee
> >
> >
> > Nitin Kakkar wrote:
> >
> > >IMHO I can think of two possibilities for this condition
> > >
> > >1) Some error in LSA creation, which overwrite link type field. :
> This
> > >should be reflected in checksum error and should be handled such.
> > >
> > >2) Some new invension which adds to the existing 4 types of Link
> Types
> > (or
> > >support for unknown link types): This Needs to have some common
> > >understanding (RFC etc) to handle this. I feel that they can be
> handled
> > like
> > >unknwon LSA's (store & forward only, no routing calc's)
> > >
> > >HTH
> > >Nitin
> > >
> > >-----Original Message-----
> > >From: Mailing List [mailto:[email-masked]]On Behalf Of
> Acee
> > >Lindem
> > >Sent: 2004Ae11OA24EO 21:37
> > >To: [email-masked]
> > >Subject: Re: router LSA with unknown link type
> > >
> > >
> > >Field, Brian wrote:
> > >
> > >
> > >
> > >>If a router receives a router LSA that contains several links and
> > >>for one of the links, the link type field is not known, should the
> > >>router ignore the entire router LSA or just skip this one link?
> > >>
> > >>
> > >>
> > >>
> > >Hi Brian,
> > >Unfortunately, the handling of unknown link types is not specifically
> > >defined in RFC 2328.
> > >Since links types 1-4 are the only ones defined an implementation
> > should
> > >probably log
> > >the invalid link type (with rate limiting). Whether it ignores the
> LSA
> > >or just the unknown link is
> > >implementation specific. If we were to move forward with link type
> > >extension it would not be
> > >backward compatible (at least not without knobs or other mechanisms).
> > >
> > >Thanks,
> > >Acee
> > >
> > >
> > >
> > >>Thanks
> > >>Brian
> > >>
> > >>
> > >>
> >
>
>   ------------------------------------------------------------------------
>                                                           Name: draft-manral-ospf-router-lsa-unknown-type-01.txt
>    draft-manral-ospf-router-lsa-unknown-type-01.txt       Type: Plain Text (text/plain)
>                                                       Encoding: base64
>                                                    Description: draft-manral-ospf-router-lsa-unknown-type-01.txt

---

From: Erblichs <[email-masked]>
Date: Tue, 30 Nov 2004 11:26:11 -0800

Vishwas Manral,

        Oooo..

           Yes, it will be a bit more work, but yes, the
           acceptance and flooding of unknowns should be
           limited to Opaque LSAs, IMO, Why??

        Answer:
        --------

        1) The removal of unknown Link-types should
        decrease the size of the LSDB.. This becomes most
        important with stub, etc routers/areas.

        2) It should reduce the size of bandwidth due
           to flooding with a large number of LSAs with
           unknown link-types. This does increase the
           amount of work to rebuild the LSA.

         3) if 1 router has unknown link-types then
            all the routers within the area are
            required to alloc mem for the useless
            info.

        4) We have 0 chance to do a minimal amount of
           due-diligence to verify the data. Don't
           insert garbage (useless info) into the LSDB.

        5) You are populating the LSDB with unknown link-types
           and each time you run your SPF calcs, you need to
           skip unknown link-types?

        ***6) If some routers include unknowns (beyond #4)
               in the calcs(because they understand) a
               superset and some don't, their could be
                routing issues.

        7) You can log and flag unknown values as they
           arrive if you do #4.

          Thus, if you don't flood known link-types, etc
          via the DR/BDR the LSDB shouldn't become mixed
          with unknowns on the non-orginating routers.

          Ex:
          So, only a flag NEED be used on these two non-other
          routers to determine the acceptance of unknowns in
          this environment with respect to flooding and initial
          database synch.

          I think this forces a full-restart if/when the router's
          capability is changed to include/exclude the unknowns
          in the LSDB. Thus, IMO a unknown flag should be
          supported.

        ----------------

        Mitchell Erblich
        -----------------

> Vishwas Manral wrote:
>
> Hi Mitchell,
>
> Good to hear from you and thanks for the comments. The basic idea is
> that the flooding happens normally, as is(we do not check if we
> understand a link type before flooding forward). This allows new
> link-types.
>
> The change done is to explicitly state that while doing the routing
> table calculations the link needs to be ignored. Maybe I will change
> the text to further clarify this.
>
> Thanks,
> Vishwas
> ----------------------------------------------------------------------
> >                                                           Name:
> draft-manral-ospf-router-lsa-unknown-type-01.txt
> >                                                       Encoding:
> base64
> >                                                    Description:
> draft-manral-ospf-router-lsa-unknown-type-01.txt

---

From: Acee Lindem <[email-masked]>
Date: Tue, 30 Nov 2004 14:54:36 -0500

>           limited to Opaque LSAs, IMO, Why??
The reason for limiting this draft to unknown link types is that this
has never
been formally specified in the OSPFv2/OSPFv3 specification. The handling
of unknown LSA types is defined in both the OSPFv2 and OSPFv3
specifications. The fact that we are discussing explicit defining  what
to do
with unknown link types is not a license to change OSPFv2 unknown LSA type
handling.

>>>I am attaching the document where I have added, exactly what you
>>>
>>>
>>have
>>
>>
>>>stated.
>>>
>>>Thanks,
>>>Vishwas
>>>
>>>will still have compatibility implications since there is the
>>>
>>>
>>potential
>>
>>
>>>for routing loops if
>>>some routers in the area support the new types and others ignore
>>>
>>>
>>them.
>>
>>
>>>However,
>>>>I think we must not forget there can be malicious violations of
>>>>
>>>>
>>the
>>
>>
>>>>While it would have been better if RFC 2328 did precisely specify
>>>>
>>>>
>>what
>>
>>
>>>>the unknown link types is/are the ones in violation of the
>>>>
>>>>
>>protocol.
>>
>>
>>>>Speaking as a WG member, I really don't like the idea of extending
>>>>
>>>>
>>the
>>
>>
>>>>protocol
>>>>using unknown link types UNLESS the new types are in fact a
>>>>
>>>>
>>different
>>
>>
>>>>type of
>>>>intra-area topological edge in the SPF graph. Once we open it up I
>>>>
>>>>
>>can
>>
>>
>>>>envision people
>>>>protocol past what it does today there are cleaner ways of doing
>>>>
>>>>
>>it
>>
>>
>>>>(e.g., new LSA types
>>>>supporting TLVs).
>>>>
>>>>Thanks,
>>>>Acee
>>>>
>>>>
>>>>Nitin Kakkar wrote:
>>>>
>>>>
>>>>
>>>>>>If a router receives a router LSA that contains several links
>>>>>>
>>>>>>
>>and
>>
>>
>>>>>>for one of the links, the link type field is not known, should
>>>>>>
>>>>>>
>>the
>>
>>
>>>>>Unfortunately, the handling of unknown link types is not
>>>>>
>>>>>
>>specifically
>>
>>
>>>>>defined in RFC 2328.
>>>>>the invalid link type (with rate limiting). Whether it ignores
>>>>>
>>>>>
>>the
>>
>>
>>>LSA
>>>
>>>
>>>>>implementation specific. If we were to move forward with link
>>>>>
>>>>>
>>type
>>
>>
>>>>>backward compatible (at least not without knobs or other
>>>>>
>>>>>
>>mechanisms).
>>
>>
>>>>>Thanks,
>>>>>Acee
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Thanks
>>>>>>Brian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>   draft-manral-ospf-router-lsa-unknown-type-01.txt       Type:
>>>
>>>
>>Plain Text (text/plain)
>>
>>
>>>                                                      Encoding:
>>>
>>>
>>base64
>>
>>
>>>                                                   Description:
>>>
>>>