Subject: RE: Requirement for LDP support in the RFC2547bis draft

From: [email-masked]
Date: Sun, 14 Jan 2001 12:49:39 -0000

Here's an observation for you all to consider, and something I think should
be an important factor in this discussion:

If, as an operator, I sell a VPN (any technology....so think about all
possibilities here) then I really need to associate that VPN with a pair of
SLAs.  One SLA covers the up-sate (=availability) performance of the VPN and
the other SLA covers QoS (ie the transfer performance which is expected
*when, and only when* the VPN is available).

IP alone is cnls in behaviour.  This means that failures are converted into
'QoS hits', ie when the IGP re-converges after a failure, whatever BW
resources that are left are shared amongst the *same* number of users.  If
there is only one forwarding class (eg BE say) then all affected customers
get a uniform reduction in resource.  If there are multiple forwarding
classes (ie DiffServ) then there is a skewed bias of resource to favour EF,
then AF11, then....etc.  This is fine for certain traffic types, but not
others.....and esp not for VPNs IMHO.  That is, in a cnls fabric we cannot
differentiate between the up-state SLA and the QoS SLA.  This observation
has the further corollaries:
(i) the *survivability* of a certain traffic-type has no relationship to its
required up-state QoS forwarding treatment.  For example, irrespective of
whether voice is or is-not a mission critical traffic entity in a given VPN
(or work-group partition of a given VPN) it has to go EF to meet the jitter
transfer requirements of such a traffic type.
(ii) if same-DS-classes are merged (eg on an LSP) across multiple VPNs, then
on failure the traffic that survives is a function of the traffic types (ie
EF, AFxy) that were active at the time of failure *and* across all VPNs.  It
is therefore not clear (to me anyway) how to state what % of what VPN has
therefore survived post-failure.

This means that it may be very hard (=impossible?) to create distinct avail
and QoS SLAs for VPNs using certain technologies.  However, if I was a
customer buying a VPN I would not care about any other customer's VPN or how
the operator was delivering my VPN, all I would care about was knowing that
my VPN had a certain overall survivability index (which I am paying for) and
that the operator would be able to detect all failures and take appropriate
actions (including protecting my traffic from leaking out or being 'hit' by
any mismerging defects......there is someway to go on just these aspects
that OAM work is trying to address).  The QoS aspects would be of secondary
importance to the avail behaviour and its SLA.

And it was against the above considerations that I have already suggested to
colleagues here that RSVP (say) LSPs might be a better way to provide VPNs
rather than using LDP (as the server LSP layers).  We note of course, that
what we are really talking about here is the emulation of traditional
hard-BW partioned L2 VPNs.  However, if one wants to offer disjoint(across
VPN pop)/robust/measurable/varying(on price) avail SLAs for VPNs, one has to
consider the above factors.

Neil 

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]]
Sent: 12 January 2001 23:33
To: Pedro Roque Marques
Cc: Barry Hass; [email-masked]
Subject: Re: Requirement for LDP support in the RFC2547bis draft

In addition to what Pedro already said let me add a comment that running
a mpls-vpns on mpls-te only without LDP is a quite challanging task. TE
in genral was build to optimize the routing paths. When it fails for
whatever reason you fall back to pure IP and IP reachability is fine. 

When TE fails for whatever reason while you are using it for mpls-vpns
your 10s or 100s of customers connected to given PEs are simply
unreachable with the peers to which PE's broken TE tunnel was going to.
P routers do not maintain any of the VPN information.

I am not going to bring here all protection you can use for TE just
wanted to bring up this point. LDP by it's nature has much more less
constrains which could cause it to fail and in most of today's
implementations I have seen can be as robust as the IGP you are running.

R.

> Pedro Roque Marques wrote:
> 
> >>>>> "Barry" == Barry Hass <[email-masked]> writes:
> 
>     Barry> As an aside, and keeping in mind that I don't want to start
>     Barry> a discussion of the merits of the choice, I would be
>     Barry> curious to know why the authors of 2547 chose LDP, rather
>     Barry> than RSVP-TE as a standard for interoperability.
> 
> With LDP you have much less signaling to do... you have it assign
> labels for your possible paths and you are just using your IGP to pick
> the shortest-path. RSVP + a path computation tool requires
> significantly more signaling in the network and it is an overkill on
> the simplest case since typically an explicit path is not needed.
> 
> LDP + IGP will also converge faster than IGP + path computation tool +
> RSVP, unless you calculate an very substantial number of backup paths.
> 
> These are different tools for different problem sets...  LDP maps well
> to the problem of providing full-mesh LSP connectivity to all edges of
> your network following IGP shortest path. Computing explicit paths
> maps well to divert parts of your traffic from shortest path.
> 
> You can* use explicit paths (+ whatever signaling protocol your fancy)
> to run a tag vpn network on top. But that is not the simplest solution
> to the problem and it will (most likely) require engineering the
> network apropriatly.
> 
>   Pedro.
> 
> *It would be actually interesting to know how far a full mesh
> edge-to-edge of explicit paths would scale.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 14 Jan 2001 11:25:11 -0800

Hi Neil, 

> rather than using LDP (as the server LSP layers).

By all means the suggestions to use RSVP LSPs for achiving your SLA
goals are fine. My comment was issued from a bit of a different angle.
What I meant to say that this is good to engineer your VPN traffic
either for L3VPN or L2VPN with TE LSPs but it is also somewhow desirable
to have a fall back protection just in case your TE LSPs fail. 

Yes you may protect it locally on each link it travels through or
protect your LSPs end to end but still I would fell much better as the
operator when I know that even if my entire TE fails VPN packets are
still not lost but delivered to the other end based on the EXP field
bits they carry. 

So my comment was addressing this scenario rather then intending to say
that RSVP established LSPs are not good at all. In the same light I read
Eric's indication that LDP should be the least common denominator for
interoperable VPNs implementations. 

R.

> [email-masked] wrote:
>