Subject: [mpls-tp] sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

From: [email-masked]
Date: Tue, 7 Sep 2010 14:19:42 +0800

hi, 

both section 3.1.1(local request) and section 3.1.2 (remote request) 
describe SD request, either local or remote, but in section 4.2.2(PSC 
request field), I could't find the SD request and it's value. 

please clarify whether SD should be included in the PSC request field?

Best Regards

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 13 Sep 2010 15:36:30 +0200

Hi,

Thank you for your comment - your observation is correct and is under
discussion amongst the authors.  

Signal degrade is a very sticky issue - consider the discussion that
took place both on the mailing list and in Maastricht concerning
draft-rkhd-mpls-tp-sd.  Some of the authors are not sure that we can
really deal with SD except as consider any SD situation that goes beyond
a certain threshold as a SF condition, and anything below as "normal".
In addition, any consideration of comparing the SD levels between the
working and protection paths (for 1:1 protection) should be for further
study.  The comparison seems to be relevant only for unidirectional 1+1
protection, where it is a local decision and does not require a
coordination protocol.

Therefore the question seems to be whether we should remove the SD
references in section 3.1.1 & 3.1.2 or not.

Best regards,

yaacov

________________________________

From: ext [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 07, 2010 09:20
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); Sprecher, Nurit (NSN -
IL/Hod HaSharon)
Cc: [email-masked]
Subject: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

hi, 

Best Regards

---

From: "Rafi Ram" <[email-masked]>
Date: Mon, 13 Sep 2010 15:47:05 +0200

Hi Yaacov,

Some carriers expect SD triggered LSP protection, similar to
functionality available in existing common transport technologies.

In my opinion, SD condition on working LSP (SD-W) and on protecting LSP
(SD-P) share the same protection priority. This means that if SD-W
occurred first, and afterwards SD-P was detected the protection state is
not changed since there is no improvement in switching. Same for the
case of first SD-P and then SD-W - no switching.

Best regards,

Rafi

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: Monday, September 13, 2010 3:37 PM
To: [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] sd in
"draft-ietf-mpls-tp-linear-protection-02.txt"

Hi,

Best regards,

yaacov

hi, 

Best Regards

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 13 Sep 2010 15:57:13 +0200

Rafi, hi

But essentially what you are saying is that an SD condition is the same
as an SF condition (it is just a question of setting the threshold
appropriately) - unless you think that if a SD-P occurred first and
before recovering an SF-W occurred then we should go into Protecting
Failure condition because SD is better than SF.  But again this is a
question of the threshold that was set to be considered a SD worth
protecting!

BR,

yaacov

From: ext Rafi Ram [mailto:[email-masked]] 
Sent: Monday, September 13, 2010 15:47
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); [email-masked];
Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: RE: [mpls-tp] sd in
"draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Yaacov,

Best regards,

Rafi

Hi,

Best regards,

yaacov

hi, 

Best Regards

---

From: "Rafi Ram" <[email-masked]>
Date: Mon, 13 Sep 2010 17:08:40 +0200

Hi Yaacov,

Assuming a carriers have interest in differentiating between SF and SD
conditions, and wish to maintain the SD trigged protection available in
existing transport networks, then reference to SD trigged protection
should be included in the draft-ietf-mpls-tp-linear-protection.

Regards,

Rafi

From: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: Monday, September 13, 2010 3:57 PM
To: Rafi Ram; [email-masked]; Sprecher, Nurit (NSN - IL/Hod
HaSharon)
Cc: [email-masked]
Subject: RE: [mpls-tp] sd in
"draft-ietf-mpls-tp-linear-protection-02.txt"

Rafi, hi

BR,

yaacov

Hi Yaacov,

Best regards,

Rafi

Hi,

Best regards,

yaacov

hi, 

Best Regards

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Mon, 13 Sep 2010 20:51:35 +0200

Agreed
./
Lieven

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rafi Ram
Sent: 13 September 2010 17:09
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Yaacov,

Assuming a carriers have interest in differentiating between SF and SD conditions, and wish to maintain the SD trigged protection available in existing transport networks, then reference to SD trigged protection should be included in the draft-ietf-mpls-tp-linear-protection.

Regards,
Rafi

________________________________
From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [mailto:[email-masked]]
Sent: Monday, September 13, 2010 3:57 PM
To: Rafi Ram; [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: RE: [mpls-tp] sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Rafi, hi

But essentially what you are saying is that an SD condition is the same as an SF condition (it is just a question of setting the threshold appropriately) - unless you think that if a SD-P occurred first and before recovering an SF-W occurred then we should go into Protecting Failure condition because SD is better than SF.  But again this is a question of the threshold that was set to be considered a SD worth protecting!

BR,
yaacov

________________________________
From: ext Rafi Ram [mailto:[email-masked]]
Sent: Monday, September 13, 2010 15:47
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: RE: [mpls-tp] sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Yaacov,

Some carriers expect SD triggered LSP protection, similar to functionality available in existing common transport technologies.

In my opinion, SD condition on working LSP (SD-W) and on protecting LSP (SD-P) share the same protection priority. This means that if SD-W occurred first, and afterwards SD-P was detected the protection state is not changed since there is no improvement in switching. Same for the case of first SD-P and then SD-W - no switching.

Best regards,
Rafi

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: Monday, September 13, 2010 3:37 PM
To: [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi,

Thank you for your comment - your observation is correct and is under discussion amongst the authors.

Signal degrade is a very sticky issue - consider the discussion that took place both on the mailing list and in Maastricht concerning draft-rkhd-mpls-tp-sd.  Some of the authors are not sure that we can really deal with SD except as consider any SD situation that goes beyond a certain threshold as a SF condition, and anything below as "normal".  In addition, any consideration of comparing the SD levels between the working and protection paths (for 1:1 protection) should be for further study.  The comparison seems to be relevant only for unidirectional 1+1 protection, where it is a local decision and does not require a coordination protocol.

Therefore the question seems to be whether we should remove the SD references in section 3.1.1 & 3.1.2 or not.

Best regards,
yaacov

To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); Sprecher, Nurit (NSN - IL/Hod HaSharon)

hi,

both section 3.1.1(local request) and section 3.1.2 (remote request) describe SD request, either local or remote, but in section 4.2.2(PSC request field), I could't find the SD request and it's value.

Best Regards

---

From: [email-masked]
Date: Tue, 14 Sep 2010 11:42:50 +0800

agreed too.

     and I have another question wrt sf and sd. If sd occurred on the 
protection path first, and then an sf condition is detected on the working 
path, so in this condition , should the data traffic on the working path 
switches to the protection path or not? 
     from the description in 
"draft-ietf-mpls-tp-linear-protection-02.txt", the protection domain shoud 
still remain in unavaliable state, ie, data traffic is transmitted and 
received on the working path

best regards,

xuehui

"LEVRAU, LIEVEN (LIEVEN)" <[email-masked]> 
2010-09-14 02:51

收件人
Rafi Ram <[email-masked]>, "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [mpls-tp] sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Agreed
./
Lieven

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Rafi Ram
 
Hi Yaacov,

Regards,
Rafi

Rafi, hi
 
But essentially what you are saying is that an SD condition is the same as 
an SF condition (it is just a question of setting the threshold 
appropriately) – unless you think that if a SD-P occurred first and 
before recovering an SF-W occurred then we should go into Protecting 
Failure condition because SD is better than SF.  But again this is a 
question of the threshold that was set to be considered a SD worth 
protecting!
 
BR,
yaacov

Hi Yaacov,
 
Some carriers expect SD triggered LSP protection, similar to functionality 
available in existing common transport technologies.
 
In my opinion, SD condition on working LSP (SD-W) and on protecting LSP 
(SD-P) share the same protection priority. This means that if SD-W 
occurred first, and afterwards SD-P was detected the protection state is 
not changed since there is no improvement in switching. Same for the case 
of first SD-P and then SD-W – no switching.
 
Best regards,
Rafi

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: Monday, September 13, 2010 3:37 PM
To: [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] sd in "draft-ietf-mpls-tp-linear-protection-02.txt"
 
Hi,
 
Thank you for your comment – your observation is correct and is under 
discussion amongst the authors. 
 
Signal degrade is a very sticky issue – consider the discussion that took 
place both on the mailing list and in Maastricht concerning 
draft-rkhd-mpls-tp-sd.  Some of the authors are not sure that we can 
really deal with SD except as consider any SD situation that goes beyond a 
certain threshold as a SF condition, and anything below as "normal".  In 
addition, any consideration of comparing the SD levels between the working 
and protection paths (for 1:1 protection) should be for further study. The 
comparison seems to be relevant only for unidirectional 1+1 protection, 
where it is a local decision and does not require a coordination protocol.

Best regards,
yaacov

hi, 

Best Regards

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 14 Sep 2010 08:41:51 +0200

Hello Xuehui,

You wrote:

> protection path first, and then an sf condition is detected on the 
> working path, so in this condition , should the data traffic on the 
> working path switches to the protection path or not?

The protection should have the same behaviour as described in
G.808.1: SF shall have a higher prioriity for switching as SD.
So when SF is detected a switch is peformed even if the standby
path had SD.

See also Figure 6 in:
http://www.ietf.org/id/draft-zulr-mpls-tp-linear-protection-switching

Best regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: [email-masked]
Date: Tue, 14 Sep 2010 15:24:26 +0800

Hi Huub，

Thank you for your reply and information, I have the same view with you. 
But from my understanding on 
"draft-ietf-mpls-tp-linear-protection-02.txt", 

under this condition, data traffic can't be switched to the protection 
path. 

can the authors tell me is my undertstanding correct?

Huub van Helvoort <[email-masked]> 
2010-09-14 14:41
请答复 给
[email-masked]

收件人
[email-masked]
抄送
[email-masked]
主题
Re: [mpls-tp] 答复: RE:  sd in 
"draft-ietf-mpls-tp-linear-protection-02.txt"

Hello Xuehui,

See also Figure 6 in:

Best regards, Huub.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 14 Sep 2010 12:22:07 +0200

Huub, and all,
I would just like to remind you that, so far, we have failed to agree on a meaningful definition of the SD condition in packet networks in general and in MPLS-TP in particular.

E.g., the methods based on packet loss measurements have been shown to be highly problematic because:
- these measurements only make sense per traffic class. This does not have any analog in traditional transport networks (SONET/SDH, OTN) since there is just one "traffic class"
- one of the major underlying causes for packet loss is congestion, i.e., measured packet loss depends on actual traffic passing both thru the measured entity and all the other entities sharing common resources with the monitored one. This almost does not had any analogs in traditional traffic networks. (One potential analog could be PoS without scrambling, where false frame alignment could be detected if you have been sending some specially nasty traffic). As a consequence, if SD based on packet loss were used to trigger 1:1 linear protection, you could easily find that packet loss is always observed in the active path while the standby path remains clean!

The methods based on bit error rate in the links crossed by a given LSP have been also shown as highly problematic. The case of an Ethernet LAN link, where bit error rate simply cannot be measured is just one example.

I may be missing something important, but isn't the discussion of SD usage as a trigger for protection meaningless since this condition cannot be defined?

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Tuesday, September 14, 2010 8:42 AM
To: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hello Xuehui,

See also Figure 6 in:

Best regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Vivien Sterling <[email-masked]>
Date: Wed, 15 Sep 2010 16:40:29 +0800

Hi Sasha,

I fail to agree with you on this point.

The requirements of MPLS-TP are defined by a group of experts (some are
operators as well) who have spent more than 2 years on this. It is not wise
to stop something by hasty decision saying "no clear definition" or "no
solution".

As I can see, there are several drafts trying to solve this problem:

http://www.ietf.org/id/draft-ietf-mpls-tp-linear-protection-02.txt

http://datatracker.ietf.org/doc/draft-rkhd-mpls-tp-sd/

http://tools.ietf.org/id/draft-zhl-mpls-tp-sd-02.txt  (expired)

-- 

Cheers,
Vivien

2010/9/14 Alexander Vainshtein <[email-masked]>

> Huub, and all,
> I would just like to remind you that, so far, we have failed to agree on a
> meaningful definition of the SD condition in packet networks in general and
> in MPLS-TP in particular.
>
> - these measurements only make sense per traffic class. This does not have
> any analog in traditional transport networks (SONET/SDH, OTN) since there is
> just one "traffic class"
> - one of the major underlying causes for packet loss is congestion, i.e.,
> measured packet loss depends on actual traffic passing both thru the
> measured entity and all the other entities sharing common resources with the
> monitored one. This almost does not had any analogs in traditional traffic
> networks. (One potential analog could be PoS without scrambling, where false
> frame alignment could be detected if you have been sending some specially
> nasty traffic). As a consequence, if SD based on packet loss were used to
> trigger 1:1 linear protection, you could easily find that packet loss is
> always observed in the active path while the standby path remains clean!
>
> The methods based on bit error rate in the links crossed by a given LSP
> have been also shown as highly problematic. The case of an Ethernet LAN
> link, where bit error rate simply cannot be measured is just one example.
>
> I may be missing something important, but isn't the discussion of SD usage
> as a trigger for protection meaningless since this condition cannot be
> defined?
>
> Regards,
>     Sasha
>
> Of Huub van Helvoort
> Subject: Re: [mpls-tp] 答复: RE: sd in

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Sep 2010 11:14:44 +0100

I half agree with Sasha and half not :-(

The bit where I agree is the bit that says we have not (yet) produced a 
respectable definition of SD. Such a definition is a prerequisite for 
actually using SD as a trigger for anything (alarm, log, protection switch, 
financial penalty) in a live network.

But I do not agree that it will be impossible to generate such a definition, 
and I think it is time that the supporters of the use of SD sat down and 
wrote a concise definition (in an Internet-Draft, of course) so that we can 
all discuss from the same base point.

Again, I agree with Sasha that the analogs between SD in a PSN and SD in L1 
networks are hard to draw. But that does not mean that the concept cannot be 
defined, just that the foundations on which it is defined will be very 
different.

I would also note that SF is apparently not the extreme end of SD. That is, 
as SD continues to get worse, it does not converge on SF. SF is defined by 
the failure of a particular OAM packet to get through (regardless of whether 
all of the data is getting through!). SD is defined as the failure of (some 
percentage of) data packets to get through.

These definitions of SD and SF *do* need to be nailed down before they can 
be used operationally. But, IMHO, the definitions are not gating on the 
ability to "signal" an SD or SF event in OAM, or to act on the signaled 
event at a protection switching point. Definition of that work (i.e. of OAM 
messages and processing) can and should continue.

Cheers,
Adrian

----- Original Message ----- 
From: "Vivien Sterling" <[email-masked]>
To: "Alexander Vainshtein" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 15, 2010 9:40 AM
Subject: Re: [mpls-tp]答复: RE: sd in 

Hi Sasha,

-- 

Cheers,
Vivien

> http://www.ietf.org/id/draft-zulr-mpls-tp-linear-protection-switching

--------------------------------------------------------------------------------

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 Sep 2010 13:04:38 +0200

Adrian,
Lots of thanks for a prompt and very useful response.

I think that the agreement between us is actually above 50%:
- We  agree that so far there is no respectable (a.k.a. usable) definition of SD
- We agree that even if/when SD in PSN is reasonably defined, it will not be a close analog of SD in L1 networks
- Last but not least we agree (or so it seems to me) that as long as a respectable definition of SD is missing, discussing (and standardizing) its possible usage (for whatever purposes) is a bit premature. 

And, on top of that, I has not ever claimed that providing a reasonable definition of SD in PSN is impossible:
AFAIK, there is no law of nature that explicitly prohibits that. I've  only claimed that this task seems to be highly non-trivial given that the "brute force" attempts did not yield the result. It seems to me that we are more or less in agreement on this point, too. 

We probably disagree on the following point:
- I think that providing a reasonable definition of SD in PSN is hardly worth the effort
- You seem to think differently (but place the burden on the proponents of SD:-).

Did I miss something? Does the level of agreement between us reach 80% now?

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, September 15, 2010 12:15 PM
To: [email-masked]
Subject: [mpls-tp] More on SD

Cheers,
Adrian

----- Original Message ----- 
From: "Vivien Sterling" <[email-masked]>
To: "Alexander Vainshtein" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 15, 2010 9:40 AM
Subject: Re: [mpls-tp]答复: RE: sd in 

Hi Sasha,

-- 

Cheers,
Vivien

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Sep 2010 12:41:10 +0100

Hi Sasha,

> - We  agree that so far there is no respectable (a.k.a. usable)

Agreed.

> - We agree that even if/when SD in PSN is reasonably defined,
>   it will not be a close analog of SD in L1 networks

Mainly agreed.
The analog of what it is actually measuring will be absent.
The analog of "the signal has degraded" will still be useful for the purpose 
of an application trying to understand the quality of data delivery.

> - Last but not least we agree (or so it seems to me) that
>   as long as a respectable definition of SD is missing,
>   discussing (and standardizing) its possible usage (for
>   whatever purposes) is a bit premature.

Don't think we do agree there.
I said:
>> These definitions of SD and SF *do* need to be nailed
>> down before they can be used operationally. But, IMHO,
>> the definitions are not gating on the ability to
>> "signal" an SD or SF event in OAM, or to act on the
>> signaled event at a protection switching point.
>> Definition of that work (i.e. of OAM messages and
>> processing) can and should continue.

In other words, IMHO, it is perfectly OK to define a mechanism to notify 
switching points about SD, and it is OK to define the action that switching 
point will take (e.g. switch).

> And, on top of that, I has not ever claimed that
> providing a reasonable definition of SD in PSN is
> impossible:

Yes. I think that was just a misreading of your mail where you said...

>>> since this condition cannot be defined

> AFAIK, there is no law of nature that explicitly prohibits
> that. I've  only claimed that this task seems to be highly
> non-trivial given that the "brute force" attempts did not
> yield the result. It seems to me that we are more or less
> in agreement on this point, too.

Yes, I would agree that the work to define SD is not simply achieved by 
waving hands :-)

>   PSN is hardly worth the effort

That is an important question. But it is trumped by...

>   on the proponents of SD:-).

