Re: [spring] Is srv6 PSP a good idea

There are several aspects of your reply that leave me wondering. First, optional behaviors in a protocol spec have signficiant cost. So if they are nbot needed, we generally prefer not to have options. Second, I am confused by your comments about complexity. From my conversations with

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

On 11/12/19 19:04, Suresh Krishnan wrote: > Hi Fernando, > Answer inline. > >> On Dec 7, 2019, at 9:31 AM, Fernando Gont wrote: >> >> 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 >>>

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

Hi Fernando, Answer inline. > On Dec 7, 2019, at 9:31 AM, Fernando Gont wrote: > > 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

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

Bruno, On 11/12/19 14:48, bruno.decra...@orange.com wrote: [] If you think a document on tunnels rules how IPv6 operates, and its end-to-endianness, then you have a huge problem reading specs. So I will not enter that game, because it would be accepting to be mocked

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

On 11/12/19 13:37, bruno.decra...@orange.com wrote: [] > > Please read this document if you haven't read the most recent version, > and send your comments to the SPRING WG list, no later than December 20. > > > > You may copy the 6MAN WG for IPv6 related comment,

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 11/12/19 03:29, Robert Raszuk wrote: > > RFC 2473   > > Quotes have been already provided to the lists.  > > When encapsulating a packet I can put whatever EH is defined and when > decapsulating the packet I can remove any EH I inserted before. I "own" > the new IPv6 header. Very simple. It

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

Hi Pablo, Very good progress. Thanks for the work. I have snipped down to the conversation points below. The document has gone through a lot of changes in -06 and clearly there is a -07 in the pipe. I'll wait for that before doing a re-read. Best, Adrian [snip] >> Another 'normal' thing to

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

So, I've tried to look at this with fresh eyes, and thanks for the various updates and clarifications. (I'm still not on the SPRING list so please leave me in CC.) I remain a bit puzzled. First, a quote from the SRH specification (draft-ietf-6man-segment-routing-header-26): > 4.2. Transit Node

Re: [spring] SRv6 Network Programming and Link Local Source Addresses

Pablo, I am happy to hear that you would not forward the packet. That is the correct behavior. Could we make that point clear in the draft? Ron Juniper Business Use Only -Original Message- From: Pablo

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 Brian, I think everyone grasps it. I think the problem is that the SRH proponents > use the word "insert" a little ambiguously. In IPv6-land, it's been assumed > to mean "insert an SRH header in the middle of an existing IPv6 packet > header". > Well I got that. In fact I recommend to some

Re: [spring] Is srv6 PSP a good idea

Joel, 1.- The use-case for PSP has already been provided at the mailer. There are scenarios where it provides benefits to operators. 2.- The PSP behavior is optional. It is up to the operator in his deployment to decide whether to enable it or not at one particular router. Similarly, a vendor

Re: [spring] Is srv6 PSP a good idea

Jingrong, > Nothing new, but benefits that people have already said seems notable to me. Agreed. Cheers, Pablo. -Original Message- From: spring on behalf of "Xiejingrong (Jingrong)" Date: Wednesday, 11 December 2019 at 05:15 To: "Joel M. Halpern" , "spring@ietf.org" Subject: Re:

Re: [spring] SRv6 packets carrying multiple instances of the SRH

Bruno, Thank you for the hint. For the current version -06 given the large amount of editorial changes in seemed difficult to send all the changes to the list. For the purpose of this thread: The best option seems to leave RFC8200 speak by itself and remove the sentence. This option got

Re: [spring] SRv6 Network Programming and Link Local Source Addresses

Ron, Ok. Let me try to be open-minded and understand why you have a concern that no-one else is sharing: I guess that your concern is that since we do not have a second FIB lookup, hence you believe that we would just cross-connect the packet. Is this correct? The fact that we set the egress

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

