The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Apr> msg00040



[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