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

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

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