[Anima-signaling] On Joel's and Charlie's comments on draft-ietf-anima-grasp-10

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

I believe that the -10A draft also resolves the following points
that are a bit more than nits and simple clarifications.
But I don't think I need to raise them as issues for the whole
WG at the present time:

- Characterization of routing protocols [Joel Halpern]

"Section 2.2 states that routing protocols mainly consider link
up/down and that "all nodes need a consistent view of the network
topology".  the first seems an over-generalization, ... The following
sentence about information not normally used also seems to be at odds
with current practice."

Proposed resolution: Update this text accordingly.

- Text on circular dependencies [Joel Halpern]

"Bullet 1 under SN7 in section 2.2  talks about the potential for
circular dependence, and then says that this protocol will not provide
any assistance for that...  If a single negotiation causes two dependent
negotiations, this would seem to have the potential to cause a work
explosion."

Correct, this is an issue with ASA design. But distributed negotiation
algorithms and distributed consensus algorithms are a field of study
in their own right. 

Proposed resolution: We should be more explicit that this is a complex
issue that is simply not handled by the GRASP layer and that must be
considered by ASA designers.

All the following issues are from Charlie:

- Text on multiple instances in section 3.2 and 3.3 

"  An autonomic node will normally run a single instance of GRASP, used
   by multiple ASAs.  However, scenarios where multiple instances of
   GRASP run in a single node, perhaps with different security
   properties, are not excluded.  In this case, each instance MUST
   listen independently for GRASP link-local multicasts in order for
   discovery and flooding to work correctly.

CEP: Better: should specify that each instance is activated by reception	
   of a single link-local multicast."

Every instance needs to receive all GRASP multicasts, so
the original statement is correct. However, it does no harm to
add that all must be woken by each multicast. (It's automatic
as long as you set SOL_SOCKET,SO_REUSEADDR in each process
before IPPROTO_IPV6,IPV6_JOIN_GROUP.)
	
"Even better: specify that each instance should have its own IP address,	
and all addresses belong to the same link-local multicast group."

The sender of the multicast has no prior knowledge of the separate
instances. As far as Flood and Discover goes, they are all
treated the same, so they can all listen on a single address.

"  o  It is normally expected that a single main instance of GRASP will	
      exist in an autonomic node, and that the protocol engine and each	
      ASA will run as independent asynchronous processes.  However,	
      separate GRASP instances may exist for security-related reasons	
      (Section 3.5.2).	

CEP: Why does the number of instances of GRASP matter for this document??"

Because the secure bootstrap document will rely on this feature.

Proposed resolution: Clarify the text, and remove some repetition..

- LL multicast security

"3.5.1.  Required External Security Mechanism	
		 		
The protocol SHOULD always run within a secure Autonomic Control	
Plane (ACP) [I-D.ietf-anima-autonomic-control-plane].  The ACP is	
assumed to carry all messages securely, including link-local	
multicast if possible.	

CEP: The clauses of the preceding sentence seem contradictory."

The ACP designers have assured us that with the ACP implemented
as a VFR instance, LL multicast will be secured. But indeed this
will not apply to the insecure GRASP instances mentioned in
the following section.

Proposed resolution: s/if possible/when it is virtualized over the ACP/

- Relay interfaces

"3.5.4.4.  Discovery Relaying	
		 		
A GRASP instance with multiple link-layer interfaces (typically	
running in a router) MUST support discovery on all interfaces.  We	
refer to this as a 'relaying instance'.	

CEP: This seems to be a mistake.  Why shouldn't a device be allowed to	
have non-participating interfaces?"

Correct, a *device* could have non-participating interfaces.
So we are referring to interfaces used by the GRASP instance,
not the device as a whole.

Proposed resolution: State that by 'interfaces' we mean those
in use for GRASP, not all physical interfaces. That applies
generally, not just here.

- Discovery replies

