The MPLS WG Archive
[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index]
[PWE3] MPLS PID
-
From: "David Allan" <dallan@nortelnetworks.com>
-
Date: Wed, 2 Apr 2003 11:55:45 -0500
-
Cc: Shahram Davari <Shahram_Davari@pmc-sierra.com>, "'Lloyd Wood'" <L.Wood@eim.surrey.ac.uk>, pwe3@ietf.org, mpls@UU.NET
Title: RE: [PWE3] MPLS PID
Hi Dan:
> >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.
>
> I believe that I addressed this point:
> I wrote:
> > 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.
In other words all traffic on an MPLS network must "self identify". Only scenario where this is not true would be a TE tunnel set up with a non IP PID.
>
> The immediate situation is that we have cases where a TE LSP
> is signalled
> using L3PID==IP, or an LDP LSP is setup for an IP FEC, but
> the encapsulated
> data (under a multi-level label stack) is not IP.
Yes.
> You seem to be arguing in favor of [1] - requiring a strict
> interpretation
> of the L3PID, which means those packets should never be
> injected into that
> LSP.
The L3 PID only really exists for TE tunnels. Strict interpretation would seem to undermine any utility in having a label stack. I'm not arguing in favor of that....
> That's an internally consistent model, and it's the one
> which was used
> during the arguments which removed the L3PID from the original MPLS
> encapsulation. Unfortunately it seems to fail the reality
> test - if there
> were not operational benefit in violating [1] then we would
> not be having
> this discussion.
>
> >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.
>
> Either I'm missing your point or this is a red herring.
Q1: Are we fixing misordering of PW payloads, or are we fixing misordering of PW LSPs?
Q2: The SONET PWE3 draft, ATMF-AIC-178 etc. are all broken if we assume the payload must self identify as an IPv4 packet or not.
> Fundamentally, any ECMP algorithm needs to be designed to avoid misordering
> flows. If someone implements an algorithm that uses a hash of the label stack
> then it needs to avoid fields which are not constant for a flow.
Which was proposed in the "guidelines for load balancing" draft and rejected by the WG.
> IF we
> codify standards
> which require arbitrarily inserting additional labels into a
> stack then it
> can certainly impact an ECMP algorithm which depends on the
> contents of the
> stack. So we can have a whole separate argument about whether
> that is a
> good idea.
Sounds like we are not arguing ;-)
>
> BUT, that is all orthogonal to the issue of whether it
> should-be/needs-to-be possible to distinguish an IP from a
> non-IP packet on
> an IP LSP.
I stick by my assertion that its only part of the solution to the overall problem
cheers
Dave
|