Re: [i2rs] Additional Next Hop Type in Section 2.4 of draft-ietf-i2rs-rib-data-model, et al...

Jeff Tantsura <> Sun, 02 October 2016 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A497812B03D for <>; Sun, 2 Oct 2016 15:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6NMbxz-Gt1TE for <>; Sun, 2 Oct 2016 15:20:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2753212B025 for <>; Sun, 2 Oct 2016 15:20:46 -0700 (PDT)
Received: by with SMTP id e6so1303344pfk.1 for <>; Sun, 02 Oct 2016 15:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+YTbFZhECSYosvzguKiOCN1/AKxg3/zjgCzvVOB6O2A=; b=zGTaEfkw4nl24T44xuPCD5TYYxffj0GmuJd+DNp6RKP9yUIVnrD+tXmXXgSoN9T45u b9UaHudpdvQlBFyu1k2c/K49dKf7obbJ2HsCJdzRlFNUmD/vUo+/BD9ZVE6ZU8JAgzhN qtillvZuoQIjblYM/gdxtVraFETRU8bm4MADRwW/J6YDWcwN8fVKeS/yRmGxlwhJU0rG xPGtVMYnWrixK9lzHTaqMYqAODSaqzUn58GO89wqrrFgxn3JCY67kBnrwOpQgxFzD8Qb aG3VfM06M1qADvJXwdoC9Gr1hX5xe//HcyfiYYRUvfMhWngXOBivjEFskZqQ/snsSLPH xP1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+YTbFZhECSYosvzguKiOCN1/AKxg3/zjgCzvVOB6O2A=; b=UY/dYK5VVCAN9lyc0D3mCpYDQP2NkDGSDF98G4nb3dQ9FKB0xAHs3MvulioUQl3WVv Gx+lrvY7M9CVwb+qgDO9FvKsNMMquFDaMg+YaqN1PHecTF4nGdd4aByfnJRamfstldF6 IpOk5DJkcw+e8BfQ+CKwx331hDRV+Eju2aSWL2rDU7o8LXBICKqICDzSKdV9Ry0dfWwu N85c77fv93oy7bYfPiyi2UsT1Ti96X7L2kJq9bEj94Ih43ly8KxtJiPgY2mGsv+UGeU2 YAsI3wFlQBc8bMMeMU69akLHcc0wTbJ/qg9baMXK3nKPPcyluO20IzG28aTEwX5kAaZ1 DVcw==
X-Gm-Message-State: AA6/9RnfztSAp3IqlHUrJ34gLzEK+IVoK/UkW7Q3qCxUbwmz2K8G3jyEO9uaQSCL+YUeNg==
X-Received: by with SMTP id e68mr31979295pfa.147.1475446845640; Sun, 02 Oct 2016 15:20:45 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id c64sm35712256pfa.0.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Oct 2016 15:20:44 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura <>
X-Mailer: iPhone Mail (14A456)
In-Reply-To: <000b01d21c59$0e0a7880$2a1f6980$>
Date: Sun, 2 Oct 2016 15:20:43 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <000b01d21c59$0e0a7880$2a1f6980$>
To: Russ White <>
Archived-At: <>
Subject: Re: [i2rs] Additional Next Hop Type in Section 2.4 of draft-ietf-i2rs-rib-data-model, et al...
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Oct 2016 22:20:47 -0000


What would be the semantics of such NH?
Don't use for forwarding at all? Don't use for forwarding within ECMP bunde? Don't use in ECMP but use otherwise?


> On Oct 1, 2016, at 7:59 PM, Russ White <> wrote:
> Y'all -- 
> I would like to suggest we add one more next hop type in section 2.4 of
> draft-ietf-i2rs-rib-data-model, and sections 2.4 & 7.2 of
> draft-ietf-i2rs-rib-info-model to include a nexthop type that tells the
> forwarding device to not use a particular next hop without sending traffic
> to dev/null. The specific case is this -- assume I have an ECMP group with
> 32 or 64 entries. In this group, I want to pin one flow to a particular set
> of links, while making certain some other set of flows do _not_ use those
> links. The only way to accomplish this today would be to replace every route
> with the same ECMP group to provide a different set of next hops for each
> one. It would be cleaner to have a construction that says, "take this next
> hop out of all ECMP groups, so it is only used when specified by this
> client," or some such.
> Maybe something like this in section 7.2 of the rib data model might work --
> ==
> 7.4. Remove from ECMP next hop
> If the a particular route is marked "remove from ECMP," then any routes
> which recurse onto this next hop as part of an ECMP group will remove any
> paths using this route as a next hop from the ECMP group. This allows the
> I2RS controller to remove ECMP traffic from a particular next hop to attain
> finer grained control over the use of specific links to which particular
> elephant flows may be pinned, or which may be otherwise congested, etc.
> ==
> I don't know of any implementation that could do this right now, but this
> seems like a useful addition to the set of available next hops (?).
> :-)
> Russ
> _______________________________________________
> i2rs mailing list