Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 Jul 2011 11:08:00 -0700

Dear Authors and All,
I think that it is function of the PHY layer to detect SD condition and
convert it into Down for the MPLS-TP Layer 0 (what we refer as Physical
Section). In case of accumulating SD over LSP the e2e Packet Loss
measurement, in my view, is addressing the issue.

Regards,
Greg

---

From: "Daniel Cohn" <[email-masked]>
Date: Wed, 27 Jul 2011 21:21:59 +0300

Greg and all,

The view of the authors is that you cannot rely on traffic (OAM or else)
to detect error condition, because of:

-          Implicit sampling bias - OAM messages are not an unbiased
sample of all traffic, e.g. they have a specific (typically short)
length, transmission periodicity, etc.

-          Traffic can be affected by congestion or other non-physical
error conditions

That's why we don't think we should leave accumulated error detection to
the transport path layer.

Regards,

Daniel

From: Greg Mirsky [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 2:08 PM
To: Daniel Cohn; Rafi Ram; [email-masked]; [email-masked];
[email-masked]; D'Alessandro Alessandro Gerardo; [email-masked]
Subject: Comments to draft-rkhd-mpls-tp-sd-03

Dear Authors and All,

Regards,
Greg

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 28 Jul 2011 10:12:23 -0500

Hi Greg-
  There is a difference between SF and SD.  Converting SD into Down
means that it will be interpreted exactly the same as SF, and if that's
the case why have SD at all?  If SD is necessary it must be somehow
different from SD.

All-

  Having said that, I'm not sure I disagree with Greg.  It seems that
this idea of propagating server layer SD up into TP is being done
because there's no good way to do SD entirely within the TP layer.  I
suspect that if there were a way to do SD within the TP layer that made
everyone happy, we wouldn't have the approach propsed in
draft-rkhd-mpls-tp-sd.  And I think that if the motivation for this
draft is:

  - we must have SD in TP because it is possible to do in other
technologies
  - it is not possible to SD entirely within TP
  - therefore we must get SD from somewhere else

is a reasonable one.  If we do that, where do we stop?  Should we
propagate information about signal quality up to TCP so it can adjust
its windows according?  (please note that this is intended to be a
reductio ad absurdum question and not a serious one. :) )

eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Greg Mirsky
> To: Daniel Cohn; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; D'Alessandro Alessandro
> Gerardo; [email-masked]
> Subject: [mpls] Comments to draft-rkhd-mpls-tp-sd-03
> 
> Dear Authors and All,

---

From: David Allan I <[email-masked]>
Date: Thu, 28 Jul 2011 12:49:23 -0400

IMO SD criteria has technology specific characteristics for each PHY that carriers MPLS. Punting/exposing it into the MPLS layer is a mistake as we will need to keep revisiting the definition for different PHY types. 

I don't think we want to continuously run MPLS layer PM on every section either in order to stunt double for and/or supercede the functionality of the server layer.

My 2 cents
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Thursday, July 28, 2011 11:12 AM
To: Greg Mirsky; Daniel Cohn; [email-masked]; [email-masked]; [email-masked]; [email-masked]; D'Alessandro Alessandro Gerardo; [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Greg-
  There is a difference between SF and SD.  Converting SD into Down means that it will be interpreted exactly the same as SF, and if that's the case why have SD at all?  If SD is necessary it must be somehow different from SD.

All-

  Having said that, I'm not sure I disagree with Greg.  It seems that this idea of propagating server layer SD up into TP is being done because there's no good way to do SD entirely within the TP layer.  I suspect that if there were a way to do SD within the TP layer that made everyone happy, we wouldn't have the approach propsed in draft-rkhd-mpls-tp-sd.  And I think that if the motivation for this draft is:

  - we must have SD in TP because it is possible to do in other technologies
  - it is not possible to SD entirely within TP
  - therefore we must get SD from somewhere else

is a reasonable one.  If we do that, where do we stop?  Should we propagate information about signal quality up to TCP so it can adjust its windows according?  (please note that this is intended to be a reductio ad absurdum question and not a serious one. :) )

eric

Of
> measurement, in my view, is addressing the issue.

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

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 28 Jul 2011 19:51:45 +0300

Hi Eric,

One of the reasons why we need SD in TP is because TP is supposed to
provide the same "look and feel" of existing transport networks, as
specified in the TP requirements document.
Transport networks technologies have long supported the distinction
between "degraded" and " faulty". In particular, protection technologies
in use have this distinction built into the innermost recedes of their
protocols. 
Even in the TP requirements didn't spell this out, I think it would be a
mistake not to take advantage of years of experience in transport
networks OAM.

Regards,

Daniel

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 11:12 AM
To: Greg Mirsky; Daniel Cohn; Rafi Ram; [email-masked];
[email-masked]; [email-masked]; D'Alessandro Alessandro
Gerardo; [email-masked]
Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Greg-

All-

eric

Of

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 28 Jul 2011 10:00:14 -0700

