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

From: Maarten Vissers <[email-masked]>
Date: Tue, 27 Jul 2010 10:43:05 +0200

Hi Ma,
 
see inline..

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 27 juli 2010 4:53
To: [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Maarten, 

I have some questions about SD. Correct me if I'm wrong. Thanks!   

1) Frame/Packet loss (per priority) of one path/channel is used for checking
SD, but protection for path/channel does not base on one priority.  
 
[maarten] At the moment the Ethernet OAM frame loss monitoring
specifications in Y.1731 and G.8021 specify that ETH CCM is able to
pro-actively monitor the frame loss in a VLAN for one priority and the
in-service frames (i.e. the non drop-eligible frames at this priority). The
operator can choose which priority it would like to monitor; typically the
highest priority is assumed, but a lower priority (if present in the VLAN)
is also possible.
 
[maarten] The frame loss monitoring in G.8021 will result in a DEG defect
and this DEG defect will trigger the SD condition, which will be an input to
the protection switching state machine.
 
[maarten] Note that on-demand frame loss monitoring is possible for every
priority level in a VLAN.
 
[maarten] MEF has requested to extend the number of pro-active frame loss
monitoring processes to be able to support frame loss monitoring for more
then one priority in a VLAN. Y.1731 and G.8021 are currently being extended
with this capability. I expect that this will also result in the definition
of a DEG defect per priority and that SD will then be triggered by the oring
of those DEG defects (e.g. SD = dDEG(p1) or dDEG(p2) or .. or dDEG(pn)).
Note that frame loss is counted for in service frames, i.e. frames that are
not drop-eligible.
 
[maarten] The potential extention of SD condition could increase complexity
of protection switching while one could argue that loss of high priority
frames is more severe then loss of low priority frames... to keep it simple
it would be best to ignore such differences. 

2) in the future, maybe all packet links will run over OTN, but now, other
interfaces(e.g. SDH, Ethernt) are being for thansport. It's worth to
consider present state.  
 
[maarten] I agree with you. 
 
Regards,
Maarten 

Thanks! 

Regards,
Ma 

[email-masked] 
发件人:  [email-masked] 

2010-07-15 上午 10:20 
请答复 给
[email-masked]

收件人
	[email-masked] 
抄送
	
主题
	mpls-tp Digest, Vol 25, Issue 72	

Message: 1
Date: Wed, 14 Jul 2010 18:51:39 -0400
From: Curtis Villamizar <[email-masked]>
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00
To: Maarten Vissers <[email-masked]>
Cc: 'Rafi Ram' <[email-masked]>, [email-masked],
                [email-masked]
Message-ID: <[email-masked]>

Maarten,

Thanks.  I was not even close.  Perhaps what I remember is what we had
configurable threshhold set to to get the response we wanted.  In any
case, on a small number of framing errors POS links could be taken
down.  On "dribbling" errors POS links could also be taken down.

I'm quite sure we didn't tolerate 10% errors under any circumstances
either when I was at a provider (actually two IP providers) or at a
router vendor.  To us SONET was a dumb framing protocol used for point
to point POS links (and to an extent that hasn't changed) and we
didn't care much what the SONET recommendation were as long as we
could configure parameters on equipment to get the desired behaviour.

The routers could easily count POS (SONET) framing errors so maybe the
fast responding error handling wasn't related at all to SONET specs.

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 27 Jul 2010 17:40:22 +0300

Maarten and all,
I have doubts regarding applicability of the SD concept to packet networks in general and MPLS-TP in particular.
The problem is that, as opposed to traditional transport networks 9SONET/SDH, OTN etc.) packet loss depends
on actual traffic. This is because one of the main reasons for dropping packets is congestion.
Note also that many types of packet traffic are backing off if they experience packet loss, and that routers employ WRED to prevent synchronized loss of packets by multiple flows.

In other words, packet loss is very different from BER.

E.g., if you use packet los-based SD to trigger path protection in a 1:1 (or N:1) model, you may simply find that your SD condition that have not been observed on the protection path before it was used (since it was not congested) appears there after you switch traffic to it in response to an SD condition on the working path.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Tuesday, July 27, 2010 10:43 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Ma,
 
see inline..

Hi Maarten, 

 

 

 
 
Regards,
Maarten 

Thanks! 

Regards,
Ma 

[email-masked] 

2010-07-15 上午 10:20 
请答复 给
[email-masked]

收件人
	[email-masked] 
抄送
	
主题

Message: 1

Maarten,

Curtis

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Rafi Ram" <[email-masked]>
Date: Tue, 27 Jul 2010 17:46:26 +0300

All,

draft-rkhd-mpls-tp-sd-00 suggest SD detection method which does not
depend on OAM and avoids aspects of congestion and other drawbacks of
OAM based SD detection.

Regards,

Rafi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alexander Vainshtein
Sent: Tuesday, July 27, 2010 5:40 PM
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten and all,

I have doubts regarding applicability of the SD concept to packet
networks in general and MPLS-TP in particular.

The problem is that, as opposed to traditional transport networks
9SONET/SDH, OTN etc.) packet loss depends

on actual traffic. This is because one of the main reasons for dropping
packets is congestion.

Note also that many types of packet traffic are backing off if they
experience packet loss, and that routers employ WRED to prevent
synchronized loss of packets by multiple flows.

E.g., if you use packet los-based SD to trigger path protection in a 1:1
(or N:1) model, you may simply find that your SD condition that have not
been observed on the protection path before it was used (since it was
not congested) appears there after you switch traffic to it in response
to an SD condition on the working path.

Regards,

     Sasha

---

From: [email-masked]
Date: Wed, 28 Jul 2010 09:55:02 +0800

I have the same doubt.

Proactive and on-demand monitoring are both for end-to-end traffic loss. 
But maybe the packet loss is not caused by BER.

SD detection method suggested by draft-rkhd-mpls-tp-sd-00 is worth 
considering.

Regards,
    Ma

Alexander Vainshtein <[email-masked]> 
2010-07-27 下午 10:40

收件人
Maarten Vissers <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten and all,
I have doubts regarding applicability of the SD concept to packet networks 
in general and MPLS-TP in particular.
The problem is that, as opposed to traditional transport networks 
9SONET/SDH, OTN etc.) packet loss depends
on actual traffic. This is because one of the main reasons for dropping 
packets is congestion.
Note also that many types of packet traffic are backing off if they 
experience packet loss, and that routers employ WRED to prevent 
synchronized loss of packets by multiple flows.

