Re: [Anima] big pictures diagrams --- how bootstrap fits into signaling and discovery

[Michael Richardson <[e-mail]>]

Brian E Carpenter <[e-mail]> wrote:
    > On 06/07/2015 08:29, Michael Richardson wrote:
    >>
    >> After reading Brians' slides last week,

    > Those were draft slides sent only to the signaling design team.
    > When they're ready they will of course be for the whole WG.

Yes, so I'm not responding to something specific in your slides, but rather
realizing that there I feel that there is some high level stuff missing.
I agree that it belongs in the framework document, but I don't find it
useful to argue in text until after we have argued in pictures (using crayons).

    >> I will also say that I think that discovery process should include running
    >> DHCP(v6).

    > Please explain how that works in a network with no administrator
    > and no pre-existing default configs. I don't see where a north-south
    > direction would even come from, let alone a designated DHCPv6
    > server.

I'm saying, when a new node turns on, that running a DHCPv6 DISCOVERY process
should be part of learning what is going on.  Clearly, if all the other
connected nodes are in a similar state, nobody is going to answer, but in the
case where there is existing infrastructure, that it could reply.

    >> I'm also unconvinced that GDNP/GRASP shouldn't be other than
    >> DHCPv6,

    > We have a list of 25 requirements. I don't think DHCP fits them,
    > not even close. (I don't care about packet formats; in fact I'm
    > pretty sure we'll have use cases where carrying DHCP options in
    > anima signaling is entirely appropriate.)

If we stick with a TLV format, I think that we can make it work inside
DHCPv6.  Maybe we won't use the exact same set of DHCPv6 messages, but I
think that DHCPv6 SOLICIT and DHCPv6 ADVERTISE might be very much what
we want for the discovery process.

    > Please review the requirements and Appendix A in
    > draft-carpenter-anima-gdn-protocol-04, and if you can show in full
    > detail how DHCP(v6) or DNCP can meet the requirements, we can have
    > the discussion.

I'll review the 25 requirements.

    >> On top of these point to point tunnels, an RPL (rfc6550) instance would
    >> run,

    > but... but... only some Anima networks will run RPL. We definitely need to
    > be agnostic about the choice of IGP. If we've learned one thing from
    > homenet, we've learned that, surely?

What I learned is that we had better decide what we are doing up-front.
If we aren't building a routed ACP to faciliate end-to-end management
traffic, then we'd better put that in the *charter*.

As for RPL vs another one, if we don't pick *one* routing protocol, then we
probably don't have interoperability period, and we should go home.

(And, my questions on Monday about the Data Plane ACP essentially amount to:
if the Data Plane can't route traffic, then the ASAs have to proxy traffic,
i.e. do layer-7 routing, and that had better be in context if someone
thinks they really want to throw away e2e for management traffic)

    >> 6) http://www.sandelman.ca/SSW/ietf/anima/diagrams/network6-imprint.svg
    >>
    >> Devices call "home".
    >> In the first version of this diagram, the devices called the vendor A,
    >> and vendor B boxes directly.  That could be the case, and they could be
    >> redirected to the domain owner based upon sales records, or it could be
    >> that the uplink, being provided by the domain owner, intercepts all
    >> traffic and directs it to the registrar.

    > "Intercepts" is a bad word. IMHO we need to devices to discover whether
    > there is a local registrar first, and not waste their time trying to
    > call home to a vendor in deployments where that is impossible. (There
    > is a chicken/egg problem here, since that should be a matter of Intent
    > but you can't get Intent until you have been authenticated.)

I don't agree.
Intents should be signed objects; the device doesn't need to authenticate
itself to the network before it can see the Intent.  The device may be unable
to authenticate the Intent; but if the device has nothing else to do, and the
Intent says, "Get network online", and the device can do that, it might as
well do it.

    >> Or the domain registrar could
    >> be running an ASA, and could have joined the ACP as well.

    > Definitely.

    > I will stop there because I think we need the ACP authors to
    > comment on much of what you said. But thanks for the systematic
    > thinking.

Sorry for leaving this draft in my edit box for over a week.



--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-