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

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

Hi Bing,


On 11/01/2016 22:56, Liubing (Leo) wrote:
> 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.

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

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

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

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

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

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