Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Joel, 1. Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field. To this I would say 100% yes – Section 2 of RFC8200 defines an address as “an IPv6-Layer identifier for an interface or a set of interfaces” and right above that it

Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

Mark, I seriously wonder as I see all this if it wasn’t a mistake to not declare srv6 an entirely new protocol with a new protocol number back at the start of this. Because it looks more and more like Robert was right when he said that srv6 was not ipv6 - that or we seem to have forgotten the v

Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

> Of course there is.  You cannot distinguish routing from host without looking > at external control channels, such as a routing or configuration protocol; > and you certainly cannot determine the subnet mask of a network without that > external information, since it's not in the ?> packet.  An

Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

ushed something widely into the field. Andrew From: Ted Hardie Sent: Monday, October 25, 2021 1:37 PM To: Andrew Alston Cc: Eliot Lear ; Nick Hilliard ; SPRING WG List ; 6man WG Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Que

Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

consumers are made easier, increases likelihood of adoption and decreases resistance – to me that just makes perfect sense. Andrew From: Eliot Lear Sent: Monday, October 25, 2021 3:35 PM To: Andrew Alston ; Ted Hardie Cc: Nick Hilliard ; SPRING WG List ; 6man WG Subject: Re: [spring

Re: [spring] SPRING: Better base header + addresses for the future ? (draft-eckert-intarea-functional-addr-internets)

Toerless, I have one question - how you reconcile any of what is in the email below with the spring charter. I would say - that if this line of thought were to be progressed - that the way forward would be to call a BOF - see if there was support - and form a working group - and at that point

Re: [spring] uSID and destination options

I am curious about this as well - since the drafts are silent on it, and this does have a material impact on destination option processing, which if not clarified could lead to some interesting inter-op issues. Thanks Andrew From: spring On Behalf Of Ron Bonica Sent: Monday, November 15, 202

Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

Alex, Will try and get you some captures off the devices I've been testing on - in order to make sure I understood this draft properly, and in light of the deployment status draft, I decided to play a lot more deeply and setup a bit of a lab. I'm still doing tests and soon as I have some other

Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

will lead to a huge amount of inter-op issues later down the line. Hence – I think an analysis of what is being claimed by the deployment draft is indeed very relevant. Thanks Andrew From: Robert Raszuk Date: Tuesday, 17 December 2019 at 13:12 To: Andrew Alston Cc: Alexandre Petrescu

Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

> I would like to ask you whether that >2001:db8:ee:2:1:: >could rather be >2001:db8:ee:ff:2:1::? No - the locator has to be on a 64bit boundary - it refuses configuration for anything else in the code bases I have tested on. Thanks Andrew ___

Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

>> /RP/0/RP0/CPU0:SRV6-R2#show segment-routing srv6 locator R2 sid Sun Dec >> 15 04:56:10.913 UTC/ >> >> /SID Behavior >> Context Owner State RW/ >> >> /-- --- >

Re: [spring] packet captures for draft-ietf-spring-srv6-network-programming-06?

in a technical draft. As such, do you not feel that a more appropriate response to my email would have been, “You seem to have misunderstood, perhaps we can provide some text in order to ensure such misunderstandings are less likely to occur? Thanks Andrew On Dec 17, 2019, at 12:57 AM

Re: [spring] 64-bit locators

+1 I have long argued that SRv6 essentially redefines and overloads the ipv6 address as defined – the argument that I have been given is that the SID is in fact not an address – however – by virtue of the fact that the SID in SRv6 is copied into the address field during traffic steering – and r

Re: [spring] 64-bit locators

avoid confusion and to avoid potential future complications Andrew From: Robert Raszuk Sent: Friday, 20 December 2019 18:45 To: Andrew Alston Cc: Alexandre Petrescu ; Gyan Mishra ; SPRING WG ; Mark Smith ; Pablo Camarillo (pcamaril) Subject: Re: [spring] 64-bit locators > So we are l

Re: [spring] 64-bit locators

: Andrew Alston Cc: Alexandre Petrescu ; Gyan Mishra ; SPRING WG ; Mark Smith ; Pablo Camarillo (pcamaril) Subject: Re: [spring] 64-bit locators Therefore – this redefines the address semantics – and that – should be accompanied by an update to said drafts to avoid confusion and to avoid

Re: [spring] 64-bit locators

-definition of the spec Thanks Andrew From: Robert Raszuk Date: Sunday, 22 December 2019 at 07:42 To: Ron Bonica Cc: Andrew Alston , Alexandre Petrescu , SPRING WG , Gyan Mishra , "Pablo Camarillo (pcamaril)" , Mark Smith Subject: Re: [spring] 64-bit locators Hey Ron, > Leaving both

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

I agree with the sentiments expressed below Andrew From: spring On Behalf Of Mark Smith Sent: Monday, 24 February 2020 00:50 To: Sander Steffann Cc: SPRING WG ; Pablo Camarillo (pcamaril) Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt On Mon, 24 Feb 20

Re: [spring] Is srv6 PSP a good idea

+1 Sander. Furthermore - if indeed that is the contention - then - I suggest you move the whole thing out of SPRING - I quote from the SPRING charter: The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6). Releva

