Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02

From: Vishwas Manral <[email-masked]>
Date: Thu, 17 Mar 2005 21:55:46 -0800

Hi Alex,

> I'll try one more time.
I am sorry to have troubled you.

> We do NOT have an interoperability issue unless we start 
> deliberately introducing new link types without making sure 
> everyone understands them.
So what anyone needs to do to get the entire OSPF domain go haywire is
to
be able to inject an LSA with an unknown link type.

We could argue that a lot more can be done by injecting wrong
information,
However in my view it does not mean we leave something undefined for
someone
to exploit (we could have similar arguments about a lot of other cases).

I am ok to drop the draft as is. Maybe if and when we face problems we
will try to find a solution. However it would be great if you can state
a clear yes to the following (or specify an alternative text). It is not
helpful to define how the receiving side should behave in case it
receives an undefined field even if it causes loops in the system,
because such things would not generally occur.

Also Alex as in my last mail, I am still eager to know why the design
decision is wrong to put
http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt in
the Reachability TLV and why we can have the same in OSPF Router LSA? 

Thanks,
Vishwas
======================================================================

Vishwas,

I'll try one more time.

> If someone wants to write an implementation of OSPF, what does he/she
do
> regarding unknown link types?

We discussed this earlier in this thread.

> We need to define the behavior else we
> will never get interoperability. I guess we both agree with the above.

We do NOT have an interoperability issue unless we start deliberately
introducing new link types without making sure everyone understands
them.

> If I understood the discussion in the mailing list right, most
> implementations ignore the link and that is what we are trying to
> standardize.

A few years ago we had a discussion that touched on link records. John
mentioned
that there are still implementations out there that will ignore the
whole LSA
when the see an unknown link type. I don't think we can ignore this.

> The suggestion you make will not interoperate with the
> installed base at all while a MUST ignore solution will with most of
> them.

I don't understand what you mean by "will not interoperate".

Alex

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 20 Mar 2005 20:19:08 -0800

Hi,

Let me summarize then, there are 4 cases the unknown link type can
occur: -

1. Malicious user inserts the LSA.
2. Error before LSA checksum is calculated.
3. Memory corruption/ LSA error after checksum yet checksum correct.
4. New Link type is added (examples of what all can be added is detailed
in the IS-IS route-tags draft/ experimental TLV draft).

In all but the case 3, the solution proposed works. I am not aware of
any protocol which works in face of case 3 at all (it may not even be a
protocol specific action at all).

Acee/ Alex let me know your views.

Thanks,
Vishwas
-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Saturday, March 19, 2005 7:46 PM
To: [email-masked]
Subject: Re: Comments on draft-manral-ospf-router-lsa-unknown-type-02

Hi Alex,
I don't feel that strongly on whether or not we need to document the
behavior when an unknown link type is encountered. However, I was
content to ignore them and leave the backward compatibility issues
to those proposing new link types. If there were compelling reasons to
introduce a new link type we are now relegated to a solution where we
need protocol mechanisms to assure that every router in the area
understands
it prior to it's usage and, depending on the link type, this may be more
conservative than what is needed.

Thanks,
Acee

do
them.
mentioned
whole LSA

---

From: Dave Katz <[email-masked]>
Date: Wed, 30 Mar 2005 08:18:06 -0700

On Mar 29, 2005, at 7:07 PM, Acee Lindem wrote:

>> One of the dominant implementations will silently skip the bad link 
>> type and go on to the next link.  Can't speak for the other one.
>
> Since this is what Vishwas' draft recommends, can we take this as a 
> vote for adoption
> of his draft :^) ?

I abstain based on lack of involvement...

>
>
>>
>>
>> It's worth defining what to do in this case, but it is essentially 
>> academic until a new link type is defined.  Unfortunately, it will 
>> have little effect on the eventual outcome if that happens, given 
>> that it's 15 years too late.
>
> It is true that this is late but at least it would provide a migration 
> path. In a perfect
> world, an OSPF routing domain is under a single administrative 
> authority and that
> authority should have some control over what is deployed.

Just pointing out that it's not a perfect world, and that customers' 
desire to upgrade software, if necessary, will be based on far more 
important considerations than whether the software conforms to this 
draft.

--Dave

---

From: Dave Katz <[email-masked]>
Date: Wed, 30 Mar 2005 08:19:47 -0700

On Mar 29, 2005, at 6:22 PM, Erblichs wrote:

> 	Don't we think that some testers has already
> 	generated undefined link types to make sure
> 	that their implementation doesn't crash?

This is probably true, though I was referring to 3rd party conformance 
testers, which by definition cannot officially test this case as there 
is no conformance to verify.

>
> 	Thus, my worst fear is that some routers
> 	will create different LSDBs from others,
> 	these non synch LSDBs will create periodic
> 	black holes, etc AND NOBODY  is aware
> 	that this is happening...

This is probably the worst case scenario.

My points, perhaps steeped in a bit too much sarcasm, are this:

If nobody ever actually adds a new link type to OSPF, this draft is 
entirely harmless.

If a new link type is added to OSPF at some point, whatever is said in 
this draft will have no effect on the vast majority of deployed 
systems, and they will *never* all be upgraded.  Further, as others 
have pointed out, the implications of a new link type cannot be 
addressed by this draft, as such a new link type is likely to impact 
the route calculation and could easily lead to a broken network unless 
all systems support it.  The only safe way to add such a thing would be 
to change something guaranteed to be noticed by older implementations, 
and the only thing guaranteed would be to bump the version number.

I don't buy the argument that adding a phrase to the spec would somehow 
make people think that new link types could be added willy-nilly 
without breaking things.  Hopefully the OSPFWG of the future will not 
be that stupid, and if they are, well, this is the least of their 
problems.

The Founding Fathers that spec'ed OSPF back in the olden days did not 
expend a lot of effort to try to make OSPF extensible, and this 
particular nit is only a small part of that problem.

I have no particular objection to adding this language to the spec, but 
the idea that it will have any meaningful effect is unrealistic.  The 
number of electrons killed to discuss it have already been excessive 
relative to its merits.  Harmless, but a solution chasing a nonexistent 
problem.  IMHO.

--Dave