Hi Daniel,
I think that while we're building MPLS-TP to be suited for the
transport we need to remember that it, as Neil pointed out on number
of occasions, is not BOS layer and doesn't put bits on a wire. Thus it
has characteristic that makes it different from other layers of a
transport network and, I think, as result not all existing concepts of
transport are applicable to packet layer realized by MPLS-TP.

Regards,
Greg

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 28 Jul 2011 20:15:07 +0300

True enough in general. But in this particular example, there is nothing suggested by this draft that requires huge implementation efforts or paradigm changes. So I fail to see why we should settle for less functionality than is available in existing transport networks.

DC 

-----Original Message-----
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 1:00 PM
To: Daniel Cohn
Cc: Eric Osborne (eosborne); Rafi Ram; [email-masked]; [email-masked]; [email-masked]; D'Alessandro Alessandro Gerardo; [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Daniel,

Regards,
Greg

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 28 Jul 2011 13:04:58 -0500

I don't quite buy "settle for less functionality".  The point I made in my last email is that the SD functionality you want just isn't *relevant* to MPLS.  The concept of degradation at the packet level is pretty slippery.  There've been ECN-type proposals over the years, but they never went anywhere and certainly don't exist in MPLS.  If we had ECN in MPLS then I would agree that it could be mapped to SD in some fashion, but we don't.  Deciding that you need an unapplicable technology and then shoehorning something else into acting as a substitute is, IMO, a mistake.

eric

> From: Daniel Cohn [mailto:[email-masked]]
> Sent: Thursday, July 28, 2011 1:15 PM
> To: Greg Mirsky
> Cc: Eric Osborne (eosborne); Rafi Ram; [email-masked];
> True enough in general. But in this particular example, there is nothing
> suggested by this draft that requires huge implementation efforts or
> paradigm changes. So I fail to see why we should settle for less
> functionality than is available in existing transport networks.
> 
> DC
> 
> Cc: Eric Osborne (eosborne); Rafi Ram; [email-masked];
> I think that while we're building MPLS-TP to be suited for the transport
> we need to remember that it, as Neil pointed out on number of occasions,
> is not BOS layer and doesn't put bits on a wire. Thus it has
> characteristic that makes it different from other layers of a transport
> network and, I think, as result not all existing concepts of transport are
> applicable to packet layer realized by MPLS-TP.
> 
> Regards,
> Greg
> 
> > between "degraded" and " faulty". In particular, protection
> > technologies in use have this distinction built into the innermost
> > recedes of their protocols.
> > Even in the TP requirements didn't spell this out, I think it would be
> > a mistake not to take advantage of years of experience in transport
> > networks OAM.
> >
> > Regards,
> >
> > Daniel
> >
> > means that it will be interpreted exactly the same as SF, and if
> > that's the case why have SD at all?  If SD is necessary it must be
> > somehow different from SD.
> >
> > All-
> >
> > suspect that if there were a way to do SD within the TP layer that
> > made everyone happy, we wouldn't have the approach propsed in

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 28 Jul 2011 21:11:21 +0300

Eric,

I believe degradation is relevant to any technology where errors can occur (i.e. all kinds). ECN reports congestion which is completely orthogonal to the physical error condition we want to detect and correct via SD detection and report. So I don’t think ECN-like proposals are relevant to the discussion.

DC

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 2:05 PM
To: Daniel Cohn; Greg Mirsky
Cc: Rafi Ram; [email-masked]; [email-masked]; [email-masked]; D'Alessandro Alessandro Gerardo; [email-masked]
Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

eric

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 28 Jul 2011 13:21:37 -0500

My point with ECN is that you need some sort of SD-detecting thingy at the MPLS level in order to have SD in MPLS.  The only 'degradation' I can think of at the packet level is sporadic loss for a reason *not* due to underlying transport issues, as that's handled by the server layer.  And the only reason for these drops that comes to mind is for QoS during congestion.  So I used ECN to mean "if you have packet drops which originate at the TP layer, ECN==1 else ECN==0".  I may have confused the issue by oversimpifying with ECN, I hope this clears it up.

eric

