Subject: Re: router LSA with unknown link type

From: Vishwas Manral <[email-masked]>
Date: Wed, 1 Dec 2004 09:18:51 -0800

Hi folks,
 
>>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.
 
Would the following text be ok?

   Any future extensions MUST take care of backward compatibility issues.
   Incase a new extension is defined, the routers unaware of the extension will 
   ignore the link. Care must be taken that this new extension does not cause 
   routing loops to occur, when some of routers do not understand the 
   new extension.

Thanks,
Vishwas

________________________________

From: Mailing List on behalf of Acee Lindem
Sent: Wed 12/1/2004 7:16 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: Acee Lindem <[email-masked]>
Date: Wed, 1 Dec 2004 16:30:36 -0500

> Would the following text be ok?

Much better, I just didn't want to the draft to give the impression that
ignoring unknown link types would solve all the backward compatibility
issues.

Thanks,
Acee

> *From:* Mailing List on behalf of Acee Lindem
> *Sent:* Wed 12/1/2004 7:16 AM