Re: [Idr] 6PE-Alt draft

"Vishwas Manral" <vishwas.ietf@gmail.com> Mon, 04 February 2008 03:58 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 A7B3C3A6DA9; Sun, 3 Feb 2008 19:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 W51Sx3VHEto8; Sun, 3 Feb 2008 19:58:38 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C6E3A6CEC; Sun, 3 Feb 2008 19:58:38 -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 B4EB53A6CEC for <idr@core3.amsl.com>; Sun, 3 Feb 2008 19:58:37 -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 j65LD9OYoL30 for <idr@core3.amsl.com>; Sun, 3 Feb 2008 19:58:37 -0800 (PST)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by core3.amsl.com (Postfix) with ESMTP id CA2523A6A82 for <idr@ietf.org>; Sun, 3 Feb 2008 19:58:36 -0800 (PST)
Received: by py-out-1112.google.com with SMTP id x19so2105836pyg.24 for <idr@ietf.org>; Sun, 03 Feb 2008 20:00:11 -0800 (PST)
Received: by 10.142.232.20 with SMTP id e20mr3170475wfh.59.1202097610838; Sun, 03 Feb 2008 20:00:10 -0800 (PST)
Received: by 10.142.102.19 with HTTP; Sun, 3 Feb 2008 20:00:10 -0800 (PST)
Message-ID: <77ead0ec0802032000p4b09c2e4j4f6bbc804a8526a6@mail.gmail.com>
Date: Sun, 03 Feb 2008 20:00:10 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: raszuk@juniper.net
In-Reply-To: <47A647FA.9040909@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> <77ead0ec0802031455s300978bfn8d10b142376f315@mail.gmail.com> <47A647FA.9040909@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,

One more question.

So are you saying the implementations you know provides a separate
label for each route, or is it per peer?  I guess it is the later, but
just want to reconfirm the same.

Thanks,
Vishwas

On Feb 3, 2008 3:02 PM, Robert Raszuk <raszuk@juniper.net> wrote:
> 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