The MPLS WG Archive

[Eric Gray <ewgray@mindspring.com>]

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

Florian-Daniel Otel wrote:

> [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.