Re: [mpls] [PWE3] Multiple RSVP paths
Curtis Villamizar <curtis@occnc.com> Tue, 06 July 2010 18:12 UTC
Return-Path: <curtis@occnc.com>
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 C5A983A68C6; Tue, 6 Jul 2010 11:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.217
X-Spam-Level:
X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599]
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 brT0UvI-6OLT; Tue, 6 Jul 2010 11:12:16 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 1B1BA3A688A; Tue, 6 Jul 2010 11:12:15 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o66ICFR0010664; Tue, 6 Jul 2010 14:12:15 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com)
Message-Id: <201007061812.o66ICFR0010664@harbor.orleans.occnc.com>
To: John E Drake <jdrake@juniper.net>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Tue, 06 Jul 2010 09:10:35 PDT." <5E893DB832F57341992548CDBB3331639843877BA7@EMBX01-HQ.jnpr.net>
Date: Tue, 06 Jul 2010 14:12:15 -0400
Sender: curtis@occnc.com
Cc: "draft-ietf-pwe3-fat-pw@tools.ietf.org" <draft-ietf-pwe3-fat-pw@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "stbryant@cisco.com" <stbryant@cisco.com>, pwe3 <pwe3@ietf.org>, "curtis@occnc.com" <curtis@occnc.com>
Subject: Re: [mpls] [PWE3] Multiple RSVP paths
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: curtis@occnc.com
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: Tue, 06 Jul 2010 18:12:18 -0000
In message <5E893DB832F57341992548CDBB3331639843877BA7@EMBX01-HQ.jnpr.net> John E Drake writes: > > Hi, > > A related ID: > > http://www.ietf.org/id/draft-kompella-mpls-rsvp-ecmp-00.txt > > Thanks, > > John John, The use of the E-bit is not clear. If the sub-LSP all have E=0, is the load split proportional to the sub-LSP reserved bandwidth? If E=1 are the reserved bandwidths of the component LSP all ignored? What happens if E=0 for some sub-LSP and E=1 for others? Also in the figure: ------------- M ----- / \ / --- P -- \ / / \ \ A --- X --- Y --- Q --- T --- B \ \ / | \ --- R ------- | \ | ------- S ---------- It is possible to set up link bundle Y-P-T and Y-Q-T as Y-T at PSC-4, then bundle Y-P-T-B and Y-R-B as Y-B at PSC-3, then X-Y-B and X-S-B as X-B at PSC-2, and A-M-B and A-X-B as A-B as PSC-1. Done with one PSC value to spare (the implied PSC=0). This use of link bundling would yield the finest control over the allocation of resources. Each link bundle is the sum of the components. The problem with link bundling and a limitation of the draft in question is that some LSP over this bundled LSP cannot specify that it *needs* to take one component (to be MPLS-TP compliant, for example), and allow other LSP to indicate that it is fine to load split it. [ And now a word for our sponsor. :-) ] See draft-villamizar-mpls-tp-multipath-00 for further requirements. Curtis > > -----Original Message----- > > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of > > Curtis Villamizar > > Sent: Tuesday, July 06, 2010 8:30 AM > > To: stbryant@cisco.com > > Cc: draft-ietf-pwe3-fat-pw@tools.ietf.org; pwe3 > > Subject: Re: [PWE3] Multiple RSVP paths > > > > > > In message <4C31E719.1060402@cisco.com> > > Stewart Bryant writes: > > > > > > In response to a comment received during last call I have added a new > > > section 7.3 entitled : "Multiple RSVP-TE Paths" which says: > > > > > > In some networks it is desirable for a Label Edge Router (LER) to be > > > able to load balance a PW across multiple RSVP-TE tunnels. The flow > > > label mechanism described in this document may be used to provide the > > > LER with the required flow information, and necessary entropy to provide > > > this type of load balancing. Methods by which the LER is configured to > > > apply this type of ECMP is outside the scope of this document. > > > > > > - Stewart > > > > > > Stewart, > > > > You could mention using a link bundle with the all ones component > > link as a possibility but still leave further details out of scope and > > not preclude other mechanisms that are local to the LER. > > > > Curtis > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www.ietf.org/mailman/listinfo/pwe3
- Re: [mpls] [PWE3] Multiple RSVP paths John E Drake
- Re: [mpls] [PWE3] Multiple RSVP paths Curtis Villamizar
- Re: [mpls] [PWE3] Multiple RSVP paths Yong Lucy