Re: [Tsv-art] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06

["Les Ginsberg (ginsberg)" <[e-mail]>]

In regards to "operation on a LAN interface",



>

> > Section 6.2.1.2:

> > “f no PSNPs have been generated on the LAN for a suitable period of time,

> then an LSP transmitter can safely set the number of un-acknowledged LSPs to

> zero.

> > Since this suitable period of time is much higher than the fast

> acknowledgment of LSPs defined in Section 5.1, the sustainable transmission

> rate of LSPs will be much slower on a LAN interface than on a point-to-point

> interface.”

> >

> > What a suitable period of time? Can you be more concrete?

>

> [Bruno] Good question. But difficult question.

> Les, would you have some suggestion?

> Otherwise, rather than adding more text for the LAN case, I'd rather remove

> some text with the following change

>

> OLD:

> However, an LSP transmitter on a LAN can infer whether any LSP receiver on

> the LAN has requested retransmission of LSPs from the DIS by monitoring

> PSNPs generated on the LAN. If no PSNPs have been generated on the LAN for

> a suitable period of time, then an LSP transmitter can safely set the number of

> un-acknowledged LSPs to zero. Since this suitable period of time is much

> higher than the fast acknowledgment of LSPs defined in Section 5.1, the

> sustainable transmission rate of LSPs will be much slower on a LAN interface

> than on a point-to-point interface.

>

> NEW: /nothing/

>

> As already stated, probably one could do better in the LAN case. E.g.,

> advertising the delay between periodic CSNP (which would answer your

> question), sending in (LSP-ID) order, having the receiver send PSNP on a range

> of LSP-ID after a specific delay/LPP. But again, LAN is not seen as the priority in

> this document.

>

[LES:] As has been noted, we already say in Section 4.7 (which does discuss the LAN issues)



"A full discussion of how best to do faster flooding on a LAN interface is therefore out of scope for this document."



The problem (as Bruno has indicated) as regards operational practices is that whatever we say will be incomplete and to some extent unsatisfactory as we have not studied this problem.

There are no doubt many things that could be said - but no collection results in a sound operational description of how to do fast flooding on a LAN.

I think we would be better off (and more honest 😊) if in Section 6.2.1.2 we simply said:



"As operation of fast flooding on a LAN interface is out of scope for this document, this section is intentionally empty."



??



   Les