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

[Curtis Villamizar <[e-mail]>]

In message <002d01cac9fc$d79fdc00$[e-mail]>
Maarten Vissers writes:
>  
> 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.

That is very close to correct.  The hashing will never look beyond the
BOS if the payload is not identified as IPv4 or IPv6.  That is what
the PW code word is for.

OTOH, there could be a label beyond the PW label known as the flow
label and described in the fat-pw draft.

> 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

Given the choice of meeting this requirement and keeping the existing
LAG functionality, some providers, maybe most of them operating a core
network, may choose to keep the LAG functionality.

Mandating that they lose this functionality may only hinder acceptance
of MPLS-TP or result in verndors, upon insistance from their
customers, provide an option to disregard this part of the spec.  If
so, the spec as written becomes a hinderance to new entrants in the
market who are unaware of the practical need to do this.

Curtis


> -----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