FRESSANCOURT ; Tom Herbert
Cc: Alexander Vainshtein ; spring@ietf.org;
Robert Raszuk ; Alvaro Retana
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Folks,
Previously in this thread, Antoine Fressancourt wrote:
" I think everyone here has realized tha
rew Alston - IETF ,
spring-cha...@ietf.org , spring@ietf.org
*Subject: *Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
Nick,
So which part of RFC7282 ?
In tracker I see zero open issues:
https://github.com/ietf-wg-spring/draft-ietf-sprin
*Date: *Wednesday, 27 March 2024 at 12:28
*To: *Andrew Alston - IETF
*Cc: *Tom Herbert , Ron Bonica ,
Alexander Vainshtein , spring@ietf.org <
spring@ietf.org>, Alvaro Retana
*Subject: *Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
Andrew,
because there are operator
ednesday, March 27, 2024 9:01 AM
To: Ron Bonica ; Antoine FRESSANCOURT
; Tom Herbert
Cc: Alexander Vainshtein ; spring@ietf.org
; Robert Raszuk ; Alvaro Retana
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
100% agree w
Cc: Tom Herbert ; Ron Bonica ; spring@ietf.org; Alvaro Retana ; Robert Raszuk
Subject: [EXTERNAL] Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Errr
When unlabelled ipv4 traffic (ethertype 0x0800) gets pushed onto an LSP, the traffic is labelled – and the ethertype is
- IETF
Cc: Tom Herbert , Ron Bonica ,
spring@ietf.org , Alvaro Retana ,
Robert Raszuk
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Andrew,
What you describe in is not an Ethertype re-write IMHO.
In your example the entire Layer 2 header (MAC addresses, VLAN
Cc: Alexander Vainshtein ; spring@ietf.org
; Robert Raszuk ; Alvaro Retana
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
Hello,
I think it is a bit odd that the question that led us to discuss whether SRv6
was an
; Alvaro Retana
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
Hello,
I think it is a bit odd that the question that led us to discuss whether SRv6
was an extension of IPv6 or a separate dataplane protocol on the
; Alvaro Retana ; Robert Raszuk
Subject: [EXTERNAL] Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
Errr
When unlabelled ipv4 traffic (ethertype 0x0800) gets pushed onto an LSP, the
traffic is labelled – and the ethertype is switched to 0x8847 (MPLS). When the
MPLS decap
7:52 PM
To: Ron Bonica
Cc: Alexander Vainshtein ; spring@ietf.org
; Andrew Alston - IETF ; Robert
Raszuk ; Alvaro Retana
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
On Tue, Mar 26, 2024 at 4:03 PM Ron Bonica wrote
Retana ,
Robert Raszuk
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Andrew,
Can you please provide any details about re-write of MPLS Ethertype? Why is it
needed, what are the applications etc.
I am not aware of any such operations.
Regards,
Sasha
Internal
: Tom Herbert ; Ron Bonica ;
spring@ietf.org; Alvaro Retana
Subject: [EXTERNAL] Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
Actually there are many reasons – which have been detailed in the ethertype
document why various operators believe that this is insufficient
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
etwork.
Regards,
Sasha
From: Andrew Alston - IETF
Sent: Wednesday, March 27, 2024 11:36 AM
To: Robert Raszuk
Cc: Tom Herbert ; Ron Bonica ;
Alexander Vainshtein ; spring@ietf.org; Alvaro
Retana
Subject: [EXTERNAL] Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
No
Raszuk ; Alvaro Retana
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Except – the objection to the checksum was never really about middleboxes – the
middle box issue was merely an example – and has been used as a red hearing –
as I clearly stated in subsequent
- IETF
Cc: Nick Hilliard , spring-cha...@ietf.org
, spring@ietf.org
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Andrew,
In IETF process issues should be opened by those who claim their existence not
by the authors of the document.
And repo shows 5 closed
drew
>
>
>
>
>
>
> 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 <
> spring@ietf.org>
> *Subject: *Re: [spring] Chair
-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
Nick,
So which part of RFC7282 ?
In tracker I see zero open issues:
https://github.com/ietf-wg-spring/draft-ietf-spring-srv6-srh-compression/issues
All issues have been addressed.
So what is the problem ?
Thx,
R.
On Wed, Mar 27, 2024 at 11:43 AM Nick Hilliard wrote:
> Robert Raszuk wrote on
Robert Raszuk wrote on 27/03/2024 10:13:
WGLC on this doc started Jan 22nd - Today we have March 27th - was the
result of the working group's last call announced and I missed it ?
Looking at the list it seems this draft got pretty overwhelming support
already. Why are we not progressing ? What
>
>
> 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 <
> spring@ietf.org>, Alvaro
ng@ietf.org>>, Andrew Alston - IETF
, Robert Raszuk
mailto:rob...@raszuk.net>>, Alvaro Retana
mailto:aretana.i...@gmail.com>>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
On Tue, Mar 26, 2024 at 4:03 PM Ron Bonica
mailto:rbon...@juniper.net>>
mechanisms that use link-local
> IPv6 addresses?
> >
> > Replicating these mechanisms does not make much sense to me.
> >
> > My 2c,
> > Sasha
> >
> >
> > Get Outlook for Android
> >
> >
> > Juniper Business Use Only
> >
&g
: 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
ert Raszuk
mailto:rob...@raszuk.net>>, Alvaro Retana
mailto:aretana.i...@gmail.com>>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
On Tue, Mar 26, 2024 at 4:03 PM Ron Bonica
mailto:rbon...@juniper.net>> wrote:
>
> Sasha,
>
> At the m
, 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 evolutionary bra
> From: Alexander Vainshtein
> Sent: Tuesday, March 26, 2024 4:24 PM
> To: Ron Bonica
> Cc: spring@ietf.org ; Andrew Alston - IETF
> ; Robert Raszuk ; Tom Herbert
> ; Alvaro Retana
> Subject: Re: [spring] Chair Review of
> draft-ietf-sprin
:36:49 PM
To: Alexander Vainshtein
Cc: spring@ietf.org ; Andrew Alston - IETF
; Robert Raszuk ; Tom Herbert
; Alvaro Retana
Subject: [EXTERNAL] Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compression-11
Sasha,
Good point. In my previous email, I didn't mean suggest that we sho
ysg>
From: Ron Bonica
Sent: Tuesday, March 26, 2024 8:36:49 PM
To: Alexander Vainshtein
Cc: spring@ietf.org ; Andrew Alston - IETF
; Robert Raszuk ; Tom Herbert
; Alvaro Retana
Subject: [EXTERNAL] Re: [spring] Chair Review of
draft-ietf-spring-srv6-srh-compress
From: Robert Raszuk
Sent: Tuesday, March 26, 2024 1:24 PM
To: Ron Bonica
Cc: Tom Herbert ; Alvaro Retana ;
Andrew Alston - IETF ; spring@ietf.org
; Joel Halpern
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content
1:56 PM
To: Ron Bonica
Cc: spring@ietf.org ; Andrew Alston - IETF
; Robert Raszuk ; Tom Herbert
; Alvaro Retana
Subject: RE: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
Ron and all,
I respectfully disagree with the propos
otherwise maintain compliance with IPv6 standard.
>
> Tom
>
> >
> >Ron
> >
> > Juniper Business Use Only
> >
> > ____________
> > From: Tom Herbert
> > Sent: Monday, March
.@liquid.tech>>; Ron Bonica
mailto:rbon...@juniper.net>>;
spring@ietf.org<mailto:spring@ietf.org>
mailto:spring@ietf.org>>; Joel Halpern
mailto:j...@joelhalpern.com>>
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be
from IPv6.
>>>
>>> My question is not rhetorical. Maybe I am missing something, but is
>>> there any real benefit in continuing to bind SRRv6 to IPv6?
>>>
>>>Ron
>>>
>>> J
>> My question is not rhetorical. Maybe I am missing something, but is there
>> any real benefit in continuing to bind SRRv6 to IPv6?
>>
>>Ron
>>
>> Juniper Business Use Only
>> --------------
>> *From:*
bert
> Sent: Monday, March 25, 2024 3:40 PM
> To: Alvaro Retana
> Cc: Robert Raszuk ; Andrew Alston - IETF
> ; Ron Bonica ; spring@ietf.org
> ; Joel Halpern
> Subject: Re: [spring] Chair Review of
> draft-ietf-spring-srv6-srh-compression-11
>
> [External Email. Be caut
t:* Monday, March 25, 2024 3:40 PM
> *To:* Alvaro Retana
> *Cc:* Robert Raszuk ; Andrew Alston - IETF
> ; Ron Bonica ;
> spring@ietf.org ; Joel Halpern
> *Subject:* Re: [spring] Chair Review of
> draft-ietf-spring-srv6-srh-compression-11
>
> [External Email. Be cautious of co
s Use Only
From: Tom Herbert
Sent: Monday, March 25, 2024 3:40 PM
To: Alvaro Retana
Cc: Robert Raszuk ; Andrew Alston - IETF
; Ron Bonica ; spring@ietf.org
; Joel Halpern
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be cautious of content]
On M
which has been said many times since the effort started by people who have
been around many architectures in networking space and lived the dreams of
violating/bending standards, shortcutting layers and other "clever"
solutions justified by exigency, limited-use-only or whatever other
figleaves cou
On March 18, 2024 at 10:49:39 AM, Francois Clad wrote:
Francois:
Hi! Thanks for the update!
> Detailed replies inline. These include your follow-up comments as well as the
> review items that we missed in the first pass.
>
> Please let us know if you have any further feedback.
I have some sug
Hi Alvaro,
> Given that the issue is constrained to an SR domain
The issue seems much more constrained that that.
* It seems very clear that there is no issue if we encapsulate packets with
new IPv6 header to make it SRv6
* It seems that the issue is also non existent if SRv6 end hosts add an
I
On Mon, Mar 25, 2024 at 12:31 PM Alvaro Retana wrote:
>
> Tom:
>
> Hi!
>
> I understand your point.
>
> I put the option out there because it came up at last week’s spring meeting
> and it should be discussed.
Alvaro,
This seems to come back to the fundamental question: is SRv6 still
IPv6 or is
Tom:
Hi!
I understand your point.
I put the option out there because it came up at last week’s spring meeting
and it should be discussed.
Thanks!
Alvaro.
On March 25, 2024 at 2:58:48 PM, Tom Herbert (t...@herbertland.com) wrote:
On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana
wrote:
>
> FWI
On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana wrote:
>
> FWIW, I agree with most of what Joel wrote. ;-)
>
> I see another path forward: Given that the issue is constrained to an SR
> domain, the draft could also point out the issues as operational/deployment
> considerations. Operators can the
FWIW, I agree with most of what Joel wrote. ;-)
I see another path forward: Given that the issue is constrained to an SR
domain, the draft could also point out the issues as operational/deployment
considerations. Operators can then make an informed decision on whether
they want to/can use C-SIDs w
(Speaking technically as an individual, but noting that Alvaro and I are
the responsible chairrs who will have to resolve any technical standards
incompatibility. And I have not talked with Alvaro. So I may be
putting my foot in my mouth.)
As I understand it, the current view is that the com
Indeed - I would not mind such clarification for the cases where the host
originates packets without SRH.
In fact modifying packet header with no SRH present would mean additional
state in the segment endpoints which is something SR architecture is trying
to avoid.
Regards,
R.
On Mon, Mar 25, 2
On Mon, Mar 25, 2024 at 10:04 AM Robert Raszuk wrote:
>
> Hi Tom,
>
> I don't think so, but I admit I may not be aware of some interesting use
> cases
Robert,
Based on previous discussions, my understanding is that there was some
intent to allow this. Maybe it should be a clear MUST NOT in
Hi Tom,
I don't think so, but I admit I may not be aware of some interesting use
cases
Many thx,
R.
On Mon, Mar 25, 2024 at 5:57 PM Tom Herbert wrote:
> On Mon, Mar 25, 2024 at 9:40 AM Robert Raszuk wrote:
> >
> >
> > Actually looking at this from the perspective where SRH may be omitte
On Mon, Mar 25, 2024 at 9:40 AM Robert Raszuk wrote:
>
>
> Actually looking at this from the perspective where SRH may be omitted I see
> in the subject draft this clearly stated:
>
> A source node steers a packet into an SR Policy. If the SR Policy results in
> a Segment List containing a singl
Actually looking at this from the perspective where SRH may be omitted I
see in the subject draft this clearly stated:
A source node steers a packet into an SR Policy. *If the SR Policy results
in a Segment List containing a single segment*, and there is no need to add
information to the SRH flag
ndrew
>>
>>
>>
>>
>>
>>
>> Internal All Employees
>>
>> From: Robert Raszuk
>> Date: Monday, 25 March 2024 at 18:23
>> To: Andrew Alston - IETF
>> Cc: Tom Herbert , Ron Bonica
>> , spring@ietf.org
>> Subject: Re:
Tom
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
> Internal All Employees
>
> From: Robert Raszuk
> Date: Monday, 25 March 2024 at 18:16
> To: Tom Herbert
> Cc: Andrew Alston - IETF , Ron Bonica
> , spring@ietf.org
> Subje
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
> Internal All Employees
> From: Robert Raszuk
> *Date: *Monday, 25 March 2024 at 18:23
> *To: *Andrew Alston - IETF
> *Cc: *Tom Herbert , Ron Bonica
> , spring@ietf.org
> *Subject: *Re: [spring] Chair
> Internal All Employees
> From: Robert Raszuk
> *Date: *Monday, 25 March 2024 at 18:16
> *To: *Tom Herbert
> *Cc: *Andrew Alston - IETF , Ron Bonica 40juniper@dmarc.ietf.org>, spring@ietf.org
> *Subject: *Re: [spring] Chair Review of
> draft-ietf-spring-srv6-srh-compr
is that it can be included, when needed and
>> excluded, when not needed.
>>
>>
>>
>> It may be time to specify the new option. What do you think?
>>
>>
>>
>>
>> Ron
>>
>>
>>
>> Juniper Business Us
?
Ron
Juniper Business Use Only
From: spring on behalf of Andrew Alston - IETF
Sent: Monday, March 25, 2024 8:05 AM
To: spring@ietf.org
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
[External Email. Be
this document WITHOUT
correct review by 6man will result in an appeal.
Thanks
Andrew
* Internal All Employees From: *spring on behalf
of Francois Clad
*Date: *Monday, 18 March 2024 at 17:50
*To: *Alvaro Retana
*Cc: *SPRING WG List
*Subject: *Re: [spring] Chair Review of
draft-ietf
WITHOUT
correct review by 6man will result in an appeal.
Thanks
Andrew
Internal All Employees
From: spring on behalf of Francois Clad
Date: Monday, 18 March 2024 at 17:50
To: Alvaro Retana
Cc: SPRING WG List
Subject: Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11
Some
Dear Alvaro,
We have integrated the remainder of your feedback in revision -14.
Detailed replies inline. These include your follow-up comments as well as
the review items that we missed in the first pass.
Please let us know if you have any further feedback.
Thanks,
Francois
> ...
> > > Operati
Hi Alvaro,
Thank you for your email.
It seems that my email client indeed truncated your previous email. Sorry
for that.
We will go through the remaining review items and your replies below, and
get back to you shortly.
Thanks,
Francois
On Mar 5, 2024 at 17:27:27, Alvaro Retana wrote:
> On
On February 29, 2024 at 12:50:46 PM, Francois Clad wrote:
Francois:
Hi!
> We have integrated those changes as part of revisions -12 and -13 of the
> document. Please find our detailed replies inline.
I have put comments below as well, and deleted any parts were we agree
or no more discussion is
Hi Alvaro,
Thank you for your review and comments.
We have integrated those changes as part of revisions -12 and -13 of the
document. Please find our detailed replies inline.
Thanks,
Francois
> Dear authors:
>
> In parallel with the WGLC I have reviewed this document. Thank you
> for the work
Dear Alvaro,Thank you very much for your review. We appreciate your feedback
and will promptly address your comments and suggestions.Best regards, Weiqiang
---原始邮件---
发件人: Alvaro Retana
发送时间: 2024-02-08 03:18:26
收件人: "draft-ietf-spring-srv6-srh-compress...@ietf.org"
抄送: S
64 matches
Mail list logo
