Draft authors -
The WG adoption call reminded me that I had some questions following the
presentation of this draft at IETF 114 which we decided to "take to the list" -
but we/I never did.
Looking at the minutes, there was this exchange:
<snip>
Les: I'm not convinced that you don't need to advertise
whether a node needs support this. If not, why not define
this as an algorithm and use the dynamic flooding?
Tony P: First bring me a case why we need to signal this.
Les: If I'm not going to flood and I'm expecting someone else
to flood, and I don't know whether we're in sync.
Tony: Think it through, the mix with old nodes just fine. The
old guy still do the full flooding and that's fine.
Les: You use the term up-to-date PSNP, I have no idea how you
determine whether the PSNP is "up-to-date"? unlike CSNP,
PSNP doesn't have the info.
Tony: You have to list all those things.
Les: Let's take it to the list.
<end snip>
Question #1: Why not define this as an algorithm and use
draft-ietf-lsr-dynamic-flooding (in distributed mode)?
This question is of significance both from a correctness standpoint and what
track (Informational or Standard) the draft should target.
Tony P's reply above suggests this isn't needed - but I don't think this is
true. The draft itself says in Section 2.1:
<snip>
Once this flooding group is determined, the members of the flooding
group will each (independently) choose which of the members should
re-flood the received information. Each member of the flooding group
calculates this independently of all the other members, but a common
hash MUST be used across a set of shared variables so each member of
the group comes to the same conclusion.
<end snip>
If a "common hash MUST be used across a set of shared variables" (and I agree
that it MUST) then all nodes which support the optimization MUST agree to use
the same algorithm. Given that there are likely many hash algorithms which
could be used, some way to signal the algorithm in use seems to be required.
By publishing a given algorithm(including the hash) and having it assigned an
identifier in the registry defined in
https://www.ietf.org/archive/id/draft-ietf-lsr-dynamic-flooding-11.html#section-7.3
- and using the Area Leader logic defined in the same draft, consistency is
achieved.
Without that, I don't think this is guaranteed to work.
Note the issue here has nothing to do with legacy nodes - I agree with Tony P's
comment above that legacy nodes do not present a problem - they just limit the
benefits.
Question #2: Please define and demonstrate how "up-to-date PSNPs" work to
recover from flooding failures.
We know that periodic CSNPs robustly address this issue - and their use has
been recommended for flooding reduction solutions over the years.
Please more completely define "up-to-date PSNPs" and spend some time
demonstrating how they are guaranteed to work - and consider in that discussion
that transmission of SNPs of either type is not 100% reliable.
Thanx.
Les
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
