Hey Saku, Mark,
> Saku Ytti
> Sent: Sunday, March 27, 2016 12:02 PM
>
> On 27 March 2016 at 13:37, Mark Tinka <mark.ti...@seacom.mu> wrote:
>
> Hey,
>
> > As costs and management got out of control, they run l3vpn's and
> > Internet in the same chassis, but on different line cards.
> >
> > Eventually, everything converged.
>
> I tend to agree. If there is significant CAPEX delta buying L3 MPLS VPN +
> HQoS capable boxes and Internet transit capable boxes, then it might make
> sense to buy two networks, as likely L3 MPLS VPN traffic rates are very minor
> but service requires much higher touch hardware.
> But I don't suspect the delta is high these days and more importantly I don't
> think the IP device CAPEX is very large part of TCO.
>
> Another justification might be, if the software stack is very different, but
> for
> L3 MPLS VPN will need all services IP Transit uses, so having IP Transit on
> same devices does not require turning on additional services, so it is not
> really creating additional risk on the premium services.
> If your bread and butter would be L2 VPN, then separating IP transit on
> another edge device might be very prudent, as you could do away with BGP
> and IP lookups completely on the edge.
>
> I am fan of Internet-in-VRF, mainly because global-table is special case and
> it's hard to import/export route between global and VRF, and this complexity
> has forced me to do some really bad/ugly solutions, which would have been
> clean and simple if Internet was in VRF. It does not have to mean ugly
> traceroutes, you can configure device on TTL exceeded to pop labels and do
> IP lookup in transit for returning TTL exceeded messages. This does not even
> exclude BGP free core, as your core can have static route pointing to anycast
> IGP loopback added to all edge devices with full BGP, so TTL exceeded
> message goes to closest edge device for lookup, probably creating less than
> millisecond additional delay on traceroute.
>
> OP states that mistakes in IGP do not affect each other, but mistakes in the
> 'core' network IGP where the L2 circuits run, still break everything.
>
> I'd say you need solid arguments to separate the networks, state exact
> specific problems and how it solves them, default to converged network in
> absence of such arguments. For background it might be interesting to hear
> what problems you've had, what is prompting this separate edge.
>
>
Although I agree with all points made I'm missing one very important factor
which in my opinion shapes the decision whether to go with a converged network
significantly and its also pertinent to the "Core network design for an ISP"
thread and the discussion bout separating core and edge in an effort to
increase availability.
Since the discussion is about converging network carrying Internet traffic with
network carrying traffic of various services I think we all agree that in such
networks the customers' VPN/Services' VPN traffic is more important than
Internet traffic (after all QOS usually reflect these preferences)
Public means exposed to whims of the wild Internet, that is in both data rates
(DDoS) and updates (Malformed BGP updates) something you can't control.
Private means very good control over traffic rates and control plane (number of
updates,...)
If you plan on building a converged network you should be absolutely sure that
Internet can't interfere with Customer/Services VPN data/control-pane under any
circumstances.
If you're not sure whether you can protect private traffic from public you
should rather consider an appropriate level of separation of public and private
control/data-plane. (there are several levels of separations one can consider -
data-plane MIC/FPC/Chassis/network-plane/network or control-plane e.g. common
RR plane vs RR plane per service)
adam
Adam Vitkovsky
IP Engineer
T: 0333 006 5936
E: adam.vitkov...@gamma.co.uk
W: www.gamma.co.uk
This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of
this email are confidential to the ordinary user of the email address to which
it was addressed. This email is not intended to create any legal relationship.
No one else may place any reliance upon it, or copy or forward all or any of it
in any form (unless otherwise notified). If you receive this email in error,
please accept our apologies, we would be obliged if you would telephone our
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk
Gamma Telecom Limited, a company incorporated in England and Wales, with
limited liability, with registered number 04340834, and whose registered office
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
