Subject: Re: router LSA with unknown link type

From: "Field, Brian" <[email-masked]>
Date: Wed, 1 Dec 2004 08:50:49 -0700

Ok, so in the draft, in section 2, it states:

--

   Section 12.4.1 [OSPFv2] describes the various values used to Link-types
   in Router LSA's. The values 1, 2, 3 and 4 are defined.

   If a Router LSA with an unknown link-type is being processed, the link
   is ignored and the rest of the router LSA is processed normally.

   Section 16.1 (2)(a) [OSPFv2]  should now read

                If this is a link to a stub network, examine the next
                link in V's LSA.  Links to stub networks will be
                considered in the second stage of the shortest path
                calculation. If the link type is unknown examine the
                next link in V's LSA. Unknown Link Types are ignored.

--

Is the processing mentioned in the second paragraph above meant to specify
that
router LSAs with unknown link types should be stored intact into the LSDB
and
flooded intact?  When I read this, I thought this was applying to the
updated text
listed in the third paragraph.  The storage and flooding implications of the
above test isn't clear to me, but if this is clear to the developers, then I
don't
have an issue with it.

Maybe this is obvious to others but it's not to me.   Maybe my assumption
base
is incorrect.  I'm thinking that "old" routers originate router LSAs with
just
types 1-4 and "new" routers originate router LSAs with types 1-4 and
possibly new
link types.   Based on this spec, "old" and "new" routers share the same
LSDB for
types 1-4 as router LSAs are no longer ignored when an unknown link type is
present.
The LSDB across routers isn't "inconsistent" but some routers have some
additional
topo info. Given this, could someone provide an example where a forwarding
loop is
created?

Thanks
Brian

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]]
> Sent: Wednesday, December 01, 2004 8:17 AM
> To: [email-masked]
> Subject: Re: router LSA with unknown link type
>
> Field, Brian wrote:
>
> >A couple of comments:
> >
> >* Is it clear from 2328 that when a router receives a router
> LSA with
> >an unknown link type that the router should not drop the LSA
> but should
> >instead store the intact LSA in its LSDB and continue to
> flood the intact LSA?
> >
> >
> It isn't really clear and hence the need for the Vishwas' draft.
>
> >* In the SPF algorithm, I wonder if it might make sense to
> tighten up
> >the language some, specifically around (2b) in 16.1 (and
> maybe in other
> >locations):
> >
> >            (b) Otherwise, W is a transit vertex (router or transit
> >                network).  Look up the vertex W's LSA (router-LSA or
> >                network-LSA) in Area A's link state database.  If the
> >                LSA does not exist, or its LS age is equal
> to MaxAge, or
> >                it does not have a link back to vertex V, examine the
> >                next link in V's LSA.[23]
> >
> >In the context of possible new link types, the text "... it does not
> >have a link back to vertex V" may be too vague.  Maybe we should
> >specify the specific link types that this link must have in
> order for this check to succeed?
> >
> >* In section 4 of the proposed draft, I have two issues with
> the following:
> >
> >   Any future extensions SHOULD not cause any change in routing table
> >   calculations. Such a change can result in routing loops
> because the routers
> >   unaware of the extension will ignore the link.
> >
> >I'm not convinced that we should close the door on defining new link
> >types which define non-edge topo and which are carried in
> the router LSA.
> >
> I agree - what the draft should say is that the introduction
> of new link types should address backward compatibility
> issues within the area.
>
> >Further, I'm
> >not convinced that introducing these new link types will necessarily
> >cause routing loops.
> >
> >
> It depends on the topology. However, if some routers are
> using the new links and others are ignoring them there is the
> potential for loops.
>
>
> >Consider some set of routers which forward all router LSAs
> intact (per
> >this ID).Some routers support just link types 1-4 and others
> support 1-4 and a new
> >link type (which defines topo info).   All routers have the
> same LSDB which contains
> >link types 1-4 and new ones.  The old routers compute trees
> based on types 1-4.
> >The new routers compute trees based on links 1-4 and the new links.
> >Instead of causing forwarding loops, doesn't this just cause some
> >routers (the ones that understand the new link types) to
> have short cuts in their topos?
> >
> >
> No - if you have router that doesn't understand the new types
> in the path to the router with the shortcut you could have a loop.
>
>
> >Now I could see forwarding loops being developed if routers, upon
> >seeing a router LSA with an unknown link type, dropped the
> router LSA
> >and did not storeit in its LSDB or flood it.  But per 2328 or this
> >spec, that's not proper behavior.
> >
> >Thanks
> >Brian
> >
> >
> >
> >
> >________________________________
> >
> >        From: Vishwas Manral [mailto:[email-masked]]
> >        Sent: Tuesday, November 30, 2004 9:57 AM
> >        To: [email-masked]
> >        Subject: Re: router LSA with unknown link type
> >
> >
> >        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: Roch Guerin <[email-masked]>
Date: Wed, 1 Dec 2004 11:18:38 -0500

Brian,

I guess a simple example seems to be as illustrated below:

|A|------|B|------|D|
 |                         |
|E|------|F|------|G|----R

Router B is an "old" router, and all the other are "new" routers.
Router D has a link of new type to router G that is connected to route
R.  The (bidirectional) costs on all links are 1 except for the link A-E
that has a cost of 10.  From router A's perspective, the shortest path
to R is through router B, but because router B does not "see" the link
of new type between routers D and G, its shortest path to R is through
router A.  Hence a routing loop.

Roch