Right. In other words, folk that think it is important and necessary need to 
define it.

> Did I miss something? Does the level of agreement between

68%? ;-)

Adrian

> Of Adrian Farrel
>> Behalf

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 15 Sep 2010 07:40:50 -0500

Hi Vivien-

  Sasha's point with which you disagree is
"[...] so far, we have failed to agree on a meaningful definition of the SD condition in packet networks in general and in MPLS-TP in particular."

I think part of this hinges around what a 'meaningful definition' is.  As an implementor, a meaningful definition is a condition I can detect and a mechanism to detect it.  If I have an RFC in hand that purports to define SD but doesn't tell me how to do so in sufficient detail that I can write code, it's not meaningful.

Specific comments inline with EO#

> Of Vivien Sterling
> Sent: Wednesday, September 15, 2010 4:40 AM
> To: Alexander Vainshtein
> Cc: [email-masked]
> Subject: Re: [mpls-tp]答复: RE: sd in "draft-ietf-mpls-tp-linear-
> protection-02.txt"
> 
> Hi Sasha,
> 
> 
> 
> operators as well) who have spent more than 2 years on this. It is not
> wise to stop something by hasty decision saying "no clear definition" or
> "no solution".
> 
> 
> 

EO#  This draft contains no definition of SD.  Version -02 contains some text that describes how to communicate SD to a far end should SD be detected, but nothing further; the pending version -03 may remove this text.

> http://www.ietf.org/id/draft-zulr-mpls-tp-linear-protection-switching

EO#  This is very similar to draft-ietf-mpls-tp-linear-protection in that it contains a method for communicating SD but no useful means to detect it.  

> http://datatracker.ietf.org/doc/draft-rkhd-mpls-tp-sd/

EO#  This draft contains requirements for a definition of SD, but there's nothing there that is implementable without further details.  I think it may be a reasonable start for the concise definition Adrian requested in the "More on SD" thread, but there's nothing in draft-zulr that gives me a packet format or a state machine or any other such things.

> http://tools.ietf.org/id/draft-zhl-mpls-tp-sd-02.txt  (expired)

EO#
This draft is the closest of the four to providing a definition of something that could be implemented (section 4.1.1).  However, it seems to clash with what the mailing list agrees is the rough definition of SD.  From Adrian's mail in the other thread:

" SF is defined by the failure of a particular OAM packet to get through (regardless of whether all of the data is getting through!). SD is defined as the failure of (some percentage of) data packets to get through."

And draft-zhl says

"the detection of SD can be based on OAM packets"

and then goes on to talk about the transmission rate of said packets.  

If SD were to be defined as "a loss of some but not all OAM packets within a given time window at a specific rate" then draft-zhl may be a useful start, but as that appears to not be the rough consensus definition of SD, draft-zhl is out of date.

eric

> 	I would just like to remind you that, so far, we have failed to
> agree on a meaningful definition of the SD condition in packet networks in
> general and in MPLS-TP in particular.
> 
> 	- these measurements only make sense per traffic class. This does
> not have any analog in traditional transport networks (SONET/SDH, OTN)
> since there is just one "traffic class"
> 	- one of the major underlying causes for packet loss is congestion,
> i.e., measured packet loss depends on actual traffic passing both thru the
> measured entity and all the other entities sharing common resources with
> the monitored one. This almost does not had any analogs in traditional
> traffic networks. (One potential analog could be PoS without scrambling,
> where false frame alignment could be detected if you have been sending
> some specially nasty traffic). As a consequence, if SD based on packet
> loss were used to trigger 1:1 linear protection, you could easily find
> that packet loss is always observed in the active path while the standby
> path remains clean!
> 
> 	The methods based on bit error rate in the links crossed by a given
> LSP have been also shown as highly problematic. The case of an Ethernet
> LAN link, where bit error rate simply cannot be measured is just one
> example.
> 
> 	I may be missing something important, but isn't the discussion of SD
> usage as a trigger for protection meaningless since this condition cannot
> be defined?
> 
> 	Regards,
> 	    Sasha
> 
> 
> Behalf Of Huub van Helvoort

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 15 Sep 2010 15:00:40 +0200

Adrian, hi

I would like to pick up (I think naturally) on one point that you make below.  Given that our current ability to identify what an SD condition is and accepting that SF is different than SD - the protection action for a single one of these conditions may be obvious - either go into an Unprotected state (if on the protection path) or Switch to Protecting state (if the condition is on the working path).  The real question is what happens if there are more than one condition, e.g. if there is an SD on the protection path followed by an SF on the working path, or each path reports SD - what is the value call on what path do we use?

Thanx for your insights,
yaacov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Adrian Farrel
Sent: Wednesday, September 15, 2010 13:41
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] More on SD

Hi Sasha,

Agreed.

Mainly agreed.

68%? ;-)

Adrian

> wise
>> the
>> usage

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 Sep 2010 15:07:59 +0200