"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 (see Section 3.8.4).  Note that this initiator	
address is only used to allow for disambiguation of the Session ID	
and is never used to address Response packets.	

CEP: But, section 3.8.5.  Discovery Response Message has:	
>   It is sent to the sender of the Discovery message via TCP at the port	
>   used to send the Discovery message (as explained in Section 3.8.4).	
Wouldn't this allow the Response to be sent to the initiator?"

The text is unclear. Relaying a discovery breaks the chain; the relay
is acting as a proxy, when I think about it. So the relayed discovery
message is sourced from an {address,port} that is specific to the
relay. It might even be a link-local address, if for some reason there
is no global unicast address in place.

Proposed resolution: Clarify the text (that will also cover
Charlie's other comments on the same subsection).

- Flood relays

"3.5.6.1.  Flooding
...
A GRASP device with multiple link-layer interfaces (typically a	
router) MUST support synchronization flooding on all interfaces.  If	
it receives a multicast Flood Synchronization message on a given	
interface, it MUST relay it by re-issuing a Flood Synchronization	
message on its other interfaces.  The relayed message MUST have the	
same Session ID as the incoming message and MUST be tagged with the	
IP address of its original initiator.
	
CEP: I am pretty sure this is a mistake."

[Clarification: this refers to the phrase 'all interfaces', to be fixed
as above.]

Proposed resolution: see "3.5.4.4. Discovery Relaying" above.

"3.8.13.  No Operation Message	
		 		
In fragmentary CDDL, a No Operation message follows the pattern:	
		 		
noop-message = [M_NOOP]	
		 		
This message MAY be sent by an implementation that for practical	
reasons needs to activate a socket.  It MUST be silently ignored by a	
recipient.	

CEP: ?? what does it mean to "activate" a socket?  Is there something about	
how long a socket may remain open but not used?"

Not that I know of. But I discovered that to find out the port number
assigned to a socket, you pretty much have to perform sendto() and
getsockname(), so the ability to send a no-op during initialisation
seemed reasonable. I could have just sent a zero, but a well-defined
message seemed better.

Proposed resolution: s/activate/initialize/

- Addressing realms

"3.9.5.  Locator Options
...
Note: It is assumed that all locators are in scope throughout the	
GRASP domain.  GRASP is not intended to work across disjoint	
addressing or naming realms.
	
CEP: It's hard to imagine the practical effect of making this statement."

This is where we point someone who says "NAT breaks my GRASP".

Proposed resolution: No change.

- Loop-count

"The 'loop-count' field is used for terminating negotiation as	
described in Section 3.8.7.  It is also used for terminating	
discovery as described in Section 3.5.4, and for terminating flooding	
as described in Section 3.5.6.1.
	
CEP: It would be much more intuitive to put "loop-count" in the message format."

>From the protocol designer's view, perhaps. But the application
programmer should think in terms of objectives, and the natural
place for the ASA to set or read the loop count is in the objective.	

Proposed resolution: No change.

- Null objective value

"3.10.3.  General Considerations for Objective Options
...
If there is no initial value,
the bits in the value field SHOULD all be set to indicate a
meaningless value, unless this is inappropriate for the specific
negotiation objective.
	
CEP: Maybe better to require such objective descriptions to mandate a	
particular O_INVALID_VALUE, whenever needed."

Actually it seems that we should simply specify CBOR's 'null' value
('None' for Python addicts). No need to reinvent the wheel.

Proposed resolution: specify 'null'.

- Dry run flaw?

"CEP: Dry Run has a significant flaw.  Namely, it appears to be stateless,	
so that subsequent simulation steps would not be acting in the	
stateful environment that a true negotiation (or true simulation)	
would be."

Whether it's stateless is an implementation issue in the ASAs that support
it. That does indeed require discussion, but probably in another draft:
draft-carpenter-anima-asa-guidelines

Proposed resolution: add a health warning here, discuss the issue elsewhere.

(ends)