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

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

Coming back to this point...
On 11/03/2016 21:00, Liubing (Leo) wrote:
> 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. 

Mathematically, that is true. But remember that several different Discovery-Responses
may arrive for the same Discovery, some on-link and some off-link. They should all
be collected (as long as they arrive before the timeout).

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

Actually it turned out to be quite simple. Every node needs a discovery cache, so
when the relay receives a Discovery-Response it simply caches it. And then the
original discovery thread picks it up automatically from the cache. So there
was no extra code to make this work. (I have to say this is not fully tested
because it needs quite a complicated test network. But every code path has been
tested.) It has the advantage that the relay node now has a cached locator
for any other Discovery initiator, so the next time no relay is needed.

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

I think it will be essential during bootstrap, before the ACP addresses are
assigned. I agree that when the ACP is running, we could send direct Discovery-
Responses, but they will not be cached in the relay node.

Regards
    Brian

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