Yaakov,
I could not parse the following fragment in your message:
	"Given that our current ability to identify what an SD condition is and..."
Did you imply that we already have an ability to identify what an SD condition is?
Or that our current ability to identify what an SD condition does not exist?

Could you please clarify?

Regards,
     Sasha

-----Original Message-----
From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 3:01 PM
To: Adrian Farrel; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] More on SD

Adrian, hi

Thanx for your insights,
yaacov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Adrian Farrel
Sent: Wednesday, September 15, 2010 13:41
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] More on SD

Hi Sasha,

Agreed.

Mainly agreed.

68%? ;-)

Adrian

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 15 Sep 2010 15:09:40 +0200

Hi,

Sorry about that - I meant to say "Given that our current inability to identify ..."

BR,
yaacov

-----Original Message-----
From: ext Alexander Vainshtein [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 15:08
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]; Adrian Farrel
Subject: RE: [mpls-tp] More on SD

Yaakov,

Regards,
     Sasha

-----Original Message-----
From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 3:01 PM
To: Adrian Farrel; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] More on SD

Adrian, hi

Thanx for your insights,
yaacov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Adrian Farrel
Sent: Wednesday, September 15, 2010 13:41
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] More on SD

Hi Sasha,

Agreed.

Mainly agreed.

68%? ;-)

Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 Sep 2010 15:12:45 +0200

Yaakov,
Lots of thanks for a prompt clarification. 
These two lower-case characters ("in") that have been missing in the original email make a lot of difference!

Regards,
     Sasha

-----Original Message-----
From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 3:10 PM
To: Alexander Vainshtein
Cc: [email-masked]; Adrian Farrel
Subject: RE: [mpls-tp] More on SD

Hi,

BR,
yaacov

-----Original Message-----
From: ext Alexander Vainshtein [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 15:08
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]; Adrian Farrel
Subject: RE: [mpls-tp] More on SD

Yaakov,

Regards,
     Sasha

-----Original Message-----
From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 3:01 PM
To: Adrian Farrel; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] More on SD

Adrian, hi

Thanx for your insights,
yaacov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Adrian Farrel
Sent: Wednesday, September 15, 2010 13:41
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] More on SD

Hi Sasha,

Agreed.

Mainly agreed.

68%? ;-)

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Sep 2010 14:16:34 +0100

Why is this something to standardise, Yaacov?

Surely it is a configurable policy question, just as the threshold at which 
SD might be notified (or acted on) is configurable. While we might give some 
examples or advice, and an implementation might be expected to act in a 
particular way out of the box, I would expect the questions you ask to be 
answered by the operator, not by the standards.

Cheers,
Adrian
----- Original Message ----- 
From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" 
<[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Alexander Vainshtein" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 15, 2010 2:00 PM
Subject: RE: [mpls-tp] More on SD

Adrian, hi

I would like to pick up (I think naturally) on one point that you make 
below.  Given that our current ability to identify what an SD condition is 
and accepting that SF is different than SD - the protection action for a 
single one of these conditions may be obvious - either go into an 
Unprotected state (if on the protection path) or Switch to Protecting state 
(if the condition is on the working path).  The real question is what 
happens if there are more than one condition, e.g. if there is an SD on the 
protection path followed by an SF on the working path, or each path reports 
SD - what is the value call on what path do we use?

Thanx for your insights,
yaacov

-----Original Message-----
Of ext Adrian Farrel

Hi Sasha,

Agreed.

Mainly agreed.

68%? ;-)

Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 Sep 2010 15:20:24 +0200

Eric, Vivien and all,

First of all Vivien's message somehow did not reach me, just Eric's response.
So I will provide some comments on both of them in a single email.

Vivien has written that:
 
	"The requirements of MPLS-TP are defined by a group of experts (some are
	operators as well) who have spent more than 2 years on this". 

This is correct. However, SD is not even mentioned in RFC 5654 (MPLS-TP Requirements), RFC 5860 (Requirements for OAM in MPLS-TP) or  RFC 5921 (MPLS-TP Framework). AFAIK, the notion first appears in n the MPLS-TP OAM Framework draft (with a reference to ITU-T G.806), but, AFAIK, this document is in contention for quite some time; my personal impression from the Maastricht IETF that the chances to resolve this contention are not high. And IMHO and FWIW the very fact that 2+ years of effort of respected experts in the field did not yield consensus on MPLS-TP OAM FW does not bode well for the project.

Eric has written that, from the implementor's point of view "a meaningful definition is a condition I can detect and a mechanism to detect it". 

IMO there is more to a meaningful definition of a condition than ability to detect it and a suitable mechanism.

E.g., a condition defined as the average temperature of patients in a given hospital crossing being out of the configured range is 100% implementable, especially in a modern computerized hospital. But is it meaningful? 

This example is, of course a joke. But if you remember that some SD definitions suggested measuring packet loss across all traffic classes in a given LSP or section, it may be not so remote from the subject we are discussing...

Regards,
     Sasha

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 2:41 PM
To: Vivien Sterling; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp]答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Vivien-

EO#

And draft-zhl says

eric

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 Sep 2010 15:27:39 +0200

Vivien,
I’ve found your original message!

Regards,
     Sasha

From: Vivien Sterling [mailto:[email-masked]]
Sent: Wednesday, September 15, 2010 10:40 AM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Sasha,

I fail to agree with you on this point.
The requirements of MPLS-TP are defined by a group of experts (some are operators as well) who have spent more than 2 years on this. It is not wise to stop something by hasty decision saying "no clear definition" or "no solution".

--
Cheers,
Vivien

2010/9/14 Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Huub, and all,
I would just like to remind you that, so far, we have failed to agree on a meaningful definition of the SD condition in packet networks in general and in MPLS-TP in particular.

Regards,
    Sasha

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Huub van Helvoort
Sent: Tuesday, September 14, 2010 8:42 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hello Xuehui,

See also Figure 6 in:

Best regards, Huub.

[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Wed, 15 Sep 2010 09:49:22 -0400

Why not use RFC3469 definitions - usually the SD (LD and PD) is operator provisioned as input for switching and also what defines it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 15, 2010 9:20 AM
To: Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Eric, Vivien and all,

Vivien has written that:

Regards,
     Sasha

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 2:41 PM
To: Vivien Sterling; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp]答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Vivien-

EO#

And draft-zhl says

eric

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 Sep 2010 16:15:40 +0200

Deborah,
Lots of thanks for pointing to RFC 3469.

I've looked it up, and these are my findings and conclusions:
<quote>
   Path Degraded (PD) is a fault that indicates to MPLS-based recovery
   schemes/mechanisms that the path has connectivity, but that the
   quality of the connection is unacceptable.  This may be detected by a
   path performance monitoring mechanism, or some other mechanism for
   determining the error rate on the path or some portion of the path.
   This is local to the LSR and consists of excessive discarding of
   packets at an interface, either due to label mismatch or due to TTL
   errors, for example.
<end quote>

I do not see how this can be applied to an MPLS-TP entity (e.g., an LSP): in particular, both label mismatch
and TTL errors would (in the non-merging MPLS-TP environment) result in Path Failure (PF), not in Path Degradation.
And what seems to be completely missing here is the fact that path performance monitoring mechanisms would, most probably, measure the effects of congestion on the working path, and these would move to the protection path  after the switchover.

<quote>
   Link Degraded (LD) is an indication from a lower layer that the link
   over which the path is carried is performing below an acceptable
   level.  If the lower layer supports detection and reporting of this
   fault, it may be used by the MPLS recovery mechanism.  In some cases,
   using LD indications may provide faster fault detection than using
   only MPLS-based fault detection mechanisms.
<end quote>

As has been noted before, usefulness of this definition depends on specific links.
In particular, Ethernet LAN interfaces do not support SD detection. 

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 15, 2010 9:20 AM
To: Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Eric, Vivien and all,

