Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

On Thu, Apr 4, 2024 at 3:54 PM Bob Hinden wrote: > Suresh, > > The prefix allocated in draft-ietf-6man-sids is not required to be used. > For example, from the Abstract: > > This document allocates and makes a dedicated prefix available for > SRv6 SIDs. > > There is not a MUST be used. Yes

Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Hi Adrian, On Thu, Apr 4, 2024 at 3:11 PM Adrian Farrel wrote: > > If any allocation had been made (early or otherwise), I'd see it here > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > and here > https://www.iana.org/assignments/ipv6-unicast-add

Re: [spring] Confirming resolution of issue #2 of draft-ietf-spring-srv6-srh-compression

Hi Joel, I believe that draft-ietf-6man-sids addresses the concerns brought up and this issue should be resolved. Thanks Suresh > On Aug 15, 2023, at 9:30 PM, Joel Halpern wrote: > > As mentioned earlier, we also need to confirm the resolution of issue #2 on > the subject document. > > Thi

Re: [spring] Confimring resolution of issue #3 https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/

Hi Greg, There is a verified Errata on RFC8754 to mention the Segment List since it is not something RFC8200 defines. https://www.rfc-editor.org/errata/eid7102 Thanks Suresh > On Aug 9, 2023, at 2:30 PM, Greg Mirsky wrote: > > Dear Authors and Ch

Re: [spring] Usage of DoH vs SRH TLVs

Hi Joel, Thanks for bringing up this important point for discussion. In my view there are two aspects into how we evaluate this choice: * If the information element is not generically applicable to all IPv6 nodes it should ideally not go into a destination option. The IPv6 option space is pre

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

