Subject: Re: [mpls] Fwd: New Version Notification for draft-villamizar-mpls-forwarding-00.txt

From: Pablo Frank <[email-masked]>
Date: Wed, 7 Nov 2012 16:56:21 -0500

Hi Curtis, Kireeti,

Very good and useful draft.  Just a couple of comments:

- I'm glad that you raise the issue of min packet-size and the very real
possibility of getting bursts of min-sized frames.  In my experience,
particularly with 100G or faster, I've encountered a number of merchant
silicon solutions that struggle to meet line-rate performance *for all
packet sizes*.  I've seen cases where the performance is line-rate for 64B
frames (in some cases, it's even optimized for 64B) but does poorly for,
say, 65B frames.  There is often a saw-tooth pattern of packet-sizes that
drop below line-rate including packet-sizes in the 70s or 80s or higher.
 These sawtooth patterns are mainly a product of external memory technology
not being able to keep up.

While I can't make a strong argument for why you might see a lot of 65B
frames, there are other packet-sizes that can be problematic when you
consider various tunneling technologies.  For example, if you consider
min-sized Ethernet pseudowires, 82B and every 4B increment after that
suddenly becomes interesting.  I would suggest adding some text that calls
out these other common encapsulations that might cause problems in
current-gen hardware.

- A minor nit:  in section 2.2, you mention 150mpps without mentioning that
this applies to 100G interfaces.

regards,
Pablo

On Mon, Oct 8, 2012 at 8:30 PM, Kireeti Kompella <[email-masked]
> wrote:

> Hi Folks,
>
> I'd spoken on the issue of deep label stacks at the last IETF, and there
> was interest from chip suppliers, vendors and service providers.  Curtis
> just submitted the draft; it goes beyond just deep label stacks.  There are
> suggestions in the draft on aspects of implementing MPLS forwarding, as
> well as questions to ask regarding an implementation, and things to test.
>
> Please read and comment to the list.
>
> If you (that includes MPLS WG chairs and ADs) could also  formulate your
> thoughts on what type of doc (Info, BCP, PS) this should be, that would be
> very helpful in moving this discussion forward.
>
> Thanks,
> Kireeti.
>
> Begin forwarded message:
>
> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-villamizar-mpls-forwarding-00.txt*
> *Date: *October 8, 2012 16:49:08PDT
> *To: [email-masked]
> *Cc: [email-masked]
>
>
> A new version of I-D, draft-villamizar-mpls-forwarding-00.txt
> has been successfully submitted by Curtis Villamizar and posted to the
> IETF repository.
>
> Filename: draft-villamizar-mpls-forwarding
> Revision: 00
> Title:  MPLS Forwarding Compliance and Performance Requirements
> Creation date: 2012-10-08
> WG ID:  Individual Submission
> Number of pages: 17
> URL:
> http://www.ietf.org/internet-drafts/draft-villamizar-mpls-forwarding-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-villamizar-mpls-forwarding
> Htmlized:
> http://tools.ietf.org/html/draft-villamizar-mpls-forwarding-00
>
>
> Abstract:
>   This document provides guidelines for implementors regarding MPLS
>   forwarding and a basis for evaluations of forwarding implementations.
>   Guidelines cover basic MPLS forwarding, forwarding when a deep MPLS
>   label stack is encountered, MPLS UHP operations which require one or
>   more label POP plus a PUSH, guidelines for hashing an MPLS stack and
>   payload for multipath, and conformance and performance requirements
>   for recent pseudowire and MPLS standards.
>
>
>
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 12 Nov 2012 13:57:29 -0500

> not being able to keep up.

The 65B problem is often due to memory width.  I've seen the sawtooth
as well.

> out these other common encapsulations that might cause problems in

Since the real world problem is TCP ACKs getting compressed into
bursts, this might be acceptable to a provider.  If OTOH there were
streams of real time traffic at 70B to 80B getting compressed into
burst it might not be acceptable.  The point of the draft is to know
what to look for and then have the system designer and/or provider
decide what is acceptable.

You make a very good point regarding min-sized Ethernet within
Ethernet pseudowires.  In the real world small packets are typically
TCP ACK, but other encapsulations could put these in the 70-80 byte
range rather than 64B.

Also POS and GFP can have encapsulations smaller than 64B.  GFP over
OTN would be nice but can yield about 240 Mpps for ODU4 (100G) due to
its very low overhead relative to Ethernet encaps.

> this applies to 100G interfaces.

Thanks.  Paul Doolan pointed this out in private email well before
IETF but it appears that I forgot to fix it.  I'll look back at
private email from Paul and others and see what else I missed.

> Pablo

Thanks for the comments.

Curtis