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

[Alexander Vainshtein <[e-mail]>]

Eric,
MPLS-TP does not exclude unidirectional LSPs, so at least in this case (and probably also for associated bidirectional LSPs) the FRR could work just fine without any coordination of protection state.

On the other hand, if you want your FRR to preserve co-routed bi-directional behavior of the original LSP, you would have to create co-routed bi-directional bypass LSPs and to run some simple APS protocol (probably in this LSP).

In any case, this is strictly orthogonal to any control plane.

My 2c,
     Sasha

________________________________________
From: Eric Osborne (eosborne) [[e-mail]]
Sent: Friday, August 13, 2010 1:20 PM
To: Alexander Vainshtein; [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

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
>