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

Nitin Bahadur <> Fri, 07 October 2016 17:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F511129663 for <>; Fri, 7 Oct 2016 10:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Status: No, score=-5.697 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, 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 h5dqvnSf6E5H for <>; Fri, 7 Oct 2016 10:06:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 926521295EF for <>; Fri, 7 Oct 2016 10:06:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1475860002; bh=oUZauuO4E1g6mHv27/SnwrQLEk52d7r+FtXjaNXbONY=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=lvcV4toxyYUIc5LWyfI7mCcYuMM8kOx7K2UW5de0hayrolwDXwWjbfziZ0GeiHfN9KQ88EAeI4+ohBv6IWPtMc8D1hicXFBnjm87SOt2cj+6fcciizLRbWbYQ95xTW3jG80ZD7NGm6KvdwyOd4t4xDxC0SQWWp4k9L6TERK4xQhs4vTufB0sIlXiP5Lui/nihacpKgYyV8+JUd/77Rx0NuvFWjmwuTE/iuSnFc4yuj1iKBDgPxZc/+CaBpWZu78doXMCUbevyOrCWpLlWMc2H2S2+nVgKHBI3Kt41EBzq6F7QbLTDr7II0B++HoHq1BUFuy1Uk565VcnnWeXAWzBug==
Received: from [] by with NNFMP; 07 Oct 2016 17:06:42 -0000
Received: from [] by with NNFMP; 07 Oct 2016 17:06:42 -0000
Received: from [] by with NNFMP; 07 Oct 2016 17:06:42 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: a9mo79QVM1ntQsRRstJYA1XLcaTEnH4FHd5BHdJzUQxM4AX 2ewUkiZf1qs9FoAyMuS6i7H.XNKEvvj9VIsim_Bd.UypOcq5mt070aot7XyS WLHesyzuWJOTPqe2o6AkewXNwbKR8I_15_937HX7Wqr5SEKctypQSvdQHjCq 19wkNq91mJq3zeHfFnywOem2iypew7viWX74JS0H3vVAmEbQTRwA6iStiFKC Z7vQEFBCo07CT_LeNMSyPC_uhbI0VN5bMz.13aY8PoEmT30xdfyZ_5SLdZkr mmT2sn1Kw1sDGs05jdruEnqkDTZBdRVm1xpBSg0zmxgyP8aMK3x0Cl1Nnd3P yeJqcXn7n.TjS.tH71z0jsLw_wSJxZuFqGaiq8npTqBlSd5V_wCLl1IMkJ40 m9a9ORO1xtoPJW3_z9xB6bbu9AV07rtZ2hWeFEb3FhaxoVTy7G4yWauz.dwk AqVo2ETCvergSPkaIOJKsjJFrvAcBzEVgamCeJ_BQaM7k19g5F4wDUm3Yjy_ sy1H46zZfFVk3RSPUhQHMz9Q5rj.E10VGa2jaF2RFHL7Io6R_6MtQ
X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10-
User-Agent: Microsoft-MacOutlook/
Date: Fri, 07 Oct 2016 10:06:34 -0700
From: Nitin Bahadur <>
To: "Joel M. Halpern" <>, Jeff Tantsura <>, Russ White <>
Message-ID: <>
Thread-Topic: [i2rs] Additional Next Hop Type in Section 2.4 of draft-ietf-i2rs-rib-data-model, et al...
References: <000b01d21c59$0e0a7880$2a1f6980$> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
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: Fri, 07 Oct 2016 17:06:44 -0000

This use-case is a little too specific. I can see that having a ³new
nexthop type² might assist with dynamic flow manipulations without causing
packet drops.

We just have to be careful about adding this to the main draft, since it
opens up to more and more special cases being added after WG LC.

On 10/2/16, 3:29 PM, "i2rs on behalf of Joel M. Halpern"
< on behalf of> wrote:

>To add to that, I am wondering about ading this now.  Unless I am
>confused, and we have also made a serious mistake, the model is quite
>extensible.  It is highly likely that we will add additional next hop
>types in the future.  If we do not yet know of any use for this
>particularly one, why add it now?
>On 10/2/16 6:20 PM, Jeff Tantsura wrote:
>> Russ,
>> 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?
>> Regards,
>> Jeff
>>> 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
>>> to dev/null. The specific case is this -- assume I have an ECMP group
>>> 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
>>> links. The only way to accomplish this today would be to replace every
>>> with the same ECMP group to provide a different set of next hops for
>>> one. It would be cleaner to have a construction that says, "take this
>>> 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
>>> paths using this route as a next hop from the ECMP group. This allows
>>> I2RS controller to remove ECMP traffic from a particular next hop to
>>> finer grained control over the use of specific links to which
>>> 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
>>> seems like a useful addition to the set of available next hops (?).
>>> :-)
>>> Russ
>>> _______________________________________________
>>> i2rs mailing list
>> _______________________________________________
>> i2rs mailing list
>i2rs mailing list