Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

Robert Raszuk <robert@raszuk.net> Thu, 05 June 2014 22:57 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCA01A025B for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 15:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DAJEv5fkB2l for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 15:57:03 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110751A0301 for <isis-wg@ietf.org>; Thu, 5 Jun 2014 15:57:03 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id y20so1588818ier.20 for <isis-wg@ietf.org>; Thu, 05 Jun 2014 15:56:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IQ1yOME1MV6OD35TZPdjdDTjbCTEho+t7E7iApztUN0=; b=CvqtWUuHPFV9CKHxtjkMcVTrOZWuyp3bhq5jsSq+hGqKg1aQNQcVFO29657yLqqhSO WEE7MGeSt3tBMt0TbVTOIfZpdPVA61DZGEqVtSTw6fCX/jQjAo1azCHbcDwUoyebuhFy xHaOn61V4rEfFQ3hjHM46RyrnfuzhF2toBV8NxxXPeIAERInJQas5vpWfQqRVHR64ky1 tR7Ua+ucOnlZQxOTiZVVPrhfbbT2sWLNy8BKPYLtWfqZC+FG3JrxH9sQAgAjztzDdPNk ICZIeycRDw/Rw3ffX78ij5kVQuv40P+rKBM7bxI2JJOvqOyocqEZjZoIfGew1ws8owVt UMMg==
MIME-Version: 1.0
X-Received: by 10.43.80.5 with SMTP id zs5mr893195icb.72.1402009016334; Thu, 05 Jun 2014 15:56:56 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.242.198 with HTTP; Thu, 5 Jun 2014 15:56:56 -0700 (PDT)
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941E1D8F3C@xmb-aln-x01.cisco.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <CA+b+ERmCusprkp3nYcwUtK4F0qmiv6-DogsEQ7vcJSgPRaHuPg@mail.gmail.com> <CECE764681BE964CBE1DFF78F3CDD3941E1D8412@xmb-aln-x01.cisco.com> <CA+b+ERndrSVcWmWWhHBOP==oub+V0gcMeLZ9X1dyKd9AfYHvXg@mail.gmail.com> <CECE764681BE964CBE1DFF78F3CDD3941E1D8679@xmb-aln-x01.cisco.com> <CA+b+ERnX+mVwnWf-jtZEUYRuZhEU-VmztrdObfdwmzrXz=erVQ@mail.gmail.com> <A1E50D8AD6310E47A6C10F075AEDC022017C54BB60@ONWVEXCHMB01.ciena.com> <CECE764681BE964CBE1DFF78F3CDD3941E1D8F3C@xmb-aln-x01.cisco.com>
Date: Fri, 6 Jun 2014 00:56:56 +0200
X-Google-Sender-Auth: Pc-ISWtRFvYLpSID7GcAJ1FrAbE
Message-ID: <CA+b+ERkRLR5+3Qn1d8gSn0zPeEh5eCFTTddb1zwTDMr5se1=zg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/qRjwjOkNV3ZheaEn3QUsoJoEc7A
Cc: "draft-xu-isis-mpls-elc@tools.ietf.org" <draft-xu-isis-mpls-elc@tools.ietf.org>, "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 22:57:05 -0000

Hi Nobo,

Inline ...

> In MPLS, there's no standards in load balancing. Meaning an
> implementation may load balance only on the top label, only on the
> bottom label or set of labels which may or may not be the entire
> label stack.

Practically I do not know any implementation which would ignore top
label as an input for hash, but you are correct that there is no
standard and that such implementation is possible in theory.

> To take this into account, every SID advertised will need to be advertised
> as a "range", even service SIDs.

Nope. I do not think this needs to be extended to service SIDs at all.
After all services require transport and transport SIDs is all we care
about for IP/MPLS loadbalancing.

> And what you are suggesting is that the "range" needs to be 7 or 8
> bits out of 20 bits.

5 bits gives option for 32 ECMP paths, 6 - 64, 7-128 that should do it :)

> Yes even SID advertisements can be optimized to take the "range" into
> account, but still a very big link/service label space & SRGB is required
> for this.

I think for v6 forwarding this is clearly beneficial. Hence such
optimization in SR architecture is welcome.

If MPLS is going to benefit from it remains to be seen or agreed up
on. I was just trying to share quick thought which just came up when
reading this thread.

>> Is this still more appealing then say mpls over UDP draft ;-) ?
>> http://tools.ietf.org/html/draft-ietf-mpls-in-udp-05
>
> I prefer not to get into this topic for now :)

:-)

Cheers,
R.