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(_at_)ietf(_dot_)org] On Behalf Of Loa Andersson
Sent: Thursday, January 09, 2014 8:17 AM
To: mark(_dot_)tinka(_at_)seacom(_dot_)mu; stbryant(_at_)cisco(_dot_)com
Cc: gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk; mpls(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; david(_dot_)black(_at_)emc(_dot_)com;
tsvwg(_at_)ietf(_dot_)org; jnc(_at_)mit(_dot_)edu; lisp(_at_)ietf(_dot_)org
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(_at_)mail01(_dot_)huawei(_dot_)com
Senior MPLS Expert loa(_at_)pi(_dot_)nu
Huawei Technologies (consultant) phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls