Content-Type: multipart/mixed; boundary="===============0720313783==" Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0720313783== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0614_01C5767C.B04BFF40" This is a multi-part message in MIME format. ------=_NextPart_000_0614_01C5767C.B04BFF40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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=20 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=20 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. ------=_NextPart_000_0614_01C5767C.B04BFF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

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

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

Specifically:

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

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

correct expected behavior of = an LSR=20 receiving a PathErr message.

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

behavior.

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

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

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

- specifications that match=20 implementation

- clear statements of procedures so = that new=20 implementations can expect

to interoperate

- this new procedure designed = sensibly and=20 functionally

- no artificial split between MPLS = and=20 GMPLS.

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

A couple of high-level issues = first:

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

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

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

Adrian

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

Proposed status: = Standard
=20 Expires: December=20 2005 &nb= sp; &nbs= p; =20 June 2005

&nbs= p; =20 MPLS Traffic Engineering Soft Preemption

&n= bsp; =20 draft-ietf-mpls-soft-preemption-06.txt

Status of this Memo

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

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

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

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

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

draft-ietf-mpls-soft-preemption-06.txt &n= bsp; &nb= sp; =20 June 2005

Abstract

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

Conventions used in this document

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

Table of Contents

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

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 2]

draft-ietf-mpls-soft-preemption-06.txt = &= nbsp; =20 June 2005
1. Terminology

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

1.1 Acronyms and Abbreviations

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

1.2 Nomenclature

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

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

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

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

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

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

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

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

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 3]

draft-ietf-mpls-soft-preemption-06.txt = &= nbsp; =20 June 2005
router is alerted to the requirement for reroute. In = soft=20 preemption
the TE LSP is reestablished before being torn = down.
##=20 Amusing concept :-)
## Perhaps you mean that "an attempt is made to = establish=20 a new LSP on a
## different path using make-before-break before the = old LSP=20 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.=20 They
## do not describe the signaling behavior, nor the data plane = behavior=20 at
## other LSRs. Although you can defer this discussion for soft=20 preemption
## because these are new procedures that you are defining, = you=20 cannot defer
## it for hard preemption which you claim is the = default. You=20 must describe
## what it is and how it works.

Soft Preemption Desired Flag - This flag is set on = the
=20 SESSION_ATTRIBUTES Flags in the Path message for the TE LSP = indicate
## "to=20 indicate"?
to LSRs along the path that, should the LSP need to = be=20 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=20 LSPs,
## You cannot say this unless you can quote the text. I do = not
##=20 believe you can do that.
## There is absolutely no reference to the = data=20 plane state on
## preemption in RFC3209.
## You may want to say = that it=20 was the intention of the authors. You
## may want to say that this is = what=20 everyone has implemented. I cannot
## comment on the veracity of = those two=20 statements.
## But you cannot say that this is what RFC3209 says, = because=20 that is
## not true.

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

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

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

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

3. Introduction

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

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

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

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

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 4]

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

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

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

as well to more
efficiently deal with any near=20 simultaneous soft preemptions that may
have been triggered = downstream=20 of the initial preemption.
## Is this right? If another soft = preemption has=20 already been triggered
## at a downstream LSR then it is too late to = take the=20 new preemption
## into account. Perhaps you mean future preemptions? = This=20 seems to be
## what you say in section 4.3.
## And is "near = simultaneous"=20 relevant? Surely any time during the
## period between initial = preemption and=20 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=20 soft
## s/benefit from/use/
preemption mechanism (and so = not to be=20 hard preempted if the soft
preemption mechanism is available), = the=20 following flag of the
SESSION-ATTRIBUTE object (for both the = C-Type 1=20 and 7) is defined:

Soft preemption desired: 0x40 (to be confirmed = by=20 IANA)
## IANA does not manage the Sesion Attributes flags.
## You = need to=20 add a request to your IANA section to get them to add a
## new = registry. You=20 may want to compare with section 11.4 of
##=20 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=20 is
defined in the IPv4/IPv6 sub-object carried in the RRO = object=20 message
defined in [RSVP-TE]. This flag is called the = preemption=20 pending
(PPend) flag. A compliant LSR MUST support the RRO = object, as=20 defined
in [RSVP-TE].

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

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

Preemption pending: 0x10

The preempting node sets this flag if a pending preemption = is=20 in
progress for the TE LSP. This indicates to the ingress LER = of=20 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=20 is in the wrong place. It belongs in section 6.

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

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 5]

