Subject: Re: [P2PSIP] ConfigUpdateReq flooding

From: "Michael Chen" <[email-masked]>
Date: Fri, 05 Aug 2011 18:36:59 -0700

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Aug 2011 14:17:10 -0700

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:

> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip