Subject: [mpls-tp] Question on draft-ietf-mpls-tp-linear-protection-01

From: Zhi-Wei Lin <[email-masked]>
Date: Tue, 23 Mar 2010 03:21:17 -0400

Hi,

I have a question on draft-ietf-mpls-tp-linear-protection-01. Does the
linear protection switching mechanism support the ability to oversubscribe a
protection paths to protect multiple working paths?

For example, if I have 4 physical 10Gbps links that are designated as
working links and I have configured LSPs across these (let's say each
physical link has 4 1Gbps LSPs created), and I have designated another
physical 10Gbps link as protection for all these working LSPs. They all
share a common ingress and egress node within the linear protection domain.
Obviously if all the LSPs fail, this would require 16 Gbps, but since these
are 4 separate physical links they should have low chance of failure
simultaneously and therefore this type of oversubscription should be safe...

Is the above scenario supported by the draft? If not, could something like
this be added?

Thanks
Zhi

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 23 Mar 2010 08:46:45 +0100

Nihao Zhi,

You wrote:

> linear protection switching mechanism support the ability to 
> oversubscribe a protection paths to protect multiple working paths?

No it does not.

Taking your example:

> share a common ingress and egress node within the linear protection 
> domain. Obviously if all the LSPs fail, this would require 16 Gbps, but 
> since these are 4 separate physical links they should have low chance of 
> failure simultaneously and therefore this type of oversubscription 
> should be safe...

And considering the LSPs in the physical links, the n LSPs
(4 x 4 in this case) are protected by m LSPs requiring m:n
protection which is not described in this draft.

If one looks at the physical links with the LSPs inside
also ACL/SNC protection can be applied. Adaptive Compound
Link/Sub-Network Protection is described in ITU-T G.808.1
but is not described in the current draft.

> Is the above scenario supported by the draft? If not, could something 
> like this be added?

It may be, but first let us get this draft into a shape
that can be implemented which requires still a lot of work.

Regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Zhi-Wei Lin <[email-masked]>
Date: Tue, 23 Mar 2010 14:35:18 -0400

Hi Huub,

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.

Also, in 4.2.3 (path fault identifier), if the command was force switch,
lock protection, manual switch, wait to restore, etc. (basically not signal
fail or signal degrade), what should these values be? This field seems to be
very tightly integrated with SF and SD (as a modifier to these to only)?

Thanks
Zhi

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 23 Mar 2010 21:04:25 +0100

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.

> lock protection, manual switch, wait to restore, etc. (basically not 
> signal fail or signal degrade), what should these values be? This field 
> seems to be very tightly integrated with SF and SD (as a modifier to 
> these to only)?

The request type should be enough to determine the cause of
the switch, the FPath information is additional, but may be
superfluous.

Best reagrds, Huub.

---

From: Zhi-Wei Lin <[email-masked]>
Date: Tue, 23 Mar 2010 16:22:48 -0400

Hi Huub,

I agree it is part of network planning, but the protection switching should
support various services. The only reason I raise this is because in Section
1 Introduction, you have a phrase that says

"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 think fully allocated should be modified as subject to the service
specification of the LSP. For example, speaking for my company, we have lots
of video traffic that are bursty in nature (some minimum committed rate plus
some burst rate). I definitely don't want to fully allocate the peak rate
for each path on the protection since the burstiness of traffic would allow
me to use a smaller protection capacity to support multiple working paths.

Because of that statement and no other statement saying oversubscription is
allowed, it would seem that I would not be allowed to do this. I think a
statement saying that the protocol does not prevent oversubscription would
be useful to clarify. Use of oversubscription is up to the operator of the
network. The nodes in the protection domain may raise an event notification
to an external management system regarding oversubscribed link (just to
confirm it was intentional and not poor planning).

Thanks
Zhi

---

From: [email-masked]
Date: Wed, 24 Mar 2010 07:07:46 +0800

huub
I agree your opinion. this draft is only a prime shape of linear 
protection.
it may be necessary to add other protection function, eg. 1:n or M：N 
protection for
p2p and p2mp 

