Re: [Anima] Consolidated floods [was Signing GRASP objectives]
On 26-Aug-22 20:02, Toerless Eckert wrote: Btw.: I have no strong opinions either way, and i am not the one who put a + in front of objective for the flood-message. Aka would be curious about the reason Brian wanted to support multiple objectives in it! Let me check my archive... unfortunately all I can tell you is that we added the multiple objectives feature in the first week of August 2016, while the GRASP design team was discussing several aspects of the M_FLOOD. I can't see any discussion of that particular change. Brian Cheers Toerless On Fri, Aug 26, 2022 at 09:14:42AM +1200, Brian E Carpenter wrote: On 26-Aug-22 08:59, Michael Richardson wrote: Brian E Carpenter wrote: > (b) but it could be implemented *on top* of the current > definition of GRASP, if the floods in question were issued with a loop > count of 1 (so they would never be relayed per RFC8990), and there was > a flood consolidator - effectively just a special ASA as far as GRASP > is concerned - that sent out consolidated floods. why couldn't the flood consolidator collect and relay things with higher loop counts, as long as it didn't do it too often? (is that called a "dam"? sluicegate? me wastes ten minutes reading about dams on wikipedia) Yes, it could, once the consolidation was done. I suspect this idea overlaps with the use cases for draft-ietf-anima-grasp-distribution. Brian . ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Consolidated floods [was Signing GRASP objectives]
This can and should be included in the draft-ietf-anima-grasp-distribution, but I doubt it has. I will add some text in my next refine (I have soon gotten some time cycle to refine draft-ietf-anima-grasp-distribution following Michael's early comments. Sheng > Brian E Carpenter wrote: > > (b) but it could be implemented *on top* of the current > > definition of GRASP, if the floods in question were issued with a loop > > count of 1 (so they would never be relayed per RFC8990), and there was > > a flood consolidator - effectively just a special ASA as far as GRASP > > is concerned - that sent out consolidated floods. > > why couldn't the flood consolidator collect and relay things with higher loop > counts, as long as it didn't do it too often? > (is that called a "dam"? sluicegate? me wastes ten minutes reading about dams > on wikipedia) Yes, it could, once the consolidation was done. I suspect this idea overlaps with the use cases for draft-ietf-anima-grasp-distribution. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Consolidated floods [was Signing GRASP objectives]
Btw.: I have no strong opinions either way, and i am not the one who put a + in front of objective for the flood-message. Aka would be curious about the reason Brian wanted to support multiple objectives in it! Cheers Toerless On Fri, Aug 26, 2022 at 09:14:42AM +1200, Brian E Carpenter wrote: > On 26-Aug-22 08:59, Michael Richardson wrote: > > > > Brian E Carpenter wrote: > > > (b) but it could be implemented *on top* of the current > > > definition of GRASP, if the floods in question were issued with a > > loop > > > count of 1 (so they would never be relayed per RFC8990), and there > > was > > > a flood consolidator - effectively just a special ASA as far as GRASP > > > is concerned - that sent out consolidated floods. > > > > why couldn't the flood consolidator collect and relay things with higher > > loop > > counts, as long as it didn't do it too often? > > (is that called a "dam"? sluicegate? me wastes ten minutes reading about > > dams on wikipedia) > > Yes, it could, once the consolidation was done. > > I suspect this idea overlaps with the use cases for > draft-ietf-anima-grasp-distribution. > >Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Consolidated floods [was Signing GRASP objectives]
On 26-Aug-22 08:59, Michael Richardson wrote: Brian E Carpenter wrote: > (b) but it could be implemented *on top* of the current > definition of GRASP, if the floods in question were issued with a loop > count of 1 (so they would never be relayed per RFC8990), and there was > a flood consolidator - effectively just a special ASA as far as GRASP > is concerned - that sent out consolidated floods. why couldn't the flood consolidator collect and relay things with higher loop counts, as long as it didn't do it too often? (is that called a "dam"? sluicegate? me wastes ten minutes reading about dams on wikipedia) Yes, it could, once the consolidation was done. I suspect this idea overlaps with the use cases for draft-ietf-anima-grasp-distribution. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Consolidated floods [was Signing GRASP objectives]
Brian E Carpenter wrote: > (b) but it could be implemented *on top* of the current > definition of GRASP, if the floods in question were issued with a loop > count of 1 (so they would never be relayed per RFC8990), and there was > a flood consolidator - effectively just a special ASA as far as GRASP > is concerned - that sent out consolidated floods. why couldn't the flood consolidator collect and relay things with higher loop counts, as long as it didn't do it too often? (is that called a "dam"? sluicegate? me wastes ten minutes reading about dams on wikipedia) -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
