Internet DRAFT - draft-wang-dyncast-centralized-service-routing
draft-wang-dyncast-centralized-service-routing
Internet Engineering Task Force X. WANG
Internet-Draft Ruijie Networks
Intended status: Informational 9 February 2023
Expires: 13 August 2023
Centralized service routing solution for dyncast
draft-wang-dyncast-centralized-service-routing-00
Abstract
This document introduces a centralized service routing solution for
dyncast architecture, which will improve the network scability and
avoid the traffic loop problem.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 August 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
WANG Expires 13 August 2023 [Page 1]
Internet-Draft Abbreviated Title February 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Session scale and scalbility problems . . . . . . . . . . 2
1.2. Service traffic loop problem . . . . . . . . . . . . . . 3
2. Centralized service routing solution for Dyncast . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
[I-D.li-dyncast-architecture]provides a easy-deployed architecture to
do optimal service traffic steering through a combination of
networking and computing related metrics, to improve service
performance of the edge services. Dyncast locates on an overlay
layer above IP, in this layer the service routing is based on the
service ID(D-SID), which indicates the ingress D-Router to lookup
some kind of service forwarding table indexed by D-SID, and
encapsulate the service packets into an overlay path towards to the
best Egress D-Router, then the Egress D-Router decapsulate the
overlay header and also need to lookup service forwarding table based
on the D-SID to get the best service instance, for the Egress
D-router always attached more than one service instance. Summing up
the Dyncast architecture indicates a distributed service routing
decision. The Ingress and Egress D-Router both require to do service
routing decisions based on D-SID. The distributed decision
architecture will incur some problems described below.
1.1. Session scale and scalbility problems
Just as described by 4.4. section of [I-D.li-dyncast-architecture],
the instance affinity is one of key features that Dyncast should
support. In order not to affect the line-rate forwarding of services
instance affinity approach should be some kind of “on-path”ones. An
generic approach is make service routing device to creat and maintain
an instance affinity table, in which each item is a corresponding
relation between the service request from a user and the nexthop
destinated to the service instance to serve it. So the instance
affinity table is in the scale of user numbers multiplied by service
numbers. The requirement for scale of the instance affinity table
would be a very important evaluation parameters of different CAN [I-
D.liu-can-ps-usecases] routing architectures.
WANG Expires 13 August 2023 [Page 2]
Internet-Draft Abbreviated Title February 2023
As a distributed routing decision architecture Dyncast requires both
the Ingress and Egress D-Router to do service routing decision based
on D-SID, corresponding both of them also require to maintain the
instance affinity table. The Ingress D-Router normally only attaches
local users, the instance affinity table also refers to the local
users’ services, the scale of the table should be under-controlled.
Whereas the Egress D-Router needs to serve all the remote users who
are assigned to the service instances attached to the Egress, and the
instance affinity table scale would be huge, so making the Egress
D-Router maintaining the instance affinity table is not a good
choice.
In addition, as the further deployment of edge services and the
increase of the attach users, we need to consider the scalibility of
the instance affinity table. E.g.,if the Ingress D-Router(e.g.,PE
router) is overloaded by the increased users, it could distribute its
instance affinity table to some of its lower routers(e.g., CPE
router), because the CPE and the Egress are located at different AS,
the CPE is hard to get the direct routing to the Egress, still
requires to first route to Ingress, then to Egress. So the Ingress
still requires to maintain the instance affinity table, which can not
be sunk.
1.2. Service traffic loop problem
A common problem of the distributed routing algorithms is the traffic
loop problem incurred by inconsistent status among different routing
devices on the moment of network failure. After the control plane
convergence is finished, the loop problem is solved automatically.
Although the duration of the loop is not very long, the bad efforts
can’t be ignored and some algorithms(e.g., Ti-LFA) are defined to
address the loop issue.
In Dyncast environment, because of presence of instance affinity,the
loop can’t be eliminated even after the control plane has converged.
Therefore, the traffic loop will always be there, which will
introduce huge waste of network resources and the failure of service
request.
Indeed we could also define some rules to avoid the traffic loop
issue. If a practical technology of Dyncast overlay is VPN, e.g.,
EVPN, we can intrdoce the horizontal splitting mechanism of EVPN VPLS
into the EVPN L3VPN, and avoid forwarding from overlay tunnel to
another overlay tunnel. Whereas this will introduce signficant
complexity to L3VPN and also do not comply with the principle of L3
routing.
WANG Expires 13 August 2023 [Page 3]
Internet-Draft Abbreviated Title February 2023
2. Centralized service routing solution for Dyncast
Dyncast is a very nice and easy-deployed architecture based on
anycast routing algorithms. Compared with the distributed routing
decision, we recommend a centralized service routing decision
solution for Dyncast.
The ingress D-Router acts as the sole node to do the service routing
decision based on D-SID, and translates the service packets
destination address from D-SID to D-BID, then encapsulates into an
overlay path to an Egress D-Router. The Egress D-Router does the
routing decision directly based on D-BID.
Therefore, the D-BID also needs to be distributed to the overlay
network.
The reverse service workflow is symmetric, corresponding the same
D-Router required to do the service packets source address translated
from D-BID to D-SID, for the consistency of traffic to/from a
D-Router.
For the service routing decision based on D-SID is performed solely
centralized on the Ingress D-Router, only the Ingress D-Router needs
to maintain the instance affinity table. After the service instance
has been affinitied at the Ingress D-Router and carried on the
service packets(destination address), the Egress D-Router does not
need to maintain the affinity table and could directly get the
instance affinity relation from the packets.
Also due to the solely Ingress decision characteristics, the instance
affinity table scalibility just as described at 1.1. section could be
easily achieved by sinking it to the CPE devices.
Again, for the single node decision characteristics, the service
traffic loop problem is naturally non-existance. Indeedly during the
control plane convergence period, the service rouing decision perhaps
is not “best”if the ingress have no the newest network or computing
status information.
3. IANA Considerations
This memo includes no request to IANA.
4. Security Considerations
This document should not affect the security of the Internet.
5. References
WANG Expires 13 August 2023 [Page 4]
Internet-Draft Abbreviated Title February 2023
5.1. Informative References
[I-D.liu-can-ps-usecases]
Liu, P., Eardley, P., Trossen, D., Boucadair, M.,
Contreras, LM., Li, C., and Y. Li, "Computing-Aware
Networking (CAN) Problem Statement and Use Cases", 2022,
<https://www.ietf.org/archive/id/draft-liu-can-ps-
usecases-00.txt>.
[I-D.li-dyncast-architecture]
Li, Y., Iannone, L., Trossen, D., Liu, P., and C. Li,
"Dynamic-Anycast Architecture", 2023,
<https://www.ietf.org/archive/id/draft-li-dyncast-
architecture-08.txt>.
Author's Address
Xuewei Wang
Ruijie Networks
Beijing
China
Email: wangxuewei1@ruijie.com.cn
WANG Expires 13 August 2023 [Page 5]
