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

From: Vishwas Manral <[email-masked]>
Date: Tue, 15 Mar 2005 21:11:52 -0800

Hi Alex,

Thanks for the detailed mail. I have a few minor points: -

> 1) LSA creation malfunction at the originating router, before 
> the LSA checksum is calculated.
If we ignore the Link in this case I am not sure how we can have
inconsistent routing tables.

> 2) Memory corruption at the calculating router before LSA's 
> checksum is rechecked.
I agree in this case there is no way and loops will occur till the
checksum check interval. Action taken in this would be independent of
protocol.

> 3) The originating router implements an extension of OSPF that
introduces
> a new link-type that is not part of the basic OSPF functionality.
In this case too as long as we are sure no routing loops are occurring
it will not cause any problems. Adding a bit which allows SPF changes in
certain cases can cause loops in case an old router does not understand
them.

Do let me know if I am missing the point?

Thanks,
Vishwas
-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Alex
Zinin
Sent: Wednesday, March 16, 2005 10:10 AM
To: [email-masked]
Subject: Comments on draft-manral-ospf-router-lsa-unknown-type-02

Folks-

 Here's the write-up of the comment I brought at the meeting in
Minneapolis.

 What the draft says is (briefly):
   a) ignore unknown link-types (Section 2)
   b) now that we ignore unknowns, introduction of new link types is
possible (Section 4)
   c) when introducing new link types, make sure routing loops are not
created (Section 4)

 Noting that processing of the 4 current link types is part of the
protocol's
 core functionality, that every OSPF router must be able to perform, we
have the
 following scenarios where SPF meets an unknown link type:

   1) LSA creation malfunction at the originating router, before the LSA
      checksum is calculated.
   2) Memory corruption at the calculating router before LSA's checksum
      is rechecked.
   3) The originating router implements an extension of OSPF that
introduces
      a new link-type that is not part of the basic OSPF functionality.
      
 In cases 1 and 2, silently ignoring the unknown link type is
ill-advised, since
 it is extremely likely that routers will end up with inconsistent
routing
 tables and loop traffic for a long time. At the very least, the router
should
 "shout" very loudly. Whether the implementation should then (after
shouting)
 ignore the unknown link and continue SPF calculation, stop the SPF
calculation
 there, cancel SPF and retain old routes, or do anything else is not a
clear
 choice and will depend on what the admin likes more--loops or
blackholes. One
 could probably imagine different sorts of creative things (that I would
 personally not entertain) here.

 In case 3, something has obviously gone wrong. Changes affecting basic
IP
 routing table calculation in OSPF were always introduced with a new
Options
 bit. Introducing new link types that would affect routing table
calculation
 without a new Option bit would be ill-advised again, since this would
lead to
 long-term routing loops. Since such situation should not be legitimate,
 silently ignoring unknown link types here is also not a good idea.
 
 Given the above, I suggest that the related part of the spec is left
intact and
 new link types are introduced with corresponding new Option bits.

 Comments are welcome.
 
-- 
Alex
http://www.psg.com/~zinin

---

From: Alex Zinin <[email-masked]>
Date: Tue, 15 Mar 2005 22:36:22 -0800

Vishwas,

> inconsistent routing tables.

Good point. If everyone ignores consistently, including the misbehaving
(originating) router, no loops will form in this case.

> checksum check interval. Action taken in this would be independent of

I missed another case from the same category:

  x) Data corruption not caught by the checksum. (Not completely improbable
     given the properties of Fletcher.)

>> 3) The originating router implements an extension of OSPF that introduces a
>> new link-type that is not part of the basic OSPF functionality.

> it will not cause any problems.

How would you propose we do that?

> Adding a bit which allows SPF changes in

The Options bits in OSPF Hellos and DDs will allow the routers implementing
the new link types to reject adjacencies with routers that are incapable
of processing them (and hence not setting the bit).

Alex