The issue is we don't want to mandate that nodes that are purely forwarding a request have to check the config version. Theses nodes should be able to forward the request quickly without having to parse and interpret the whole request. In practice, when a new configuration files gets put out, it quickly floods the whole network so this is all pretty much a corner case. Making every message be checked would slow things down more than a message getting forwarded a few times before the destination node checked it in the rare case where there is a config update. Hope that makes sense - it's sort of hard to explain in email.
On Aug 5, 2011, at 18:36 , Michael Chen wrote: > > Funny how one can understand his own question better afterward. This > topic stems from section 5.3.2.1 of the base draft, 2nd paragraph: > > "When a **destination** node receives a request, it MUST check that > the configuration_sequence field is equal to its own ..." > > Here are some possible interpretations: > > 1) The phrase "destination node" seems to suggest that only the > "ultimate" destination peer (whom the message was meant for) should > check/respond/update an out-dated configuration_sequence. > > 2) An intermediate peer should forward a knowingly out-dated > configuration_sequence number in the forwarding header. Section 5.3.2 > does not say that this field should be replaced in every hop. > > I suggest removing the word "destination" from the above paragraph and > make it clear that any request with an out-dated configuration_sequence > will never go beyond its first hop (immediate neighbor). > > Thanks > > --Michael > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
