[mpls-tp] MPLS-TP LM OAM usage over a LAG [was: RE: Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP =>~ETH aggregation?]

[Maarten Vissers <[e-mail]>]

Curtis,

Can you address this 'MPLS-TP LM OAM usage over a LAG' issue with the
authors of the MPLS-TP OAM Framework and MPLS Transport Profile Data Plane
Architecture drafts. I think that the data plane draft should include a LAG
section.

Regards,
Maarten

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: maandag 22 maart 2010 22:59
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 <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