Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Hi Julien,

draft-kini-mpls-ring-frr-facility-backup describes a mechanism to let the primary LSP be aware of what the bypass LSP for corresponding protected facility. If my understanding is correct, the association mechanism defined in 4872 is used to associate the primary and backup LSPs. This is not good enough for the problem the draft is trying to address since each link/node along the primary LSP may have different bypass LSPs.

Regards,
Autumn

-----Original Message-----
From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Julien Meuric
Sent: Monday, July 26, 2010 10:40 AM
To: Sriganesh Kini
Cc: mpls@ietf.org
Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Hi Sriganesh.

The mechanism described in draft-kini-mpls-ring-frr-facility-backup
reminds me of end to end recovery (or more specifically end to end protection), as enabled by RFC 4872. That is all the more similar because the association mechanism is already defined in there, with a dedicated RSVP-TE object. RFC 4872 is Standard Track: is there any rational for not considering it?

Regards,

Julien

Le 26/07/2010 18:59, Sriganesh Kini a écrit :
> FYI - These updated version of these drafts were presented today at 
> IETF78.
> http://tools.ietf.org/html/draft-kini-mpls-ring-frr-facility-backup-01
> http://tools.ietf.org/html/draft-kini-mpls-fast-lsp-alert-01
> Thanks
>
> - Sri
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>    
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls