Hi Loa, et al., I think that you're referring to Connectivity Verification in MPLS-TP (RFC 6428). It would only detect mis-connection but would not count leaked in frames. Such problem may be more apparent in Segment Routing (SPRING WG). Perhaps CV should be a requirement in SR OAM. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@xxxxxxxx] On Behalf Of Loa Andersson Sent: Thursday, January 09, 2014 8:17 AM To: mark.tinka@xxxxxxxxx; stbryant@xxxxxxxxx Cc: gorry@xxxxxxxxxxxxxx; mpls@xxxxxxxx; ietf@xxxxxxxx; david.black@xxxxxxx; tsvwg@xxxxxxxx; jnc@xxxxxxx; lisp@xxxxxxxx Subject: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft Changed the subject line ! On 2014-01-09 20:36, Mark Tinka wrote: > On Thursday, January 09, 2014 02:08:43 PM Stewart Bryant > wrote: > >> Either or both. > > I can only speak to native MPLS, as I've never run tunneled MPLS. > >> I am interested in how often in practice MPLS packets get >> misdelivered due to label corruption. > > Well, first of all, routers would need to report corrupted MPLS frames > so operators can glean this data. This isn't something I've come > across, but it would be good to find some kind of way to count this > across interfaces, if the routers can detect and report them. This would be possible to do with MPLS-TP OAM, wouldn't it? /Loa > > The known issue about mis-delivery of MPLS frames is poorly- sized MTU > interfaces. I have no empirical data as to how this can corrupt > successive MPLS frames that may fit into the transit MTU. But in this > case, as with any Layer 2 traffic, not enough MTU = dropped frame. > > Mark. > -- Loa Andersson email: loa@xxxxxxxxxxxxxxxxx Senior MPLS Expert loa@xxxxx Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@xxxxxxxx https://www.ietf.org/mailman/listinfo/mpls