E.g., if you use packet los-based SD to trigger path protection in a 1:1 
(or N:1) model, you may simply find that your SD condition that have not 
been observed on the protection path before it was used (since it was not 
congested) appears there after you switch traffic to it in response to an 
SD condition on the working path.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Maarten Vissers
Sent: Tuesday, July 27, 2010 10:43 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Ma,
 
see inline..

Hi Maarten, 

1) Frame/Packet loss (per priority) of one path/channel is used for 
checking
SD, but protection for path/channel does not base on one priority. 
 
in-service frames (i.e. the non drop-eligible frames at this priority). 
The
 
[maarten] The frame loss monitoring in G.8021 will result in a DEG defect
and this DEG defect will trigger the SD condition, which will be an input 
to
the protection switching state machine.

[maarten] MEF has requested to extend the number of pro-active frame loss
monitoring processes to be able to support frame loss monitoring for more
then one priority in a VLAN. Y.1731 and G.8021 are currently being 
extended
with this capability. I expect that this will also result in the 
definition
of a DEG defect per priority and that SD will then be triggered by the 
oring
of those DEG defects (e.g. SD = dDEG(p1) or dDEG(p2) or .. or dDEG(pn)).
Note that frame loss is counted for in service frames, i.e. frames that 
are
not drop-eligible.
 
[maarten] The potential extention of SD condition could increase 
complexity
of protection switching while one could argue that loss of high priority
frames is more severe then loss of low priority frames... to keep it 
simple
it would be best to ignore such differences. 

 
Regards,
Maarten 

Thanks! 

Regards,
Ma 

[email-masked] 

2010-07-15 上午 10:20 
请答复 给
[email-masked]

收件人
                 [email-masked] 
抄送
 
主题

Message: 1

Maarten,

Curtis

--------------------------------------------------------
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: Maarten Vissers <[email-masked]>
Date: Wed, 28 Jul 2010 09:28:06 +0200

Sasha,

For a customer it does not matter what is causing the packet loss (bit
errors on a medium, packet drop due to congestion). The performance
monitoring specifications in a SLA specify thresholds to determine a
Severely Errored Second based on generic frame/packet loss and not just on
frame/packet loss due to bit errors on a medium. 10 consecutive SESs result
in entering unavailable time, which is a very bad thing to happen.

SD triggered protection switching is defined to prevent that UAT is entered.

It is well understood (at least in Q.9/15) that the use of SD as a trigger
of 1:1 PW/LSP SNC/S protection requires a check of the SD condition on the
protection connection after switching... In a badly engineered packet
transport networks congestion of the non-drop eligible (i.e. CIR) traffic
may occur. 	If this is the case a protection switch due to congestion on
working connection may not be succesful as - after switching - there will be
congestion on the protection connection. Result will be that the customer
will be dissatisfied with the performance provided by its service...

In a well engineered transport network, links may be congested for drop
eligible (i.e. EIR) traffic but not for the non-drop eligible (i.e. CIR)
traffic. A protection switch will in such case not result in congestion on
the links carrying the protection connection.

SD is as such not about bit errors (i.e. loss of the original bit
information), it is about loss of information, either bits or
frames/packets.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: dinsdag 27 juli 2010 16:40
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten and all,
I have doubts regarding applicability of the SD concept to packet networks
in general and MPLS-TP in particular.
The problem is that, as opposed to traditional transport networks
9SONET/SDH, OTN etc.) packet loss depends on actual traffic. This is because
one of the main reasons for dropping packets is congestion.
Note also that many types of packet traffic are backing off if they
experience packet loss, and that routers employ WRED to prevent synchronized
loss of packets by multiple flows.

E.g., if you use packet los-based SD to trigger path protection in a 1:1 (or
N:1) model, you may simply find that your SD condition that have not been
observed on the protection path before it was used (since it was not
congested) appears there after you switch traffic to it in response to an SD
condition on the working path.

Regards,
     Sasha

-----Original Message-----

Hi Ma,
 
see inline..

Hi Maarten, 

 

 

 
 
Regards,
Maarten 

Thanks! 

Regards,
Ma 

[email-masked] 

2010-07-15 上午 10:20 
请答复 给
[email-masked]

收件人
	[email-masked] 
抄送
	
主题

Message: 1

Maarten,

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Jul 2010 09:41:12 +0200

Rafi,
 
The description:
   An LSP is considered to have SD fault, when at least one of the links
   it forwarded through has rate of errored bits exceeding a
   predetermined BER threshold.
is not correctly representing the nature of a SD condition. 
 
SD is about loss of information, either in bits or in frames/packets. In
e.g. OTN it is expressed in terms of "number of ODU frames with one or more
bit errors exceeds a threshold". In OTN those frames are not discarded when
an error is detected. In packet networks, the frame or packet with an error
is discarded. Furthermore, in packet networks congestion may introduce
frame/packet loss; in OTN this is loss of information condition is not
present.
 
The idea to detect bit errors at the physical layer and forwarding this
information in new OAM messages does not meet the requirements to determine
the number of lost packets and thus the ability to check if the required
performance as specified in the SLA would be met, or if it is required to
switch the traffic to the protection connection.
 
Regards,
Maarten

  _____  

From: Rafi Ram [mailto:[email-masked]] 
Sent: dinsdag 27 juli 2010 16:46
To: Alexander Vainshtein; Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

All,

draft-rkhd-mpls-tp-sd-00 suggest SD detection method which does not depend
on OAM and avoids aspects of congestion and other drawbacks of OAM based SD
detection.

Regards,

Rafi

-----Original Message-----
Of Alexander Vainshtein

Maarten and all,

Regards,

     Sasha

---

From: "Rafi Ram" <[email-masked]>
Date: Wed, 28 Jul 2010 10:59:28 +0300

Maarten,

The description of SD fault in the draft was intended to provide general
view of link impairment due to link operation out of desirable quality
target.

I would like to exclude congestion and reduce link bandwidth as causes
SD triggered protection.

The exact definition of entering/exiting SD condition is transport
technology dependent.

The number of lost packets, I believe, should not be the criterion for
SD detection since selecting a viable a-priory threshold value is not
possible :

1)       Threshold cannot be not agnostic to frame rate/length

2)       Threshold cannot be not agnostic to traffic class and drop
precedence marking

3)       Threshold cannot be not agnostic to link congestion level

4)       Difficult in determining low BER conditions with reasonable
miss-detection and false alarm probabilities

Best regards

Rafi

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, July 28, 2010 10:41 AM
To: Rafi Ram; 'Alexander Vainshtein'
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Rafi,

The description:

