Just an update on this.
1) I missed a couple of inconsistencies below, noted in line.
2) I updated the GRASP prototype to support the previously
missing features used below. I update my demo ASAs for the
pledge, proxy and registrar roles. They work.
I need to do quite a bit more testing before pushing the
updated code to GitHub, but basically I think the GRASP
aspect of BRSKI is good to go.
On 18/10/2017 16:19, Brian E Carpenter wrote:
> 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]
proxy-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]
registrar-objective = ["AN_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.
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
