[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fw: Liaison from the OIF
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" <ldaugherty@oiforum.com>
To: <adrian@olddog.co.uk>; <dbrungard@att.com>
Cc: <rcallon@juniper.net>; <fenner@research.att.com>; "'Jim Jones'"
<jim.d.jones@alcatel.com>; "'Trey Malpass'" <trey.malpass@yahoo.com>
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: ldaugherty@oiforum.com
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)