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

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 03 December 2020 03:50 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205523A09E5 for <idr@ietfa.amsl.com>; Wed, 2 Dec 2020 19:50:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.817
X-Spam-Level:
X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdfEnKTSIvKO for <idr@ietfa.amsl.com>; Wed, 2 Dec 2020 19:49:57 -0800 (PST)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB423A09E0 for <idr@ietf.org>; Wed, 2 Dec 2020 19:49:55 -0800 (PST)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 3A9C9480B6; Thu, 3 Dec 2020 11:49:51 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Linda Dunbar'" <linda.dunbar@futurewei.com>, "'Acee Lindem \(acee\)'" <acee@cisco.com>, <idr@ietf.org>
References: <SN6PR13MB233415994F565A8F8B12682985F40@SN6PR13MB2334.namprd13.prod.outlook.com> <3C8F724B-DBE1-4C70-A055-9CFB822D69A9@cisco.com> <SN6PR13MB2334FE2CFBD40316F34B9B2785F20@SN6PR13MB2334.namprd13.prod.outlook.com>
In-Reply-To: <SN6PR13MB2334FE2CFBD40316F34B9B2785F20@SN6PR13MB2334.namprd13.prod.outlook.com>
Date: Thu, 3 Dec 2020 11:49:50 +0800
Message-ID: <00b401d6c927$5a64a0a0$0f2de1e0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_00B5_01D6C96A.6889DC70"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH8r9e/nAmiO3ZWM/p5gXrQtT0xXAKmlc6TAohMnO6pb3XhoA==
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZS05CSU5NSEJKQ0kZVkpNS01CTUxIQkpNSUlVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hPQ1VLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PlE6Mzo5Aj8LPjkcDANDFjEi DSpPCStVSlVKTUtNQk1MSEJJSklDVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpMT0pKTTcG
X-HM-Tid: 0a7626b874839865kuuu3a9c9480b6
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/CeCH0eE3C9wdL37XbSYjCXO8t4c>
Subject: Re: [Idr] Existing solutions in enforcing Flow based forwarding can be used by draft-dunbar-idr-5g-edge-compute-app-meta-data
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 03:50:01 -0000

Hi,Linda:

 

From: idr-bounces@ietf.org <idr-bounces@ietf.org> On Behalf Of Linda Dunbar
Sent: Thursday, December 3, 2020 10:51 AM
To: Acee Lindem (acee) <acee@cisco.com>om>; idr@ietf.org
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)?

 

Answers to your specific question are inserted below: 

 

 



 

 

From: Acee Lindem (acee) <acee@cisco.com <mailto:acee@cisco.com> > 
Sent: Wednesday, December 2, 2020 3:35 PM
To: Linda Dunbar <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com> >; idr@ietf.org <mailto:idr@ietf.org> 
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/ 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 <linda.dunbar@futurewei.com <mailto:linda.dunbar@futurewei.com> >
Date: Tuesday, December 1, 2020 at 1:21 PM
To: Acee Lindem <acee@cisco.com <mailto:acee@cisco.com> >, IDR List <idr@ietf.org <mailto:idr@ietf.org> >
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://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