wrote:
In line.
On 3/21/2022 6:30 AM, Ketan Talaulikar wrote:
> Hi Joel,
>
> Please check inline below.
>
>
> On Mon, Mar 21, 2022 at 2:19 PM Joel M. Halpern
mailto:j...@joelhalpern.com>
> <mailto:j...@joelhalpern.com <
rs,
Joel
On 3/20/2022 2:54 AM, Ketan Talaulikar wrote:
> Hi Joel,
>
> Please see inline below.
>
> On Sun, Mar 20, 2022 at 11:34 AM Joel M. Halpern
mailto:j...@joelhalpern.com>
> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpe
the
use of argument. Ingress PE does need to know & support the specific
behavior when it needs to supply the argument based on the behavior
definition.
Thanks,
Ketan
On Sun, Mar 20, 2022 at 10:56 AM Joel M. Halpern <mailto:j...@joelhalpern.com>> wrote:
I keep reading th
I keep reading the description of the handling of unknown endpoint
behaviors.
It seems there is an implicit assumption that I would think it would be
helpful to make explicit. As far as I can tell, a head end would never
choose based purely based on local policy to make use of an advertised
I never saw such a policy on egress PEs and I did see L3VPNs or
L2VPNs running over IP. The protection is applied on ingress you your
domain.
Thx,
R.
On Thu, Feb 17, 2022 at 5:03 PM Joel M. Halpern <mailto:j...@joelhalpern.com>> wrote:
I would presume that the general policy (w
I would presume that the general policy (which does not apply to SRv6)
that nodes should not decapsulate tunnel packets without configuration
or special exemption would mean that an arbitrary MPLS node will not
decapsualte a GRE packet and process its MPLS content. Otherwise, all
tunnels
this document provides a clear description of how and why to use the
tools we have standardized to improve operational capabilities as part
of migrating to IPv6. I support adopting this document.
Yours,
Joel
On 4/13/2021 5:36 AM, Bocci, Matthew (Nokia - GB) wrote:
Hello,
This email begins
delay, packet loos, jitter) to
provide better application performance by choosing the right underlay
that meets or exceeds the specified criteria./ Thank you very much.
Linda
-Original Message-
From: Joel M. Halpern mailto:j...@joelhalpern.com>>
Sent: Friday, July 31, 2020 6:35 AM
To: a
So Adrian does not feel like is a lone voice, let me agree publicly that
the terminology you are using is either wrong or more likely ambiguous
as to its purpose. If you really want to use the term, define it
explicitly please.
Yours,
Joel
On 7/31/2020 4:34 AM, Adrian Farrel wrote:
Hi
drafts. Again, sorry, I misread and misunderstood your note. Yes,
you referenced your draft.
On 10/6/2019 11:29 AM, Greg Mirsky wrote:
Hi Joel,
thank you for reviewing U-SID draft. I'm looking forward to reading a
more detailed analysis.
Regards,
Greg
On Sat, Oct 5, 2019 at 8:18 PM Joel M
No Greg, uSID does not bring all the benefits of SRv6 while using
shorter SIDs.
It also violates the basic IP archtiecture really abdly.
Yours,
Joel
On 10/5/2019 7:44 PM, Greg Mirsky wrote:
Hi Gyan,
you're asking very good questions and your arguments are all correct.
But I think that now
I think is a useful complement to the work in RFC 8300. It appears
ready for publication. Given the evolution in SFC usage, I think
getting this out there now serves the community better than waiting for
the implementations. Please do progress this.
Thank you,
Joel
On 4/4/19 1:58 PM,
an allowed set of SFIs
using the local policy for balancing SF load.
Hope this helps,
Adrian
-Original Message-
From: sfc [mailto:sfc-boun...@ietf.org] On Behalf Of Joel M. Halpern
Sent: 13 November 2016 09:49
To: adr...@olddog.co.uk; s...@ietf.org
Cc: bess@ietf.org
Subject: Re: [sfc
Fair enough.
In this case, what I was refering to is the combination of two
preorpties of the encoding of paths.
On teh one hand, it is extraordinarily flexible in being able to
represent a broad range of delegated choices (as well as allowing the
controller to advertise very specific things.
Trimming to those issues where I understand the disagreement enough to
comment. I would observe that what we are discussing is really SFC
definition. As such, I would like to ask that we at least copy the SFC
list (I have not done so as this is currently a BESS document.)
Yorus,
Joel
On
I had thought an earlier discussion in the SFC WG had clarified that the
decrement was by 1. Since that did not happen, I have now forwarded
that question to them.
Other comments in line.
Yours,
Joel
PS: Given the announcement, I should clarify that what I am writing here
is my personal
Some of this is going to get long for an email, but I don't see another
choice. Also, a lot of this discussion belongs in the SFC working
group. We need to figure out how to handle collaboration between IDR
and SFC for this.
Having said all that, further comments in line.
Yours,
Joel
On
Thank you authors.
Reading through this, I have a few questions.
1) I like the idea of being able to support multiple SFC overlays. I
can see circumstances when this would be valuable. However, I can not
see how it works. (I presume I am missing something obvious.) If the
SPI are unique,
Without wanting to be pedantic, I would have expected to see discusison
of this on the list, and determination that the list agreed with it.
Discussion at the meeting is informative, but is not the basis for a WG
decision.
I am also slightly concerned that the working group is creating a
19 matches
Mail list logo
