-----Original Message-----
From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Richard Rabbat
Sent: Thursday, August 14, 2003
2:09 PM
To: ccamp@ops.ietf.org
Cc: 'Vishal Sharma'
Subject: Time-bounded notification
Hello Everyone,
Following some discussions prior to Vienna, and feedback and
comments received during Vienna and thereafter, we have realized that perhaps
one aspect of draft-rabbat-fault-notification-protocol-03.txt that we may not
have adequately highlighted is its focus on providing *time-bounded* notification.
This is because draft-rabbat focuses on recovery in optical
transport networks, where recovery of failed LSPs (fibers, lambdas, etc.) in a
*bounded time* is critical for the
provider to be able to offer guarantees/SLAs to its transport customers, and
also to its L2 and L3 customers. The transport infrastructure often serves as a
foundation for the L2 and L3 networks built upon it, and so should be able to
provide recovery within some well-specified time, so that L2 and L3 recovery
can be appropriately performed based on what L1 provides.
For this reason, notification via signaling or OSPF-based
flooding, which could work well at the packet layer, may not be directly
applicable at the transport layer.
I agree with the notion of the
time-bounded recovery. However, here you started to make assumption about possible
solutions. The same confusion arrived at the last IETF meeting when an LMP
based solution was presented. All I am saying is that IMO breaking the
problem into two part, I.e., getting agreement on the requirements and then
following it up with the solution would be the right approach.
[Richard] Agreed. Let’s write a document to highlight
that based on our ML email exchange.
I agree with the requirement part of the
problem statement.
[Richard] Thanks.
In fact, since recovery at the packet layer may not
involve the stringent time constraints that are applicable at the transport
layer, directly comparing notification solutions at the packet layer with those
at the transport layer is probably not accurate.
What would be useful here is to quantify
the differences
between the two types of networks. Such quantification will be useful in
catalyzing some email discussions at the mailing list.
[Richard] Yes
Rather, we need to examine (as done in draft-rabbat) the
applicability of signaling and flooding to notification *at the transport layer* under the
constraint of achieving time-bounded recovery.
Agreed!
[Richard] We will try to add examples that will help
visualize the problem at the transport layer and the network model assumption.
So if the WG looks at draft-rabbat with this backdrop, we
believe some of the arguments made there will be clearer. Of course, we welcome
feedback from the list.
[snipped]