draft-ietf-mpls-soft-preemption-06.txt = &= nbsp; =20 June 2005
preemption candidates toward LSPs already soft = preempted=20 elsewhere in
their path.
## This is exactly the sort of = function=20 you might want to apply if the
## LSP had been hard preempted, but it = is=20 unclear that biasing in the
## case of soft preemption has any value. = It will=20 not have any result
## on the traffic because the preemption is soft. = It will=20 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.
##=20 So what is the value of alerting the downstream LSRs during soft
##=20 preemption?

5. Theory of Operation

Let's consider the following example:

=20 R0--1G--R1---155----R2        &nb= sp;=20 LSP1:       =20 LSP2:
          |=20 \        =20 |
          = |  =20 \      = 155       =20 R0-->R1     =20 R1<--R2
         =20 |    \     =20 |            =     =20 \     =20 |
         155  =20 1G    =20 R3            = ;    =20 V    =20 V
         =20 |       \  =20 |            =     =20 R5    =20 R4
         =20 |        \=20 155
         =20 |         =20 \|
         =20 R4----1G----R5

&n= bsp;=20 Figure 1: example of Soft Preemption Operation

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

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

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

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

## s/path tear/Path Tear/

preemption (which would result in an immediate traffic = disruption=20 for

## I'm sorry? Where does it say that a R1 sends a Path Tear during=20 hard
## preemption? Can you give me the reference in RFC 3209? I = think=20 you'll
## find that RFC 3209 says...
## A ResvErr and/or PathErr = with the=20 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.=20 Optionally,

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 6]

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

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

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

In the case that Diff-Serv [DIFF-MPLS] and TE
= [RSVP-TE]=20 are deployed, receiving preemption pending may imply to a
= head-end LSR=20 that the available bandwidth for the affected priority
level = and=20 numerically greater priority levels has been exhausted for
the = indicated node interface. R2 may choose to reduce or zero
= available=20 bandwidth for the implied priority range until more
accurate=20 information is available (i.e. a new IGP TE update is
= received).
##=20 You are saying that information carried in a signaling message
## may = be=20 taken to override the information flooded by the IGP
## until such = time that=20 the information flooded by the IGP is more
## accurate. This type of=20 statement is dangerous.
## 1. We have only one mechanism for flooding = TE link=20 state. If this
##    mechanism is inadequate, we = should work=20 to improve it, not
##    invent a new mechanism.
## = 2. It=20 is best to try to keep the link state = information
##   =20 consistent on all nodes. Your proposal breaks this=20 specifically
##    for the ingress of preempted LSRs = but for=20 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.=20 In fact, the result of the preemption
##    may be = that there=20 is *more* bandwidth available at the holding
##    = priority of=20 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=20 a
## consequence of the previous paragraph?
disruptive = rerouting of=20 the new TE LSP T2 by means of the make-
before-break = procedure. The=20 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=20 TE
LSP(s) because not all TE LSPs can be accommodated on a=20 specific
interface, a node triggers a preemption action which = consists=20 of
selecting the set of TE LSPs that must be preempted so as = to free=20 up
some bandwidth in order to satisfy the newly signaled=20 numerically
lower preemption TE LSP.

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

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

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

The preempting node MUST immediately send a Resv message = with=20 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=20 preemption to trigger an
immediate IGP update or influence the = scheduling of an IGP update.
## Is this changed behavior? I don't = think so.=20 IGP updates can be
## triggered according to changes in available = bandwdith=20 on a link.
## This is what happens during soft preemption.

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

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 7]

draft-ietf-mpls-soft-preemption-06.txt = &= nbsp; =20 June 2005

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

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

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

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

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

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

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

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

6.2 On Head-end LSR of soft preempted TE LSP

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 8]

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

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

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

7. Interoperability

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

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

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

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

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 9]

draft-ietf-mpls-soft-preemption-06.txt = &= nbsp; =20 June 2005
8. Management

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

Displays of under-provisioning are recommended for the=20 following
midpoint, ingress and egress views:
   = - Sum of=20 current bandwidth per preemption priority per local
=20 interface
   - Sum of current bandwidth total per local=20 interface
   - Sum of current bandwidth total local router=20 (ingress, egress,
midpoint)
   - List current = LSPs and=20 bandwidth in PPend status
   - List current sum bandwidth = and=20 session count in PPend status per
