Les,
With regard to what You said about “needing to do load balancing at the
Application Layer – not at Layer 3”:
Answer: Most deployments could have 10s, 100s, or even thousands of Application
Layer load balancers. The proposed solution is to utilize network layer and
resource capability information to balance the distribution of traffic among
the Application Load balancers. The documents stated that the distribution
behind the load balancers are out of the scope.
With regard to what you said about “oscillation”:
Answer: The rate of capability index changes is in terms of hours or days, more
like the link failure that IGP is intended to distribute. Therefore, the
oscillation is not the issue.
With regard to what you said about “incorrect TLV”
Per IANA: TLV 128 is for IP Int. Reachability; TLV 130 is for IP Ex Address;
and TLV 135 is for Extended IP reachability.
Do you mean another TLV should be used instead of TLV 128/130/135?
For the AggCostSubTLV, yes, the prefix shouldn’t be there. It is now changed to
be consistent with OSPF:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AggCostSubTLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AggCost to the App Server |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Aggregated cost Advertisement in IS-IS
Any other issues?
Linda
From: Les Ginsberg (ginsberg) <[email protected]>
Sent: Tuesday, January 11, 2022 11:14 PM
To: Linda Dunbar <[email protected]>; [email protected]
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda -
From: Linda Dunbar
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, January 11, 2022 7:47 PM
To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Les,
Starting with a clean slate:
Problem:
Most applications are instantiated at multiple locations to achieve optimal
performance. Traditional shortest path to reach one single destination is
making load balancers the bottleneck, or pushing the traffic management
responsibility to DNS.
From Underlay IP network perspective, connecting applications with instances
instantiated at multiple locations is like having multiple Egress routers
towards the same destination (ANYCAST).
For example, to reach an application B instantiated at B1, B2, B3, which
corresponds to egress ER1, ER2, ER3 respectively, the Shortest Path
Computation need to include both routing distance and the resources attached to
ER1, ER2, ER3. i.e. the cost in the ECMP (Equal Cost Multiple Path) should
include both the routing distances and the resource cost.
[LES:] What I am saying is that you need to do load balancing at the
Application Layer – not at Layer 3.
IGPs can provide you with paths to the set of Application servers that share
the same anycast address – but dynamically manipulating the IGP metrics (even
this new metric you propose) – will give you oscillation – not application
server load balancing.
Suggested solution:
Using TLV 128 and 130 to carry the “aggregated site cost” (associated t the
Egress router) is suggested by Peter Psenak (through the offline discussion
prior to the IETF 112, see the attached email thread)
There is only one sentence in the Section 6, which is per Peter’s suggestion:
“Aggregated Cost appended to the IP Reachability TLV: 128, 130, or 135.”
Why do you say it is a “mess”? I felt your words are more like personal
attack than giving a constructive suggestion.
[LES:] Apologies if you were offended – I did put a smiley in to try give it a
light touch – but I should know better than to be so flippant in this context.
My point is that in what is indeed a very small section there are multiple
errors:
* The TLVs mentioned are not correct
* The diagram with the proposed sub-TLV encoding incorrectly includes the
prefix. The prefix is already present in the parent TLV – it should not be
present in the sub-TLV. You have this correct in Section 5 for OSPF.
But these points can be ignored because I believe using the IGPs isn’t the
right solution and so we won’t need these new sub-TLVs anyway.
I don’t know what comment from Peter you are referring to – but if he mentioned
TLVs 128/130 I will take that up with him – he knows better. 😊
I do recall that in an earlier version of the draft you were proposing to
advertise the new metric as part of a link advertisement (TLV 22) – and he was
quite correct in directing you to use Prefix Reachability advertisements (like
TLV 135).
But please focus on looking at a non-IGP solution – that is what you need to do
IMO.
Les
Linda
From: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>
Sent: Monday, January 10, 2022 9:48 AM
To: Linda Dunbar
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: RE: Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
Linda –
I believe the most valuable feedback you received during your presentation at
IETF 112 is that using IGPs likely will not meet the deployment requirements.
In particular, persistence of a given client session with a given application
server is likely a requirement which will not be achieved using an IGP based
solution.
Also, the modification of IGP metrics will likely introduce unwanted
oscillation in traffic flows.
I suggest you start with a clean slate – focus on defining what all the
requirements are without regard to what mechanism/protocol might be used – and
then think about defining a solution which meets these requirements.
I think you will end up NOT using routing protocols at all.
On a more mundane note, the section describing the new IS-IS advertisement
(https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dunbar-lsr-5g-edge-compute-03%23section-6&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4e790860cb7e40ff9cac08d9d58a7534%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637775612935452545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=W9%2FRpPfP4JXon%2F5kAftUxpjZjQzjgHkephRs5StyCqE%3D&reserved=0>
) is – to put it bluntly – a mess! 😊
TLVs 128 and 130 are legacy TLVs which don’t support sub-TLVs – they should not
be mentioned at all.
And the encoding diagram shows a “prefix” being advertised in the new sub-TLV
when it should not. The prefix has already been advertised in the parent TLV.
Les
From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of
Linda Dunbar
Sent: Friday, January 7, 2022 11:29 AM
To: [email protected]<mailto:[email protected]>
Subject: [Lsr] Seeking feedback to the revised draft-dunbar-lsr-5g-edge-compute
LSR experts,
We have revised the draft-dunbar-lsr-5g-edge-compute to address the comments
and feedback from IETF 112.
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-lsr-5g-edge-compute%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C4e790860cb7e40ff9cac08d9d58a7534%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637775612935452545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=C02rBS0oFyNztREkN2lMaCKTL%2BUfOJIZ2zHJl%2FFA2Cw%3D&reserved=0>
In a nutshell, the proposed solution
* advertises the “Site-Cost” via IP prefix reachability TLV associated with
the (anycast) prefix
The Site-Cost is the aggregated cost associated with an Edge Compute (EC)
server (i.e., ANYCAST prefix), computed based on the IP layer related metrics
for the prefix, such as Load Measurement, the Capacity Index, the Preference
Index, and other constraints by a consistent algorithm across all egress
routers to which the EC servers are attached.
* Uses a Flag in the Flexible Algorithm TLV to indicate that “site-cost”
needs to be included for the constrained SPF to reach the Prefix
Any feedbacks? Or suggestions?
Thank you very much
Linda
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
