Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP =>~ETH aggregation?

[Maarten Vissers <[e-mail]>]

Curtis,

If there is a guarantee that Y.1731 OAM within EVC signals is not corrupted
by a LAG within the MPLS-TP network, then it would be good to state that in
the MPLS-TP document describing LAG as a component in a MPLS-TP network.
That will take away one concern I have with LAG deployment. I understadn
that a LAG in MPLS-TP network will thus never look behind a PW label for its
hashing.

Having cleared this concern, I would like to make you aware of another
related concern, now being part of MPLS-TP OAM definition.

I was just reading section 5.5 of the MPLS-TP OAM framework document and
found the following text:

----------------------
5.5. Packet Loss Measurement  

   Packet Loss Measurement (LM) is one of the capabilities supported by 
   the MPLS-TP Performance Monitoring (PM) function in order to 
   facilitate reporting of QoS information for a transport path as 
   required in section 2.2.11 of [12]. LM is used to exchange counter 
   values for the number of ingress and egress packets transmitted and 
   received by the transport path monitored by a pair of MEPs.   

   Proactive LM is performed by periodically sending LM OAM packets from 
   a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP 
   (if a bidirectional transport path) during the life time of the 
   transport path. Each MEP performs measurements of its transmitted and 
   received packets. These measurements are then transactionally 
   correlated with the peer MEP in the ME to derive the impact of packet 
   loss on a number of performance metrics for the ME in the MEG. The LM 
   transactions are issued such that the OAM packets will experience the 
   same queuing discipline as the measured traffic while transiting 
   between the MEPs in the ME. 

   For a MEP, near-end packet loss refers to packet loss associated with 
   incoming data packets (from the far-end MEP) while far-end packet 
   loss refers to packet loss associated with egress data packets 
   (towards the far-end MEP).  

5.5.1. Configuration considerations 

   In order to support proactive LM, the transmission rate and PHB 
   associated with the LM OAM packets originating from a MEP need be 
   configured as part of the LM provisioning procedures. LM OAM packets 
   should be transmitted with the same PHB class that the LM is intended 
   to measure. If that PHB is not an ordered aggregate where the 
   ordering constraint is all packets with the PHB being delivered in 
   order, LM can produce inconsistent results. 
-------------------

The last sentence in section 5.5.1 refers to a required ordering. 

When a LAG is deployed within a Section layer transport path (i.e. Section
MEP functions are outside LAG), then the LM procedure will most likely
produce inconsistent results. Consistent results would be obtained only if
the Section MEP functions are located inside the LAG, i.e. on each link in
the LAG. 

When a LAG is deployed within a Transport Path layer transport path (e.g.
edge-to-edge LSP), then the edge-to-edge LSP LM procedure may produce
inconsistent results if the edge-to-edge LSP packets of the PHB and the
associated LM OAM packets are transported over more then one link in the
LAG. Can a LAG be operated such that all packets within an edge-to-edge LSP
with the same PHB will be carried over a single link in the LAG?

REgards,
Maarten
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: zondag 21 maart 2010 5:03
To: Maarten Vissers
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP
=>~ETH aggregation?


In message <000601cac72e$65d71d20$[e-mail]>
Maarten Vissers writes:
>  
> Curtis,
>  
> It will not be amusing for an operator when he deploys LAG as you 
> describe in which
> - the frames with Priority X of a p2p EVC (monitored with Y.1731 Frame
>   Loss Measurement OAM) are distributed over multiple links in the LAG
> - causing a reordering of these frames
> - resulting in the detection of lost frames or unexpected additional
frames.

Y.1731 is Ethernet OAM and would be inside a PW.  No MAC to MAC flow will be
reordered as long as the PW T-PE doesn't do something that would cause
reordering.

The single Ethernet PW is not a challenge.  Todays LAG of a few hundred
Gb/s, likely to be a Tb/s by the time MPLS-TP is deployed, is where LAG is
needed.

MPLS Ping is the current MPLS OAM and as long as we don't break what works
today in "enhancing" it to be MPLS-TP, then it will continue to work fine.

Of course, if MPLS-TP is only applicable to low bandwidth used, then there
is no issue.

> The reason this will not be amusing for the operator is that his EVC 
> support resutls in reporting of Severely Errored Seconds and possibly 
> Unavailable time by his UNI-N MEP functions and by the customer's 
> UNI-C MEP functions, thus causing non-compliance with the SLA for this EVC
service.
>  
> Regards,
> Maarten

You seen to be assuming that Y.1731 is MPLS-TP OAM.  That is not expected to
be the case.  The requirements for CC/CV, etc, will be met, but not with
Y.1731.  When IETF rejected Y.1711 as an MPLS OAM and adopted MPLS Ping, it
was with good reason.  We should not break MPLS Ping in adapting to a
MPLS-TP profile.

Our goal should be to let MPLS-TP support link bundle PW carrying Ethernet
with no reordering at all, let MPLS-TP support PW over LAS distributing
traffic on a MAC pair (or other) basis over LAG using flow label (fat-pw),
and let the large LSP over LAG the that exist today use MPLS-TP if they want
to.  Either that or MPLS-TP will only be capable of handlubg the low speed
traffic in the core and the vast majority of the traffic will continue to
use plain MPLS.

Curtis