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
