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

["Tarek Saad (tsaad)" <[e-mail]>]

Hi John,

Thanks, please see inline.

From: mpls <[e-mail]<mailto:[e-mail]>> on behalf of John E Drake <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 4, 2015 at 12:10 PM
To: Kireeti Kompella <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] comments on draft-saad-mpls-lsp-instant-install-rsvpte

Hi,

I have a couple of observations in addition to Kireeti's comment, below, with which I agree:

1)  If the labels that are being returned in signaling are LSP labels, then the scheme won't work because it falls prey to the same problem you are trying to solve
[TS]: indeed, they're not. The DLL(s) are pre-allocated and pre-programmed label(s) driven by TE link configuration - prior to LSP singling.

2)  if the labels are IGP link labels (i.e., the ingress uses the link labels to source route packets along the same path as the LSP's path), then you don't need to wait for signaling to start sending packets.  However, if the ingress waits for signaling then it knows that CAC has been performed along the LSP's path
[TS]: yes, the DLL(s) can be IGP link label(s) aka adjacency-segments (but can also be managed solely by TE as we're proposing)-- and yes, the ingress waits to confirm CAC is done (via singling) on LSRs before forwarding traffic.

3)  the ingress still needs LSP Self Ping to know when the LSP has been instantiated
[TS]: yes, this is still needed.

4)  I think the combination of 2) and 3) might be useful
[TS]: yes, the draft is pushing for a similar combo of 2) and 3) above.

Regards,
Tarek

Yours Irrespectively,

John

From: mpls [mailto:[e-mail]] On Behalf Of Kireeti Kompella
Sent: Tuesday, November 03, 2015 8:31 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [mpls] comments on draft-saad-mpls-lsp-instant-install-rsvpte

Hi Tarek, George:

I appreciate (but don't fully agree with) your motivation -- to minimize time on the temporary path.  This could be the backup path in the case of FRR, or the original path in case of reoptimization.

On the other hand, I think some might be worried about the number of forwarding changes: from original path to temporary to DLL stack to final path.  Each forwarding change can lead to some packets being dropped or reordered.  So, perhaps the objective function being optimized should be to minimize forwarding changes rather than minimize time on the temporary path.  At the very least, there should be a discussion of this in the draft (and on the list).

--
Kireeti