Hi Warren, Brian, Thank you for your comments. Previous versions of this draft contained a more verbose Security section (e.g. https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-03#section-7). However, the content of that section was already covered in the SRH. Hence in the

Re: [spring] Question about SRv6 Insert function

Brian, Draft-ietf-spring-srv6-network-programming does NOT have any text that proposes SRH insertion. The text you are pointing in Section 8.2 uses the word "Insert" in a different context that has nothing to do with SRH insertion. I have replaced the word insert throughout the entire draft to

Re: [spring] What if? [was Re: Extension Header Insertion]

Brian, The new revision of draft-ietf-spring-srv6-network-programming-06 removes that sentence. This new version of the draft has been published today. Draft-ietf-spring-srv6-network-programming does NOT propose to craft a packet with multiple SRHs. Thank you, Pablo. -Original

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

Hi Bruno, Thanks. Agreed and done on the latest revision. (I had also spotted it). Thanks, Pablo. From: "bruno.decra...@orange.com" Date: Wednesday, 11 December 2019 at 10:27 To: draft-ietf-spring-srv6-network-programming Cc: 'SPRING WG List' , Brian E Carpenter Subject: RE: WGLC -

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

Hi Bruno, This paragraph is in the context of BGP-LS advertisement for SRv6 capabilities. The text in there is an example of a potential advertised capability. The detailed definition of how capabilities are advertised belongs to draft-ietf-idr-bgpls-srv6-ext. In my opinion it should be the

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

Removed 6man Hi Bruno, I agree with all your changes and I have applied them to the latest version of the draft (rev06). Many thanks, Pablo. From: "bruno.decra...@orange.com" Date: Tuesday, 10 December 2019 at 18:41 To: draft-ietf-spring-srv6-network-programming Cc: "6...@ietf.org"

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

Hi Bruno, Many thanks for your comments. Please see inline. Thanks, Pablo. From: spring on behalf of "bruno.decra...@orange.com" Date: Thursday, 5 December 2019 at 18:50 To: 'SPRING WG List' , draft-ietf-spring-srv6-network-programming Subject: Re: [spring] WGLC -

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

Rajesh, I have included this as part of the latest revision of the draft (rev06). Thanks, Pablo. From: Rajesh M Date: Monday, 25 November 2019 at 05:16 To: "Pablo Camarillo (pcamaril)" , Parag Kaneriya , SPRING WG List Cc: "cf(mailer list)" Subject: RE:

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

Andrew, No big deal. :-) In reply to your question: I confirm that draft-ietf-spring-srv6-network-programming does not present any restriction to combine the SRH in conjunction with other EHs from other RFCs. Thanks, Pablo. From: Andrew Alston Date: Monday, 9 December 2019 at 18:19 To:

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

Hi all, We have published a new revision of draft-ietf-spring-srv6-network-programming. It addresses the comments received. I will be replying individually on each thread. Many thanks to all of those who have contributed with such comments. Please have a look and let me know any comment. I

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: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Wednesday, December 11, 2019 12:25 AM > > 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,

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

Fernando, > From: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Wednesday, December 11, 2019 12:16 AM > > 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 > > > >>

Re: [spring] Is srv6 PSP a good idea

Thank you Jingrong for providing some of the other motivations. Two furhter comments. As far as I know, the only savings on the end box is the processing for noticing the SRH, noticing that SL is 0 and there are no relevant TLVs, and then moving on. If the actual end device is not part of

Re: [spring] SPRING SRv6 Deployment Status draft

Hi Sebastien, Thank you very much for your updates on Iliad in detail! It shows that one vendor’s SRv6 implementation is interoperable with your in-house SRv6 implementation, and the networks consist of those routers are running very well. I think the draft has this info should be a good

Re: [spring] Question about SRv6 Insert function

Brian, Pablo Please see inline (multiple points) > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Tuesday, December 10, 2019 8:36 PM > To: DECRAENE Bruno TGI/OLN; Fernando Gont > Cc: Ron Bonica; spring@ietf.org; 6...@ietf.org; Suresh Krishnan; >

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

[-6man] Hi Pablo, authors, The draft has a reference to [I-D.filsfils-spring-srv6-net-pgm-insertion]. This reference is unused in the text and be may understood as a hint to SRH insertion which is out of scope of this draft. Could you please remove that reference? Thank you --Bruno From:

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

Hi Brian, > 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. Correct. But we are not discussing draft-voyer here. I think recent mail threads prove that it is much better

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

RFC 2473 Quotes have been already provided to the lists. When encapsulating a packet I can put whatever EH is defined and when decapsulating the packet I can remove any EH I inserted before. I "own" the new IPv6 header. Very simple. It is like taking the cars on a ferry. Your original packet