Re: [spring] Is srv6 PSP a good idea

I think it's a good idea. Nothing new, but benefits that people have already said seems notable to me. (1) reduce the load of final destination. This benefit can be notable for the following sub reasons. (1.1) final destination tends to have heavy load. It need to handle all the EHs and do the d

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

On 10/12/19 21:23, Fernando Gont wrote: > Joel, > > On 10/12/19 19:49, Joel M. Halpern wrote: >> Fernando, I really wish I could agree with you. >> But I can't. >> >> In 8200, it is clear that the meaning fo "Destination Address" for an >> IPv6 packet is the value placed in the IPv6 destination ad

[spring] Is srv6 PSP a good idea

For purposes of this thread, even if you think PSP violates RFC 8200, let us assume that it is legal. As I understand it, the PSP situation is: o the packet arrives at the place (let's not argue about whether SIDs are locators) identified by the SID in the destination address field o that SID

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

Joel, On 10/12/19 19:49, Joel M. Halpern wrote: > Fernando, I really wish I could agree with you. > But I can't. > > In 8200, it is clear that the meaning fo "Destination Address" for an > IPv6 packet is the value placed in the IPv6 destination address field. One could indeed argue that the word

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

On 10/12/19 18:50, Robert Raszuk wrote: > > By your books does RFC 2473 or RFC 4798 or 100s of other RFCs which > encapsulate IPv6 packets all violate Internet Standard I presume IPv6 > spec ?  > > One of us clearly is missing the point. I will let list members judge > which one :) Could you ple

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

Tom, I was and am commenting on OSP.  Header insertion is a separate, lo8sely related, topic.I think it is quite important that we use the words we ended up with, both when they support what we want and when they do not.Yours,JoelSent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Thanks Bob for sharing your opinion. I fully agree with that, and I either don’t have any problem if an intermediate node decides to parse extension headers and modified one based on the definition of the specific EH. Regards, Jingrong -Original Message- From: ipv6 [mailto:ipv6-boun...@

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

On Tue, Dec 10, 2019 at 4:49 PM Joel M. Halpern wrote: > > Fernando, I really wish I could agree with you. > But I can't. > > In 8200, it is clear that the meaning fo "Destination Address" for an > IPv6 packet is the value placed in the IPv6 destination address field. > the fact that if we had loo

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Robert, On 11-Dec-19 09:18, Robert Raszuk wrote: > Hi Erik, > > What you are proposing IMHO is not needed.  > > Each SR node (Segment Endpoint) is effectively applying new IPv6 encap so is > already doing an insertion of new SRH That isn't "insertion" in the sense of draft-voyer. It's prepend

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

+1 Kindly remind that, there are ‘final destination’ wording 5 times in RFC8200. The 8200 is aware of difference of ‘destination’ and ‘final destination’. Line 375: note 3: for options to be processed only by the final destination Line 443:packet's final destination.

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Robert, > On Dec 10, 2019, at 2:05 PM, Robert Raszuk wrote: > > > > Other EH’s allow for different forms of modification, for example SRH > > allows for TLV modification, see Section 2.1. > > Section 2.1 talks about segment endpoint and that is where IPv6 outer header > destination address m

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

Bravo Joel ! On Wed, Dec 11, 2019 at 1:49 AM Joel M. Halpern wrote: > Fernando, I really wish I could agree with you. > But I can't. > > In 8200, it is clear that the meaning fo "Destination Address" for an > IPv6 packet is the value placed in the IPv6 destination address field. > the fact tha

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

> I would have to question your understanding of the term "end to end" > if you're make such an assertion. > My description of end to end purity of IPv6 is based on Fernando's comments. In his view if packet gets encapsulated with an arbitrary header and if that header changes hop by hop end to en

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

On Tue, Dec 10, 2019 at 6:22 PM Fernando Gont wrote: > > Bruno, > > On 10/12/19 13:18, bruno.decra...@orange.com wrote: > > Fernando, > > > > Thank you for spelling out your comment, plus on the WGLC thread. > > More in-line > > > >> Bruno, > >> > >> On 5/12/19 12:15, bruno.decra...@orange.com wro

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

Fernando, I really wish I could agree with you. But I can't. In 8200, it is clear that the meaning fo "Destination Address" for an IPv6 packet is the value placed in the IPv6 destination address field. the fact that if we had looked ahead we might have said something different does not change

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

On Wed, 11 Dec 2019 at 10:39, Robert Raszuk wrote: > > Dear Fernando, > > Allow me to make something very clear here. > >> And, since we are at it, please let me know if IPv6 is and end to end >> protocol. And, if it is, how does that e2e-ness work with inserting and >> removing EHs on the path to

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

By your books does RFC 2473 or RFC 4798 or 100s of other RFCs which encapsulate IPv6 packets all violate Internet Standard I presume IPv6 spec ? One of us clearly is missing the point. I will let list members judge which one :) Cheers, R. On Wed, Dec 11, 2019 at 12:43 AM Fernando Gont wrote:

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

