The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Curtis,

	The "binary" version of adaptivity does need
to be signaled.  This is done either by specifying 
a strict explicit route, or by "pinning" the route
using some other mechanism.

	Otherwise, the decision to re-route is up to
the last explicit hop before a loosely specified
explicit next hop.  For example, using RSVP-TE, a
re-route occurs automatically for loosely specified
hops because of PATH redirection.

	Finer tuning of "Adaptivity" is done by the 
ingress, either as a function of deciding when to
re-route, or in specifying the explicit path more
or less loosely in signaling.

--
Eric Gray

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@avici.com]
> Sent: Thursday, May 25, 2000 11:22 AM
> To: otel@ce.chalmers.se
> Cc: mpls@UU.NET
> Subject: Re: RFC 2702 and LSP attributes 
> 
> 
> 
> In message 
> <14637.8526.593947.107314@rasputin.ce.chalmers.se>, Florian-Daniel O
> tel writes:
> > 
> > 1) Section 5.8 "Preemtption attribute". Why there are defined four
> > preemtion modes  and then a discussion about the obvious impossible
> > combinations ? Quite a few other attributes defined in prev
> > subsections (e.g. "Path preference rule",  "Resource affinity",
> > "Adaptivity") are binary attributes, so the four preemtion 
> modes could
> > be simply implemented w/ two binary attributes "preemtor?" 
> (yes/no) and
> > "preemtable?" (yes/no). In addition to the simplicity there 
> will be no need
> > to state the obvious impossible combinations.
> 
> RFC2702 is really a requirements document, not a protocol definition.
> 
> The sample implementation are just samples and are described in
> RFC2702 as minimal implementations.  For example, the Adaptivity
> attribute need not be binary.  Parameters can be specified to provide
> finer control over how quickly an LSP reacts to a change in available
> resources.
> 
> > 2) RFC 2702 seems to me a rather lax framework for what LSP 
> attributes are.
> > Is there any other document describing in more detail what are LSP
> > attributes (e.g. number of priority values, formats, etc) or each
> > label distrib. proto is free to implement it however it sees fit as
> > long as it is within the RFC 2702 framework and takes into 
> consideration the
> > link attributes as defined by the present "IGP Requirements for
> > Traffic Engineering with MPLS"  (i.e. the long-since-expired
> > draft-li-mpls-igp-te-00.txt)  ?
> 
> See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt regarding your questions
> about "Preemtption attribute".
> 
>       Setup Priority
> 
>          The priority of the session with respect to  taking  
> resources,
>          in  the  range of 0 to 7.  The value 0 is the 
> highest priority.
>          The Setup Priority is used in deciding whether this 
> session can
>          preempt another session.
> 
>       Holding Priority
> 
>          The priority of the session with respect to holding  
> resources,
>          in  the  range of 0 to 7.  The value 0 is the 
> highest priority.
>          Holding Priority is used in deciding whether this  
> session  can
>          be preempted by another session.
> 
> Other parameters mentioned in RFC2702 (for example, the adaptivity
> parameter) need not be signalled since the decision to reroute is made
> at the ingress.
> 
> Curtis
>