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

Adrian,

Wouldn't RFC 4427 (http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-recovery-terminology/) be even better?

Thanks,

John

> -----Original Message-----
> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf
> Of Adrian Farrel
> Sent: Monday, March 29, 2010 1:09 AM
> To: curtis@occnc.com; Zhi-Wei Lin
> Cc: mpls-tp@ietf.org
> 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" <curtis@occnc.com>
> To: "Zhi-Wei Lin" <zhiwlin@gmail.com>
> Cc: <mpls@ietf.org>; <mpls-tp@ietf.org>
> Sent: Sunday, March 28, 2010 1:00 AM
> Subject: Re: [mpls-tp] [mpls] Question
> ondraft-ietf-mpls-tp-linear-protection-01
> 
> 
> >
> > In message
> > <s2p67ec4be61003250652q370b3a7dvf6d33c5e5847b317@mail.gmail.com>
> > 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
> >> <hhelvoort@chello.nl>wrote:
> >>
> >> > Hi Curtis,
> >> >
> >> >
> >> > You wrote:
> >> >
> >> >  In message <4BA91EC9.7080803@chello.nl>
> >> >> 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
> > mpls-tp@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> 
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp