[OSPF] Comments for "OSPF Stub Neighbors"
"Russ White" <email@example.com> Mon, 08 February 2016 05:28 UTC
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F731A9120 for <firstname.lastname@example.org>; Sun, 7 Feb 2016 21:28:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=1.55 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5bJdRQzgaPT for <email@example.com>; Sun, 7 Feb 2016 21:28:39 -0800 (PST)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329541A911D for <firstname.lastname@example.org>; Sun, 7 Feb 2016 21:28:39 -0800 (PST)
Received: by mail-pa0-x22f.google.com with SMTP id uo6so69153086pac.1 for <email@example.com>; Sun, 07 Feb 2016 21:28:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=TH+Nz3GQFsXL/MISTbVB1QwVwFKz40ihO6rkSfLn+ow=; b=tVqDM1mpY4nvzUlHqR/oowy/Q/AcgMHINffrWulPJ6kQszDv1alqDwwFdjomqAZd+u kLkVBqd5Rc9SiY0+/sX53xRR+04C5xc2iv9anVPPfnpn414fPPP+1sY/443u+kjFfoVq vrfEzRGdOqnFL7uytZSiedTjEBqeJIwXP+HfmaVQATU5CKsnM2EAxi7dqtjbrr9tqaDs /Ue8APaR4ojomeZfOoQsUZCTsSxdP4CufHHl3AN3jnQb4Fx8VQ3LyUKTCroybdJPb0yr U5GdqFNb8RSVhvAIaKJn7MpmR1FVpHuPGu22UQZ7H9aAP8dHIbkwr2+6kkXVQ5U7L/kQ kvVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=TH+Nz3GQFsXL/MISTbVB1QwVwFKz40ihO6rkSfLn+ow=; b=H5xyumR7NsPLBYkE8SYpPIjdyLk1MvrODrDlOsYgpn7CPAfczSJZu5AFX8PKcEWCNo FLwxFlQWeZjRYZJyWZfN8PbyaOfLLGKJuX4Mb2r4k373aX4H0v+Y6uqx7G8/rFELEAGK 3+OfQeYymvB+5DZ2ELgOIwG6lTVIs8ecF17PgzWV7qlaCCz5rIH59od8+poMW/JsrLf/ Xul6BwDnmAGLvPleVLpIr9iag372BMK2QMqUQTS1v8MKvfK02Y6zjw8hXJmibHXJlCwV EIlyGmUe3OdIEmgxQJ+jf1DWS1060j1yuCEkqVOhDTzJwe3Nc4xWywLi3muv3EOdGvcE u9dw==
X-Received: by 10.66.255.9 with SMTP id am9mr15154505pad.86.1454909318822; Sun, 07 Feb 2016 21:28:38 -0800 (PST)
Received: from Russ ([188.8.131.52]) by smtp.gmail.com with ESMTPSA id fc8sm39955601pab.21.2016.02.07.21.28.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Feb 2016 21:28:38 -0800 (PST)
From: Russ White <firstname.lastname@example.org>
To: "'Acee Lindem (acee)'" <email@example.com>, 'OSPF WG List' <firstname.lastname@example.org>
Date: Mon, 08 Feb 2016 00:28:30 -0500
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Microsoft Outlook 16.0
Subject: [OSPF] Comments for "OSPF Stub Neighbors"
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 05:28:41 -0000
Y'all -- Some thoughts on the current OSPF stub neighbors draft. Some are grammar, later ones are content. == With the growing size of an OSPF-network, most large networks are now deploying OSPF in large hub and spoke topologies. Also in lot of cases L3 routing would be extended to Top of rack or even to a host running virtual machines. In any case these remote devices constitute a stub point in an OSPF network. These devices although being part of OSPF network will never be a transit point and thus do not need any topology information of the area nor do they require optimal routing calculations. This is too much text that's not needed. Something simpler would do, such as -- OSPF is often deployed on large scale hub and spoke or spine and leaf topologies. In both of these topologies, a large number of routers running OSPF will never transit traffic, and hence could be declared stub routers. == The spoke router in the case of a hub and spoke (or a host running OSPF) only need default route to the rest of the network, but they do need to send information about the connected network in the local site. In case of hosts they need to advertise routes in the virtual machines. This feels like too much text as well. Maybe -- OSPF stub routers only need to receive a default route to the rest of the network, and they need to send information about connected subnets or hosts (in the case of a virtual machine or hypervisor running OSPF). I actually don't know that I would agree with the idea that an OSPF stub only needs a default route -- in fact, you want a subset of routes rather than a defualt only, much like partials in BGP peering. The point is that the stub doesn't need any topology information, and it also doesn't need full reachability information. I'll have more comments on this in later sections. == OSPF as network protocol was designed for an environment where routers were of similar capabilities. To protect the larger network, area hierarchy was introduced. Network was typically broken up into a backbone area and several subordinate areas. This breakup of the topology into areas serves multiple purposes As OSPF has become pervasive protocol in the enterprise network it needs to evolve for large hub and spoke setups, these are typical retail environments. In a retail setup typical remote branch router does not have enough capacity to become part of a larger area, even if we break the network in large number of smaller areas. A remote router in one retail store does not need to have routes to all the router in other retail store that are part of its area setup. Too much explanation... There's no real tie between flooding domains (areas), "protecting the larger network," and the concept being presented here -- it just feels like random information. Something like this might help tie things together better -- OSPF networks are broken up into flooding domains, called areas, to manage the amount of control plane state carried to any individual router. Within a flooding domain, each router has a synchronized database containing full reachability and topology information within the area. At the area border, topology information is automatically removed from the information advertised by an OSPF router, and reachability information can be removed through route aggregation. This draft proposes removing all topology information transmitted to OSPF stub routers, and allowing the network administrator fine grained control over reachability information advertised to an OSPF stub router. == Also increasing the number of areas on ABR can burden the ABR, this is due to the creation of large number of summary LSA. Although this can be handled by creating the areas as stub with no summary. Even by creating smaller sized areas with stub no summary, it does not completely eliminate the problem of having unnecessary information from the prospective of intra area. I think what this is trying to say is -- "if you set up each remote as its own area, you incur a penalty in OSPF ABR processing." I would either introduce the alternate solution more fully, or just remove this. IMHO, it's not needed, so I would choose the simpler path and just remove it. == With the advent of virtualized hosts, hosts are now advertising an increasing number of new virtual machine routes. These prefixes need to be advertised by a router that is connected to the host. Traditionally the host would be connected to the router via a shared link between the two (host and router). The host is often sourcing subnets that are not connected to the common subnet between the host and routers. However, the hosts (or spokes) themselves just need a default route from the router(or hub) to reach rest of the network. The solutions using current features of the protocol are not scalable. The overhead of protocol info and flooding of large number of unnecessary information to low-end routers caps the number of spokes on a hub. The problem is made more urgent because of VMs and hypervisors -- ack. Again, though, either explain the problem completely, or leave it out. Again, IMHO, this isn't needed, so I would leave it out. It's simpler in the long run. == We presuppose familiarity with the contents of [RFC2328]. I don't think this is needed, myself... == Incremental deployment The introduction to this section feels like it could be simplified a good bit. Maybe something like -- The changes proposed in this draft impact the hub router in a hub and spoke or spine and leaf topology. The hub router is not required to be an area border router (ABR). From the perspective of the hub router's neighbors, the hub router will appear to be a normal OSPF router running an unmodified version of OSPF. Or something like that... ?? BTW, I'm not certain you're going to actually get away with not changing the remotes, but more on that in a moment. :-) == Vendors have implemented LSA filtering function on per neighbors basis specially for the purpose of scaling large full mesh environments. This section seems a little muddled to me... :-( First, there are two types of filtering here; one that blocks flooding across a particular link similar to a DR/DIS, the other which blocks the advertisment of specific reachability information in a type 3 (the inverse of route leaking in IS-IS). I think you're talking about the first one here, but I don't really understand how it applies to the problem at hand. If it's really a hub and spoke sort of topology, then each remote is only going to receive one copy of each LSA. If it's spine and leaf, then you can block flooding, but it's a bit harder than it seems, I think. You either need to have the one hub that is flooding towards the remotes list all the hubs that are connected to the remote, or you need to play some other game. For the remotes towards the hubs, there are a number of solutions here -- look at the old MANET work for something that's already been implemented in this space. == 4.1, 4.2, and 4.3 don't seem to be necessary to me... ?? == 5.1 Stub Neighbor Overview I'm a little confused by the special default route type. Specifically -- Why not just send a type 3 with only a default route, or only the subset of routes you want the stub to know about? Maybe this has been discussed before, but building a new TLV type seems like a lot of work for a limited range of functionality that could be provided in a way the protocol already knows about. How are you going to prevent the stub from reflooding the LSA it receives from the hub to any other device? Given the draft specifically says "the stub router doesn't need to be changed," there doesn't seem to be any way to solve this. You can assume the stub will only be connected to other modified hub routers, but this seems like a pretty dangerous assumption. What I think I'd do instead is introduce a new type 3 with a TTL. Then you could put whatever you want in it, and be assured the information won't be reflooded. Require the use of a tag for stub routers that don't support the new TTL field, rather than relying on correct network topology configuration. The point of control to prevent reflooding needs to be at the stub router, rather than the hub router. == I have more comments for the later sections, but I'd like to clear these up before moving into the rest of the draft. HTH :-) Russ
- [OSPF] Comments for "OSPF Stub Neighbors" Russ White