Re: [mpls] [PWE3] ELI as a reserved label

John E Drake <jdrake@juniper.net> Mon, 09 August 2010 20:51 UTC

Return-Path: <jdrake@juniper.net>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3393A63EC; Mon, 9 Aug 2010 13:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.244
X-Spam-Level:
X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGy6OUz-IDYT; Mon, 9 Aug 2010 13:51:39 -0700 (PDT)
Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id EC4A33A6879; Mon, 9 Aug 2010 13:51:38 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTGBqfBSG4CEVAxCJd3MjYmABf7MqzjcH@postini.com; Mon, 09 Aug 2010 13:52:13 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 9 Aug 2010 13:28:27 -0700
From: John E Drake <jdrake@juniper.net>
To: "curtis@occnc.com" <curtis@occnc.com>, Kireeti Kompella <kireeti@juniper.net>
Date: Mon, 09 Aug 2010 13:28:24 -0700
Thread-Topic: [PWE3] [mpls] ELI as a reserved label
Thread-Index: Acs06aWZO7fBD5W0SRu8zRtjtYVaRQDFxUcw
Message-ID: <5E893DB832F57341992548CDBB333163984769690D@EMBX01-HQ.jnpr.net>
References: Your message of "Thu, 05 Aug 2010 07:08:51 PDT." <0A475913-EE22-491C-A883-F09E02058DC9@juniper.net> <201008052200.o75M0Z6g080049@harbor.orleans.occnc.com>
In-Reply-To: <201008052200.o75M0Z6g080049@harbor.orleans.occnc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: [mpls] [PWE3] ELI as a reserved label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Aug 2010 20:51:43 -0000

Comments inline

Sent from my iPhone


> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Curtis Villamizar
> Sent: Thursday, August 05, 2010 3:01 PM
> To: Kireeti Kompella
> Cc: mpls@ietf.org; pwe3@ietf.org
> Subject: Re: [PWE3] [mpls] ELI as a reserved label
> 
> 
> In message <0A475913-EE22-491C-A883-F09E02058DC9@juniper.net>
> Kireeti Kompella writes:
> >
> > Hi Curtis,
> >
> > On Aug 2, 2010, at 06:50 , Curtis Villamizar wrote:
> >
> > > This doesn't work in the following cases:
> > >
> > >  1.  P2MP (multiple egress, therefore multiple ELI values).
> >
> > Let's step back a bit.
> >
> > I think we're all agreed for p2mp that:
> > a) _if_ an ELI is needed, it must be the same ELI for all receivers;
> > b) *all* receivers must agree to process an EL;
> > c) *all* receivers must agree whether an ELI is needed and if so,
> what
> > the value of the ELI is.
> >
> > As  a reminder, we have mechanisms for upstream label allocation.
> >
> > Here's my opinion:
> >
> > For p2mp, use the signaling for app labels (if any) to also agree on
> > whether ELs will be used.  If ELs are to be used, the label stack
> > looks like:
> >
> > tunnel label
> > app label (p2mp PW/mVPN/...)
> > EL
> > payload
> >
> > In this case, there is no need for an ELI.
> 
> 
> The case for hierarchy and P2MP is weak.  Perhaps we will never need a
> P2MP LSP that carries both MPLS and MPLS-TP LSP inside it, but if we
> did, then the ELI would be needed.
> 
> I'm willing to solve that problem when and if it comes up and accept
> that for now, ELI is not needed on P2MP.

JD:  Agreed

> 
> 
> > For cases where there isn't an app label (IP mcast over p2mp LSPs),
> > use an upstream label allocation method to assign an ELI distinct
> from
> > all app labels over the p2mp LSP (note that the ingress LSR is
> > responsible for all upstream assignments, apps and ELI).  The label
> > stack looks like this:
> >
> > tunnel label
> > ELI (upstream allocated)
> > EL
> > payload
> >
> > Of course, if any receiver is unwilling or unable to process ELs,
> then
> > we're back to not using them.
> 
> 
> Right.  But if the ingress selects the ELI, the set of egress may end
> up with many label values allocated as ELI.
> 
> 
> > >  2.  Label stack depth is limited in order to accommodate MPLS-TP
> > >      (midpoints must know to look past the ELI to include the
> entropy
> > >      label in the hash).
> >
> > IMHO, an MPLS-TP box should be able to process labels to any depth
> > (note that "process" in this case is simply hashing).  I'll read and
> > comment on your draft, but if the primary reason for moving ELs/ELIs
> > "up" the stack is for depth-limited h/w, I'm not convinced.
> 
> 
> The depth limit is because a MPLS-TP LSP may be carrying more than one
> PW.  If it is, then the PW label can't be considered in the hash,
> otherwise the MPLS-TP LSP will not all be on the same path and OAM
> will be affected.  It is particularly hard to get the LM right.
> 
> I'm not saying I like MPLS-TP, but if we are going to carry MPLS-TP in
> the same large LSP that also carry non-TP traffic, we have to limit
> the stack depth and that signaling is carried across the midpoint LSR
> for the outer label only.

JD:  One of your proposed solutions was to enable MPLS-TP OAM multipath.  I think that this is a better approach, since we may want to use MPLS-TP OAM in non MPLS-TP situations and the existing MPLS OAM tools already support multipath. 

> 
> 
> > As for changing the semantics of the TC of ELs/ELI, I'm with Shane
> > that that's something that the MPLS WG as a whole should agree on.
> > Whether or not this is "not too horribly ugly" is a matter of opinion
> > :-) (and more importantly, what the hardware folks say!)
> 
> 
> I'm not fond of changing the TC bits at all.  The label below the
> forwarding label is used for hash only which is why the "not too
> horribly ugly" assessment.  The only thing lost by not allowing this
> is the marking of large flows and I could easily do without that.

JD:  Agreed

> 
> > Kireeti.
> 
> Curtis
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3