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

Hi Thanks Ted for the constructive suggestions, which remind me to try to understand the questions. Here are the questions I think give the clear suggestions for LC. Brian: So could the draft make this explicit, because I guarantee you it is not in the least obvious to the non-expert reader?

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

Inline gyan> On Thu, Feb 27, 2020 at 4:00 PM Pablo Camarillo (pcamaril) < pcama...@cisco.com> wrote: > Gyan, > > > > Inline [PC1]. > > > > Thanks, > > Pablo. > > > > *From: *Gyan Mishra > *Date: *Thursday, 27 February 2020 at 08:14 > *To: *"Pablo Camarillo (pcamaril)" > *Cc: *SPRING WG > *Subj

Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

Hi Chris, I agree with Peter and I would suggest to drop LSR since this is not a protocol specific thing. I believe the text in draft-ietf-spring-srv6-network-programming clears says what locator block and locator node are. What more details do you think are required? Thanks, Ketan From: Lsr

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

Hi John, Please check inline below. From: spring On Behalf Of John Scudder Sent: 28 February 2020 02:41 To: SPRING WG ; 6man WG Cc: Ron Bonica ; daniel.vo...@bell.ca Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt I have an additional observation, or questi

Re: [spring] A permanent change to/violation of RFC8200 for a temporary situation. (Re: Is srv6 PSP a good idea)

Hi Mark, Just to clarify, the SRv6 control plane is not being extended beyond the SRv6 data plane. Let me explain. The legacy egress PE which does not have SRH processing capabilities is still instantiating the SRv6 End.DT/DX SID [ref net-pgm draft sec 4.4-8] in its FIB. That is still SRv6. No

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

Hi Ted, I’ve tried to clarify Brian’s point : https://mailarchive.ietf.org/arch/msg/spring/rb23KclF_SKqRsnjvm82192vBZ8/ The draft under WGLC review in Spring WG already has pointers to all those drafts that I’ve mentioned. Thanks, Ketan From: ipv6 On Behalf Of Ted Lemon Sent: 28 February 202

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

Hi Brian, It is likely that things are not clear if one were to just try to read the text around just the specific section of the draft which covers PSP. The document does needs prior understanding of the SR Architecture RFC8402 and SRH draft in addition to reading of the entire network progr

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

On 28-Feb-20 15:06, Stefano Salsano wrote: > Brian, > > Il 2020-02-28 02:47, Brian E Carpenter ha scritto: >> Stefano, >> >> The problem is that the draft simply doesn't explain (or refer to an >> explanation) of what this "penultimate segment" is. There are at least three >> hypotheses which I

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

Brian, Il 2020-02-28 02:47, Brian E Carpenter ha scritto: Stefano, The problem is that the draft simply doesn't explain (or refer to an explanation) of what this "penultimate segment" is. There are at least three hypotheses which I suspect different people are using, leading to this endless d

Re: [spring] Is srv6 PSP a good idea

Ridiculous .. any NOS coder, coding IPv6, would have awareness of 2460, why would you even go there .. seriously ? The highlight was for: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#page-4 - you should probl read it all. I think we've reach the limit of what the "IET

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

Pablo, I have been looking at the latest version. See my previous note to Stefano Salsano. I really think that the problem here is that certain things are obvious to SRH experts but not to others, and they simply need more explanation in elementary terms. Regards Brian Carpenter On 28-Feb-

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

Stefano, The problem is that the draft simply doesn't explain (or refer to an explanation) of what this "penultimate segment" is. There are at least three hypotheses which I suspect different people are using, leading to this endless dialogue: 1) It's a forwarding node, a.k.a. a router, that b

Re: [spring] Monitoring metric to detect and locate congestion

Yes you are right. That may only work in single-chip pizzabox. So link coverage is needed in general. Haoyu From: Tianran Zhou Sent: Thursday, February 27, 2020 5:37 PM To: Haoyu Song ; Robert Raszuk Cc: ippm-cha...@ietf.org; spring@ietf.org; i...@ietf.org Subject: RE: [spring] Monitoring metr

