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

From: Sriganesh Kini <[email-masked]>
Date: Mon, 26 Jul 2010 12:59:49 -0400

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

---

From: Julien Meuric <[email-masked]>
Date: Mon, 26 Jul 2010 19:40:04 +0200

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 :
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Autumn Liu <[email-masked]>
Date: Mon, 26 Jul 2010 14:30:17 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Monday, July 26, 2010 10:40 AM
To: Sriganesh Kini
Cc: [email-masked]
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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 26 Jul 2010 12:03:07 -0700

Dear Autumn,
I'm quite surprised to read your reply to Julien. My understanding of your
proposal is that all PLRs share the same u-PLR for given ring segment of
LSP. Please correct me if my understanding is different from authors
intention.
I'd like to add to Julien's comment that RFC 4873 seems relevant to your
solution as well as RFC 4872. And I'd ask the same question as Julien in
regard to not referencing RFC 4873.

Regards,
Greg

On Mon, Jul 26, 2010 at 11:30 AM, Autumn Liu <[email-masked]>wrote:

> 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
>
>
> Subject: Re: [mpls] Updated drafts -
> draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert
>
> Hi Sriganesh.
>
> 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
>
>

---

From: Autumn Liu <[email-masked]>
Date: Mon, 26 Jul 2010 15:16:47 -0400

Hi Greg,

 +-------L1--------L2---------L3--------L4-------+
  |                                                      |
 L10                                                  L5
  |                                                      |
 +-------L9--------L8---------L7--------L6-------+

Not all PLRs. Using the diagram in draft as an example.
Bypass 1 (to protect link between L8 and L7) : L8-L9-L10-L1-L2-L3-L4-L5-L6-L7
Bypass 2 (to protect node failure on L8) : L9-L10-L1-L2-L3-L4-L5-L6-L7

e-backup tunnel L10-L1-L2-L3-L4-L5 can be used instead for both cases without getting traffic u-turned.

Regards,
Autumn

________________________________
From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, July 26, 2010 12:03 PM
To: Autumn Liu
Cc: Julien Meuric; Sriganesh Kini; [email-masked]
Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Dear Autumn,
I'm quite surprised to read your reply to Julien. My understanding of your proposal is that all PLRs share the same u-PLR for given ring segment of LSP. Please correct me if my understanding is different from authors intention.
I'd like to add to Julien's comment that RFC 4873 seems relevant to your solution as well as RFC 4872. And I'd ask the same question as Julien in regard to not referencing RFC 4873.

Regards,
Greg

On Mon, Jul 26, 2010 at 11:30 AM, Autumn Liu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Julien,

Regards,
Autumn

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

Hi Sriganesh.

Regards,

Julien

Le 26/07/2010 18:59, Sriganesh Kini a écrit :
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 26 Jul 2010 13:37:16 -0700

Dear Autumn,
thank you for adding specific case to our discussion. In my view protecting
segment L10-L1-L2-L3-L4-L5 (e-backup tunnel) is shared by all backup tunnels
that traverse the ring through nodes L10-L9-L8-L7-L6-L5. This e-backup
tunnel is the e-backup tunnels for all working sections/segments (in case of
link and node protection) of an LSP L10-...-L8-..-L5. I'd re-state my
question to authors whether they've considered re-using RSVP-TE objects and
subobjects defined in RFC 4873.  If mechanisms and objects defined in RFC
4873 not sufficient, why RFC 4873 not referenced in the draft Efficient
Facility Backup FRR.

Regards,
Greg

On Mon, Jul 26, 2010 at 12:16 PM, Autumn Liu <[email-masked]>wrote:

>  ------------------------------
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Monday, July 26, 2010 12:03 PM
> *To:* Autumn Liu
> *Cc:* Julien Meuric; Sriganesh Kini; [email-masked]
>
> *Subject:* Re: [mpls] Updated drafts -

---

From: Autumn Liu <[email-masked]>
Date: Tue, 27 Jul 2010 18:35:10 -0400

Hi Greg and Julien

Thanks for pointing this out. The draft can be applied to the case when segment protection is utilized as defined in 4873. We will update the draft accordingly.

Regards,
Autumn

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Monday, July 26, 2010 1:37 PM
To: Autumn Liu
Cc: [email-masked]
Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Dear Autumn,
thank you for adding specific case to our discussion. In my view protecting segment L10-L1-L2-L3-L4-L5 (e-backup tunnel) is shared by all backup tunnels that traverse the ring through nodes L10-L9-L8-L7-L6-L5. This e-backup tunnel is the e-backup tunnels for all working sections/segments (in case of link and node protection) of an LSP L10-...-L8-..-L5. I'd re-state my question to authors whether they've considered re-using RSVP-TE objects and subobjects defined in RFC 4873.  If mechanisms and objects defined in RFC 4873 not sufficient, why RFC 4873 not referenced in the draft Efficient Facility Backup FRR.

Regards,
Greg

On Mon, Jul 26, 2010 at 12:16 PM, Autumn Liu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Regards,
Autumn

________________________________
From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, July 26, 2010 12:03 PM
To: Autumn Liu
Cc: Julien Meuric; Sriganesh Kini; [email-masked]<mailto:[email-masked]>

Dear Autumn,

Regards,
Greg

Regards,
Autumn

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

Hi Sriganesh.

Regards,

Julien