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

[Sriganesh Kini <[e-mail]>]

Xuehui,

e-backup can be setup without a signaling protocol.

Other observations are ok.

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

>
> 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]*<[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]*<[e-mail]>]
> *
> Sent:* Monday, July 26, 2010 12:03 PM*
> To:* Autumn Liu*
> Cc:* Julien Meuric; Sriganesh Kini; *[e-mail]* <[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]*<[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]* <[e-mail]> [mailto:*
> [e-mail]* <[e-mail]>] On Behalf Of Julien Meuric
> Sent: Monday, July 26, 2010 10:40 AM
> To: Sriganesh Kini
> Cc: *[e-mail]* <[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]* <[e-mail]>
> > *https://www.ietf.org/mailman/listinfo/mpls*<https://www.ietf.org/mailman/listinfo/mpls>
> >
> _______________________________________________
> mpls mailing list*
> **[e-mail]* <[e-mail]>*
> **https://www.ietf.org/mailman/listinfo/mpls*<https://www.ietf.org/mailman/listinfo/mpls>
> _______________________________________________
> mpls mailing list*
> **[e-mail]* <[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
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>


-- 
- Sri