Re: [spring] Monitoring metric to detect and locate congestion

I take the second point. But it also gives short coming, the probe cannot take many data in one packet. The first point I do not understand. You said “combination ingress+egress queuing information on each transit node”. I suppose you mean all the queues information in this node. This in my opini

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

Hi Pablo, thank you and al lthe authors for kind consideration of my comments, much appreciated. I've found all my comments being address in the latest version of the draft.. I'll now discuss with Zafar OAM-specific aspects of using some of behaviors defined in the SRv6 network programming. Would b

Re: [spring] Monitoring metric to detect and locate congestion

Two key differences. (1) you want to do this purely in data plane fast path. (2) you don’t want to keep a streaming session from each node for scalability reason The path probing approach can meet both requirements. Haoyu From: Tianran Zhou Sent: Thursday, February 27, 2020 5:14 PM To: Haoyu S

Re: [spring] Monitoring metric to detect and locate congestion

This is a good point. In this way, the probe is generically used to collect node data. At each node, the probe will be send to the slow path to get the node data. Data could be carried in the payload which has more space. Then, what’s the difference to existing way that Robert mentioned? Use str

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

At Thu, 27 Feb 2020 23:41:18 +, "Darren Dukes (ddukes)" wrote: > Hi Jinmei, allow me to address the two technical concerns you raise > in this email, upon which it appears this interpretation of RFC8200 > hinges for you. You state: > > Aside from that this > > interpretation logically doesn

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

+1 in support of moving the documentation forward. Regards, Keyur From: spring on behalf of "Zafar Ali (zali)" Date: Wednesday, February 26, 2020 at 9:43 AM To: Lizhenbin , "bruno.decra...@orange.com" , 'SPRING WG List' Cc: "6...@ietf.org" <6...@ietf.org>, "Zafar Ali (zali)" , draft-ietf-sp

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

Jinmei, My apologies. I was writing my message as you posted yours. I agree fully with both the spirit and letter of your message. Ron Juniper Business Use Only -Original Message- From: 神明達哉 Sent: Thursday, February 27, 2020 5:18 PM

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

Hi Jinmei, allow me to address the two technical concerns you raise in this email, upon which it appears this interpretation of RFC8200 hinges for you. You state: > > Aside from that this > interpretation logically doesn't make sense as it's not compatible > with AH or PMTUD, if it could be jus

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

Mark, Good point. I think that "The Devil's Paragraph" in RFC 8200 may be ambiguous. We should tighten it us using whatever mechanism the AD's suggest. Clearly, this will take time. Until then, we should probably hammer out some compromise so that the bulk of the network programming draft can

Re: [spring] A permanent change to/violation of RFC8200 for a temporary situation. (Re: Is srv6 PSP a good idea)

Hi Pablo, On Fri, 28 Feb 2020 at 07:51, Pablo Camarillo (pcamaril) wrote: > > Mark, > > Both the SRv6 control plane and dataplane operate between PEs. The legacy > egress PE only executes End.DT/End.DX and is not capable of doing SRH > processing at linerate in the use-case described by Dan. I

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

Hi Ron, On Fri, 28 Feb 2020 at 08:30, Ron Bonica wrote: > > Jinmei, > > The current discussion is about Penultimate Segment Popping (PSP) (Section > 4.16). Normally, when an IPv6 node processes a packet that includes a Routing > header with Segment Left equal to 1, the node decrements Segments

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

On 27/2/20 19:34, Suresh Krishnan wrote: Hi Jinmei, On Feb 27, 2020, at 5:18 PM, 神明達哉 wrote: At Thu, 27 Feb 2020 21:29:24 +, Ron Bonica wrote: The question is whether PSP violates the following clause from Section 4 of RFC 8200: "Extension headers (except for the Hop-by-Hop Options h

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

Hi Jinmei, > On Feb 27, 2020, at 5:18 PM, 神明達哉 wrote: > > At Thu, 27 Feb 2020 21:29:24 +, > Ron Bonica wrote: > >> The question is whether PSP violates the following clause from Section 4 of >> RFC 8200: >> >> "Extension headers (except for the Hop-by-Hop Options header) are not >> pro

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

