Minutes interim-2023-alto-01: Thu 13:00
minutes-interim-2023-alto-01-202302231300-00

IETF ALTO Interim Meeting 02/23/2023

Session:

Thursday 2/23/2023 2pm CET

WG Chairs:

Mohamed Boucadair (mohamed.boucadair@orange.com)
Qin     Wu        (bill.wu@huawei.com)

Agenda:

1. Session Introduction and WG Status Update (5 minutes)
2. ALTO over New Transport (50 minutes) Richard
3. ALTO OAM Support (50 mintutes) Jensen
4. Others (15minutes)

Session Introduction and WG Status Update

Chairs:

• Goal is that two main chartered doc items get ready for last call.
• Last recharter was on Nov 2021.
• A lot of progress since recharter on transport, OAM and deployments.

• Promoted new deployments:

  • CERN (EU) / NRP (USA)
  • Telefonica

• IETF 116:

  • WGLCs
  • Multi-domain
  • Compute exposure

ALTO over New Transport (50 minutes) Richard

Review and Recap

• Main focus is ability to support incremental updates
• Take CERN example with 600 nodes. Leads to cost map of 360000
  entries.

• One way is ALTO SSE (RFC 8895). Purely push approach.

  • Issues:
    • Need separate control connection (fw issues etc.)
    • Based on HTTP 1.x. Concurrency issues.

• Another is RFC7285:

  • Clien putll only, incremental not cacheable

• Goal efficient incremental updates to support client pull or HTTP
  2/3 native push.

Main Design Summary

• REST is 'REpresentational State Transfer'

  • Generalization, here the model is incremental

• Incremental transfer graph

• Should the mapping be persistent or per-session?

  • Decision: per-session based

• How the 3 types of resources? max-flexibility: all can be at
  different nodes; max-simplicity: all are in the same single node;
  compromise, directory in one node, meta and data in another.

  • Decision: single node

  [JRG] Who decides the structure of the graph?
  [RY] The server
  [JRG] Structure of the graph can be designed to implement
  different levels of time granularity
  [RY] Yes

• Review of IRD structure

• Review of TIPS Open + Response

  • Server does not keep state

• Review of TIPS Close / Delete

  • Closing the connection has the same effect

• Review of TIPS Request

• Review of TIPS filtered director request

• Graph invariants

  • Continuity
  • Feasibility
  • Right shift only

• Review of TIPS Individual Requests

• Error conditions
• Push:
  • Recommended: push data to the client with lowest cost.

Doc status

• Will update and submit new version this week

Remaining Issues

• Current design is colocated.
  • Does not allow fine grained LB
  • Solution 1: put front end at different location serving as LB
  • Solution 2: Redirect

[JRG] Plans to present this work in the IETF 116 hackathon
[RY] Yes
[JRG] Good to socialize the "i-REST" design, get feedback also from
running code.

ALTO OAM Support

• Review of reached agreements in 115
• Open issue: resource-level access control

• Review of the architecture and various YANG models

  [QW] Any examples for BGP in the Appendix?
  [JZ] I can add it.

  [RY] Access control should be based on what each client can
  access.
  [RY] Resource ID + parameter should solve the issue
  [QW] Let's bring this to the list

• During the reviews, Jordi made comments on showing examples on how
  to use the models to operate a server. We can do that.

  [QF] What's the relationship between ALTO client and role
  [JZ] It can have many-to-many
  [QF] Need to nail down
  [RY] I can post in the mailing list a solution we can discuss

Next steps:

• YANG doctor review
• WGLC

[QW] Ready for WGLC?
[JZ] Need to complete client side, but server side is ready. Will
propose a new version this week.
[QW] See you in Yokohama