On 03/06/2017 01:22, Toerless Eckert wrote: > 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 ?
It's available in the socket API, returned with the message by recvfrom(). > How would it know whether to respond via TCP or UDP ? It's specified as always TCP. The phrasing is confusing though; we need to find a port that is available for *sending* UDP and *listening* for TCP. Will rephrase. > > 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. Personal opinion: You may be right, but I'm not sure yet. Can we leave this for an update? It seems quite easy to retro-fit this to the registry when we have experience. For now, it will just give the IESG something else to DISCUSS. > > 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. True, but that's a feature. If we've announced (say) the URL for Intent and the announcer dies, it doesn't mean the Intent is dead. > 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. That's about right I think, but do we want to say this in the protocol spec? I don't think we want to give the IESG any new text to chew on right now. I'll take it as good input to draft-carpenter-anima-asa-guidelines > 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). Yes, that's the intention. If the name and tag are the same, it overwrites. We can make it clearer. To me, "same objective" means "objectve with the same name" but I can see it might be unclear. > 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). Iy seems to me that the previous sentence ending "the corresponding cached copy of the objective MUST be overwritten" says this quite clearly. > 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). Section <mumble>. It's impossible to include an <xref> in CDATA text. Will find a way to fix this. > > 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. No. When you discover an objective, the discovered locator is [address, protocol, port]. Then there's an option on a flood to tag the flooded objective with [address, protocol, port]. I just don't see the problem. > 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. That's wrong, sorry. Of course you could put anything you like in the objective value, but GRASP already supplies the locator 3tuple. > 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. Look, I'm not very interested in adding yet more text to confuse the IESG further. I think both of your comments are true but do you really want another month of discussion? > 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. But then we'd have a rule objective-parameters = any. Is that really an improvement? Regards Brian > > Cheers > toerlss > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
