The MPLS WG Archive

[Tricci So <tso@caspiannetworks.com>]

Hi Sven,

Thank you for bringing up the interesting FRR scenario in your previous email.

For your first part of the resource sharing enhancement, I can see that there
is some merit on your suggestion.  Especially, it allows the re-use of the
existing merging rules and the label reservation.  But I would like to point
out that, in my previous email to Juniper over this mailing list, they
suggested that they don't use the Ext_Tunnel_ID to support the merging
decision.  Instead, both the primary and the detour LSPs would have the same
Sender_Template object so that they can use it for merging.  By using the
Fast_Reroute and Detour objects, they can differentiate primary vs. backup
tunnel.  I believe, their model of LSP tunnel is not quite the same as your
layout in your previous email. Der-Hwa, please correct me if I have
mis-understood your response.

For you second enhancement recommendation, I am afraid that I have some major
reservation.  As of today, I am not convinced that  it is important to have the
two FRR proposals to interwork with each other since they are two different
design of trying to achieve similar purpose.

First of all, IMHO, I don't see that FRR will be used for inter-domain
situation.  Hence, if the FRR is implemented within a single domain, I can't
see why a SP will have the mixed and match vendors' solutions  in a single
network.  So, why do we want to make the FRR's design more complicated than it
is already?  I would  extrermely curious if you can point out a SP who like to
have a mixed vendors' solution, then, I agree with you that the FRR
interworking needs to be addressed.  In the mean time, let's keep it simple.

Cheers,
Tricci

sven.van_den_bosch@alcatel.be wrote:

> 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.