Dear authors:
some comments/questions/suggestions for GRASP:
P1: 3.8.4:
" In a more complex implementation, the GRASP discovery mechanism will find,
for each interface, a dynamic port that it can bind to for both UDP and TCP
before initiating any discovery. "
AFAIK currently, there is no definition of an originator port in
the discovery message (initiator = ipv* address), so i can not see
how the above mentioned "more complex implementation" could work. How
would the responder know the dynamically assigned TCP or UDP port of the
initiator ? How would it know whether to respond via TCP or UDP ?
P2:
In draft-ietf-anima-prefix-management, two GRASP objective-names(s) are
PrefixManager and PrefixManager.Params. Looks as if its useful to think of the
objective-name space as hierarchical. But i do not find any text to that end
in the GRASP draft. I would love to see GRASP objective-names to have at
least for the purpose of IANA registration at least one level of hierarchy,
which is <word1>(.<wordI>)* and that IANA registrations are only for word1.
Otherwise we would end up with a lot more "surplus"? IANA registrations that
really only are details of a particular ASA/autonomic-function.
P3: 3.8.11 Flood Synchronization Message
It would be good to add some text explaining in more detail how to use the
M_FLOOD
objective. Here is some text explaining how _i_ think it works. I hope i even
get
it right:
As outlined in the overview section, Flood Synchronization messages are used as
an efficient
mechanism to announce objectives and their parameters (synchronization data)
when
the objective is needed on many ASA in the network. Instead of creating an
ongoing
amount of flooded Request messages from every client of the objective, these
clients
can listen passively for flooded announcements of the objective.
GRASP has no mechanism to flush long lived objectives whose announcer has died.
ASA that use M_FLOOD objectives should primarily rely on transport layer
mechanisms
to determine the aliveness of a specific locator of such an objective: determine
that an objective locator has become inoperatble due to "unreachable" signaling
(eg: ICMP) or timeouts in attempts to establish a connection. Announcers of
M_FLOOD
objectives should carefully consider the time-to-live for such objectives to
avoid
that stale entries clog up caches and force a large number of clients to probe
(unsuccessfully) a failed objective locator. For an objective with few locators
in the network, a periodicity of 30 seconds and time-to-live of 90 seconds may
be
a good compromise (Supporting loss of as much as 3 out of three M_FLOOD
messages).
be lost. Note that every periodic announcement needs to have a new session-id to
ensure that he new periodic messages is not ignored by GRASPs duplicate
elimination
mechanism.
P4:
" If a subsequent Flood Synchronization message carrying the same objective
arrives with a different tag, a new cached entry MUST be created"
I think this should not say "objective", but "objective-name". Eg: consider
that any of the parameters of the objective have changed, then the new entry
should
also overwrite the old entry (for the same locator).
More fundamentally: The orinator of M_FLOOD objectives would periodically
send the M_FLOOD and the content of the new M_FLOOD would simply
overwrite/refresh
the cache content for what was cached with the same tag. Aka: that explanation
should be rewritten. One could argue that it gets overwritten because the new
M_FLOOD with its fresh time-to-live will have a longer lifetime than the cache
entry, but event hat is IMHO to complex. The rule should simply be to update
cache entries with fresh M_FLOOD information received (and just ignore
duplicates
with sesion-id).
P5:
6. CDDL Specification of GRASP
"objective-name = text ;see specification for uniqueness rules"
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^
Which specification (i thought this is the specification),
which uniqueness rules ? (uniqueness does not otherwise occur in the doc).
P6: The handling of locators in GRASP is somewhat confusing: Except when using
the
URI locator, there seems to be no consistent encoding in GRASP what protocol to
use on top of a O_IPv6/v6_LOCATOR. Instead, the protocol to use is randonly
encoded in the *any part of an objective. And i could not even find text that
describes this. Not sure where, but maybe add an explanation like the following:
GRASP does maintain the notion of locators only to the extend necessary to
ensure
that different ASA can be implemented as different application (processes). In
the
context of typical operating systems, different application processes require
different transport sockets, eg: (address,proto,port) sockets (as in
O_IPV4_LOCATOR,
O_IPv6_LOCATOR and indirectly O_FQDN_LOCATOR). GRASP does not standardize
declarations
about what protocols an ASA expects to be used across these locators. If ASA
need to indicate/negotiate a specific protocol across such a locator then that
protocol would need to be specified as part of the objective specific
parameters.
section 3.9.5: "GRASP is not intended to work across disjoint addressing or
naming realms".
a) It would be helpful to have corollary text such as this:
When GRASP is run in the ACP context,
this means that all locators indicate an ACP IPv6 address (O_IPV6_LOCATOR).
Using
O_FQDN_LOCATOR or O_URI_LOCATOR in the ACP context is safest if all
IPv6 addresses of the domain name indicated are ACP addresses. ASA might also be
able to identify IPv6 addresses to be part of the ACP because of their prefix,
but that would be additional processing complexity not necessary when simply
sticking to O_IPV6_LOCATORS of only ACP addresses.
b) Another corollary that IMHO would be highly useful:
The fact that GRASP is not intended to work across disjoint addressing spaces
does not prohibit it to be used to signal and negotiate different address
spaces:
Consider a flood-message (M_FLOOD) in the context of running GRASP across the
ACP:
The objective independent locator option indicates a locator for the objective
in the ACP. If there are locators for the objective outside of the ACP, then
that locator would have to be encoded into the objective parameters - and it
would
be a problem for the involved ASAs to ensure that the receiving ASA will know
what addressing/naming realm is indicated - and most likely that those ASA have
connectivity to that addressing/naming realm.
c) It would be nice if the CDDL for "objective" would not only say 'any', but
would be given a name that we can use to refer to it, eg: 'objective-parameters'
or 'objective-data' or the like. I like objective-parameters.
Cheers
toerlss
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