Vivien has written that:

Regards,
     Sasha

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 2:41 PM
To: Vivien Sterling; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp]答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Vivien-

EO#

And draft-zhl says

eric

---

From: Eric Gray <[email-masked]>
Date: Wed, 15 Sep 2010 10:43:24 -0400

Sasha,

	There are a few problems with using label mismatch (in particular) to 
drive detection of Path Degradation.  In addition to the point you made about
the indications RFC 3469 lists would more probably indicate path failure, there
is also the fact that label mismatch would be hard to associate with a specific
LSP.

	The potential for moving congestion from the original path to the path
switched to by protection, depends a lot on how the network administrator -
or network operating policies/procedures and provisioning - allocates services
to paths.  Also, it depends - in at least those cases where service allocation to
paths is based on measured resource availability and some form of admission
control - a great deal on what causes the congestion.  For instance, if the fault
is predicated by a partial loss of resources on a path, then (it is to be hoped)
we can presume that this partial loss of resources would not also apply to the
alternate path.

	For LD, RFC 3469 specifically allows that this may not be supported.  
If it is not, then LD would not work for those specific links that do not support it.
But we then fall back to reliance on detecting PD (and subsequent diagnostic
efforts to isolate the link or links that caused the PD).

	If this is not good enough, then we can assume there will be some
incentives to switch to a lower-layer technology that does support LD, or to
improve the ability of lower-layer technology in use to support LD.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 15, 2010 10:16 AM
To: BRUNGARD, DEBORAH A (ATTLABS); Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Deborah,

<quote>

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 15, 2010 9:20 AM
To: Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Eric, Vivien and all,

Vivien has written that:

Regards,
     Sasha

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 2:41 PM
To: Vivien Sterling; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp]答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Vivien-

EO#

And draft-zhl says

eric

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 Sep 2010 18:08:51 +0200

Eric,
Lots of thanks for a prompt response.
I tend to agree with Adrian: People who think that SD is important, should come up with an explicit detailed definition and convince the unbelievers that this definition works (and under which explicit assumptions). I do not feel that RFC 3469 provides that.

Regards,
     Sasha

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 4:43 PM
To: Alexander Vainshtein; BRUNGARD, DEBORAH A (ATTLABS); Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: RE: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Sasha,

	For LD, RFC 3469 specifically allows that this may not be supported.[[[Sasha]]]   
If it is not, then LD would not work for those specific links that do not support it.
But we then fall back to reliance on detecting PD (and subsequent diagnostic
efforts to isolate the link or links that caused the PD).

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 15, 2010 10:16 AM
To: BRUNGARD, DEBORAH A (ATTLABS); Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Deborah,

<quote>

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 15, 2010 9:20 AM
To: Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Eric, Vivien and all,

Vivien has written that:

Regards,
     Sasha

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Wednesday, September 15, 2010 2:41 PM
To: Vivien Sterling; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp]答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Vivien-

EO#

And draft-zhl says

eric

---

From: [email-masked]
Date: Thu, 16 Sep 2010 10:57:52 +0800

Hi all，

How about this definition of SD condition: Loss rate of non-drop eligible 
packet > threshold

Drop eligible packets are allowed to discard when congestion occurs, so 
loss of drop eligible packets should not result in SD. CIR is a carrier's 
commitment to user, a good designed network should not discard non-drop 
packets in congestion condition, because some bandwidth is reserved for 
these packets, so whatever the cause of loss(fiber degrade, congestion…), 
 loss of non-drop eligible packet need to be take into account the SD 
state calculation.

I think SD and SF should have different priority since they have different 
effect on traffic.

I think that detecting SD base on server layer is feasible, in the case of 
ETH link, we can use 8b/10b or 64b/66b code to detect bit error, or can 
use FCS to detect frame error.

Regard,
Suhui

"Adrian Farrel" <[email-masked]> 
发件人:  [email-masked]
2010-09-15 21:16
请答复 给
Adrian Farrel <[email-masked]>

收件人
"Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" 
<[email-masked]>, "Alexander Vainshtein" 
<[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] More on SD

Surely it is a configurable policy question, just as the threshold at 
which 
SD might be notified (or acted on) is configurable. While we might give 
some 
examples or advice, and an implementation might be expected to act in a 
particular way out of the box, I would expect the questions you ask to be 
answered by the operator, not by the standards.

Cheers,
Adrian
----- Original Message ----- 

Adrian, hi

and accepting that SF is different than SD - the protection action for a 
single one of these conditions may be obvious - either go into an 
Unprotected state (if on the protection path) or Switch to Protecting 
state 
(if the condition is on the working path).  The real question is what 
happens if there are more than one condition, e.g. if there is an SD on 
the 
protection path followed by an SF on the working path, or each path 
reports 
SD - what is the value call on what path do we use?

Thanx for your insights,
yaacov

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

Of ext Adrian Farrel

Hi Sasha,

Agreed.

Mainly agreed.
The analog of what it is actually measuring will be absent.
The analog of "the signal has degraded" will still be useful for the 
purpose
of an application trying to understand the quality of data delivery.

In other words, IMHO, it is perfectly OK to define a mechanism to notify
switching points about SD, and it is OK to define the action that 
switching
point will take (e.g. switch).

>   on the proponents of SD:-).

Right. In other words, folk that think it is important and necessary need 
to
define it.

68%? ;-)

Adrian

Behalf
> networks are hard to draw. But that does not mean that the concept 
cannot
> be
>> I would just like to remind you that, so far, we have failed to agree 
on
>> a
>> E.g., the methods based on packet loss measurements have been shown to 
be
>> highly problematic because:
>> any analog in traditional transport networks (SONET/SDH, OTN) since 
there
>> is
i.e.,

--------------------------------------------------------
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: Thu, 16 Sep 2010 07:49:22 +0200

There is a very clear existing definition of SD in ITU-T recommendations; i.e. SD =  dDEG.

There is also a clear existing definition of dDEG in ITU-T recommendations; i.e. 
- for TDM signals:
The degraded signal defect (dDEG) shall be declared if DEGM consecutive bad intervals (interval is the 1-second period used for performance monitoring) are detected. An interval is declared bad if the percentage of detected errored blocks in that interval, or the number of errored blocks in that interval  degraded threshold (DEGTHR).
NOTE 1 – For the case of dDEG in the MSn layer, the errored block is equal to a BIP violation.
The degraded signal defect shall be cleared if DEGM consecutive good intervals are detected. An interval shall be declared good if the percentage of detected errored blocks in that interval, or the number of errored blocks in that interval  DEGTHR.
The parameter DEGM shall be provisionable in the range 2 to 10. 
The parameter DEGTHR shall be provisioned either as a percentage or as a number of errored blocks. When based on a percentage, it shall be in the range 0  DEGTHR  100%. When based on a number of errored blocks, it shall be in the range 0  DEGTHR  number of blocks in the interval.

- for Ethernet signals:
Every second the state machine receives the 1 second counters for far end received and transmitted frames and determines whether the second was a Bad Second. The defect is detected if there are MI_LM_DEGM consecutive Bad Seconds and cleared if there are MI_LM_M consecutive Good Seconds. 
In order to declare a Bad Second the number of transmitted frames must exceed a threshold (TF_MIN). If this is true then a Bad Second is declared if either the Frame Loss is negative (i.e. there are more frames received than transmitted) or the Frame Loss Ratio (lost frames/transmitted frames) is greater than MI_LM_DEGTHR.

- Default value of DEGM is 7 (see G.7710) and DEGTHR is SES threshold (see G.7710). 

- SES threshold is defined in the performance monitoring recommendations (e.g. G.826 for TDM and Y.1563 for Ethernet).

