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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Mar 2016 11:50:58 +1300

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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 11 Mar 2016 02:33:35 +0000

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:[email-masked]] 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
> Co-authors: any comments or objections? I'd like to post this draft during
> this week, as I will be on vacation next week.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2016 16:02:30 +1300

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

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.

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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 11 Mar 2016 03:06:30 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> 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
> 
> > 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".
> 
[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
> 
> >> From: Anima-signaling [mailto:[email-masked]] On
> >> Behalf Of Brian E Carpenter
> >> connected in a loop by 3 or more routers, GRASP multicasts (Discovery
> >> and Flood Synch
> >> 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.
> >>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Mar 2016 17:41:07 +1300

On 11/03/2016 16:06, Liubing (Leo) wrote:
> [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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 11 Mar 2016 08:00:01 +0000

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

> 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

> Sent: Friday, March 11, 2016 12:41 PM
> >> Actually the end of discovery is well-defined. Either the relayed
> >> discovery receives a Response message or the discovery timeout itself
> expires.
> 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.
> 
> >> 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
> >>>
> >>>
> >>>> (Discovery and Flood Synch
> >>>> 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 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.)
> >>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2016 15:10:44 +1300

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