Subject: Re: draft-ietf-mpls-rsvp-lsp-tunnel-08.txt

From: Anouk Rocher <[email-masked]>
Date: Thu, 12 Jul 2001 13:45:45 -0400

David, Senthil

First, thanks for your replies. Comments inline.

>The resources reserved are in the FLOWSPEC sent from the egress router
>to the ingress router.  This FLOWSPEC may be one of three kinds of
>intserv classes: Null (meaning best-effort), Controlled-Load, or
>Guaranteed Service.

While trying to do vanilla Traffic Engineering which for quite
a few people seems to finding a path which guarantees a certain bandwidth
for an LSP while reducing hopcount (and I do realize there are many
other possibilities), clearly Null intserv class is not interesting.

Is there an expectation from Network Operators and Service Providers
that they would use one of "Controlled Load" or "Guaranteed Service"
over the other?

>
>The TSPEC in the Path message is used by the ingress router to inform
>the egress router of what it wants to reserve.  Under most MPLS
>implementations, the egress router will try to reserve this amount,
>although it is possible for policy decisions to choose a lower amount.
>The ADSPEC in the Path message, if used, serves two purposes.  It
>gathers information about the network along the path so that the egress
>router will have an idea of what resources are available, and it may be
>used to request a particular kind of intserv class for the FLOWSPEC.

This definitely helps me some. The question I have here is that while 
ADSPEC is used for regular RSVP, is it still used in MPLS networks which
are using RSVP only for traffic engineering?

Or more generally, since several RSVP features are not relevant to MPLS/TE
is there some conventional-wisdom/informational-document out there
which specifies what RSVP features can be safely turned off or not 
implemented when doing MPLS/TE.

>
>This is all straight RSVP and has nothing to do with traffic
>engineering.
>
>Traffic engineering is made possible via the new objects introduced in
>RSVP-TE.  Specifically, SESSION_ATTRIBUTES and EXPLICIT_ROUTE.

I understand this. However the LSP constraints may included bandwidth
as well as other things which come via RSVP. Which is why I was asking
the question.

>-- David

Anouk

________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

---

From: David Charlap <[email-masked]>
Date: Thu, 12 Jul 2001 14:11:46 -0400

Anouk Rocher wrote:
> 
> Is there an expectation from Network Operators and Service
> Providers that they would use one of "Controlled Load" or
> "Guaranteed Service" over the other?

Not that I know of.  Both are useful, but for different kinds of
applications.  IMO, any router vendor implementing MPLS with RSVP-TE
must be prepared to handle both classes.

> This definitely helps me some. The question I have here is that
> while ADSPEC is used for regular RSVP, is it still used in MPLS
> networks which are using RSVP only for traffic engineering?

It is an optional object.  LSRs that receive it should process it
according to RFC 2205.

As for its usefulness, that depends on the nature if the LERs.

The classes used in the ADSPEC object tell the egress router which class
to reserve resources with.  If the ingress router has a preference
(controlled-load or guaranteed), it must signal that preference by
including the appropriate service in the ADSPEC, and by explicitly not
including any others.

The actual values in the ADSPEC may not be of much use, because an
egress router will probably base its reservations on what's in the
TSPEC.  But it is perfectly reasonably for an "application aware" LER to
use local policy or other information beyond the scope of RSVP to decide
on a different size reservation.  If it does, the inforation carried in
the ADSPEC may be very useful.

> Or more generally, since several RSVP features are not relevant to
> MPLS/TE is there some conventional-wisdom/informational-document out
> there which specifies what RSVP features can be safely turned off or
> not implemented when doing MPLS/TE.

I don't know of such a document, but several obvious things come to
mind:

- WF style reservations
- sessions that are not of ctype LSP_TUNNEL_IPV4 or LSP_TUNNEL_IPV6
- sender templates and filterspecs that are not of an LSP ctype
- multicast addresses for tunnel endpoint addresses
- features that don't make sense in the absence of multicast
  endpoints, like some Resv merging rules and blockade states.

>> Traffic engineering is made possible via the new objects
>> introduced in RSVP-TE.  Specifically, SESSION_ATTRIBUTES and
>> EXPLICIT_ROUTE.
> 
> as well as other things which come via RSVP. Which is why I was
> asking the question.

These constraints all serve to generate an explicit route.  This ERO may
be computed by the router, by manual configuration, or by some
standalone management server.  Once the ERO is computed, RSVP doesn't
have to care about the constraints that were used to compute it.

-- David