Subject: Fw: Liaison from the OIF

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 20 May 2006 15:15:35 +0100

Hi,

We have received a communication from the OIF about the use of GMPLS 
protocols to provide 1:n protection. This includes a lot of questions for 
clarification and, although my first response is to suggest more careful 
reading of the associated RFCs and I-Ds, we should, nevertheless put 
together a more detailed reply pointing to the relevant sections and 
explaining how the protocols work

Deborah and I (ha! welcome to the world of work, Deborah ;-) will put 
together a response for your review, but we would welcome input from all 
interested parties.

The text of the communication is included below. It can be found in its 
original form (PDF) together with an attachment (PPT) at 
www.olddog.co.uk/incoming.htm

Thanks,
Adrian
----- Original Message ----- 
From: "Lisa Daugherty" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "'Jim Jones'" 
<[email-masked]>; "'Trey Malpass'" <[email-masked]>
Sent: Friday, May 19, 2006 7:17 PM
Subject: Liaison from the OIF

> Dear Adrian and Deborah,
>
> On behalf of OIF Technical Committee Chair, Jim Jones, attached please 
> find
> a liaison letter and related OIF presentation (oif2006.031.01).
>
> Kind regards,
> Lisa
>
> Lisa Daugherty/ Association Coordinator / OIF
> 39355 California Street, Suite 307/ Fremont, CA 94538
> Phone: 510.744.4016 (direct) / 510.608.5928 (main)
> Fax: 510.608.5917
> Email: [email-masked]
> http://www.oiforum.com
>
> Managed by Association Management Solutions (AMS);
> Forum Management, Meeting and Event Planning
> http://www.amsl.com

======
To: Adrian Farrel and Deborah Brungard, IETF CCAMP WG Co-Chairs
From: Jim Jones, OIF TC Chair
Copy: Ross Callon and Bill Fenner, IETF Routing Area Directors
Subject: Liaison to IETF CCAMP WG on 1:N Protection

Dear Adrian and Deborah,

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 .

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.

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.

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.

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. 
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.

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.)

The OIF would appreciate the review and feedback of the CCAMP working group 
on these items.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments
1.) Update for 1:N Protection capability: Control Plane assisted 1:N link 
connection protection (oif2006.031.01)