Subject: Re: router LSA with unknown link type

From: Vishwas Manral <[email-masked]>
Date: Wed, 24 Nov 2004 22:53:49 -0800

Hi Sina,

I believe specifying one behavior as right will at-least make the
vendors change at some point of time. Leaving it to the implementation I
think is not right. I think we need to fill the crack and specify a
correct behavior.

Also I think we need to specify the behavior for RFC2740, as Acee
intends to re-spin it. Similar case with unknown options etc. Acee you
might want to add these to your list.

Thanks,
Vishwas

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Sina
Mirtorabi
Sent: Thursday, November 25, 2004 12:04 PM
To: [email-masked]
Subject: Re: router LSA with unknown link type

Vishwas,

->
->Hi Acee,
->
->I think we cannot leave this to an implementation, as it can 
->cause routing loops if different routers have different 
->assumptions and hence different Router LSA's on which to 
->build the routing table.

If we are talking about an action in the future, that is an extension
which
add or use a new link type, then the specification should handle
backward
compatibility problem.

If we are talking about present and say a bug which introduces an
unknown
link in Router LSA, then since there is nothing specified in 2328,
different
implementation could handle unknown link differently and yes this could
cause problem. We don't have much choice to leave to implementation in
this
case because there are implementation already out there ;-)

Sina

->
->Thanks,
->Vishwas
->
->-----Original Message-----
->From: Mailing List [mailto:[email-masked]] On 
->Behalf Of Acee Lindem
->Sent: Wednesday, November 24, 2004 9:37 PM
->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
->>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 24 Nov 2004 23:15:01 -0800

Hi Vishwas,

>think is not right. I think we need to fill the crack and specify a
The problem is to determine what should be the "correct" behavior when
dealing with older code
- dropping or accepting the LSA, because of  an unknown link,  might
both cause loops

At this point, we cannot specify what should be done, it is best left to
the implementation
(eventually with knobs .. sigh!) to deal with.

"Be liberal in what you accept and conservative with what you send "  is
to me the best course of action.

Padma

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 25 Nov 2004 11:07:32 +0100

> - dropping or accepting the LSA, because of  an unknown link,  might

So this is a discussion that triggered my interest. I partially agree &
disagree with
all parties here ;-)

My observations from quite a couple of specs and their deployment would be:
. It is a sign of a good protocol spec that it specifies very tightly
behavior when
unexpected, corrupt data is received. One implementatoin taking the last
elements
vs. another taking the first of unexpected duplicates can loop as we all
know. Given
that IP is becoming such a critical infrastructure piece in the world
and routing
is holding lots of it together, I think that this request will show up
more and more
until it happens (ye all remember happy times where security sections were
a sign of cluelessness and RFC boilerplates were smaller than a license
plate).
. The issue is becoming more urgent when the protocol leaves its original
simplicitiy and purpose (and actually, this is a sign of a successfull
protocol, only
dead ones remain symmetric, static and beautifull) and people start to use
it to paint cars, nail coffins and educate their kids. Just look @ IP.
Can't squeeze
a vague bit out in the header anywhere anymore (if we could, SPAM would be
using it already ;-).
. The problem with being tight on specification of behavior in such
scenarios is
that it blows up the spec very much and those redundant pieces need carefull
maintainance since when broken become meta-confusing. The other problem is
that a certain vagueness gives better implementations and sometimes a little
hatch to cheat things out later in the protocol behavior. As last argument,
on the other hand, being left with implementatoins hiding a zoo of
behavior-changing
knobs can become quite, let's say, undesirable and we all know good
examples I guess.

Ultimately, it's a philosophical decision with a good shot of real-world
politics
and pressure influencing it.

    --- tony