Subject: [OPSAWG] more commentary needed on draft-ietf-opsawg-automated-network-configuration-01.txt

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 7 Jul 2011 08:05:17 +0000

Greetings all,

	To second Scott's previous post about this draft, neither of us, at this point, feel that there is any real support or resistance to this draft.  If there is any working group consensus, it is a consensus of abstention.  We both agree that that is not a good way to advance a draft.  We adopted this as a working group item, but there seems to be no working group discussion on it.

	If people want to see this draft advance (or not), please speak up now with substantive comments.  We will leave this open for another week (until before 81).  However, as it currently stands, we will have a hard time representing this as working group consensus to advance the draft.

	Chris

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

---

From: "George, Wesley" <[email-masked]>
Date: Wed, 13 Jul 2011 12:41:37 -0400

I think that the draft may be useful, but not ready for WGLC.

Your intro mentions capwap, but doesn't explain why this by itself isn't adequate. It also mentioned the 3GPP work, but then does not mention it any further in the document. In other words, yes, 3GPP is doing something, yes IETF has something, but why does this document need to exist? What ground is it covering that the others do not? Is it meant to compare/contrast? Identify gaps/overlap? String together pieces of both to create a BCP recommendation that is closer to an implementation? Section 3 implies that perhaps there needs to be a unified solution, which is probably more of a liason activity. Additional clarity around the purpose of this draft and the reason for mentioning 3GPP's work in this area would be helpful. It may be as simple as noting that you identify gaps later in the doc, but the gaps don't look to be specific to 3GPP's implementation, or to CAPWAP.

scenarios (sect 2) -

Assuming simply that a DHCP server exists is not enough. You also need to assume that the DHCP server is reachable from the new device N prior to any configuration taking place. If the DHCP server is not on the same segment, this requires some method to ensure that the device can reach the DCHP server via broad[any]cast (helper address in IPv4, for example). I realize that this is a pretty basic concept, but for a device that has zero configuration, it's important to mention.
This is further complicated in scenario 2 by the idea of a secondary SP being involved and interacting with the new device N at Layer 3 (vs simply doing Layer 1/2 backhaul), because it now makes the idea of using DHCP options (current or new) to push bits of config beyond standard items like IP address, GW and DNS server problematic due to the amount of coordination required between the two networks. So to your point about needing a DHCP option to provide the address of a config server - even if this existed in the future, it's unlikely that you could reliably use this mechanism in scenario 2, especially if the SP X network is considered mostly untrusted.
It may be appropriate to cover another scenario where the other SP network is not participating at layer 3 or is providing an L3VPN. This may be a subset of the first scenario since it mainly looks like an extension of the SP's network rather than a device at the end of a foreign network, but it's worth mentioning I think.

Section 5.3 - "burned-in vendor URI". I'd rather we didn't even suggest this or discuss it other than to say that this is a bad idea/not recommended/considered harmful or whatever language you want to use. I think that it's a bad idea most notably because it assumes the device being configured has global network (Internet) reachability or that there is a backdoor to the vendor's network/server from the private network so that it can hit that redirect, which may not be a valid assumption. In addition, if it did use some method like SSL to validate the server to prevent malicious redirects/MITM (which it should), that would create a problem where if the SP wanted to insert an HTTP redirector to send it to their own server, rather than rely on the vendor's redirector they would be unable to do so.

But along those lines...Why are we not mentioning anycast at all in this document? It seems to me that a simple solution to the problem of needing an easy way for a device to reliably find a config server with minimal configuration would be to have a well-known (or at least agreed-upon) anycast address burned into the default config for a device of this type. It could be coupled with some filtering/scoping requirements on the network side to prevent it from being reachable beyond the network in question. There is a consideration of which server it hits if you are in scenario 2 and both ISP X and N's ISP are maintaining routes to the well-known anycast address, but this is probably solvable via either policy routing (based on source IP, for example) or via a redirect on the config server that it hits.

Thanks
Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christopher LILJENSTOLPE
Sent: Thursday, July 07, 2011 4:05 AM
To: [email-masked]
Subject: [OPSAWG] more commentary needed on draft-ietf-opsawg-automated-network-configuration-01.txt

Greetings all,

        Chris

---
李柯睿
Check my PGP key here:

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.