Re: regarding ospf las flushing .....

[Acee Lindem <[e-mail]>]

Quaizar Vohra wrote:

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


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