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

["Max Pritikin (pritikin)" <[e-mail]>]

One comment below,

On Jul 22, 2015, at 11:17 AM, Brian E Carpenter <[e-mail]> wrote:

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

An interesting point. Is intent information confidential to the anima domain?

My naive assumption would be that one doesn’t get to see intent or anything until bootstrapping is complete — in which case the device *can* be authenticated. I’m not commenting on the requirements discussion concerning if it *should* be authenticated.

- max

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