Re: [Idr] 6PE-Alt draft

Robert Raszuk <raszuk@juniper.net> Sun, 03 February 2008 23:02 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: ietfarch-idr-archive@core3.amsl.com
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5FBC3A6D39; Sun, 3 Feb 2008 15:02:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.297
X-Spam-Level:
X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHYGUgG+fR0x; Sun, 3 Feb 2008 15:02:00 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4EF73A6D50; Sun, 3 Feb 2008 15:02:00 -0800 (PST)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C759A3A6D39 for <idr@core3.amsl.com>; Sun, 3 Feb 2008 15:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhcKnkBU0UqE for <idr@core3.amsl.com>; Sun, 3 Feb 2008 15:01:58 -0800 (PST)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id E28393A6C98 for <idr@ietf.org>; Sun, 3 Feb 2008 15:01:53 -0800 (PST)
Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Sun, 03 Feb 2008 15:03:29 PST
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Feb 2008 15:02:21 -0800
Received: from [172.26.250.99] ([172.26.250.99]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m13N2Jq42262; Sun, 3 Feb 2008 15:02:19 -0800 (PST) (envelope-from raszuk@juniper.net)
Message-ID: <47A647FA.9040909@juniper.net>
Date: Sun, 03 Feb 2008 15:02:18 -0800
From: Robert Raszuk <raszuk@juniper.net>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Vishwas Manral <vishwas.ietf@gmail.com>
References: <BAY120-W259B9D353746E33D0864CED8370@phx.gbl> <77ead0ec0801310631r29449dafq961d8a9aecfea098@mail.gmail.com> <77ead0ec0801310700j55f10bcah2aae27dd0fea3927@mail.gmail.com> <BAY120-W1856D92C0C10B950241B43D8370@phx.gbl> <77ead0ec0801310932i5d6ed617j3fe1df7674c0740f@mail.gmail.com> <20080201090733.GA1929@nic.dtag.de> <77ead0ec0802010926k6e57424eoc6ad1328eb65774c@mail.gmail.com> <47A631EC.80703@juniper.net> <77ead0ec0802031455s300978bfn8d10b142376f315@mail.gmail.com>
In-Reply-To: <77ead0ec0802031455s300978bfn8d10b142376f315@mail.gmail.com>
X-OriginalArrivalTime: 03 Feb 2008 23:02:21.0822 (UTC) FILETIME=[D54629E0:01C866B8]
Cc: idr@ietf.org
Subject: Re: [Idr] 6PE-Alt draft
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@juniper.net
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Hi Vishwas,

Unfortunately it is not configurable ... as it is done at the forwarding 
layer in hardware ASICs in some implementations I am familiar with.

In fact some just hash on first and last label in stack some indeed 
could hash only on first two or three and some could go up to the IP 
header (if this is IP which is a big question at the P router).

Cheers,
R.

> 
>  Hi Robert/ Martin,
> 
> That is an interesting point you bring out.  What you say does make sense.
> 
> I agree if load balancing is based on the labels it will not help load
> share in case of 6PE-Alt - if we use a constant label. Anyway I would
> assume the load sharing mechanism is configurable (what fields to use
> to hash) and works within the scope of the router.
> 
> Thanks,
> Vishwas
> 
> On Feb 3, 2008 1:28 PM, Robert Raszuk <raszuk@juniper.net> wrote:
>  > Hi Vishwas,
>  >
>  >  > The P device works on the outer Tunnel label and its functionality
>  >  > will not change in my view.
>  >
>  > I must say that your view here is incorrect.
>  >
>  > There are hardware implementations just like Martin pointed out which
>  > take not the only top most but _entire_label_stack_ in the mpls packets
>  > into considerations when hashing in P routers for load sharing purposes.
>  >
>  > As far as I can see your proposal breaks this as the second label will
>  > be always the same thus all packets going to single PE will always take
>  > the same path.
>  >
>  > To address this you would need to change implementations of those P
>  > routers mpls switching vectors to also consider IPv6 header which is a
>  > non starter operationally.
>  >
>  > Cheers,
>  > R.
>  >
>  >
>  > > Hi Martin,
>  > >
>  > > The load sharing and everything else on the of P devices will still
>  > > work the same way. So we would have for example LDP running on the P
>  > > routers giving out labels for FEC's just the same way. The P device
>  > > works on the outer Tunnel label and its functionality will not change
>  > > in my view.
>  > >
>  > > There is a case of having different labels for preventing one IPv6
>  > > lookup in some cases but in case we had the ECMP case we would have to
>  > > use the IPv6 header lookup and use the inner label as an IPv6 Explicit
>  > > NULL label.
>  > >
>  > > Do let me know if I missed the point?
>  > >
>  > > Thanks,
>  > > Vishwas
>  >
>  >
> 

_______________________________________________
Idr mailing list
Idr@ietf.org
http://www.ietf.org/mailman/listinfo/idr