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 protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to