Re: [Rift] Discussion on draft-cheng-rift-srv6-extensions-01

[Tony Przygienda <[e-mail]>]

actuaqlly, not all that easy, in rift draft we have to change the KeyIDType
but that's fairly trivial, something like

struct {
   required u8 type;
   required binary key;

}

and rev major version of rift schema encoding last time ;-)

that's used in a map but thrift being a proper IDL allows for that no
problem ;-)

-- tony

On Wed, Aug 2, 2023 at 4:34 PM Tony Przygienda <[e-mail]> wrote:

> very fair summary here. Easiest support will be by adding a key type that
> has a longer key basically allowing to put targeted system ID into it. So
> something like this
>
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |       X       |             Prefix Key Identifier             |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> |        Targeted   System ID                                   |
> +---------------------------------------------------------------+
>
>
> and define for this key type that the targeted system ID is integral part of key comparison _and_ can be used to filter southbound.
>
>
> Variants with bloom filter are also thinkable.
>
>
> This leads us into an interesting corner where we have variable key lengths on the KV store and hence nodes not implementing X would tie-break on 3 bytes only.
>
>
> I'm not even against radical reword of the KV registry draft where we do the following
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |       2       |   Key Length  |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                               Well-Known Key Identifier.      |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> which will make us future proof, i.e. nodes not implementing a KV key can always compare the key, no matter how complex
>
> or even indicate that there is a targeted system ID in southbound KV that can be filtered on and all 0s is basically "anyone" though I think this is superfluous. Nodes not understasnding the key type will flood to all southbound and anyone understanding it will filter
>
> bear discussion since this draft is independent of rift which describes tie breaking in generic sense only so rift rfc should be able to progress ahead
>
> -- tony
>
>
> On Wed, Aug 2, 2023 at 2:36 PM Jordan Head <jhead=
> [e-mail]> wrote:
>
>> All,
>>
>>
>>
>> I think we had quite a meaningful discussion during the meeting in San
>> Francisco last week. I’ve compiled the main points regarding
>> https://datatracker.ietf.org/doc/draft-cheng-rift-srv6-extensions/01/
>> and how we can perhaps find a more generic mechanism to solve what is
>> outlined in the draft as well as other similar problems.
>>
>>
>>
>>
>>
>>    1. First a quick side note. There is no need for new
>>    negative/positive TIEs for SIDs, after all they are just IPv6 prefixes and
>>    they will be handled by existing disaggregation functions. To indicate
>>    relevance to SR, we can simply tag those prefixes as a “SID” using prefix
>>    attributes (similar to how we tag if a prefixes metric (distance)).
>>
>>
>>
>>    1. This problem is similar to the one we have with performing
>>    distributed derivation of IPv4 loopback addresses in
>>    https://datatracker.ietf.org/doc/draft-head-rift-auto-fr/ in that
>>    there are simply not enough bits to avoid collisions.
>>
>>
>>
>>    1. Putting the configuration for all nodes in the fabric into the
>>    same Key-Value TIE won't work either. You'll exceed the MTU and end up with
>>    issues that cannot be managed by most silicon (i.e. commodity silicon).
>>    While RIFT does allow fragmentation to some degree, this will still not
>>    scale. Things need to be broken into reasonable pieces, e.g. System ID.
>>    However, since the Key-Value TIEs reserve 1 byte to indicate Well-Known and
>>    only an additional 3 bytes to hash and encode the System ID into. This
>>    isn't enough space and you'll end up with collisions and Southbound TIE
>>    breaking rules will eventually cause information to be thrown away.
>>
>>
>>
>> Ultimately, we can add new tie breaking rules. Which could be indicated
>> via a new well-known Key-Type, new code point entirely, or a new TIE type.
>> The result being that we tie break on System ID southbound (as northbound
>> would be pointless) and allow for targeted KV-TIE distribution.
>>
>>
>>
>> This assumes that every leaf node DOES NOT need to know about every other
>> leaf. If that is the goal, it's better to just create an over the top
>> tunnel and push information directly from the controller/ToF to the leaf,
>> no IGP would be capable of handling it at scale.
>>
>>
>>
>>
>>
>> This e-mail should serve as a starting point for more detailed
>> discussion, so additional observations are very much welcome.
>>
>>
>>
>> Thank you
>>
>> Jordan
>>
>>
>>
>>
>>
>> Juniper Business Use Only
>> _______________________________________________
>> RIFT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rift
>>
>