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

[Tony Przygienda <[e-mail]>]

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
>