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

[Curtis Villamizar <[e-mail]>]

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



Maarten,

This is a question of whether some things are SHOULD or MUST in the
eye of the service provider deploying equipment.  Ideally that would
match the documents, but reality has often deviated from standards if
SDO are too rigid.  In the view of the TP framework document what we
have been discussing could be viewed as the second case in the usage
(not looking at the document at the moment, but from memory) where
MPLS-TP coexists with MPLS.  If the only different between the
"conformant" MPLS-TP and MPLS is the former has LM and the latter can
support huge LSP using CL or LAG, the latter is likely to carry the
vast majority of traffic and the former may not even exist.

If on the other hand huge LSP using CL or LAG is recognized as a
requirement by MPLS-TP, then the only difference is that such a
deployment could be called an MPLS-TP compliant deployment rather than
be called an MPLS deployment with most capabilities of MPLS-TP
enabled.  It matters very little to the outcome, but its always nice
when framework documents more accurately reflect the outcome.

So yes, I will take your advice and send specific comments to the
framework authors to encourage then to consider this.  Minor mention
in the TP framework wouldn't hurt if it would not interfere with
advancement.  The data plane framework should have a mention of this.
The OAM framework should also have a mention if some types of OAM are
affected, which LM is.

On a relatd topic, there is also a question of accuracty of LM on
existing hardware which will slow path OAM but fast path forwarding.
I was planning to send a paragraph to be considered for inclusion in
the OAM framework.

Curtis

ps - I tried to respond yesterday but gave up trying to use the
wireless at IETF.



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