SD is about loss of information, either in bits or in frames/packets. In
e.g. OTN it is expressed in terms of "number of ODU frames with one or
more bit errors exceeds a threshold". In OTN those frames are not
discarded when an error is detected. In packet networks, the frame or
packet with an error is discarded. Furthermore, in packet networks
congestion may introduce frame/packet loss; in OTN this is loss of
information condition is not present.

The idea to detect bit errors at the physical layer and forwarding this
information in new OAM messages does not meet the requirements to
determine the number of lost packets and thus the ability to check if
the required performance as specified in the SLA would be met, or if it
is required to switch the traffic to the protection connection.

Regards,

Maarten

All,

Regards,

Rafi

-----Original Message-----

Maarten and all,

Regards,

     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Jul 2010 11:14:30 +0200

Rafi,
 
SD definition is related to specifications in performance standards. Those
standards define the condition under which the peformance is degraded. For
packet technology networks, this condition includes packet loss. At this
point in time we have as such two options:
1) use packet loss as main information loss element of the SD condition
2) request SG12 and MEF to change their packet performance specifications
and then base the information loss element of the SD condition on the
modified information loss element.
 
Current status is option 1.
 
Please note that existing SD definition includes a single dDEG. This is due
to the existing standards require that frame/packet loss measurement is only
to be done on one priority level (for non-drop eligible traffic); i.e.
threshold is ptraffic class/drop precedence aware. 

Recently it was agreed in SG15 to extend this initial requirement and work
is ongoing to measure packet loss on multiple priority levels (for non-drop
eligible traffic). This work most likely will result in a need to extend the
SD definition, and include the dDEG for each of the measured priority levels
(traffic classes).

An outstanding item, currently under study, is if packet loss counting
should be based on the number of bytes being discarded, instead of the
number of packets. I.e. make the counting aware of the frame/packet lengths.

Regards,
Maarten

From: Rafi Ram [mailto:[email-masked]] 
Sent: woensdag 28 juli 2010 9:59
To: Maarten Vissers; Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten,

I would like to exclude congestion and reduce link bandwidth as causes SD
triggered protection.

The number of lost packets, I believe, should not be the criterion for SD
detection since selecting a viable a-priory threshold value is not possible
:

Best regards

Rafi

Rafi,

The description:

Regards,

Maarten

All,

Regards,

Rafi

-----Original Message-----

Maarten and all,

Regards,

     Sasha

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 08:14:45 -0400

In message <[email-masked]>
> E.g., if you use packet los-based SD to trigger path protection in a 1:1 (or N:1) model, you may simply find that your SD condition that have not been observed on the protection path before it was…

SD should not be used to indicate queueing loss.

Curtis

> ������:  [email-masked] 
>  
> 2010-07-15 ���� 10:20 
> ��� ��
> [email-masked]
> 	
>  
>  
> �ռ���
> 	[email-masked] 
> ����
> 	
> ����

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Jul 2010 15:24:23 +0300

Curtis,
You've said:
	"SD should not be used to indicate queuing loss".

I completely agree. Actually this is what I have been trying to say in my email.
The problem is that packet loss due to bit errors in physical links cannot be attributed to specific LSPs.
And if we put aside queuing loss and loss due to bit errors, what is left?

My conclusion is that there is no such thing as SD for LSPs.

It is just one more case when the generic ITU network model is not applicable to packet-based networks.

My 2c,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 28, 2010 2:15 PM
To: Alexander Vainshtein
Cc: Maarten Vissers; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00 

Curtis

> ·¢¼þÈË:  [email-masked] 
>  
> 2010-07-15 ÉÏÎç 10:20 
> Çë´ð¸´ ¸ø
> [email-masked]
> 	
>  
>  
> ÊÕ¼þÈË
> 	[email-masked] 
> ³ËÍ
> 	
> Ö÷Ìâ

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Jul 2010 14:33:00 +0200

Curtis,

SD is required to indicate packet loss. 
There is no requirement to indicate packet loss due to bit errors on a
medium.

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 28 juli 2010 14:15
To: Alexander Vainshtein
Cc: Maarten Vissers; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

In message
<[email-masked]>
> 9SONET/SDH, OTN etc.) packet loss depends on actual traffic. This is
because one of the main reasons for dropping packets is congestion.

Curtis

> Behalf Of Maarten Vissers
> checking SD, but protection for path/channel does not base on one
priority.
> in-service frames (i.e. the non drop-eligible frames at this 
> priority). The operator can choose which priority it would like to 
> monitor; typically the highest priority is assumed, but a lower 
> priority (if present in the VLAN) is also possible.
>  
> [maarten] The frame loss monitoring in G.8021 will result in a DEG 
> defect and this DEG defect will trigger the SD condition, which will 
> be an input to the protection switching state machine.
>  
> [maarten] Note that on-demand frame loss monitoring is possible for 
> every priority level in a VLAN.
>  
> [maarten] MEF has requested to extend the number of pro-active frame 
> loss monitoring processes to be able to support frame loss monitoring 
> for more then one priority in a VLAN. Y.1731 and G.8021 are currently 
> being extended with this capability. I expect that this will also 
> result in the definition of a DEG defect per priority and that SD will 
> then be triggered by the oring of those DEG defects (e.g. SD = dDEG(p1) or
dDEG(p2) or .. or dDEG(pn)).
> Note that frame loss is counted for in service frames, i.e. frames 
> that are not drop-eligible.
>  
> complexity of protection switching while one could argue that loss of 
> high priority frames is more severe then loss of low priority 
> frames... to keep it simple it would be best to ignore such differences.
>  
> 2) in the future, maybe all packet links will run over OTN, but now, 
> other interfaces(e.g. SDH, Ethernt) are being for thansport. It's 
> worth to consider present state.
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 08:57:48 -0400

In message <[email-masked]>
> It is just one more case when the generic ITU network model is not applicable to packet-based networks.

Yes I read the continued thread.  If SD is based on congestion and
used to switch traffic to alternate paths, it is very easy to produce
oscillations.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Jul 2010 09:06:54 -0400

In message <[email-masked]>
> There is no requirement to indicate packet loss due to bit errors on a

If queueing loss causes traffic to move elsewhere, the queueing loss
is decreased and the queueing loss elsehwere can increase.

This can result in oscillations.  This did occur in the old DARPANET
in the mid 1980s (I think).  It is well know to be a Bad Idea (tm).

I hope we don't need a long thread on this.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 28 Jul 2010 15:09:13 +0200

Curtis,

> If SD is based on congestion and used to switch traffic 
> to alternate paths, it is very easy to produce oscillations.

In a non-intelligent design this would indeed be the case... As there is a
lot of intelligence in our industry this potential consequence has been
identified some years ago, and counter measures have been build into the
protection switching operation caused by SD... So no oscillations will
occur.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 28 juli 2010 14:58
To: Alexander Vainshtein
Cc: [email-masked]; Maarten Vissers; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

