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

["Liubing (Leo)" <[e-mail]>]

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". 
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