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

Robert Raszuk <> Thu, 05 June 2014 14:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 797141A019B for <>; Thu, 5 Jun 2014 07:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AJxs7vWXr-jq for <>; Thu, 5 Jun 2014 07:07:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F1E01A0167 for <>; Thu, 5 Jun 2014 07:07:46 -0700 (PDT)
Received: by with SMTP id h18so2330988igc.11 for <>; Thu, 05 Jun 2014 07:07:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=w6nisB18XWW6nJ7Lh/XnvATn52aIkj0fO789QW+znbQ=; b=m6nI+0+CxpFIKPZ5nvCxX2YWmmDCRSRB7XW1CajH6hrwf+RgbC2yuiLNofQskC+mbs gsZkPQ+OHkDQbVShYHoF+YA/4WWUY94yL3dpO6hvaG310Yk+ce7NyWsA6A8Rm94mJ6dP WyQtdxT0apN3Tyt7xeYS1Y7WJAwTHcdCFIaWv8eELc8bdwtz33gY5Qqc6NYQv/lBiL9V 3gTV+wkEseiiX8ivQiBto8q6G8/R7ruGz+BFVSOm2A66rmSXDqwS5BCHQ5vvvTjWfeXl f+HBe1MS7jHwvjFdAk6XkkXz0cIrbM1ghJHiatqy+2t8ErjAdhr0UktqcM0hQwfrk0d8 CbUQ==
MIME-Version: 1.0
X-Received: by with SMTP id lp7mr20591616igb.28.1401977259879; Thu, 05 Jun 2014 07:07:39 -0700 (PDT)
Received: by with HTTP; Thu, 5 Jun 2014 07:07:39 -0700 (PDT)
In-Reply-To: <29719_1401976957_5390787C_29719_1584_3_9E32478DFA9976438E7A22F69B08FF9201DDCC@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <> <> <5527_1401974709_53906FB5_5527_3538_2_9E32478DFA9976438E7A22F69B08FF9201DD5C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <> <29719_1401976957_5390787C_29719_1584_3_9E32478DFA9976438E7A22F69B08FF9201DDCC@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Date: Thu, 5 Jun 2014 16:07:39 +0200
X-Google-Sender-Auth: qoSutQnTCD5cwkpfUfsJRYwvwUo
Message-ID: <>
From: Robert Raszuk <>
To: "<>" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "" <>, "" <>
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jun 2014 14:07:47 -0000

> As far as I understand your proposal, you need to create forwarding entries "per flow" in all nodes, that's creating more states ...
> Moreover, SIDs are bound to links and prefixes (not really node), so for Prefix SID, it's quite similar to a FEC , except that you can bind multiple SIDs to the same prefix. But each Prefix SID you are adding, adds a new forwarding state in the whole IGP domain.

No not at all :)

SIDs can be aggregated in forwarding just fine. Think v6 address for
simplicity .. or MPLS labels if your data plane supports such
aggregation ..

Then what is in the packet's header  is only input for today's hash function.

If there is any logic (and that does not need to be stateful) it is
only on ingress to impose packets with the proper IP/MPLS header.
That's it.

Last sure you have prefix SIDs but those prefixes just describe node
say loopbacks as example. Frankly I do not understand why this forced
indirection is really needed - but this is different topic.