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

From: [email-masked]
Date: Tue, 3 Aug 2010 15:38:18 +0800

hi,Autumn
here I only ask a question for this E-FRR solution.
for example as the following:
   +-------L1--------L2---------L3--------L4-------+
    |                                                      |
 L10                                                  L5
  |                                                      |
 +-------L9--------L8---------L7--------L6-------+
we suppose there are two working LSP , One LSP: L10-L9-L8-L7-L6,
another LSP: L10-L1-L2-L3-L4.
now if the failure happened between L8 and L7. according to your solution.
L8 and L7 would send fast alert message to each node of bypass Tunnel
: L8-L9-L10-L1-L2-L3-L4-L5-L6-L7;
when node L10 received fast alert message from L8 or L7, for working LSP:
L10-L9-L8-L7-L6, will swich into e-backup tunnel: L10-L1-L2-L3-L4-L5-L6;
while for another LSP: L10-L1-L2-L3-L4 , how  do it know the failure don't 

affect the working LSP and can't need to switch into e-backup tunnel?
whether there is include LSP ID information which will be affected by 
the failure in the fast alert message packet? or the solution will adapt
new method to judge which LSP will be affected by the failure?

maybe my understanding be wrong?

best regards
liu

Autumn Liu <[email-masked]> 
发件人:  [email-masked]
2010-07-28 06:35

收件人
Greg Mirsky <[email-masked]>, Julien Meuric 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [mpls] Updated drafts       - 
draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

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]> 
wrote:
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]> 
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

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

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

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 3 Aug 2010 05:53:09 -0400

Liu,

The LSP L10-...-L6 would advertise in its RRO that e-backup L10-...-L3-...-L6 is protecting it. However, the LSP L10-...-L6 does not indicate that. So L10 knows apriori that an alert message on that specific e-backup tunnel should trigger a protection switch from L10-...-L6 to the e-backup (whereas it should not for the other LSP).

- Sri
________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Tuesday, August 03, 2010 12:38 AM
To: Autumn Liu
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

hi,Autumn

best regards
liu

2010-07-28 06:35

收件人
        Greg Mirsky <[email-masked]>, Julien Meuric <[email-masked]>
抄送
        "[email-masked]" <[email-masked]>
