Subject: Re: regarding ospf las flushing .....

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 8 Jun 2005 16:51:56 -0700

Anup

This was already done in a major implementation. I think it was a good idea.

You have to be careful though as this might break some implementation who
access the body of the lsa on flushing ( though I don't see why they 
would do that).

I'm for it and can collaborate. This can initiate a discussion on the list.

Padma

anup wrote:

> Hello Padma,
>
> As per RFC 2328, we send the lsa (header + body) to the peer though 
> the lsa is maxaged.
>
> Considering that the peer would not examine the lsa body if the lsa is 
> maxaged, *if we could send only the maxaged lsa’s header*, it would 
> reduce a lot of traffic as well as the protocol memory consumption 
> during flushing.
>
> If you agree with this idea, I would like to prepare a small draft on 
> this.
>
> Regards,
>
> Anup
>

---

From: Don Goodspeed <[email-masked]>
Date: Wed, 8 Jun 2005 16:58:08 -0700

Padma,

How does one address the issues of summary and external
LSAs where the LSID "may" change depending upon Appendix
E of RFC2328.  In those cases, isn't including the subnet
mask needed?  Otherwise, an incorrect LSA could be flushed.

-don

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Wednesday, June 08, 2005 4:52 PM
To: [email-masked]
Cc: [email-masked]; Padma Pillay-Esnault
Subject: Re: regarding ospf las flushing .....

Anup

Padma

anup wrote:

> maxaged, *if we could send only the maxaged lsa's header*, it would

---

From: Quaizar Vohra <[email-masked]>
Date: Wed, 8 Jun 2005 17:23:27 -0700

But that major implementation had to revert to sending the entire
LSA (header + body) because another major implementation did not
like it :).

Have gone thru enought pain on this subject and would prefer not
having to do yet another revision. As far as efficiency and memory
is concerned, I wouldn't worry too much about it for this particular
case.

Quaizar

---

From: Dave Katz <[email-masked]>
Date: Wed, 8 Jun 2005 17:30:06 -0700

The tuple of originating router, LSA ID, and LSA type *always* uniquely 
and completely identifies an LSA, by definition.

There can never be any ambiguity about which LSA is being flushed, even 
when only the header is sent.  The only way this could even 
conceptually be an issue is if an implementation thought it could send 
two different external routes with the same LSA ID but different masks, 
but this is not allowed (I seem to recall that there was evidence that 
some misguided implementation attempted such a thing recently.)

I wrote the Juniper implementation this way back in '97 and things 
worked swimmingly until a broken implementation came along that tried 
to access the contents of the LSA before noticing that it was being 
flushed, and did something bad (like crashed.)  I don't recall offhand 
how this was resolved, though I'm sure I resisted changing our 
implementation.

--Dave

---

From: mike shand <[email-masked]>
Date: Thu, 9 Jun 2005 11:01:02 +0100

Of course a certain other Link State Protocol has always specified that 
this is what you should do i.e. send only the header, (not that all 
implementations follow the spec in this regard:-)

         Mike

At 00:51 09/06/2005, Padma Pillay-Esnault wrote:
>access the body of the lsa on flushing ( though I don't see why they would 
>do that).
>
>>As per RFC 2328, we send the lsa (header + body) to the peer though the 
>>lsa is maxaged.
>>
>>reduce a lot of traffic as well as the protocol memory consumption during 
>>flushing.
>>
>>If you agree with this idea, I would like to prepare a small draft on this.
>>
>>Regards,
>>
>>Anup

---

From: Acee Lindem <[email-masked]>
Date: Thu, 9 Jun 2005 12:58:43 -0400

>is concerned, I wouldn't worry too much about it for this particular
I guess I'd have to agree with this. There would have to be some WG 
momentum and we'd
need to address the backward compatibility issues given that we know 
there are deployed
implementations that have problems with the header-only LSA flush.

BTW, I previously worked on a less-deployed (avoiding the adjective 
"minor") implementation
that accepted header-only LSA flushes but would not send them :^)

Thanks,
Acee

---

From: Dave Katz <[email-masked]>
Date: Thu, 9 Jun 2005 12:02:18 -0700

On Jun 9, 2005, at 3:01 AM, mike shand wrote:

> Of course a certain other Link State Protocol has always specified 
> that this is what you should do i.e. send only the header, (not that 
> all implementations follow the spec in this regard:-)

Yes, and a certain implementor who had previously implemented the 
certain Link State Protocol took this to heart when implementing the 
uncertain Link State Protocol.  ;-)

--Dave