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

[Curtis Villamizar <[e-mail]>]

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