主题
        Re: [mpls] Updated drafts        -        draft-kini-mpls-ring-frr-facility-backup,        draft-kini-mpls-fast-lsp-alert

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,

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]<mailto:[email-masked]>]
Sent: Monday, July 26, 2010 12:03 PM
To: Autumn Liu
Cc: Julien Meuric; Sriganesh Kini; [email-masked]<mailto:[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,

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

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 :
> [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: [email-masked]
Date: Tue, 3 Aug 2010 19:32:01 +0800

sri
thank you for replying , but I don't completely understand your opinions.
whether each LSP has a specific alert message to notify source node of its
relative e-backup tunnel. for example, if the LSP L10......L6 have the 
failure,
node L10 will receive a alert message of LSP L10.....L6, 
in addtion, if the LSP L10......L4 have the failure,
node L10 will receive another alert message of LSP L10.....L4?

can my understanding be true?

best regards
liu

Sriganesh Kini <[email-masked]> 
发件人:  [email-masked]
2010-08-03 17:53

收件人
"[email-masked]" <[email-masked]>, Autumn Liu 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [mpls] Updated drafts       - 
draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Liu,

The LSP L10-...-L6 would advertise in its RRO that e-backup 
L10-...-L3-...-L6 is protecting it. However, the LSP L10-...-L6 does not 
indicate that. So L10 knows apriori that an alert message on that specific 
e-backup tunnel should trigger a protection switch from L10-...-L6 to the 
e-backup (whereas it should not for the other LSP).

- Sri
________________________________
From: [email-masked] [[email-masked]] On Behalf Of 
[email-masked] [[email-masked]]
Sent: Tuesday, August 03, 2010 12:38 AM
To: Autumn Liu
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Updated drafts - 
draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

hi,Autumn

best regards
liu

2010-07-28 06:35

收件人

Hi Greg and Julien

Regards,
Autumn

Dear Autumn,

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

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 3 Aug 2010 12:06:26 -0700

Liu,

Alert message is used to notify at the time of failure. The association of
protected LSP to backup and e-backup tunnel is done prior to failure. A
single alert message (right after failure) per backup tunnel is sufficient
(though a couple duplicates may be sent to protect against packet loss). It
is important to note that the alert message is not per protected LSP.

2010/8/3 <[email-masked]>

>  *Sriganesh Kini <[email-masked]>*
> "[email-masked]" <[email-masked]>, Autumn Liu <
> [email-masked]>
> 抄送
> "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> 主题
> segment protection is utilized as defined in 4873. We will update the draft
> accordingly.
>
> Regards,
> 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
>
> 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
>
>
> From: [email-masked]<mailto:[email-masked]> [mailto:
> [email-masked]<mailto:[email-masked]>] On Behalf Of Julien
> Meuric
> are not permitted to disclose the contents of this communication to others.
> If you have received this email in error please notify the originator of the
> message. Any views expressed in this message are those of the individual
> sender.

-- 
- Sri

---

From: [email-masked]
Date: Wed, 4 Aug 2010 09:14:13 +0800

Sri
maybe i not clarify my problem?  my key problem is how do u-PLR know which 
LSP will be affected by the failure after receiving an alert message?
can U-PLR  apperceive which LSP have the failure? or can PLR tell u-PLR 
about which LSP will have the failure by an alert message?

I hope you can provide a clear answer.

best regards
liu

2010-08-04 03:06

收件人
[email-masked]
抄送
"[email-masked]" <[email-masked]>, Autumn Liu <[email-masked]>, 
"[email-masked]" <[email-masked]>
主题
Re: [mpls] Updated drafts -     draft-kini-mpls-ring-frr-facility-backup, 
draft-kini-mpls-fast-lsp-alert

Liu,

Alert message is used to notify at the time of failure. The association of 
protected LSP to backup and e-backup tunnel is done prior to failure. A 
single alert message (right after failure) per backup tunnel is sufficient 
(though a couple duplicates may be sent to protect against packet loss). 
It is important to note that the alert message is not per protected LSP.

sri 

best regards 
liu

收件人

Liu,

- Sri

hi,Autumn

best regards
liu

2010-07-28 06:35

收件人
       Greg Mirsky <[email-masked]>, Julien Meuric <
[email-masked]>
抄送
       "[email-masked]" <[email-masked]>
主题
       Re: [mpls] Updated drafts        - 
draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Hi Greg and Julien

Regards,
Autumn

Dear Autumn,

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

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

Regards,
Autumn

-----Original Message-----

Hi Sriganesh.

Regards,

Julien

-- 
- Sri_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Autumn Liu <[email-masked]>
Date: Tue, 3 Aug 2010 22:35:24 -0400

Liu,

The proposed RRO subject tells u-PLR of primary LSP which backup is protecting it. When the alert message is received on that backup, the u-PLR finds out the primary LSP (protected by the backup) to switch the traffic onto the e-backup.

Hope this gives you the clear answer to your question.

Autumn

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 03, 2010 6:14 PM
To: Sriganesh Kini
Cc: Autumn Liu; [email-masked]; [email-masked]
Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Sri
maybe i not clarify my problem?  my key problem is how do u-PLR know which LSP will be affected by the failure after receiving an alert message?
can U-PLR  apperceive which LSP have the failure? or can PLR tell u-PLR about which LSP will have the failure by an alert message?

best regards
liu

2010-08-04 03:06

收件人
[email-masked]
抄送
"[email-masked]" <[email-masked]>, Autumn Liu <[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: [mpls] Updated drafts -        draft-kini-mpls-ring-frr-facility-backup,        draft-kini-mpls-fast-lsp-alert

Liu,

Alert message is used to notify at the time of failure. The association of protected LSP to backup and e-backup tunnel is done prior to failure. A single alert message (right after failure) per backup tunnel is sufficient (though a couple duplicates may be sent to protect against packet loss). It is important to note that the alert message is not per protected LSP.

2010/8/3 <[email-masked]<mailto:[email-masked]>>

sri
relative e-backup tunnel. for example, if the LSP L10......L6 have the failure,

best regards
liu

Sriganesh Kini <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2010-08-03 17:53

收件人
"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Autumn Liu <[email-masked]<mailto:[email-masked]>>
抄送
"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
主题
Re: [mpls] Updated drafts        -        draft-kini-mpls-ring-frr-facility-backup,        draft-kini-mpls-fast-lsp-alert

Liu,

- Sri
________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 03, 2010 12:38 AM
To: Autumn Liu
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

hi,Autumn

best regards
liu

Autumn Liu <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2010-07-28 06:35

收件人
      Greg Mirsky <[email-masked]<mailto:[email-masked]>>, Julien Meuric <[email-masked]<mailto:[email-masked]>>
抄送
      "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
主题
      Re: [mpls] Updated drafts        -        draft-kini-mpls-ring-frr-facility-backup,        draft-kini-mpls-fast-lsp-alert

Hi Greg and Julien

Regards,
Autumn

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Greg Mirsky

Dear Autumn,

Regards,
Greg

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

Regards,
Autumn

________________________________
From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]><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]><mailto:[email-masked]<mailto:[email-masked]>>

Dear Autumn,

Regards,
Greg

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

Regards,
Autumn

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

---

From: [email-masked]
Date: Wed, 4 Aug 2010 11:39:14 +0800

Autumn
thank you for explaining. according to my understanding, when one link 
have failure, PLR node will append to the PRO of per LSP which have been 
affected by the failure in the 
BFD Session of backup tunnel, so that PLR-u will know which LSP need to 
switch its own e-backup tunnel? if so , as PLR may be MIP of some LSP , 
how do it know PRO of per LSP?
can you need to query the PRO of per LSP by control plane?
in addtion, for P2MP , when U-PLR received alert message from PLR , U-PLR 
should make service packet bridge both primary LSP and e-backup tunnel at 
the same time. it is very rapid and
valid solution. do you think so? 
if you can be interested in the p2mp protection solution, we may disscuss 
it in detail in the following time.

best regards
liu

2010-08-04 10:35

收件人
"[email-masked]" <[email-masked]>, Sriganesh Kini 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, 
draft-kini-mpls-fast-lsp-alert

Liu,
 
The proposed RRO subject tells u-PLR of primary LSP which backup is 
protecting it. When the alert message is received on that backup, the 
u-PLR finds out the primary LSP (protected by the backup) to switch the 
traffic onto the e-backup.

Autumn

Sri 

best regards 
liu

收件人
[email-masked] 
抄送

Liu, 

sri 

best regards 
liu 

收件人

Liu,

- Sri

hi,Autumn

best regards
liu

2010-07-28 06:35

收件人

Hi Greg and Julien

Regards,
Autumn

Dear Autumn,

Regards,
Greg

Regards,
Autumn

Dear Autumn,

Regards,
Greg

Regards,
Autumn

-----Original Message-----

Hi Sriganesh.

Regards,

Julien

---

From: Autumn Liu <[email-masked]>
Date: Wed, 4 Aug 2010 18:08:55 -0400

Hi Liu,

In your example, the bypass tunnel only protects the first primary LSP (L10-L9-L8-L7-L6). The proposed RRO object will be included for this primary LSP only. As a result, the alert message will only trigger this primary to switch over to the e-backup.

Regards,
Autumn

Cc: Greg Mirsky; Julien Meuric; [email-masked]; [email-masked]

hi,Autumn

best regards
liu

2010-07-28 06:35

收件人

Hi Greg and Julien

Regards,
Autumn

Dear Autumn,

Regards,
Greg

Regards,
Autumn

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

---

From: Autumn Liu <[email-masked]>
Date: Wed, 4 Aug 2010 22:09:55 -0400

Hi Liu,

The RRO information is exchanged before the failure, and it is per LSP along with each refresh message.
P2MP LSP protection is interesting topic and we can discuss further.

Regards,
Autumn

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 03, 2010 8:39 PM
To: Autumn Liu
Cc: [email-masked]; [email-masked]; Sriganesh Kini
Subject: RE: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Autumn
thank you for explaining. according to my understanding, when one link have failure, PLR node will append to the PRO of per LSP which have been affected by the failure in the
BFD Session of backup tunnel, so that PLR-u will know which LSP need to switch its own e-backup tunnel? if so , as PLR may be MIP of some LSP , how do it know PRO of per LSP?
can you need to query the PRO of per LSP by control plane?
in addtion, for P2MP , when U-PLR received alert message from PLR , U-PLR should make service packet bridge both primary LSP and e-backup tunnel at the same time. it is very rapid and
valid solution. do you think so?
if you can be interested in the p2mp protection solution, we may disscuss it in detail in the following time.

best regards
liu

2010-08-04 10:35

收件人
"[email-masked]" <[email-masked]>, Sriganesh Kini <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
主题
RE: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Liu,

Autumn

---

From: [email-masked]
Date: Thu, 5 Aug 2010 10:29:09 +0800

hi Autumn,
BTW, Is the PRO information exchanged by control signaling?
if so, this protection solution must not be independent of 
control plane. whether it can violate RFC5464 23.B:
 taking recovery actions independent of the control or
 management plane used to configure the MPLS-TP layer network?

Regards
liu

2010-08-05 10:09

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, 
draft-kini-mpls-fast-lsp-alert

Hi Liu,
 
The RRO information is exchanged before the failure, and it is per LSP 
along with each refresh message.
P2MP LSP protection is interesting topic and we can discuss further.
 
Regards,
Autumn

Subject: RE: [mpls] Updated drafts - 

Autumn 

best regards 
liu

收件人

Liu, 

  
Autumn

---

From: [email-masked]
Date: Fri, 13 Aug 2010 13:33:42 +0800

Hi all，

From my understanding, FRR mechanism is based on RSVP-TE protocol, since , 
if the proposed method be used in MPLS-TP ,this can only be used when 
there is a control plane.

 and in the example below, e-backup tunnel  L10-L1-L2-L3-L4-L5-L6 can only 
protect LSP1: L10-L9-L8-L7-L6; and for LSP2:: L10-L1-L2-L3-L4, there 
should be another e-backup tunnel . and 

through the association between the primary LSP and bypass tunnel ( by RRO 
object ), once an alert message received from this bypass tunnel , the 
node can judge which primary LSP needs to be protected.

is my understanding right?

Best regards,

-xuehui

2010-08-05 06:08

收件人

Hi Liu,
 
In your example, the bypass tunnel only protects the first primary LSP 
(L10-L9-L8-L7-L6). The proposed RRO object will be included for this 
primary LSP only. As a result, the alert message will only trigger this 
primary to switch over to the e-backup.
 
Regards,
Autumn

hi,Autumn 

best regards 
liu

收件人

Hi Greg and Julien 

Regards, 
Autumn 

Dear Autumn,

Regards,
Greg

                            

Regards, 
Autumn 

Dear Autumn,

Regards,
Greg

Regards,
Autumn 

-----Original Message-----

Hi Sriganesh.

Regards,

Julien

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 13 Aug 2010 09:11:29 +0300

Xuehui, and all,

As a matter of fact, FRR is a pure data plane mechanism that can be decoupled from the control plane.
(Of course it means that your bypass tunnels have to be constructed by the management plane, but this is nothing to prevent this). As a consequence, FRR is fully acceptable in MPLS-TP.

My 2 c,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Friday, August 13, 2010 8:33 AM
To: Autumn Liu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [mpls] 答复: Re: Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-mpls-fast-lsp-alert

Hi all，

From my understanding, FRR mechanism is based on RSVP-TE protocol, since , if the proposed method be used in MPLS-TP ,this can only be used when there is a control plane.

 and in the example below, e-backup tunnel  L10-L1-L2-L3-L4-L5-L6 can only protect LSP1: L10-L9-L8-L7-L6; and for LSP2:: L10-L1-L2-L3-L4, there should be another e-backup tunnel . and

through the association between the primary LSP and bypass tunnel ( by RRO object ), once an alert message received from this bypass tunnel , the node can judge which primary LSP needs to be protected.

Best regards,

-xuehui

2010-08-05 06:08

收件人

Hi Liu,

Regards,
Autumn

hi,Autumn

best regards
liu

2010-07-28 06:35

收件人

Hi Greg and Julien

Regards,
Autumn

Dear Autumn,

Regards,
Greg

Regards,
Autumn

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

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 13 Aug 2010 05:44:42 -0700

Xuehui,

e-backup can be setup without a signaling protocol.

Other observations are ok.

On Thu, Aug 12, 2010 at 10:33 PM, <[email-masked]> wrote:

> if the proposed method be used in MPLS-TP ,this can only be used when there
> is a control plane.
>
> object ), once an alert message received from this bypass tunnel , the node
> can judge which primary LSP needs to be protected.
>
>  *Autumn Liu <[email-masked]>*
> (L10-L9-L8-L7-L6). The proposed RRO object will be included for this primary
> LSP only. As a result, the alert message will only trigger this primary to
> switch over to the e-backup.
>
> Regards,
> Autumn
>
> ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* Tuesday, August 03, 2010 12:38 AM*
> To:* Autumn Liu*
> Cc:* Greg Mirsky; Julien Meuric; [email-masked]; [email-masked]*
> Subject:* Re: [mpls] Updated drafts -
>   *Autumn Liu <[email-masked]>*
>  ------------------------------
> *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 -
> 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]*<[email-masked]>>
> wrote:
> Hi Greg,
>
>  ------------------------------
> *From:* Greg Mirsky [mailto:[email-masked]*<[email-masked]>]
> *
> Sent:* Monday, July 26, 2010 12:03 PM*
> To:* Autumn Liu*
> Cc:* Julien Meuric; Sriganesh Kini; [email-masked]* <[email-masked]> *
>
> Subject:* Re: [mpls] Updated drafts -
> On Mon, Jul 26, 2010 at 11:30 AM, Autumn Liu <[email-masked]*<[email-masked]>>
> wrote:
> Hi Julien,
>
> From: [email-masked]* <[email-masked]> [mailto:*
> [email-masked]* <[email-masked]>] On Behalf Of Julien Meuric
> Cc: [email-masked]* <[email-masked]>
> > *http://tools.ietf.org/html/draft-kini-mpls-ring-frr-facility-backup-01*<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*<http://tools.ietf.org/html/draft-kini-mpls-fast-lsp-alert-01>
> > Thanks
> >
> > - Sri
> >
> >
> > [email-masked]* <[email-masked]>
> > *https://www.ietf.org/mailman/listinfo/mpls*<https://www.ietf.org/mailman/listinfo/mpls>
> >
> mpls mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/mpls*<https://www.ietf.org/mailman/listinfo/mpls>
> mpls mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/mpls*<https://www.ietf.org/mailman/listinfo/mpls>
>

-- 
- Sri