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

[Brian E Carpenter <[e-mail]>]

Sorry, pressed send too soon.

On 22/07/2015 20:50, Michael Richardson wrote:
> 
> 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.

In fact I believe we should specify that a node SHOULD run the whole
DNA machinery (RFC6059).

>     >> 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.

Multi-hop?

>     > 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*.

The ACP will be routed, afaik. We were talking yesterday about picking
a default without going down the same rat hole as HOMENET.

> 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.

Well, there might be a model where you do network-wide discovery to find
which routing protocols are supported. But without agreeing on a lowest
common denominator "MUST implement" protocol, it becomes a procurement
requirement issue, and I don't like that conclusion.

> (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)

I don't see that. Surely there will be ASAs (in routers) whose job
after bootstrap is to bring up the data plane?

> 
>     >> 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.

I'm not sure how the network can trust the device at that time. Maybe we
don't want to send Intent to an untrusted device?

    Brian

> 
>     >> 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 =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>