ietf
[Top] [All Lists]

Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp was RE: gre-in-udp draft

2014-01-10 10:58:19

Since we are all top posting ...

For counting dropped packets LM OAM is what you need.  CV doesn't do
that.  Direct LM will give best results on a per LSP basis but
requires forwarding chip support to do so.

I also don't know the origin of this discussion.

I am interested in how often in practice MPLS packets get 
misdelivered due to label corruption.

Not very often if ever at least for major vendor products.  I don't
know if second tier or third tier players have bugs.

(Very often circa 2000 or earlier particularly with one specific
vendor and with one provider who made things much worse by mucking
with the ILM through management plane, but that is ancient history).

Bit rot in TCAM or SRAM is very rare.  Bit rot in circa 1980s DRAM was
a problem.  Bit rot in modern non-ECC DRAM is rare.  Bit rot in modern
ECC DRAM is very rare.  Therefore to have a bad ILM you need bugs.

Curtis


In message 
<E6C17D2345AC7A45B7D054D407AA205C391FEA0A(_at_)eusaamb105(_dot_)ericsson(_dot_)se>
David Allan I writes:

Hi  (trimmed received list)

I'm not sure what the starting point of this dialog is, but I can at least say 
Greg is right on the CV front, it only detects and does not measure 
misdirection. 

The only other possibility to count anything is a "no ILM" condition where the 
label value is unrecognized by the receiving LSR, which IMO could not be made 
authoritative if it is label values in either the frame or the NHLFE and not 
exclusively next hops that is corrupted.

Cheers
D

-----Original Message-----
From: mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Gregory Mirsky
Sent: Thursday, January 09, 2014 9:30 AM
To: Loa Andersson; 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; 
lisp(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; 
david(_dot_)black(_at_)emc(_dot_)com; jnc(_at_)mit(_dot_)edu; 
tsvwg(_at_)ietf(_dot_)org
Subject: Re: [mpls] misdelivered mpls packets - Was: Re: draft-ietf-mpls-in-udp 
was RE: gre-in-udp draft

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
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls

<Prev in Thread] Current Thread [Next in Thread>