Re: Updated draft response to OIF on 1:n protection

[Lou Berger <[e-mail]>]

Adrian,
         I like what you have so far, but there is one additional item to add:

Bulk notifications *are* supported in the recovery drafts using the 
Notify message.  Notify messages could be used to provide a "single 
signaling interaction" and "a bulk notification ... 
procedure".  Protection/recovery could then be provided on a per LSP 
basis (per segment protection) or use the hierarchy approach you 
mentioned below.  (Bulk) reversion is also supported via Notify 
messages, see section 12 of 
draft-ietf-ccamp-gmpls-recovery-e2e-signaling.  Note that these 
procedures also apply to segment recovery.

Lou

At 03:43 PM 6/8/2006, Adrian Farrel wrote:

>Hi,
>
>Looking at the latest input from the OIF, I think we have to perform
>some type of meld on the two incoming communications and respond
>to them together.
>
>Here is my attempt building on what we had before. Please comment on or
>off the list.
>
>Thanks,
>
>Adrian
>
>==
>
>Dear Jim,
>
>Thank you for your communication to CCAMP on the use of GMPLS to provide
>1:n protection at the OIF UNI and the OIF E-NNI dated 20th May 2006 and
>for your updates received on 2nd June 2006.
>
>We are grateful for this opportunity to comment, but we note that this
>type of communication requesting clarifications is better suited to 
>a mailing list discussion than to official communications that, by their
>nature, have a slow turn-around. This opinion is considerably 
>reinforced by the process we have gone through here with a revision to
>the OIF communication being generated while CCAMP is trying to draft 
>its response. It seems to us that if official lines of communication 
>are to be followed then they have to be adhered to, but if iterative
>discussions are needed (as has proved to be the case here) then it would
>be possible to respond far more dynamically using mailing lists.
>
>The appropriate place for discussions of GMPLS protocols is the CCAMP
>working group mailing list. Details of how to subscribe to the mailing
>list can be found at
>http://www.ietf.org/html.charters/ccamp-charter.html
>
>Anyway, the CCAMP chairs are keen to ensure smooth communications with
>the OIF and have consulted as widely as they could in the short time in
>order to update the response that we had already drafted to your 
>original enquiries.
>
>We hope that our answers are satisfactory.
>
>In the remainder of our response we have quoted extracts from your two
>communications as:
>
>>1> For a quote from the first communication dated 20th May 2006
>
>>2> For a quote from your second communication dated 2nd June 2006
>
>>1> Future updates to OIF UNI and E-NNI signaling may include a feature
>>1> for 1:N connection protection. The attached document presents
>>1> requirements for these features. Recently a review was completed
>>1> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
>>1> implement this function (including draft-ietf-ccamp-gmpls-recovery-
>>1> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
>>1> It appears that the abstract messages from RFC 4426 provide much
>>1> of this functionality, however several questions resulted from this
>>1> review. OIF would appreciate review and comments from IETF
>>1> CCAMP on the following items.
>>1>
>>1> 1.) OIF would appreciate knowing if there are protocol features in
>>1> other IETF documents relevant to 1:N protection .
>
>We would like to suggest that, in order to utilize advanced features of
>the GMPLS control plane protocol, engineers should be familiar with the
>full set of GMPLS RFCs and Internet-Drafts. These are listed on the
>CCAMP charter page and can be downloaded free of charge by clicking on
>the links.
>
>Although not all of this work is directly related to protection and
>restoration, it should be noted that any protocol aspect present for a
>working path may also be required for a protection path. Protocol
>engineers must, therefore, be familiar with the details of the protocol
>before attempting to provide advanced functions like protection.
>
>>2> 1) OIF would appreciate CCAMP's guidance as to whether CCAMP has
>>2> defined standards for any similar form of restoration, i.e., one
>>2> that protects a group of LSPs at once over a local span, by
>>2> shifting these LSPs from their original link within the span over
>>2> to a backup link.  It should be noted that
>>2> - the backup link may be a different type than the original
>>2> (e.g., OC192 rather than OC48), so that GMPLS signaling rather
>>2> than underlying SONET/SDH link protection is used to perform
>>2> the switchover; and
>>2>
>>2> - it is intended that the affected LSPs be shifted using a
>>2> single signaling interaction rather than separate interactions
>>2> per individual LSP in order to reduce the signaling overhead
>>2> required.
>>2>
>>2> We believe that some of the existing work, especially for segment
>>2> recovery, may be helpful, but may not meet the exact requirements
>>2> of the service that has been proposed within OIF. Any pointers to
>>2> existing drafts or RFCs, however, would be greatly appreciated.
>
>There are two principal ways in which the objectives you cite can be
>met, and both of these techniques are, to our certain knowledge, 
>implemented and successfully deployed.
>
>a) Link-level protection. This technique relies on the protection
>   of the underlying link outside the scope of GMPLS. Thus, the
>   TE link over which one or more LSPs are provisioned is actually
>   supported by more than one underlying link. When one link fails,
>   the traffic that it was carrying (the LSPs) is transferred to
>   another link. This type of protection is transparent to GMPLS
>   although it could leverage GMPLS fault notification procedures.
>
>   You can learn some more about link-level protection by reading
>   RFC3945 and RFC4426 (where it is referred to as Span Protection).
>
>   Please note that the links used in this mode do not need to be
>   of the same type. This is not link bundling.
>
>b) LSP Hierarchies. This technique relies on nesting multiple LSPs
>   within another LSP. Most familiar in packet technologies, this
>   process is also applicable to non-packet technologies where
>   appropriate adaptation is available.
>
>   By nesting multiple LSPs within another LSP, it is possible to
>   reroute them all simply by rerouting the nesting LSP. Thus any
>   protection scheme that can be applied to the nesting LSP can be
>   applied to the nested LSPs in a single stage. Such procedures
>   are, therefore, fully available for GMPLS control.
>
>   You can read more about LSP hierarchies in RFC4206.
>
>Excellent though the procedures documented in
>draft-ietf-ccamp-gmpls-segment-recovery are, we are unsure as to the 
>"exact requirements of the service that has been proposed
>within OIF" and so cannot be sure which procedures to advise for
>the problem as you have described it.
>
>>2> 2) Reviewing some of the existing RFC text, we note that RFC 4426
>>2> section 2.5.2 states "it MAY be possible for the LSPs on the working
>>2> link to be mapped to the protection link without re-signaling each
>>2> individual LSP" and "it MAY be possible to change the component
>>2> links without needing to re-signal each individual LSP".
>>2> This text appears to refer to the use of SONET/SDH link protection
>>2> in such a way that the labels for each LSP remain the same. Does
>>2> this imply, however, that an action that changes the local
>>2> labels for the affected LSPs then requires re-signaling of each
>>2> individual LSP, or is there a "bulk" mechanism to change labels
>>2> for a group of LSPs simultaneously?
>
>Your question is confusing in the light of the referenced section. The
>section describes the messages required to achieve span protection.
>Clearly, if a span is protected, then all LSPs carried over that span
>may be transparently protected. This is how normal link protection 
>operates and there is nothing clever going on.
>
>Obviously (hopefully this is obvious) if you change the label in use on
>a link for a particular LSP then the NEs at each end of the link 
>need to know that information since both the sender and the receiver need to
>use the correct label. This applies for each LSP whose label you change.
>The accepted mechanism in the control plane for exchanging labels is the
>signaling protocol, so it follows that, if you wish to change the label
>in use for an LSP on a link, you must engage signaling.
>
>You should observe that an NE may change the label in use on a link at
>any time using the RSVP-TE protocol. All that is required (assuming a
>unidirectional LSP) is a trigger Resv message carrying a new label.
>Considerations of the impact to user traffic are left as an exercise for
>the reader.
>
>It is unclear how the "bulk" mechanism you propose could operate unless
>it was well-known that all labels are going to change in the same 
>way. So perhaps you are suggesting that a single signaling message 
>might itemise all of the LSPs and show each new label. If this is 
>really a significant issue (i.e., you feel it is absolutely 
>imperative to reduce
>the number of signaling messages) then you should consider RSVP message
>bundling.
>
>>2> 3) RFC 4426 describes the sending of the Failure Indication
>>2> Message upon detection of failure by a slave device.  It is
>>2> our belief that the same mechanism could also be used when
>>2> the slave device is triggered to send an indication due to
>>2> management system intervention (cases are mentioned in RFC
>>2> 4427 but not in 4426), and we would like to know if CCAMP
>>2> concurs with this.
>>2> An example of where this might occur is where the master
>>2> and slave devices are in different management domains.
>
>As you correctly observe, RFC4427 section 4.13 describes exactly this
>case where management plane intervention causes a Failure Indication,
>and it is useful for forced or controlled switch-over.
>
>You should note that RFC4426 section 2.5.1 says of the Failure
>Indication message...
>   This message is sent from the slave to the master to indicate the
>   identities of one or more failed working links.  This message MAY not
>   be necessary when the transport plane technology itself provides for
>   such a notification.
>
>It could also be the case that the message MAY not be necessary in the
>case where the failure indication is conveyed to the master node by the
>management plane. That is to say, there is no specific requirement (in
>the case of management plane intervention) for the intervention to 
>be to the slave and causing a Failure Indication message to be sent to the
>master - the management plane intervention could consist of a 
>notification sent to both the slave and the master from the management
>plane.
>
>The absence of this discussion within the GMPLS RFCs owes much to the
>fact that they are largely control plane specifications with some notes
>about the management plane for additional helpfulness.
>
>Your final example about the use of this technique where the master and
>slave are in different management domains is interesting, but the use of
>a control plane means that you should consider the control plane 
>domains, not just the management domains.
>
>>1> 4.) A goal of the 1:N protection is to use a bulk notification and
>>1> recovery procedure, based on RFC 4427 section 4.15. However, that
>>1> RFC states the corresponding recovery switching actions are
>>1> performed at the LSP level. It would be useful to know if bulk
>>1> processing could be applied to recovery of individual connection
>>1> segments on the failed span, not entire LSPs.
>
>>2> 4) RFC 4427, section 4.15 discusses bulk recovery for a failed span,
>>2> and suggests that the recovery switching message to recovered LSP
>>2> ratio may be 1 or greater.  OIF would like to know if it is possible
>>2> to define procedures such that the ratio is much less than 1, 2> 
>>i.e., a message that causes bulk recovery actions on a number of
>>2> LSPs.
>
>We believe that you have missed the point of section 4.15 of RFC4427.
>This section is describing the case where all or only some of the LSPs
>carried on a span are protected by a single recovery message 
>exchange (full or partial span protection). In the case of partial span
>protection it is possible that not all LSPs on the span will be
>protected. Thus, the discussion of message to LSP ratios refers to the
>number of recovery messages needed to protect the LSPs on a span.
>
>The expression of the ratios is probably unclear, but the subsequent
>text explains the situation.
>
>Let us assume that there are S LSPs on the span, and s LSPs protected by
>a protection message. Consider the ratio S/s.
>
>If S/s = 1, one message has been used to protect all LSPs on the span.
>(Full recovery)
>
>If S/s > 1, more than one message is used to protect all of the LSPs on
>the span OR not all LSPs on the span are protected. (Partial recovery)
>
>Clearly a ratio of less than one would be particularly odd !
>
>It should be obvious from wider reading of the RFCs (4436, 4427, and
>3473) that the whole point of the Failure Indication is to be able to
>report on more than one LSP failure at a time.
>
>>2> 5) RFC 4426 defines a "master" and "slave" role for dedicated 1+1
>>2> and 1:1 span protection and a "source" and "destination" role for
>>2> control of end-to-end restoration and for reversion.  We believe
>>2> that "source" and "destination" mean the initiator and receiver
>>2> of the LSP (as opposed to the source and destination of data
>>2> in-band).
>
>The terms "source" and "destination" are standard.
>
>For unidirectional LSPs, the "source" is the source of data on the LSP,
>also known as he ingress. Where a control plane is used, signaling 
>progresses from the source (also known as the head-end).
>
>Similarly, the "destination" is the destination of data on the LSP, also
>known as the egress. Where a control plane is used, signaling progresses
>from the source to the destination (also known as the tail-end).
>
>By common convention, for bidirectional LSPs set up by the control
>plane, the "source" remains the signaling source (ingress) and the
>"destination" is the signaling destination (egress). Traffic flowing
>in the reverse direction is referred to as reverse direction traffic
>and flows from destination to source.
>
>Very probably there is an ITU-T architectural term for these end points
>of LSPs.
>
>Note that RFC 4426 is very careful to state:
>   The end-to-end recovery models discussed in this
>   document apply to segment protection where the source and destination
>   refer to the protected segment rather than the entire LSP.
>
>Should this still be unclear to you, RFC4426 section 1 states
>   Consider the control plane message flow during the establishment of
>   an LSP.  This message flow proceeds from an initiating (or source)
>   node to a terminating (or destination) node, via a sequence of
>   intermediate nodes.  A node along the LSP is said to be "upstream"
>   from another node if the former occurs first in the sequence.  The
>   latter node is said to be "downstream" from the former node.  That
>   is, an "upstream" node is closer to the initiating node than a node
>   further "downstream".  Unless otherwise stated, all references to
>   "upstream" and "downstream" are in terms of the control plane message
>   flow.
>
>The terms "master" and "slave" are introduced to describe the trigger
>points for protection activity and are defined clearly in section 2.3
>of RFC4426.
>   Consider two adjacent nodes, A and B.  Under 1:1 protection, a
>   dedicated link j between A and B is pre-assigned to protect working
>   link i.  Link j may be carrying (pre-emptable) Extra Traffic.  A
>   failure affecting link i results in the corresponding LSP(s) being
>   restored to link j.  Extra Traffic being routed over link j may need
>   to be pre-empted to accommodate the LSPs that have to be restored.
>
>   Once a fault is isolated/localized, the affected LSP(s) must be moved
>   to the protection link.  The process of moving an LSP from a failed
>   (working) link to a protection link must be initiated by one of the
>   nodes, A or B.  This node is referred to as the "master".  The other
>   node is called the "slave".  The determination of the master and the
>   slave may be based on configured information or protocol specific
>   requirements.
>
>Thus, the "master" is responsible for initiating the switchover, and the
>slave is responsible for keeping up with the state changes.
>
>>1> Further, it would be helpful to understand why the actions are
>>1> performed by source and destination nodes rather than master and
>>1> slave nodes. It may be appropriate to reuse the master/slave roles
>>1> in the reversion process just as is done in the switchover process.
>
>>2> We are not clear on the rationale for when control
>>2> plane roles are based on master/slave vs. source/destination:
>>2> it appears that local span actions are controlled using
>>2> master/slave while remote actions are controlled using
>>2> source/destination, however the reasoning for control of
>>2> reversion is less clear to us.  Any clarification of the
>>2> rationale for using master/slave vs. source/destination
>>2> control would be appreciated.
>
>As explained by the definitions of the terms, there is a distinction
>between the node that invokes a switchover process (the master) and a
>node that performs the process. For example, a Bridge and Switch Request
>message is sent by the source node after it has bridged traffic back 
>to both working and protection links simply because the source node 
>has performed the bridging and is the only node that can know this fact.
>
>In other words, whether the source is master or slave depends on the
>protection scheme in use and the nature of the operation. It should be
>a simple matter when considering a protection scheme and the necessary
>protocol exchanges and switchover actions to determine which of the
>source and destination must play the master or slave role.
>
>>1> In addition, RFC 4426 does not include an abstract message similar
>>1> to the Failure Indication Message to request the beginning of the
>>1> reversion procedure. It may be beneficial to include a message from
>>1> the slave device to initiate reversion, just as there is a Failure
>>1> Indication Message to initiate switchover. (RFC 4426 states that the
>>1> Failure Indication Message may not be needed when the transport 
>>1> plane technology itself provides such a notification. The same may
>>1> apply when a failure is cleared; however, there should still be an
>>1> optional message to trigger the reversion process.)
>
>>2> 6) We believe that it may be useful in some cases of reversion to
>>2> allow a "slave" device to request reversion using an abstract 2> 
>>message similar to the Failure Indication Message.  An example
>>2> case is (again) when the "master" and "slave" devices are in
>>2> different management domains, such that reversion is initiated from
>>2> the management domain of the "slave" device.  We request CCAMP 
>>2> comment on this suggestion.
>
>Reversion is described as an administrative procedure in RFC4426 and
>RFC4427 quite deliberately. In our view it should not be a rapid 
>response to a specific situation triggered through the control plane
>by the 'master', but should be a considered operation under the control
>of administrative policy. The trigger is, therefore, outside the 
>scope of the control plane. This discussion can be seen in section 
>4.13 of RFC4427.
>
>We believe that your suggestion does not change this view, but that you
>are proposing that the control plane be used as a transport for a 
>management plane request. You are suggesting that a management station
>in the management domain that contains the slave sends the request 
>to the slave, the slave would then deliver the request through the control
>plane to the master. In the absence of any specific control plane
>requirement for this message, we believe that the correct architectural
>approach is for management plane messages to be delivered in the 
>management plane. Thus, if there is a need for management plane 
>coordination between separate management plane domains, this should be
>arranged through an appropriate management plane peering point where 
>the correct policies can be applied.
>
>
>We hope this answers your questions, and we would be happy to enter into
>further dialog on these topics.
>
>In conclusion, it may be helpful to the OIF to know the status of two
>CCAMP drafts related to recovery.
>draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03 and
>draft-ietf-ccamp-gmpls-segment-recovery-02 both completed CCAMP
>working group last call in early 2005. Since then they have been
>implemented and tested. The drafts are stable and complete, and are
>queued in the IETF process waiting to become RFCs
>
>
>
>Best regards,
>Adrian Farrel and Deborah Brungard
>CCAMP co-chairs
>
>
>
>
>
>
>
>
>--
>Internal Virus Database is out-of-date.
>Checked by AVG Anti-Virus.
>Version: 7.1.394 / Virus Database: 268.7.0/345 - Release Date: 5/22/2006