Re: [spring] Is srv6 PSP a good idea

Figured I'd add to this - as I continued to read the charter SPRING WG should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implem

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

The problem is – I’m not convinced we have reached such an agreement – far from it. My view on this is that – and I have stated this many times – I have no problem with the standard moving forward – providing that it does not violate other well defined standards (rfc8200 etc) I also as I have

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Considering the discussion about how +1’s don’t mean much – I still feel that I need to +1 what Ted said in the below paragraph 😊 It seems to me that there is a belief that if you ignore objections long enough – and shout loud enough – the objections will some how disappear. That if you promise

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

rldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYs9oOW3B$> Cheers, Pablo. From: Ron Bonica mailto:40juniper@dmarc.ietf.org>> Date: Monday, 24 February 2020 at 16:27 To: Andrew Alston mailto:andrew.als.

Re: [spring] RFC8200 update?

This is certainly an interesting idea - and I'd probably need to give this a whole lot more thought before commenting properly, but the first thought that comes to mind is - would we be able to standardize a way to instruct like this. What I would not want to see is every extension header out th

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hi All, While myself and others are busy consolidating the text for an appeal – and we will in due course release the issues under which we are appealing – we realize there is a long and substantive list of unaddressed issues that will form the basis of this, and there may we will be issues tha

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

* One of the principles of natural justice is that one cannot be judge and party in a case. In the matter under discussion, Mr Decraene is the Working Group Chair taking the decision(s) on draft-ietf-spring-srv6-network-programming and listed as a Contributor of draft-ietf-spring-srv6-network-p

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming (off-topic)

The usual practice when a hair o-authors a document is for the co-chair to manage all aspects of the document life cycle. In this case, due to the co-chair being unavailable, we have a bit of a problem. For non-contentious documents, we can easily manage anyway. In this case, the document is quite

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

I am completely stunned by this. The question regarding RFC8200 is still unaddressed. The promises to deliver an assessment of IP Space burn as per what is on video from the montreal meeting – was not delivered on or addressed The issues around the potentially problems in relation to rfc7112 – ha

Re: [spring] Resignation request

> On 02/03/2020, 23:34, "ietf on behalf of Sander Steffann" > wrote: > >Hi, > > I am shocked by the declaration of consensus on > draft-ietf-spring-srv6-network-programming by Martin Vigoureux. There was > much discussion going on about one aspect of the draft, and there was clearly

Re: [spring] Resignation request

Contributor - not co-author - but also with 6 drafts that have normative references to the draft in question that could not proceed if this stalled Andrew On 03/03/2020, 00:44, "ietf on behalf of Sander Steffann" wrote: Hi, > I have no information about the situation but I do n

Re: [spring] SRv6 PSP use case

