Re: [mpls-tp] Question ondraft-ietf-mpls-tp-linear-protection-01

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
John E Drake writes:
>  
> Adrian,
>  
> Wouldn't RFC 4427
> (http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-recovery-terminology/)
> be even better?
>  
> Thanks,
>  
> John


It would be if it covered the case described below.  It doesn't and
therefore a definition is needed in another document.

The one paragraph on shared mesh restoration might be adequate for
circuit (OTN, SONET, TDM) but it is not adequate for packet.  It is
easier to fix it in another document.  The description of shared mesh
is not wrong, just insufficient.

Curtis


> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Adrian Farrel
> > Sent: Monday, March 29, 2010 1:09 AM
> > To: [e-mail]; Zhi-Wei Lin
> > Cc: [e-mail]
> > Subject: Re: [mpls-tp] Question ondraft-ietf-mpls-tp-linear-protection-01
> > 
> > Hi,
> > 
> > Would it be worth NOT including definitions of protection switching in
> > this
> > document?
> > 
> > We have draft-ietf-mpls-tp-survive-fwk. Can you all check that the
> > definitions in that document are things you can agree with?
> > 
> > Then the linear protection draft can simply reference the framework.
> > 
> > In my experience, doubling up definitions leads to discrepancies and
> > confusion further down the line.
> > 
> > Cheers,
> > Adrian
> > ----- Original Message -----
> > From: "Curtis Villamizar" <[e-mail]>
> > To: "Zhi-Wei Lin" <[e-mail]>
> > Cc: <[e-mail]>; <[e-mail]>
> > Sent: Sunday, March 28, 2010 1:00 AM
> > Subject: Re: [mpls-tp] [mpls] Question
> > ondraft-ietf-mpls-tp-linear-protection-01
> > 
> > 
> > >
> > > In message
> > > <[e-mail]>
> > > Zhi-Wei Lin writes:
> > >>
> > >> Hi Huub,
> > >>
> > >> Offline computation tools and explicit-path currently support this in
> > >> > plain old MPLS.
> > >> >
> > >>
> > >> >And what should be the CIR of the protection resource in this case,
> > >> >CIR of working path A *plus* CIR of working path B?
> > >>
> > >> I believe that is correct. The decision to do this would be made by
> > >> external
> > >> process. Ultimately this could result in oversubscription of the
> > >> protection
> > >> link, sum of CIRs on protection link > actual capacity of protection
> > >> link.
> > >>
> > >> And when this occurs, an event notification message could be sent to
> > >> external management system of this overcommitment.
> > >>
> > >> Here's a proposal for changes in the draft to support the above:
> > >>
> > >> Section 1 Introduction (2nd paragraph):
> > >>
> > >> Protection switching is a fully allocated survivability mechanism. It
> > is
> > >> fully allocated in the sense that the route and bandwidth of the
> > recovery
> > >> path is reserved for a selected working path or set of working paths.
> > >>
> > >> I would like to propose the following changes:
> > >>
> > >> Protection switching is a survivability mechanism with pre-configured
> > >> paths.
> > >> The route and bandwidth of the recovery path is reserved for a selected
> > >> working path (in the case of 1+1 and 1:1) or set of working paths (in
> > the
> > >> case of 1:n or m:n). Protection switching mechanism defined in this
> > >> document
> > >> does not preclude oversubscription of the recovery paths, i.e., the sum
> > >> of
> > >> bandwidth of the recovery path may be less than the sum of bandwidth of
> > >> the
> > >> working paths. This is a network planning and engineering issue outside
> > >> the
> > >> scope of this document.
> > >>
> > >>
> > >> Thanks
> > >> Zhi
> > >
> > >
> > > Two changes would make this more general.
> > >
> > >  Old first sentence:
> > >
> > >    Protection switching is a survivability mechanism with
> > >    pre-configured paths.
> > >
> > >  New first sentence:
> > >
> > >    Protection switching is a survivability mechanism which may use
> > >    pre-configured or dynamically allocated paths.
> > >
> > >  Old end of paragraph (1.5 sentence, begins with comma):
> > >
> > >    , i.e., the sum of bandwidth of the recovery path may be less than
> > >    the sum of bandwidth of the working paths. This is a network
> > >    planning and engineering issue outside the scope of this document.
> > >
> > >  End prior sentence and paragraph and add new paragraphs:
> > >
> > >    In transport layers for which sharing capacity with graceful
> > >    degredation of service is not possible (ie: SONET, OTN, optical
> > >    switching) rescovery capacity may in theory be shared up to the
> > >    point where the sum of recovery capacity for any one SRLG does not
> > >    exceed available recovery capacity.  Signaling for this case is
> > >    out of scope for this document.  Otherwise transport layers for
> > >    which sharing capacity with graceful degredation of service is not
> > >    possible are limited by existing signaling mechanisms such that
> > >    the sum of rescovery capacity may not exceed the sum of physical
> > >    capacity.
> > >
> > >    In transport layers for which sharing capacity with graceful
> > >    degredation of service is supported (ie: Ethernet, packet MPLS)
> > >    rescovery capacity may be oversubscribed.  This may be acceptable
> > >    in some circumstances.  For example, oversubscription may be
> > >    acceptable if QoS capabilities results in no congestion related
> > >    loss experienced by preferred services and/or if fast protection
> > >    is intended primarily as an interim measure prior to reroute of a
> > >    working path.
> > >
> > >    The routing of recovery paths and rescovery capacity sharing are
> > >    network planning and engineering issues outside the scope of this
> > >    document.
> > >
> > > This more accurately reflects rescovery capabilities but puts further
> > > details out of scope.
> > >
> > > Note that the sentence "Signaling for this case is out of scope for
> > > this document" could be corrected in GMPLS, but the change is
> > > significant enough to require a separate document.
> > >
> > > Curtis
> > >
> > >
> > >> On Thu, Mar 25, 2010 at 2:39 AM, Huub van Helvoort
> > >> <[e-mail]>wrote:
> > >>
> > >> > Hi Curtis,
> > >> >
> > >> >
> > >> > You wrote:
> > >> >
> > >> >  In message <[e-mail]>
> > >> >> Huub van Helvoort writes:
> > >> >>
> > >> >>>  Hi Zhi,
> > >> >>>  You wrote:
> > >> >>>
> > >> >>>
> > >> >>>> Why would this document restrict ability to overscubscribe?
> > >> >>>> Oversubscription should be a function of what type of service
> > level
> > >> >>>> is
> > >> >>>> defined for the underlying LSP. LSPs do not need to always be full
> > >> >>>> "CBR"
> > >> >>>> type service.
> > >> >>>>
> > >> >>>  I am not sure whether this belongs in this draft or in network
> > >> >>> planning for protection.
> > >> >>>  The network plaaning should find a protection LSP that supports
> > >> >>> the same bandwidth as the working LSP, the question is if in this
> > >> >>> case only the CIR should be used or the CIR + EIR of the working
> > >> >>> LSP.
> > >> >>>
> > >> >>
> > >> >> Since this is a packet network the same resource can protect against
> > >> >> two working paths if the two working demands have no common SRLG.
> > >> >>
> > >> >
> > >> > OK, this is indeed possible.
> > >> >
> > >> >
> > >> >  Offline computation tools and explicit-path currently support this
> > in
> > >> >> plain old MPLS.
> > >> >>
> > >> >
> > >> > And what should be the CIR of the protection resource in this case,
> > >> > CIR of working path A *plus* CIR of working path B?
> > >> >
> > >> >
> > >> >  There is no need to remove this capability in MPLS-TP.
> > >> >>
> > >> >
> > >> > It is still there, maybe I should have used path instead of LSP.
> > >> >
> > >> > Regards, Huub.
> > >
> > > _______________________________________________
> > > mpls-tp mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > >
> > 
> > _______________________________________________
> > mpls-tp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-tp