At Thu, 27 Feb 2020 21:29:24 +, Ron Bonica wrote: > The question is whether PSP violates the following clause from Section 4 of > RFC 8200: > > "Extension headers (except for the Hop-by-Hop Options header) are not >processed, inserted, or deleted by any node along a packet's delivery >

Re: [spring] Is srv6 PSP a good idea

On 27/2/20 18:11, Darren Dukes (ddukes) wrote: Mark AH is not defined for SRH.  There is no specification to ignore. Do you realize that you are using IPv6, and that AH is specified for IPv6? Is the AD watching? -- Seriously, this is going through a very curious and dangerous path. For the

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

On 27/2/20 18:29, Ron Bonica wrote: Jinmei, The current discussion is about Penultimate Segment Popping (PSP) (Section 4.16). Normally, when an IPv6 node processes a packet that includes a Routing header with Segment Left equal to 1, the node decrements Segments Left and forwards the packet,

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

Thank you for writing this down so well. This is exactly how I feel about this issue too, but you are much better at staying polite :) Cheers! Sander ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

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

Jinmei, The current discussion is about Penultimate Segment Popping (PSP) (Section 4.16). Normally, when an IPv6 node processes a packet that includes a Routing header with Segment Left equal to 1, the node decrements Segments Left and forwards the packet, with the Routing header intact. In PSP

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

Brian, > For example, the word "pop" is used but still not defined. In computer > science, it generally refers to popping a stack. I understand that in the > MPLS context (a label stack) but not in the IPv6 context, where there is no > stack in the header. You raised such comment on Decem

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

I have an additional observation, or question, about Dan’s scenario. Almost all communication is bidirectional. Presumably this means a router that’s the tail end of an SRv6 path in one direction is the head end in the other. Doesn’t a head end need to add an SRH? If I’ve gotten that right, then

Re: [spring] Is srv6 PSP a good idea

Mark AH is not defined for SRH. There is no specification to ignore. Recall RFC8200 says nothing about mutability, it only describes things that are modified in flight and how/why. RFC4301 builds on RFC8200 to define mutability for use in AH ICV computation without having to modify RFC8200. “Mu

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

Fernando, In order for an IPv6 node to process the SRH (or other routing header) the address of such router needs to be in the IPv6 Destination Address. Right? Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's

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

Gyan, Inline [PC1]. Thanks, Pablo. From: Gyan Mishra Date: Thursday, 27 February 2020 at 08:14 To: "Pablo Camarillo (pcamaril)" Cc: SPRING WG Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt In-line response On Tue, Feb 25, 2020 at 10:16 AM Pablo Camari

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

On Feb 27, 2020, at 3:38 PM, Pablo Camarillo (pcamaril) wrote: > The discussion that we are having is about PSP which has nothing to do with > that. So, there is text in the document that addresses Brian’s question? ___ spring mailing list spring@iet

Re: [spring] A permanent change to/violation of RFC8200 for a temporary situation. (Re: Is srv6 PSP a good idea)

Mark, Both the SRv6 control plane and dataplane operate between PEs. The legacy egress PE only executes End.DT/End.DX and is not capable of doing SRH processing at linerate in the use-case described by Dan. And as a reminder this is only one of the use-cases of PSP. Cheers, Pablo. -Orig

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

Ted, > The situation here is that all the objections appear not to have been > addressed, and that agreed-upon supporting work has not been done (and nobody > wants to do it). Let me recall: 1.- draft-ietf-spring-srv6-network-programming contained a section about SRH insertion by a transit nod

Re: [spring] Monitoring metric to detect and locate congestion

Can the combination ingress+egress queuing information on each transit node be collected by simply visit the node? If so, one or more probing paths that can cover all the nodes are sufficient. Best, Haoyu From: Robert Raszuk Sent: Thursday, February 27, 2020 12:18 PM To: Haoyu Song Cc: ruedig

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

