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

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

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Friday, March 11, 2016 11:03 AM
> To: Liubing (Leo); Anima signaling DT
> Cc: Joel M. Halpern
> Subject: Re: [Anima-signaling] draft-ietf-anima-grasp-04A
> 
> 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.
[Bing] The Response message probably not pass through the relay devices; and the Discovery timeout is only available for the discovery initiator. 
So for the relay devices, it should be hard to judge the end?

B.R.
Bing

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