Hi,
I believe that Section 6.5 is sufficient as-is. Note that I have
raised my concerns about the L4 checksum issue in previous versions of
the draft, and I believe the current text in Section 6.5 resolves my
concerns.
Regarding the middlebox discussion, I have not seen (please correct me
if I
On Thu, Apr 4, 2024 at 2:50 PM Francois Clad wrote:
> An SRv6-unaware middlebox will not be able to verify the upper-layer checksum
> of SRv6 packets in flight, regardless of whether an SRH is present or not.
> An SRv6 and C-SID aware middlebox will be able to find the ultimate DA and
> verify
I am not aware of any IPRs that are related to this document.
Cheers,
Tal.
On Tue, Apr 2, 2024 at 7:24 PM Joel Halpern wrote:
>
> Can the authors (and listed contributors) please confirm to the working
> group email list that all IPR believed to be relevant which is known to
> the author (or
Dear Andrew,
A couple of questions regarding the middlebox use case.
1. I am curious to know whether there are existing middleboxes that
can verify the L4 checksum for packets with an SRH.
2. Can a middlebox verify the L4 checksum of a packet with an SRH *in
compliance with RFC 8200*?
RFC 8200
Dear authors,
A couple of questions:
1. Why not decouple the IPv6 path tracing option from SRv6? It does
not seem to be strictly SRv6 related. You could potentially define the
relevant SRv6 endpoint behavior in a separate draft.
2. Would it be possible to use the ICMPv6 Loopback message with an
ahead and open
> one please.)
>
> Yours,
>
> Joel
>
> On 8/3/2023 2:54 AM, Tal Mizrahi wrote:
> > Hi Joel,
> >
> > I agree that this may be a corner case, but it still needs to be covered.
> > As you pointed out, the compression document shou
ntext and
> compute transport layer checksums per the requirements of RFC8200.
>
> Tom
>
> On Thu, Aug 3, 2023 at 12:02 AM Tal Mizrahi wrote:
> >
> > Hi,
> >
> > This new draft introduces a proposed update to [RFC8200], which is
> > intended to address
In my opinion the suggested approach is the most reasonable approach
at this point, and therefore the issue can be closed.
Cheers,
Tal.
On Tue, Aug 1, 2023 at 12:08 AM Joel Halpern wrote:
>
> As per the discussions on list and at IETF 117, the SPRING WG chairs (myself
> and Alvaro
Hi,
This new draft introduces a proposed update to [RFC8200], which is
intended to address compressed segment lists in SRv6
[draft-ietf-spring-srv6-srh-compression].
Link to the new draft:
https://datatracker.ietf.org/doc/draft-mizrahi-spring-l4-checksum-srv6/
There was some discussion in the
o this?
> Probably. Please suggest text.
>
> Is this a corner case that I personally consider quite rare? Yes,
> although it was the original excuse for the authentication TLV.
>
> Yours,
>
> Joel
>
> On 8/2/2023 1:58 AM, Tal Mizrahi wrote:
> > Darren, Authors
/en/group/rtg/RtgDir
Document: draft-ietf-rtgwg-srv6-egress-protection-11
Reviewer: Tal Mizrahi
Review Date: August 2, 2023
Intended Status: Standards Track
Summary:
I have concerns about this document. It needs more work before being
submitted to the IESG.
Main comments:
- Reading the document
ination Address used in the
pseudo-header is the address that is expected to be received
by the destination.
Cheers,
Tal.
On Tue, Aug 1, 2023 at 6:46 PM Darren Dukes (ddukes) wrote:
>
> That is correct.
>
> From: spring on behalf of Tal Mizrahi
>
Dear Authors,
I have a question regarding the following two paragraphs from the
draft (at the bottom of the message).
If I understand the text correctly, if the compressed segment list
fits into a single SID, then the entire compressed list can be encoded
in the DA, and the packet can be sent
Dear authors,
Thanks for sharing this interesting draft.
Per-hop measurement and reporting is a very important OAM tool, and
there is quite a bit of ongoing / previously proposed work in the IETF
about this topic.
A few comments:
1. It looks like the draft defines two aspects: (a) the path
ue, Dec 8, 2020 at 10:13 PM Yingzhen Qu wrote:
>
> Hi Tal,
>
> Thank you for your review and comments, we have published version -29 to
> address your comments. Please see my detailed answers below inline.
>
> Thanks,
> Yingzhen
>
> On Tue, Dec 8, 2020 at 3:52 AM Ta
that you receive, and strive to resolve them
through discussion or by updating the draft.
Document: draft-ietf-spring-sr-yang-28
Reviewer: Tal Mizrahi
Review Date: 08-Dec-2020
Intended Status: Standards Track
Summary:
I have some minor concerns about this document that I think should be
resolved
, May 23, 2016 11:55 PM
To: Tal Mizrahi
Cc: draft-ietf-nvo3-gen...@tools.ietf.org;
draft-ietf-nvo3-vxlan-...@tools.ietf.org; spring@ietf.org; 6man WG;
n...@ietf.org; draft-ietf-6man-segment-routing-hea...@tools.ietf.org; Stefano
Previdi (sprevidi)
Subject: Re: [nvo3] [spring] L4 Checksum and
draft
to avoid ambiguity, it would be great if the authors could explicitly
mention that IPv6 extension headers are permitted.
Regards,
Tal.
From: rras...@gmail.com [mailto:rras...@gmail.com] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:47 AM
To: Tal Mizrahi
Cc: spring@ietf.org; 6man WG; draft
,
Tal.
>-Original Message-
>From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Tal Mizrahi
>Sent: Tuesday, May 17, 2016 12:09 PM
>To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
>gen...@tools.ietf.org; draft-ietf-nvo3-vxlan-...@tools.ietf.org
>Cc:
.
Thanks,
Tal.
>-Original Message-
>From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
>Sent: Tuesday, May 17, 2016 10:41 AM
>To: Tom Herbert
>Cc: Tal Mizrahi; 6man WG; spring@ietf.org; draft-ietf-6man-segment-routing-
>hea...@tools.ietf.org
>Subject: Re:
nd, it would be great if the draft
would specify it.
Thanks,
Tal.
>-Original Message-
>From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
>Sent: Monday, May 16, 2016 2:13 PM
>To: Tal Mizrahi
>Cc: Ole Trøan; draft-ietf-6man-segment-routing-hea...@tools.ietf.org;
&g
SR domain ingress router encapsulating a received IPv6 packet
into an outer IPv6 header followed by an SRH.
Will appreciate if you can clarify that.
Thanks,
Tal.
>-Original Message-
>From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com]
>Sent: Monday, May 16, 2016 1
to:otr...@employees.org]
>Sent: Sunday, May 15, 2016 9:07 PM
>To: Tal Mizrahi
>Cc: draft-ietf-6man-segment-routing-hea...@tools.ietf.org; spring@ietf.org;
>6man WG
>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-
>header
>
>Tal,
>
>> [Apologies
. Otherwise, the L4
Checksum may be located in a pretty deep location.
Speaking from a chip vendor's perspective this may be a problem.
Thanks,
Tal Mizrahi.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
24 matches
Mail list logo
