[c-nsp] ISP / MPLS "POP" design

[Mark Tinka]

On Tuesday, November 05, 2013 11:39:11 PM CiscoNSP List 
wrote:

> 1. I notice that a number of people use IS-IS rather than
> OSPF - Is there benefits to using one vs the other?

The main differences that I have found between IS-IS and 
OSPF that are worth mentioning from a performance standpoint 
in favour of IS-IS are:

	1. IS-IS integrates both IPv4 and IPv6 address
	   families in a single protocol implementation.
	   OSPFv2 supports only IPv4. OSPFv3 does support
	   both IPv4 and IPv6, but to support IPv4 on
	   OSPFv3, you still need an IPv6 link layer. Not
	   many vendors support it. For the ones I run, I
	   know Juniper do, since Junos 9.

	2. IS-IS is easily scalable, due to its TLV
	   structure. OSPFv2 is based on an Option
	   structure, and can't be scaled anymore since it
	   has run out. OSPFv3 is based on a TLV structure,
	   and is as scalable as IS-IS from that
	   perspective. This means more features are likely
	   to come to IS-IS first, and probably OSPFv3 next,
	   whatever those features may be (some may even be
	   non-intuitive features like OTV and TRILL, which
	   use IS-IS to work).

	3. IS-IS supports stringy networks, as opposed to
	   OSPF which requires all links to hook back into
	   Area 0 (the Backbone Area), i.e., star
	   topologies. Virtual links are asking for it, so
	   you get what you deserve :-). As I've said many
	   times before on this list, this, for me, was my
	   biggest motivator to switch from OSPF to IS-IS.

	4. OSPFv2 carries IP address information in Type 1
	   and Type 2 LSA's. A change in NLRI triggers Type
	   1 LSA flooding; but since Type 1 LSA's also carry
	   topology information, a full SPF is run within
	   the local area, which is unnecessary if only IP
	   address information has changed (like a metric),
	   but the topology remains the same. IS-IS has a
	   clean separation between IP address and topology
	   information (but then again, so does OSPFv3).

	5. IS-IS runs at Layer 2, and as such, is "less
	   prone" to remote attacks. OSPF is an IP protocol,
	   and can be attacked, especially if poorly
	   secured.

Router CPU's and memory have improved massively since the 
'90's, so while IS-IS can have excellent inherent 
performance scaling numbers with little tuning, OSPF can 
achieve the same on modern hardware also, if run within its 
design constraints. So I don't consider this a major issue 
anymore, particularly for OSPFv3 which separates topology 
from IP address information a la IS-IS.

> 2. Majority of customer tails will be supplied via vlans
> (On Carrier AGG's) - Typically we would have two AGG's
> from two different carriers per POP. I was looking at
> using 2 x 4948's to terminate the Carrier AGG's (Trunk
> ports), then trunk ports to the 7200's(PE's) for L3Any
> recommendations/advice on how to provide redundancy for
> these customer tails? i.e.
> Carrier A AGG to 4948(A)
> Carrier B AGG to 4948(B)
> 
> 4948(A) then has trunk links to both 7200(PE A) and
> 7200(PE B), and same with 4948(B) - Is an acceptable
> setup to have Carrier A L3 Ints on 7200(A) and Carrier B
> L3 Ints on 7200(B), and then if we were to lose (for
> example) 7200(A) we trunk Carrier A's vlans to 7200(B)
> and create the dot1Q Ints to restore service?

A couple of options:

	1. Customers pay for two links, and either run them
	   as active/active or active/backup. You need to
	   ask yourself whether protection for your customer
	   services is native or a billable add-on.
	   Different ISP's have different philosophies,
	   especially driven by the nature of local markets.

	2. You mirror VLAN and IP address configuration
	   between both routers, and only turn one up when
	   the other fails (needs automation to avoid hair
	   loss).

	3. Use MC-LAG, but this is hardware dependent. Plays
	   back into point 1), above, commercially.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20131106/411a8f1f/attachment.sig>