Hi All,
As I have repeatedly stated in spring and will state so again here. In certain
circumstances the use of C-SID breaks the checksums as relates to transit
nodes. RFC8200 lays out specific processing rules for upper-layer checksums,
and expressly deals with scenarios where there is a
From: jmh.direct
Sent: Thursday, April 4, 2024 8:26:22 PM
To: Francois Clad
Cc: SPRING WG List ; Robert Raszuk ; Andrew
Alston - IETF
Subject: Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh-compression)
So you can't ping a uSID list
Internal All Employees
From: Francois Clad
Date: Thursday, 4 April 2024 at 17:19
To: Andrew Alston - IETF
Cc: SPRING WG List , Robert Raszuk , Joel
Halpern
Subject: Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh-compression)
CAUTION: This email has originated from
: Thursday, 4 April 2024 at 17:10
To: Francois Clad , Andrew Alston - IETF
Cc: SPRING WG List , Robert Raszuk
Subject: Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh-compression)
Does this mean that if I have a source and destiantion host inside an SRv6
domain, and I am
routers are acting as middle
boxes.
Thanks
Andrew
Internal All Employees
From: Francois Clad
Date: Thursday, 4 April 2024 at 16:59
To: Andrew Alston - IETF
Cc: SPRING WG List , Robert Raszuk , Joel
Halpern
Subject: Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh
To: Andrew Alston - IETF
Cc: Francois Clad , Joel Halpern
, SPRING WG List
Subject: Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh-compression)
Hi Andrew,
I am afraid this is nothing new. Moreover even if there is SRH or for that
matter any other Routing Header none
So in investgiating this further, there is a further problem.
I’ve checked on 4 different linux boxes with 4 different network cards.
Linux by default offloads TX checksumming on a lot of network cards. If you
originate a packet with a microsid and no SRH – and the linux box offloads the
2024 at 15:40
To: Andrew Alston - IETF , SPRING WG List
Cc: spring-cha...@ietf.org
Subject: Re: [spring] C-SIDs and upper layer checksums
(draft-ietf-spring-srv6-srh-compression)
CAUTION: This email has originated from a free email service commonly used for
personal email services, please
Hi Alvaro,
Just a clarification – I believe my comments on section 6.5 have been well
documented in other threads – would you like them duplicated here for clarity?
Andrew
Internal All Employees
From: spring on behalf of Alvaro Retana
Date: Tuesday, 2 April 2024 at 20:41
To: SPRING WG
Which - as you know since I have stated it to you - is still not incompatible
with the ravioli draft - since the ravioli draft could well take advantage of
an ethertype allocated by the safe-limited-domains draft
Again those drafts are in no way mutually exclusive or reliant on each other
Vainshtein
Date: Wednesday, 27 March 2024 at 16:41
To: Stewart Bryant
Cc: Tom Herbert , Ron Bonica ,
spring@ietf.org , Alvaro Retana ,
Robert Raszuk , Andrew Alston - IETF
Subject: RE: [EXTERNAL] Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
Stewart,
The 6man-sid
on the packet.
Regards,
Sasha
Internal All Employees
From: Andrew Alston - IETF
Sent: Wednesday, March 27, 2024 2:34 PM
To: Alexander Vainshtein
Cc: Tom Herbert ; Ron Bonica ;
spring@ietf.org; Alvaro Retana ; Robert Raszuk
Subject: [EXTERNAL] Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh
– and I’m
happy to co-author on that.
Thanks
Andrew
Internal All Employees
From: Ron Bonica
Date: Wednesday, 27 March 2024 at 15:59
To: Antoine FRESSANCOURT , Andrew Alston -
IETF , Tom Herbert
Cc: Alexander Vainshtein , spring@ietf.org
, Robert Raszuk , Alvaro Retana
Subject: Re
0x0800 to
0x8100 and back again when VLAN tags are stripped. In both cases ethertypes
are being rewritten.
Thanks
Andrew
Internal All Employees
From: Alexander Vainshtein
Date: Wednesday, 27 March 2024 at 15:30
To: Andrew Alston - IETF
Cc: Tom Herbert , Ron Bonica ,
spring@ietf.org , Alvaro
Andrew
Internal All Employees
From: Alexander Vainshtein
Date: Wednesday, 27 March 2024 at 15:18
To: Andrew Alston - IETF , Robert Raszuk
Cc: Tom Herbert , Ron Bonica ,
spring@ietf.org , Alvaro Retana
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Andrew
at 12:02 PM Andrew Alston - IETF
wrote:
Interesting Robert,
That entire repo is entirely empty – was last updated on Feb 11th – and
directly conflicts with the slide deck presented at 119 which expressly lists
the checksum issue as an open issue.
As per
https://datatracker.ietf.org/meeting/119
-srv6-segment-list-encoding
Andrew
Internal All Employees
From: Robert Raszuk
Date: Wednesday, 27 March 2024 at 13:58
To: Nick Hilliard
Cc: Andrew Alston - IETF , spring-cha...@ietf.org
, spring@ietf.org
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Nick
be a
bad idea – but it CAN be done)
Thanks
Andrew
Internal All Employees
From: Robert Raszuk
Date: Wednesday, 27 March 2024 at 12:28
To: Andrew Alston - IETF
Cc: Tom Herbert , Ron Bonica ,
Alexander Vainshtein , spring@ietf.org
, Alvaro Retana
Subject: Re: [spring] Chair Review of draft-ietf
: Antoine FRESSANCOURT
Date: Wednesday, 27 March 2024 at 11:42
To: Andrew Alston - IETF , Tom Herbert
, Ron Bonica
Cc: Alexander Vainshtein , spring@ietf.org
, Robert Raszuk , Alvaro Retana
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
You don't often get email
, spring@ietf.org
, Andrew Alston - IETF , Robert
Raszuk , Alvaro Retana
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
On Tue, Mar 26, 2024 at 4:03 PM Ron Bonica wrote:
>
> Sasha,
>
> At the moment when SRv6 diverges from IPv6, the two evolution
So I’ve given a lot of thought to the checksum issue – and here is where my
thinking is currently sitting.
Firstly – RFC8200 does not mention the word middlebox or middleware anywhere.
Nor does RFC8200 specify anywhere that the checksum should not be verifable in
flight.
Indeed, section 8.1
not in a
position where I can say more than that - suffice to say they exist and this
would cause issues
Andrew
Andrew Alston
Internal All Employees
From: Nick Buraglio
Sent: Wednesday, February 7, 2024 2:32:22 AM
To: Robert Raszuk
Cc: Andrew Alston - IETF
at 12:16
To: Andrew Alston - IETF , Robert Raszuk
, Ron Bonica
Cc: spring@ietf.org
Subject: RE: [spring] draft-ietf-spring-srv6-srh-compression
Hello,
I tend to agree with Andrew that the fact that the verification of a L4
checksum by a middlebox breaks is a problem. But I think this is a huge
I call breaking any middleware that does checksum validation a problem - and a
big one
Andrew Alston
Internal All Employees
From: Robert Raszuk
Sent: Monday, February 5, 2024 7:16:23 PM
To: Ron Bonica
Cc: Andrew Alston - IETF ; spring@ietf.org
Subject: Re
Hi All,
(In capacity as a contributor and wearing no other hats)
At this point I cannot support progression of this document until the issues
around the L4 Checksum have been resolved. It’s been clearly stated in other
emails on the list that in certain circumstances the behavior described in
Thanks Cheng,
I’ve cleared the discuss ballot.
Andrew
Internal All Employees
From: Cheng Li
Date: Thursday, 30 November 2023 at 17:12
To: Andrew Alston - IETF , James Guichard
, Stewart Bryant
Cc: draft-ietf-spring-mpls-path-segm...@ietf.org
, spring-cha...@ietf.org
, spring@ietf.org
Andrew
Internal All Employees
From: James Guichard
Date: Thursday, 30 November 2023 at 16:56
To: Cheng Li , Andrew Alston - IETF ,
Stewart Bryant
Cc: draft-ietf-spring-mpls-path-segm...@ietf.org
, spring-cha...@ietf.org
, spring@ietf.org ,
bruno.decra...@orange.com
Subject: RE: [spring
Employees
From: Stewart Bryant
Date: Thursday, 30 November 2023 at 11:04
To: Andrew Alston - IETF
Cc: The IESG , draft-ietf-spring-mpls-path-segm...@ietf.org
, spring-cha...@ietf.org
, spring@ietf.org ,
james.n.guich...@futurewei.com ,
bruno.decra...@orange.com
Subject: Re: [spring] Andrew
Hi All,
Please see the next part of my review of the draft mentioned in the title –
this should be read in conjunction with the other part of this review as posted
in a separate email. This part of the review covers sections 4.2 through to
the end of section 6.2. I will attempt to send the
Hi All,
While this review is far from complete – and I will be submitting reviews of
the rest of the document as time allows – please see below regarding the text
of the document up to and including parts of section 4.2.
Based on the below as a summary – I would argue that this document could
, 4 August 2023 at 08:24
To: Andrew Alston - IETF , Joel Halpern
, SPRING WG List
Subject: RE: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression
Hi Andrew,WG,
Let me add my understanding of interoperability.
If all devices support NEXT-C-SID, the encapsulation is as follows
Hi Joel, WG
Speaking strictly as a spring participant and wearing no other hats.
I cannot call this one solution �C yes �C what Changwang said below is correct
that they can potentially co-exist �C however the question of one solution
comes down to this:
If there is an implementation done
Latest version of the draft that aims to address comments received so far has
been posted.
Comments/reviews appreciated as always.
Thanks
Andrew
A new version of I-D, draft-raviolli-intarea-trusted-domain-srv6-01.txt
has been successfully submitted by Andrew Alston and posted to the
IETF
mpella
Cc: Adrian Farrel ; Andrew Alston - IETF
; int-a...@ietf.org ;
spring@ietf.org ; Dr. Tony Przygienda
Subject: RE: [spring] [Int-area] FW: New Version Notification for
draft-raviolli-intarea-trusted-domain-srv6-00.txt
On second thought, if we had the new ethertype, we wouldn’t need the n
to provide an option that does not
interfere with existing srv6 to those that may want to use the technology, but
aren’t comfortable using it in the absence of this mechanism.
Thanks
Andrew
From: Robert Raszuk
Date: Wednesday, 29 March 2023 at 10:30
To: Andrew Alston - IETF
Cc: adr
Andrew
From: Adrian Farrel
Date: Tuesday, 28 March 2023 at 11:24
To: Andrew Alston - IETF , int-a...@ietf.org
Cc: spring@ietf.org
Subject: RE: [Int-area] FW: New Version Notification for
draft-raviolli-intarea-trusted-domain-srv6-00.txt
[Spring cc’ed because, well, you know, SR. I wonder
Hi All,
I wanted to send this before the SPRING meeting so that people were aware.
As people may be aware Jim Guichard was recently appointed as one of the
routing area directors. As such he will be leaving his position as SPRING
chair. Alvaro Retana will then be taking over as SPING chair
Hi All,
Firstly, sorry for my silence on this one of late.
I’m going to ask that I be moved from author to contributor on this document, I
also note that I will be recusing myself from this document in an IESG related
work and will ask one of the other routing AD’s to handle it, to avoid the
Hi All,
Sending this email wearing only the hat of a working group participant.
One of the things that our network uses, and is used by so many networks out
there, are martini based pseudowires (which for clarity are generally setup
using what is described in RFC8077). In an SR world however,
Just a notification to the working group, an errata was reported on RFC8986
(Errata 6809) in Section 4.10.
The original text reads: "When N receives a packet whose IPv6 DA is S and S is
a local End.DX2 SID", this should read End.DX2V SID.
As such I've marked this one verified.
Thanks
Andrew
.
Anything else would run into issues with section 8.2 of RFC8402.
Thanks
Andrew
From: spring On Behalf Of Xiejingrong (Jingrong)
Sent: Monday, March 14, 2022 10:16 AM
To: Gyan Mishra ; Andrew Alston - IETF
Cc: spring@ietf.org; Tom Hill
Subject: Re: [spring] Network Programming Interface
Hi There,
Speaking entirely as a working group participant,
I have two substantial concerns with this document at first skim read.
Firstly - the 12 bits for an interface ID - I have serious concerns that this
will be far from sufficient. Keep in mind you have interface specific VLAN's
(that
Hi Jingrong,
I'm struggling to entirely understand this. I think the question for me is -
if you are sending packets with SID's over the open internet - are you
encapsulating those packets and is this encapsulation cryptographically
protected - I.E the SID's are not visible outside of the
43 matches
Mail list logo
