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

[Weiqiang Cheng <[e-mail]>]

Hi Jordan,
Thank you for your email. It serves as an excellent summary and accurately identifies the issues co-authors have met. 
We appreciate your insights and welcome further comments and suggestions from the experts in the working group to improve the draft.

Best regards, 
Weiqiang Cheng
 
From: Jordan Head
Date: 2023-08-02 20:35
To: [e-mail]
Subject: [Rift] Discussion on draft-cheng-rift-srv6-extensions-01
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.
 
 
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)). 
 
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. 
 
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