Re: RPR protection with MPLS

nitin panjwani <[email protected]> Tue, 19 Nov 2002 00:01:14 -0800 (PST)
Newsgroups gmane.ietf.iporpr
Message-ID <[email protected]>
John & Albert,

I can also see how the situation will work. I am also
conviced by John and  it will be good idea to keep
MPLS as a backup for RPR as Alberts suggested.

Thanks,
Nitin 

--- "A.Herrera" <[email protected]> wrote:
> John,
> 
> I agree, protection kicks in quickly and there's no
> need nor time for MPLS to intervene. I was referring
> more to other scenarios where multiple faults occur
> with multiple Signal Fails or combinations of Signal
> Degrades and instances where a few nodes are
> isolated
> creating 'island' sub-rings.
> 
> In these cases, the WG might like to look at
> scenarios
> where MPLS might compliment RPR protection.
> 
> Albert
> 
> 
> ----- Original Message -----
> From: <[email protected]>
> To: <[email protected]>; <[email protected]>;
> <[email protected]>
> Sent: Monday, November 18, 2002 1:51 PM
> Subject: RE: [IPORPR] RPR protection with MPLS
> 
> 
> Albert,
> 
> I'm not sure what you mean by "RPR protection
> settles". There is no "settling"
> for protection. It just switches to the alternate
> path, as quickly as the link
> problem is detected. Since the RPR MAC owns the
> interface to the physical layer,
> the RPR MAC will learn first and react first.
> 
> jl
> 
> -----Original Message-----
> From: A.Herrera [mailto:[email protected]]
> Sent: Tuesday, November 12, 2002 4:17 PM
> To: nitin panjwani; David Zelig; 'Frank Kastenholz';
> [email protected]
> Subject: Re: [IPORPR] RPR protection with MPLS
> 
> 
> ----- Original Message -----
> From: "nitin panjwani" <[email protected]>
> To: "David Zelig" <[email protected]>; "'Frank
> Kastenholz'"
> <[email protected]>; <[email protected]>
> Sent: Tuesday, November 12, 2002 3:09 PM
> Subject: RE: [IPORPR] RPR protection with MPLS
> 
> 
> >
> > Hi David and all,
> > Shouldn't it be something like: either RPR or MPLS
> > protection will take charge of rerouteing the
> traffic;
> > and one which assures minimum packate loss and
> delay
> > will win and take charge.
> > On this, usually upper layer(MPLS) depends on the
> > lower layer(RPR)(as it simplifies the
> implementation
> > and serves the perfect goal of layering
> approach)and
> > shouldn't it be upto MPLS to decide wheathet to
> take
> > charge of protection or wait for RPR, depending on
> how
> > critical network and the passing traffic is(this
> > should be configurable).
> > Please correct me.
> >
> > Tahnks,
> > Nitin
> >
> Both MPLS FRR and RPR steer/wrap are localized
> reactions to divert within ms. to a pre-determined
> detour path or alternate ring direction. So I'll
> assume that operator preferences to fault scenarios
> are pre-determined and pre-configured as per network
> planning based on critical flows.
> 
> In this case, I would think, that sufficient
> feedback from
> RPR as to the nature of the faults (i.e. multiple or
> combinations of Signal Fail/Degrade, etc.) will
> allow MPLS
> to choose to divert even before RPR protection
> settles.
> For single occurrances of SF, etc, RPR is more than
> sufficient protection for critical flows.
> 
> These mechanisms and scenarios should be discussed
> and further clarified within the WG.
> 
> Albert
> 
> 
> _______________________________________________
> IPORPR mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/iporpr
> 
> _______________________________________________
> IPORPR mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/iporpr


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com