is my understanding right?

best regards
liu

Huub van Helvoort <[email-masked]> 
发件人:  [email-masked]
2010-03-23 15:46
请答复 给
[email-masked]

收件人
Zhi-Wei Lin <[email-masked]>
抄送
[email-masked], [email-masked]
主题
Re: [mpls] [mpls-tp] Question on draft-ietf-mpls-tp-linear-protection-01

Nihao Zhi,

No it does not.

Regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls mailing list
[email-masked]
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.

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 24 Mar 2010 00:31:34 +0100

Hello Liu,

> is my understanding right?

Yes.
However the current objective is  to describe 1+1 and 1:1,
and later add 1:n and m:n, but maybe consider (1:1)^n as
this is better suited for packet technologies.

BUT, in the current description we may already leave some
hooks for these later extensions.

Kind regards, Huub.

> *Huub van Helvoort <[email-masked]>*

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 25 Mar 2010 02:23:07 -0400

In message <[email-masked]>
> case only the CIR should be used or the CIR + EIR of the working

Since this is a packet network the same resource can protect against
two working paths if the two working demands have no common SRLG.
Offline computation tools and explicit-path currently support this in
plain old MPLS.  There is no need to remove this capability in
MPLS-TP.

> the switch, the FPath information is additional, but may be

Curtis

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 25 Mar 2010 07:39:40 +0100

Hi Curtis,

> two working paths if the two working demands have no common SRLG.

OK, this is indeed possible.

> 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.

---

From: Zhi-Wei Lin <[email-masked]>
Date: Thu, 25 Mar 2010 09:52:17 -0400

Hi Huub,

>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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 25 Mar 2010 12:05:02 -0400

In message <[email-masked]>
> CIR of working path A *plus* CIR of working path B?

In this case because the control plane does not allow sufficient
semantics for sharing, the protect is set of with zero bandwidth and
the TC (formerly EXP) bits are used to influence queuing prioroty.
All LSP are configured with a reserbable bandwidth on the working LSP
and zero on the protect.  A further fallback to a dynamic routed LSP
is available.

If a single fault occurs (one SRLG affected) then there is no
congestion if the provisioning exercise accuarately reflects the
traffic load.

If a multiple fault occurs, some protect paths go down with the
working path but many don't.  As much as providers would love to sell
a lot of high margin services, their high priority services remain a
small percentage of total traffic, AFAIK always under 10% and
generally a few percent.  No loss occurs for the high priority traffic
though loss may occur for best effort traffic which is predominantly
Internet.  The fallback to dynamic routing is generally subsecond,
though not as fast as protection, for those tunnels where the protect
path was affected by the multiple fault.

In either case, single fault or multiple fault, a new working path is
brought up.  This is on a slower timer to allow all tunnels affected
by a multiple fault to come up as quickly as possible without having
to compete in a signaling storm.  New protect LSP would then be
brought up for the new working LSP would.  With MTTR on fiber still
being rather long and even a card swap taking 15 minutes or more, this
prevents a subsequent fault from violating SLAs.

A further fallback is available should resources fall below the level
needed to support all LSP.  In a packet network having a tunnel not
come up at all is completely unacceptable.  This is unlike TDM where
it is not possible to deliver 80-90% of desired capacity in such a
situation.  In this case secondary LSP can be brought up with reduced
reservable bandwidth.

The high end routers support this and generally retain the terminology
of the TE-WG in their CLI, standby and secondary LSP.

This is a very pragmentic approach.  I'm not sure if any provider uses
all of the features available.  In the interest of simplifying
configurations (lowering people opex) many providers simple specify
dynamic routing with dynamic FRR protection with zero bandwidth on the
protection.  This is not ideal and may somehow offend the defenders of
"transport purity".

That was a long answer to a short question.

> It is still there, maybe I should have used path instead of LSP.

Regards,

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 27 Mar 2010 20:00:33 -0400

> working paths. This is a network planning and engineering issue outside the

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

---

From: Adrian Farrel <[email-masked]>
Date: Mon, 29 Mar 2010 09:08:33 +0100

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" <[email-masked]>
To: "Zhi-Wei Lin" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Sunday, March 28, 2010 1:00 AM
Subject: Re: [mpls-tp] [mpls] Question 
ondraft-ietf-mpls-tp-linear-protection-01

>
> In message 
> <[email-masked]>
> Zhi-Wei Lin writes:
>>
>> Hi Huub,
>>
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: John E Drake <[email-masked]>
Date: Mon, 29 Mar 2010 09:22:44 -0700

Adrian,

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

Thanks,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Farrel
> Sent: Monday, March 29, 2010 1:09 AM
> To: [email-masked]; Zhi-Wei Lin
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Question ondraft-ietf-mpls-tp-linear-protection-01
> 
> Hi,
> 
> >> >>>> Oversubscription should be a function of what type of service
> level
> >> >>>> is

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 29 Mar 2010 18:03:15 +0100

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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>; "Zhi-Wei 
Lin" <[email-masked]>
Cc: <[email-masked]>
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
>
>> >> 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
>> >
>> >
>> >> >>>> defined for the underlying LSP. LSPs do not need to always be 
>> >> >>>> full
>> >> >>>> "CBR"
>> >> >>>> type service.
>> >> >>>>

---

From: "tom.petch" <[email-masked]>
Date: Mon, 29 Mar 2010 12:20:54 +0200

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
Sent: Monday, March 29, 2010 10:08 AM
Subject: Re: [mpls-tp] Question ondraft-ietf-mpls-tp-linear-protection-01

> confusion further down the line.

Yes, I was about to point out that most of the I-Ds which contain definitions
of MIP and MEP get them wrong, eg 
draft-asm-mpls-tp-bfd-cc-cv-02
" MEP: Maintenance End Point
 MIP: Maintenance Intermediate Point"

Probably, in the case of abbreviations, they are worth duplicating BUT
including a statement such as 
"This terminology is reproduced from 
draft-ietf-mpls-tp-rosetta-stone
which should be considered authoritative in the event of any discrepancies."

Tom Petch

> ondraft-ietf-mpls-tp-linear-protection-01
<snip>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 29 Mar 2010 21:55:45 -0400

In message <EF95718250914BEAAD068EAD3680DA5C@your029b8cecfe>
> confusion further down the line.

Good point.  I'll look at the definition there.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 29 Mar 2010 22:36:01 -0400

> (http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-recovery-terminology/)

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

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Tue, 30 Mar 2010 03:46:37 -0400

Yes, definitions in RFC4427 should be used as a basis - as the framework
does. There's no need to define protection again in the linear
protection document - the definition in the framework (and RFC4427)
already aligns with Zhi's suggestion - as they all are based on G808.1.

Zhi's suggestion on oversubscription should be added to the framework
document (if agreed) - any extras for supporting mpls-tp should be in
the mpls-tp-survive-fwk document. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Curtis Villamizar
Sent: Monday, March 29, 2010 10:36 PM
To: John E Drake
Cc: [email-masked]; Adrian Farrel
Subject: Re: [mpls-tp] Question
ondraft-ietf-mpls-tp-linear-protection-01

In message
<[email-masked]>
> Wouldn't RFC 4427
(http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-recovery-termino
logy/)

Curtis

> > Subject: Re: [mpls-tp] Question
> > 
> > Hi,
> > 
> > Would it be worth NOT including definitions of protection switching
in
> > this
> > >> I believe that is correct. The decision to do this would be made
by
> > >> external
> > >> link, sum of CIRs on protection link > actual capacity of
protection
> > >> link.
> > >> Protection switching is a fully allocated survivability
mechanism. It
> > >> Protection switching is a survivability mechanism with
pre-configured
> > >> paths.
> > >> 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
outside
> > >> >>>> defined for the underlying LSP. LSPs do not need to always
be full
> > >> >  Offline computation tools and explicit-path currently support
this
> > in