Subject: Re: [Anima-signaling] grasp-02: 48 hours last call before posting

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 11 Jan 2016 09:56:48 +0000

Hi Brian,

Thanks for the frequent and comprehensive update, I think it already covers most of the open issues. And sorry for my late response.
Please see some comments, which are based on 01-02d diff.

1. Section 3.1.1
> The ACP MUST carry all messages securely, including link-local multicast if possible. 
[Bing] This sentence sounds like it is the ACP's duty to decide which messages to be secured. But actually the ACP is not responsible for that decision, any messages go into the ACP will be secured naturally. GRASP or other function/protocol stack decide whether the messages go to ACP.
> Link-local multicast is used for discovery messages. It is preferred that the ACP will handle these and distribute them securely to all on-link ACP nodes only.
[Bing] For link-local multicast, since the ACP is an L3 overlay, if multiple nodes are attached to the same link, I think it cannot prevent the messages going to the un-secured L2 link according to normal behavior. Unless the GRASP engine intentionally send out the link-local multicast packets exclusively into the ACP interface. So, this issue in my mind might be a GRASP internal behavior issue. 

2. Section 3.3.5.1 Flooding
> If it receives a multicast Flood message on a given interface, it MUST	relay it by re-issuing a Flood message on its other interfaces. The relayed message MAY have a different Session ID.
[Bing] Is there any concern that different Session IDs for the same flood message? 
My rough idea is that the same Session ID might be beneficial to identify the flooded message. E.g., the interface could easily examine whether the message had been relayed once.

3. Regarding to the organization/naming of messages
(This is a premature idea for discussion, not necessarily mean any revision proposal)
According to different functions, we have the following message (pairs):
- Discovery & Response
- Request & Negotiation & Negotiation_End
- Request & Synchronization
- Confirm_waiting
- Flood
Sometimes my mind was confused by following factors:
1) "Request" is usually coupled with "Response" in other protocols. In GRASP, it's not. This might create a little bit trouble to remember the specific meaning of the two words in GRASP.
2) "Request" is overloaded for both Negotiation and Synchronization. Also a little bit confusion maker.

So, I was think the possibility to re-organize/re-name the messages as:
- Discovery & Discovery_Res
- Negotiation_Init & Negotiation & Negotiation_End
- Synchronization & Synchronization_Res
- Confirm-waiting
- Flood
This seems more institutive for me. But I'm not sure it is a MUST-BE-FIXED problem.

Btw, the message name "Flooding message" is a very common/abstract phrase, can we find another more precise name? E.g., "Flooded Synchronization" or "Unsolicited Synchronization". However, I can live with "Flood Message" if no other better one.

Best regards,
Bing