Nick, The draft does not require changes to address assignment policy. SRv6 has been already deployed using IPv6 addresses already available to the operator. As an example for Softbank (all this is based on their public information that they have reported): They have a /20 IPv6 prefix available

Re: [spring] Monitoring metric to detect and locate congestion

The point is not to assure all egress ports are inspected. The point of any really useful end to end path probing is to find out if combination of ingress+egress queuing on each transit node my packet may traverse are not congested. Looking at Eulerian path algorithm I do not see such guarantees.

Re: [spring] Monitoring metric to detect and locate congestion

Hi Robert, The Eulerian path algorithm guarantees to visit all the edges of a graph. In the SR context, we can consider the sub-path between two segments an edge. Haoyu From: Robert Raszuk Sent: Thursday, February 27, 2020 11:50 AM To: Haoyu Song Cc: ruediger.g...@telekom.de; ippm-cha...@ietf

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

On Wed, Feb 26, 2020 at 11:39 AM wrote: > > So... is the plan to ship a document that violates RFC8200? > > Please forgive me asking some clarification question that seems to be > obvious for others: which part of > draft-ietf-spring-srv6-network-programming-10 violates RFC8200? From > a quick r

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

On Thu, Feb 27, 2020 at 2:27 PM Joel M. Halpern wrote: > > THere is one nuance that is worth noting. It is not for the case of a > controversial document. > > Rather, the case where +1 can be useful is when the question is whether > the working group even cares about the document. I have had sev

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

Robert – Do you know or can you please name any hardware that cannot do line rate PSP? I could understand not being able to do USP at line rate – which may in certain implementations cause re-circulation (maybe THAT’S the unstated dirty secret that are keeping people pushing this without stati

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

Two different disagreements with you. First, I did list adoption as well as last call. In adoption the chairs can't very well look back at the adoption to see if there was really support. Second, it is the WG, not the document authors, that send a document to the AD for IETF approval. if the

Re: [spring] Monitoring metric to detect and locate congestion

Hi Haoyu, > which applies Eulerian Path algorithm to find the minimum set of paths with network-wide coverage. In practice networks use ECMP. ECMP decision may happen at each hop. Your end to end flows get spread over all ECMP paths. So limiting number of probed paths is inaccurate to the fundame

Re: [spring] Monitoring metric to detect and locate congestion

Hi Ruediger, I like the general idea that using pre-determined paths in SR to collect performance metrics. I think this approach provides some unique benefits compared with the other approaches. It is also coincident with some of related research work I'm doing. Here are some thoughts I have.

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

On Feb 27, 2020, at 2:27 PM, Joel M. Halpern wrote: > Rather, the case where +1 can be useful is when the question is whether the > working group even cares about the document. I have had several cases of > calls for adoption or WG last call where there was almost no response on the > mailing

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

THere is one nuance that is worth noting. It is not for the case of a controversial document. Rather, the case where +1 can be useful is when the question is whether the working group even cares about the document. I have had several cases of calls for adoption or WG last call where there wa

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

Ron, How about we go the other way and really admit that some hardware just can not PSP at line rate ? But for that there is very simple solution - you advertise PSP depth of zero in IGP extensions and you are done. Both ISIS and OSPFv3 extensions support this already today. And as it has been

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

On Feb 27, 2020, at 1:59 PM, Robert Raszuk wrote: > It is very unfortunate that IETF does not have a good way of retrieving > judgement from real group of folks who understand given proposal. We do. It’s called “substantive comments.” > "+1" is just only one demonstration of it. Humming is a

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

Warren, Excellent note !!! In the past I have been part of an employers forcing you to support a draft just to push it regardless if it was even in your area of interest ... leave alone expertise or your technical opinion about it. It is very unfortunate that IETF does not have a good way of ret

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

Pablo, The question at hand is whether PSP is so crucial to SRv6 that it is worth stretching the limits of RFC 8200 compliance. The emails that you site below say that it is for the following reasons: 1. Because PSP is already deployed 2. Because PSP unburdens the ultimate segment router

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

On Wed, Feb 26, 2020 at 8:14 PM Brian E Carpenter wrote: [SNIP] > > It's possible that "penultimate" means something else, e.g. "ultimate". I > don't know. I've been puzzling over this language for months and it doesn't > change. Maybe someone can finally post an explanation, but until they do

[spring] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

SPRING and LSR WGs, I think that we need a much more detailed description of the locator block and locator node in either draft-ietf-spring-srv6-network-programming or draft-ietf-lsr-isis-srv6-extensions. See original email below. Thanks, Chris On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak wr

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

+1 From: ipv6 On Behalf Of Yisong Liu Sent: Wednesday, February 26, 2020 8:14 PM To: Voyer, Daniel ; Dirk Steinberg Cc: SPRING WG List ; 6man <6...@ietf.org>; draft-ietf-spring-srv6-network-programming Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spr

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

Fernando, Il 2020-02-27 12:11, Fernando Gont ha scritto: [... removed non-technical discussion] One of their last inventions has been to pretend that IPv6 allows EH insertion/deletion en-route, based on their reading of RFC8200. Based on a curious interpretation of the text, they claim that e

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

On Feb 26, 2020, at 8:14 PM, Brian E Carpenter wrote: > > I don't know about you, but when I see a message whose only content is "+1" I > just delete it. +1 ;-) —John ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spr

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

Andrew Alston wrote on 27/02/2020 10:35: 1. The burn of address space required to adequately deploy some of this (something that there was agreement on in Montreal that there would be analysis on – which was never done) I'm a bit alarmed by the lack of engagement here between the autho

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

Even if one assumes that the violation has not been proven, I think it has been shown clearly that PSP pushes the limits of 8200. If there is a strong reason for PSP, then pushing those limits is sensible. But the vast majority of the response we are getting to the issue on this list is eithe

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] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi all, I cannot say whether PSP is allowed or disallowed by RFC 8200. But, to the best of my understanding, format of SRH and its handling are specified by the IPv6 Segment Routing Header draft that is owned by the 6MAN

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

