cloud resources."
Yours,
Joel
On 9/21/2023 2:28 PM, Linda Dunbar wrote:
Joel,
Thank you very much for the additional comments.
Resolutions to your comments are inserted below:
Linda
-Original Message-
From: Joel Halpern
Sent: Wednesday, September 20, 2023 5:45 PM
To: draft-ietf-rtg
ote:
Joel,
I see your points. Please see my explanation below quoted by .
*From:* Joel Halpern
*Sent:* Monday, August 21, 2023 11:34 PM
*To:* Linda Dunbar
*Cc:* rtgwg-chairs ;
draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org; rtgwg@ietf.org
*Subject:* Re: Need your help to make sure
are not aggregated
nicely, which is very common, one single site failure can trigger a
huge number of BGP UPDATE messages. There are proposals, such as
[METADATA-PATH], to enhance BGP advertisements to address this problem.”/
//
Linda
*From:* Joel Halpern
*Sent:* Tuesday, August 22, 2023 6:03 PM
Thank you Linda. Trimmed the agreements, including acceptable text from
your reply. Leaving the two points that can benefit from a little more
tuning.
Marked
Yours,
Joel
On 8/22/2023 12:12 AM, Linda Dunbar wrote:
Similarly, section 3.2 looks like it could apply to any operator.
If by "on-path" we mean an edge device using higher level information to
tunnel packets to the intended egress edge, then I understand what is
beign asked.
However, if this is read in any way to mean that the edge computing
properties are to be injected into underlay routing burdening all
If CAN does isntance selection and DSCP marking, then it can influence
routing and select appropraite instances. It is an understandable,
deployable, and probably scalable solution with the selection and
marking deployed at an appropriate place. If that place is the PE, and
we want to use a
Agreed on both points. Those milestones are pretty aggressive. Also,
until we have actually progressed the problem statement I do not see how
a working group could adopt a solution.
So, in light of the discussion about avoiding assuming answer, i think
the interesting target would be a date
One of the arguments made in these documents seems to be that by using
this technology you can reduce latency by skipping the DNS step.
I do not see how that works. Are you assuming that applications will
have the anycast address for a given service hard coded? And that all
operators
(It took me a minute to find this to respond, as you left the old
subject line in place.)
The most interesting thing I can see in the gap analysis is the
expectation that applications will explicitly indicate the affinity
grouping of packets. I can understand wanting such, although there is
My reading as shepherd of the inclusion of the mitigation references was
that it constituted a fair effort to recognize that the community hadd
not and was not ignoring these issues, and that any effort to better
address the issues should be aware of the existing mitigation efforts.
As an
10 matches
Mail list logo