> -----Original Message-----
> From: Anima-signaling [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Sunday, January 10, 2016 8:45 AM
> To: Liubing (Leo); Carsten Bormann
> Cc: Anima signaling DT
> Subject: [Anima-signaling] grasp-02: 48 hours last call before posting
> 
> Hi,
> 
> Here is my proposed final candidate for draft-ietf-anima-grasp-02 (1st
> attachment).
> Bing and Carsten: if I don't hear from you in 48 hours, I will post this version.
> Others in design team: comments very welcome.
> 
> 2nd attachment: The diffs from the previous candidate.
> 3rd attachment: The diffs from the -01 version.
> 
> I will upload the xml to github.
> 
> For reference, here are the protocol changes since -01:
> 
>    Protocol change: only allow one objective in rapid mode.
> 
>    Protocol change: added optional error string to DECLINE option.
> 
>    Protocol change: removed statement that seemed to say that a Request
>    not preceded by a Discovery should cause a Discovery response.  That
>    made no sense, because there is no way the initiator would know where
>    to send the Request.
> 
>    Protocol change: Removed PEN option from vendor objectives, changed
>    naming rule accordingly.
> 
>    Protocol change: Added FLOOD message to simplify coding.
> 
>    Protocol change: Added SYNCH message to simplify coding.
> 
>    Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD
>    messages.
> 
>    Protocol change: Require that discovered addresses must be global
>    (except during bootstrap).
> 
>    Protocol change: Receiver of REQUEST message must close socket if no
>    ASA is listening for the objective.
> 
>    Protocol change: Simplified Waiting message.
> 
>    Protocol change: Added No Operation message. (I discovered this is
>    needed during start up to initialise certain sockets.)
> 
> Regards
>    Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jan 2016 08:29:09 +1300

Hi Bing,

> [Bing] This sentence sounds like it is the ACP's duty to decide which messages to be secured. But actually the ACP is not responsible for that decision, any messages go into the ACP will be secured…

Yes, correct, that MUST does not belong here. I will rephrase it.

> [Bing] For link-local multicast, since the ACP is an L3 overlay, if multiple nodes are attached to the same link, I think it cannot prevent the messages going to the un-secured L2 link according to…

I have been asking Michael Behringer about this a few times with no real answer.
One of GRASP's jobs is to relay discovery (and flood) messages between physical
links. I don't think the ACP will support this, because its interface will hide
the existence of the physical links.

For now I will simply comment out that sentence, but we need to discuss this
as part of the ACP discussion.

> My rough idea is that the same Session ID might be beneficial to identify the flooded message. E.g., the interface could easily examine whether the message had been relayed once.

I will send a separate message about this, because it's complicated.

> Btw, the message name "Flooding message" is a very common/abstract phrase, can we find another more precise name? E.g., "Flooded Synchronization" or "Unsolicited Synchronization". However, I can li…

Maybe we can discuss those questions on the list? (Certainly for the Request
message, the Negotiation/Synchronization choice is hidden in the Objective
flag, so it is a bit obscure.)

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 12 Jan 2016 08:17:19 +0000

Hi Brian,

> >> Link-local multicast is used for discovery messages. It is preferred that the
> ACP will handle these and distribute them securely to all on-link ACP nodes
> only.
> > [Bing] For link-local multicast, since the ACP is an L3 overlay, if multiple
> nodes are attached to the same link, I think it cannot prevent the messages
> going to the un-secured L2 link according to normal behavior. Unless the
> GRASP engine intentionally send out the link-local multicast packets
> exclusively into the ACP interface. So, this issue in my mind might be a GRASP
> internal behavior issue.
> 
> One of GRASP's jobs is to relay discovery (and flood) messages between
> physical links. I don't think the ACP will support this, because its interface will
> hide the existence of the physical links.

> as part of the ACP discussion.

[Bing] I think maybe the ACP couldn't really do something essential for this.
GRASP could choose:
- Only discover the nodes within the ACP. Then the relay behavior is just NOT "between links", rather, it is "specifically sending to ACP interface".
- Discover both ACP nodes and non-ACP nodes. Then link-local multicast for non-ACP nodes. Node should response in the ACP as a priority if it receives discovery in both ACP and local link.

We can make this as an open question after 02 submitted.

> > 3. Regarding to the organization/naming of messages (This is a
> > premature idea for discussion, not necessarily mean any revision
> > proposal) According to different functions, we have the following message
> (pairs):
> > - Discovery & Response
> > 1) "Request" is usually coupled with "Response" in other protocols. In
> GRASP, it's not. This might create a little bit trouble to remember the specific
> meaning of the two words in GRASP.
> > Btw, the message name "Flooding message" is a very common/abstract
> phrase, can we find another more precise name? E.g., "Flooded
> Synchronization" or "Unsolicited Synchronization". However, I can live with
> "Flood Message" if no other better one.
> 

[Bing] Ok, let's discuss it later after the submission.
Btw, may I ask your personal opinion on this, do you think this is a real issue?

Best regards,
Bing

> >> From: Anima-signaling [mailto:[email-masked]] On
> >> Behalf Of Brian E Carpenter
> >> Here is my proposed final candidate for draft-ietf-anima-grasp-02
> >> (1st attachment).

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jan 2016 13:00:28 +1300

OK, we can certainly discuss splitting Request into two messages.
Let's ask the WG.

I will post the draft now. I believe I have taken care of your
comments and Carsten's. I have simplified the CDDL fragments
and added a 'message .within message-structure' construct.

Regards
   Brian