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

Robert Raszuk <robert@raszuk.net> Fri, 06 June 2014 07:45 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 2B7D01A03E2 for <isis-wg@ietfa.amsl.com>; Fri, 6 Jun 2014 00:45:02 -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 ILtDVxt_bqZy for <isis-wg@ietfa.amsl.com>; Fri, 6 Jun 2014 00:45:01 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF9C1A03D8 for <isis-wg@ietf.org>; Fri, 6 Jun 2014 00:45:01 -0700 (PDT)
Received: by mail-ig0-f175.google.com with SMTP id uq10so389287igb.8 for <isis-wg@ietf.org>; Fri, 06 Jun 2014 00:44:54 -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=o/gOZ+axRxpoAy8YiOpX84fU0psB8lPmeNMOJwcJ2zQ=; b=MU+wQy6/8/d1w/y7vi2FBske3WHWRxUstT9Fuq1nKnW1vK5dy6GBqHxofSk6J5KeDc FjGS5mZ50m72PyhGTJQWax2g3UrSn2GR60nmNl9LkrzVqzAWA1l0uxVpNsfa0OxGsw+5 3DqRyyJ1NAj2M6lkfmww84uDTSVKUWZxp/qTIQLqVDbOTFEhE5MSm/INfKhYQjfeoOyn vZJ0Srg3DCCoC+6Cwomlf6r5ZC9E+PJRYFgIb0zwB5LBfTED6hGyV945bZgBTzV8YodN C8If7hmctKEQEe0A6ypaNrRzUXoCXV/4oDqEQLTpXwv972qUWN4xwnvPOXHYw9BPEuNr u6tg==
MIME-Version: 1.0
X-Received: by 10.43.80.5 with SMTP id zs5mr3414459icb.72.1402040694285; Fri, 06 Jun 2014 00:44:54 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.242.198 with HTTP; Fri, 6 Jun 2014 00:44:54 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827EBC7@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <CA+b+ERmCusprkp3nYcwUtK4F0qmiv6-DogsEQ7vcJSgPRaHuPg@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827EBC7@NKGEML512-MBS.china.huawei.com>
Date: Fri, 6 Jun 2014 09:44:54 +0200
X-Google-Sender-Auth: _lbYlvqEvsbVOQnWESnAJ8oAsPM
Message-ID: <CA+b+ERk8cG3kuzg8POg3Kx6Xdb3GG-s9aKb+1FnstdKWvi6+Vg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Xuxiaohu <xuxiaohu@huawei.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/qZlIPN1QNKDQ8z8BJV0cplvuGEY
Cc: "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>, "draft-xu-isis-mpls-elc@tools.ietf.org" <draft-xu-isis-mpls-elc@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: Fri, 06 Jun 2014 07:45:02 -0000

Xu,

> Since he MPLS-based SPRING or SR architecture has no change to the
> MPLS data-plane, why can't we apply the EL concept directly to SPRING
> or SR architecture?

You sure can. That was not my point. My point was that we should
analyze and also consider alternatives other then EL approach.


> be orders of magnitude less in the SR concept) is true. Compare LDP with
> the IGP-based label distribution protocol, why do you believe the latter
> means orders of magnitude less of bindings?


Because as it has been already proven in other threads number of SR
nodes in a given domain may be much less then number of IGP nodes. (I
remove the adj SIDs requirement for now). In the latter and in the LDP
based FECs you rather must support signalling of ranges of FECs end to
end for it to work. With SR you can just do it for 10 nodes in 500
node IGP domain to get pretty good results. That's key difference.


> What' the same mistakes in your mind? The entropy label concept as defined in RFC6790? Or allocate a single label rather than a label range for a given FEC?

Mistake that you need a new level of stack to support load balancing.
If MPLS would provide few additional bits in the header day one
Kireeti would not need to invent entropy labels at all. :)

With SID range we can accomplish the same without need to touch MPLS
data plane so it is fully backwords compatible too.

Cheers,
R.