> Sent: Thursday, July 28, 2011 2:11 PM
> To: Eric Osborne (eosborne); Greg Mirsky
> Cc: Rafi Ram; [email-masked]; [email-masked];
> I believe degradation is relevant to any technology where errors can occur
> (i.e. all kinds). ECN reports congestion which is completely orthogonal to
> the physical error condition we want to detect and correct via SD
> detection and report. So I don't think ECN-like proposals are relevant to
> the discussion.
> 
> DC
> 
> Cc: Rafi Ram; [email-masked]; [email-masked];
> I don't quite buy "settle for less functionality".  The point I made in my
> last email is that the SD functionality you want just isn't *relevant* to
> MPLS.  The concept of degradation at the packet level is pretty slippery.
> There've been ECN-type proposals over the years, but they never went
> anywhere and certainly don't exist in MPLS.  If we had ECN in MPLS then I
> would agree that it could be mapped to SD in some fashion, but we don't.
> Deciding that you need an unapplicable technology and then shoehorning
> something else into acting as a substitute is, IMO, a mistake.
> 
> 
> 
> eric
> 
> > True enough in general. But in this particular example, there is
> > nothing suggested by this draft that requires huge implementation
> > efforts or paradigm changes. So I fail to see why we should settle for
> > less functionality than is available in existing transport networks.
> >
> > DC
> >
> > > Even in the TP requirements didn't spell this out, I think it would
> > > be a mistake not to take advantage of years of experience in
> > > transport networks OAM.
> > >
> > > Regards,
> > >
> > > Daniel
> > >
> > > because there's no good way to do SD entirely within the TP layer.
> > > I suspect that if there were a way to do SD within the TP layer that
> > > propagate information about signal quality up to TCP so it can
> > > adjust its windows according?  (please note that this is intended to
> > > be a reductio ad absurdum question and not a serious one. :) )
> > >
> > >
> > >
> > > eric
> > >
> > >> [email-masked]; [email-masked]; D'Alessandro
> > >> Alessandro Gerardo; [email-masked]

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 28 Jul 2011 21:29:32 +0300

But what the SD draft specifies is that the SD condition should be *detected* at the server layer, and *reported* at the MPLS layer. The MPLS layer can use this SD report as a trigger to protection schemes, as specified in the linear protection draft.
Congestion reports are already covered by MPLS OAM tools such as packet loss (LM).
The SD drafts draws a clear distinction between physical and non-physical errors. 

Daniel