On 10/12/19 18:39, Robert Raszuk wrote: > Dear Fernando,  > > Allow me to make something very clear here.  > > And, since we are at it, please let me know if IPv6 is and end to end > protocol. And, if it is, how does that e2e-ness work with inserting and > removing EHs on the path to

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

Dear Fernando, Allow me to make something very clear here. And, since we are at it, please let me know if IPv6 is and end to end > protocol. And, if it is, how does that e2e-ness work with inserting and > removing EHs on the path to the ultimate destination of a packet. > The dream of IPv6 flat

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

On 10/12/19 08:16, bruno.decra...@orange.com wrote: > Fernando, > >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont >> Sent: Sunday, December 8, 2019 1:55 AM >> >> On 7/12/19 15:40, Robert Raszuk wrote: >>> Hi Fernando, >>> >>> >>> The online possible instantiation

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

Bruno, On 10/12/19 13:18, bruno.decra...@orange.com wrote: > Fernando, > > Thank you for spelling out your comment, plus on the WGLC thread. > More in-line > >> Bruno, >> >> On 5/12/19 12:15, bruno.decra...@orange.com wrote: >> []> >>> This email starts a two weeks Working Group Last Call on

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

> Other EH’s allow for different forms of modification, for example SRH allows for TLV modification, see Section 2.1. Section 2.1 talks about segment endpoint and that is where IPv6 outer header destination address matches the node address doing the modification. If you stating that it can be modi

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Robert, > On Dec 10, 2019, at 12:42 PM, Robert Raszuk wrote: > > > The issue is that RFC8200 forbids even modification to any EH unless the node > is a destination node in top most IPv6 header. I don’t think that is true. The options in the Hop-by-Hop Options header and the Destination Opt

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

> and not updating its source address. Honestly speaking to me personally this is not a strict requirement to accomplish the necessary functionality discussed. Well I take it as a joke ... >> > > > It's as serious as performing major updates on a packet and not updating > its source address. >

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

On Wed, 11 Dec 2019, 08:08 Robert Raszuk, wrote: > > Well I take it as a joke ... > It's as serious as performing major updates on a packet and not updating its source address. as I am sure you are aware that SRH already contains those verbatim. > > PS. > > Note that SRm6 would require a loca

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Well I take it as a joke ... as I am sure you are aware that SRH already contains those verbatim. PS. Note that SRm6 would require a local mapping database to decipher those in CRH. On Tue, Dec 10, 2019 at 10:02 PM Mark Smith wrote: > Perhaps we need to update RFC8200 and eliminate the source

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Perhaps we need to update RFC8200 and eliminate the source address field, or at least update it so that it can hold a multicast address, indicating the packet has multiple source devices. On Wed, 11 Dec 2019, 07:54 Erik Kline, wrote: > Ah right. > > Still, in terms of the things that could be re

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Ah right. Still, in terms of the things that could be relaxed in 8200, allowing the SRH to be treated more like a Hop-by-Hop header might be more palatable than things that change the effective MTU. On Tue, Dec 10, 2019 at 12:42 PM Robert Raszuk wrote: > > The issue is that RFC8200 forbids even

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

