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
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 the
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 d
(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 a
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 providi
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.
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
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
*To
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
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 info
you expected / wanted / sought?
2) Can you help us understand what wording in the document led to that
expectation, so we can clarify the document?
Thank you,
Joel Halpern (document Shepherd)
On 9/11/2024 11:56 AM, Mike Ounsworth wrote:
Hi Linda,
Alright, you’ve rejected every one of my
and relaxing subnet boundaries
should be done with extreme caution. In that this is a problem
statement document, I’m sure there is something you can say in each
section to this point.
---
*Mike*Ounsworth
*From:*Joel Halpern
*Sent:* Wednesday, September 11, 2024 7:14 PM
*To:* Mike Ounsworth ;
statement and requirements document, we need to add them to the
milestones, so we should have a clear understanding of the scope of
the requirements document. A new topic may have only a problem
statement document.
Thanks,
Yingzhen
On Tue, Nov 12, 2024 at 7:12 AM Joel Halpern wrote:
I wonder if
I wonder if the dispatch and incubation function would be clearer if
RTGWG allowed for work on problem statements, but explicitly deferred
requirements development to wherever the work is dispatched? If the
expertise is e.g. in IDR, SPRING, LSR, it seems they should do the
requirements develop
I should also point out that years ago the I2RS effort looked at
creating transient state in routers, and concluded that YANG could be
used for that task, even with the responsiveness requirements.
Yours,
Joel
On 3/19/2025 12:38 AM, Joel Halpern wrote:
My understanding is that part of the
e the argument in the draft, not that you need to convince me.
Yours,
Joel
On 3/19/2025 1:53 AM, Zafar Ali (zali) wrote:
Hi Joel
As this is for ephemeral state, the consistency check with the
configuration is not required.
Thanks
Regards … Zafar
*From: *Joel Halpern
*Date: *Wednesday, Mar
Regards … Zafar
*From: *Joel Halpern
*Date: *Saturday, March 8, 2025 at 2:10 PM
*To: *Zafar Ali (zali) , rtgwg@ietf.org
, spr...@ietf.org
*Subject: *Re: [rtgwg] RPC for programming ephemeral routing states
One thing I missed in reading this draft is why this was better than
existing tools
One thing I missed in reading this draft is why this was better than
existing tools, e.g. YANG over RESTCONF. For which we know the
integration with the rest of the operational environment. (I can
believe there is an advantage, but I couldn't tell what it was.)
Yours,
Joel
On 3/8/2025 1:04
Cloud DCs
Reviewer: Joel Halpern
Review result: Not Ready
Hello
I have been selected to do a routing directorate “early” review of
this draft.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-multisegment-sdwan%2F&data=05%
2] for the proposed resolutions. Let us know if they
are acceptable.
Linda
*From:*Joel Halpern
*Sent:* Thursday, July 17, 2025 6:50 PM
*To:* Linda Dunbar ; rtg-...@ietf.org
*Cc:* draft-ietf-rtgwg-multisegment-sdwan@ietf.org; rtgwg@ietf.org
*Subject:* Re: draft-ietf-rtgwg-multisegment
[Linda3] . Please let
me know if they are acceptable.
Thank you,
Linda
*From:*Joel Halpern
*Sent:* Wednesday, July 30, 2025 7:38 AM
*To:* Linda Dunbar ; Joel Halpern
; rtg-...@ietf.org
*Cc:* draft-ietf-rtgwg-multisegment-sdwan@ietf.org; rtgwg@ietf.org
*Subject:* Re: draft-ietf-rtgwg
segment to reach a
distant CPE through transit Cloud GWs without decryption. It supports
hybrid traffic handling: local cloud-bound traffic is decrypted by the
Cloud GW, while CPE-to-CPE traffic is forwarded securely across the
backbone./
//
//
Linda
*From:*Joel Halpern
*Sent:* Thursday
Document: draft-ietf-rtgwg-multisegment-sdwan
Title: Multi-segment SD-WAN via Cloud DCs
Reviewer: Joel Halpern
Review result: Not Ready
Hello
I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/
The
23 matches
Mail list logo