-----Original Message-----
From: Eric Osborne (eosborne) [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 2:22 PM
To: Daniel Cohn; Greg Mirsky
Cc: Rafi Ram; [email-masked]; [email-masked]; [email-masked]; D'Alessandro Alessandro Gerardo; [email-masked]
Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

eric

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 28 Jul 2011 21:34:03 +0300

You can make the same argument about SF - should be handled in the server layer. Yet I see no discussion on whether MPLS-TP needs SF reporting.
The server layer cannot always overcome error conditions. A TP protection scheme should be able to overcome it by switching to an error-free path. Isn't this something we can all agree to?

DC

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 2:30 PM
To: Daniel Cohn; Greg Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; Rafi Ram
Subject: RE: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi,

I also don't believe SD is needed for MPLS-TP. Such defect is not related to MPLS-TP and should be handled in the server layer, such as changing the FEC type in OTN, etc.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Thursday, July 28, 2011 10:15 AM
To: Greg Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; Rafi Ram
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

DC 

-----Original Message-----
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 1:00 PM
To: Daniel Cohn
Cc: Eric Osborne (eosborne); Rafi Ram; [email-masked]; [email-masked]; [email-masked]; D'Alessandro Alessandro Gerardo; [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Daniel,

Regards,
Greg

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 28 Jul 2011 11:30:06 -0700

Hi,

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Thursday, July 28, 2011 10:15 AM
To: Greg Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; Rafi Ram
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

DC 

-----Original Message-----
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 1:00 PM
To: Daniel Cohn
Cc: Eric Osborne (eosborne); Rafi Ram; [email-masked]; [email-masked]; [email-masked]; D'Alessandro Alessandro Gerardo; [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Daniel,

Regards,
Greg

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 28 Jul 2011 14:41:19 -0400

I agree with Eric, Shahram and actually richard kam (alcatel/lucent) made this exact point at the mike
during presentation.

/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Thursday, July 28, 2011 2:30 PM
To: Daniel Cohn; Greg Mirsky
Cc: Rafi Ram; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi,

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Cohn
Sent: Thursday, July 28, 2011 10:15 AM
To: Greg Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; Rafi Ram
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

DC

-----Original Message-----
From: Greg Mirsky [mailto:[email-masked]]
Sent: Thursday, July 28, 2011 1:00 PM
To: Daniel Cohn
Cc: Eric Osborne (eosborne); Rafi Ram; [email-masked]; [email-masked]; [email-masked]; D'Alessandro Alessandro Gerardo; [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Daniel,

Regards,
Greg

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 28 Jul 2011 11:48:08 -0700

Agree with others. Don't think we should be handling this at mpls-TP but should be handled at server layer.

Cheers
Sam

Sent from my iPad

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 28 Jul 2011 15:04:42 -0400

Also, if we were to propagate to Tp, why stop there? It should be propagated to PW as well, right?

Sam

Sent from my iPhone

---

From: Pablo Frank <[email-masked]>
Date: Thu, 28 Jul 2011 15:30:38 -0400

I agree that there is no defined way to detect "degradation" in an LSP or
PW.  LM/DM is the closest thing that could measure something approximating
"degradation" but several have already indicated that they don't want to use
LM/DM for this purpose.  The problem is that both the Survivability
framework and the Linear Protection draft expect us to handle "degraded"
transport paths.  Well, if we're not interested in server-layer indications
of degradation (as Daniel has proposed) and we're not interested in OAM
providing some sort of degradation, then there is no way for us have
"degraded" transport paths.  Either we agree on what a degraded transport
path means or we should delete it from the various documents that mention
it.

Pablo

On Thu, Jul 28, 2011 at 2:21 PM, Eric Osborne (eosborne) <[email-masked]
> wrote:

> My point with ECN is that you need some sort of SD-detecting thingy at the
> MPLS level in order to have SD in MPLS.  The only 'degradation' I can think
> of at the packet level is sporadic loss for a reason *not* due to underlying
> transport issues, as that's handled by the server layer.  And the only
> reason for these drops that comes to mind is for QoS during congestion.  So
> I used ECN to mean "if you have packet drops which originate at the TP
> layer, ECN==1 else ECN==0".  I may have confused the issue by oversimpifying
> with ECN, I hope this clears it up.
>
>
>
> eric
>
>

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 28 Jul 2011 22:50:47 +0300

Right - that's why the SD draft refers to "transport path" rather than
to LSP. 
This is in line with draft-ietf-mpls-tp-fault-05, "Fault OAM messages
are applicable to Bidirectional Co-Routed LSPs and to Multi-Segment
Pseudowires (MS-PW)"

DC

-----Original Message-----
From: Sam Aldrin [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 3:05 PM
To: Shah, Himanshu
Cc: Shahram Davari; Daniel Cohn; Greg Mirsky; Rafi Ram;
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Also, if we were to propagate to Tp, why stop there? It should be
propagated to PW as well, right?

Sam

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shahram Davari
> I also don't believe SD is needed for MPLS-TP. Such defect is not
related to MPLS-TP and should be handled in the server layer, such as
changing the FEC type in OTN, etc.
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daniel Cohn
technologies
>> Even in the TP requirements didn't spell this out, I think it would
be a
>> means that it will be interpreted exactly the same as SF, and if
that's
>> suspect that if there were a way to do SD within the TP layer that
made

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 28 Jul 2011 22:12:15 +0200

And propagate to the VC12 carried By the PW?
and...

Huub

> On Jul 28, 2011, at 2:41 PM, "Shah, Himanshu"<[email-masked]>  wrote:
>
>> On Thu, Jul 28, 2011 at 9:51 AM, Daniel Cohn<[email-masked]>  wrote:
>>> Hi Eric,
>>>

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 28 Jul 2011 23:16:47 +0300

I don't think sending iterative e-mails referring to ever higher layer
serves the point of this discussion. A similar argument can be made on
e.g. other technologies sending AIS-like indications on all client
layers.
I think we should focus on what Pablo wrote, i.e. do we want to provide
SD to MPLS layers, like existing transport networks, or not? And if we
do, what is the best way to do it?

DC

PS: No need to, the VC12 has its own SD detection capabilities.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Huub van Helvoort
Sent: Thursday, July 28, 2011 4:12 PM
To: [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Huub

Of Shahram Davari
Of Daniel Cohn
technologies
be a
that's
>>> because there's no good way to do SD entirely within the TP layer.
I
made
>>> propagate information about signal quality up to TCP so it can
adjust
>>>> [email-masked]; [email-masked]; D'Alessandro
Alessandro

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 28 Jul 2011 22:31:50 +0200

Hi Daniel Cohn

You wrote:

> serves the point of this discussion.

OK, ---8<---snipped

> PS: No need to, the VC12 has its own SD detection capabilities.

So why don't we define SD (service degrade) defect detection criteria
for MPLS-TP?
In stead of relying on SD (signal degrade) defect detect mechanisms in
other technologies.

BR, Huub.

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 28 Jul 2011 23:36:49 +0300

Hi Huub,

Can propose a TP-based detection method that can detect only physical
errors, i.e. without being influenced by non-physical conditions such as
congestion, CPU overload, etc.?
If you can, by all means do so, it would greatly serve the purpose of
this discussion.

Thanks,

Daniel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Huub van Helvoort
Sent: Thursday, July 28, 2011 4:32 PM
To: [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Daniel Cohn

OK, ---8<---snipped

BR, Huub.

Of
Alessandro
>>>>> I think that it is function of the PHY layer to detect SD
condition
>>>> and

---

From: <[email-masked]>
Date: Thu, 28 Jul 2011 21:37:46 +0100

Daniel Cohn wrote 28 July 2011 21:17

> serves the point of this discussion. 

NH=> I thinks Huub's mail makes the point excellently..as have other before him.  

The general principle is that we should not be functionally coupling different layer networks....so in the case of OAM we should not be indicating upwards or (even worse) downwards specific OAM messages between pairs of layer networks...each layer should be indepedent.

The reality sadly is that we are not very good at doing this, eg "access circuit" (sic) <=> PW defect OAM mappings is about as wrong as you can get it.

However the principle of layer independence is correct.  Indeed 'IP over everything' is based on the requirement for strict adherence to this layer indepedence principle (to protect IP).

The 'common CP myth' is yet another example of where have gone wrong in trying to couple different layer networks....and it plain does not work.

> A similar argument can be made on

NH=> Careful.  AIS is very bad idea for all pkt-based layer networks.  It is only forced when we have regular-time slices of resource as in the co-cs TDM layer networks and where we must fill the resource TS with something....the traditional all-1s signature comes from how PDH layer network TTL logic used would fail (to +5V).  Life is not this in packet-based networks...so carrying over this behaviour is not a good idea at all.  

regards, Neil

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 28 Jul 2011 22:48:30 +0200

Hi Daniel,

> congestion, CPU overload, etc.?

So as a customer I should only complain about degraded service
if it is caused by physical errors...
I have never seen SLAs with this restriction.

We should use the characteristics of the technology to detect
any issues with the transport of the characteristic information.

Regards, Huub.

---

From: Vivien Sterling <[email-masked]>
Date: Fri, 29 Jul 2011 05:01:11 +0800

Hi Daniel,

I think you might misunderstand several things:
1) AIS is used for alarm suppression;
2) SD is different from SF. SF in PHY must cause interruption of services
(same impact) in LSP and PW. However, SD in PHY may have different impact on
LSP and PW, e.g. the loss/delay status of packets on LSP is different from
that on PW,  etc.

Besides, IMHO you are indeed talking about SD of PHY rather than SD of
MPLS-TP transport path. Right?

-- 
Cheers,
Vivien

---

From: "Daniel Cohn" <[email-masked]>
Date: Fri, 29 Jul 2011 00:09:34 +0300

Inline

From: Vivien Sterling [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 5:01 PM
To: Daniel Cohn
Cc: [email-masked]
Subject: Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Daniel,

[DC] I'm aware of that, I just mentioned AIS as an example. As an aside,
pls note that draft-ietf-mpls-tp-fault uses AIS LDI flag for more than
just alarm supression

2)      SD is different from SF. SF in PHY must cause interruption of
services (same impact) in LSP and PW. However, SD in PHY may have
different impact on LSP and PW, e.g. the loss/delay status of packets on
LSP is different from that on PW,  etc.

[DC] Fully agreed. SD OAM message on LSP and PW is supposed to be a
notification of SD detected in server layer

 [DC] Right.

-- 
Cheers,
Vivien

DC

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

Huub van Helvoort

Huub

Of Shahram Davari
Of Daniel Cohn
technologies
be a
that's
I
made
adjust
Alessandro

---

From: Pablo Frank <[email-masked]>
Date: Thu, 28 Jul 2011 18:37:28 -0400

Hi Daniel,

Whether we get SD from the server layer or from a TP-based mechanism (such
as OAM) is not necessarily in conflict with one another.  The current Linear
Protection draft has place-holders for getting SD indications from the
server layer (what I think you are trying to address), from OAM (this is
less clear-- is it FM/DM or something else?), and from the management plane
(I have no idea what this is).  The PSC takes care of reacting to and
propagating the SD state so I don't think you need to use FM to do this.

I also don't think it's a good idea to propagate server-layer SD indications
to the next layer up automatically.  If we do this, some undefined entity
probably wants to take into account both server-layer and local indications
(from OAM and/or management plane) before deciding if an SD is propagated up
(as a server-layer indication to the next layer up).

cheers,
Pablo

---

From: [email-masked]
Date: Fri, 29 Jul 2011 09:49:48 +0800

Hi Greg and all,

I want to clarify several things:

1) Why some vendors do the research and development on SD of MPLS-TP?  ―
―  Requirements from service providers.  SD should be reported and 
trigger to protection.

2) Why propagate server layer infor to TP?  ―― IMO, Signal degrade only 
refers to the bit error happening on the physical layer. Packet loss 
induced by congestion or CPU overload is not the factor to SD. In order to 
avoid these impacts, we use the information detected by physical layer.

