Subject: Re: Last call on recovery framework

From: "Irfan Lateef" <[email-masked]>
Date: Tue, 04 Sep 2001 13:28:14 -0400

George,
Here are a few comments based on draft-ietf-mpls-recovery-frmwrk-03.txt

There are no explicit definitions or reference to definitions
of path, segment, and link in the framework.
In the absence of these I have assumed that the definition of
working path in section 2.3.1 as the definition of path.
"Working Path

The protected path that carries traffic before the occurrence of a
fault.  The working path exists between a PSL and PML. The working
path can be of different kinds; a hop-by-hop routed path, a trunk, a
link, an LSP or part of a multipoint-to-point LSP.
"
According to this, I am assuming that a path is between two end
points of an LSP which may span more than one path segments. As per
this definition the rest of the doc discusses the path segment faults.
These segment may or may not be at the ingress/egress points. It does
not definitively address detection of fault at ingress/egress points.

Liveness Message is defined as
"  Liveness Message

   A message exchanged periodically between two adjacent LSRs that
   serves as a link probing mechanism. It provides an integrity check of
   the forward and the backward directions of the link between the two
   LSRs as well as a check of neighbor aliveness.
"
The above definition of liveness message indicates it is detecting
link failure. How is it different from the lower layer link failure
detection already in place.

The definition of the Path Continuity Test hints at the notion of a
path consisting of multiple path segments, but rest of the document
does not differentiate between a path and path segment.

1. In section 3.5, liveness message is being proposed as a path
failure detection mechanism. If liveness message is between adjacent
LSR, it may be able to detect a failure of segment of path. If it is
between path segment of adjacent LSRs then what does it mean by

"  the test message
   must be guaranteed to follow the same route as the working or
   recovery path, over the segment being tested"

Since it is across just one link, I think it is automatically
guaranteed. Are you just being explicit here or mean something else.

Again Path Degraded and Link Degraded appear to between the
same one link but at different layers.

The summary of the above points is, the framework should differentiate
between the path and segment in the MPLS layer and link at the lower
layer. It should propose different mechanisms for path and segment
and link failure detection. May be it is doing so, but somehow
section 3.5 is not very clear. Perhaps it should rename Path as
Path Segment and write one more paragraph on path failure, and propose
Lsp-ping like detection for path failure which may always be detected
at source and destination of paths.

In section 3.6 the fault notification processing for sending FIS to
upstream nodes may not meet the protection swithcing reqs if there
are a large number of hop between the fault and the ingress node.
It appears like the FIS is traversing the stack upto the application
on all the nodes to determine as to which nodes the FIS should be
forwarded.

Finally, the detection mechanism should be somehow related to
repair mechanism. For example, the framework should propose a
coordination mechanism between local and global repair using which
FIS may be sent only to those nodes which have to trigger global
repair like protection switching.

What happens if the OSPF flooding starts at the same time as FIS
and slows down the FIS.

Hope some of my comments make sense.

Regards,
Irfan Lateef

>From: George Swallow <[email-masked]>
>To: [email-masked]
>CC: [email-masked]
>Subject: Last call on recovery framework
>Date: Tue, 21 Aug 2001 18:03:49 -0400
>
>This message begins a last call on
>
>       Framework for MPLS-based Recovery
>       <draft-ietf-mpls-recovery-frmwrk-02.txt>
>
>The last call ends on Sept 5 at midnight GMT.
>
>...George
>
>
>======================================================================
>George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

From: "R.F. Graveman" <[email-masked]>
Date: Wed, 5 Sep 2001 16:31:41 -0400 (EDT)

Section 6 states that "The MPLS recovery that is specified herein
does not raise any security issues that are not already present in
the MPLS architecture."

This may or may not be technically correct, but in either case, this
comment suggests that inserting a bit more informative detail about
those security issues in the case of MPLS-based recovery would be helpful.

In particular, a forged failure notification or FIS may cause costly and
unnecessary reconfigurations as well as having several other effects:
 - susceptibility of rerouted traffic to eavesdropping or tampering,
 - facilitated traffic analysis,
 - diverted revenue for carrying traffic,
 - general denial of service caused by storms of conflicting failures,
 - increased time to recovery for legitimate failures,
 - compromised quality of service.

To prevent such attacks, cryptographic authentication of the failure
notification or FIS can be used, and the failure notification or FIS
can be filtered based on incoming interface.

It may also be noted that using global or multi-layer repair and concatenated
protection domains may increase protocol risks of the above type. For example,
key management for cryptographic protection is likely to be more difficult
in the global case.

In n-to-1 and n-to-m protection schemes, it may be possible for one
or a small coalition falsely to simulate a failure and therefore
consume the recovery resources of competing users.

Finally, the management protocols used to establish and communicate
recovery configuration and state information may be subject to attack
if left unprotected.

Richard Graveman | V: +1 973 829 2632 | Telcordia 445 South St., Rm. 1A-352R
[email-masked]      | F: +1 973 829 5981 | Morristown, NJ 07960 USA