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

["Adrian Farrel" <[e-mail]>]

John,

Indeed.

draft-ietf-mpls-tp-survive-fwk only makes new definitions.
Others are inherited from RFC 4427 et al.

I believe, however, that we should cascade our references and not use a 
splatter gun. Thus, the linear protection I-D should reference the 
survivability framework only. The survivability framework can then reference 
other documents.

Cheers,
Adrian
----- Original Message ----- 
From: "John E Drake" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>; "Zhi-Wei 
Lin" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, March 29, 2010 5:22 PM
Subject: 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: [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
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>