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]>]

Ai Jun,

Thank you very much for the comments.

You said:
[WAJ] It seems the BGP best path selection procedures should be changed based upon the additional information? There is no such description within the document.

The current BGP best path selection procedure is based on the “metrics from IGP”, the “LocalPrefence”, and some forms of configured “Weight”. The change can be very minimal, for example,  making the Weight be derived from the additional information. We will add a section to explain it, as Stephane Litkowski also pointed out this issue at the IETF 109 IDR session.

You said:

And on the other hand, even the Ra select the best egress router(for example R1), the final forward path(from Ra to R1) may not be optimal because there is IGP between them. Why not carry these information within the IGP, as your other proposed draft(https://tools.ietf.org/html/draft-dunbar-lsr-5g-edge-compute-ospf-ext-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext-01&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C7a48c27109fd48835c2a08d8973e7f9c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637425641994243677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gh9KM37hHIAM0oqZNA7Z3l5RhFx87DPc5bpl3lVpoNg%3D&reserved=0>)?

The algorithm for Ra to select the optimal egress router does  need IGP information.  We haven’t got around to update the https://tools.ietf.org/html/draft-dunbar-lsr-5g-edge-compute-ospf-ext-01 per LSR chair’s comment. Will do this coming week.

Thank you very much
Linda
From: Aijun Wang <[e-mail]>
Sent: Wednesday, December 2, 2020 9:50 PM
To: Linda Dunbar <[e-mail]>; 'Acee Lindem (acee)' <[e-mail]>; [e-mail]
Subject: RE: [Idr] Existing solutions in enforcing Flow based forwarding can be used by draft-dunbar-idr-5g-edge-compute-app-meta-data

Hi，Linda:

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> On Behalf Of Linda Dunbar
Sent: Thursday, December 3, 2020 10:51 AM
To: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] Existing solutions in enforcing Flow based forwarding can be used by draft-dunbar-idr-5g-edge-compute-app-meta-data

Acee,

In the figure below: 3 App servers for S1 (ANYCAST address) are attached to R1, R2 and R3 respectively. R1/R2/R3 are called the App Server Egress routers In the draft-dunbar-idr-5g-edge-compute-app-meta-data.

Ra/Rb are the ingress routers to Local Data Network (the N6 interface in 3GPP spec). There can be many hops between  Ingress routers and Egress routers. They are similar to EVPN’s edge nodes.
The proposed NLRI App-Meta-data SubTLV is for App Server Egress routers to advertise the LoadIndex & SitePreference & SiteCapacity  to the ingress routers.
When Ra determines R1 is the optimal location for a flow from UE-1 to S1, Ra tunnels the packets from UE1 to R1. So all the immediate nodes don’t see S1.
[WAJ] It seems the BGP best path selection procedures should be changed based upon the additional information? There is no such description within the document.
And on the other hand, even the Ra select the best egress router(for example R1), the final forward path(from Ra to R1) may not be optimal because there is IGP between them. Why not carry these information within the IGP, as your other proposed draft(https://tools.ietf.org/html/draft-dunbar-lsr-5g-edge-compute-ospf-ext-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-ospf-ext-01&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C7a48c27109fd48835c2a08d8973e7f9c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637425641994243677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Gh9KM37hHIAM0oqZNA7Z3l5RhFx87DPc5bpl3lVpoNg%3D&reserved=0>)?

Answers to your specific question are inserted below:


[cid:image001.png@01D6C96D.5CA16E70]


From: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, December 2, 2020 3:35 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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).
[Linda] There can be many hops between Ra and R1/R2/R3. Ra tunnels the packets to R1, all the immediate nodes only see unicast address of R1.

Otherwise, your assumption of the routing decision being made solely in the 5G site router doesn’t hold.
[Linda] The path selection is by the router adjacent to the 5G PSA (part of the UPF)
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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-6man-5g-edge-compute-sticky-service%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C7a48c27109fd48835c2a08d8973e7f9c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637425641994243677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Nc%2Bre%2BCIA6fZQNokzdXSb1mvoihMwY7i11aZNYdrzlA%3D&reserved=0> describe the approach for ingress node to stick one flow to the same location even after the UE anchored to a new PSA (i.e. moved to a new 5G site).

Please let me know if I have answered all your concerns.

Thanks, 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%7C7a48c27109fd48835c2a08d8973e7f9c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637425641994253673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SjJSROh6XyWspGEV1CM6olQz6WNvQzIfeRcemrRCQww%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%7C7a48c27109fd48835c2a08d8973e7f9c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637425641994253673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ieF4wWGhhWNEUF%2FY13agjc%2FgAN0uHkN8tFD54OVz2lQ%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