In message
<[email-masked]>
> It is just one more case when the generic ITU network model is not
applicable to packet-based networks.

Yes I read the continued thread.  If SD is based on congestion and used to
switch traffic to alternate paths, it is very easy to produce oscillations.

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 28 Jul 2010 16:12:39 +0300

Maarten,
Could you be a bit more specific about "intelligent counter-measures"?
Did they apply to SD based on packet loss measurements?
And have they ever been deployed?

Regards,
     Sasha
________________________________________
From: Maarten Vissers [[email-masked]]
Sent: Wednesday, July 28, 2010 4:09 PM
To: [email-masked]; Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Curtis,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 28 juli 2010 14:58
To: Alexander Vainshtein
Cc: [email-masked]; Maarten Vissers; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

In message

Curtis

---

From: "Rafi Ram" <[email-masked]>
Date: Wed, 28 Jul 2010 21:57:34 +0300

Maarten,
 
There are (at least) 3 possible link impairment:
1. Bit errors on link
2. Offered load greater than link bandwidth (i.e. congestion)

3. Reduction in link bandwidth

In existing transport networks (which MPLS-TP targets) :
(a) Only bit errors are considered cause for SD condition
(b) Protection is triggered due to SD condition

Regards
Rafi

From: [email-masked] on behalf of Maarten Vissers
Sent: Wed 7/28/2010 3:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Curtis,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 28 juli 2010 14:15
To: Alexander Vainshtein
Cc: Maarten Vissers; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

In message

Curtis

priority.

---

From: [email-masked]
Date: Thu, 29 Jul 2010 14:25:55 +0800

hi,all
it is unclear for me whether sd of server layer eg. bit error , congestion 
etc, will lead to SD condition in the lsp layer?
if the answer is yes, we may make use of SD detection of server layer to 
indicate SD defect of LSP Layer;
if the answer is no, we may detect SD of LSP layer by LM or DM function,
IMO, the method MAY be very hard and diffcult to detect SD by LM or DM 
function for E-LSP.

can i miss something important ?
 
best regards
liu

"Rafi Ram" <[email-masked]> 
发件人:  [email-masked]
2010-07-29 02:57

收件人
"Maarten Vissers" <[email-masked]>, <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten,

Regards
Rafi

Curtis,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 28 juli 2010 14:15
To: Alexander Vainshtein
Cc: Maarten Vissers; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

In message
> I have doubts regarding applicability of the SD concept to packet 
networks
synchronized
SD

Curtis

priority.

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 29 Jul 2010 08:39:52 +0200

Sasha,

A p2p packet service is typically protected by means of 1:1 SNC/S
protection. 
- Under non-SF/non-SD conditions the traffic is forwarded over the working
connection only; no traffic is send to the protection connection. 
- If a SF condition occurs, then it is possible to forward the traffic over
the protection connection only; no traffic has to be send to the workign
connection.
- If you protect such packet service against SD conditions then if such SD
condition occurs on working it is necessary to forward the traffic to both
the working and protection connections. 

Rationale for the traffic broadcast to both working and protection is that
SD conditions are detected on the basis of measuring the actual traffic, and
if this traffic would be removed from the working connection during a
protection switch on SD, the SD condition would clear; i.e. zero packets
transmitted, zero packets received implies no packets lost and thus SD
clearing. Such SD clearing would result in switching the traffic back to
working, and then SD is detected again, and then there is a switch, and then
SD on working clears, etc... 

With the use of what is called a "broadcast bridge" in a 1:1 SNC/S packet
service protection switch method we get a stable protection behaviour.

If the protection connection would experience SD condition after traffic is
carried also over protection connection, then the protection selector will
keep selecting traffic from protection connection and not switch back to
working connection. This is enforced by the APS protocol, which gives
priority to the first occurance of the SD condition (i.e. SD-W).

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 28 juli 2010 15:13
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten,

Regards,
     Sasha

Curtis,

> If SD is based on congestion and used to switch traffic to alternate 
> paths, it is very easy to produce oscillations.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 28 juli 2010 14:58
To: Alexander Vainshtein
Cc: [email-masked]; Maarten Vissers; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

In message
<[email-masked]>
Alexander Vainshtein writes:
> I completely agree. Actually this is what I have been trying to say in 
> my
email.
> The problem is that packet loss due to bit errors in physical links 
> cannot
be attributed to specific LSPs.

Curtis

>=

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 29 Jul 2010 09:54:14 +0200

Rafi,
 
If you look at the SD specification in G.8021 (i.e. for Ethernet based
packet transport network), then you will find the following:
1) SD = dDEG
2) dDEG is activated if there are M (2 <=M <= 10) consecutive BAD seconds. A
BAD second is a second in which the frame loss ration exceeds the value
DEGTHR and more then a minimum number of TFMIN frames was transmitted.
 
The MEP Sink function detecting the dDEG defect is totaly unaware of the
reasons of the frame loss; it could be bit errors on the medium and/or frame
drops due to congestion and/or other frame drop conditions.
 
For MPLS-TP based packet transport networks it will be the same.

****************

If you would like to change this and would only trigger protection switching
due to bit errors on a medium, then you would need to create a complex error
forwarding mechanism... e.g. assume that a PW or service-LSP is passing
through e.g. 10 nodes as follows:
 
PE1 - PE2 - P1 - PE3 - P2 - P3 - PE4 - P4 - PE5 - PE6
         \- P5 - PE7 - P6 - P7 - PE8 - P8 -/   

				FIGURE 1
 
1:1 PW/service-LSP SNC protection is set up between PE2 and PE5.
Assume that bit errors occur on the links between PE2->P1 and P2->P3. 
How will PE5 be aware of the occurrence of those bit errors?

