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

From: "Russ White" <[email-masked]>
Date: Sat, 1 Oct 2016 22:59:54 -0400

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

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 2 Oct 2016 15:20:43 -0700

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 <[email-masked]> wrote:
> 
> Y'all -- 
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 2 Oct 2016 18:29:39 -0400

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?

Yours,
Joel

---

From: "Russ White" <[email-masked]>
Date: Mon, 3 Oct 2016 06:44:59 -0400

> Don't use for forwarding at all? Don't use for forwarding within ECMP
bunde?
> Don't use in ECMP but use otherwise?

"Don't use as a next hop in an ECMP bundle but use otherwise..." The problem
I'm having (to answer Joel's follow on question) is this isn't really a
"route," but specific to a particular route that's being used (even if
connected) as a next hop -- so it's not really a new "next hop" type, I
don't think... Rather, it would be a way to override the use of an existing
route for recursion by other routes -- I don't know if this is possible in
the current models.

Thoughts? 

:-)

Russ

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 07 Oct 2016 10:06:34 -0700

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"
<[email-masked] on behalf of [email-masked]> wrote:

>>bunde? Don't use in ECMP but use otherwise?
>>
>> Regards,
>> Jeff
>>