I suppose the 0xffff sequence number is intended for force-feed a new configuration to a handful of peers known to the configuration server (although such method/policy is not spelled out by the draft). Beyond that, section 5.3.2.1 (checking sequence number of a request) is the only means defined by this draft to propagate new configuration document. It's hardly a corner case.
Am I missing something else? Thanks --Michael > -------- Original Message -------- > Subject: Re: [P2PSIP] ConfigUpdateReq flooding > From: Cullen Jennings <[email protected]> > Date: Tue, August 09, 2011 2:17 pm > To: Michael Chen <[email protected]> > Cc: [email protected] > > > 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
