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

From: Vishwas Manral <[email-masked]>
Date: Tue, 15 Mar 2005 22:46:12 -0800

Hi Alex,

>> In this case too as long as we are sure no routing loops are 
>> occurring it will not cause any problems.
> How would you propose we do that?
The way to impose it is that we do not allow any standard link type
extensions which can cause routing changes and hence loops.

I think adding the option bit as you suggest will help for sure. However
the point is do we want to extend OSPF that way (we already have opaque
LSA's). If there is demand to add information which can cause routing
changes, we could go in for the heavier extension as you suggest.

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

Vishwas,

> 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.

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

>> 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.

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.

> In this case too as long as we are sure no routing loops are occurring
> it will not cause any problems.

How would you propose we do that?

> Adding a bit which allows SPF changes in
> certain cases can cause loops in case an old router does not
understand
> them.

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

---

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

Vishwas,

> extensions which can cause routing changes and hence loops.

Seems it's time to put the cards on the table :) What kind of information
do you think we would put in link records?

We need to keep in mind that we only have one router LSA per router and its size
needs to be well-controlled. I personally would be reluctant to put there
anything that isn't related to the basic topology abstraction.

> changes, we could go in for the heavier extension as you suggest.

This is what was done for stub and NSSA areas. I would use the same method for
other extensions that affect route calculations. If they don't, then the
question is whether this info belongs in the router-LSA at all.

Alex