Subject: Re: [OPSAWG] review draft-ietf-opsawg-automated-network-configuration-02

From: "George, Wes" <[email-masked]>
Date: Mon, 28 Nov 2011 15:22:08 -0500

As requested, I've reviewed the changes between -01 and -02. Most of my concerns from my previous message (http://www.ietf.org/mail-archive/web/opsawg/current/msg01756.html) have been addressed, with two exceptions:

First, the introduction and later sections still do not provide a clear explanation of the gaps and issues associated with CAPWAP, NETCONF/YANG, and the cited BBF/3GPP standards. The current intro section ends abruptly with several surveys of different existing protocols without making it clear why those are inadequate. It may be that this is more left for a follow-on document (a formal gap analysis, perhaps), but that's worth stating explicitly. Otherwise, I'd recommend at least some explanation of why the existing efforts are not enough, thus necessitating this problem statement.
It's discussed somewhat in section 6, but I think some linking text in the intro would be helpful.

Second, there is still no discussion of anycast as a potential solution for 5.3 (config server discovery), either why it would work or why it would not. I would think that this would be significantly less brittle than preconfiguring a standard IP address or a URI, because typically anycast routing can use route scoping to manage where traffic destined for that IP block is sent, and a well-known address doesn't suffer from the same inflexibility that using a provider-address or a hard-coded private address might create.

Thanks,

Wes

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Tuesday, November 22, 2011 6:01 AM
> To: Kent Watsen; George, Wes
> Cc: [email-masked]
> Subject: review draft-ietf-opsawg-automated-network-configuration-02
>
> Hi,
>
> your comments on the -01 version have led to a new revision of this
> document:
>
> http://tools.ietf.org/html/draft-ietf-opsawg-automated-network-
> configuration-02
>
> It would be helpful if you can review the changes and let the WG know
> whether you are happy with the edits or detail which changes you think
> should still be done.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Nov 2011 12:55:33 +0100

> It's discussed somewhat in section 6, but I think some linking text in the intro would be helpful.

I will draft some text to address this but I need to check some of the
specs again to get this right.
 
> Second, there is still no discussion of anycast as a potential solution for 5.3 (config server discovery), either why it would work or why it would not. I would think that this would be significant…

My understanding of IP anycast is that 

- it works well if there is service that is highly replicated and
  every (replicated) server provides the same service (the common
  example seems to be DNS)

- it works well for short (ideally stateless) transactions where the
  impact of disruptions due to routing updates is small

- to work with BGP (that is the interdomain scenario), one typically
  needs to allocate a /24 prefix for a service in the case of IPv4
  (which is kind of costly); for interior routing protocols, a host
  route might work

Section 5.3. talks about the problem of locating the configuration
server of a device. To use IP anycasts, one would need to preconfigure
IP anycast addresses or prefixes and we would then need servers that
provide redirection services for all devices being deployed. However,
a device at the end needs to find "it's" configuration server not an
arbitrary configuration server and hence I do not see how IP anycasts
would work in an inter-domain scenario unless the anycast servers all
can provide the same redirection service.

It is likely that I am missing something basic, please let me know if
this is the case. I am also wondering whether there is any operational
experience with products doing this sort of discovery via IP anycasts.
Any insights and pointers might help me to get my understanding clear.

Thanks,

/js

---

From: "George, Wes" <[email-masked]>
Date: Tue, 29 Nov 2011 10:23:12 -0500

>   every (replicated) server provides the same service (the common

[WEG] I don't think that highly replicated is totally necessary for a case like this. Typically replication is used as a means for redundancy and load-balancing (often geographically or route-metric aware). That wouldn't necessarily be a requirement for this application. Simply having the right one be reachable from a given point in the network is enough. If one wants multiple servers for redundancy or balancing, the simple requirement is that each be in sync with the other, so that a client can hit any and receive the information it needs.
>   impact of disruptions due to routing updates is small

[WEG] yes, but in this case, instead of using anycast for the entire configuration exchange, that might be as simple as:
1) client hits anycast server IP, exchanges some identifying information (including certs)
2) server uses the info provided to respond with a redirect to send client to the right unicast IP location to request config
OR
2a) server responds on a different (unicast) address with the required config, so that if there are issues, the client knows which server it needs to send retransmit requests, etc.
OR
2b) if the config fails, the client simply sends repeated requests for config to the anycast address until it's successful or a timeout expires (the assumption being that if a server fails and a reroute is triggered, a retry will absorb this problem)

>   (which is kind of costly); for interior routing protocols, a host
[WEG] I believe that we could have IANA allocate a well-known prefix for this, but allow for those who wish to use their own as well. Using a well-known prefix allows the networks involved to control the scope - if they have a business relationship that requires them to be able to route from one network to another to reach the closest conf server, they can leak the routes, or carry them in a vpn. If they want it to remain local, they don't announce the routes beyond their ASN, and they filter it inbound. Managing anycast prefixes and routing scope across AS boundaries is already sort of a known quantity with things like 6to4 (independent of the implementation problems due to 6to4 using stateless tunneling), where people leak, announce, or filter it based on a number of different factors to control which networks can use the "service" that they are advertising based on its reachability.
> provide redirection services for all devices being deployed. However, a
> device at the end needs to find "it's" configuration server not an
[WEG] I think the thing you're missing is that you're assuming globally-scoped anycast (eg reachable from anywhere on any network), which requires some sort of central repository and hierarchy, and that's not what I'm suggesting. It's possible to control the scope (reachability, really) of an anycast address block through route policy, meaning that a given anycast listener only needs to know about the equipment within the domain that it's scoped for based on the routing. This allows you to burn the same network-independent IP on all devices, but allow the network provider to decide where that traffic goes: to the bit-bucket if they are not using that auto-conf model, to another network if they're serving as transit, to a local server if they're maintaining their infrastructure with this autoconf model, etc.
This would allow for an ISP to provide something like this as a service to their customers (especially if combined with methods of identifying one customer's device from another, like certs), or to use it solely for internal infrastructure, or some combination of the two. Managing the scope and reachability is critical, but quite possible, especially with a good discussion of the "gotchas."

Hope this helps to clarify...

Wes George

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Tue, 29 Nov 2011 16:55:26 -0800

Greetings Juergen,

	Some comments in-line

>  every (replicated) server provides the same service (the common

doesn't need to be highly replicated.  Anycast of one works fine.
>  impact of disruptions due to routing updates is small

Or routing is stable enough that the anycast route doesn't change frequently
>  (which is kind of costly); for interior routing protocols, a host

You would use a /24 for multiple anycast services.  But yes, most eBGP speakers will throw-away a longer than /24 without prior arrangement.

> can provide the same redirection service.

Not necessarily so.  If we picked an address a.b.c.d as the re-direction service, I would policy filter a.b.c.d route imports from networks that are not part of my anycast-based configuration network.
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

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