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

["Liubing (Leo)" <[e-mail]>]

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