These SD and dDEG definitions will prevent that a protected service enters unavailable time (UAT is declared after 10 seconds) due to bit or packet loss.

When MPLS-TP carries Ethernet or TDM signals, MPLS-TP networks should be able to prevent that UAT is entered due to packet loss in a protected service connection. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 15 September 2010 12:15
To: [email-masked]
Subject: [mpls-tp] More on SD

Cheers,
Adrian

----- Original Message ----- 
From: "Vivien Sterling" <[email-masked]>
To: "Alexander Vainshtein" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 15, 2010 9:40 AM
Subject: Re: [mpls-tp]答复: RE: sd in 

Hi Sasha,

-- 

Cheers,
Vivien

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Sep 2010 07:50:46 +0200

Suhui,
You've written:
Loss rate of non-drop eligible packet > threshold
There are two problems with this definition:

 1.
Different TC in the same LSP or Section can yield different loss rates. While you can restrict usage of LSPs to a single traffic class (or explain that your definition only applies to this kind of LSPs), you will not be able to do the same for Sections IMO. And having a vector of SD conditions  for a single switchable entity looks problematic as a trigger for switching.
 2.
Loss rate depends on actual total traffic using a given resource (due to congestion). From what I see, one of the reasons the operators switch to packet network is oversubscription (including CIR oversubscription). So the fact that you did not experience packet loss on your standby entity before the switch does not in any way guarantee that you will not experience it there after the switch.

All this has been discussed on this list already. One way to go forward would be to explicitly define the scope applicability of this kind of definitions, because they are obviously not universal. Once we have these definitions of applicability, we should ask the operators whether such a scope makes any sense for them.

Regards,
     Sasha
________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, September 16, 2010 4:57 AM
To: Adrian Farrel
Cc: Alexander Vainshtein; [email-masked]; [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [mpls-tp] More on SD

Hi all，

How about this definition of SD condition: Loss rate of non-drop eligible packet > threshold

Drop eligible packets are allowed to discard when congestion occurs, so loss of drop eligible packets should not result in SD. CIR is a carrier's commitment to user, a good designed network should not discard non-drop packets in congestion condition, because some bandwidth is reserved for these packets, so whatever the cause of loss(fiber degrade, congestion…),  loss of non-drop eligible packet need to be take into account the SD state calculation.

I think SD and SF should have different priority since they have different effect on traffic.

I think that detecting SD base on server layer is feasible, in the case of ETH link, we can use 8b/10b or 64b/66b code to detect bit error, or can use FCS to detect frame error.

Regard,
Suhui

2010-09-15 21:16
请答复 给

收件人
        "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <[email-masked]>, "Alexander Vainshtein" <[email-masked]>
抄送
        [email-masked]
主题
        Re: [mpls-tp] More on SD

Cheers,
Adrian
----- Original Message -----

Adrian, hi

Thanx for your insights,
yaacov

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

Hi Sasha,

Agreed.

Mainly agreed.

68%? ;-)

Adrian

---

From: "Rafi Ram" <[email-masked]>
Date: Thu, 16 Sep 2010 09:18:48 +0200

Hi Suhui,

If the carrier would like to trigger SD protection when link bit error rate exceeds a certain threshold (e.g. 1E-9), then it impossible to map it to a threshold of number of lost non drop eligible packets.

The reason is that :

1.	The packets have variable length
2.	The packets rate varies
3.	Protection is required also for best effort traffic

I think that definition which is based on specific link properties (e.g. 8b/10b like you mentioned) is preferable.

Best regards,

Rafi

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, September 16, 2010 4:58 AM
To: Adrian Farrel
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] More on SD

Hi all， 

Regard, 
Suhui

---

From: Eric Gray <[email-masked]>
Date: Thu, 16 Sep 2010 05:31:02 -0400

Sasha,

        Your response is confusing and/or irrelevant to my comments.

        My comments were in response to the issues you seemed to have with
the terms Path Degradation and Link Degradation as defined in RFC 3469.

        While you mentioned SD in your last sentence, no part of my response
had anything to do with that sentence.

--
Eric

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, September 15, 2010 12:09 PM
To: Eric Gray
Cc: [email-masked]; Eric Osborne (eosborne); BRUNGARD, DEBORAH A (ATTLABS); Vivien Sterling
Subject: RE: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"
Importance: High

Eric,

Regards,
     Sasha

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Wednesday, September 15, 2010 4:43 PM
To: Alexander Vainshtein; BRUNGARD, DEBORAH A (ATTLABS); Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: RE: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Sasha,

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 15, 2010 10:16 AM
To: BRUNGARD, DEBORAH A (ATTLABS); Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Deborah,

<quote>

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 15, 2010 9:20 AM
To: Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Eric, Vivien and all,

Vivien has written that:

Regards,
     Sasha

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]]
Sent: Wednesday, September 15, 2010 2:41 PM
To: Vivien Sterling; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp]答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"

Hi Vivien-

EO#

And draft-zhl says

eric

---

From: Eric Gray <[email-masked]>
Date: Thu, 16 Sep 2010 05:52:27 -0400

Maarten,

        I don't think this is the sort of issue that should be resolved by using a
"majority rules" polling of service providers.

        If it might be important to some subset of potential customers that SD
is supported, then (IMO) standards need to define how this would be done.  It
then may be the case that implementors elect to either support or not support
this capability depending on their "read" of their own customer requirements.

        This is kind of a moot discussion (AFAICT) because the standards are
at least on the way to supporting the tools that would allow for detection of SD.
Assuming that a service provider can detect whatever their own definition of SD
is, then protection switching in the event that this is detected should be within
the capabilities of implementors to support.

--
Eric

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, September 16, 2010 1:27 AM
To: 'Alexander Vainshtein'; Eric Gray
Cc: [email-masked]
Subject: RE: [mpls-tp] 答复: RE: sd in "draft-ietf-mpls-tp-linear-protection-02.txt"
Importance: High

SD as protection switch condition was introduced to prevent that the service
enters unavailable time due to bit or packet loss. Unavailable time is a
condition in which the customer will get some refund of its service fee.

Y.1563 specifies the unavailable time definition for Ethernet services.
G.826 specifies the unavailable time definition for TDM services.

Customers of the MPLS-TP network will monitor their e.g. Ethernet or TDM
service performance and will include the detection of Ethernet frame loss or
TDM bit loss. Without a means to protect on a packet loss condition, MPLS-TP
operators will not be able to prevent the entering of UAT in a protected
Ethernet or TDM PW.

If this is acceptable to the operator community, then MPLS-TP does not have
to support SD as protection switching condition.
If this is unacceptable to the operator community, then MPLS-TP has to
specify a means to support SD as protection switching condition.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: 15 September 2010 18:09
To: Eric Gray
Cc: [email-masked]
Subject: Re: [mpls-tp] 答复: RE: sd in
"draft-ietf-mpls-tp-linear-protection-02.txt"

Eric,
Lots of thanks for a prompt response.
I tend to agree with Adrian: People who think that SD is important, should
come up with an explicit detailed definition and convince the unbelievers
that this definition works (and under which explicit assumptions). I do not
feel that RFC 3469 provides that.

Regards,
     Sasha

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Wednesday, September 15, 2010 4:43 PM
To: Alexander Vainshtein; BRUNGARD, DEBORAH A (ATTLABS); Eric Osborne
(eosborne); Vivien Sterling
Cc: [email-masked]
Subject: RE: [mpls-tp] 答复: RE: sd in
"draft-ietf-mpls-tp-linear-protection-02.txt"

Sasha,

        There are a few problems with using label mismatch (in particular)
to
drive detection of Path Degradation.  In addition to the point you made
about
the indications RFC 3469 lists would more probably indicate path failure,
there
is also the fact that label mismatch would be hard to associate with a
specific
LSP.

        The potential for moving congestion from the original path to the
