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

["Eric Osborne (eosborne)" <[e-mail]>]

You can't (easily) directly port FRR over to TP since FRR is unidirectional and TP has this bidirectional requirement, but you solve that with a protection state coordination protocol, a la draft-weingarten-mpls-tp-linear-protection.  Once you have that, you can get pretty close to what people think of as FRR in MPLS-TP.

Of course, since FRR stands for 'fast reRoute' and we're not supposed to talk about routing in TP networks, we end up calling it something else like 1:n Linear Protection. :)
 


eric


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Alexander Vainshtein
> Sent: Friday, August 13, 2010 2:11 AM
> To: [e-mail]
> Cc: [e-mail]; Shell Nakash; Alexander Kugel; MPLS TP; Mishael Wexler;
> Srinivas Goli
> Subject: Re: [mpls-tp] [mpls] 答复: Re: Updated drafts - draft-kini-mpls-ring-
> frr-facility-backup, draft-kini-mpls-fast-lsp-alert
> 
> 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: [e-mail] [[e-mail]] On Behalf Of
> [e-mail] [[e-mail]]
> Sent: Friday, August 13, 2010 8:33 AM
> To: Autumn Liu
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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.
> 
> is my understanding right?
> 
> Best regards,
> 
> -xuehui
> 
> 
> 
> 
> Autumn Liu <[e-mail]>
> 发件人:  [e-mail]
> 
> 2010-08-05 06:08
> 
> 收件人
> "[e-mail]" <[e-mail]>
> 抄送
> "[e-mail]" <[e-mail]>
> 主题
> Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup, draft-kini-
> mpls-fast-lsp-alert
> 
> 
> 
> 
> 
> 
> 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
> 
> 
> ________________________________
> 
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, August 03, 2010 12:38 AM
> To: Autumn Liu
> Cc: Greg Mirsky; Julien Meuric; [e-mail]; [e-mail]
> Subject: Re: [mpls] Updated drafts - draft-kini-mpls-ring-frr-facility-backup,
> draft-kini-mpls-fast-lsp-alert
> 
> 
> 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 <[e-mail]>
> 发件人:  [e-mail]
> 
> 2010-07-28 06:35
> 
> 
> 
> 收件人
> Greg Mirsky <[e-mail]>, Julien Meuric
> <[e-mail]>
> 抄送
> "[e-mail]" <[e-mail]>
> 主题
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Greg Mirsky
> Sent: Monday, July 26, 2010 1:37 PM
> To: Autumn Liu
> Cc: [e-mail]
> 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 <[e-mail]
> <mailto:[e-mail]> > 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:[e-mail]
> <mailto:[e-mail]> ]
> Sent: Monday, July 26, 2010 12:03 PM
> To: Autumn Liu
> Cc: Julien Meuric; Sriganesh Kini; [e-mail] <mailto:[e-mail]>
> 
> 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 <[e-mail]
> <mailto:[e-mail]> > 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: [e-mail] <mailto:[e-mail]>
> [mailto:[e-mail] <mailto:[e-mail]> ] On Behalf
> Of Julien Meuric
> Sent: Monday, July 26, 2010 10:40 AM
> To: Sriganesh Kini
> Cc: [e-mail] <mailto:[e-mail]>
> 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-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
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/mpls
> <https://www.ietf.org/mailman/listinfo/mpls>
> >
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls
> <https://www.ietf.org/mailman/listinfo/mpls>
> _______________________________________________
> mpls mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls
> <https://www.ietf.org/mailman/listinfo/mpls>
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> 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.
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>