Hi,
Unfortunately this is still a little broken around both GRASP objectives,
in a way that needs to be fixed:
> 4.1.1. Proxy Grasp announcements
>
> A proxy uses the GRASP M_FLOOD mechanism to announce itself. The
> pledge SHOULD listen for messages of these form. This announcement
> can be within the same message as the ACP announcement detailed in
> [I-D.ietf-anima-autonomic-control-plane].
>
>
> proxy-objective = ["AN_Proxy", [ O_IPv6_LOCATOR, ipv6-address,
> transport-proto, port-number ] ]
That's not valid syntax for an objective. Also, in the Flood message you
have the option of associating a locator directly with the flooded
objective, as part of the basic message format. My suggestion:
The objective is defined in fragmentary CDDL as:
registrar-objective = ["AN_Proxy", objective-flags, loop-count, null]
objective-flags = ; as in the GRASP specification
loop-count = 1 ; restricted to link-local use
The objective-flags field is set to indicate synchronization.
The loop-count is set to 1 to limit the scope of flooding
to the local link.
The value field is set to a null value.
In the GRASP Flood message, an IPv6 locator option is
associated with the objective as described in Section 2.8.11
of [I-D.ietf-anima-grasp]. The locator format is
[O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number]
where
> ipv6-address - the v6 LL of the proxy
> transport-proto - 6, for TCP 17 for UDP
> port-number - the TCP or UDP port number to find the proxy
Then there are more problems with this:
> 4.4. Proxy discovery of Registrar
>
> The Registrar SHOULD announce itself so that proxies can find it and
> determine what kind of connections can be terminated.
>
> When the Registrar joins an Autonomic Control Plane
> ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP
> ([I-D.ietf-anima-grasp]) M_NEG_SYN message.
There is no such thing as M_NEG_SYN. Anyway this is a backwards
way of describing things. I think you should start with something
like:
When the Registrar joins an Autonomic Control Plane
[I-D.ietf-anima-autonomic-control-plane] it MUST be
ready to support the GRASP [I-D.ietf-anima-grasp]
object "AN_registrar" defined below. This is an
objective that supports only discovery; it does not
support synchronization or negotiation. When a proxy
sends a GRASP Discovery (M_DISCOVERY) message seeking
this objective, the Registrar SHOULD respond with a
GRASP Discovery Response (M_RESPONSE) message including
relevant locators as described below.
The objective is defined in fragmentary CDDL as:
registrar-objective = ["AN_join_registrar", objective-flags,
loop-count, null]
objective-flags = ; as in the GRASP specification
loop-count = ; as in the GRASP specification
The objective-flags field is set to indicate discovery.
The loop-count is set to a suitable value to limit the scope of
discovery. A suggested default value is 6.
The value field is set to a null value.
> The registrar responds to discovery messages from the proxy (or GRASP
> caches between them) as follows: (XXX changed from M_DISCOVERY)
>
> objective = ["AN_registrar", F_DISC, 255 ]
Why 255? Do you expect networks to be that big? Discovery
loops will be detected anyway, but I think a much more conservative
value is appropriate.
> discovery-message = [M_NEG_SYN, session-id, initiator, objective]
Nope. M_DISCOVERY is needed. But anyway, what is the point of
replicating bog-standard GRASP here? Possibly in an appendix, but not
main text.
> Figure 6: Registrar Discovery
>
> The response from the registrar (or cache) will be a M_RESPONSE with
> the following parameters:
>
> response-message = [M_RESPONSE, session-id, initiator, ttl,
> (+locator-option // divert-option), ?objective)]
Here an example is more helpful than more cut-and-paste from
GRASP.
> initiator = ACP address of Registrar
Wrong, another argument against redundancy.
See https://tools.ietf.org/html/draft-ietf-anima-grasp-15#section-2.8.5
> locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443]
> locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683]
> locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
OK. This is fine in terms of GRASP syntax, although it's
a slightly special case of implying semantics within the
locators. The only problem is mine: my prototype code can't
do this without enhancement. I'd suggest giving the example
a bit more precisely, something like:
An example M_RESPONSE packet, following the GRASP syntax,
could be as follows:
[M_RESPONSE, session-id, initiator, ttl,
[O_IPv6_LOCATOR, fd45:1345::6789, 6, 443],
[O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683],
[O_IPv6_LOCATOR, fe80::1234, 41, null]]
Also, technically, using proto = 41 extends the formal GRASP syntax.
We could let that slide, holding it in reserve for GRASP 2.0, or
we could at least note that it's an extension.
Regards
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
