Hi, Adrian and all
Thank you for introducing proposal from OIF.
I think this proposal is valuable to add specification
in RFC 4426/4427/4428 and related drafts.
The proposed functionality can enhances applicability of GMPLS protocols
to enhance the reliability of networks.
Best Regards
Wataru@NTT
At 04:50 06/05/23, Adrian Farrel wrote:
>Hi,
>
>Thanks to those who have sent me off-list comments.
>
>Here is a draft response to the OIF on 1:n protection. Please send me (or
>the list) your comments.
>
>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.
>
>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. 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
>
>> Future updates to OIF UNI and E-NNI signaling may include a feature
>> for 1:N connection protection. The attached document presents
>> requirements for these features. Recently a review was completed
>> of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
>> implement this function (including draft-ietf-ccamp-gmpls-recovery-
>> e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
>> It appears that the abstract messages from RFC 4426 provide much
>> of this functionality, however several questions resulted from this
>> review. OIF would appreciate review and comments from IETF
>>CCAMP on the following items.
>>
>> 1.) OIF would appreciate knowing if there are protocol features in
>> 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.) RFC 4426 section 2.5.2 says "it MAY be possible for the LSPs
>> on the working link to be mapped to the protection link without
>> re-signaling each individual LSP" and "it MAY be possible to change
>> the component links without needing to re-signal each individual LSP".
>> OIF would like to know what signaling messages and objects can be
>> used to accomplish this.
>
>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.
>
>Recall that section 2.5.2 is a subsection of section 2, and this is
>entirely dedicated to span protection.
>
>Further, if the bundling example is followed, the referenced RFC
>(RFC4201) explains the signaling necessary to achieve bundling.
>
>You may find it easier to consider this as a layering architecture. The
>span (link) that is protected is a lower layer commodity and its
>protection may be, therefore, transparent to the higher layer.
>
>If you have a specific question we would be happy to answer.
>
>> 3.) It is suggested that the Failure Indication Message (or
>> equivalent) from RFC 4426 can be triggered not only from a
>> failure but also a command from a management system.
>
>You have not asked a specific question here so it is hard to give any
>answer except for "yes".
>
>Management systems are usually regarded as supreme. A management
>system can instruct an implementation to do anything, and this may be
>useful for forced or controlled switch-over. You may want to refer to
>RFC4427 section 4.13.
>
>> 4.) A goal of the 1:N protection is to use a bulk notification and
>> recovery procedure, based on RFC 4427 section 4.15. However, that RFC
>> states the corresponding recovery switching actions are performed at
>> the LSP level. It would be useful to know if bulk processing could be
>> applied to recovery of individual connection segments on the failed
>> span,
>> not entire LSPs.
>
>We do not understand your question. Each LSP has its own entry in the
>switching matrix. Any switching recovery action that is required can
>only be applied to this individual entry. Implementations may have some
>optimisations (such as back-up, pre-programmed matrices, or magic matrix
>re-program commands), but this is clearly out of scope of a control
>plane specification.
>
>Please note that recovery switching actions are not signaling actions.
>
>We are also confused as to the meaning of "It would be useful to know if
>bulk processing could be applied to recovery of individual connection
>segments on the failed span, not entire LSPs." To process it further, we
>probably need to deconstruct the term Connection Segment. As you may be
>aware, the term 'connection segment' is not widely used in the ASON
>Recommendations and does not find a definition there. The reference from
>G.8081 is to an ATM forum document.
>
>We assume that you are concerned to provide end-to-end data transfer.
>Presumably you are interested in a variety of symmetrical cases such as
>client-layer connectivity, UNI-C to UNI-C connectivity, UNI-N to UNI-N
>connectivity, or UNI-N/E-NNI to E-NNI/UNI-N connectivity. The path
>between these points is an LSP (it may be a hierarchical LSP through
>which
>other LSPs are tunneled) and it is this path that you wish to protect.
>Whether you perform span, segment, or end-to-end protection, you are
>still
>protecting the LSP.
>
>> 5.) RFC 4426 refers to three abstract messages involved in the
>> reversion sequence:
>>
>> - A Bridge and Switch Request message from the source node after it
>> has bridged traffic back to both working and protection links.
>>
>> - A Bridge and Switch Response message from the destination node after
>> it has bridged traffic back to both working and protection links and
>> changed its selector to the working link.
>>
>> - A Bridge and Switch Completed message from the source node after it
>> has changed its selector to the working link and stopped sending
>> traffic
>> on the protection link (so the destination can stop transmitting on
>> protection).
>>
>> Since RFC 4426 covers these Bridge and Switch messages briefly, more
>> details should be specified on the operation and behavior in this
>> reversion process.
>
>If you have specific questions, we would be happy to answer them. If you
>believe that additional documentation is required, we would welcome your
>contributions as an Internet-Draft.
>
>> Further, it would be helpful to understand why the actions are
>> performed by source and destination nodes rather than master and
>> slave nodes. It may be appropriate to reuse the master/slave roles
>> in the reversion process just as is done in the switchover process.
>
>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 addition, RFC 4426 does not include an abstract message similar to
>> the Failure Indication Message to request the beginning of the
>> reversion
>> procedure. It may be beneficial to include a message from the slave
>> device to initiate reversion, just as there is a Failure Indication
>> Message
>> to initiate switchover. (RFC 4426 states that the Failure Indication
>> Message may not be needed when the transport plane technology
>> itself provides such a notification. The same may apply when a failure
>> is cleared; however, there should still be an optional message to
>> trigger the reversion process.)
>
>Reversion is described as an administrative procedure 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 is in section 4.13 of RFC4427.
>
>We hope this answers your questions, and we would be happy to enter into
>further dialog on these topics.
>
>Best regards,
>Adrian Farrel and Deborah Brungard
>CCAMP co-chairs
>
>
>
>
>
-------------------------------------
Wataru Imajuku@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: +81-468-59-5541