A) P1 will detect on its ingress port some bit errors when terminating the
physical layer signal.
B) P3 will detect on its ingress port some bit errors when terminating the
physical layer signal.
C) P1 and P3 have to communicate those bit error indications to PE5, but P1
and P3 are totally unaware of the PW or service-LSP's SPME which is
monitoring the PE2 egress to PE5 ingress working connection ("working SPME
LSP" in Figure 2).

|----------------PW or service-LSP------------------|

        |---------working SPME LSP----------|
        |-tLSP23-| |---tLSP34----| |-tLSP45-|
  |-S-| |-S-||-S-| |-S-||-S-||-S-| |-S-||-S-| |-S-|
  |-P-| |-P-||-P-| |-P-||-P-||-P-| |-P-||-P-| |-P-|

PE1 - PE2 - P1 - PE3 - P2 - P3 - PE4 - P4 - PE5 - PE6
         \- P5 - PE7 - P6 - P7 - PE8 - P8 -/ 
  
        |-P-||-P-| |-P-||-P-||-P-| |-P-||-P-|
        |-S-||-S-| |-S-||-S-||-S-| |-S-||-S-|
        |-tLSP27-| |---tLSP78----| |-tLSP85-|
        |-------protection SPME LSP---------|

P: Physical medium conection
S: MPLS-TP Section connection
tLSP: MPLS-TP transport-LSP

				FIGURE 2

D) In theory you could think of the following bit error communication
channel architecture:
1) P1 ingress port will write the number of bit errors (or errored blocks)
detected in a second on the physical interface into a Bit Error Comms (BEC)
OAM packet and insert this BEC OAM packet into tLSP23 (and all other tLSPs
active on this interface)
2) PE3 will detect the BEC OAM packet in its tLSP23 MEP Sink function and
inserts this BEC packet into the working SPME LSP (and in all other LSPs/PWs
present in tLSP23)
3) P3 ingress port will write the number of bit errors detected in a second
on the physical interface into a BEC OAM packet and insert this BEC OAM
packet into tLSP34 (and all other tLSPs active on this interface)
4) PE4 will detect the BEC OAM packet in its tLSP34 MEP Sink function and
inserts this BEC packet into the working SPME LSP (and in all other LSPs/PWs
present in tLSP34)
5) PE5 will detect the BEC OAM packets inserted into the working SPME LSP by
PE3 and PE4 in its working SPME LSP MEP Sink function.

Unfortunately, PE5 does not have any information if those bit errors/errored
blocks have caused any actual packet loss in the working SPME LSP. How can
PE5 now correctly interprete the numbers within the BEC OAM packets? Perhaps
the working SPME LSP MEP in PE5 can also count the number of packets lost
between PE2 and PE5 on the working connection, and use the BEC information
to filter the packet loss information; e.g. if no BEC OAM packets are
received, then assume any packet loss is due to congestion; if BEC OAM
packets are received, then assume packet loss is due to bit errors.

As the 1-second bit error/errored block counting in P1 and P3 and the
1-second packet loss counting in PE5 are not synchronized, there is a
misalignment in the BEC OAM and packet loss information counting... This
will degenerate the correctness of the results... i.e. we will get very
arbitrary results.

Can we do better? An other alternative is to require that the egres ports
count the number of discarded packets due to congestion; e.g. PE2, P1, PE3,
P2, P3, PE4 and P4 could be configured to count the number of discarded
working SPME LSP packets in their egress ports and generate every 1-second a
Discarded Packets (DP) OAM packet into the working SPME LSP. For P1, P2, P3,
P4 this implies that these nodes have to have awareness of the inner working
SPME LSP... Not a very attractive option in my understanding.

If MPLS-TP is carrying an Ethernet service (90% of cases), then the Ethernet
customer will use its Ethernet frame loss measurement capability to check if
his service provider (using his MPLS-TP network) complies with the agreed
SLA. The customer will as such count lost, non-drop eligible ethernet
frames, including those frames lost due to congestion in the service
providers network. If the service provider is counting dropped
frames/packets excluding those dropped due to congestion, there will be
regularly conflicts between the customer and service provider with respect
to the number of lost frames. Very bad for the MPLS-TP technology...

Regards,
Maarten

From: Rafi Ram [mailto:[email-masked]] 
Sent: woensdag 28 juli 2010 20:58
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten,

Regards
Rafi

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 29 Jul 2010 09:56:56 +0200

Curtis,

Use of SD as trigger condition for protection does not result in moving the
traffic from the working connection to the protection connection. Refer to
my response to Sasha this morning. Traffic will stay on working connection
and will also be send over the protection connection.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 28 juli 2010 15:07
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Curtis

networks
synchronized
SD

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 29 Jul 2010 05:44:55 -0400

In message <[email-masked]>
> and will also be send over the protection connection.

So if congestion occurs in the network the reaction is to double the
load offerred to the network and in doing so increase congestion.

Apparently this is the "highly intellegent" network behaviour that you
referred to in prior email.

This is a G.8021 behaviour that we could document and but we may want
to explicitly prohibit it in MPLS-TP, at least discourage it.

Curtis

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 29 Jul 2010 13:26:33 +0300

Maarten, Curtis, and all,

1+1 path protection with its "permanent bridging" is indeed the only case when SD measurements based on
packet loss can be applicable. It is not applicable in any other case IMO.
Consider the case when packets are dropped due to bit errors on some links: longer packets will 
experience bit errors (and dropped by the FCS checks) with higher probability than short packets,
so if the traffic patterns on the two paths are different, the SD measurements would be incomparable.)

Whether 1+1 path protection is a reasonable MPLS-TP technique is, IMO, questionable.

But, at the very least, is worth to state explicitly that the SD concept based on packet loss measurement has
very limited applicability.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Thursday, July 29, 2010 9:57 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Curtis,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 28 juli 2010 15:07
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Curtis

networks
synchronized
SD

---

From: [email-masked]
Date: Fri, 30 Jul 2010 09:26:21 +0800

Hi Maarten,

I don’t think error forwarding mechanism is very complex, it is just the 
same as FDI forwarding mechanism. 

Using error of link to detect error of LSP is called ‘Inherent monitoring
’ in G.805,  it states in G.805
‘The trail in the server layer network may also provide some error 
performance information about a single link connection. When the 
adaptation function includes multiplexing, the error performance 
statistics for each of the link connections, supported by the server layer 
trail, will not be available individually; it must be estimated from the 
error performance of the trail.’
It is not much accurate, but I think it is useful in some case, such as 
the client layer doesn’t support LM. As we know, LM mechanism need 
hardware support, network equipments which are already deployed cannot 
support LM unless upgrade hardware. 
On other hand, if there are large number of LSP, Detecting packet loss of 
each of these LSP will consume lot of hardware resource. 

IMO, using broadcast bridge in 1:1 protection will waste the bandwidth of 
working path. A good designed network should not drop packets with ‘non 
eligible’ flag even congestion occurs，so the main reason of packet loss 
is fiber failure, I was told by a carrier that 90% of the network fault is 
fiber fault, monitoring LSP error by inherent monitoring can work 
correctly in most cases, and it doesn’t need broadcast.

Regard,
Suhui

2010-07-29 15:54

收件人
'Rafi Ram' <[email-masked]>, [email-masked]
抄送
[email-masked]
主题
Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Rafi,
 
