Subject: RFC 2702 and LSP attributes

From: Florian-Daniel Otel <[email-masked]>
Date: Thu, 25 May 2000 14:49:18 +0200 (MEST)

[This is a Jhonny-come-lately-question so if this was asked before,
pls point me to the right source]

Hello all,

Regarding  RFC 2702 i have two questions:

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.

(Well, i agree this is a post-mortem, potentially useless discussion
but i'm actually wondering if it's not only a glitch and  I'm missing
something there ;) ) 

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)  ?

Regards,

Florian.

---

From: Eric Gray <[email-masked]>
Date: Thu, 25 May 2000 07:58:56 -0700

Florian,

    RFC2702 specifies requirements, rather than a framework.

    The preemptor/preemptable requirement described implies the
behavior you suggest, but - because RFC2702 was written to
define requirements rather than specific behaviors - it does not
restrict behavior to exactly this behavior.

    This is what a requirements document should do.

    To see why it might be useful to describe this requirement the
way that it is described, consider that some one else may have a
requirement to provide graduated levels of preemption capability.
For example, I may wish to have "setup" and "hold" preemption
priorities which are more flexible than a binary value.

    This would allow me to establish, for example, relatively low
priority circuits which are difficult - but not impossible - to preempt.
This is accomplished by setting a relatively low "setup" priority (to
preclude preempting possibly more important circuits) and a higher
"hold" priority (preventing preemption by another setup that is not
- for example - much more important).  This is useful for relatively
short duration circuit setup where interruption is unacceptable once
a circuit is established.

    It is simple to use this scheme to also satisfy requirements in the
TER RFC (2702).  Simply setting the "setup" and "hold" priorities
appropriately gets the binary behavior you suggest.

    Because RFC2702 does not attempt to mandate specific behavior,
it is possible to implement a more flexible approach that satisfies the
requirements of this RFC.

--
Eric Gray

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 25 May 2000 14:21:43 -0400

In message <[email-masked]>, Florian-Daniel O
> 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

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