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. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp