Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Aug 2010 09:33:03 -0400

In message <[email-masked]>
Maarten Vissers writes:
>  
> Curtis,
>  
> See inline.. 
>  
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: vrijdag 30 juli 2010 13:39
> To: Maarten Vissers
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
>  
>  
> In message <[email-masked]>
> Maarten Vissers writes:
> >  
> > Curtis,
> >  
> > Transport networks are traffic engineered and congestion of committed 
> > rate traffic should be an abnormal condition. If it however happens on 
> > a link carrying a working connection of a protected service-LSP or PW 
> > then the network can switch the traffic of these protected transport 
> > service signals to their protection connection as well. This should 
> > not result in creation of congestion of committed rate traffic on ony 
> > of the links over which the protection connection is set up.
>  
> If so, then how does queueing loss occur and impact how SD is set?
>  
> [maarten] Queueing loss occurs due to a fault; e.g. reduced capacity of a
> link (e.g. link aggregation, VCAT) or mistake in choice of links when
> setting up of a new service. These things should not happen, but actually
> they do occasionally.

If a LAG member is lost, curreent MPLS practice is to reduce the
advertised link bandwidth and preempt (preferably soft-preempt) those
lowest priority LSP that no longer fit.  If reasonable provisioning
has been done, then this works fine.

This is current practice for *MPLS*, maybe not T-MPLS, but T-MPLS is
dead so don't bother quoting Y.1731.  MPLS-TP is based on MPLS.

This would also work in the absense of a control plane, as the
preempted LSP would fall back to protection and the rest would be
unaffected.  In a 10x LAG this is much better than indicating to all
LSP (all of which may be carrying some low priority traffic) that
service is degrated.  With a control plane, those LSP that have been
preempted have the chance to signal a new working and protect and
remain protected until the LAG member is brought back into service.

Also note that as previously discussed LAG, being a form of multipath
that can result of reordering within a LSP, is not suitable to carry
MPLS-TP without some modification.

> Noticing congestion and sending twice is not a good idea.
>  
> [maarten] That is your opinion, which is not shared by everybody. Protected
> services are in demand and are offered as premium services. The protection
> paths are designed into the network and the bandwidth is paid for by the
> customer... Nonetheless that he/she is only using this bandwidth very
> rarely.

There has been little or no concensus for anything you've said in this
thread.  I've just cited current practice which is implemented by
every MPLS LSR as it is the behaviour consistent with existing MPLS
specifications as they have stood for about a decade.

> If you say congestion can't happen, stick with that argument and we have no
> SD due to queueing loss.
>  
> [maarten] Transport network designs are architected around the idea that
> congestion of committed rate traffic should not happen; but as indicated
> above, the network is experiencing faults and during the presence of some
> faults congestion may temporarily occur. After the fault is repaired the
> congestion is gone.

There should be no congestion on the LAG with the fault the way MPLS
currently works.  The lower priority LSP are simply preempted.

> If you say congestion can happen, then don't make it worse by sending twice.
>  
> [maarten] Sending a copy of the traffic to the protection path does not make
> congestion worse... The protection path is not congested and will not be
> congested when the protected traffic is send to it as long as there is no
> fault on this protection path.

If the total capacity of the network has been reduced and congestion
has occurred as a result, then congestion exists in the network.

If protection capacity has been engineered into the network, then the
LAG that was carrying working traffic should also have some protection
LSP which are unused.  If enough capacity has been lost to cause
congestion in one part of the network, then it is entirely possible
that congestion exists elsehwere.  Some good examples are floods that
take more than one site out, train wrecks that take fiber out on both
sides of tracks, earthquakes with more than one fiber right of way
along the fault, bridge collapse with fiber on both sides of the
bridge, etc, etc, etc.  Anything that doubles the total offerred load
in the network in response to congestion is just plain stupid.

This is consistent with ITU-T.  Behaviours have not been well thought
through and apparently there has not yet been enough deployment (of
this aspect of protection) to figure out that it doesn't work well.

> Regards,
> Maarten

Curtis

> > The customer will be satisfied that his investment in a protected 
> > service pay of in such committed rate network congestion problem.
> >  
> > The network operator providing this protection against any packet loss 
> > condition is able to deploy the protection bandwidth for most of the 
> > time to transport excess traffic and or lower priority traffic which 
> > has an availability of e.g. 95%.
> >  
> > Regards,
> > Maarten
>  
> Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Aug 2010 18:44:51 +0200

Curtis,

What you describe is a compound link protection method in which there are
e.g. two LAGs. An LSP can be carried over LAG #0 or on LAG #1. If bandwidth
of LAG#0 is reduced, then LSPs #A to #F can be moved to LAG#1 to reduce
bandwidth demand on LAG #0. As a LAG is a MPLS-TP physical layer entity,
this compound link protection method protects against physical layer faults
and degradations. Alternatively there is one LAG and LSPs are distributed
over the individual links in the LAG (with traffic of each LSP/PW going over
one link only to prevent reordering). 
	Note that such compound link protection uses a distributor bridge
(not a broadcast bridge).

It is in theory possible that a LAG degrades so much (e.g. loose 9 of the 10
links in a 10x LAG) that there is insufficient protection capacity to
restore preferred traffic (>10%) without congestion. If there are 1:1
protected LSPs or PWs passing over such LAG, then detecting such congestion
at the LSP/PW tail ends will result in a SD triggered protection switch and
thus in restoring the protected traffic... But...

I agree with your statement "In a 10x LAG this is much better than
indicating to all LSP (all of which may be carrying some low priority
traffic) that service is degrated.". 
So can we make it mandatory in MPLS-TP networks that LAGs are operated with
compound link protection? And for the case that the LAG capacity gets too
small to keep LSPs/PWs congestion free (for preferred traffic) can we
mandate that some LSPs/PWs are blocked and can not access the degraded LAG?
Congestion of all LSPs/PWs then results in interruption of some LSPs/PWs,
and those LSPs/PWs can then be protected on the basis of a SF condition.

In order for an MPLS-TP compound link protection circuit to know which
LSPs/PWs to switch or block access in the latter case, it is required that
this protection circuit has knowledge of the CIR/EIR values of each LSP/PW,
plus a priority list of the LSPs/PWs to block access first when bandwidth
gets too small.

We should add this type of compound link protection (essentially the
adaptive version of compound link protection) as a protection method in the
survivability framework. 

---------

Besides LAGs we also have microwave links in the edge of the packet
transport networks, and those links may also adapt their bandwidth based on
weather conditions. Those microwave systems do not have multiple interfaces,
so compound link protection can typically not be performed at those
microwave systems. Instead those compound link protection mechanisms have to
be deployed from other (e.g. PE) nodes located around these microwave
systems. Micorwave endpoints could signal the degraded bandwdith per
transport-LSP and then PE nodes can redistribute PWs/service-LSPs/HVPLSs
over the group of transport-LSPs, or block access for some
PWs/service-LSPs/HVPLSs to these transport-LSPs.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 2 augustus 2010 15:33
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten Vissers writes:
> > Transport networks are traffic engineered and congestion of 
> > committed rate traffic should be an abnormal condition. If it 
> > however happens on a link carrying a working connection of a 
> > protected service-LSP or PW then the network can switch the traffic 
> > of these protected transport service signals to their protection 
> > connection as well. This should not result in creation of congestion 
> > of committed rate traffic on ony of the links over which the protection
connection is set up.
> [maarten] Queueing loss occurs due to a fault; e.g. reduced capacity 
> of a link (e.g. link aggregation, VCAT) or mistake in choice of links 
> when setting up of a new service. These things should not happen, but 
> actually they do occasionally.

If a LAG member is lost, curreent MPLS practice is to reduce the advertised
link bandwidth and preempt (preferably soft-preempt) those lowest priority
LSP that no longer fit.  If reasonable provisioning has been done, then this
works fine.

This is current practice for *MPLS*, maybe not T-MPLS, but T-MPLS is dead so
don't bother quoting Y.1731.  MPLS-TP is based on MPLS.

This would also work in the absense of a control plane, as the preempted LSP
would fall back to protection and the rest would be unaffected.  In a 10x
LAG this is much better than indicating to all LSP (all of which may be
carrying some low priority traffic) that service is degrated.  With a
control plane, those LSP that have been preempted have the chance to signal
a new working and protect and remain protected until the LAG member is
brought back into service.

Also note that as previously discussed LAG, being a form of multipath that
can result of reordering within a LSP, is not suitable to carry MPLS-TP
without some modification.

> [maarten] That is your opinion, which is not shared by everybody. 
> Protected services are in demand and are offered as premium services. 
> The protection paths are designed into the network and the bandwidth 
> is paid for by the customer... Nonetheless that he/she is only using 
> this bandwidth very rarely.

There has been little or no concensus for anything you've said in this
thread.  I've just cited current practice which is implemented by every MPLS
LSR as it is the behaviour consistent with existing MPLS specifications as
they have stood for about a decade.

> If you say congestion can't happen, stick with that argument and we 
> have no SD due to queueing loss.
>  
> [maarten] Transport network designs are architected around the idea 
> that congestion of committed rate traffic should not happen; but as 
> indicated above, the network is experiencing faults and during the 
> presence of some faults congestion may temporarily occur. After the 
> fault is repaired the congestion is gone.

> [maarten] Sending a copy of the traffic to the protection path does 
> not make congestion worse... The protection path is not congested and 
> will not be congested when the protected traffic is send to it as long 
> as there is no fault on this protection path.

If the total capacity of the network has been reduced and congestion has
occurred as a result, then congestion exists in the network.

If protection capacity has been engineered into the network, then the LAG
that was carrying working traffic should also have some protection LSP which
are unused.  If enough capacity has been lost to cause congestion in one
part of the network, then it is entirely possible that congestion exists
elsehwere.  Some good examples are floods that take more than one site out,
train wrecks that take fiber out on both sides of tracks, earthquakes with
more than one fiber right of way along the fault, bridge collapse with fiber
on both sides of the bridge, etc, etc, etc.  Anything that doubles the total
offerred load in the network in response to congestion is just plain stupid.

This is consistent with ITU-T.  Behaviours have not been well thought
through and apparently there has not yet been enough deployment (of this
aspect of protection) to figure out that it doesn't work well.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 03 Aug 2010 14:12:06 -0400

A LAG in a provider network, either in core or metro or anything in
between is multiple wavelengths on the same WDM on the same fiber.

If a card goes dark, a LAG member goes out or for some multiport card
failures a set of LAG members goes out.  If the fiber is cut (more
common) then the whole LAG goes down.

Generally when a LAG member goes out, there is protection capacity for
the working paths on the other LAG and if anything, that gets
preempted.

Lighting an extra wave is relatively cheap (particularly when 10s of
LAG members are already in use in the core) so LAGs tend to be a
little bit bigger than they need to be.  They are also sized for
anticipated traffic growth.

So yes what I described is the common case and preemption is more an
academic issue until multiple failures occur.

Curtis

In message <[email-masked]>