I support the adoption for the following reasons:
1. If you look at the analysis, CSID has the best attributes for the
compressed SRv6 solution in IETF.
2. Adopting a WG means we put in some guidance on the direction of IETF.
Even we still need to discuss more on the different behaviors i
As a coauthor I support the adopting of the docs. They provide a good basis on
the element to look for regarding SRv6 compression and define the analysis of
the different proposals out there.
From: spring on behalf of bruno.decra...@orange.com
Date: Tuesday, 7 September 2021 at 15:13
To: spri
Maybe just to clarify my statement. in my view we can adopt CSID and discuss
the matter of 1 versus 2 data-planes during the WG and see how to move forward
from here. At least we can make progress on this matter.
From: spring on behalf of Henderickx, Wim (Nokia -
BE/Antwerp)
Date: Wednesday
Joel and chairs thx for having us move forward here. On the q if CSID is 1
dataplane or 2 dataplane, in my view there is 2 dataplanes inside the CSID
proposal and I am advocating that in case CSID moves fwd we pick 1 of them, not
both.
From: spring on behalf of Joel M. Halpern
Date: Monday,
I will repeat what I said before, given this has to be implemented in HW it is
better for everyone to have a single solution.
Also for interoperability purposes 1 solution will help us all.
From: spring on behalf of Joel M. Halpern
Date: Wednesday, 4 August 2021 at 20:52
To: spring@ietf.org
S
Let me shime in as another individual contributor.
On requirements, there has been plenty of input from various people (see
meeting minutes and comments from people on mailing lists). On top given the
people discussing this were in the DT they had direct access to getting the
requirements in th
Given the design team accomplished the work on providing requirements and
analysis to compress an SRv6 SID list, I would recommend we pick 1 solution
similar to what was done in NVO3 (when we discussed GENEVE, GUE, GPE, etc)
given this has to be implemented in HW..
I hope we can conclude on thi
I agree with your observation Bruno and I believe it is better to go for the
more optimal approach using next header
From: spring on behalf of Bruno Decraene
Date: Monday, 15 March 2021 at 16:44
To: "spring@ietf.org" , "draft-ietf-spring-nsh...@ietf.org"
Subject: Re: [spring] WG Last Call dr
As a co-athor, not aware of IPR related to this draft
On 09/02/2021, 19:40, "spring on behalf of Joel M. Halpern"
wrote:
As a contributor, I do not know of any undisclosed IPR on this draft.
Yours,'
Joel
On 2/9/2021 1:06 PM, bruno.decra...@orange.com wrote:
> Hi authors,
As a co-author I believe this should progress.
Not aware of an implementation though
From: spring on behalf of Bruno Decraene
Date: Tuesday, 9 February 2021 at 19:31
To: "spring@ietf.org"
Cc: "draft-ietf-spring-nsh...@ietf.org"
Subject: [spring] WG Last Call draft-ietf-spring-nsh-sr
Dear WG,
Support adoption of WG doc
On 22/06/2020, 20:44, "spring on behalf of Stone, Andrew (Nokia - CA/Ottawa)"
wrote:
Hi Spring WG
Support adoption.
Willing to work on the document, and already participating in related
documents in PCE and IDR.
Thanks
Andrew
On 2020-
Thx Rob and welcome Jim and Joel
On 14/06/2020, 22:25, "spring on behalf of Martin Vigoureux"
wrote:
WG,
Rob had decided to step down as chair some time ago. There hasn't been
any formal communication on that so I'd like, first, to thank Rob for
his work and dedication to th
On 29/05/2020, 12:25, "ipv6 on behalf of Peter Psenak" wrote:
On 29/05/2020 12:12, Gyan Mishra wrote:
>
>
> On Fri, May 29, 2020 at 5:11 AM Peter Psenak
> mailto:40cisco@dmarc.ietf.org>>
> wrote:
>
> Hi Ron,
>
> On 28/05/2020 18:55, Ron
Sander, can you describe your use case. So far the only thing that people has
asked CRH to do is steering and as mentioned we have solutions for those. If
there are others, please share them..
On 28/05/2020, 16:58, "Sander Steffann" wrote:
Hi Robert,
> There can be a lot of acronymou
Fred, if the issue is a document to describe RFC 8663 w/o calling our MPLS,
this can be done. Would that solve your issue?
From: "Templin (US), Fred L"
Date: Wednesday, 27 May 2020 at 22:33
To: Andrew Alston , Ron Bonica
, "Zafar Ali (zali)" ,
"Henderickx, Wim (Noki
Sander,
On 26/05/2020, 21:48, "Sander Steffann" wrote:
Hi,
> WH> what you are saying I only want a CRH solution and you are not open
to anything else, because the SIDs are not in the right place.
No, that is not what I said. Please stop twisting my words. I want to steer
a packe
Sander,
On 26/05/2020, 21:17, "Sander Steffann" wrote:
Hi Wim,
> WH> We are either all encapsulating or not, but in essence the point is
that the difference is you put the sids in the extension header versus next
header. Lets leave it like this. All in all what I am saying is RFC8663
Sander,
On 26/05/2020, 19:40, "Sander Steffann" wrote:
Hi Wim,
> Wh> Nothing is put in the payload when using RFC8663. The SID list is put
in a next header field as per RFC 4023, whereas in CRH you put them in an EH,
but the payload is intact. I have not done the exact calculation on
Sander,
On 26/05/2020, 19:20, "Sander Steffann" wrote:
Hi Wim,
> WH> Why would it matter if I add the sids in an Extension Header, versus
through a Next header. As long as we achieve the same goal why would you care?
I don't understand what you mean. If you're talking about enca
Sander, inline
On 26/05/2020, 19:03, "Sander Steffann" wrote:
Hi Wim,
> WH> Sander RFC8663 is supported in linux and various implementations.
You can do the encap in the same way as you have done with CRH w/o a router
doing the encap.
You misunderstand. I don't want any encap
On 26/05/2020, 18:11, "Sander Steffann" wrote:
Hi Wim,
> WH> in the same way as you get CRH across the Internet. It is a tag
encapsulated in an IPV6 header. It uses ipv6 encap based on RFC4023.
That assumes that there is always a router that adds an encap to an
existing packet.
On 26/05/2020, 16:46, "Sander Steffann" wrote:
Hi Wim,
> It does work across domains that are not directly connected, but that
scenario is not well described I have to admit. The operation is as I said very
similar to CRH.
> Think of the MPLS tag as the same as the SID tag in C
It does work across domains that are not directly connected, but that scenario
is not well described I have to admit. The operation is as I said very similar
to CRH.
Think of the MPLS tag as the same as the SID tag in CRH. From a data-plane all
packets on the wire will use v6 addresses, so inte
I agree that if you look into the details RFC8663 from a data-plane operation
is very similar to CRH. It uses a tag and derives a destination ipv6 address
from it.
On top it if you look at the requirements, the following is possible with
RFC8663
* It can steer the packet through a specific
As a co-author not aware of IPR related to this draft
From: spring on behalf of Robert Raszuk
Date: Thursday, 5 December 2019 at 20:05
To: Bruno Decraene
Cc: SPRING WG List ,
draft-ietf-spring-srv6-network-programming
Subject: Re: [spring] IPR poll for draft-ietf-spring-srv6-network-program
level w/o any interworking at
service level.
In my view this is very compelling compared to coming up with something new
that does the same thing. My 2 cents.
From: Robert Raszuk
Date: Tuesday, 10 September 2019 at 20:36
To: "Henderickx, Wim (Nokia - BE/Antwerp)"
Cc: Sander Steffann ,
Sander, in-line
On 10/09/2019, 19:39, "Sander Steffann" wrote:
Hi Wim,
> WH> Would you be ok with this?
https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07, support segment
routing over IPv4 and/or IPv6.
No, I don't want to have to manage both MPLS and tunnels. Tha
Sander, in-line
On 10/09/2019, 18:21, "spring on behalf of Sander Steffann"
wrote:
Hi,
> No. And that is why I want SRv6+ to move forward, to avoid getting
trapped in the SRv6 walled garden.
>
> The way IETF works (at least in vast majority of WGs) is that if you do
not
Adding my perspective here. The fact that some proposals come on the table
shows that we have something to optimize. So far there has been little feedback
on sizes required in real deployments. Personally I have seen request for small
(1-2 sids) to other cases which require up to 9-10 sids deep.
Same here not aware of IPR related to this draft
From: Jisu Bhattacharya
Date: Monday, 15 July 2019 at 08:15
To: Rob Shakir
Cc: "draft-xuclad-spring-sr-service-programm...@ietf.org"
, SPRING WG List
Subject: Re: [spring] IPR Poll: draft-xuclad-spring-sr-service-programming
Resent from:
Resen
Not aware on IPR related to this draft
From: Rob Shakir
Date: Thursday, 27 June 2019 at 10:14
To: "draft-guichard-spring-nsh...@ietf.org"
, SPRING WG List
Subject: IPR Poll: draft-guichard-spring-nsh-sr
Resent-From:
Resent-To: , , EXT Jeff
Tantsura , ,
, "mohamed. boucadair"
,
Resent-Date:
I am not aware of IPR related to this draft
From: spring on behalf of Bruno Decraene
Date: Wednesday, 10 April 2019 at 12:20
To: SPRING WG
Subject: [spring] FW: IPR Poll for
draft-filsfils-spring-srv6-network-programming
From: Dirk Steinberg [mailto:d...@lapishills.com]
Sent: Wednesday, Ap
I am not aware of IPR related to this draft
From: spring on behalf of Stephane Litkowski
Date: Monday, 4 June 2018 at 18:23
To: Bruno Decraene , SPRING WG List
, "draft-ietf-spring-segment-routing-m...@ietf.org"
Subject: Re: [spring] IPR Poll for draft-ietf-spring-segment-routing-mpls
Hi,
I am not aware of IPR related to this draft.
On 07/06/2018, 03:15, "Loa Andersson" wrote:
Working Group,
We are currently preparing draft draft-xu-mpls-sr-over-ip for working
group adoption.
Part of this preparation is to do an IPR poll.
This mail is to start
I agree also with that. SR-TE is a different technology compared to
TEAS/RSVP/GMPLS. So I agree to keep this work in SPRING WG and progress it
there.
From: spring on behalf of "Kamran Raza (skraza)"
Date: Wednesday, 21 March 2018 at 01:45
To: Robert Raszuk , "Darren Dukes (ddukes)"
Cc: "spr
"mohamed. boucadair" ,
"Henderickx, Wim (Nokia - BE/Antwerp)" , Robert
Raszuk , Adrian Farrel
Cc: mpls , SPRING WG List , "s...@ietf.org"
, "b...@ietf.org"
Subject: RE: [mpls] [sfc] Progress with draft-farrel-mpls-sfc
I guess I am not being clear.
The issue as I se
update it but for reference:
https://tools.ietf.org/html/draft-guichard-sfc-nsh-sr-00
From: Stephane Litkowski
Date: Tuesday, 20 March 2018 at 10:24
To: "LINGALA, AVINASH" , "mohamed. boucadair"
, "UTTARO, JAMES" we ,
"Henderickx, Wim (Nokia - BE/Antwerp)&qu
19:13
To: Adrian Farrel
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" , mpls
, SPRING WG List , "s...@ietf.org"
, "b...@ietf.org"
Subject: Re: [sfc] [mpls] Progress with draft-farrel-mpls-sfc
Hi Adrian,
> That proxy may be a bump in the wire between the SFF and
Adrian, on replacement of NSH. You will have to change the SF with this
proposal in Non proxy case so this proposal does not solve a brownfield case.
Which SF(s) support MPLS?
On 16/03/2018, 22:12, "mpls on behalf of Adrian Farrel" wrote:
All,
The authors of draft-farrel-mpls-sf
I have the same observation as Robert here. The IETF has focussed on using NSH
as a mechanism for service chaining in SFC WG. We finally see some
implementations coming alive. With this proposal we will start from scratch as
all SFF and SF implementations will have to be modified. NSH was and st
Welcome on board Rob
From: spring on behalf of Alvaro Retana
Date: Wednesday, 21 February 2018 at 13:41
To: SPRING WG
Subject: [spring] New spring WG Co-Chair
Dear spring WG:
As all of you already know, Martin has been selected as a Routing AD starting
next month at IETF 101 in London. He
Support as co-author
On 08/12/2017, 21:33, "mpls on behalf of Jeff Tantsura" wrote:
Loa,
Support as co-author.
Thanks!
Cheers,
Jeff
-Original Message-
From: mpls on behalf of Loa Andersson
Date: Friday, December 8, 2017 at 05:17
To: "
Adrian see my other comments on the mailing list which seem to clarify some of
the ctxt I am taking about
On 14/08/2017, 03:59, "Adrian Farrel" wrote:
Hi Wim,
> The draft only defines procedures for SRoIP E2E, why don’t we envision
SRoIP to
> Interwork with native MPLS-SR.
In-line
On 14/08/2017, 00:30, "spring on behalf of Xuxiaohu" wrote:
> -邮件原件-
> 发件人: Henderickx, Wim (Nokia - BE/Antwerp)
> [mailto:wim.henderi...@nokia.com]
> 发送时间: 2017年8月14日 15:18
> 收件人: Xuxiaohu; Uma Chunduri; adr...@olddog.co.uk
More in-line
On 14/08/2017, 09:11, "Xuxiaohu" wrote:
Hi Wim,
> -邮件原件-
> 发件人: Henderickx, Wim (Nokia - BE/Antwerp)
> [mailto:wim.henderi...@nokia.com]
> 发送时间: 2017年8月14日 15:03
> 收件人: Xuxiaohu; Uma Chunduri; adr...@olddog.co.uk; spring
In-line
On 14/08/2017, 08:41, "Xuxiaohu" wrote:
Hi Wim,
> -邮件原件-
> 发件人: spring [mailto:spring-boun...@ietf.org] 代表 Henderickx, Wim (Nokia
> - BE/Antwerp)
> 发送时间: 2017年8月14日 14:27
> 收件人: Uma Chunduri; adr...@olddog.co.uk; spring@ietf.
ring [mailto:spring-boun...@ietf.org] On Behalf Of Henderickx, Wim
(Nokia - BE/Antwerp)
Sent: Sunday, August 13, 2017 6:55 PM
To: adr...@olddog.co.uk; spring@ietf.org
Subject: Re: [spring] FW: New Version Notification for
draft-bryant-mpls-unified-ip-sr-01.txt
The draft onl
The draft only defines procedures for SRoIP E2E, why don’t we envision SRoIP to
Interwork with native MPLS-SR.
What I mean is when using the SRoIP procedures the draft uses SRoIP at every
hop which is SR capable.
You could envision certain segments to do SRoIP and other segments to have
native M
support
On 06/02/2017, 10:22, "spring on behalf of Stefano Previdi (sprevidi)"
wrote:
I support as co-author.
s.
> On Feb 6, 2017, at 2:20 PM, Martin Vigoureux
wrote:
>
> Hello Working Group,
>
> This email starts a 2-week Working Group Last Call o
I also vote for maximizing forwarding based on customer input. Although I agree
we want to avoid SID conflicts, it is going to happen and we need to minimize
the implications in the network.
Life is not easy
From: spring on behalf of Gunter VAN DE VELDE
Date: Saturday, 10 December 2016 at 07:
I support WG adoption
On 24/07/16 14:39, "mpls on behalf of John G. Scudder" wrote:
>Dear WG (and cc MPLS, please include SPRING in replies),
>
>As we discussed at our meeting, working group adoption has been requested for
>draft-psarkar-spring-mpls-anycast-segments. Please reply to the list
As a contributor not aware of IPR related to this draft
On 24/07/16 14:49, "spring on behalf of John G.Scudder"
wrote:
>Dear Authors:
>
>As we discussed at the SPRING meeting, a second working group last call has
>been requested for draft-ietf-spring-segment-routing. Before we begin the
>W
As a contributor not aware of IPR related to this draft
On 24/07/16 14:52, "spring on behalf of John G.Scudder"
wrote:
>Dear Authors:
>
>As we discussed at the SPRING meeting, working group last call has been
>requested for draft‐ietf-spring-segment‐routing-mpls. Before we begin the
>WGLC,
As a co-author is support WG adoption.
Not aware of IPR related to this draft
On 24/07/16 14:55, "spring on behalf of John G. Scudder"
wrote:
>Dear WG,
>
>As we discussed at our meeting, working group adoption has been requested for
>draft‐filsfils‐spring‐large-scale-interconnect. Please re
As reviewer not aware on IPR related to this draft
On 13/04/16 20:32, "spring on behalf of EXT Martin Pilka"
wrote:
>Hello Bruno,
>I am also not aware of any IPR related to this draft.
>Thanks,
>Martin
>
>
>On 13/04/16 09:57, bruno.decra...@orange.com wrote:
>> Working Group,
>>
>> The autho
55 matches
Mail list logo