Thanks Joel for the inference. Would love to have some comment from the authors on this. In the mean time in the next 2 or 3 days I’ll write some code and see if I can verify this theory across a range of vendor devices that I have, will advise on the results I get. Thanks Andrew From: spri

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

I have to second the below from an operator perspective. When a vendor is pushing me to implement a technology – yet not disclosing that implementing it could result in serious network degradation dependent on the boxes I have in the network and their positioning – that exposes me as an operato

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

question. For now – I will refrain from naming said vendor – but they are free to raise their hands and own up to it if they choose to do so Andrew From: Robert Raszuk Date: Thursday, 5 March 2020 at 01:04 To: Andrew Alston Cc: "Joel M. Halpern" , "Darren Dukes (ddukes)"

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

From: Pablo Camarillo (pcamaril) Sent: Wednesday, 4 March 2020 15:17 To: Andrew Alston ; Martin Vigoureux ; spring@ietf.org Cc: 6...@ietf.org; draft-ietf-spring-srv6-network-programming Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming Andrew, Inline. PC1. Regards

[spring] Packet Captures?

Hi Guys, I just wondered, since there are people on this list who are on the deployment draft – if anyone here has some packet captures from platforms that actually use the SRH. In an effort to truly understand the behavior of the network programming draft and be able to comment in an informed

Re: [spring] Who is the design ultimate authority over IPv6? (Re: WGLC - draft-ietf-spring-srv6-network-programming)

Sorry realized I had hit direct reply so adding relevant Andrew Get Outlook for iOS<https://aka.ms/o0ukef> From: Andrew Alston Sent: Sunday, March 8, 2020 09:07 To: Brian E Carpenter Subject: Re: Who is the design ultimate authority over IPv6? (Re: [spring

Re: [spring] Dispute process (Was: Resignation request)

So, As one of the people that openly supported the original request for resignation by Sander - I felt that - it may be helpful to understand from my side *why* I so strongly supported it - and why I believe, still, that it was a fair option. Firstly - let me say this - there are several outsta

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Pablo PC2: The comment started because in the draft we had an example that was assigning A:1::/32 as loopback interface for a router. This is wrong (prefix length, documentation prefix,). This was fixed in revision 2 of the WG draft, published in September 19th 2019. The closure of this comment

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

First I fail to see in the recording where such promise happened. I asked you for the precise timing but you did not send it. It seems to me that you are putting words in someone else’s mouth, because the presenter asked you politely to send your comment to the mailer and you didn’t. Then you ar

[spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

the fact that draft-ietf-spring-network-programming violates the address semantic specifications of RFC4291. Can we please have a proper discussion on this Thanks Andrew From: "Darren Dukes (ddukes)" Date: Wednesday, 11 March 2020 at 22:03 To: Ron Bonica Cc: Andrew Alston , 6man W

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

To: Andrew Alston ; Darren Dukes (ddukes) ; Ron Bonica Cc: spring@ietf.org; 6man WG Subject: Re: Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture? On 12-Mar-20 09:53, Andrew Alston

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

nicely side stepped. Andrew From: Pablo Camarillo (pcamaril) Sent: Wednesday, 11 March 2020 17:42 To: Andrew Alston Cc: 6man WG ; spring@ietf.org Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming Andrew, The threads you initiated describing technical questions on the mailing

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

, Andrew Best regards, Ole > On 12 Mar 2020, at 09:26, Andrew Alston > mailto:andrew.als...@liquidtelecom.com>> > wrote: > > Brian, > > Let me clarify a few things – for my own understanding – I am happy to be > wrong here, and if I am just let me know (while what I

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Jim Given RFC2460 definition of a link I am wondering which “link” a loopback interface attaches to in your opinion? I would argue the answer to that is in the name – loopback Thanks Andrew From: spring mailto:spring-boun...@ietf.org>> On Behalf Of Andrew Alston Sent: Thursday, Ma

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Martin, Since myself - and others still believe the consensus call was fundamentally flawed and a violation of process - we actually welcome this continuing so that we can finally officially lodge the prepared appeals. Thank you for this Thanks Andrew From: spring On Behalf Of Martin Vigou

Re: [spring] Appeal to the IESG re WGLC of draft-ietf-spring-srv6-network-programming

Just to confirm, I fully support this appeal. Thanks Andrew From: Fernando Gont Sent: Thursday, 23 April 2020 05:27 To: The IESG Cc: Andrew Alston ; Sander Steffann ; spring@ietf.org; 6...@ietf.org; 'i...@ietf.org' Subject: Appeal to the IESG re WGLC of draft-ietf-spring-sr

Re: [spring] Adoption call criteria for CRH? [was: Re: CRH and RH0]

Zafar, Let me give another perspective on this. In Montreal – people screamed – no use case – a use case was provided – and for months after – people kept screaming – no use case – until they couldn’t scream it anymore because the mails showed clearly that use cases had been supplied Then – we

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

Actually Ketan, As an operator – I am looking for the tyre – I want the building block – because it allows me to both use what the vendors build on top of it – and to build my own stuff on top of it that is specific to my needs. The tyre association is one such association – the brick is anothe

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

can do what they need on devices – rather than the dictates of vendors? I think the very fact that the above article exists – illustrates the desire for simple building blocks. Thanks Andrew From: spring On Behalf Of Andrew Alston Sent: Friday, 22 May 2020 12:15 To: Ketan Talaulikar (ketant

Re: [spring] 答复: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

. Hence – yes – I like simple building blocks Andrew From: spring On Behalf Of Aijun Wang Sent: Friday, 22 May 2020 18:55 To: Andrew Alston ; 'Ketan Talaulikar (ketant)' ; 'Joel M. Halpern' Cc: rtg-...@ietf.org; spring@ietf.org; '6man' <6...@ietf.org> Subj

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

I think a better question would be – not if hats are on or off – but which hat – the employee of a vendor hat? The WG chair hat? The CoC hat? The “In personal capacity” hat? Like Ron and others – I’m kinda curious here Andrew From: spring on behalf of Ron Bonica Date: Monday, 25 May 2020

Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Speaking as an operator that operates in 15 countries – yes – yes and yes again. SRv6 will never find a home on our network – it is complex, it has massive overhead, it overloads the address space in ways that make me cringe, it currently (in my view) violates RFC8200, the network programming dr

Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Date: Tuesday, 26 May 2020 at 20:26 To: Andrew Alston , Mach Chen , "Zafar Ali (zali)" , Ron Bonica , "Chengli (Cheng Li)" , 6man <6...@ietf.org>, "spring@ietf.org" Subject: RE: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option? Hi Andrew, So

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

What I find so bizarre is – You have an multiple operators – who have clearly said – we want this – we see advantage of this. Yet still the obstructionism and denialism continues. The “not invented here” syndrome seems to run deep – and email after email is patently ignored from the very peop

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Zafar, It amazes me how totally selective you are with your reading. I won’t even bother dignifying much of the word twisting and gaming and selective reading with a response – but what I will say is this. Yes, originally, CRH was heavily linked to SRm6. But – over time, thinking and ideas e

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

t; dedicated working groups with expertise in the area. > > Why should CRH be an exception, especially when there are multiple competing > solutions in 6man and Spring? > > > > Thanks > > > > Regards … Zafar > > > > From: "Templin (US),

[spring] IPv6+??

Hi All, I came across this website: https://www.ipv6plus.net/ Now, I wish to clarify a few things. 1. This website seems to imply – strong – that Srv6 is not infact IPv6 – but rather IPv6+ - is this the position of the member of this working group or is this simply someones bizarre idea?

Re: [spring] Spring protection - determining applicability

So – One of the use cases, in fact, some very major use cases in any spring technology for us revolve around the following 1. The explicit avoidance of certain nodes 2. The explicit avoidance of certain sections of the network Anything that could result in that explicit avoidance being v

Re: [spring] Spring protection - determining applicability

: Andrew Alston Cc: Joel M. Halpern ; Robert Raszuk ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Hi Andrew, would such requirements support using e2e protection? Regards, Greg On Mon, Aug 3, 2020 at 2:46 PM Andrew Alston mailto:andrew.als

Re: [spring] Spring protection - determining applicability

Raszuk Sent: Tuesday, 4 August 2020 01:27 To: Andrew Alston Cc: Joel M. Halpern ; spring@ietf.org Subject: Re: [spring] Spring protection - determining applicability Is this a common use case ie. "but rather – which nodes / network segments it can never touch or flow through." If so p

Re: [spring] Spring protection - determining applicability

production ready code is of an urgency that no longer allows us to wait for months – thankfully we get what we need as a result of CRH and it does work – and work well Thanks Andrew From: Greg Mirsky Sent: Tuesday, 4 August 2020 03:18 To: Andrew Alston Cc: Joel M. Halpern ; Robert Raszuk ; spring

Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt

Erm, Ok – so – we have waited 6 months for a document – that we will go into SPRING and 6man to discuss – and what we have here in my view – is a document that says precisely nothing. I’m going to take this section by section – and I would have hoped sending an email like this – that it would

Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

From: spring On Behalf Of Stefano Salsano Sent: Friday, 20 November 2020 08:09 To: 程伟强 ; spring Cc: srcomp ; spring-chairs@ietf.o Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt Il 2020-11-15 16:27, 程伟强 ha scritto: > Hi Group, > > SR

[spring] CRH Prototype development

Hi Guys, I have been given permission to share that we have confirmation that Intel is currently working on a prototype firmware for the E810 cards – as well as DPDK support for CRH. This is also what we have been working on in our active code development internally and forms the basis for how

Re: [spring] SRv6 compression

From my side, With or without the IETF – I will continue to use CRH and we will continue to make product choices based on it. CRH is not SRv6 – it is, and we have stated this before, a building block for many things. In our case – the ability to steer traffic is what drives a lot of what we do

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Sorry – but – I’m a little confused here. Because the way I look at this – the working group clearly stated that they wished for a single behavior – and this – does not deliver that – it is two separate behaviors. As such – I see this call for adoption – irrespective of the merits or lack ther

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

working group consensus should be sacrosanct. Andrew From: Andrew Alston Date: Friday, 1 October 2021 at 23:21 To: James Guichard , SPRING WG Cc: spring-cha...@ietf.org Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Sorry – but

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

pport this combination as we are proposing. Thanks Andrew From: James Guichard Sent: Monday, October 4, 2021 6:10 PM To: Andrew Alston ; SPRING WG Cc: spring-cha...@ietf.org Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ A

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

granted in step one if the working group feels that there is grounds for two solutions. This at least allows us to progress without a stale mate Andrew From: Gyan Mishra Date: Monday, 4 October 2021 at 19:49 To: James Guichard Cc: Andrew Alston , SPRING WG , Tony Li , "sprin

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

As an operator I have to admit – I always have slight concerns when people start referring to these limited domain applications – and here is why. Many networks – including the one I run at the moment – are segregated for a host of reasons. Separate IGP levels – a few ASN’s – BGP labeled unicas

Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Figured I would weigh in here once again - and try and summarize the way I see things. 1. The working group found consensus on a single behavior - this document contains 3 - if that consensus is to be changed - let it be changed by the working group before we walk down this path. 2. The

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Robert, I would say that many of your arguments – particularly that srv6 is not exactly ipv6 – if my interpretation of your emails is correct – indicate that indeed – we seem to be in the terrain of modifying or extending things that would put this wg In violation of its own charter – and the s

[spring] Further thoughts on g-srv6/csid

Hi All, So - to understand the claims of compatibility between the behaviors within the same domain - I decided the best way to test this was to write some actual code to simulate it. I'm hoping to get the full simulation code out in the next 24 hours - but in the mean time I figured I'd add s

Re: [spring] CSID proposed clarifications

(Apologies if this appears twice - seems something went screwy with my outbound address so the other version of this is moderated) Darren, I'm a little confused here reading this - but all said and done - on the next behavior - how is this different from doing something along the lines of Da[l

Re: [spring] CSID proposed clarifications

Darren, I'm a little confused here reading this - but all said and done - on the next behavior - how is this different from doing something along the lines of Da[loc_bits/8] << sid_size Because - when I trace this all out into actual C code - that's pretty much what it seems to summarize down

Re: [spring] CSID proposed clarifications

(Apologies if this appears twice - seems something went screwy with my outbound address so the other version of this is moderated) Darren, I'm a little confused here reading this - but all said and done - on the next behavior - how is this different from doing something along the lines of Da[l

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-01.txt

g filtered on, on the preceding hop. (Yes this is highly theoretical, but - I'd like to hear the authors comments on this) Looking forward to the response Yours Sincerely Andrew Alston From: spring On Behalf Of internet-dra...@ietf.org Sent: Wednesday, 3 July 2019 12:05 To: i-d-annou

[spring] FW: New Version Notification for draft-alston-spring-crh-bgp-signalling-00.txt

Hi All, We’ve just submitted the below, please review and give us any feedback! Thanks Andrew From: internet-dra...@ietf.org Sent: Monday, 8 July 2019 18:01 To: Ron Bonica ; Andrew Alston ; Andrew Alston ; Daniam Henriques Subject: New Version Notification for draft-alston-spring-crh-bgp

Re: [spring] Comment on draft-alston-spring-crh-bgp-signalling-00

ed if you are carrying the SAFI and either missing that attribute or that attribute is not set to 2 or 4. We'll look at clarifying the wording - thanks for the input. Thanks Andrew -Original Message- From: S Moonesamy Sent: Wednesday, 10 July 2019 12:10 To: Andrew Alston ; sprin

Re: [spring] Approaches to MTU efficiency in SRv6 in todays SPRING session

> It is also not true that uSID inflates the IGP and/or FIB tables > more than other approaches. A uSID is advertised just like > other SRv6 SIDs, although the prefix length will typically > be much shorter. The fact that no extra label mapping > table is required contributes to improved control

Re: [spring] Beyond SRv6.

Thanks Rob, So – Firstly let’s start with the use cases. Our biggest requirement for any of this is about traffic steering and about removal of V4 from the network in the long term. Our entire motivation for getting involved in SR in the first place initially revolved around the fact that in

Re: [spring] Beyond SRv6.

Yes and no – because that assumption assumes that we will not see a growth of in the requirement where I have a need to actually working with steering inside those islands – as the temp solution you are correct. As a long term solution – with the abandonment of SR-MPLS by certain vendors in the

Re: [spring] Beyond SRv6.

I can state categorically that we have a solid case to use 8 to 12 SID’s – Let me put it this way – If I cross my own network – To get to certain countries I have to pass through no less than 5 separate countries in certain scenarios – and it’s not practically possible to avoid this. When I add

Re: [spring] Beyond SRv6.

still get around to doing this – time has just been a little hectic of late. Andrew From: Robert Raszuk Date: Sunday, 1 September 2019 at 22:28 To: Andrew Alston Cc: Ron Bonica , Rob Shakir , SPRING WG List , "6...@ietf.org" <6...@ietf.org> Subject: Re: [spring] Beyond

Re: [spring] Beyond SRv6.

Just another note on clashes – any company that deals with constant and frequent merges and acquisitions will know – uniqueness is paramount – unless you want integration headaches that will cause you weeks of sleepness nights. And when you’re doing 3 or 4 M&A’s a year – this is very very very i

[spring] Questions about draft-ietf-spring-srv6-networking-programming and draft-filsfils-spring-net-pgm-extension-srv6-usid

Hi All, The following things in the drafts referenced in the subject line are questions that I feel need to be addressed - since having gone through these drafts closely in light of some of the comments on the spring list and cross referenced and checked a number of things - there are a number

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Even if you remove the reference – you still have problems in 4.13 and 4.21 which manipulate the headers. I also point out that it’s rather hard to argue that headers aren’t being inserted when the network programming draft is explicitly mentioned as a normative reference for draft-ietf-lsr-isi

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Ole, I'm far from convinced that saying we stop - while the issue is a very big can of worms - is a good idea. Right now, there is a clear issue on the table here - and there are no proposals on how to address this - where addressing it would be either to remove the issue from the draft or pro

Re: [spring] Beyond SRv6.

> This is absolutely false!   > Have you forgotten the very strong arguments against it at the Spring session > in Montreal and the various emails on the list that echoed them 😉 > Not to mention comments from Robert R > (https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo)

Re: [spring] Beyond SRv6.

Zafar, One of the things I keep seeing below is you referring to the operators perspective. So - as someone who actually is from an operator - and has done substantial testing of the proposed solution let me give you the perspective of an operator. Firstly - as an operator - on the table mapp

Re: [spring] Question about SRv6 Insert function

Robert, my problem here is – I believe that there could have been common ground found between various proposals except – what the current drafts do – is fundamentally rewrite the ipv6 protocol – the changes in the address semantics (twice over in incompatible ways between the programming draft a

Re: [spring] Beyond SRv6.

on top of it. But again – we have asked – multiple times – for the technical problems behind CRH – and the ringing in my ears is deafening from the silence. Andrew From: Zafar Ali (zali) Sent: Friday, 6 September 2019 11:28 To: Robert Raszuk ; Andrew Alston Cc: Ron Bonica ; Srihari Sangli

Re: [spring] Question about SRv6 Insert function

I second this - and I was extremely clear in my email to spring a few weeks ago - I believe that there is place for both srv6+ and the alternatives - especially since I point out that srv6+ solves an overhead problem that was not solved by srh or the programming draft - and actually pre-dates th

Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Zafar, While I am not going to answer all the points in your email – I am going to raise one issue. You talk about NOT debating a solution. I point out that it was also stated in Montreal that we needed an analysis of the IPv6 address space required by the network programming and usid drafts.

Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

>> Please elaborate about the real deployment. Where was it deployed? In what >> kind of networks? On what scale? For which use cases? > > https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-01

Re: [spring] 答复: Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

will not satisfy everyone, will be in the interests of the market in general by avoiding a total standoff. Just my thoughts Andrew From: Zafar Ali (zali) Sent: Wednesday, 11 September 2019 07:27 To: Aijun Wang ; 'Robert Raszuk' ; 'Sander Steffann' Cc: 'Ron Bonica'

Re: [spring] “SRV6+” complexity in forwarding

* You also suggest that Juniper’s is the only implementation. Are you sure that this is correct? There is a packet capture of CRH for anyone who is interested taken from our DPDK implementation – in this case – this is from the source node of traffic – steering through nodes 3 -> 2 -> 5

[spring] A note on CRH and on going testing

Hi Guys, I thought this may be of interest in light of discussions around deployments and running code - because one of the things we've been testing is inter-domain traffic steering with CRH on both our DPDK implementation and another implementation. So - the setup we used last night: 6 syst

Re: [spring] SRm6: Motivation?

Just to add to this because it’s the one thing that I am still confused about. We are referring to finishing the work on SRv6 - what does this mean? SRH is with the editors - meaning - its pretty much completed (and it came out of 6man not spring) Network programming and CRH are entirely differe

[spring] CRH and Unified SID Draft

state that we have agreed in combination to work together towards common cause. Yours Sincerely Andrew Alston / Greg Mirsky ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

[spring] CRH and Unified SID - Follow up email

Hi Guys, I just wanted to clarify something that we are being asked on both sides from various quarters. The announcement made earlier does not indicate that we are doing a merge of the documents, what it means is that we have agreed to technical discussions to explore a way forward and are wo

  1   2   >