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 7/12/19 15:40, Robert Raszuk wrote: > Hi Fernando, >   > > The online possible instantiation of "Destination Address" as in RFC8200 > is the final destination of the packet. > > > No. That is incorrect.  > > Hint: Please read carefully RFC2473. If you think a document on tunnels ru

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

On 08-Dec-19 00:47, Robert Raszuk wrote: > Besides the pseudocode says it black and white "S14.1. If (updated SL == 0) As I already pointed out, "updated SL" is undefined in the text and may in fact simply mean "Segments Left" after executing S14. Pseudocode really should be unambiguous.

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

[Hmmm, there were a lot of people in the to/cc fields. I trimmed a bit because (hopefully) some of them are subscribed to the mailing lists.] Brian, I think some of the notion of "popping an SRH" may be associated with the idea of having more than one SRH present. Whether that is a good idea is

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

Ketan, On 07-Dec-19 23:13, Ketan Talaulikar (ketant) wrote: > +1 > >   > > For some strange reason the PSP behaviour is being mixed with EH insertion > and likely there is some misunderstanding here. I found the language in draft-ietf-spring-srv6-network-programming very hard to understand, an

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

Hi Fernando, > The online possible instantiation of "Destination Address" as in RFC8200 > is the final destination of the packet. No. That is incorrect. Hint: Please read carefully RFC2473. Please focus on sections: 3.1, 3.2, 3.3, 5.1 etc ... Kindly read this part of section 3.2 at least few

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

On 7/12/19 12:57, Darren Dukes (ddukes) wrote: > Hi Robert, thank you for injecting clarity to this thread. > > draft-ietf-spring-network-programming defines PSP, and the only relevant > portion of this thread to that draft is Discussion #3. > > As I stated in another post, I consider #3 closed a

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 7/12/19 12:29, Robert Raszuk wrote: > > 2) A related question I have for you: Is IPv6 an end-to-end protocol? > (The answer to this question also serves as an answer for the rest). > > > The moment IPv6 src <--> dst flow makes it legal to be encapsulated you > are dealing with end to

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

On 7/12/19 13:03, Robert Raszuk wrote: > > Exactly - That is why I thought  it does make sense to make this crystal > clear to everyone here.  > > From some comments it seemed that either folks do not understand or want > on purpose to make false assertions only to mud the waters :) FWIW, I wil

Re: [spring] Network Programming - Penultimate Segment Popping

Tom, > If intermediate hosts in the routing list are able to add or remove SRH per RFC8200 "Routing list" contained in SRH does not matter at all here in terms of compliance with RFC8200. At each segment midpoint the outer IPv6 destination is *rewritten*. For illustrative purposes you may visual

Re: [spring] Network Programming - Penultimate Segment Popping

On Sat, Dec 7, 2019 at 7:10 AM Darren Dukes (ddukes) wrote: > > Ron, you say > >> RFC 8200 addresses extension header insertion and deletion identically, > >> in the same sentence. > > This sentence you refer to clearly permits PSP as defined in network > programming: >Extension headers (ex

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

Exactly - That is why I thought it does make sense to make this crystal clear to everyone here. >From some comments it seemed that either folks do not understand or want on purpose to make false assertions only to mud the waters :) All - have a great weekend, Robert. On Sat, Dec 7, 2019 at 4:

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

Hi Robert, thank you for injecting clarity to this thread. draft-ietf-spring-network-programming defines PSP, and the only relevant portion of this thread to that draft is Discussion #3. As I stated in another post, I consider #3 closed as this is clearly complying with RFC8200. https://mailarc

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

> 2) A related question I have for you: Is IPv6 an end-to-end protocol? > (The answer to this question also serves as an answer for the rest). The moment IPv6 src <--> dst flow makes it legal to be encapsulated you are dealing with end to end inner IPv6 and end to end outer IPv6. You keep drawin

Re: [spring] Network Programming - Penultimate Segment Popping

On 7/12/19 12:10, Darren Dukes (ddukes) wrote: > Ron, you say >>>  RFC 8200 addresses extension header insertion and deletion > identically, in the same sentence. > > This sentence you refer to clearly permits PSP as defined in network > programming: >    Extension headers (except for the Hop-by-H

Re: [spring] Network Programming - Penultimate Segment Popping

Ron, you say >> RFC 8200 addresses extension header insertion and deletion identically, in >> the same sentence. This sentence you refer to clearly permits PSP as defined in network programming: Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or d

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 7/12/19 04:19, Suresh Krishnan wrote: > (responding on spring mailing list) > > Hi Fernando, > >> On Dec 7, 2019, at 11:07 AM, Fernando Gont > > wrote: >> >> On 6/12/19 23:47, Brian E Carpenter wrote: >>> Again, comment at the end... >>> On 07-Dec-19 14:37, Fernan

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 7/12/19 07:13, Ketan Talaulikar (ketant) wrote: > +1 > >   > > For some strange reason the PSP behaviour is being mixed with EH > insertion and likely there is some misunderstanding here. You mean we're mixing EH insertion with EH removal? -- Fernando Gont SI6 Networks e-mail: fg...@si6netw

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 7/12/19 04:19, Suresh Krishnan wrote: > (responding on spring mailing list) > > Hi Fernando, > >> On Dec 7, 2019, at 11:07 AM, Fernando Gont > > wrote: >> >> On 6/12/19 23:47, Brian E Carpenter wrote: >>> Again, comment at the end... >>> On 07-Dec-19 14:37, Fernan

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

Le 06/12/2019 à 17:21, Sander Steffann a écrit : Hi Robert, To your specific first question this is very popular deployment model ... just look at SDWANs. So Internet is just a L3 transport for all routers in your administrative domain or global WAN. Spot on. I do sincerely hope that whate

[spring] PHP - Deep Listening (was: RE: Separating issues)

Suresh, Fair enough. Let's review PHP, with open minds, and see if the motivation merits the proposed behavior Assume that an SRv6 node receives the following packet: * IPv6 header. Destination Address == LOCATOR:0x0002 (0x0002 indicates that this is and end with PSP) * IPv6 heade

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

Hey Fernando, (pop when you are the destination but SL!=0 is essentially 'in the > network removal') I was trying to stay out of this but I have one fundamental question or observation this entire debate seems to be about. In the context of SRv6 there are two parallel discussions *Discussion #

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

+1 For some strange reason the PSP behaviour is being mixed with EH insertion and likely there is some misunderstanding here. Fernando says: (pop when you are the destination but SL!=0 is essentially 'in the network removal’) This is NOT what PSP is (refer https://tools.ietf.org/html/draft-ie

Re: [spring] Separating issues (was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

+ 1 and I will also clarify, what I see as, a misunderstanding (or perhaps a misrepresentation) of the PSP behaviour on the other thread that Suresh has started. From: ipv6 On Behalf Of Suresh Krishnan Sent: 07 December 2019 12:44 To: 6man <6...@ietf.org>; SPRING WG Cc: Ron Bonica ; int-...@i