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

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

Hi Brian,

I was out for a little errand this noon, so didn't reply you timely. The new version looks good to me, thank you.


Just a bit more discussion as the following. (Not necessary to finish the discussion this time, we can always discuss it after your travel.)

> > [Bing] The Response message probably not pass through the relay
> > devices;
> 
> It must - it's an on-link process. The Discovery Response goes to the relay
> node that sent the link-local multicast. Then the relay has to send a
> Discovery Response itself to the initiator.

[Bing] If the initiator is a GUA/ULA, maybe it's good to allow the responder directly send the Discovery-Response msg to the initiator?

From technical perspective, relaying Discovery-Response is only necessary when the initiator is an link-local address. But in this case, the relay devices need to record the multicast source of a given SessionID+Initiator pair, and route back the Discovery-Response in a complete reverse path. That is some additional complexity. 

So, I was wondering whether the link-local address initiator is a corner case? If it is, is it worth to be addressed by this additional complexity?
So far I don't have a clear answer, I'd like to hear your opinions.

Have a good trip.

Best regards,
Bing


> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Friday, March 11, 2016 12:41 PM
> To: Liubing (Leo); Anima signaling DT
> Cc: Joel M. Halpern
> Subject: Re: [Anima-signaling] draft-ietf-anima-grasp-04A
> 
> On 11/03/2016 16:06, Liubing (Leo) wrote:
> >> -----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;
> 
> It must - it's an on-link process. The Discovery Response goes to the relay
> node that sent the link-local multicast. Then the relay has to send a
> Discovery Response itself to the initiator. I have added some text for that.
> 
> > and the Discovery timeout is only available for the discovery initiator.
> 
> Yes, there is a point missing there: the relaying node doesn't know the
> original timeout, so it has to use the default. I will add that to the text.
> 
> Actually there's no real solution to that in any case: if a Discovery Response
> arrives too late, it will be wasted. So if the initiator sets a very small timeout
> it will never get an answer. The only real purpose of the timeout is to avoid
> wating for ever.
> 
> So now the text reads:
> 
>          If an ASA in the neighbor device supports the requested
>          discovery objective, it MAY respond to the link-local multicast
>          with a unicast Discovery Response message (Section 3.7.4) with
>          locator option(s). ...
> 
>          <snip>
> 
>          A GRASP device with multiple link-layer interfaces (typically a
>          router) MUST support discovery on all interfaces.  If it
>          receives a Discovery message on a given interface for a
>          specific objective that it does not support and for which it
>          has not previously cached a Discovery Responder, it MUST relay
>          the query by re-issuing a Discovery message as a link-local
>          multicast on its other interfaces.  The relayed discovery
>          message MUST have the same Session ID as the incoming
> discovery
>          message and MUST be tagged with the IP address of its original
>          initiator.  Since the relay device is unaware of the timeout
>          set by the original initiator it SHOULD set a timeout at least
>          equal to GRASP_DEF_TIMEOUT milliseconds.
> 
>          The relaying device MUST decrement the loop count within the
>          objective, and MUST NOT relay the Discovery message if the
>          result is zero.  Also, it MUST limit the total rate at which it
>          relays discovery messages to a reasonable value, in order to
>          mitigate possible denial of service attacks.  It MUST cache the
>          Session ID value and initiator address of each relayed
>          Discovery message until any Discovery Responses have arrived or
>          the discovery process has 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.  These
>          precautions avoid discovery loops and mitigate potential
>          overload.
> 
>          The discovery results received by the relaying device MUST in
>          turn be sent as a Discovery Response message to the Discovery
>          message that caused the relay action.
> 
> The relay process needs a diagram to explain but I don't have time today.
> OK if I submit the draft? I can clarify this in the slides for the IETF.
> 
> Regards
>     Brian
> 
> 
> 
> > 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
> >>>