path
switched to by protection, depends a lot on how the network administrator -
or network operating policies/procedures and provisioning - allocates
services
to paths.  Also, it depends - in at least those cases where service
allocation to
paths is based on measured resource availability and some form of admission
control - a great deal on what causes the congestion.  For instance, if the
fault
is predicated by a partial loss of resources on a path, then (it is to be
hoped)
we can presume that this partial loss of resources would not also apply to
the
alternate path.

        For LD, RFC 3469 specifically allows that this may not be supported.
[[[Sasha]]]
If it is not, then LD would not work for those specific links that do not
support it.
But we then fall back to reliance on detecting PD (and subsequent diagnostic
efforts to isolate the link or links that caused the PD).

--
Eric

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

Deborah,

I do not see how this can be applied to an MPLS-TP entity (e.g., an LSP): in
particular, both label mismatch
and TTL errors would (in the non-merging MPLS-TP environment) result in Path
Failure (PF), not in Path Degradation.
And what seems to be completely missing here is the fact that path
performance monitoring mechanisms would, most probably, measure the effects
of congestion on the working path, and these would move to the protection
path  after the switchover.

<quote>

As has been noted before, usefulness of this definition depends on specific
links.
In particular, Ethernet LAN interfaces do not support SD detection.

Regards,
     Sasha

-----Original Message-----
From: BRUNGARD, DEBORAH A (ATTLABS) [mailto:[email-masked]]
Sent: Wednesday, September 15, 2010 3:49 PM
To: Alexander Vainshtein; Eric Osborne (eosborne); Vivien Sterling
Cc: [email-masked]
Subject: RE: [mpls-tp] 答复: RE: sd in

Why not use RFC3469 definitions - usually the SD (LD and PD) is operator
provisioned as input for switching and also what defines it.

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

Eric, Vivien and all,

First of all Vivien's message somehow did not reach me, just Eric's
response.
So I will provide some comments on both of them in a single email.

Vivien has written that:

        "The requirements of MPLS-TP are defined by a group of experts (some
are
        operators as well) who have spent more than 2 years on this".

This is correct. However, SD is not even mentioned in RFC 5654 (MPLS-TP
Requirements), RFC 5860 (Requirements for OAM in MPLS-TP) or  RFC 5921
(MPLS-TP Framework). AFAIK, the notion first appears in n the MPLS-TP OAM
Framework draft (with a reference to ITU-T G.806), but, AFAIK, this document
is in contention for quite some time; my personal impression from the
Maastricht IETF that the chances to resolve this contention are not high.
And IMHO and FWIW the very fact that 2+ years of effort of respected experts
in the field did not yield consensus on MPLS-TP OAM FW does not bode well
for the project.

Eric has written that, from the implementor's point of view "a meaningful
definition is a condition I can detect and a mechanism to detect it".

IMO there is more to a meaningful definition of a condition than ability to
detect it and a suitable mechanism.

E.g., a condition defined as the average temperature of patients in a given
hospital crossing being out of the configured range is 100% implementable,
especially in a modern computerized hospital. But is it meaningful?

This example is, of course a joke. But if you remember that some SD
definitions suggested measuring packet loss across all traffic classes in a
given LSP or section, it may be not so remote from the subject we are
discussing...

Regards,
     Sasha

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]]
Sent: Wednesday, September 15, 2010 2:41 PM
To: Vivien Sterling; Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp]答复: RE: sd in

Hi Vivien-

  Sasha's point with which you disagree is
"[...] so far, we have failed to agree on a meaningful definition of the SD
condition in packet networks in general and in MPLS-TP in particular."

I think part of this hinges around what a 'meaningful definition' is.  As an
implementor, a meaningful definition is a condition I can detect and a
mechanism to detect it.  If I have an RFC in hand that purports to define SD
but doesn't tell me how to do so in sufficient detail that I can write code,
it's not meaningful.

> http://www.ietf.org/id/draft-ietf-mpls-tp-linear-protection-02.txt

EO#  This draft contains no definition of SD.  Version -02 contains some
text that describes how to communicate SD to a far end should SD be
detected, but nothing further; the pending version -03 may remove this text.

> http://www.ietf.org/id/draft-zulr-mpls-tp-linear-protection-switching

EO#  This is very similar to draft-ietf-mpls-tp-linear-protection in that it
contains a method for communicating SD but no useful means to detect it.

> http://datatracker.ietf.org/doc/draft-rkhd-mpls-tp-sd/

EO#  This draft contains requirements for a definition of SD, but there's
nothing there that is implementable without further details.  I think it may
be a reasonable start for the concise definition Adrian requested in the
"More on SD" thread, but there's nothing in draft-zulr that gives me a
packet format or a state machine or any other such things.

> http://tools.ietf.org/id/draft-zhl-mpls-tp-sd-02.txt  (expired)

EO#
This draft is the closest of the four to providing a definition of something
that could be implemented (section 4.1.1).  However, it seems to clash with
what the mailing list agrees is the rough definition of SD.  From Adrian's
mail in the other thread:

" SF is defined by the failure of a particular OAM packet to get through
(regardless of whether all of the data is getting through!). SD is defined
as the failure of (some percentage of) data packets to get through."

And draft-zhl says

If SD were to be defined as "a loss of some but not all OAM packets within a
given time window at a specific rate" then draft-zhl may be a useful start,
but as that appears to not be the rough consensus definition of SD,
draft-zhl is out of date.

eric

---

From: Vivien Sterling <[email-masked]>
Date: Thu, 16 Sep 2010 23:05:07 +0800

Hi Eric,

Thanks for your kindly response and analysis for the drafts which I have
listed below.
IMHO packet loss and packet delay can be regarded as the factors of SD
condition and operators can make arbitrary combination of the factors as the
trigger of SD and set thresholds.

More comments inline.

Thanks!

---
Cheers,
Vivien

2010/9/15 Eric Osborne (eosborne) <[email-masked]>

> I think part of this hinges around what a 'meaningful definition' is.  As
> an implementor, a meaningful definition is a condition I can detect and a
> EO#  This is very similar to draft-ietf-mpls-tp-linear-protection in that
> it contains a method for communicating SD but no useful means to detect it.

> "More on SD" thread,

[Vivien]: Actually I have concerns about using PHY bit error rate to
indicate LSP SD described in draft-rkhd.

> but there's nothing in draft-zulr that gives me a packet format or a state
> machine or any other such things.
>

[Vivien]: I agree.

> This draft is the closest of the four to providing a definition of
> something that could be implemented (section 4.1.1).  However, it seems to
> clash with what the mailing list agrees is the rough definition of SD.  From
> Adrian's mail in the other thread:
>
> If SD were to be defined as "a loss of some but not all OAM packets within
> a given time window at a specific rate" then draft-zhl may be a useful
> start, but as that appears to not be the rough consensus definition of SD,
> [Vivien]: Pity draft-zhl expired but it looks to me a reasonable start for
> SD work.

---

From: [email-masked]
Date: Sun, 19 Sep 2010 17:26:25 +0800

Hi Sasha,
Please see inline...

Alexander Vainshtein <[email-masked]> 
2010-09-16 13:50

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" 
<[email-masked]>, Adrian Farrel <[email-masked]>
主题
RE: [mpls-tp] More on SD

Suhui,
You've written:
Loss rate of non-drop eligible packet > threshold 
There are two problems with this definition:
1.      Different TC in the same LSP or Section can yield different loss 
rates. While you can restrict usage of LSPs to a single traffic class (or 
explain that your definition only applies to this kind of LSPs), you will 
not be able to do the same for Sections IMO. And having a vector of SD 
conditions  for a single switchable entity looks problematic as a trigger 
for switching. 

