[j-nsp] Core network design for an ISP

[Mark Tinka]

On 27/Mar/16 12:27, Saku Ytti wrote:

> I understand this argument, but I feel it's opposite. Let's assume
> there is 5% chance of failure to occur in some time frame, i.e. 95% of
> not occurring. If your control-plane depends on two separate instance
> working to produce services then you have only 90% chance of failure
> not occurring, i.e. you reduced service availability by deploying more
> features.
>
> Now you could argue that sure, you maybe have slightly higher chance
> of failing one of them, but you have much lower chance of failing all
> of them at same time, that may be true. But for me, having IPv6 up if
> IPv4 is down is 0 value. The control-plane example you have is
> non-issue, because I'm going to need OOB to RS232 anyhow.

We hit a severe Cisco bug on the ASR920 that broke MPLS. This broke IPv4
traffic as it is encapsulated in MPLS.

We were still able to manage the box over IPv6, as there is currently
not native no MPLS transport for that on the ASR920.

You may see this as a small, zero-value case of keeping both protocols
separate, but I see lots of value in it. OoB is not always a possibility
as it becomes more difficult to do when you have a large Metro-E Access
network, in locations that may have fibre but no phone lines or poor
2G/3G/4G connectivity.

This is just one example of fate-sharing that quickly comes to mind on
this Easter Sunday. But my point is if I can produce enough separation
for a moderate increase in human workload, while still fundamentally
keeping the actual protocol deployment simple (native IPv6 is simpler
than 6PE), why not go for it even if the gains may seem marginal on the
outside?

It's easier for me to add complexity later, than to add simplicity later.

Mark.