The issue is that RFC8200 forbids even modification to any EH unless the node is a destination node in top most IPv6 header. If there were no resolution to the insertion question vis a vis RFC 8200, > then would it then suffice to recommend that ingress nodes should include > some padding for the

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

On Tue, Dec 10, 2019 at 12:18 PM Robert Raszuk wrote: > Hi Erik, > > What you are proposing IMHO is not needed. > > Each SR node (Segment Endpoint) is effectively applying new IPv6 encap so > is already doing an insertion of new SRH while maintaining src address and > previous SRH content (modul

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Hi Erik, What you are proposing IMHO is not needed. Each SR node (Segment Endpoint) is effectively applying new IPv6 encap so is already doing an insertion of new SRH while maintaining src address and previous SRH content (modulo updating it). That is legally permitted operation based on IPv6 tu

[spring] SRH scratch space (was Re: Question about SRv6 Insert function)

My apologies for raising something that might have already been discussed a rejected, but I'm finding it non-trivial to track this wide-ranging discussion across multiple mailing lists. Regardless of how SRv6 works now (using header insertion, as Darren said in Singapore), I'm wondering if it woul

Re: [spring] Question about SRv6 Insert function

Brian, > Situation has changed since this email: the network programming draft has > now removed text related to SRH insertion. > > Please comment on the text if you see text related to SRH insertion. > > For example: > > https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#se

Re: [spring] Question about SRv6 Insert function

Bruno, On 11-Dec-19 06:17, bruno.decra...@orange.com wrote: > Fernando, > >> From: Fernando Gont [mailto:ferna...@gont.com.ar] >> Sent: Monday, December 9, 2019 9:54 PM >> >> On 5/9/19 09:46, bruno.decra...@orange.com wrote: >> [] Since there have been plenty of attempts to do EH i

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

Fernando, Thank you for spelling out your comment, plus on the WGLC thread. More in-line > Bruno, > > On 5/12/19 12:15, bruno.decra...@orange.com wrote: > []> > > This email starts a two weeks Working Group Last Call on > > draft-ietf-spring-srv6-network-programming [1]. > > > > > > > >

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

On 10/12/19 08:16, bruno.decra...@orange.com wrote: > Fernando, > >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando >> Gont Sent: Sunday, December 8, 2019 1:55 AM >> >> On 7/12/19 15:40, Robert Raszuk wrote: >>> Hi Fernando, >>> >>> >>> The online possible instantiation of

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

Hi Pablo, authors "4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps" is clear that an IPv6 encapsulation is performed. e.g with the below text " S14. Push a new IPv6 header with its own SRH containing B" However, I find that "4.14. End.B6.Encaps.Red: [...] with reduced SRH" is

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

[-6man as I believe this is spring specific] Hi Pablo, authors, < The T.Encaps behavior would describe the capability of node N to perform a T.Encaps behavior, specifically it would describe how many SIDs could be inserted by N without significant performance degradation." Could you p

Re: [spring] Question about SRv6 Insert function

Fernando, > From: Fernando Gont [mailto:ferna...@gont.com.ar] > Sent: Monday, December 9, 2019 9:54 PM > > On 5/9/19 09:46, bruno.decra...@orange.com wrote: > [] > >> > >> Since there have been plenty of attempts to do EH insertion or > >> leave the IPv6 standard ambiguous in this respect,

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

Fernando, > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont > Sent: Sunday, December 8, 2019 1:55 AM > > On 7/12/19 15:40, Robert Raszuk wrote: > > Hi Fernando, > > > > > > The online possible instantiation of "Destination Address" as in RFC8200 > > is the fina

[spring] A question regarding Section 3.2 of RFC 8402

Hi all, My colleagues and I have a question pertaining to Section 3.2 of RFC 8402

Re: [spring] SPRING SRv6 Deployment Status draft

Hi Satoru, Zafar, I would like to provide an update to SRv6 deployment in Iliad's nationwide network in Italy. As of the end of 2019, the SRv6 network consists of: - 1000 Cisco NCS 5500 routers - 1800 Iliad's Nodeboxes - The network services 4.5 million mobile subscribers (as of Q3 2019) - The n