3) Why only propagate to TP? ―― We think it is not only TP, but also PW. 
In fact, propagate to transport path. It is described in the draft.

4) Why not propagate to the higher layer above thansport path? ―― Now, 
we are discussing the requirement and solution referring to transport 
path. Whether propagate to higher layer is not the topic we care about. 

Regards,
Yuxia

Greg Mirsky <[email-masked]> 
2011-07-29 01:00

收件人
Daniel Cohn <[email-masked]>
抄送
"Eric Osborne (eosborne)" <[email-masked]>, Rafi Ram 
<[email-masked]>, [email-masked], [email-masked], 
[email-masked], "D'Alessandro Alessandro Gerardo" 
<[email-masked]>, [email-masked]
主题
Re: [mpls] Comments to draft-rkhd-mpls-tp-sd-03

Hi Daniel,

Regards,
Greg

>> measurement, in my view, is addressing the issue.

--------------------------------------------------------
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: [email-masked]
Date: Fri, 29 Jul 2011 10:50:19 +0800

Agree with Daniel and Pablo.
Several carriers have the requirement of SD protection, and this 
requirement is already included in the draft of survivability framework 
and linear protection. So we should focus on how to achieve the 
requirement. 
I think the mechanism describe in draft-rkhd-mpls-tp-sd is a good way to 
achieve the requirement.

SuHui

"Daniel Cohn" <[email-masked]> 
发件人:  [email-masked]
2011-07-29 04:16

收件人
<[email-masked]>, <[email-masked]>
抄送

主题

DC

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

Huub

Of Shahram Davari
Of Daniel Cohn
technologies
be a
that's
I
made
adjust
Alessandro

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 29 Jul 2011 05:55:48 +0200

Dear Yuxia,

> I want to clarify several things:

OK.

> 1) Why some vendors do the research and development on SD of MPLS-TP? ―― 
> Requirements from service providers. SD should be reported and trigger 
> to protection.

There is no issue with that requirement.

> induced by congestion or CPU overload is not the factor to SD. In order 
> to avoid these impacts, we use the information detected by physical layer.

I respect your opinion.

However, the Signal/Service degrade detection shall be based on the
characteristic information of the layer that requires SD detection.

According to G.8110.1 clause 6.1.2 :
"The MPLS TP layer network characteristic information is a flow of
 MT_CI Data (MT_CI_D) traffic units".

The (SD) defect detection should never rely on defect detection mechanisms
in lower layers with possibly oher technologies.

In transport networks congestion should not occur under normal operating
conditions and neither should CPU overload.

> In fact, propagate to transport path. It is described in the draft.

Propagation to higher layers is useless, it only adds complexity.

> path. Whether propagate to higher layer is not the topic we care about.

This contradicts what you write in your item 3).

Best regards, Huub.

> *Greg Mirsky <[email-masked]>*
> 
> 2011-07-29 01:00
> 
> 	
> 收件人

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 29 Jul 2011 06:01:48 +0200

Hello SuHui,

Please read my reply to Yuxia.

Regards, Huub.

> *"Daniel Cohn" <[email-masked]>*

---

From: Maarten vissers <[email-masked]>
Date: Fri, 29 Jul 2011 06:27:16 +0000

The detection of a Degraded defect and associated raising of a Degraded failure condition is required to send a warning to the maintenance people that the connection is suffering from a persistent CIR packet loss which is exceeding the packet loss value in the SLA (case of transport service layer connection) or the value set for infrastructure connections (transport path or section layer connections).

The detection of a Degraded defect condition and associated raising of the Signal Degrade (SD) consequent action is required to prevent that a protected connection (Section, LSP, PW, PSME) enters UnAvailable Time (UAT). The SD should cause that the signal is switched to protection so that UAT will not be entered (default Degraded defect detection time is 7 seconds (see G.7710)). Degraded defect threshold is based on packet loss value in SLA.

It is a primary requirement in transport networks to prevent that a transport service layer connection (PW, service-LSP) enters UAT. A customer will be upset when his/her protected service enters UAT on CIR packet loss in the working connection and does not switch to protection to restore it. A customer does not care what is causing the unacceptable packet loss (bit errors on fiber, bit errors in equipment, congestion, packet buffer errors, switch fabric faults, other).

Regards,
Maarten

> Sent: 28 July 2011 22:49
> >>>> I agree with Eric, Shahram and actually richard kam
> (alcatel/lucent)
> >> made this exact point at the mike
> >>>> during presentation.
> >>>>
> >>>> /himanshu
> >>>>
> >>>>
> >>>>
> >>>> Cc: [email-masked]; [email-masked]; [email-masked];
> Rafi
> >> Ram
> >>>> of occasions, is not BOS layer and doesn't put bits on a wire.
> Thus
> >> it
> >>>> transport network and, I think, as result not all existing
> concepts
> >> of

---

From: Masahiro DAIKOKU <[email-masked]>
Date: Fri, 29 Jul 2011 13:08:32 +0900

Hi all,

In case that bit error rate gets incrementally worse, linear protection
is expected to keep prioritized customers traffic before occurring frame
loss on server layer.
So, signals degrade becomes one of the good candidate for monitoring
transport path state and fault indication trigger from lower layer.
Of course, in case of frame congestion, CPU overloading and the other
physical failure mode (e.g. loss of light, fiber cut, etc.), frame loss
is use for fault indication trigger from lower layer.

Although OTN has Forward Error Correction feature to monitor transport
path state, MPLS-TP frame is not always encapsulated by OTN, especially
access line portion.

Masa

>> 1) Why some vendors do the research and development on SD of MPLS-TP?
>> ―― Requirements from service providers. SD should be reported and
>> trigger to protection.
>>
>> 2) Why propagate server layer infor to TP? ―― IMO, Signal degrade
>> only refers to the bit error happening on the physical layer. Packet
>> loss induced by congestion or CPU overload is not the factor to SD.
>> In order to avoid these impacts, we use the information detected by
>> physical layer.
>>
>> 3) Why only propagate to TP? ―― We think it is not only TP, but also
>> PW. In fact, propagate to transport path. It is described in the draft.
>>
>> 4) Why not propagate to the higher layer above thansport path? ――
>> Now, we are discussing the requirement and solution referring to
>> transport path. Whether propagate to higher layer is not the topic we
>> care about.
>>
>>
>> Regards,
>> Yuxia
>>
>>
>>
>>