2) dDEG is activated if there are M (2 <=M <= 10) consecutive BAD seconds. 
A
 
The MEP Sink function detecting the dDEG defect is totaly unaware of the
reasons of the frame loss; it could be bit errors on the medium and/or 
frame
drops due to congestion and/or other frame drop conditions.

****************

If you would like to change this and would only trigger protection 
switching
due to bit errors on a medium, then you would need to create a complex 
error
forwarding mechanism... e.g. assume that a PW or service-LSP is passing
through e.g. 10 nodes as follows:

                                                                 FIGURE 1

C) P1 and P3 have to communicate those bit error indications to PE5, but 
P1

 

                                                                 FIGURE 2

D) In theory you could think of the following bit error communication
channel architecture:
1) P1 ingress port will write the number of bit errors (or errored blocks)
detected in a second on the physical interface into a Bit Error Comms 
(BEC)
OAM packet and insert this BEC OAM packet into tLSP23 (and all other tLSPs
active on this interface)
2) PE3 will detect the BEC OAM packet in its tLSP23 MEP Sink function and
inserts this BEC packet into the working SPME LSP (and in all other 
LSPs/PWs
present in tLSP23)
3) P3 ingress port will write the number of bit errors detected in a 
second
on the physical interface into a BEC OAM packet and insert this BEC OAM
packet into tLSP34 (and all other tLSPs active on this interface)
4) PE4 will detect the BEC OAM packet in its tLSP34 MEP Sink function and
inserts this BEC packet into the working SPME LSP (and in all other 
LSPs/PWs
present in tLSP34)
5) PE5 will detect the BEC OAM packets inserted into the working SPME LSP 
by
PE3 and PE4 in its working SPME LSP MEP Sink function.

Unfortunately, PE5 does not have any information if those bit 
errors/errored
blocks have caused any actual packet loss in the working SPME LSP. How can
PE5 now correctly interprete the numbers within the BEC OAM packets? 
Perhaps
the working SPME LSP MEP in PE5 can also count the number of packets lost
between PE2 and PE5 on the working connection, and use the BEC information
to filter the packet loss information; e.g. if no BEC OAM packets are
received, then assume any packet loss is due to congestion; if BEC OAM
packets are received, then assume packet loss is due to bit errors.

Can we do better? An other alternative is to require that the egres ports
count the number of discarded packets due to congestion; e.g. PE2, P1, 
PE3,
P2, P3, PE4 and P4 could be configured to count the number of discarded
working SPME LSP packets in their egress ports and generate every 1-second 
a
Discarded Packets (DP) OAM packet into the working SPME LSP. For P1, P2, 
P3,
P4 this implies that these nodes have to have awareness of the inner 
working
SPME LSP... Not a very attractive option in my understanding.

If MPLS-TP is carrying an Ethernet service (90% of cases), then the 
Ethernet
customer will use its Ethernet frame loss measurement capability to check 
if
his service provider (using his MPLS-TP network) complies with the agreed
SLA. The customer will as such count lost, non-drop eligible ethernet
frames, including those frames lost due to congestion in the service
providers network. If the service provider is counting dropped
frames/packets excluding those dropped due to congestion, there will be
regularly conflicts between the customer and service provider with respect
to the number of lost frames. Very bad for the MPLS-TP technology...

Regards,
Maarten

Maarten,

Regards
Rafi

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jul 2010 11:12:44 +0200

Sasha,

In Ethernet and MPLS-TP type packet transport networks we use 1:1 SNC/S
protection with a "broadcast bridge". Note that a "broadcast bridge" is not
the same as a "permanent bridge" used in 1+1 SNC protection.

A "broadcast bridge" sends under non-SF/SD conditions traffic to the working
connection only. Only during SF or SD conditions the traffic is send to both
the working and the protection connections. This implies that traffic is
send to both working and protection connections for a few hours per year
only (assuming a typical MTTR of about 4 hours).

A "permanent bridge" send traffic under all conditions to both working and
protection connections. In packet transport networks (Ethernet, MPLS-TP)
such "permanent bridge" would be used only for 1+1 unidirectional p2mp SNC/N
protected LSPs or PWs. The unidirectional nature of the p2mp connections
require for the case of protection that both working and protection
connections carry the traffic so that the tail end (i.e. leaf nodes) can
perform the protection switching locally.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: donderdag 29 juli 2010 12:27
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

1+1 path protection with its "permanent bridging" is indeed the only 
1+case when SD measurements based on
packet loss can be applicable. It is not applicable in any other case IMO.
Consider the case when packets are dropped due to bit errors on some links:
longer packets will experience bit errors (and dropped by the FCS checks)
with higher probability than short packets, so if the traffic patterns on
the two paths are different, the SD measurements would be incomparable.)

Whether 1+1 path protection is a reasonable MPLS-TP technique is, IMO,
questionable.

But, at the very least, is worth to state explicitly that the SD concept
based on packet loss measurement has very limited applicability.

Regards,
     Sasha

-----Original Message-----

Curtis,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 28 juli 2010 15:07
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Curtis

networks
synchronized
SD

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jul 2010 11:22:57 +0200

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. 

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 29 juli 2010 11:45
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten Vissers writes:
>  
> Curtis,
>  
> Use of SD as trigger condition for protection does not result in 
> moving the traffic from the working connection to the protection 
> connection. Refer to my response to Sasha this morning. Traffic will 
> stay on working connection and will also be send over the protection
connection.
> Maarten

So if congestion occurs in the network the reaction is to double the load
offerred to the network and in doing so increase congestion.

This is a G.8021 behaviour that we could document and but we may want to
explicitly prohibit it in MPLS-TP, at least discourage it.

Curtis

> > There is no requirement to indicate packet loss due to bit errors on 
> > a medium.
> >  
> > Regards,
> > Maarten
>  
>  
> > (or N:1) model, you may simply find that your SD condition that have 
> > not been observed on the protection path before it was used (since 
> > it was not
> > > 1) Frame/Packet loss (per priority) of one path/channel is used 
> > > for checking SD, but protection for path/channel does not base on 
> > > one
> > priority.
> > >  
> > > specifications in Y.1731 and G.8021 specify that ETH CCM is able 
> > > to pro-actively monitor the frame loss in a VLAN for one priority 
> > > and the in-service frames (i.e. the non drop-eligible frames at 
> > > this priority). The operator can choose which priority it would 
> > > like to monitor; typically the highest priority is assumed, but a 
> > > lower priority (if present in the VLAN) is also possible.
> > >  
> > > defect and this DEG defect will trigger the SD condition, which 
> > > will be an input to the protection switching state machine.
> > >  
> > > [maarten] Note that on-demand frame loss monitoring is possible 
> > > for every priority level in a VLAN.
> > >  
> > > [maarten] MEF has requested to extend the number of pro-active 
> > > frame loss monitoring processes to be able to support frame loss 
> > > monitoring for more then one priority in a VLAN. Y.1731 and G.8021 
> > > are currently being extended with this capability. I expect that 
> > > this will also result in the definition of a DEG defect per 
> > > priority and that SD will then be triggered by the oring of those 
> > > DEG defects (e.g. SD = dDEG(p1)
> or
> > > complexity of protection switching while one could argue that loss 
> > > of high priority frames is more severe then loss of low priority 
> > > 2) in the future, maybe all packet links will run over OTN, but 
> > > now, other interfaces(e.g. SDH, Ethernt) are being for thansport. 
> > > It's worth to consider present state.
> > >

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 30 Jul 2010 07:38:30 -0400

