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

[Jordan Head <[e-mail]>]

Yes, great idea. Let’s go with the variable key-length option, it solves our original problem and makes for better interoperability at the same time.

I’ll work on iterating the KV Registry draft as well as adjust the KeyIDType in the RIFT base spec. Auto-FR/EVPN updates will follow.

Jordan



Juniper Business Use Only
From: Tony Przygienda <[e-mail]>
Date: Wednesday, August 2, 2023 at 11:04 AM
To: Jordan Head <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Rift] Discussion on draft-cheng-rift-srv6-extensions-01
[External Email. Be cautious of content]

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]<mailto:[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]<mailto:[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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cheng-rift-srv6-extensions/01/__;!!NEt6yMaO-gk!FDuLnXN6HYPEMdY3l5-850IYldZ9AOmXpfvewyllntJoit0NU8WVWZ-LiHDLxJDtmTwMonjjjMN50Mng$> 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-head-rift-auto-fr/__;!!NEt6yMaO-gk!FDuLnXN6HYPEMdY3l5-850IYldZ9AOmXpfvewyllntJoit0NU8WVWZ-LiHDLxJDtmTwMonjjjDQcy5Cp$> 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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rift<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rift__;!!NEt6yMaO-gk!FDuLnXN6HYPEMdY3l5-850IYldZ9AOmXpfvewyllntJoit0NU8WVWZ-LiHDLxJDtmTwMonjjjHb8YBat$>