---

From: [email-masked]
Date: Fri, 29 Jul 2011 15:31:04 +0800

Hi Huub,

>Propagation to higher layers is useless, it only adds complexity.
I disagree with that. The advantages of this mechanism are stated in 
draft-rkhd-mpls-tp-sd chapter 4.1, it is not useless.  Since FDI have been 
defined,  FEI only add a type of packet, FEI propagation is just the same 
as FDI Propagation, it doesn’t add much complexity

Suhui

Huub van Helvoort <[email-masked]> 
发件人:  [email-masked]
2011-07-29 11:55
请答复 给
[email-masked]

收件人
[email-masked]
抄送

主题
Re: [mpls] 答复: Re:  Comments to draft-rkhd-mpls-tp-sd-03

Dear Yuxia,

OK.

> 1) Why some vendors do the research and development on SD of MPLS-TP? ―
― 

I respect your opinion.

> 3) Why only propagate to TP? ―― We think it is not only TP, but also 
PW. 

Best regards, Huub.

technologies
be a
that's
made

---

From: <[email-masked]>
Date: Fri, 29 Jul 2011 08:42:07 +0100

I agree with Huub.  Each layer network must be functionally independent (this is more than OAM please note) wrt any client or server layer networks.  And for transport networks this is a MUST because they have to provide a transparent transport service to their clients.   

regards. Neil

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

> Sent: 29 July 2011 04:56
> Subject: Re: [mpls] 答复: Re: Comments to draft-rkhd-mpls-tp-sd-03
> 
> Dear Yuxia,
> 
> You wrote:
> 
> ――
> only
> Now,

---

From: <[email-masked]>
Date: Fri, 29 Jul 2011 08:42:02 +0100

Maarten I agree with you wrt the layer and causal independence principle at play here.

This is the situation architecturally:

A layer N path is composed of layer N nodes and layer N links.  The layer N links are in turn provided by paths at layer N-1.....and so on downwards as we recurse to the duct.

Hence the impairments seen at layer N are a sum (to a good 1st~) of
-       the impairments introduced in the layer N nodes
-       the impairments inherited (from all the lower layer networks down to the duct) by the layer N links

This is a complex impairment inheritance/aggregation case.  However, the client of layer N cares nothing about what the actual layered arch is that supports his/her (external message/file/stream) applications....he/she just cares about the impact on his/her applications...and the perceived impact will vary from application to application.

Down at the EM guided wave layer is where we most generally associate 'SD' impairments wrt q'ary symbol errors (that become bits errors at higher layers).  These are generally not Poisson in nature but bursty...I spent much of 90s measuring these events and their distributions.  They are very complex and based on self-similar/chaotic characteristics (which have some interesting consequences for how folks quantify these wrt metrics and set maintenance thresholds that I will not go into here).

Above the BOS guided EM wave level impairments are either due to (i) rogue equipment components or (ii) congestion due to overbooked resources.

The former case is rare....and we don't need complex OAM with lots of QoS classes to identify these.

In a transport network the latter case should be non-existent, ie overbooking of resources violates a requirement of transparency.  Note carefully this also implies there cannot be any QoS classes in transport networks.  This is esp true if we also observe that a transport network often carries an aggregate (often temporally varying in mix) of ultimate message/file/stream applications which can have widely different QoS and survivability importance requirements...so we have to treat each bit in a transport connection equally...this is part of transparency.

Of course with the co-cs mode based on regular time-slices one can't overbook resources so we get transparency without thinking about it.

In the co-ps mode we don't get transparency for free but have to consciously engineer it.  Note that QoS is largely a nonsense anyway (irrespective of a transport role) for many reasons...that is, because real co-ps mode networks have to run far to the LHS of a their congestion knee for nearly all time it makes the topic of QoS (which is very different to 'survivability importance') of little value in the real world.

So, what we conclude from the above is that 'SD-like' impairments in the co-ps mode are largely a function of network design and how much an operator wants to overbook their resources. Looking ahead it my view that operators that subscribe to gross overbooking (and by inference also probably like lots of QoS classes) are backing the wrong strategy.  Though if one is *supposed* to be building a transport network anyway this should be a non-existent argument.

Aside=> We make things way too complex...esp OAM and much of the QoS nonsense.....most of it is simply not necessary.

regards, Neil