Fernando, Il 2020-02-27 10:07, Fernando Gont ha scritto: Bruno, On 27/2/20 05:41, bruno.decra...@orange.com wrote: Fernando, -Original Message- From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Fernando Gont Sent: Thursday, February 27, 2020 12:45 AM Hello, Eric, On 26/2/20 20

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

On Feb 27, 2020, at 8:02 AM, Voyer, Daniel wrote: > You should rephrase that - 1 objection can’t prevent the rest of us to move > forward hence why sometime we need to go with a rough consensus. Rough consensus means all the objections have been addressed, not that everyone agrees. The situati

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

This is really not helpful, Fernando, and goes some way toward explaining why communication isn’t happening. What I reacted to in Brian’s message is that he asked a really simple question that could be readily answered with a pointer to the text in the document where the answer is given. Since

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

On Feb 27, 2020, at 05:27, Ted Lemon wrote:  The IETF serves users, not “industry”. Wrong - it’s not the users that fund you to be here, it’s the industry - everything is about the money The IETF does not promote. Our job is to make the internet work interoperably. Brian has raised an object

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

+1 ! Sent from my mobile On Feb 27, 2020, at 04:30, Maojianwei (Mao) wrote:  Hi friends, Internet standard is aimed to promote deployment and innovation, but not to be a barrier. While this WG LC has been extended again and again, if we have reached an agreement that SRv6 can bring many adv

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

However, the PSP behavour doesn't even fit in that fictional interpretation of RFC8200. What PSP does is that, given: B - C routers, when B realizes, after processing the SRH and setting the Dest Addr to the last segment, SegmentsLeft==0, it removes the SRH. This case is not eve

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

Fernando, > From: Fernando Gont [mailto:fg...@si6networks.com] > > Bruno, > > On 27/2/20 05:41, bruno.decra...@orange.com wrote: > > Fernando, > > > >> -Original Message- > >> From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Fernando Gont > >> Sent: Thursday, February 27, 2020 1

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

