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

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

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

On 12/01/2016 21:17, Liubing (Leo) wrote:
> 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.
>>
>> 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.
> 
> [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
>>> - 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.
>>
>> 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.)
> 
> [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
> 
> 
> 
>>> Best regards,
>>> Bing
>>>
>>>> -----Original Message-----
>>>> From: Anima-signaling [mailto:[e-mail]] 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
>>>>
>>>