Hi Eduard, Thanks for your comments. > On Oct 11, 2022, at 3:29 AM, Eduard Metz wrote: > > Apologies for the late review, some comments from my side (maybe some have > been addressed already earlier, I didn't check, the thread was quite lengthy) Haha. Yes it is :-). Most of the things you br

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

Hi Robert, Thanks for your further clarifications on the topic. I think I do understand your concern now based on your discussions with Joel and Brian. If I understand it correctly, the concern exists whether or not someone is using their own allocated address block or if they use the prefix a

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

Hi Joel, > On Oct 7, 2022, at 9:07 PM, Joel Halpern wrote: > > Almost, but not quite. The first part, up to "egress points" is fine. But > the description of the reasons leaves out one case I think is important. > Namely, preventing packets from outside the SR Domain (e.g. from an outside

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

Hi Nick, > On Oct 7, 2022, at 7:20 AM, Nick Buraglio wrote: > > > > On Thu, Oct 6, 2022 at 10:15 PM Joel Halpern > wrote: > I wonder if we could / should add a sentence or two related to the address > block noting that if an operator chooses to use other address

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

ries. Hope you had some time to relax. > Thanks, > Jingrong. > > -Original Message- > From: Suresh Krishnan [mailto:suresh.krish...@gmail.com] > Sent: Friday, September 30, 2022 4:46 AM > To: Xiejingrong (Jingrong) > Cc: Jen Linkova ; 6man ; spring@ietf.org; > 6

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

Hi Joel, Thanks for your comment. Please find response inline > On Oct 6, 2022, at 11:15 PM, Joel Halpern wrote: > > I wonder if we could / should add a sentence or two related to the address > block noting that if an operator chooses to use other address blocks for the > SRv6 SIDs then they

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

Hi Dhruv, > On Oct 5, 2022, at 12:27 AM, Dhruv Dhody wrote: > > Hi Suresh, > > Thanks for taking the comments into consideration. Snip to just two points... > > > >> - Do we need to add some text on what happens if the address block assigned >> by IANA is not used in the received IPv6 pack

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

Hi Ed/Nick/Mark/Michael/Robert/Gyan, I have noted the valuable points you brought up regarding the format, and operational properties of the prefix. They are all extremely relevant to the discussion of the operational guidelines mentioned at the end of section 5. I will try to put these togeth

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

Hi Dhruv, Thanks for your comments. Please find responses inline. > On Oct 4, 2022, at 9:29 AM, Dhruv Dhody wrote: > > Hi Jen, > > I support publication. > > Few comments > - Introduction ends abruptly for my taste. Perhaps a few lines that state the > purpose of the document would help.

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

Hi Mark, Thanks for your comments. Please find responses inline. > On Sep 29, 2022, at 8:58 PM, Mark Smith wrote: > > > > On Thu, 29 Sept 2022 at 19:51, Brian Carpenter > wrote: > No Gyan, fc00::/7 is not available for carving. fc00::/8 is on reserve for

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

Hi Joel, Thanks for clarifying. > On Oct 1, 2022, at 12:20 AM, Joel Halpern wrote: > > Hmmm. I read "signal" in the draft as "indicate". That is, for example, if > there is an address range defined to be reserved for SIDs then that range > appearing in the destination address is the "sig

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

Hi Cheng, Thanks a lot for your comments. Please find responses inline. > On Sep 29, 2022, at 11:49 PM, Chengli wrote: > > Thanks for Joel's reminder. My comments are below. > > 1. Document is informational, it may be incorrect. Standard tracks? This was a point of discussion earlier but sin

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

Hi Jingrong, Thanks for your detailed comments. Please find responses inline. > On Sep 29, 2022, at 5:53 AM, Xiejingrong (Jingrong) > wrote: > > Hi working group: > > I have a few comments/questions on the draft (Marked with ==> in the > beginning of a line). > > Section 1 "SR source node

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

Hi Gyan, Thanks for your comments. Please find responses inline. > On Sep 28, 2022, at 11:06 PM, Gyan Mishra wrote: > > > I support publication of the draft. > > I have reviewed the draft and have some comments. > > As the C-SID draft had been adopted by Spring I don’t see a need for sectio

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

Hi Adrian, Thanks again for the text suggestions. I think we are mostly in agreement regarding the changes. I have snipped out the points where we agree on the text below and brought forward the points that need further discussion >> >> 3. >> >> When an SRv6 SID occurs in the IPv6 destinat

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

Hi Acee, > On Sep 26, 2022, at 10:13 AM, Acee Lindem (acee) wrote: > > Hi Suresh, Adrian, > >> >> --- >> >> 4. >> >> A node >> taking part in this mechanism accomplishes this by using the ARG part >> [RFC8986] of the Destination address field of the IPv6 header to come >> up with a

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

Thanks a lot for your comments Acee. Agree about point 2. and will make a change. Regarding 1. the registry does not require a standards track doc for an allocation. There have been some discussions on the track as well earlier, and this can be changed if the WG feels that it is the right thing to

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

Thanks a lot Brian. Your suggested changes look great. I will incorporate them into the next rev. Regards Suresh On Sat, Sep 17, 2022 at 5:10 PM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > Hi, > > I think this draft is just about ready. A few comments: > > > shall we specify that i

Re: [spring] Proposed policy on reporting implementation and interoperability

Hi Joel, I think it is a great idea to keep track of the implementation and interop status of the Standards Track work that spring produces. My thoughts are very much in line with what Adrian said below in that I would certainly not like this potentially stale, out-of-date and misleading inform

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

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 Addressing Architecture [RFC4291]. Comments are welcome and greatly appreciated. Te

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] 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, On Dec 11, 2019, at 7:22 PM, Fernando Gont mailto:fg...@si6networks.com>> wrote: On 11/12/19 19:04, Suresh Krishnan wrote: Hi Fernando, Answer inline. On Dec 7, 2019, at 9:31 AM, Fernando Gont mailto:fg...@si6networks.com>> wrote: On 7/12/19 04:19, Suresh Kr

[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 >> <mai

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

(responding on spring mailing list) Hi Fernando, On Dec 7, 2019, at 11:07 AM, Fernando Gont mailto:fg...@si6networks.com>> wrote: On 6/12/19 23:47, Brian E Carpenter wrote: Again, comment at the end... On 07-Dec-19 14:37, Fernando Gont wrote: On 6/12/19 22:15, Brian E Carpenter wrote: [...] an

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

(Apologies up front. I am about to get on a 10 hr flight and will be unable to respond for at least that period) Hi all, Picking the last message in the thread to reply to. It looks to me that there are at least two different (but related) issues being discussed here a) Spring SRv6 NP behavio

Re: [spring] Question about SRv6 Insert function

Hi Fernando, > On Sep 3, 2019, at 10:50 PM, Fernando Gont wrote: > > On 4/9/19 05:23, Suresh Krishnan wrote: >> Hi Fernando, >> >>> On Sep 3, 2019, at 7:17 AM, Fernando Gont >>> wrote: >>> >>> Hello, Suresh, >>> >>

Re: [spring] Question about SRv6 Insert function

Hi Fernando, > On Sep 3, 2019, at 7:17 AM, Fernando Gont wrote: > > Hello, Suresh, > > On 2/9/19 19:07, Suresh Krishnan wrote: > [] >>>> So, we should probably explore the motivation for Option 2). If the >>>> motivation is not sufficient,

Re: [spring] Question about SRv6 Insert function

Hi Fernando, > On Aug 31, 2019, at 10:09 AM, Fernando Gont wrote: > > On 30/8/19 20:24, Ron Bonica wrote: >> Li, >> >> >> >> In the scenarios that you mention, below, SRv6 nodes have the following >> options: >> >> >> >> 1. To prepend and IPv6 header, with its own SRH >> 2. To insert an

[spring] Suresh Krishnan's No Objection on draft-ietf-spring-segment-routing-mpls-19: (with COMMENT)

Suresh Krishnan has entered the following ballot position for draft-ietf-spring-segment-routing-mpls-19: 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] Suresh Krishnan's No Objection on charter-ietf-spring-01-01: (with COMMENT)

Thanks Bruno. That works for me. Regards Suresh > On Jul 5, 2018, at 10:09 AM, bruno.decra...@orange.com wrote: > > Suresh, > >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Suresh Krishnan >> >> Suresh Krishnan has entered the following ballo

[spring] Suresh Krishnan's No Objection on charter-ietf-spring-01-01: (with COMMENT)

Suresh Krishnan has entered the following ballot position for charter-ietf-spring-01-01: 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.) The document