Re: [Idr] Existing solutions in enforcing Flow based forwarding can be used by draft-dunbar-idr-5g-edge-compute-app-meta-data

[Linda Dunbar <[e-mail]>]

Acee,

We are in the process of revising the draft. I listened to the IETF109 recording again and plan to revise the draft per your comments.

We will add the assumption about  the 5G Edge Computing environment to the revised draft:  it is a confined network, not the general Internet. In this environment, it is assumed that the egress routers to which the Edge servers are attached belong to the same operator as ingress routers. Between the egress router and the servers, there might be another Virtual switch (or top of rack switch), but they are co-located.

[cid:image002.png@01D6FFEF.8BD2C140]

With those assumptions in mind, my answers to your questions are inserted below:


From: Acee Lindem (acee) <[e-mail]>
Sent: Wednesday, December 2, 2020 3:35 PM
To: Linda Dunbar <[e-mail]>; [e-mail]
Subject: Re: Existing solutions in enforcing Flow based forwarding can be used by draft-dunbar-idr-5g-edge-compute-app-meta-data

Hi Linda,

There are a couple limitations here that need to be covered in the draft. The first is that you are assuming the anycast servers are all attached to a router one hop away (or at least on a path where the first hop will always on the shortest path to the same instance of an anycast server). Otherwise, your assumption of the routing decision being made solely in the 5G site router doesn’t hold.
[Linda] Yes, there are limitation. The assumption is that 5G Edge Computing network is a confined network, not the general Internet.  There might be Virtual switch (or top of rack switch) between the egress routers and the servers, but they are co-located in the Edge Computing mini data centers.

Second, when there is a handover from the Site A router to the Site B router, how does the Site B router know which instance of the anycast server the UE was bound to on the Site A router? I guess it doesn’t without some design.
[Linda] https://datatracker.ietf.org/doc/draft-dunbar-6man-5g-edge-compute-sticky-service/ described the approach for Site B Ingress router to discover the flow should stick to the Site A server.

Thank you very much, Linda

Thanks,
Acee

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 1, 2020 at 1:21 PM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>, IDR List <[e-mail]<mailto:[e-mail]>>
Subject: Existing solutions in enforcing Flow based forwarding can be used by draft-dunbar-idr-5g-edge-compute-app-meta-data

Acee,

You asked a question on how to enforce one flow to be nailed towards the same location for an ANYCAST address during the IETF 109 IDR Friday session.
Here are some links showing that the commercial routers already support the feature, a.k.a. Flow Affinity, or Flow-based load balancing.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/lanswitch/configuration/xe-3s/lanswitch-xe-3s-book/lnsw-flow-portchannel-load.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Ftd%2Fdocs%2Fios-xml%2Fios%2Flanswitch%2Fconfiguration%2Fxe-3s%2Flanswitch-xe-3s-book%2Flnsw-flow-portchannel-load.html&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C0b90845aa45f400e455c08d8970a5394%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637425417898549584%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VBY6rgIaAD9GlJvHH2ru1Dvd6SEy8jdnH5pbRzjqiSg%3D&reserved=0>
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/data-flow-affinity-edit-chassis.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.juniper.net%2Fdocumentation%2Fen_US%2Fjunos%2Ftopics%2Freference%2Fconfiguration-statement%2Fdata-flow-affinity-edit-chassis.html&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C0b90845aa45f400e455c08d8970a5394%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637425417898559538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RdIFXWipGwCOAz5pwFzbFeKdbolPfW1TRP2BdD1v6nY%3D&reserved=0>

draft-dunbar-idr-5g-edge-compute-app-meta-data states that the ingress node, i.e. the router Ra/Rb which are adjacent to 5G UPF (or Packet Session anchor point-PSA), can use Flow ID (in IPv6 header) or UDP/TCP port number combined with Source Address in IPv4  to enforce packets in one flow being placed in one tunnel to one Egress router, such as R1, R2, or R3 in the figure below.  All other nodes in the network don’t need to take any extra action.
Does it address your concern?

+--+
|UE|---\+---------+                 +------------------+
+--+    |  5G     |    +---------+  |   S1: aa08::4450 |
+--+    | Site +--++---+         +----+                |
|UE|----|  A   |PSA| Ra|         | R1 | S2: aa08::4460 |
+--+    |      +---+---+         +----+                |
  +---+    |         |  |           |  |   S3: aa08::4470 |
  |UE1|---/+---------+  |           |  +------------------+
  +---+                 |IP Network |       L-DN1
                     |(3GPP N6)  |
  |                  |           |  +------------------+
  | UE1              |           |  |  S1: aa08::4450  |
  | moves to         |          +----+                 |
  | Site B           |          | R3 | S2: aa08::4460  |
  v                  |          +----+                 |
                     |           |  |  S3: aa08::4470  |
                     |           |  +------------------+
                     |           |      L-DN3
+--+                 |           |
|UE|---\+---------+  |           |  +------------------+
+--+    |  5G     |  |           |  |  S1: aa08::4450  |
+--+    | Site +--++-+--+        +----+                |
|UE|----|  B   |PSA| Rb |        | R2 | S2: aa08::4460 |
+--+    |      +--++----+        +----+                |
+--+    |         |  +-----------+  |  S3: aa08::4470  |
|UE|---/+---------+                 +------------------+
+--+                                     L-DN2
Figure 1: App Servers in different edge DCs
Thank you very much
Linda Dunbar