IETF121 RIFT working group session
Nov 7th, Thursday Session IV
Chairs: Jeff Tantsura, Jeffrey Zhang
RIFT Working group information: https://datatracker.ietf.org/group/rift/about/

WG Status; chairs; 10 minutes
Weiqiang Cheng: I see the SR-MPLS extension draft has been listed here. We have a draft of RIFT extension for SRv6.
Jeff Tantsura: The milestones are the goals for chairs to track. The extensions for SR-MPLS and SRv6 are separate documents.

draft-head-rift-auto-is-is-00; Jordan Head; 10 minutes
Jordan Head: This draft doesn’t re-invent IS-IS and EVPN. Next version will have more contents.
Tony Przygienda: Multiple customers push us to do this work. They want something flat with the option to do the flood reflection.
Jeff Tantsura: we will start the adoption after the new version with more details.
Jeffrey Zhang: Is it still a fat tree topo more than arbitrary topo?
Jordan Head: Yes. It works on the hierarchy topology.
Jim Guichard: why does IS-IS come into the picture?
Tony Przygienda: It comes with the customer demand - they want to replace a chassis with this thing and want ZTP.
Jeff Tantsura: it’s better to describe the use case more clearly.

draft-cheng-rift-srv6-extensions; Changwang Lin; 10 minutes
Jim Guichard: have you provided any justification that why this draft is wanted?
Weiqiang Cheng (co-author): we will add some use case and requirements, for example, adaptive routing or something else, for example switch the route to TE tunnel because of link failure.
Jim Guichard: from the protocol perspective, RIFT can provide good ECMP or convergence for the failure. So needs to clarify why the TE capability is needed. RIFT can be filled with many things. better to have specific deployment situation to clarify it.
Tony Przygienda: An example is egress peer engineering - It does make sense when a leaf can select different ToFs to go out of the fabric, because above that the bandwidth sitaution is different and other reasons.
Jim: Thank you Tony. The document does not have to provide an exhaustive list but one or two use cases like this will help.
Jeff Tantsura: I like that you didn't go for all 127 flaviors of SIDs. Let's keep it relatively simple and focus on static traffic engineering only.
Tony Przygienda: You have a problem with key-ID. Same key-ID from different nodes will lead to tie breaks. For northbound it’s OK but for southbound there will be tie-break.
Tony: Maybe you want to filter the key-value information - only a specific node will keep a specific key-value - going southbound.
Tony: A new TIE type can be added and doesn’t need to change any specification.
Jeffrey Zhang: Why use a new prefix TIE for it?
Tony Przygienda: It's just cleaner. SRv6 is not an address family. When the nodes don’t support SRv6 receive the packet, will go on flooding. It will be transparent - if it's prefix scope. But the key-ID tie break still needs to be discussed.
Jeffrey Zhang: the published draft is different from this presentation, right?
Changwang Lin: Yes. Will publish the newest version.
John Scudder (chat): Also the doc isn’t even adopted by the WG yet, I would assume problem statement (short! not novel length!) would be critical for that discussion.

draft-zzhang-rift-multicast-02; Jeffrey Zhang; 10 minutes
Tony Przygienda: This does look like flood reduction reversed. The ToFs and the sub-ToFs can run a distributed algorithm to get full coverage. Check with Pascal. Also consider the Plane ID - maybe that's the missing link.
Jeffrey: Pre-setup multicast trees could be very useful in AI/ML networking.
Tony: That would be a cheap solution but we probably have to get a bit smarter like to support in-subtrate computation.