[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TE Requirements Draft - ELSP
Hi Francois...see below, regards, Neil
> > > So one possible use of E-LSPs therefore might be to
> provide VPNs where per
> > > VPN SLAs are required on availability and QoS. To do
> this ER E-LSPs would
> > > need some 'effective BW' and 'survivability' attribute.
>
> Is it correct that what you are describing here is the
> ability to transport
> multiple OAs on a single LSP and have the path for this LSP
> be computed
> based on one "effective Bw" for that LSP , and have one single
> survivability policy/attribute (as opposed to one independent
> survivability
> policy/attribute for each OA)?
NH=> Effectively yes. As I tried to point out previously, there is no
relationship between an applications up-state QoS requirements (ie in DS
class X) and its need to survive vis-a-vis like pkts also of DS class X or
indeed other pkts of DS class Y (from the same or other VPNs). To me that
is the fundamental problem. Now whilst in a 'public' service case one can
of course aggregate like-DS classes and treat the whole population according
to some same-treatment-applies-to-all rules, I am not sure this would be
acceptable to all VPN customers. If I bought a VPN off a SP I don't care
about other VPNs, I only care about the survivability/QoS performance of my
VPN. And my priorities in using DS codepoints may be completely different
to someone else's. So what does the SP do? The only solution to me is to
be able to decouple whatever I do for my 'public' services from what I do
for my VPN customers......and the only way I can see to do this in MPLS (ie
so I have a chance of offering robust availability and QoS SLAs) is to
manage the VPN service on an 'LSP-basis' rather than on a 'per pkt-basis'.
Hence, I am suggesting that E-LSPs look like a potential method to do this
in MPLS (as I simply can't see how to do it with LDP and like-DS-class
merging across all VPNs....since defaults back to the per pkt-basis)......an
alternative of course is to continue to service these customers using FR and
ATM.