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