[SH]I think we can monitor multiple TC’s performances by sending multiple 
LM packets simultaneously. If only one TC can be monitored, but operator 
want more than one TC to trig protection, I think operator can choose the 
lowest priority TC to monitor, because in most case when a higher priority 
traffic is in SD condition, the lower priority traffic will be in SD 
condition too. From the view of statistics, errors on link have the same 
effect to all TC which pass this link, so I think only monitoring one TC 
is enough for link error.

2.      Loss rate depends on actual total traffic using a given resource 
(due to congestion). From what I see, one of the reasons the operators 
switch to packet network is oversubscription (including CIR 
oversubscription). So the fact that you did not experience packet loss on 
your standby entity before the switch does not in any way guarantee that 
you will not experience it there after the switch.

[SH]CIR can be overbooked? I think it is not a requirement of transport 
network, can some carrier people clarify this?

All this has been discussed on this list already. One way to go forward 
would be to explicitly define the scope applicability of this kind of 
definitions, because they are obviously not universal. Once we have these 
definitions of applicability, we should ask the operators whether such a 
scope makes any sense for them.
 
Regards,
     Sasha
From: [email-masked] [[email-masked]]
Sent: Thursday, September 16, 2010 4:57 AM
To: Adrian Farrel
Cc: Alexander Vainshtein; [email-masked]; [email-masked]; 
Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [mpls-tp] More on SD

Hi all， 

Regard, 
Suhui 

.

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 19 Sep 2010 11:51:21 +0200

Hi Suhui,

I am not sure that monitoring the loss rate for one selected TC will yield any information on the other classes.
This depends on many factors including actual distribution of traffic within each class and between the classes. E.g., if the main reson for the drop is bit errors with Poisson distribution (I do not know whether this is a realsitic assumption, but let’s take it as an example for the time being), then long packets will be dropped more frequently than short ones. So if your high priority TC carries mainly short packets (CES, VoIP etc.) while your low priority TC carries mainly long packets (Internet access), the  picture will be skewed...

IMHO the ability to monitor SD in the classic (TDM, SONET/SDH) transport networks stands on the following “three whales”:

・         Just one TC

・         Fixed size blocks for monitoring errors (see ITU-T G.826)

・         The server layer errors do not depend on the client traffic.  This “whale” has been compromized at least once when RFC 1619<ftp://ftp.rfc-editor.org/in-notes/rfc1619.txt> intoroduced PoS without Path Payload scrambling. This resulted in falce SONET/SDH frame alignment. Eventually, this has been fixed with RFC 2561<ftp://ftp.rfc-editor.org/in-notes/rfc2615.txt>.
Please note that none of these holds for packet networks.

As for oversubscribing CIR: it depends, IMO, on a specific transport operator. There is no law of nature (nor, AFAIK, administrative regulation) explicitly prohibiting that, so it is most probably a matter ofbusiness considerations translated into a specific policy.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, September 19, 2010 11:26 AM
To: Alexander Vainshtein
Cc: Adrian Farrel; [email-masked]; [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: 答复: RE: [mpls-tp] More on SD

Hi Sasha,
Please see inline...

2010-09-16 13:50

收件人

抄送

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>, Adrian Farrel <[email-masked]>

主题

RE: [mpls-tp] More on SD

Suhui,
You've written:
Loss rate of non-drop eligible packet > threshold
There are two problems with this definition:
1.        Different TC in the same LSP or Section can yield different loss rates. While you can restrict usage of LSPs to a single traffic class (or explain that your definition only applies to this kind of LSPs), you will not be able to do the same for Sections IMO. And having a vector of SD conditions  for a single switchable entity looks problematic as a trigger for switching.

[SH]I think we can monitor multiple TC’s performances by sending multiple LM packets simultaneously. If only one TC can be monitored, but operator want more than one TC to trig protection, I think operator can choose the lowest priority TC to monitor, because in most case when a higher priority traffic is in SD condition, the lower priority traffic will be in SD condition too. From the view of statistics, errors on link have the same effect to all TC which pass this link, so I think only monitoring one TC is enough for link error.

2.        Loss rate depends on actual total traffic using a given resource (due to congestion). From what I see, one of the reasons the operators switch to packet network is oversubscription (including CIR oversubscription). So the fact that you did not experience packet loss on your standby entity before the switch does not in any way guarantee that you will not experience it there after the switch.

[SH]CIR can be overbooked? I think it is not a requirement of transport network, can some carrier people clarify this?

Regards,
     Sasha

Hi all，

Regard,
Suhui

.

---

From: <[email-masked]>
Date: Sun, 19 Sep 2010 12:47:56 +0100

There seems little point worrying about SD if one has not got a proper transparent transport network as a starting point.....so to make the key points one more time:
 
-    A transport network must be able to provide a *transparent* transport service to its clients...if it cannot do this then do not call it a transport network, call it something else.
 
-    Transparency requires that each client symbol (where a 'bit' is the atomic unit of information and client symbols are created from groups of bits) must be treated equally, and a key corollary of which is that client symbol ordering must be preserved and thus a connection (see below) must only have a single 'traffic class'.  This also implies there must be no attempts by the server to infer meaning of client symbols and/or change them...an absolutely vital requirement for a transport network.
 
-    Two important 'degrees of isolation' follow from the above for a transport network:
    o reachability isolation between different clients, and a client and its server...this implies we must have a proper client/server relationship
    o performance isolation between different clients, ie the traffic behaviour of client X cannot impact the SLA enjoyed by client Y....this implies:    
    * we must only use proper (ie single source) connections - this is a necessary condition
    * we must not overbook resource - this is a full sufficiency condition (but see Note)
 
Note - All the above are default behaviours in the co-cs mode but must be consciously engineered in the co-ps mode.  One can in principle relax the latter resource overbooking requirement to varying degrees......but once you start on this slippery slope its not really viable to claim one has a transparent transport network any longer.  Violate any of the prior requirements and one most definitely does not have a transparent transport network.
 
To conclude....the current MPLS-TP specification does not meet the above.  So as I have said before, we should no longer claim MPLS-TP is a transport network. 
 
BTW - The above are simply technical facts and not opinions.  Though one should also put oneself in the position of a customer who wants to build his/her own client layer N network when considering what behaviour one wants from a layer N-1 server transport network supplier.

regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
	Sent: 19 September 2010 10:51
	To: [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] More on SD

	Hi Suhui,

	·         Just one TC

	·         Fixed size blocks for monitoring errors (see ITU-T G.826)

	·         The server layer errors do not depend on the client traffic.  This “whale” has been compromized at least once when RFC 1619 <ftp://ftp.rfc-editor.org/in-notes/rfc1619.txt>  intoroduced PoS without Path Payload scrambling. This resulted in falce SONET/SDH frame alignment. Eventually, this has been fixed with RFC 2561 <ftp://ftp.rfc-editor.org/in-notes/rfc2615.txt> .

	Regards,

	     Sasha

	
	Hi Sasha, 
	Please see inline... 

	2010-09-16 13:50 

			收件人

	抄送

	主题

		RE: [mpls-tp] More on SD

	

	Suhui, 
	You've written: 

	

	Regards, 
	     Sasha 

	Hi all， 

	

	Regard, 
	Suhui 

	
	
	.

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 23 Sep 2010 11:19:27 +0200

Eric,

There are network operators that require detection of SD and triggering of
protection switching after detection of SD. Nonetheless the debate of how to
detect a packet SD condition, we have to support SD as a trigger condition
in MPLS-TP protection switching standard. If such SD trigger in protection
switching is supported in a specific MPLS-TP equipment is a decision of the
manufacturer as you indicate.

Regards,
Maarten

> Sent: 16 September 2010 11:52
> To: Maarten Vissers
> Cc: [email-masked]