Skip to main content

Minutes interim-2022-rtgwg-01: Tue 08:00

Meeting Minutes Routing Area Working Group (rtgwg) WG
Date and time 2022-06-21 15:00
Title Minutes interim-2022-rtgwg-01: Tue 08:00
State Active
Other versions markdown
Last updated 2022-06-27


==RTGWG Interim==
Tuesday 2022-06-21 15:00 UTC

++Meetecho for participation++

++Hedgedoc (Etherpad for notes, comments)++


++Video Recording++


  1. Administrivia (5: 5/120)
  2. Refresher : What is Semantic Routing? What problems is it solving
    (15 : 20/120)
    Daniel King
  3. Counterpoint : QoS or Bandwidth? (10 : 30/120)
    Phil Eardley
  4. Caution : What we must do. What we must not do. (15 : 45/120)
    Adrian Farrel
  5. Architecture : What are the possible approaches? (15 : 60/120)
    Dirk Trossen
  6. Strawmen (understanding what people are thinking about)
    5a. Using Segment Routing do achieve Semantic Routing (15 : 75/120)

    Suresh Krishnan
    5b. Extensible In-band Processing (EIP) (15 : 90/120)
    Stefano Salsano
    7. Open Discussion (25 : 115/120)
    8. Wrap-up and Next Steps (5 : 120/120)



  1. Refresher : What is Semantic Routing? What problems is it solving
    (15 : 20/120)
    Daniel King

Linda: what are the information carried by semantic routing?
Dan: Based on header info and traffic demands, we programme the path to
ensure the application or service demand is me, this is about routing
packets and not services.

Linda: Can you identify the user if you are aware of how to treat
specific traffic based on heder info.

Hesham: Is it possible to look into payload and decide action?
Dan: Yes, but. Although cheap hardware might be available for payload
inspection, someone or something needs to determine what you are looking
for, so privacy issues will pop up. Also payload inspection is not
encryption proof.

Acee: This reminds me of APN. It's already done for QoS and Routing.
What you're saying is to standardize the marking and treating, how do
you know people will follow the standard unless one administrator
domain? it's going to cost more money.
Dan: "Trust, but verify."" Who, or how, will pay will need further
discussion. I'll defer the APN discussion, Adrian has chaired the
question before.
Adrian: you're right, it looks similar to APN. APN is more interested in
per-hop behavior, it's open for discussion.

  1. Counterpoint : QoS or Bandwidth? (10 : 30/120)
    Phil Eardley

Adrian: Do you envision a model where customers (of BT) could pay for
traffic treatment for specific applications over a common link?
Phil: Yes, we've tried to look at this before, but need to consider cost
model. MPLS is a good example of a business service that does this.
Linda: What is the difference between MPLS and Semantic Routing?
Greg: Time-sensitive networking could provide capabilities, what about
Adrian: Yes, good points, but stove pipe. Maybe we need to consider a
more general approach, semantic networking

  1. Caution : What we must do. What we must not do. (15 : 45/120)
    Adrian Farrel

Greg: Thanks for highlighting OAM. Its a challenge to reflect path usage
for time critical and resources, DetNet has time constraints with zero
Adrian: Yes, thanks. It is really worth people looking into what DetNet
can achieve for them.
Linda: What is semantic routing?
Adrian: Forwarding based on packet info, the proposal is to add
additional fields to the existing ones, and semantic routing would then
programme the forwarding plane, and determine packer processing

  1. Architecture : What are the possible approaches? (15 : 60/120)
    Dirk Trossen

No questions

  1. a. Using Segment Routing do achieve Semantic Routing (15 : 75/120)
    Suresh Krishnan
    Adrian: Is there a difference between the tag and the function? How
    do we distinguish between the "thing that needs to get done" and the
    "description of the packet and what it wants from the network"
    Suresh: Yes, the tag groups together packets that want similar
    Kausik: what's the key difference between SRv6 and Semantic Routing?

    Suresh: This is like one tool to deliver semantic routing
    capabilities, if something is missing then we can decide what is
    Kausik: Thats what missing, we need to identify what those are?
    Tianji: Is this considered an Overlay?
    Suresh: Think of this as an underlay, as the nodes are not aware of
    whats happening. How MPLS transport works.
    Tianji: A difference of opinion, but thanks.

  2. b. Extensible In-band Processing (EIP) (15 : 90/120)
    Stefano Salsano

Greg:Do you propose to collect path information in the trigger packet
for telemetry?
Stefano: This is an existing proposal in the IETF we are following
Greg: This is an individual I-D, so not an IETF document. Why not
collect and monitor path information using an OOB mechanism?
Stefano: Well, its good to monitor the data plane directly, we may want
to insert information drectly in the packet when it is more efficient.

Greg: This sounds like in-situ OAM?
Stefano: Yes, but this is something we are investigating, we are looking
for a more general way to meet use cases. Semantic routing and advance
path monitoring would both be supported.
Greg: I think slightly differently IOAM does not need a new header, and
it supports OOB telemetry info, or hybrid two-step.
Adrian: I would encourage continue OAM discussion between you both, but
I need to bring the discussion back to conclusions and next steps.

Closing Comments

Closing comments from Adrian: Last opportunity to discuss semantic
routing, are their applications and use cases, do have everything we
need already? There was a nice comment in the chat about putting too
much state in the network, and making the archictecture fragile. Chairs,
do you have anything to add?

Tianji: Raising initial use case in first slide deck, semantic routing
requirements and applications, I need to see the connection to 5G use
cases (such as haptic communication and holographic conferencing).

Lixia: I think the semantic routing proposal sounds interesting, one
question what identifiers do we use to identify? I want to point out
that an identifier space means one thing if you want to put multiple
definitions into the same identifier space, then it requires an
architecture discussion.

Adrian: Yes, I think you nail the issue. We need to identify what is
actually needed, and what needs to be expressed in the packet semantic.
Over to Jeff.

Jeff: My suggestion is to also follow what's going on in MPLS 2.0
developments. The pendulum swings data plane, then control plane. There
is a lot of work not published in the IETF. We need to find the right
balance. That is all for now.

Adrian: Ok, that sounds reasonable. Time is up, back to Chairs.

Jeff (as Chair): The chairs are going to work with the ADs to assess
what was presented and what could potentially be the next steps.

Closing comments from Chairs: Proponents, please work on a coherent
proposal on how you perceive the presentations, the interest, and the
potential next steps. Please talk to us.

MeetEcho Chat Log