Subject: Re: [mpls] draft-saad-lsp-instant-install-rsvpte

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Wed, 4 Nov 2015 05:10:16 +0000

Hi Shahram,

Thanks for the feedback. See Inline.

From: mpls <[email-masked]<mailto:[email-masked]>> on behalf of Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 4, 2015 at 10:38 AM
To: Shahram Davari <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [mpls] draft-saad-lsp-instant-install-rsvpte

Sorry, Just changed the subject to correct Draft.

Hi,

Although the problem the draft is trying to solve is a legitimate problem, but the solution has a number of issues:

1)      It requires ingress LER to impose a stack of labels that is potentially large. Existing HW can't currently support this and therefore this draft requires replacing all LER HW

[TS]: this is valid, but LER(s) today are having to deal with this fact anyway (e.g. For SR-TE, SFC, etc..) -- imposing up to 10 labels, today, is something doable on LERs.

2)      The solution requires all intermediate LSRs to support this new RSVP-TE extension.

[TS]: yes, if there are node/link(s) that don't support DLL, then ingress can fallback to the classic reoptimization (make-before-break) method without further impact.

3)      The QoS is not guaranteed. Since there is no correlation between ultimate LSP and the  DLL Stack. Since potentially many LSPs may be required to go through the same path and they will all use the same DLL stack.

[TS]: the reservation in the control plane is done via RSVP-TE a-priori to starting forwarding any traffic with the DLL stack. Other LSPs that want to use a DLL stack will have to reserve the bandwidth in advance (using RSVP-TE as usual) before forwarding traffic.

4)      Switching multiple times to final LSP causes in flight packet drops and out of order delivery

[TS]: the DLL stack and new LSP are coinciding - so it's less likely such out-of-order delivery can occur.

5)      In a large MPLS network, There is no guarantee that the RESV message comes back with low delay.
[TS]: I agree, performance of RSVP-TE control plane under scale is important, and in fact there are WG has recommendations to improve it that can be implemented too (e.g. Driven by MPLS and TEAS WG). However, the intent of the draft was to minimize the time to ensure the performance of data plane(s) of traversed LSR(s)  -- which constitutes the wait time after singling completes- is illuminated from the LSP installation wait time.

Regards,
Tarek

Thx
Shahram