Brian, Il 2020-02-27 03:29, Brian E Carpenter ha scritto: Stefano, On 27-Feb-20 14:42, Stefano Salsano wrote: Il 2020-02-27 02:14, Brian E Carpenter ha scritto: Eric, On 27-Feb-20 12:18, Eric Vyncke (evyncke) wrote: Writing this without any hat, Please note that on the logical side, it stil

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

On 27/2/20 07:27, Ted Lemon wrote: The IETF serves users, not “industry”.  The IETF does not promote. Our job is to make the internet work interoperably. Brian has raised an objection that could be answered, but has not been. It is inappropriate to say that this document has passed last call.

Re: [spring] Monitoring metric to detect and locate congestion

Hi Robert, thanks for your support and comments. I’d be glad if other interested operator representatives indicate their interest on the list... Regards, Ruediger Von: Robert Raszuk Gesendet: Donnerstag, 27. Februar 2020 10:38 An: Geib, Rüdiger Cc: ippm-cha...@ietf.org; SPRING WG ; i...@ietf.

[spring] A permanent change to/violation of RFC8200 for a temporary situation. (Re: Is srv6 PSP a good idea)

On Sat, 14 Dec 2019 at 09:14, Voyer, Daniel wrote: > > I agree 100% with Jingrong, > > PSP allows us to bring SRv6 to legacy PE devices that are not capable of > processing the SRH in the dataplane, but are capable of supporting SRv6 in > the control plane. > > See this example: > I am streaming

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

The IETF serves users, not “industry”. The IETF does not promote. Our job is to make the internet work interoperably. Brian has raised an objection that could be answered, but has not been. It is inappropriate to say that this document has passed last call. In my experience, when it is hard t

Re: [spring] Monitoring metric to detect and locate congestion

Hi, As I mentioned in my first mail I am a big supporter of end to end path measurement - mainly have been focusing on hop by hop timestamping approach. So my comments were not really to discourage in any way end to end path probing - it is extremely useful. They were just to see your point of vi

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

Hi friends, Internet standard is aimed to promote deployment and innovation, but not to be a barrier. While this WG LC has been extended again and again, if we have reached an agreement that SRv6 can bring many advantages for our network in future, we should shelve the dispute and promote indus

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

Bruno, On 27/2/20 05:41, bruno.decra...@orange.com wrote: Fernando, -Original Message- From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Fernando Gont Sent: Thursday, February 27, 2020 12:45 AM Hello, Eric, On 26/2/20 20:18, Eric Vyncke (evyncke) wrote: Writing this without any

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

Fernando, > -Original Message- > From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Fernando Gont > Sent: Thursday, February 27, 2020 12:45 AM > > Hello, Eric, > > On 26/2/20 20:18, Eric Vyncke (evyncke) wrote: > > Writing this without any hat, > > > > Please note that on the logical

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

On Thu, 27 Feb 2020 at 18:52, Dirk Steinberg wrote: > > > > On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont wrote: >> >> Hello, Eric, >> >> On 26/2/20 20:18, Eric Vyncke (evyncke) wrote: >> > Writing this without any hat, >> > >> > Please note that on the logical side, it still have to be "proven"

Re: [spring] Monitoring metric to detect and locate congestion

Hi Robert, regarding scalability, I hope the difference between our positions is just whether it’s a router or a dedicated CPE. I don’t promote deploying 20k PCs (I hope to promote a metric to replace them). I prefer the dedicated CPE, but routers do as well. The telemetry threshold might be a

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

On 27/2/20 04:51, Dirk Steinberg wrote: On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont > wrote: Hello, Eric, On 26/2/20 20:18, Eric Vyncke (evyncke) wrote: > Writing this without any hat, > > Please note that on the logical side, it still h

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

On 27/2/20 04:51, Dirk Steinberg wrote: On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont > wrote: Hello, Eric, On 26/2/20 20:18, Eric Vyncke (evyncke) wrote: > Writing this without any hat, > > Please note that on the logical side, it still h