The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

 

As might be recalled by those with long memories, I am not happy about this I-D. Of course, if the WG has consensus I can only register my voice as believing it is a bad idea, and sit back and watch the fun.

 

I am disappointed that many of the comments agreements made on the list in discussion of the -02 revision before it was last called have not been addressed. Can anyone say why this is the case? Were we supposed to re-hash all of the arguments during the last call phase?

 

Specifically:

- The authors were supposed to answer why PathErr with RRO could not be used.

- The chair was requested to pronounce as an author of RFC3209 on the

  correct expected behavior of an LSR receiving a PathErr message.

- The authors were supposed to define hard preemption including the protocol

  behavior.

- There was agreement to write a clarification of RFC 3209 with respect to

  preemption and to take that to CCAMP for alignment with GMPLS.

 

It is not my intention to get anyone to change their implementations to match any interpretation of any RFC. All I want to see is:

- specifications that match implementation

- clear statements of procedures so that new implementations can expect

  to interoperate

- this new procedure designed sensibly and functionally

- no artificial split between MPLS and GMPLS.

 

Here are my detailed comments on the I-D. As George has stressed that the last call is only applicable to the changes in the I-D, the authors and chairs will have to decide which comments to ignore.

 

A couple of high-level issues first:

1. You need to clarify that an ingress LSR that sets the soft preemption desired flag SHOULD include an RRO in the Path message it sends (and that if it doesn't it will not receive an alert).

2. You need to discuss the RRO too large problem.

3. You need to resolve the fact that the only way for any LSR to know that preemption is pending on an LSP is to scan the RRO. This is too resource-intensive.

 

Adrian

 

===========

 

  MPLS WG
  Internet Draft                             Matthew R. Meyer (Ed)
                                                   Global Crossing
                                        Jean-Philippe Vasseur (Ed)
                                                Cisco Systems, Inc
                                                     Denver Maddux
                                                       Nitrous.net
                                                 Curtis Villamizar
                                                     Amir Birjandi
                                                  Juniper Networks
## I believe you have too many authors listed. The chairs can tell
## you the rules.

 

  Proposed status: Standard
  Expires: December 2005                                June 2005

 

               MPLS Traffic Engineering Soft Preemption

 

               draft-ietf-mpls-soft-preemption-06.txt

 

Status of this Memo

 

  By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware
  have been or will be disclosed, and any of which he or she becomes
  aware will be disclosed, in accordance with Section 6 of BCP 79.

 

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups. Note that other
  groups may also distribute working documents as Internet-Drafts.

 

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

 

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt.

 

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

 

 

 

 

 

 

 

 

 

 

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005

 

Abstract

 

  This document details MPLS Traffic Engineering Soft Preemption, a
  suite of protocol modifications extending the concept of preemption
  with the goal of reducing/eliminating traffic disruption of preempted
  Traffic Engineering Label Switched Paths (TE LSPs). Initially MPLS
  RSVP-TE was defined supporting only immediate TE LSP displacement
  upon preemption. The utilization of a preemption pending flag helps
  more gracefully mitigate the re-route process of preempted TE LSP.
  For the brief period soft preemption is activated, reservations
  (though not necessarily traffic levels) are in effect under-
  provisioned until the TE LSP(s) can be re-routed. For this reason,
  the feature is primarily but not exclusively interesting in MPLS
  enabled IP networks with Differentiated Services and Traffic
  Engineering capabilities.

 

Conventions used in this document

 

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC-2119 [i].
## What does "[i]" mean?

 

Table of Contents

 

  1. Terminology...............................................3
     1.1 Acronyms and Abbreviations............................3
     1.2 Nomenclature..........................................3
  2. Motivations...............................................4
  3. Introduction..............................................4
  4. RSVP Extensions...........................................5
     4.1 SESSION-ATTRIBUTE Flags...............................5
     4.2 RRO IPv4/IPv6 Sub-Object Flags........................5
     4.3 Use of the RRO IPv4/IPv6 Sub-Object in Path message...5
  5. Theory of Operation.......................................6
  6. Elements Of Procedures....................................7
     6.1 On a soft preempting LSR..............................7
     6.2 On Head-end LSR of soft preempted TE LSP..............8
  7. Interoperability..........................................9
  8. Management................................................10
  9. IANA Considerations.......................................10
  10. Security considerations..................................10
  11. Acknowledgment...........................................10
  12. Intellectual Property Considerations.....................10
  13. References...............................................11
     13.1 Normative references.................................11
     13.2 Informative references...............................11
  14. Authors' Addresses.......................................12

 

 

 

Meyer, Vasseur et al.                                   [Page 2]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005
1. Terminology

 

  This document follows the nomenclature of the MPLS Architecture
  defined in [MPLS-ARCH].

 

1.1 Acronyms and Abbreviations

 

  CSPF            Constraint-based Shortest Path First.
  DS              Differentiated Services
  LER             Label Edge Router
  LSR             Label Switching Router
  LSP             Label Switched Path
  MPLS            MultiProtocol Label Switching
  PPend           Preemption Pending
  RSVP            Resource ReSerVation Protocol
  TE              Traffic Engineering
  TE LSP       Traffic Engineering Label Switched Path

 

1.2 Nomenclature

 

  Make Before Break - Technique used to non-intrusively alter the path
  of a TE LSP. The ingress LER first signals the new path, sharing the
  bandwidth with the primary TE LSP (to avoid double booking), then
  switches forwarding over to a new path. Finally the old path state is
  torn down.

 

  Numerically Lower Preemption Priority - TE LSPs have setup and hold
  preemption priorities of zero (best) through seven (worst).  A
  numerically lower setup priority TE LSP is capable of preempting a
  numerically higher hold priority TE LSP.

 

  Preemption Pending flag - This flag is set on an IPv4 or IPv6 RSVP
  Resv RRO sub-object to signal to the TE LSP ingress LER that the TE
  LSP is about to be preempted and must be re-signaled (in a non
  disruptive fashion, with make before break) along another path. If
  present in the Path RRO, it is used to alert downstream LSRs that the
  LSP was soft preempted upstream.

 

  Point of Preemption - the midpoint or ingress LSR which due to RSVP
  provisioning levels is forced to either hard preempt or under-
  provision and signal soft preemption.
## In theory preemption can also happen on the egress LSR. It is a
## function of how and where you account resources. It does not seem
## necessary to restrict this definition to exclude the egress.

 

## Note that there seems little point in defining this term because
## the rest of the document uses four or five different terms to
## refer to this concept.

 

  Hard Preemption - The (typically default) preemption process in which
  higher numeric priority TE LSPs are intrusively displaced at the
  point of preemption by lower numeric priority TE LSPs. In hard
  preemption the TE LSP is torn down before reestablishment.
## This definition covers two unrelated points. Intrusive displacement
## of an LSP relates to the hardware state at the point of preemption.
## LSP teardown relates to the signaling state and hardware state at
## other LSRs. The is no reason why make-before-break should not be
## used to re-route an LSP that has been hard preempted, and there
## are many good reasons for using that process (hint: these reasons
## are not associated with protecting the traffic flow which has already
## been impacted.

 

## Note that there is no meaning to "typically default". Something is
## either the default or not. If you have a configurable default, then
## there is no statement you can make on the likely setting.

 

  Soft Preemption - The preemption process in which the point of
  preemption allows a brief under-provisioning period while the ingress
## "brief" is somewhat subjective. Can you quantify?

 

Meyer, Vasseur et al.                                   [Page 3]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005
  router is alerted to the requirement for reroute. In soft preemption
  the TE LSP is reestablished before being torn down.
## Amusing concept :-)
## Perhaps you mean that "an attempt is made to establish a new LSP on a
## different path using make-before-break before the old LSP is torn
## down."

 

## I notice that your hard and soft preemption definitions are only truly
## definitive about the data plane behavior at the point preemption. They
## do not describe the signaling behavior, nor the data plane behavior at
## other LSRs. Although you can defer this discussion for soft preemption
## because these are new procedures that you are defining, you cannot defer
## it for hard preemption which you claim is the default. You must describe
## what it is and how it works.

 

  Soft Preemption Desired Flag - This flag is set on the
  SESSION_ATTRIBUTES Flags in the Path message for the TE LSP indicate
## "to indicate"?
  to LSRs along the path that, should the LSP need to be preempted,
  soft preemption should be used if supported.

 

2. Motivations

 

  Initially MPLS RSVP-TE [RSVP-TE] was defined supporting only one
  method of TE LSP preemption which immediately tears down TE LSPs,
## You cannot say this unless you can quote the text. I do not
## believe you can do that.
## There is absolutely no reference to the data plane state on
## preemption in RFC3209.
## You may want to say that it was the intention of the authors. You
## may want to say that this is what everyone has implemented. I cannot
## comment on the veracity of those two statements.
## But you cannot say that this is what RFC3209 says, because that is
## not true.

 

  disregarding the preempted in-transit traffic. This simple but abrupt
  process nearly guarantees preempted traffic will be discarded, if

 

## "nearly guarantees"? Are you saying that preempted traffic is
## actually not discarded?

 

  only briefly, until the RSVP Path Error message reaches and is
  processed by the ingress LER and a new forwarding path can be
  established. In cases of actual resource contention this might be
  helpful, however preemption may be triggered by mere reservation
  contention and reservations may not reflect forwarding plane
  contention up to the moment. The result is that when conditions that
  promote preemption exist and hard preemption is the default behavior,
  inferior priority preempted traffic may be needlessly discarded when
  sufficient bandwidth exists for both the preempted LSP and the
  preempting TE LSP(s).
## You appear to be drawing a direct link between LSP priorities and
## traffic priorities. This seems broken. Traffic priority may be
## irrelevant, but traffic importance could be quite relevant.

 

  Hard preemption may be a requirement to protect numerically lower
  preemption priority traffic in a non Diff-Serv enabled architecture,
  but in a Diff-Serv enabled architecture, one need not rely
  exclusively upon preemption to enforce a preference for the most
  valued traffic since the marking and queuing disciplines should
  already be aligned for those purposes. Moreover, even in non Diff-
  Serv aware networks, depending on the TE LSP sizing rules (imagine
  all LSPs are sized at double their observed traffic level),
  reservation contention may not accurately reflect the potential for
  forwarding plane congestion.
## No. It does accurately reflect the *potential* for forwarding
## plane congestion. It might not reflect the actual forwarding plane
## congestion.

 

3. Introduction

 

  In an MPLS RSVP-TE [RSVP-TE] enabled IP network, hard preemption is
  the default behavior.
## Saying it again doesn't make it any truer.
## Hard preemption is a data plane behavior according to your definition.
## But RFC3209 does not describe the data plane behavior appart from how
## reservations are handled. So you cannot say that this is the default
## behavior and cite the specification. Perhaps you want to say that this
## is waht everyone has implemented, but I can't comment on that.

 

  Hard preemption provides no mechanism to allow
  preempted TE LSPs to be handled in a make-before-break fashion: the
  hard preemption scheme instead utilizes a very intrusive method that
  can cause traffic disruption for a potentially large amount of TE
  LSPs.

 

  Without an alternative, network operators either accept this
  limitation, or remove functionality by using only one preemption
  priority or using invalid bandwidth reservation values.
## These are the only options? What about testing paths to see if they
## are practical or would cause preemption?

 

  Understandably desirable features like ingress LER automated TE
  reservation adjustments are less palatable when preemption is
  intrusive and high network stability levels are a concern.

 

 

 

Meyer, Vasseur et al.                                   [Page 4]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005
  This document defines the use of additional signaling and maintenance
  mechanisms to alert the ingress LER of the preemption that is pending
  and allow for temporary under-provisioning while the preempted tunnel
  is re-routed in a non disruptive fashion (make-before-break) by the
  ingress LER. During the period that the tunnel is being re-routed,
  link capacity is under-provisioned on the midpoint where preemption
  initiated and potentially one or more links upstream along the path
## "was initiated and potentially on one or more"

 

## Can you tell me whether underprovisioning happens on an LSR ("the
## midpoint where preemption was initiated") or on a link? Your text
## appears confused on this issue.
## Presumably it really happens at a link end. That is, on an LSR, but
## associated with a link. (Which is good, because that is what we
## advertise in the TE IGPs.)

 

  where other soft preemptions may have occurred. Optionally the
  downstream path to the egress LER may be signaled
## "the path may be signaled"? Do you mean "alerted"?

 

  as well to more
  efficiently deal with any near simultaneous soft preemptions that may
  have been triggered downstream of the initial preemption.
## Is this right? If another soft preemption has already been triggered
## at a downstream LSR then it is too late to take the new preemption
## into account. Perhaps you mean future preemptions? This seems to be
## what you say in section 4.3.
## And is "near simultaneous" relevant? Surely any time during the
## period between initial preemption and re-routing (or conversion to
## hard preemption) is valid.

 

4. RSVP Extensions

 

4.1 SESSION-ATTRIBUTE Flags

 

  To explicitly signal the desire for a TE LSP to benefit from the soft
## s/benefit from/use/
  preemption mechanism (and so not to be hard preempted if the soft
  preemption mechanism is available), the following flag of the
  SESSION-ATTRIBUTE object (for both the C-Type 1 and 7) is defined:

 

  Soft preemption desired:  0x40  (to be confirmed by IANA)
## IANA does not manage the Sesion Attributes flags.
## You need to add a request to your IANA section to get them to add a
## new registry. You may want to compare with section 11.4 of
## draft-ietf-mpls-rsvpte-attributes-05.txt

 

4.2 RRO IPv4/IPv6 Sub-Object Flags

 

  To report that a soft preemption is pending for an LSP, a new flag is
  defined in the IPv4/IPv6 sub-object carried in the RRO object message
  defined in [RSVP-TE]. This flag is called the preemption pending
  (PPend) flag. A compliant LSR MUST support the RRO object, as defined
  in [RSVP-TE].

 

  Several flags in the RRO IPv4 and IPv6 sub-object have been defined
  in [RSVP-TE]and [FAST-REROUTE]:
## Missing space
## Why does line end with a colon. Is there missing text?

 

  This documents defines a new flag for the use of soft preemption
  named the 'Preemption pending' flag and defined as below:

 

  Preemption pending: 0x10

 

  The preempting node sets this flag if a pending preemption is in
  progress for the TE LSP. This indicates to the ingress LER of this
  LSP that it SHOULD be re-routed.

 

## Don't you think that IANA should manage these flags, too?

 

4.3 Use of the RRO IPv4/IPv6 Sub-Object in Path message
## This section is in the wrong place. It belongs in section 6.

 

  An LSR MAY use the Preemption pending flag in the IPv4/IPv6 RRO sub-
  object carried in a PATH RRO message to simultaneously alert
  downstream LSRs that the LSP was soft preempted upstream.  This
  information could be used by the downstream LSR to bias future soft

 

Meyer, Vasseur et al.                                   [Page 5]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005
  preemption candidates toward LSPs already soft preempted elsewhere in
  their path.
## This is exactly the sort of function you might want to apply if the
## LSP had been hard preempted, but it is unclear that biasing in the
## case of soft preemption has any value. It will not have any result
## on the traffic because the preemption is soft. It will not have any
## result on the number of path computations because the preempted LSP
## has already been told and and is busy being re-routed.
## So what is the value of alerting the downstream LSRs during soft
## preemption?

 

5. Theory of Operation

 

Let's consider the following example:

 

  R0--1G--R1---155----R2          LSP1:        LSP2:
          | \         |
          |   \      155        R0-->R1      R1<--R2
          |    \      |                 \      |
         155   1G     R3                 V     V
          |       \   |                 R5     R4
          |        \ 155
          |          \|
          R4----1G----R5

 

             Figure 1: example of Soft Preemption Operation

 

  In the network depicted above in figure 1, consider the following
  conditions:

 

  -Reservable BW on R0-R1, R1-R5 and R4-R5 is 1Gb/sec.
  -Reservable BW on R1-R2, R1-R4, R2-R3, R3-R5 is 155 Mb/sec.
  -Bandwidths and costs are identical in both directions.
  -Each circuit has an IGP metric of 10 and IGP metric is used by CSPF.
## Curious. We might have expected it to use the TE metric.
  -Two TE tunnels are defined:
          - LSP1: 155 Mb, setup/hold priority 0 tunnel, path R0-R1-R5.
          - LSP2: 155 Mb, setup/hold priority 7 tunnel, path R2-R1-R4.
  Both TE LSPs are signaled with the soft preemption desired bit of
  their SESSION-ATTRIBUTE object set.
  -Circuit R1-R5 fails.
## Is this a circuit? Surely it is a link.
  -Soft Preemption is functional.
## What does this mean?

 

  When the circuit R1-R5 fails, R1 detects the failure and sends an
## Again, not a "circuit".
  updated IGP LSA/LSP and Path Error message to all the head-end LSRs
## It is not right to talk about sending IGP updates "to all the head-end
## LSRs. Although in this example the two head-end LSRs happen to be
## adjacent to the node that detects the failure, this is not generally
## the case. IGP updates are flooded.
  having a TE LSP traversing the failed link (R0 in the example above).
  Either form of notification may arrive at the head-end LSRs first.
  Upon receiving the link failure notification, R0 triggers a TE LSP
  re-route of LSP1, and re-signals LSP1 along shortest path available
  satisfying the TE LSP constraints: R0-R1-R4-R5 path. The Resv
  messages for LSP1 travel in the upstream direction (from the
  destination to the head-end LSR - R5 to R0 in this example). LSP2 is
  soft preempted at R1 as it has a numerically lower priority value and
  both bandwidth reservations cannot be satisfied on the R1-R4 link.
## Tucked away in this paragraph is the fact that preemption happens
## when processing the Resv. Although this may be "obvious" it is not
## stated in RFC 3209. You should bring this point out as part of the
## introduction.
## You are also making a hidden statement that preemption only applies
## on the upstream link end. There is no evidence for this except
## the limitations of current implementations. So you should qualify
## your example with the implementation conditions that you are assuming
## (in this case you are assuming no physical reservations on incoming
## interfaces or LSRs associated with downstream link ends).

 

  Instead of sending a path tear for LSP2 upon preemption as with hard

 

## s/path tear/Path Tear/

 

  preemption (which would result in an immediate traffic disruption for

 

## I'm sorry? Where does it say that a R1 sends a Path Tear during hard
## preemption? Can you give me the reference in RFC 3209? I think you'll
## find that RFC 3209 says...
## A ResvErr and/or PathErr with the code "Policy
## Control failure" SHOULD be sent toward the downstream receivers and
## upstream senders.

 

  LSP2), R1s local bandwidth accounting for LSP2 is zeroed and a
  preemption pending flagged Resv RRO for LSP2 is issued. Optionally,

 

Meyer, Vasseur et al.                                   [Page 6]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005
  R1 MAY simultaneously send a soft preemption flagged Path RRO
  notifying downstream LSRs of LSP2s soft preemption.

 

  Upon reception of the LSP2's Resv message with the preemption pending
  flag set, R2 may update the working copy of the TE-DB before running
  CSPF for the new LSP.

 

## Let me see if I have this right. The only indication that soft preemption
## is taking place is found in a bit embedded in the RRO. So, if I have a
## long path and label recording etc., I must parse the entire RRO to find
## out if soft preemption is taking place (note that finding out *where*
## soft preemption has happened is different from finding out *if* soft
## preemption has happened). This is not very efficient. Why can't you
## flag the error condition with (for example) an error code/value.
## Oh, but then you'd have to use the existing mechanisms for reporting
## preemption (viz. PathErr).
## And so...
## Why don't you use PathErr? There is no requirement to use Resv for
## this function. (And before you ask: yes, RRO is carried on PathErr.)
## There seems to be no reason to change the semanitcs of a Resv and to
## try to carry hidden state information within it.
## But if you MUST use the Resv (no reason having been shown why you do)
## can you please be explicit about the information it carries instead of
## hiding it. Use a real flag that says what has happened rather than
## allow the existing contradiction:
## - the Resv carries FilterSpec information that says that a specific
##   reservtion is in place within the network, but we know this is
##   no longer true
## - there are plenty of established ways to carry and report LSP
##   state information that you could use.
##
## Note that TE-DB has not been defined (and should read TED for
## consistency with other I-Ds).

 

  In the case that Diff-Serv [DIFF-MPLS] and TE
  [RSVP-TE] are deployed, receiving preemption pending may imply to a
  head-end LSR that the available bandwidth for the affected priority
  level and numerically greater priority levels has been exhausted for
  the indicated node interface. R2 may choose to reduce or zero
  available bandwidth for the implied priority range until more
  accurate information is available (i.e. a new IGP TE update is
  received).
## You are saying that information carried in a signaling message
## may be taken to override the information flooded by the IGP
## until such time that the information flooded by the IGP is more
## accurate. This type of statement is dangerous.
## 1. We have only one mechanism for flooding TE link state. If this
##    mechanism is inadequate, we should work to improve it, not
##    invent a new mechanism.
## 2. It is best to try to keep the link state information
##    consistent on all nodes. Your proposal breaks this specifically
##    for the ingress of preempted LSRs but for no other nodes.
## 3. The preemption alert does not indicate that the available b/w
##    at the affected priority level and numerically greater priority
##    levels has been exhausted. In fact, the result of the preemption
##    may be that there is *more* bandwidth available at the holding
##    priority of the preempted LSP.

 

  It follows that R2 re-computes a new path and performs a non traffic
## "It follows that"? Is there some implication that this step is a
## consequence of the previous paragraph?
  disruptive rerouting of the new TE LSP T2 by means of the make-
  before-break procedure. The old path is then torn down.

 

6. Elements Of Procedures

 

6.1 On a soft preempting LSR

 

  When a new TE LSP is signaled which requires to preempt a set of TE
  LSP(s) because not all TE LSPs can be accommodated on a specific
  interface, a node triggers a preemption action which consists of
  selecting the set of TE LSPs that must be preempted so as to free up
  some bandwidth in order to satisfy the newly signaled numerically
  lower preemption TE LSP.

 

  For each preempted TE LSP, instead of sending a path tear upon
## s/path tear/Path Tear/
  preemption as with hard preemption (which would result in an
## As before, Path Tear is not part of the previously specified
## preemption techniques. If you wish to redefine (or define from
## scratch) the procedures for hard preemption then please do so,
## but don't do so by inference.

 

  immediate traffic disruption for the preempted TE LSP), the
  preempting node's local bandwidth accounting for the preempted TE LSP
  is zeroed and a preemption pending flagged Resv RRO for that TE LSP
  is issued upstream toward the head-end LSR.

 

  Optionally, the preempting node MAY simultaneously send a soft
  preemption flagged Path RRO notifying downstream LSRs of soft
  preemption.  If more than one soft preempted TE LSP has the same
  head-end LSR, these soft preemption Resv (Path) messages may be
  bundled together.
## Bundle is a hop by hop message. Therefore bundling depends only
## on the next hop and not on the shared head-end. Worse (!) the
## question of whether the head-end is shared could never be relevant
## to whether you bundle the Path messages.

 

  The preempting node MUST immediately send a Resv message with the
  preemption pending RRO flag set for each soft preempted TE LSP.
## You have already said this a few lines earlier (although with less
## force).
  The
  node MAY use the occurrence of soft preemption to trigger an
  immediate IGP update or influence the scheduling of an IGP update.
## Is this changed behavior? I don't think so. IGP updates can be
## triggered according to changes in available bandwdith on a link.
## This is what happens during soft preemption.

 

  Should a refresh event for a soft preempted TE LSP arrive before the
  soft preemption timer expires, the soft preempting node MUST continue
  to refresh the TE LSP.
## In what sense does a refresh event "arrive"? Do you mean the receipt
## of a Path or Resv refresh message?
## This is the first mention of the "soft preemption timer" so the
## paragraph is not very clear or helpful.
## By "continue to refresh the TE LSP" I assume you mean send refresh
## messages using the RRO containing soft preemption flags. Perhaps
## you could make this clear.

 

Meyer, Vasseur et al.                                   [Page 7]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005

 

  When the MESSAGE-ID extensions defined in [REFRESH-REDUCTION] are
  available, Resv messages with the RRO preemption pending flag set
  SHOULD be sent in reliable mode.
## This means that each LSR (upstream and downstream) SHOULD examine
## the contents of the RRO on all received trigger Path and Resv
## messages to determine whether they SHOULD use Message-ID.
## That doesn't scale well. Why don't you have a single flag to
## indicate soft preemption is in progress?

 

  In the case that reservation availability is restored at the point of
  preemption, the point of preemption MAY issue a Resv message with the
  preemption pending flag unset to signal restoration to the head-end
  LSR.  This implies that a head-end LSR might have delayed or been
  unsuccessful in re-signaling.
## Note that this is only *its* preemption pending flag in the RRO. Not
## all preemption pending flags.
## Presumably it would also send a Path message with updated RRO if it
## had previously added a preemption pending flag to a Path message that
## it had said. perhaps you could say so.

 

  To guard against a situation where bandwidth under-provisioning will
  last forever, a local timer (named the "Soft preemption timer") MUST
  be started on the preemption node, upon soft preemption. If this
## s/preemption node/point of preemption/
  timer expires, the preempting node SHOULD send a PathTear and either
## s/preempting node/point of preemption/
  a ResvTear or a PathErr with the 'Path_State_Removed' flag set.
## 1. Why not revert to RFC 3209 behavior?
## 2. What error code/value should be used?
## 3. Why do you force the Path_State_Removed flag to be set? Doesn't
##    this limit the behavior in PSC GMPLS networks? In particular,
##    if the point of preemption is an MPLS LSR, but further upstream
##    you have GMPLS LSRs, this will result in stale Path state and
##    reservations on the intervening MPLS LSRs since you will never
##    receive a PathTear from the ingress but the MPLS LSRs will
##    ignore the Path_State_Removed flag.
## 4. Note that the definition of the Path_State_Removed flag is
##    found in RFC3473 so you need to add a reference.

 

## Shouldn't this subsequent text be a subsection?
  Selection of the preempted TE LSP at a preempting mid-point: when a
  numerically lower priority TE LSP is signaled that requires the
  preemption of a set of numerically higher priority LSPs, the node
  where preemption is to occur has to make a decision on the set of TE
## s/node where preemption is to occur/point of preemption/
  LSP(s), candidates for preemption. This decision is a local decision
  and various algorithms can be used, depending on the objective. See
  [PREEMPT-EXP].
## I don't think you should reference an expired I-D. Also note that
## since the IETF "does not do algorithms" it may be unlikely that
## the reference I-D will ever progress.
## You should, however, perhaps add that the decision is a Policy
## decision and that it may be influenced by information in the
## Policy object.
  As already mentioned, soft preemption causes a
  temporary link under provisioning condition while the soft preempted
  TE LSPs are rerouted by their respective head-end LSRs. In order to
  reduce this under provisioning exposure, a soft-preempting LSR MAY
  check first if there exists soft preempt-able TE LSP bandwidth
  flagged PPend by another node but still available for soft-preemption
  locally.
## Again, in order to achieve this the LSR has to parse all received
## RROs.
  If sufficient overlap bandwidth exists the LSR MAY attempt
  to soft preempt the same LSP. This would help reducing the
## s/reducing/to reduce/
  temporarily elevated under-provisioning ratio on the links where soft
  preemption occurs and the number of preempted TE LSPs.
## We may assume that if the preemption point knows about another soft
## preempted LSP, the ingress of that LSP will know about its preemption
## casued at some other premption point before it knows about the
## preemption caused by this preemption point. In that case, it will
## already have started make-before-break. Thus the new preemption of the
## same LSP will at best make no difference (it may actually complicate
## matters for the ingress that was trying to do make-before-break
## using the interface on which the new preemption occurs. This does
## not reduce the number of preempted LSPs since the make-before-break
## operation creates a new LSP.
## I think the case you are trying to cover is subtly more restricted.
## In the network A-B-C-D, if LSP1 preempts LSP2 at C, and preemption
## is also needed at B, you would like:
## - to preempt the same LSP (LSP2)
## - only notify A of the preemption once.
## This goal is admirable, but will require you to actually write down
## the procedures.

 

## The next paragraph seems to overlap with the former because the
## upstream/downstream LSRs described will actually be the points of
## preemption in the previous paragraph.
  Optionally, a
  midpoint LSR upstream or downstream from a soft preempting node MAY
  choose to flag the LSPs soft preempted state. In the event a local
  preemption is needed, the relevant priority level LSPs from the cache
  are soft preempted first, followed by the normal soft and hard
  preemption selection process for the given priority.

 

## Let us consider a netwrok A-B-C-D-E. LSP1 exists from A to E. We
## are trying to set up LSP2 from A to E.
## Suppose preemption is needed at D. D will send two messages
## upstream to C.
## a. Resv update for LSP1 showing preemption at D.
## b. Resv for LSP2 showing successful reservation.
## Which happens first?
## Let us assume b. before a. In this case, the new Resv for LSP2
## is processed at C without the knowledge that any preemption was
## performed at D. C may, therefore choose any other LSP and preempt
## it. This is clearly not the process you want to achieve. Further,
## in this case, C might preempt LSP1 anyway and would send two
## messages to B
## b'. Resv for LSP2
## a'. Resv for LSP1 showing preemption at C
## C would then receive message a. (preemption at D on LSP1) and
## would have to send another Resv at once. For a long sequence of
## LSRs you might end up with quite a flurry of Resv messages
## arriving at the ingress.
## So, you must mean that a. is sent before b. In this case, C
## receives the updated Resv for LSP1, flags its local state and
## forwards the trigger Resv at once (following the rules of RFC2205).
## It then gets the Resv for LSP2 and can decide to preempt the same
## LSP (LSP1). This causes it to send messages a' and b'. So B
## sees two Resv messages for LSP1 followed by one for LSP2.
##
## The second sequence enables your optimal preemption but it still
## causes a flurry of Resv messages. Worse: the flurry of messages is
## such that the ingress hears about the first preemption (furthest
## downstream) and starts to do make-before-break (see the next section)
## before it hears about the second preemption. it may then need to
## abort the first make-before-break and start a new one. And then it
## hears about the next preemption, etc.
##
## So it seems to me that you need to:
## 1. Specify the order of transmission of the messages in order to
##    achieve the function you want.
## 2. RECOMMEND a change in RFC2205/3209 behavior so that trigger
##    Resv messages are not immediately forwarded upstream if their
##    only change is the setting of a preemption pending flag in the
##    RRO.
## 3. Suggest that the ingress LSR SHOULD pause on receiving a
##    preemption pending Resv before starting make-before-break to
##    see if any further information about the LSP will be received.
##    The length of such a pause might be around five seconds.

 

  Under specific circumstances such as unacceptable link congestion, a
  node MAY decide to hard preempt a TE LSP (by sending a PathTear and
  either a ResvTear or a PathErr with the 'Path_State_Removed' flag
## Yup. Here you have it again. I think you need to write a section to
## describe this *new* hard preemption procedure.
  set) even if its head-end LSR explicitly requested 'soft preemption'
  ('Soft Preemption desired' flag of the corresponding SESSION-
  ATTRIBUTE object set). Note that such decision MAY also be taken for
  TE LSPs under soft preemption state.

 

## This section should also discuss preemption holding times that are
## necessary to dampen flapping networks. These can only be recommended
## not enforced, but they should still be covered.

 

6.2 On Head-end LSR of soft preempted TE LSP

 

 

 

Meyer, Vasseur et al.                                   [Page 8]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005
  Upon reception of a Resv message with the preemption pending flag
  set, the head-end LSR MAY first update the working copy of the TE-DB
  before computing a new path (e.g by running CSPF) for the new LSP. In
## Here again you have the TE-DB (TED?) being updated by the information
## in a signaling message. There are two issues with this:
## 1. It is wrong to do this.
## 2. We may find that the IPR claim applied to loose-path-reoptimization
##    will be applied here (although I, of course, have no opinion on
##    this issue).
## Why is it not enough to say that the new path will computed using
## exclusions?
  the case that Diff-Serv [DIFF-MPLS] and MPLS Traffic Engineering
  [RSVP-TE] are deployed, receiving preemption pending may imply to a
  head-end LSR that the available bandwidth for the affected priority
  level and numerically greater priority levels has been exhausted for
  the indicated node interface. A head-end LSR MAY choose to reduce or
  zero available bandwidth for the implied priority range until more
  accurate information is available (i.e. a new IGP TE update is
  received).
## This text is identical to that appearing in a previous section and
## so my comments from there apply here, too. No such implication can
## be drawn.

 

  Once a new path has been computed, the soft preempted TE LSP is
  rerouted using the non traffic disruptive make-before-break
  procedure.

 

  As a result of soft preemption, no traffic will be needlessly black
  holed due to mere reservation contention. If loss is to occur, it
  will be due only to an actual traffic congestion scenario and
  according to the operators Diff-Serv (if Diff-Serv is deployed) and
  queuing scheme.
## And that loss will not constitute black-holing? Oh, perhaps it will
## be "needful" black-holing? Could you cut out the motive sales blurb
## and just wrtie what happens?

 

7. Interoperability

 

  Backward compatibility should be assured as long as the
  implementation followed the recommendations set forth in [RSVP-TE].
  When processing an RRO, unrecognized sub-objects SHOULD be ignored
## Why is there a reference to unrecognized sub-objects? This was
## raised as a WG last call comment.
  and passed on. An LSR without soft preemption capabilities but that
  followed the aforementioned recommendation will simply ignore the RRO
  Preemption Pending flag and treat the Resv message as a regular Resv
  refresh message. As a consequence, the soft preempted TE LSP will not
  be rerouted with make before break by the head-end LSR.
## You have mixed up legacy transit nodes with legacy ingress nodes.
## The implication of what you write is that your procedures do not
## apply if there is any legacy transit node. You intend to say
## that a legacy transit node will not impact the procedures if the
## point of preemption and the ingress support the new procedures.
## However (you intend to say) if the ingress does not support the
## procedures it will ignore the received flag and not to make-before-
## break.
## There is something missing here, however. In order that a Resv is
## recognized as a trigger and forwarded upstream, the receiver must
## compare the new objects with the previously received objects. If
## a new flag is set, it is quite possible that this will not be
## recognized as a change in the RRO and no action will follow. Thus
## you need some other change that will cause the trigger to be noticed.

 

  As mentioned previously, to guard against a situation where bandwidth
  under-provisioning will last forever, a local timer (soft preemption
  timer) MUST be started on the preemption node, upon soft preemption.
  When this timer expires, the soft preempted TE LSP SHOULD be hard
  preempted by sending a PathTear and either a ResvTear or a PathErr
  with the 'Path_State_Removed' flag set. This timer SHOULD be
  configurable and a default value of 30 seconds is RECOMMENDED.
## Thirty seconds represents a lot of lost data.

 

  It is RECOMMENDED that configuring the default preemption timer to 0
  will cause the implementation to use hard-preemption.
## This description of the soft preemption timer is out of place. Move
## the text to section 6.1 and just reference it here to say that the
## timer protects you against an ingress that ignores the flag.

 

  Soft Preemption as defined in this document is designed for use in
  MPLS RSVP-TE enabled IP Networks and may not functionally translate
  to some GMPLS technologies. As with backward compatibility, if a
  device does not recognize a flag, it should pass the subobject
  transparently.
## So what is this paragraph saying?
## Is it saying that GMPLS soft preemption is a different thing in
## some switching technologies, or that there is no such thing as
## soft preemption in some switching technologies?
## How does soft preemption work in a GMPLS technology where the
## term is identical (that is, in a PSC network)? Are you requiring
## a change to GMPLS as currently implemented and deployed?
## We must ensure correct interworking of MPLS-TE and GMPLS LSRs.

 

Meyer, Vasseur et al.                                   [Page 9]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005
8. Management

 

  Both the point of preemption and the ingress LER SHOULD provide some
  form of accounting internally and to the network operator interface
  with regard to which TE LSPs and how much capacity is under-
  provisioned due to soft preemption.

 

  Displays of under-provisioning are recommended for the following
  midpoint, ingress and egress views:
   - Sum of current bandwidth per preemption priority per local
  interface
   - Sum of current bandwidth total per local interface
   - Sum of current bandwidth total local router (ingress, egress,
  midpoint)
   - List current LSPs and bandwidth in PPend status
   - List current sum bandwidth and session count in PPend status per
  observed ERO hops (ingress, egress views only).
   - Cumulative PPend events per observed ERO hops.

 

## You might also talk about configurable options wrt preemption.

 

9. IANA Considerations

 

  IANA [RFC-IANA] will not need to create a new registry. This document
  requires the assignment of flags related to RFC3209 [RSVP-TE]
  sections 4.1.1.1, 4.1.1.2, 4.7.1 and 4.7.2.

 

  IANA will assign RRO IPv4/IPv6 sub-object flags defined in RFC3209
  [RSVP-TE] sec 4.1.1.1 and 4.1.1.2 as detailed in section 4.2 of this
  document.
## IANA does not currently have a registry for this flag

 

  IANA will assign session attribute flags for both the C-Type 1 and 7
  (defined in RFC3209 [RSVP-TE] sec 4.7.1 and 4.7.2) as detailed in
  section 4.1 of this document.
## IANA does not currently have a registry for this flag

 

10. Security Considerations

 

  This document does not introduce new security issues. The security
  considerations pertaining to the original RSVP protocol [RSVP] remain
  relevant.

 

## You should at least reference RFC 3209 since it has additional
## security notes above RFC 2205.

 

## But is this all you want to say? Preemption allows one user to
## impact the service provided to other users. By repeatedly firing
## off new LSP requests on different paths (and then tearing them
## down and firing off new requests) a user may stay within his
## service agreement (only one high-capacity high setup priority LSP
## at once) but still cause chaos in the network. Don't you think
## you should comment on this?

 

11. Acknowledgment

 

  The authors would like to thank Carol Iturralde, Dave Cooper, Loa
  Andersson, Arthi Ayyangar, Ina Minei and George Swallow for their
  valuable comments.

 

12. Intellectual Property Considerations

 

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in

 

Meyer, Vasseur et al.                                  [Page 10]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights. Information
  on the procedures with respect to rights in RFC documents can be
  found in BCP 78 and BCP 79.

 

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this
  specification can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

 

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard. Please address the information to the IETF at ietf-
  ipr@ietf.org.

 

13. References

 

13.1 Normative references

 

  [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  Requirement Levels," RFC 2119.

 

  [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
  IANA Considerations Section in RFCs", RFC 2434.

 

  [MPLS-ARCH] Rosen, Viswanathan, Callon, "Multiprotocol Label
  Switching Architecture", RFC3031, January 2001.

 

  [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) -
  version 1 functional specification," RFC2205, September 1997.

 

  [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
  Tunnels", RFC3209, December 2001.

 

13.2 Informative references

 

## This reference is normative because the procedures SHOULD be used.
  [REFRESH-REDUCTION] Berger et al, "RSVP Refresh Overhead Reduction
  Extensions", RFC 2961, April 2001.

 

  [FAST-REROUTE] P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed et al.,
  "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
  2005.

 

## I think the I-D has expired.
  [PREEMPT-EXP]De Oliveira, J., Vasseur, JP., Chen, L. and Scoglio, C.,
  "LSP Preemption Policies for MPLS Traffic Engineering",
  daft-deoliviera-diff-te-preemption-02.txt, October 2003.

 

Meyer, Vasseur et al.                                  [Page 11]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005

 

  [DIFF-MPLS]  Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
  Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen, "Multi-
  Protocol Label Switching (MPLS) Support of Differentiated Services",
  RFC 3270, May 2002.

 

14. Authors' Addresses

 

  Matthew R. Meyer
  Global Crossing
  3133 Indian Valley Tr.
  Howell, MI 48855
  USA
  email: mrm@gblx.net, matthew.r.meyer@gmail.com

 

  Denver Maddux
  Nitrous.net
  4237 E. Hartford Ave.
  Phoenix, AZ 85032
  USA
  email: denver@nitrous.net

 

  Jean-Philippe Vasseur
  CISCO Systems, Inc.
  300 Beaver Brook
  Boxborough, MA 01719
  USA
  Email: jpv@cisco.com

 

  Curtis Villamizar
  AVICI
  curtis@faster-light.net

 

  Amir Birjandi
  Juniper Networks
  2251 corporate park dr ste
  herndon, VA 20171
  USA
  abirjandi@juniper.net

 

  Full Copyright Statement

 

  Copyright (C) The Internet Society (2005).  This document is subject
  to the rights, licenses and restrictions contained in BCP 78, and
  except as set forth therein, the authors retain all their rights.

 

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

 

Meyer, Vasseur et al.                                  [Page 12]

 

draft-ietf-mpls-soft-preemption-06.txt                        June 2005
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

 

 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls