[{"author": "Tony Li", "text": "

Couldn't this be done with YANG?

", "time": "2022-11-10T13:10:29Z"}, {"author": "Tony Li", "text": "

Slides aren't visible

", "time": "2022-11-10T13:14:21Z"}, {"author": "Markus Stenberg", "text": "

I see slide at least.

", "time": "2022-11-10T13:14:30Z"}, {"author": "Dhruv Dhody", "text": "

Must be delay at the speakers end

", "time": "2022-11-10T13:14:57Z"}, {"author": "Yingzhen Qu", "text": "

I guess there were delays

", "time": "2022-11-10T13:16:00Z"}, {"author": "Yingzhen Qu", "text": "

please help with the notes: https://notes.ietf.org/notes-ietf-115-rtgwg?edit

", "time": "2022-11-10T13:21:29Z"}, {"author": "Eduard V", "text": "

This room had Ethernet connector. 6man was loosing WiFi constantly too.

", "time": "2022-11-10T13:32:49Z"}, {"author": "Markus Stenberg", "text": "

Wifi is significantly worse in the meeting rooms than elsewhere in the venue.

", "time": "2022-11-10T13:33:59Z"}, {"author": "Amy", "text": "

YANG did not fully address the semantic interoperability between multiple vendors due to vendor-specific YANGs. We think the parsing-validating-mapping methodology could also be applied to YANG. We discuss it more in the discussion session of our paper: https://amyworkspace.github.io/hxchen/files/sigcomm22-nassim.pdf

", "time": "2022-11-10T13:36:52Z"}, {"author": "Lorenzo Miniero", "text": "

Chairs should have an ethernet cable on the desk they can use for connectivity

", "time": "2022-11-10T13:37:38Z"}, {"author": "Yingzhen Qu", "text": "

Thanks. good to know. hope this won't happen again

", "time": "2022-11-10T13:41:29Z"}, {"author": "Martin Thomson", "text": "

(wrong channel, sorry)

", "time": "2022-11-10T13:44:37Z"}, {"author": "Eduard V", "text": "

DNS has so many extentions. It makes sense to analyze which one is sopported by ROSA and which one is not. Comparison to DNS looks mendatory for better understanding.

", "time": "2022-11-10T13:52:14Z"}, {"author": "Feng Yang", "text": "

Does that mean the SAG needs to learn full of the services advertised ? That will put a big burden to the SAG

", "time": "2022-11-10T13:57:54Z"}, {"author": "Dirk Trossen", "text": "

@Eduard fair point to outline which DNS capability we intend to 'replace'

", "time": "2022-11-10T14:00:44Z"}, {"author": "Dirk Trossen", "text": "

@Feng no, the SAG utilizes the namespace-specific resolution service, e.g., the DNS, it does not learn all services available (which would indeed be a significant scalability challenge)

", "time": "2022-11-10T14:01:48Z"}, {"author": "Louis Chan", "text": "

Just processing the URL in a different way could be a solution too. Replacing DNS would a huge processing load to routing entities

", "time": "2022-11-10T14:04:12Z"}, {"author": "Markus Stenberg", "text": "

I don't really see what extra it brings over dns -> anycast address -> (some routing happening), but perhaps I should read the draft. e.g. adding new AF is pretty big hammer.

", "time": "2022-11-10T14:05:58Z"}, {"author": "Dirk Trossen", "text": "

@Louis at the SAR (i.e., the domain-internal elements), the binary names (encoded from the URLs) are indeed processed through a hash-based lookup, so much faster than a DNS lookup. In eBPF, that is what we do, i.e., extract the serviceID from the EH, do the hash based lookup to determine the next hop (possibly doing a secondary step to select one of possibly more next hops) and forward. This is fast (100ks of requests per second), even in eBPF. Also, the load is smaller since the SAR only processes the local client load, rather than needing to resolve all clients of a domain.

", "time": "2022-11-10T14:07:32Z"}, {"author": "Dirk Trossen", "text": "

@Markus less latency due to missing DNS lookup and the ability to realize ingress scheduling of requests, in addition to anycast type of ROSA-level routing.

", "time": "2022-11-10T14:09:29Z"}, {"author": "Markus Stenberg", "text": "

If those anycast addresses are static, they should be cacheable and have long TTL etc. Is this just optimizing initial single rare requests to bunch of seldom used services or what?

", "time": "2022-11-10T14:10:13Z"}, {"author": "Dirk Trossen", "text": "

@Markus this allows, for instance, for multi-site retrieval, scheduled at the ingress, without involving any lookup and using the existing IPv6 routes to the unicast replicas.

", "time": "2022-11-10T14:10:43Z"}, {"author": "Eduard V", "text": "

Is KIRA a replacement for BGP?

", "time": "2022-11-10T14:11:25Z"}, {"author": "Tony Li", "text": "

See bullet 1.1

", "time": "2022-11-10T14:11:54Z"}, {"author": "Boris Khasanov", "text": "

How does the KIRA communicate with routers?

", "time": "2022-11-10T14:12:03Z"}, {"author": "Dirk Trossen", "text": "

@Markus indeed, for long-lived anycast addresses, the routed mode of ROSA is the same, essentially, but you could do per request scheduling for those (anycast) services.

", "time": "2022-11-10T14:12:05Z"}, {"author": "Darren Dukes", "text": "

@Dirk Trossen The draft mentions LISP similarities, is it correct to say you convert the service url into an identifier then make a map request equivalent based on the service identifier? However you do this in-band by sending the service request to a special map server - called ingress SAR who forwards the request and then the host updates the service mapping locally when they get a response from the receiving service.

", "time": "2022-11-10T14:14:43Z"}, {"author": "Darren Dukes", "text": "

Is that on the right track?

", "time": "2022-11-10T14:15:05Z"}, {"author": "Dirk Trossen", "text": "

@Darren that is indeed correct. In a manner, the SAR is the mapping service, particularly in the scheduled mode where indeed one of possibly several service instance IPs is chosen, based on some possibly service-specific selection mechanism. In routed mode, the SAR forwards to another SAR, until it reaches the instance. This is different from the mapping process in LISP.

", "time": "2022-11-10T14:19:28Z"}, {"author": "Dirk Trossen", "text": "

Differences come in the mapping federation, itself. SARs are not federated but include mapping/routing entries populated by an overlay DV protocol. Any locally unknown service address is being directed to the SAG, which may either direct the packet to another ROSA domain or to the public Internet.

", "time": "2022-11-10T14:24:05Z"}, {"author": "Tony Li", "text": "

The similarities to the UPA work in LSR are not small.

", "time": "2022-11-10T14:27:26Z"}, {"author": "Darren Dukes", "text": "

@Dirk Trossen thanks, that clarifies the proposal for me.

", "time": "2022-11-10T14:31:40Z"}, {"author": "Roland Bless", "text": "

Eduard V said:

\n
\n

Is KIRA a replacement for BGP?

\n
\n

No, it is not. It's designed for control plane connectivity, so routing of data packets would be a different thing. One of KIRA's use cases is its use as in-band control plane fabric for SDN.

", "time": "2022-11-10T14:32:49Z"}, {"author": "Roland Bless", "text": "

Boris Khasanov said:

\n
\n

How does the KIRA communicate with routers?

\n
\n

Not sure what you mean. Currently, we are using IPv6 packets and link-local addresses for communicating between KIRA routing instances. So a router would always have to implement KIRA for its control plane. Using this connectivity, you could simply use ssh netconf or whatever to connect to the router in order to configure it, e.g., its data plane routing like OSPF or BGP.

", "time": "2022-11-10T14:34:35Z"}, {"author": "Boris Khasanov", "text": "

@Roland - Am i correct that routers do need to have KIRA agent installed and run to be able to communicate?

", "time": "2022-11-10T14:36:48Z"}, {"author": "Tony Li", "text": "

SRv6 is required to waste more bandwidth.

", "time": "2022-11-10T14:43:29Z"}, {"author": "Aleksandr Klimenko", "text": "

Yingzhen, was it a single-vendor solution?

", "time": "2022-11-10T14:44:23Z"}, {"author": "Boris Khasanov", "text": "

@Tony: \"SRv6 or not SRv6, that is the question...\" :)

", "time": "2022-11-10T14:46:09Z"}, {"author": "Yingzhen Qu", "text": "

@aleksander sorry, which one are you asking?

", "time": "2022-11-10T14:57:19Z"}, {"author": "Louis Chan", "text": "

I wonder why there are 1800 SRv6 policies, and the network shown is not big

", "time": "2022-11-10T14:57:21Z"}, {"author": "Tony Li", "text": "

This seems somewhat similar to MPLS MNA

", "time": "2022-11-10T15:00:09Z"}, {"author": "Roland Bless", "text": "

Boris Khasanov said:

\n
\n

@Roland - Am i correct that routers do need to have KIRA agent installed and run to be able to communicate?

\n
\n

Yes.

", "time": "2022-11-10T15:02:29Z"}]