The MPLS WG Archive

[sven.van_den_bosch@alcatel.be]

Hi,

I have the following comments/inputs regarding
draft-ping-rsvp-fastreroute-00.txt. Hopefully, if they are useful, they can
be taken into account in a next version of the draft.

A next section of the draft is to be expected soon. This new version is
expected to cover new merging rules and interoperability issues. Based on
draft-atlas-rsvp-local-protect-interop-02.txt we make the following
assumptions regarding the (updated) method:
- an ingress requesting local protection both inserts the FAST_REROUTE
object in the PATH message and sets the two flags, "Label Recording
desired" and "Local Protection desired", in the SESSION_ATTRIBUTE object.
- the EXT_TUNNEL_ID of the DETOUR message contains the ingress address and
the SENDER_ADDRESS contains the address of the PLR. This required for
proper operation of make-before-break on DETOURs.
- non-DETOUR capable LSR on the backup path do not reject the DETOUR setup
- merge nodes do not merge backup EROs under the merging rules specified in
draft-ping-rsvp-fastreroute-00.txt. Instead, it is proposed that they use
the normal ERO merging rules.

With these assumptions I have the following comments/inputs

1) Detour resource sharing

In draft-ping-rsvp-fastreroute-00.txt, it is proposed that LSPs can share
resources if their LSP_IDs are different and cannot share resources when
they are the same. While this is certainly true, it does not solve the main
resource sharing inefficiency that results from not merging the DETOUR LSPs
because will have the same LSP_ID. The DETOUR resource sharing rules will
in fact have to consider the SENDER_ADDRESS in addition to the LSP_ID.

Consider the network depicted below. A tunnel needs to be set up between
[R1] and [R6].

         [R7]-----[R8]---------[R9]----------[R10]
          |        |                          |
          |        |                          |
[R1]-----[R2]-----[R3]-----[R4]-----[R5]-----[R6]
          |        |                          |
          |        |                          |
         [R11]----[R12]--------[R13]---------[R14]

Suppose this tunnel is set up by means of two LSPs, LSP1 and LSP2, which
are used for load balancing. The path for LSP1 is [R1]-[R2]-[R3]-[R8]-[R9]
-[R10]-[R6]. The path for LSP2 is [R1]-[R2]-[R3]-[R12]-[R13]-[R14]-[R6].
Both LSPs are protected by means of the DETOUR fast local protection
mechanism. In this case, the detours for LSP1 protecting against node
failures of [R9] and [R10], DT1.1 and DT1.2, may share link [R2]-[R3] with
the primary path for LSP1. Similarly, the detours for LSP2 protecting
against node failures of [R13] and [R14], DT2.1 and DT2.2, may share link
[R2]-[R3] with the primary path for LSP2.

On link [R2]-[R3] we have the following situation
- LSP1 and LSP2 may share resources if the reservation style is SE
- DT1.1 may always share with DT1.2 (same for DT2.1 and DT2.2)
- DT1.1 and DT1.2 may not share with LSP1 (same for DT2.1, DT2.2 and LSP2)
- DT1.1 and DT1.2 may share with DT2.1 and DT2.2 when the reservation style
for LSP1 and LSP2 is SE.

This means that LSPs that are in the same SESSION sometimes may not be
allowed to share resources even if SE reservation style is used for the
primary LSP. Hence we propose the following resource sharing procedure for
DETOUR LSPs.
For different LSP_ID
  Base resource sharing decision on reservation style (share if SE)
For identical LSP_ID
  Base resource sharing decision on contents of SENDER_ADRESS and
  EXT_TUNNEL_ID (always share unless SENDER_ADDRESS differs from
  EXT_TUNNEL_ID and link is upstream of protected entity)

These resource sharing rules largely eliminate the bandwidth inefficiency
on the DETOUR path. However, the do not address the label conservation
issue. This can only be done by merging the DETOURs. We propose to use the
normal merging rules for ERO processing. This means that DETOURs will be
merged when they have the same (remaining) ERO. In this respect, it might
be appropriate for the ingress to specify the ERO for one or more DETOURs,
possibly as a result of learning the backup ERO that are computed by the
PLRs along the primary path. Such functionality could be provided by a
backup ERO/RRO object.

Note that the difference between RESV messages received for a DETOUR LSP
and a primary need no longer be made on the basis of the presence of a
DETOUR object. Instead they can be obtained from the SESSION and
SENDER_TEMPLATE objects only.

2) Bypass/Detour interoperability

In this section, we attempt to describe interoperability scenario between
LSRs implementing only BYPASS and other LSRs implementing only DETOUR. True
interoperability is only achieved if this holds. We then need to cover the
following interactions:

a. Ingress-PLR interaction

Assuming that the ingress is BYPASS-only capable and the PLR is DETOUR-only
capable, they could interact as follows. The ingress request local
protection by setting the local protection desired and label recording
desired flags in the SESSION_ATTRIBUTE. The PLR will detect that local
protection is required based on the SESSION_ATTRIBUTE. It can not provide a
BYPASS LSP, but instead it will protect the next hop with a DETOUR. To this
end, it constructs a PATH message for the DETOUR LSP as if it would have
received a FAST_REROUTE object containing the same setup priority, holding
priority, bandwidth and include and exclude colors as the primary LSP.

If the ingress is DETOUR-only capable and the PLR is BYPASS only capable,
the interaction goes as follows. The ingress indicates that local
protection is desired by inserting the FAST_REROUTE object and by setting
the local protection desired and label recording desired flags in the
SESSION_ATTRIBUTE. A BYPASS-only capable PLR will detect that local
protection is required based on the SESSION_ATTRIBUTE. It will do this by
providing a backup BYPASS LSP towards the NNHOP (node protection).

b. DETOUR LSR operation

A LSR on a DETOUR LSP is not required to support the DETOUR method.
Instead, it can pass the PATH message containg the DETOUR object
transparently. This will not cause faulty behaviour under the updated
merging rules. It will not be resource inefficient with the resource
sharing specification made in this document.

It is possible that the MP or the egress of a DETOUR LSP is also not DETOUR
capable. Even in this case, the updated merging rules and the new resource
sharing rules will ensure the correct behaviour.

c. Egress-MP  behaviour

For the BYPASS technique, the merge point is the NNHOP or the NHOP. For the
DETOUR the destination is the egress. Under the assumed merging rules,
merging will not occur unless the same ERO is specified. Resource sharing
can be tackled with the proposed resource sharing rules.