Re: [Anima-signaling] draft-ietf-anima-grasp-04A

[Brian E Carpenter <[e-mail]>]

On 11/03/2016 15:33, Liubing (Leo) wrote:
> Hi Brian,
> 
> Thanks for the update. I only have a minor comment.
> 
>  " It MUST cache the	
>    Session ID value and initiator address of each relayed	
>    discovery message until the discovery process has ended or	
>    timed out.  To prevent loops, it MUST NOT relay a Discovery	
>    message which carries a given cached Session ID and initiator	
>    address more than once."
> 
> I think it is hard for the relays to judge whether the Discovery process has ended/time out. Even the initiator could only do "time out" count (GRASP_DEF_TIMEOUT), not solid judgment of "Discovery end".

Actually the end of discovery is well-defined. Either the relayed discovery
receives a Response message or the discovery timeout itself expires.
So the discovery code already does disactivate the cached entry
automatically, even for a normal (not relayed) discovery.

I'm not sure I know how to explain that in the text though, let me have
a quick look. Then I will submit the draft because I will be on travel
from tomorrow.

Regards
   Brian

> So maybe we also recommend a value of twice the GRASP_DEF_TIMEOUT, just as the Flood Synchronization case.
> 
> Best regards,
> Bing
> 
> 
>> -----Original Message-----
>> From: Anima-signaling [mailto:[e-mail]] On Behalf
>> Of Brian E Carpenter
>> Sent: Tuesday, March 08, 2016 6:51 AM
>> To: Anima signaling DT
>> Cc: Joel M. Halpern
>> Subject: [Anima-signaling] draft-ietf-anima-grasp-04A
>>
>> Hi Design Team, Joel,
>>
>> Attached is proposed update to GRASP that hopefully fixes a serious looping
>> issue that Joel noticed in the -03 draft.
>>
>> The issue was that in a physical topology with 3 or more LANs connected in a
>> loop by 3 or more routers, GRASP multicasts (Discovery and Flood Synch
>> messages) would have looped until the loop count reached zero.
>>
>> The fix was to revert to the 'initiator' field previously included in the -02 draft,
>> but with the logic properly worked out this time ;-).
>>
>> I've both observed the problem in the -03 version of the prototype code, and
>> shown that the fix works in a new -04 version of the code. (I didn't need to
>> build a router loop; when the code is set to listen to its own multicasts, it
>> simulates an infinite router loop.)
>>
>> Co-authors: any comments or objections? I'd like to post this draft during
>> this week, as I will be on vacation next week.
>>
>> Txt file and diffs attached. I will post the XML to GitHub.
>>
>> Regards
>>    Brian
>