Skip to main content

Minutes IETF117: rtgwg: Tue 16:30

Meeting Minutes Routing Area Working Group (rtgwg) WG
Date and time 2023-07-25 16:30
Title Minutes IETF117: rtgwg: Tue 16:30
State Active
Other versions markdown
Last updated 2023-08-02



Jeff Tantsura (
Yingzhen Qu (

WG Page:


9:30-11:30 - Tuesday Session I, July 25

  1. 9:30
    Meeting Administrivia and WG Update
    Chairs (10 mins)
  • Acee Lindem: I'm going to work on the YANG model as well. Waiting
    for NETMOD's non backward compatible changes discussion. Next on the
    list and will do it in RTGWG.
  1. 9:40
    “Signaling In-Network Computing operations (SINC)” and “Signaling
    In-Network Computing operations (SINC) deployment considerations”.

    David Lou (10 mins)

  • Adrian F: With CATS chair hat on, and ALTO rubber gloves on. You're
    building a SINC topology, is it dynamic?

  • David: Kind of dynamic, the nodes need to report their workload.

  • Adrian: I'm interested in getting the common metric between CATS and
    ALTO. There will be an interim between CATS and ALTO, and I'll let
    you know.
  • Jeff T: Please take a look at the technologies already developed
    here. Within Datacenter, there is not much MPLS deployment. Most DC
    use Geneve.
  • David: We'll consider that in the control part. For the 2nd, we'll
    consider adding Geneve.
  • Jeff T: This may save half of the bandwidth, will be very important.

Will coordinate with CATS on the potential Interim meeting.

  1. 9:50
    Routing mechanism in Dragonfly Networks Gap Analysis, Problem
    Statement, and Requirements

    Wenxuan Wang/Weiqiang Cheng (15 mins)

  • Andrew A: Have you checked with the RIFT work? it is not clear what
    hasn't solved yet. Second, I see you have referenced work in BIER,
    will you continue to work in BIER?

  • Weiqiang: this is just problem statement and gap analysis. We
    believe there are some potential use cases for dragonfly, don't
    intend to use dragonfly to replace RIFT. For multicast, we listed
    possible way to improve AI DC, and multicast is one possible
    solution. Whether to do it, it's an open question.

  1. 10:05
    Routing in Dragonfly+ Topologies

    Dmitry Afanasiev (20 mins)

To scale cheaper, use less links and less ports which are expensive.
many ideas come from HPC.

  • Linda Dunbar: looks like the only difference between Dragonfly
    topology and the traditional DC design is that the GW is eliminated
    and the spine nodes are directly interconnected.

  • Dmitry: Yes. Dragonfly use the second spine node to reflect traffic
    if there is no direct link between the source and destination spine
    nodes to minimize stages.

  • Linda D: At the beginning of your talk, you stated that the goal is
    to reduce the number of ports and links. But interconnecting spine
    nodes need more links.
  • Dmitry: by not fully mesh connect all the spine nodes, it needs less
  • Tony Li: For routing, the word you're looking for is traffic
  • Dmitry: yes, but with lots of states.
  • Jeff T: This is informational. It's for routing people to see how to
    solve the problem in different ways.
  1. 10:25
    Routing Framework for LEO Mega-constellation Based on Region

    Dongxu Hou (15 mins)

  • Tony Li: First question: It seems like you're routing regions
    correspond exactly to an IGP area. did you consider looking at just
    using the IGP in the hierarchical mode?

  • Dongxu Hou: Yes. At present, the routine framework is many
    improvement after existing IGP to adapt to the constellation.

  • Tony Li: What was the problem with using routing as it is?
  • Dongxu Hou: I think the Terrestrial network generally adopts the
    manner of the area division to improve the efficiency of routing and
    network management. But the existing area division method typically
    divide network into backbone area and non-backbone area. The
    backbone area is unique and has routing information of all areas.
    The backbone area is responsible for forwarding between all areas
    and require higher performance. However, the performance of
    satellites normally is peer-to-peer and limited. Especially in the
    satellite constellation. The current division method could easily
    make the backbone area congested. Besides due to the dynamics, the
    connectivity between areas can't be maintained.
  • Tony Li: Okay, well, I think you should take a look at IS-IS. It
    does not have the requirement for a backbone area. I think you might
    have more flexibility there.Second question, I know nothing about
    orbital mechanics but my understanding is there are situations where
    is the orbits are not synchronized and relationship between orbits
    are not constant. Does your solution address that issue at all?
  • DONGXU HOU: Thanks for your question. For this problem, I think the
    location of satellite in the constellation, the relative location is
    static. So we can address the satellite address and the mark. Thanks
    for your question.
  • TONY: Okay, third point, I'm Co-Chair of the TVR Working Group. Put
    my working chair hat on and say this might fall under our charter.
  • ANDREW: Routing AD. I am not sure if this fits into TVR or not and
    was my gut reaction as well. What I would say at the very least is I
    think that this should probably be presented in TVR. To get some
    thoughts and feedback out of the Working Group to ensure that if TVR
    does believe that is where it belong, let them say so. This should
    probably be taken to TVR at least for comment.
  • Jim Guichard: Routing AD. The other Working Group that I think is
    possibly could fit into is Manet. At least there should be a
    conversation to TVR and MANET, take a look at this work to see if it
    is something that would fit into those charters. So let's plan to do
  • Jeffrey Zhang: Add to what Tony said about ISIS can be without
    backbone, even OSPF supports virtual links to connect non backbone
    areas. So similar mechanism does exist in OSPF.
  • Arashmid Akhavain: This may work if you stay in one plane. But may
    break since satellites move. The goal of satellite routing is to
    route to the ground, so some addressing have to be managed. Two
    different types of routing, inter satellites, and between satellites
    and the earth. This work needs to be discussed in TVR.

  • Lin Han: Two questions. Have you considered the links state changes
    for horizontal link when the satellite move to the polar area?
    Because all horizontal links will be swapping when they move to
    polar area in about 90 minutes. That's very dynamic state changes. I
    don't think currently routing protocol can handle that. Secondly,
    all satellite may have the station connection. And the number of
    those links is huge. Starlink supports million users. Which means
    millions of the satellite links. How can you handle this network
    with low state changes with this technology?

  • Arashmid: Agreed with the previous comments. Very important to solve
    the problem.
  • Jeff T: we will talk with TVR and ADs and see where this goes.
  1. 10:40
    ROSA Use Cases and Problem Statment Update 

    Dirk Trossen (15 mins)

  • Jeff Zhang: what is the difference from CATS? CATS is trying to
    figure out which service instance to use, seems related.
  • Dirk: not necessarily Computing aware. second is traffic steering.
    CATS is more in network to steer traffic. We started from DNS,
    potentially wide area. We have more in the draft about different
    with CATS. Of course CATS might be evolving.
  1. 10:55
    SCION Control Plane
    Nicola Rustignoli (15 mins)
  • Jeff T: Besides security, how about converge time? More tangible
    data on handling failures would be useful.
  • Nicola: There is data available. We'll add to the draft.
  1. 11:10
    Overflow and Open discussions


12:00-13:30 - Friday Session II, July 28

  1. 12:00
    Meeting Administrivia
    Chairs (5 mins)

  2. 12:05
    QoS YANG Model Update
    Mahesh Jethanandani (5 mins)

  • Jeff T: We'll start the review requests, and YANG doctor is one of
  1. 12:10
    SRv6 Path Egress Protection

    Huaimo Chen/Zhibo Hu (10 mins)

  • Yingzhen: We have requested the directorate early reviews of this
    document. We hope the WG can also review this document before the
  1. 12:20
    SRv6 Midpoint Protection

    Xuesong Geng/Huaimo Chen (10 mins)

  • Jeff T: the number of times you presented the draft is not a
    decision factor to adopt the draft. If the WG thinks the documents
    should be merged, the editors should work to resolve it.

  • Huaimo: I'm still open to merge.

  • Jeff T: You need to address the issues raised before adoption.
  • Yao Liu: There are cases this solution is not working. In SRv6, only
    the end points can modify the SRH header. If there are A, B, and C.
    When C fails, packets sent to B, but B doesn't know what to do.
  • Huaimo: It's mentioned in the draft. Only end point will make the
    change. Can you put more detailed description of the problem in the
  • Yao Liu: Yes.
  • Xuesong: for the comments from Yao Liu. This was commented by Bruno
    before and addressed. We've removed the transit node behavior, and
    protection only happens from the end point. The MPLS solution is
    more mature, and the dataplane is very different. so these two
    document should stay separate.
  • Yao Liu: I don't think you addressed my question. it's not about
    violating RFC 8200. You can't do the protection.
  • Jim G: no hats on. It's true you can't modify SRH, but you can
  • Xuesong: We removed the scenario with a transit node from the draft
    and narrowed down the scope so we thought that this requirement was
  1. 12:30
    Considerations for Protection of SR Networks

    Yisong Liu / Changwang Lin (10 mins)

  • Jeff T: it's a single provider and two vendors. Would be good to get
    more operators opinions. We want to avoid specific deployment. We
    want it to be more useful. Please solicit more deployment
  1. 12:40
    Update: Net2cloud Problem Statment 

    Linda Dunbar (10 mins)

  • Jeff T: Thank you for the efforts addressing the comments. Please
    continue to improve the readability of the document.
  • Yingzhen: We'd like to encourage the WG to review the document.
  1. 12:50
    Multi-segment SD-WAN via Cloud DCs

    Kausik Majumdar (10 mins)

  • Jeff T: I recognize this as a real problem. Please social with the
    genev people with the encoding.
  • Kausik: We worked with security people on this. (Different options
    in the backup slides.)
  1. 13:00
    Extension of Transport Aware Mobility in Data Network

    Linda Dunbar (5 mins)

  • Jeff T: Practically you're mapping UDP source port to some id in
    data network. PCEP doesn't allow you to do that. You need protocol
    mapping to do that.
  1. 13:05
    Problem Statement of APN
    Shuping Peng/Zhenbin Li (10 mins)
  • Adrian Farrel: this is not about making routing decisions. This is
    about making packet treatment. Perhaps you could use red ink to make
    it clearer.
  • Shuping: It's not just about routing, it's about policy enforcement.
  • Adrian: Is there any routing in it? I think it's just about policy
  • Shuping: about traffic steering, is it considered routing?
  • Adrian: Besides the head end. Within the network, is there any
    routing decision made?
  • Shuping: it's only about steering.
  • Jeff T: Adrian has a valid point. There is an APN list, you're
    welcome to join if you're interested in this work.