> Maarten vissers
> Sent: 29 July 2011 07:27
> The detection of a Degraded defect and associated raising of a Degraded
> failure condition is required to send a warning to the maintenance
> people that the connection is suffering from a persistent CIR packet
> loss which is exceeding the packet loss value in the SLA (case of
> transport service layer connection) or the value set for infrastructure
> connections (transport path or section layer connections).
>
> The detection of a Degraded defect condition and associated raising of
> the Signal Degrade (SD) consequent action is required to prevent that a
> protected connection (Section, LSP, PW, PSME) enters UnAvailable Time
> (UAT). The SD should cause that the signal is switched to protection so
> that UAT will not be entered (default Degraded defect detection time is
> 7 seconds (see G.7710)). Degraded defect threshold is based on packet
> loss value in SLA.
>
> It is a primary requirement in transport networks to prevent that a
> transport service layer connection (PW, service-LSP) enters UAT. A
> customer will be upset when his/her protected service enters UAT on CIR
> packet loss in the working connection and does not switch to protection
> to restore it. A customer does not care what is causing the
> unacceptable packet loss (bit errors on fiber, bit errors in equipment,
> congestion, packet buffer errors, switch fabric faults, other).
>
> Regards,
> Maarten
>
>
>
> > > errors, i.e. without being influenced by non-physical conditions
> such
> > as
> > >>>>> One of the reasons why we need SD in TP is because TP is
> supposed
> > > to
> > >>>>> provide the same "look and feel" of existing transport
> networks,
> > as
> > >>>>> in use have this distinction built into the innermost recedes
> of
> > >> their
> > >>>>> protocols.
> > >>>>> its windows according?  (please note that this is intended to
> be
> > a

---

From: [email-masked]
Date: Fri, 29 Jul 2011 15:46:25 +0800

Hi Maarten，

It looks like we agree with the SD protection requirement. The difference 
between us is detect in server layer or detect in MPLS-TP layer, is my 
understanding right?
 One advantage of detect in server layer is it can work correctly even in 
the case that no packet is transporting. This is important to use SD as a 
trigger of protection, because there is no packet in standby path.

Suhui 

Maarten vissers <[email-masked]> 
发件人:  [email-masked]
2011-07-29 14:27

收件人
"[email-masked]" <[email-masked]>
抄送

主题

The detection of a Degraded defect and associated raising of a Degraded 
failure condition is required to send a warning to the maintenance people 
that the connection is suffering from a persistent CIR packet loss which 
is exceeding the packet loss value in the SLA (case of transport service 
layer connection) or the value set for infrastructure connections 
(transport path or section layer connections).

The detection of a Degraded defect condition and associated raising of the 
Signal Degrade (SD) consequent action is required to prevent that a 
protected connection (Section, LSP, PW, PSME) enters UnAvailable Time 
(UAT). The SD should cause that the signal is switched to protection so 
that UAT will not be entered (default Degraded defect detection time is 7 
seconds (see G.7710)). Degraded defect threshold is based on packet loss 
value in SLA.

It is a primary requirement in transport networks to prevent that a 
transport service layer connection (PW, service-LSP) enters UAT. A 
customer will be upset when his/her protected service enters UAT on CIR 
packet loss in the working connection and does not switch to protection to 
restore it. A customer does not care what is causing the unacceptable 
packet loss (bit errors on fiber, bit errors in equipment, congestion, 
packet buffer errors, switch fabric faults, other).

Regards,
Maarten

---

From: <[email-masked]>
Date: Fri, 29 Jul 2011 08:58:20 +0100

Suhui,

You assume a permanent binding relationship of client layer link connection (and from here right up the stack to the ultimate TOS message/file/stream applications) to server layer path.  What if the client moves its routing (any of the higher layers up to the ultimate TOS case)?  Who are you sending FDI to then?

BTW – I coined the term FDI way back to try and differentiate the co-ps mode case from the co-cs mode AIS case.  In the co-cs mode AIS is required...there is a fixed/reserved resource partition (ie a regularly occurring time slice of fixed duration) that MUST be filled with something.  The all-1s AIS signature here came from how TTL logic failed to a +5V state in early PDH layer networks.  I used to think FDI/AIS was a good idea in co-ps mode packet networks until a few years ago.  I have since realised its adds no information value and simply creates something else to generate and possibly go wrong (with really bad consequences if it does).  FDI/AIS is should therefore not be used in any packet-based networks.

regards, Neil

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 29 July 2011 08:31
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] 答复: Re: Comments to draft-rkhd-mpls-tp-sd-03

Hi Huub,

>Propagation to higher layers is useless, it only adds complexity.
I disagree with that. The advantages of this mechanism are stated in draft-rkhd-mpls-tp-sd chapter 4.1, it is not useless.  Since FDI have been defined,  FEI only add a type of packet, FEI propagation is just the same as FDI Propagation, it doesn’t add much complexity

Suhui

2011-07-29 11:55
请答复 给
[email-masked]

收件人

[email-masked]

抄送

主题

Dear Yuxia,

OK.

> 1) Why some vendors do the research and development on SD of MPLS-TP? ——

> 2) Why propagate server layer infor to TP? —— IMO, Signal degrade only

I respect your opinion.

> 3) Why only propagate to TP? —— We think it is not only TP, but also PW.

> 4) Why not propagate to the higher layer above thansport path? —— Now,

Best regards, Huub.