Re: [spring] Erik Kline's Discuss on draft-ietf-spring-sr-replication-segment-15: (with DISCUSS and COMMENT)

Rishabh, Thanks for the update. Some thoughts on draft-16: ### S2.2.1 S01. If (Upper-Layer header type == 4(IPv4) OR Upper-Layer header type == 4(IPv6) ) { seems suspicious. I think the second "4" should probably be "41"? ### S5 ULAs are not "non-routable"; they're "non

[spring] Erik Kline's Discuss on draft-ietf-spring-sr-replication-segment-15: (with DISCUSS and COMMENT)

Erik Kline has entered the following ballot position for draft-ietf-spring-sr-replication-segment-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [spring] Erik Kline's No Objection on draft-ietf-spring-nsh-sr-12: (with COMMENT)

On Wed, Apr 26, 2023 at 3:23 PM Joel Halpern wrote: > Responding to the first comment in line as s document contributor, trimmed. > > Yours, > > Joel > > On 4/26/2023 4:15 PM, Erik Kline via Datatracker wrote: > > Erik Kline has entered the following ballot position fo

[spring] Erik Kline's No Objection on draft-ietf-spring-nsh-sr-12: (with COMMENT)

Erik Kline has entered the following ballot position for draft-ietf-spring-nsh-sr-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [spring] FW: I-D Action: draft-yang-spring-sid-as-source-address-00.txt

SPRING chairs, If consensus emerges to move this work forward in the working group please do notify 6MAN, its chairs and ADs. 6MAN will likely want to assess SIDs as source addresses (and may even want to comment explicitly in draft-ietf-6man-sids

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

> > With regard to RFC4291 I assume the main observation is that the SRv6 SID > structure does not match with the structure of RFC4291, in particular the > interface ID part. A small discussion on the other aspects of RFC4291 could > be added to further clarify this (as done for the subnet-router a

Re: [spring] Requesting comments on draft-krishnan-6man-sids-00.txt

Thanks Suresh! On Thu, Feb 10, 2022 at 20:36 Suresh Krishnan wrote: > Hi all, > As discussed during the IETF112 6man working group meeting I have > written a short draft that describes the characteristics of SRv6 SIDs and > attempts to clarify the relationship of SRv6 SIDs to the IPv6 Addressi

[spring] Erik Kline's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT)

Erik Kline has entered the following ballot position for draft-ietf-spring-segment-routing-policy-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

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

Joel, One thing that could have been more clear (of many such things, no doubt)... On Mon, Oct 25, 2021 at 3:39 PM Erik Kline wrote: > [replying on this thread as is has more folks cc'd] > --- > > Next steps for consideration: > > [A] A separate 6MAN document to clar

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

[replying on this thread as is has more folks cc'd] Joel, First: thank you to everyone who has commented, clarified, sat for meetings, and reviewed and edited text, often repeatedly. It is very much appreciated. This reply is on behalf of the 6MAN chairs and INT ADs. -- Erik, Éric, Bob, Ole [

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

Joel, I'm afraid we failed to meet this deadline, my apologies. But we should have an answer for you in the first part of next week. Thank you (and everyone) for your continued patience, -Erik, Eric, Bob, and Ole On Thu, Oct 14, 2021 at 1:04 PM Erik Kline wrote: > Joel, > >

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

Joel, Thank you for your email. The ADs and chairs have been discussing. One thing that would be very helpful to our discussions would be some worked examples of the various C-SID behaviors, showing some SRv6 datagrams and what happens to their contents as they move across some suitable example

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

ress and forward the packet on, until it reaches the last node. The last node won't be able to originate a packet with the correct source address though, I think. Am I missing something? Probably... On Sat, Oct 9, 2021 at 7:03 PM Erik Kline wrote: > > > To address the self-rewrit

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

To address the self-rewriting Destination Address complexity, and some related objections, might it be possible to add a mutable TLV, requiring the presence of an SRH (no SRH-less packets)? The mutable TLV would contain any extra state necessary to continue decompression of the current segment i

Re: [spring] I-D Action: draft-ietf-spring-sr-service-programming-05.txt

Ummm...Is section 6.4.2 attempting to describe some support for IPv6 NAT? On Fri, Sep 10, 2021 at 10:23 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Source Packet Routing in Networking WG of > the IETF. > >

[spring] note: [DMM] WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Spring folk, Per request from spring chairs, I wanted to drop a note that a document discussing using SRv6 in a 3GPP carrier network is in dmm WGLC. If this is of interest to you, please feel free to read and review (please direct comments to dmm@). Thanks, -Erik On Wed, Apr 7, 2021 at 10:35 A

[spring] Erik Kline's No Objection on draft-ietf-spring-sr-yang-29: (with COMMENT)

Erik Kline has entered the following ballot position for draft-ietf-spring-sr-yang-29: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

[spring] Erik Kline's No Objection on draft-ietf-spring-srv6-network-programming-24: (with COMMENT)

Erik Kline has entered the following ballot position for draft-ietf-spring-srv6-network-programming-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

[spring] Erik Kline's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

Erik Kline has entered the following ballot position for draft-ietf-spring-srv6-network-programming-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

> > (5) This point is for the IESG to discuss. > > §4.16.1.2: > > The End, End.X and End.T behaviors with PSP do not contravene > Section 4 of [RFC8200] because the destination address of the > incoming packet is the address of the node executing the behavior. > > The spring WG's

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

There are actual, meaningful differences to be contemplated; folks with no operational MPLS in there networks might not want to be forced to start. On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali) wrote: > > Fred, > > > > Is there any IETF requirement document for OMNI and AERO (I am sorry I am

Re: [spring] SRv6 Network Programming - ICMP Source Address Selection

Seems like you're saying that if the SID is not an anycast SID it is as though it were unicast and therefore 4443/2.2/a applies, i.e. the SID is the source address for the ICMP error message. If the SID is an anycast SID, then the router must follow 4443/2.2/b and chose another unicast address ass

Re: [spring] 64-bit locators

On Sun, Dec 29, 2019 at 9:49 AM Ron Bonica wrote: > Robert, > > > > We may be converging! > > > > In another email thread, you and I agreed that a SID should be drawn from > global unicast address space or ULA space, but not from any other special > address space (e.g., link-local, multicast). It

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)

ts to play with (iff. the network has such midpoints), and otherwise abide by RFC 8200? Thx > R. > > > > > > > On Tue, Dec 10, 2019 at 9:10 PM Erik Kline wrote: > >> My apologies for raising something that might have already been discussed >> a rejected, but

[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