The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: [PWE3] MPLS PID

Dan:

The issue specific to ECMP is granularity vs. other trade offs (such as requiring control words, losing path consistency etc.), there is simply no free lunch. Obviously you cannot hash one label. If there is no usable label stack, consider FEC/incoming interface, sure it is not as fine grained as hashing the payload, the point is there are options that are less destructive to other useful properties.

I think we can all agree with the argument that on paper, the finer the microflow classification the better for load spreading of a single LSP, do we have real measurement to back that up where there are large numbers of LSPs, or are we well into diminshing returns at that point?

NOW If there are issues w.r.t. MPLS here, they are:

1) are we going to permanently break the paradigm where labels are PIDs?, because that's where we're headed. IMHO that's fairly fundamental. MPLS cannot just carry "anything" via signalled convention, because intermediate boxes are making their own assumptions as to what the payload is.

2) if we codify snooping the first nybble, it still does not fix ECMP hashing of reserved labels, we're still in the woods. We also hang out to dry work in PWE3 and other SDOs that are not compliant with this "new" convention.

If the goal is that ECMP trumps the MPLS architecture, we have a few things to fix, not just the PID. If the goal is that MPLS must be backwards compliant with deployed or may be deployed ECMP gear making PW 1st nybbles == 0 is only a start.

However I consider there to be a lot of practical difficulties with such a dictate, mandating that all future work to support proprietary and therefore unknowable implementations (a.k.a. arbitrary layer violations) is a bit of an oxymoron.

cheers
Dave

>
> You keep talking about using the label stack. Consider the case:
> - at the end of an LSP, where the forwarding operation is
> "pop and forward"
> - and where the packets being carried are IP
> - and there is ECMP on the output paths
>
> How is one supposed to make the ECMP decision in that case?
> There's only
> one label, so hashing on the label stack will only choose a
> single path.
>
> And don't say "well, it's ok to look at the IP packet in that
> case". If
> it's "fundamentally wrong" to look at the data, as opposed to
> the label(s),
> in the packet to make an ECMP decision in the middle of the
> LSP, then it's
> "fundamentally wrong" at the end.
>
> Or is that case acceptable, because the particular pre-standard
> implementation that you're trying to protect won't encounter it?
>
> Is it a layer violation for an IP ECMP implementation to look at the
> TCP/UDP ports when spreading the traffic over paths? Or to
> look under an
> IPinIP tunnel header? Or for a WFQ implementation to look at
> any packet
> fields? Maybe, but there can be practical value in doing so.
>
> For that matter, if we're worrying about layer violations,
> why is it ok to
> look below the top label (as in "hash the label stack").
> Isn't that also a
> layer violation?
>
> If your answer is "you know what the labels are, but you
> don't know that
> what the encapsulated data is" then that's the whole point of
> this PID
> discussion.
>
> IMO, if you want to make an argument based on architectural
> purity and
> "layering" then you need to stick with the top label. In any
> other case
> we've decided what we are,  we're just arguing over the price.
>
> But, in fact I don't accept that any of these are layer
> violations. In all
> these cases, the fundamental forwarding decision is on the outermost
> header. Any examination of underlying data is simply selecting finer
> granularity of flows.  In most of these discussions "layer
> violation" is
> simply a debating trick, holding out for OSI architectural
> purity as when
> all else fails.
>
> As I see it there are two possible approaches:
>
> 1. Require that an LSP set up for an IP L3PID or IP FEC carry
> IP packets. 2. Allow non-IP packets on such an LSP, but
> require that they be
> distinguishable.
>
> The simple facts are:
> - it turns out that [2] has value operationally, otherwise we
> wouldn't be
> having this discussion
> -  there is a proposal on the table which provides a backward
> compatible
> way to achieve [2], without affecting any fielded, standardized,
> implementations.
> -  the only negative impact of the proposal is on existing
> implementations
> of pre-standard drafts. And we all know the risks of
> implementing prior to
> standardization. Even there, an operator can deploy the pre-standard
> implementation, as long as they avoid [2].
>
> Why isn't this a no-brainer?
>
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>