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

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

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 <7riw77@gmail.com> 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
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>