observed ERO hops (ingress, = egress=20 views only).
   - Cumulative PPend events per observed ERO=20 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=20 [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=20 RFC3209
[RSVP-TE] sec 4.1.1.1 and 4.1.1.2 as detailed in = section 4.2=20 of this
document.
## IANA does not currently have a = registry for=20 this flag

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

10. Security Considerations

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

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

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

11. Acknowledgment

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

12. Intellectual Property Considerations

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

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 10]

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

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

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

13. References

13.1 Normative references

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

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

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

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

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

13.2 Informative references

## This reference is normative because the procedures SHOULD be=20 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,=20 May
2005.

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

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 11]

draft-ietf-mpls-soft-preemption-06.txt = &= nbsp; =20 June 2005

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

14. Authors' Addresses

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

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

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

Curtis Villamizar
AVICI
curtis@faster-light.net

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

Full Copyright Statement

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

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

Meyer, Vasseur et=20 al. &nbs= p; = ; =20 [Page 12]

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

------=_NextPart_000_0614_01C5767C.B04BFF40-- --===============0720313783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0720313783==-- From mpls-bounces@lists.ietf.org Wed Jun 22 20:23:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlFVB-0006Im-9h; Wed, 22 Jun 2005 20:23:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlDjS-00078b-2H; Wed, 22 Jun 2005 18:30:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13445; Wed, 22 Jun 2005 18:30:02 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlE7e-0006Fx-VE; Wed, 22 Jun 2005 18:55:07 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5MMSIpT027114; Wed, 22 Jun 2005 17:28:19 -0500 (CDT) Received: from [135.180.160.116] (thyaga-pcho.dnrc.bell-labs.com [135.180.160.116]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j5MMS8j14118; Wed, 22 Jun 2005 18:28:09 -0400 (EDT) Message-ID: <42B9E5F9.2000405@lucent.com> Date: Wed, 22 Jun 2005 18:28:09 -0400 From: Thyaga Nandagopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: thyagu@crhc.uiuc.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail2.lucent.com id j5MMSIpT027114 X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 22 Jun 2005 20:23:27 -0400 Cc: Subject: [mpls] CFP: Deadline approaching - COMSWARE 2006 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Submission Deadline: June 24, 2005 (extended) (Our apologies if you receive multiple copies of this document) CALL FOR PAPERS *************** The First International Conference on Communication Systems Software and Middleware http://www.comsware.org ----------------------- January 8 - 12, 2006 Taj Palace Hotel, New Delhi, India Technical Co-Sponsor : IEEE Communications Society In Co-operation with : ACM SIGMOBILE Sponsored by: CreateNet (Italy), ICST (USA) Co-Sponsors: IBM, Microsoft Research, NOKIA, Lucent Technologies, Sasken University Co-Sponsor: Indian Institute of Technology, Delhi Paper Submission: June 24, 2005 (extended) (Instructions at http://www.comsware.org) (Proceedings to be published by IEEE and to appear in IEEE Explore) The convergence of the communications, information technologies and the Internet has ushered in a revolution in the way people communicate with each other. The key enabler for this convergence has been the advancement of software technology in various communication sectors, as evident by the high levels of activity in the industry, academia, and standards bodies, coupled with the increasing dependence of this convergence to sustain and improve growth rates in many countries around the world. This new international conference will provide a forum to exchange ideas, techniques, and applications, discuss best practices and challenging issues, raise awareness and share experiences among researchers, practitioners, standard developers and policy makers in the field of software techniques in communications. The conference will bring leading researchers and practitioners in areas ranging from communications software and software engineering aspects of communications software, to middleware and networking protocols. The objective of the conference is to provide a high degree of collaboration, participation and discussions of the various topics among multi-national participants from the industrial, governmental and academic sectors. COMSWARE will include a regular paper track and an industry track. The paper track will include a highly selective technical program. The conference solicits original, previously unpublished research work, experimental efforts, and practical experiences for the technical program. COMSWARE will also feature panel discussions from experts in academia and industry, workshops and tutorials featuring the state-of -the-art in various communications software and related areas. There will be demos and exhibits that will expose the delegates to exciting products and software solutions from industry and academia. Accepted papers will be published by IEEE Computer Society. The top papers accepted to the conference will be published in a reputed journal. Areas of interest include, but are not limited to: =B7 Communications Software =B7 Reconfigurable Software Stacks =B7 Software Engineering Aspects of Communications Software =B7 Context-Based and Implicit Computing =B7 Telecommunications Services and QoS =B7 Software for Billing and Pricing =B7 User Interfaces and Interaction Models =B7 Multi-Agent Systems =B7 Client-Server Applications =B7 Mobile and Intermittently Connected Applications =B7 Mobile Data Management =B7 Middleware Services and Agent Technologies =B7 Middleware for Wireless Sensor Networks =B7 Middleware for P2P Systems =B7 Middleware for Future Communication Networks =B7 Information Infrastructure and Security =B7 Security and Privacy Issues of Pervasive Computing Systems =B7 Network Operations and Management =B7 Policy and Workflow-based Network Operations =B7 Reliability Support Software =B7 Resource Management in Pervasive Computing Platforms =B7 Management Software for Optical Networks =B7 Network Monitoring Software =B7 Internet and IP based Services =B7 Dynamic Service Composition and Deployment =B7 Service Discovery Mechanisms =B7 Wireless/Mobile Service Management and Delivery =B7 Mobile / Wireless Computing Systems and Services =B7 Performance Evaluation Techniques =B7 Location Determination =B7 Positioning and Tracking Technologies =B7 Smart Devices and Smart Spaces =B7 Enterprise Networking =B7 Personal Area Networks =B7 Integration of Wired and Wireless Networks =B7 Next Generation Networks and Services Deadlines ********* Paper Submission: June 24, 2005 (Instructions at http://www.comsware.org= ) Notification of Acceptance: August 15, 2005 Camera-ready due: September 26, 2005 Conference Organizing Committee ******************************* General Chairs: Victor Bahl, Microsoft Research, USA Bijendra Nath Jain, IIT, Delhi, India Henning Schulzrinne, Columbia University, USA Alfred Spector, IBM Research, USA Steering Committee: Imrich Chlamtac, University of Trento, Italy=20 (Chair) Rajeev Shorey, IBM Research, India=20 (Co-Chair) Prasant Mohapatra, University of California,=20 Davis, USA =20 (Co-Chair) Program Chairs: Sanjoy Paul, Whenu, USA G. Venkatesh, SASKEN Technologies, India Jim Woodcock, University of York, UK Tutorial Chair: Archan Misra, IBM Research, USA Workshop Chairs: Ashwin Gumaste, Fujitsu Research, USA Gaurav Sharma, University of Rochester, USA Demos/Exhibit Chair: Huzur Saran, IIT, Delhi, India Demos/Exhibit Co-Chair: Jaijit Bhattacharya, Oracle, India Publicity Chair: Thyaga Nandagopal, Lucent Technologies, USA Publicity Co-Chairs: Sunghyun Choi, Seoul National University, Korea Marco Conti, IIT, Pisa, Italy Ben Lancini, LinLan, Brisbane, Australia Prashant Pradhan, IBM Research, USA Hemant Chaskar, Airtight Networks, India Local Arrangement Chair: Sudipta Maitra, IBM, Delhi _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue Jun 28 17:40:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnNoG-0004lK-CT; Tue, 28 Jun 2005 17:40:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnNoE-0004jf-Pi for mpls@megatron.ietf.org; Tue, 28 Jun 2005 17:39:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29161 for ; Tue, 28 Jun 2005 17:39:55 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnODe-0003Pk-24 for mpls@ietf.org; Tue, 28 Jun 2005 18:06:15 -0400 Received: from du-069-0253.access.clara.net ([217.158.132.253] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1DnNo4-000HUm-7y; Tue, 28 Jun 2005 22:39:49 +0100 Message-ID: <030f01c57c2a$3deefbb0$c9919ed9@Puppy> From: "Adrian Farrel" To: , References: Date: Tue, 28 Jun 2005 22:14:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.9 (++) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: Subject: [mpls] Further short last call on draft-ietf-ccamp-inter-domain-framework-03.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org draft-ietf-ccamp-inter-domain-framework-03.txt has been updated after CCAMP WG last call. The changes were purely editorial, but there were quite a few changes made so we shall have another quick last call ending on 6th July at noon GMT. I want to bring this I-D to the attention of the MPLS WG since it covers TE for MPLS and GMPLS. Please read, review and comment. Thanks, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 30 02:56:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnsyK-0000dy-2R; Thu, 30 Jun 2005 02:56:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnsyH-0000dq-Fe for mpls@megatron.ietf.org; Thu, 30 Jun 2005 02:56:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09992 for ; Thu, 30 Jun 2005 02:56:24 -0400 (EDT) Received: from pne-smtpout2-sn2.hy.skanova.net ([81.228.8.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DntNy-0001ii-P3 for mpls@ietf.org; Thu, 30 Jun 2005 03:23:00 -0400 Received: from [127.0.0.1] (213.66.236.118) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 42B94E290016E37C; Thu, 30 Jun 2005 08:56:10 +0200 Message-ID: <42C39782.4030108@pi.se> Date: Thu, 30 Jun 2005 08:56:02 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Bill Fenner Subject: [mpls] draft-zamfir-explicit-resource-control-bundle-05.txt as a wg doc X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Working group, in Minneapolis we discussed the draft-zamfir-explicit-resource-control-bundle-05.txt (well an earlier version but anyway...) The authors suggested that we make it a wg document. There were pretty good support for this at the meeting could you before July 18th state your opinions on making it a wg document. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 30 09:34:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzBA-0004LN-Sj; Thu, 30 Jun 2005 09:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnzB7-0004LF-WF for mpls@megatron.ietf.org; Thu, 30 Jun 2005 09:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11005 for ; Thu, 30 Jun 2005 09:34:04 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnzal-0007KT-Ny for mpls@ietf.org; Thu, 30 Jun 2005 10:00:43 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id GAA19543; Thu, 30 Jun 2005 06:33:30 -0700 (PDT) Received: from XCH-SWBH-04.sw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5UDXTv24299; Thu, 30 Jun 2005 08:33:29 -0500 (CDT) Received: from XCH-SW-42.sw.nos.boeing.com ([192.79.11.43]) by XCH-SWBH-04.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 06:33:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] draft-zamfir-explicit-resource-control-bundle-05.txt as a wgdoc Date: Thu, 30 Jun 2005 06:33:28 -0700 Message-ID: <626FC7C6A97381468FB872072AB5DDC8369349@XCH-SW-42.sw.nos.boeing.com> Thread-Topic: [mpls] draft-zamfir-explicit-resource-control-bundle-05.txt as a wgdoc Thread-Index: AcV9QTncYptqUNKYSGWujwWrW0qaIQANuO3w From: "Drake, John E" To: "Loa Andersson" , X-OriginalArrivalTime: 30 Jun 2005 13:33:28.0817 (UTC) FILETIME=[4CCFEE10:01C57D78] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: Bill Fenner X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org Yes, it's a very nice piece of work. -----Original Message----- From: Loa Andersson [mailto:loa@pi.se]=20 Sent: Wednesday, June 29, 2005 11:56 PM To: mpls@ietf.org Cc: Bill Fenner Subject: [mpls] draft-zamfir-explicit-resource-control-bundle-05.txt as a wgdoc Working group, in Minneapolis we discussed the draft-zamfir-explicit-resource-control-bundle-05.txt (well an earlier version but anyway...) The authors suggested that we make it a wg document. There were pretty good support for this at the meeting could you before July 18th state your opinions on making it a wg document. Loa and George --=20 Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu Jun 30 23:51:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCYr-0002jL-KC; Thu, 30 Jun 2005 23:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoCYp-0002jG-MQ for mpls@megatron.ietf.org; Thu, 30 Jun 2005 23:51:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07182 for ; Thu, 30 Jun 2005 23:51:25 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoCyh-0001Ms-Rs for mpls@ietf.org; Fri, 01 Jul 2005 00:18:13 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Jun 2005 20:51:16 -0700 X-IronPort-AV: i="3.93,248,1115017200"; d="scan'208"; a="195752191:sNHT26273056" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j613p56t004986; Thu, 30 Jun 2005 20:51:13 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 23:50:49 -0400 Received: from [192.168.1.101] ([10.86.240.86]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 23:50:49 -0400 In-Reply-To: <42C39782.4030108@pi.se> References: <42C39782.4030108@pi.se> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23385E7B-F2CB-4E7E-85C4-9337AD06D730@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [mpls] draft-zamfir-explicit-resource-control-bundle-05.txt as a wg doc Date: Thu, 30 Jun 2005 19:47:06 -0400 To: Loa Andersson X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 01 Jul 2005 03:50:49.0151 (UTC) FILETIME=[11A3FCF0:01C57DF0] X-Spam-Score: 0.7 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Bill Fenner , mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@lists.ietf.org Errors-To: mpls-bounces@lists.ietf.org in favor. JP. On Jun 30, 2005, at 2:56 AM, Loa Andersson wrote: > Working group, > > in Minneapolis we discussed the > draft-zamfir-explicit-resource-control-bundle-05.txt > (well an earlier version but anyway...) The authors suggested > that we make it a wg document. There were pretty good support > for this at the meeting could you before July 18th state > your opinions on making it a wg document. > > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls