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).
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 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. 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 -- --- t...@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
