Subject: [mpls] RFC 4875 one-to-one fast reroute procedures (section 15.2)

From: "Nic Neate" <[email-masked]>
Date: Mon, 7 Jul 2008 16:33:41 +0100

Hi all,

RFC 4875 section 15.2 (http://tools.ietf.org/html/rfc4875#section-15.2)
defines one-to-one fast reroute procedures for P2MP LSPs.  I've got a
few questions on some fairly high level aspects of this behaviour.  I'd
appreciate it if anyone could clarify these points for me, or let me
know how your implementation interprets them.

(1) Backup path state identifiers

This is complicated by the fact that a PLR may initiate multiple backups
protecting the same next hop, each for a different S2L sub-LSP.

Ordinary P2MP LSP path state is uniquely identified by the SESSION and
SENDER_TEMPLATE objects, including the sub-group identifiers (section 10
of the RFC).

In P2P fast reroute, with Path-specific signaling, the DETOUR object is
used as a further identifier for backup path state.  However, that is
insufficent for backups to P2MP LSPs because a PLR may originate
multiple backups for different S2L sub-LSPs with identical DETOUR
objects.

It's unclear how that path state should be differentiated.  Using
S2L_SUB_LSP objects as path state identifiers would be inconsistent with
normal P2MP LSP processing, and might lead to problems if an S2L_SUB_LSP
is moved to a different sub-group (it would be considered new backup
path state rather than a re-optimization).  The alternative would be for
the PLR to always use different sub-group identifiers for the different
backups it originates, however the RFC does not state that it must do
that.

Which behavior is correct?

(2) P2MP backups

It is not explicitly stated whether P2MP backups are supported.  The
implication of backups being for individual S2L sub-LSPs is that backups
are P2P.  However, it is stated that there can be multiple S2L_SUB_LSP
objects in a single backup Path message, meaning that they do make up a
P2MP backup LSP.

Clearly P2MP backups would be benefical (in the same way as P2MP bypass
LSPs).  In particular, they would avoid the need to send multiple copies
of data down the same link following a failure of the protected LSP.

If they are allowed then it would be helpful to also state the merge
rules.  A single LSR could be a merge point for some S2L backups, a
branch point for others, and a cross-over for still others, with complex
mappings from upstream to downstream path state.

(3) Sub-group re-optimization

RFC 4090 fast reroute procedures are only applicable to explicitly
routed LSPs, not those that dynamically change their routes (RFC 4090
section 1 paragraph 2).

Sub-group re-optimization is a form of rerouting for P2MP LSPs.
However, it changes the LSP identifiers (the sub-group IDs in the
SENDER_TEMPLATE) for signaling the new route.  I think it should
therefore be compatible with fast reroute procedures, and allowable for
protected P2MP LSPs.  Furthermore, it would be useful function to allow
an ASBR to re-optimize a P2MP protected LSP that had suffered one or
more failure/repair.

RFC 4875 doesn't state whether or not sub-group re-optimization is
allowed for fast reroute protected P2MP LSPs.  Is it?

Thanks,

Nic Neate
Data Connection Ltd.
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls