IETF 117 RTGWG

Chairs:
Jeff Tantsura (jefftant.ietf@gmail.com)
Yingzhen Qu (yingzhen.ietf@gmail.com)

WG Page: https://datatracker.ietf.org/group/rtgwg/about/
Materials: https://datatracker.ietf.org/meeting/116/session/rtgwg

##

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”.

   https://datatracker.ietf.org/doc/draft-lou-rtgwg-sinc/
   https://datatracker.ietf.org/doc/draft-lou-rtgwg-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
   https://www.ietf.org/archive/id/draft-wang-rtgwg-dragonfly-routing-problem-00.txt

   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
   https://datatracker.ietf.org/doc/draft-agt-rtgwg-dragonfly-routing/

   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
  ports/links.
• Tony Li: For routing, the word you're looking for is traffic
  engineering.
• 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
   Division
   https://datatracker.ietf.org/doc/draft-hou-rtgwg-satellite-routing-framework/

   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
  that.
• 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
   https://datatracker.ietf.org/doc/draft-mendes-rtgwg-rosa-use-cases/ 

   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
   https://datatracker.ietf.org/doc/draft-dekater-scion-controlplane/
   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
   https://datatracker.ietf.org/doc/draft-ietf-rtgwg-qos-model/
   Mahesh Jethanandani (5 mins)

• Jeff T: We'll start the review requests, and YANG doctor is one of
  them.

1. 12:10
   SRv6 Path Egress Protection
   https://datatracker.ietf.org/doc/draft-ietf-rtgwg-srv6-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
  LC.

1. 12:20
   SRv6 Midpoint Protection
   https://datatracker.ietf.org/doc/draft-chen-rtgwg-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
  list?
• 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
  reencapsulate.
• Xuesong: We removed the scenario with a transit node from the draft
  and narrowed down the scope so we thought that this requirement was
  solved.

1. 12:30
   Considerations for Protection of SR Networks
   https://datatracker.ietf.org/doc/draft-liu-rtgwg-srv6-protection-considerations/

   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
  experiences.

1. 12:40
   Update: Net2cloud Problem Statment
   https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ 

   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
   https://datatracker.ietf.org/doc/draft-dmk-rtgwg-multisegment-sdwan/

   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
   https://datatracker.ietf.org/doc/draft-mcd-rtgwg-extension-tn-aware-mobility/

   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
  treatment.
• 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.