Re: [Idr] 6PE-Alt draft

"Vishwas Manral" <vishwas.ietf@gmail.com> Sun, 03 February 2008 22:53 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 0060B3A6D4D; Sun, 3 Feb 2008 14:53:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.206
X-Spam-Level:
X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599]
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 qmSW5thqX+kG; Sun, 3 Feb 2008 14:53:34 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109A63A6D1A; Sun, 3 Feb 2008 14:53:34 -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 460A13A6D1A for <idr@core3.amsl.com>; Sun, 3 Feb 2008 14:53:32 -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 d0WKORzYjuPn for <idr@core3.amsl.com>; Sun, 3 Feb 2008 14:53:31 -0800 (PST)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by core3.amsl.com (Postfix) with ESMTP id 68B763A6C71 for <idr@ietf.org>; Sun, 3 Feb 2008 14:53:31 -0800 (PST)
Received: by py-out-1112.google.com with SMTP id x19so2018746pyg.24 for <idr@ietf.org>; Sun, 03 Feb 2008 14:55:06 -0800 (PST)
Received: by 10.142.156.2 with SMTP id d2mr3122334wfe.219.1202079305755; Sun, 03 Feb 2008 14:55:05 -0800 (PST)
Received: by 10.142.102.19 with HTTP; Sun, 3 Feb 2008 14:55:05 -0800 (PST)
Message-ID: <77ead0ec0802031455s300978bfn8d10b142376f315@mail.gmail.com>
Date: Sun, 03 Feb 2008 14:55:05 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: raszuk@juniper.net
In-Reply-To: <47A631EC.80703@juniper.net>
MIME-Version: 1.0
Content-Disposition: inline
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>
Cc: idr@ietf.org
Subject: Re: [Idr] 6PE-Alt draft
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 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