Subject: [mpls-tp] Can SD be used as a trigger for LSP prtotection in MPLS-TP? (was Re: I-D Action:draft-zhl-mpls-tp-sd-01.txt)

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 9 Nov 2009 15:41:27 +0200

Hi all,
I have given a new subject line  to this email (in accordance with Loa's rules), because I am going to question 
the very possibility of SD-based protection for LSPs in MPLS-TP.

The rationale for my doubts is like following:

1. I assume that, in packet networks, SD condition will be derived from measurement of such parameters as 
    packet loss ratio and, possibly packet delay/delay variation.
2. When I have discussed draft-frost-mpls-tp-loss-delay with its authors this afternoon, we have all agreed that:
    measurements of packet loss ratio only make sense when taken across user packets with the same 
    class of service and drop precedence level. (I believe the same applies to delay and delay variation measurements,
    but we did not go into it.). 
3. The MPLS-TP framework draft (in its present form) explicitly states that both E-LSPs and L-LSPs are supported
    in MPLS-TP.
4. Combining (1), (2) and (3) means that, for an E-LSP, there are up to 8 different measurements that can be used
    as the base for deriving the SD condition. Unsurprisingly, these measurements can result in up to 8 independent
    decisions regarding entry into and exit from the SD condition - for the same E-LSP.
5. Having 8 (eight) independently derived SD states for a single E-LSP to be switched seems to be at least 7 too much to me
   to be useful. 
6. L-LSP is not that much better; you have a single CoS but up to 3 drop precedence levels. (Of course, you can decide
    that only SD condition derived from packet loss measurement for the packets with the lowest drop precedence level
    is used; but the implications of such a decision are not quite obvious to me. E.g., an LSP that experiences severe congestion
    and hence drops all its discard eligible packets would remain unswitched, while an LSP that experiences bit errors on some of
    its links would be switched.)

My 2c,
     Sasha

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Thursday, October 29, 2009 2:41 PM
> To: Zhang Haiyan
> Cc: [email-masked]
> Subject: Re: [mpls-tp] I-D Action:draft-zhl-mpls-tp-sd-01.txt
> 
> Hi,
> 
> >> On the other hand, in the case of 1:n, this document is completely 
> >> unclear
> >> about which traffic should be bridged onto the protection 
> path (clearly 
> >> it
> >> cannot carry all of the traffic from all of the working paths it 
> >> protects).
> >> Yet, to provide the correct like-for-like comparison with 
> a working path, 
> >> it
> >> would need to carry the identical traffic.
> >
> > [HY] For 1:n, n working entities are protected by one 
> protection transport
> > entity. When SF or SD is detected only on one working 
> transport entity,
> > the process is the same as 1:1. When SF or SD is detected on several
> > working transport entities, we switch the traffic on the 
> working entity 
> > that
> > has the highest priority to protection transport entity.
> 
> Yes.
> The issue I had was that I was not clear that bridging does 
> not happen until 
> the failure/degradation has been detected on one of the working paths.
> In that respect, as I said to maarten, this scheme is like 
> on-demand 1+1 
> protection.
> 
> Cheers,
> Adrian
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: <[email-masked]>
Date: Mon, 9 Nov 2009 16:59:03 -0000

Hi Sasha,

You may now be starting to realise why I said some time ago that a
connection MUST only have a single QoS class.  This has a G.800
information-theory/transparency basis (which in principle requires that
a server MUST NOT try and infer the meaning of client symbols and must
therefore preserve the temporal ordering at the bit level, ie atomic
symbol, and you are starting to see the practical consequences of this
requirement.  The one I quoted in a mail while back was the entry/exist
of unavailable state, noting here the additional nuanace that when
entering an unavail state the PM counters should be disabled (as least
wrt counting against SLAs).  
BTW - This is not simply an end-end trail issue if one has nested TCM
levels....but I think you know my view on the TCM issue.

OAM and PM need to be kept as simple as possible...it is very easy to
create massive complexity that has little, if any, practical value.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: 09 November 2009 13:41
> To: Adrian Farrel; Zhang Haiyan; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: [mpls-tp] Can SD be used as a trigger for LSP 
> prtotection in MPLS-TP? (was Re: I-D 
> Action:draft-zhl-mpls-tp-sd-01.txt)
> 
> Hi all,
> I have given a new subject line  to this email (in accordance 
> with Loa's rules), because I am going to question the very 
> possibility of SD-based protection for LSPs in MPLS-TP.
> 
> 1. I assume that, in packet networks, SD condition will be 
> derived from measurement of such parameters as 
> 2. When I have discussed draft-frost-mpls-tp-loss-delay with 
> its authors this afternoon, we have all agreed that:
>     class of service and drop precedence level. (I believe 
> the same applies to delay and delay variation measurements,
> 3. The MPLS-TP framework draft (in its present form) 
> explicitly states that both E-LSPs and L-LSPs are supported
>     in MPLS-TP.
> 4. Combining (1), (2) and (3) means that, for an E-LSP, there 
> are up to 8 different measurements that can be used
>     as the base for deriving the SD condition. 
> Unsurprisingly, these measurements can result in up to 8 independent
> 5. Having 8 (eight) independently derived SD states for a 
> single E-LSP to be switched seems to be at least 7 too much to me
>    to be useful. 
> 6. L-LSP is not that much better; you have a single CoS but 
> up to 3 drop precedence levels. (Of course, you can decide
>     that only SD condition derived from packet loss 
> measurement for the packets with the lowest drop precedence level
>     is used; but the implications of such a decision are not 
> quite obvious to me. E.g., an LSP that experiences severe congestion
>     and hence drops all its discard eligible packets would 
> remain unswitched, while an LSP that experiences bit errors on some of
> > >> unclear about which traffic should be bridged onto the protection
> > path (clearly
> > >> it
> not happen 
> > until the failure/degradation has been detected on one of 
> the working 
> > paths.
> on-demand 
> > 1+1 protection.