Subject: Draft response to OIF on 1:n protection

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 May 2006 20:50:32 +0100

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

---

From: Wataru Imajuku <[email-masked]>
Date: Tue, 23 May 2006 07:03:14 +0900

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:
 >mailing list. Details of how to subscribe to the mailing list can be 
found at http://www.ietf.org/html.charters/ccamp-charter.html
 >Adrian Farrel and Deborah Brungard

-------------------------------------
Wataru Imajuku@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: +81-468-59-5541

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 23 May 2006 00:12:27 +0100

Hi Wataru,

Thanks for your mail. I wonder if you could clarify precisely which proposal
you are referring to in the OIF communication and how you believe it should
be taken forward.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 May 2006 17:35:32 +0100

Hi,

Jim Jones has been in touch to ask that we hold off responding for a while. 
it appears that having read this draft response, some OIF folk would like to 
spend some time clarifying the questions.

Thanks,
Adrian