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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx] On Behalf Of Gregory Mirsky
Sent: Thursday, January 09, 2014 9:30 AM
To: Loa Andersson; mark.tinka@xxxxxxxxx; stbryant@xxxxxxxxx
Cc: gorry@xxxxxxxxxxxxxx; mpls@xxxxxxxx; lisp@xxxxxxxx; ietf@xxxxxxxx; david.black@xxxxxxx; jnc@xxxxxxx; tsvwg@xxxxxxxx
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@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
_______________________________________________
mpls mailing list
mpls@xxxxxxxx
https://www.ietf.org/mailman/listinfo/mpls





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]