In message <[email-masked]>
> protection connection is set up. 

If so, then how does queueing loss occur and impact how SD is set?

Noticing congestion and sending twice is not a good idea.

If you say congestion can't happen, stick with that argument and we
have no SD due to queueing loss.

If you say congestion can happen, then don't make it worse by sending
twice.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jul 2010 13:44:58 +0200

Liu,
 
SD defects are based on a packet loss ratio (PLR), i.e. the ratio of
transmitted packets and lost packets.
The first packet loss is detected by the Section MEP and is computed over
all non-drop eligible packets with priority X and on the link/section.
The second packet loss is detected by a Transport Path MEP and is computed
over all non-drop eligible packets with priority X and on the transport path
connection (e.g. transport-LSP, transport path SPME LSP).
The third packet loss is detected by a Transport Service MEP and is computed
over all non-drop eligible packets with priority X and on the transport
service connection (e.g. PW, service-LSP, transport service SPME LSP).
 
Assume that a Section carries 100 transport-LSPs and that each transport-LSP
carries 50 service-LSPs/PWs/HVPLSs then the Section carries 5000 service
LSPs/PWs/HVPLSs.
 
Your question below translates in this example into the question if bit
errors in the physical media will lead to packet loss in one or more of the
100 transport-LSPs and in one or more of the 5000 service-LSPs, PWs and
HVPLS instances?
 
Individual bit errors (after FEC correction) will only hit one packet and
thus one of the 100 transport-LSPs and one of the 5000
service-LSPs/PWs/HVPLSs; which one of those 100 or 5000 instances is
unknown.

The EB counting is performed per 1-second period, and ODU dDEG is detected
(and ODU SD is triggered) when M (default 7) seconds have more then 15% EBs
(refer to G.8201 and G.798).

15% EBs implies that there are one or more bit errors (after FEC) in every
7th ODU frame. An ODU frame carries the MPLS-TP packets in its OPU payload,
which contains 15232 bytes. Assuming an average MPLS-TP packet length of 256
bytes and GFP-F encapsulation with GFP FCS, an OPU frame will contain up to
56 MPLS-TP packets and 7 OPU frames will contain up to about 400 packets. An
ODU SD condition would then imply that every 400 packets one or more will
contain bit errors and will thus be discarded when the ODU is terminated and
the MPLS-TP packets are extracted. 

The question is if you would like to initiate protection switching on either
100 transport-LSPs or 5000 service-LSPs/Pws/HVPLSs when there is >=0.25%
committed traffic packet loss at the section layer?

Regards,
Maarten 
PS. Please be aware that for Ethernet frame loss counting is now implemented
and introduced into the networks; note that p2p VLANs are like E-LSPs.
Draft-bhh intents to reuse those implementations and combine them with
MPLS-TP OAM headers. I.e. if it works for Ethernet VLANs, it should work
also for MPLS-TP. Also some T-MPLS designs already support packet loss
counting on the basis of these Ethernet designs. Would MPLS-TP be so much
worse/different then Ethernet and T-MPLS?

From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 29 juli 2010 8:26
To: Rafi Ram
Cc: [email-masked]; Maarten Vissers; [email-masked];
[email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

hi,all 

best regards 
liu

2010-07-29 02:57

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jul 2010 13:57:19 +0200

Suhui,
 
This bit error/errored block communication forwarding mechanism requires
hardware support as well in every adaptation sink function. It also requires
that adaptation sink functions which demultiplex LSPs and PWs have to
replicate the BEC OAM onto all client LSPs/PWs; this is a broadcast
function. E.g. in a PE interface with 100 transport-LSPs carrying 5000
service-LSPs/PWs up to 5000 BEC OAM packets have to be inserted every
second, while the normal traffic still is present. This is different with
respect to AIS insert; i.e. AIS is inserted when the original traffic is not
longer present.
 
I agree with you that a good designed transport network should not drop
non-drop eligible packets. Such network also should not break links or have
other fault and degradation conditions occuring. We all know that such
faults/degradations occur, and the OAM is added to the network to detect
when such conditions occur, help with fault/degradation location and trigger
protection when customers have included this feature in their SLA.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 30 juli 2010 3:26
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]; 'Rafi Ram'
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Hi Maarten, 

Using error of link to detect error of LSP is called ‘Inherent monitoring’
in G.805,  it states in G.805 
‘The trail in the server layer network may also provide some error
performance information about a single link connection. When the adaptation
function includes multiplexing, the error performance statistics for each of
the link connections, supported by the server layer trail, will not be
available individually; it must be estimated from the error performance of
the trail.’ 
It is not much accurate, but I think it is useful in some case, such as the
client layer doesn’t support LM. As we know, LM mechanism need hardware
support, network equipments which are already deployed cannot support LM
unless upgrade hardware. 
On other hand, if there are large number of LSP, Detecting packet loss of
each of these LSP will consume lot of hardware resource. 

IMO, using broadcast bridge in 1:1 protection will waste the bandwidth of
working path. A good designed network should not drop packets with ‘non
eligible’ flag even congestion occurs，so the main reason of packet loss is
fiber failure, I was told by a carrier that 90% of the network fault is
fiber fault, monitoring LSP error by inherent monitoring can work correctly
in most cases, and it doesn’t need broadcast. 

Regard, 
Suhui 

2010-07-29 15:54 

收件人

抄送
[email-masked] 

主题

Rafi,

****************

                                                                   FIGURE 1

 

                                                                   FIGURE 2

Regards,
Maarten

Maarten,

Regards
Rafi

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.

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jul 2010 14:10:38 +0200

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

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.

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

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

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.

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.

Regards,
Maarten

> The customer will be satisfied that his investment in a protected 
> service pay of in such committed rate network congestion problem.
>  
> 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: <[email-masked]>
Date: Fri, 30 Jul 2010 13:33:56 +0100

Curtis,

You are correct in what you say below.

Transport networks have a really important quality which they must
provide, ie they must treat client symbols in a *transparent* sense.
This is so very important for a whole raft of technical, commercial and
regulatory reasons.

One of the key principles of transparency is that a server layer network
must make no attempt to understand (and for sure not modify) client
information symbols (the smallest information symbol is the bit, larger
symbols are formed from groups of bits).  So all forms of client
snooping/DPI by a server layer network are most definitely not allowed
in transport networks.  Some less well understood (it seems)
consequences of transparency are:

-	besides the obvious reachability isolation between different
client layer network instances that a server network must ensure, it
also needs to ensure performance isolation between different client
layer network instances, ie traffic behaviour of client X cannot impact
SLA experienced by client;

-	one immediate corollary of the above is that server layer
resources should not be overbooked (this is your correct point Curtis
about SD not being a function of congestion in transport networks);

-	a less obvious consequence is that all client *bits* (ie the
atomic information symbol) must maintain ordering in a transport network
and this is also why a connection can only have a single source and
traffic class.

-	it is trivially simple to prove that a non-TOS layer network
never needs E-NNIs...however, since all networking scenarios where we
have to cover geographic distance require a BOS layer network (ie where
we modulate an EM wave) we MUST have a physical interconnect here.  But
this is NOT an E-NNI as some folks try and argue!!.....we simply pass
client *bits* with ordering maintained transparently across such
physical layer interconnects.  Note there is no attempt to infer any
client symbol meaning (ie larger grouping of client bits) be they part
of the  client's DP, CP or MP.

Hopefully this is helping to clarify what transparency means and why it
is an important characteristic of a transport network.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Curtis Villamizar
> Sent: 30 July 2010 12:39
> To: Maarten Vissers
> Cc: [email-masked]
> If you say congestion can't happen, stick with that argument 
> and we have no SD due to queueing loss.
> 
> > > > There is no requirement to indicate packet loss due to 
> bit errors 
> > > > on a medium.
> > > >  
> > > > Regards,
> > > > Maarten
> > >  
> > >  
> <[email-masked]
> > > > >
> > > > > The problem is that, as opposed to traditional transport 
> > > > > networks 9SONET/SDH, OTN etc.) packet loss depends on actual 
> > > > > traffic. This is
> > > > > Note also that many types of packet traffic are 
> backing off if 
> > > > > they
> > > > > E.g., if you use packet los-based SD to trigger path 
> protection 
> > > > > in a 1:1
> > > > (or N:1) model, you may simply find that your SD condition that 
> > > > have not been observed on the protection path before it 
> was used 
> > > > (since it was not
> > > > > From: [email-masked] 
> [mailto:[email-masked]] 
> > > > > On Behalf Of Maarten Vissers
> > > > > for checking SD, but protection for path/channel does 
> not base 
> > > > > on one
> > > > priority.
> > > > >  
> > > > > to pro-actively monitor the frame loss in a VLAN for one 
> > > > > priority and the in-service frames (i.e. the non 
> drop-eligible 
> > > > > frames at this priority). The operator can choose 
> which priority 
> > > > > it would like to monitor; typically the highest priority is 
> > > > > assumed, but a lower priority (if present in the 
> VLAN) is also possible.
> > > > >  
> > > > > [maarten] The frame loss monitoring in G.8021 will 
> result in a 
> > > > > DEG defect and this DEG defect will trigger the SD condition, 
> > > > > which will be an input to the protection switching 
> state machine.
> > > > >  
> > > > > monitoring for more then one priority in a VLAN. Y.1731 and 
> > > > > G.8021 are currently being extended with this capability. I 
> > > > > expect that this will also result in the definition of a DEG 
> > > > > defect per priority and that SD will then be triggered by the 
> > > > > oring of those DEG defects (e.g. SD = dDEG(p1)
> > > or
> > > > > Note that frame loss is counted for in service frames, i.e. 
> > > > > frames that are not drop-eligible.
> > > > >  
> > > > > complexity of protection switching while one could argue that 
> > > > > loss of high priority frames is more severe then loss of low 
> > > > > priority frames... to keep it simple it would be best 
> to ignore 
> > > > > such
> > differences.
> > > > >

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jul 2010 14:52:41 +0200

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

Regards,
Maarten

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 30 Jul 2010 09:15:00 -0400

> customer... Nonetheless that he/she is only using this bandwidth very

TOM: It is not just his opinion; its not a good idea to send it twice if you
do not have to. If you are talking about a true 1+1 protection and a service
that is designed around that, then that is expected and you factor that
overhead into the service design/cost. However, in the normal case this is
not needed or desired, and Curtis is spot on.

> fault on this protection path.

    Sending an extra copy *could* make congestion worse if your protection
paths overlap at the same node(s), for example. Since MPLS-TP paths are not
explicitly disjoint unless planned that way, it is most certainly possible.
Even CR traffic *could* experience congestion depending on the
implementation in use.  Also, congestion is not necessarily mitigated after
the fault is repaired, as it could be orthogonal or contributing element of
the fault.

    --Tom

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jul 2010 16:04:53 +0200

Tom,
 
> TOM: It is not just his opinion; its not a good idea to send it twice
> if you do not have to. If you are talking about a true 1+1 protection
> and a service that is designed around that, then that is expected and
> you factor that overhead into the service design/cost. However, in the
> normal case this is not needed or desired, and Curtis is spot on.

As you write "if you do not have to". In this case "you have to".

In general with protected services there will be a period of some hours per
year that you have to sent its traffic twice into the network. The customer
is paying for this.

> paths overlap at the same node(s), for example. Since MPLS-TP paths are
> not explicitly disjoint unless planned that way, it is most certainly
possible.

Overlapping protection and working paths are very bad protection designs. 
You would introduce a single point of failure and Murphy's law will apply.
Your customer will certainly be upset with you.

> Even CR traffic *could* experience congestion depending on the
implementation
> in use.  Also, congestion is not necessarily mitigated after the fault is
> repaired, as it could be orthogonal or contributing element of the fault.

If you design your network with congestion build in for CR traffic and have
as design rule to operate with CR congestion on the links carrying working
and the links carrying protection connections, then you will most likely
have spent a lot of hasle to set up the protected paths and you will not be
able to provide lossless CR transport. Will your premium customer be happy?

Regards,
Maarten

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: vrijdag 30 juli 2010 15:15
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

On 7/30/10 8:52 AM, "Maarten Vissers" <[email-masked]> wrote:

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

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

    --Tom