In the near to moderate term, I really don't expect to see the 
ability to have SLA's across arbitrary Internet connections. I do see 
the ability for specific ISPs to offer SLA's on IP-based (i.e., not 
necessarily public Internet) paths.

The reason for doing this is as much, or more for business as 
technical reasons.  Let's say ISP A, to whom you directly connect, 
contracts with an enterprise for a particular SLA.  ISP A has no 
direct connectivity to the destination, which is served by ISP E. 
Three ISPs, B, C, and D, interconnect the two endpoint AS.

OK.  Assume ISP A sets a community or diffserv field that specifies 
some sort of priority handling.  Establishing internet-wide meanings 
for such handling is NOT trivial.  For sake of argument, you could 
even say it uses RSVP, although RSVP is specifically designed for 
intra-domain applications.  However you do it, there is something 
that identifies the traffic as preferred.

Perhaps ISP B has agreed with ISP A, as ISP B's upstream, to 
recognize priority traffic.  But why should ISPs C, D, and E honor a 
demand for priority handling from other ISPs with which they have no 
particular business relationship? ISP A is asking the others to use 
additional resources for the priority traffic, but isn't compensating 
the others to do so.

Aside from the technical and operational challenges, this simply 
makes no business sense.  What makes a good deal more business sense 
is to think of the model used to provision Frame Relay.

Let's say you order a FR VC between New York and Los Angeles. You 
order it from MCI.  Assume that MCI does not have appropriate local 
loops in NY and LA. The reality is that MCI will accept the order, 
and then buy access service in NY from someone like Verizon and in LA 
from someone like PacBell.  The national part will run on MCI 
facilities, unless MCI leases national capacity from a third party.

The point is that while the customer sees one bill, MCI has priced 
that service to include access costs, and MCI will compensate all 
other carriers involved.  This gives everyone involved an economic 
incentive to play nicely together.

Assuming the IP/MPLS/TE operational issues can be solved, it's not 
unreasonable for an ISP to offer SLAs on VPNs for which it has 
end-to-end responsibility. This is not the same thing as SLA across 
the Internet, but the traffic may run over some of the other 
facilities that contracted ISPs use to deliver public service.

>Suppose I need to do IPSec for whatever reason? I.e. I have data that MUST
>remain confidential, such as financial or medical information. ( I.e. GRE
>alone does  cut it )  What does the configuration then look like?
>
>IPSec_router<>GRE_Router<>ISP<>GRE_Ruter<>Your_Company_MPLS<>GRE_Router<>ISP
><>GRE_Router<>IPSec_router
>
>Would that cover it?
>
>What are your engineers saying about latency in this kind of setup?

Nothing is free. If latency is a critical issue, you may have to 
increase bandwidth on some of the links, not because you have enough 
traffic to fill the link, but because faster media inherently have 
less latency.

>I am not trying to knock you. I am just trying to get a good idea how this
>works. I have customers to whom this might be worth mentioning.
>
>Chuck
>
>
>Greetings,
>
>I am actually working with a company that will be offering a product with an
>SLA over the internet.  One caveat is that you can not be more than one ISP
>away from the company on either end.  They will be using GRE tunnels to the
>ingress router, then they will create MPLS Traffic Engineering Tunnels (TE)
>to transverse their network to the egress router and finally GRE tunnels to
>far end customers site.  They have built a nationwide fiber optic network to
>support this product and it should be interesting to see if businesses
>choose to pay a premium for the SLA.
>
>Thanks,
>Jeff

___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to