On 06/07/2017 11:05, Toerless Eckert wrote:
> Brian,
> 
> 1. I think the conclusions about IP-in-IP where that it should be in an 
> appendix
>    because it would not be MTI (Mandatory to implement). 

That makes sense. But the text is still a bit confusing because it doesn't make 
that
clear in the main text. However, before we resolve that, I need to understand
how it's really supposed to work.

> 
> 2./3.  This was addressed in my shepherd review BRSKI where i folded in the 
> information from
> your ani-objectives draft. See my other mail about the status of that review.
> 
> You can find the last integrated version of the ani objective text for BRSKI 
> in section 3.4 of:
> 
> https://raw.githubusercontent.com/anima-wg/anima-bootstrap/toerless_review_section3_20160606/dtbootstrap-anima-keyinfra.txt
> 
> This was done in may/june. Like for acp-07, i would like to improve this 
> though:
> 
> -> I did very much like what the original BRSKI text had, eg: showing also 
> the addresses
>    in an example (independent of the fact that as you explain below the 
> examples are not
>    correct).
> 
>    - Because the addresses are not in the objective field but in the 
> locator-option,
>      your proposed text in ani-objectives does not show it. In result i could 
> only
>      understand ani-objectives going back and forth with the grasp draft. I 
> think that
>      makes it quite unreadable. Thats why the text i put into acp-07 does 
> show the
>      whole M_FLOOD format including the location-option and objective.

I understand that; showing example packets is an excellent idea. (But the reader
must understand GRASP anyway.) The reason I'm trying to figure out exactly what
happens in IPIP is exactly so that I can generate example packets from code; if 
they
don't agree with what you expect, we would then have a real problem to solve.
> 
>    - I think your concern was a bit about consistency and duplication. I am 
> not worried
>      about consistency given how GRASP is out the door (i hope ;-), and i am 
> happy
>      to invest the time for the few additional lines in BRSKI and ACP to make 
> the GRASP explanations
>      in BRSKI and ACP be readable (and verifyable for functionality) 
> standalone.
>      Especially because of this IMHO confusing bit of scatter-gather encoding 
> that we ended
>      up with in GRASP: The name of the service is a parameter to the
>      objective, but the address information of the service is in the 
> locator-option field
>      outside of the objective...
> 
> -> in ani-objectives, the service is called "method", but in grasp-14 it's 
> called
>    now objective-value.

Right. It's the value of the objective, which is a generic concept in GRASP. 
But what
the value actually is depends on the syntax and semantic of the individual 
objective.
That's actually your fault ;-) because it's the flexibility of CBOR that allows 
it.

So what's confusing is that every objective has a value, and (the way I wrote 
it)
the value of the "AN__join_proxy" is simply named "method". Perhaps I should not
use a short cut in the CDDL; would this be clearer:

  proxy-objective = ["AN_join_proxy", objective-flags, loop-count,
                     objective-value]
  
  objective-flags = ; as in the GRASP specification
  loop-count = 1    ; limit to link-local operation
  objective-value = method
  method = "BRSKI-TCP" / "BRSKI-UDP"

I'll come back separately with my musings about how I understand IPIP to work.

Regards
    Brian

> 
> Cheers
>     Toerless
> 
> On Tue, Jul 04, 2017 at 05:32:06PM +1200, Brian E Carpenter wrote:
>> Hi,
>>
>> I am still trying to figure out what you really want to say in sections 
>> 3.1.1. Proxy Discovery Protocol Details and 3.1.2. Registrar Discovery 
>> Protocol Details.
>>
>> 1. Why doesn't section 3.1.1 mention IP-in-IP (protocol 41)? Surely the 
>> pledge needs to know about it?
>>
>> 2. The description is wrong anyway; see 
>> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.3
>>  for something that can work.
>>
>> 3. In section 3.1.2, as I already pointed out, the proposal is really a 
>> misuse of the GRASP discovery response message. Not a problem, we simply 
>> replace it with a synchronization response; see 
>> https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-02#section-2.2.
>>  
>> But regardless of that, I am confused by the example locators:
>>     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]
>>
>> The first two are OK. The ports announced by the proxy to the pledges may be 
>> different. If the registrar sends  [O_IPv6_LOCATOR, fd45:1345::6789, 6,  
>> 443], the proxy might announce [O_IPv6_LOCATOR, fe80::4321, 6, 9999] - the 
>> proxy's link-local address and a different port chosen by the proxy.
>>
>> But the third locator sent by the Registrar indicates a meaningless 
>> link-local address, because it could come from many hops away. At first I 
>> thought this was a confusion with the previous (proxy-to-pledge) case, where 
>> all addresses must be link-local. But no: this text is just confused, I 
>> think:
>>
>>    A protocol of 41 indicates that packets may be IPIP proxy'ed.  In the
>>    case of that IPIP proxying is used, then the provided link-local
>>    address MUST be advertised on the local link using proxy neighbour
>>    discovery.  The Join Proxy MAY limit forwarded traffic to the
>>    protocol (6 and 17) and port numbers indicated by locator1 and
>>    locator2.  The address to which the IPIP traffic should be sent is
>>    the initiator address (an ACP address of the Registrar), not the
>>    address given in the locator.
>>
>> A link local address provided by the Registrar is completely invalid except 
>> on the relevant link connected directly to the Registrar. So it definitely 
>> must not be given to anybody off that link. At the moment I have no idea how 
>> the IP-in-IP is supposed to work. Appendix C doesn't help much. Apart from 
>> anything else, it mentions a non-existent GRASP message type. I can sort of 
>> see what you want to do, but it isn't a codable spec at the moment.
>>
>> Maybe you can provide a complete example of the packet flow, where the 
>> pledge has link-local address Lp, the proxy has link-local address Lx and 
>> ACP address Ax, and the registrar has ACP address Ar. And to make my concern 
>> clear, the registrar has the link-local address Lp, by chance the same as 
>> the pledge, although on a different LAN.
>>
>> Regards
>>    Brian
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to