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] 6MAN WGLC: draft-ietf-6man-sids

t; > -éric > > > > *From: *ipv6 on behalf of Joel Halpern < > j...@joelhalpern.com> > *Date: *Sunday, 9 October 2022 at 16:38 > *To: *Robert Raszuk > *Cc: *6man , SPRING WG List > *Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids > > > >

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

Thanks, some additional clarification on my remarks below /Eduard > 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 >

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

I note that section 5.1 of RFC 8754 says "Any packet entering the SR domain and destined to a SID within the SR domain is dropped." Which means that your distributed limited domain without using tunnels either will not work or violates RFC 8754. Yours, Joel On 10/11/2022 1:08 AM, Dirk Steinb

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

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) cheers, Eduard Introduction "In SRv6, SR source nodes initiate packets with a segment identifier in the Destination Address of the IPv6

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

Brian, On Mon, Oct 10, 2022 at 10:53 PM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > Dirk, > > I'm not picking on your message particularly, because the comment below > could be made on many of the messages on this thread: > > On 11-Oct-22 04:51, Dirk Steinberg wrote: > > Well, an IP

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

Dirk, I'm not picking on your message particularly, because the comment below could be made on many of the messages on this thread: On 11-Oct-22 04:51, Dirk Steinberg wrote: Well, an IPv6 packet with an SRH first of all is a legal IPv6 packet. Dropping of IP packets which are not malformed by

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

Hi Joel, Great so this closes this little exchange. And just to clarify my comments were triggered by your statements not the actual text in the subject draft. The text in the draft as it is now looks fine to me. Best, R. On Mon, Oct 10, 2022 at 6:17 PM Joel Halpern wrote: > What I asked for,

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

What I asked for, and I believe Suresh plans for, is to note that not using the reserved block complicates the filtering for ingress and egress.   I do not expect this document to discuss what other methods of filtering could be applied. Yours, Joel On 10/10/2022 11:40 AM, Robert Raszuk wrot

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

Well, an IPv6 packet with an SRH first of all is a legal IPv6 packet. Dropping of IP packets which are not malformed by transit domains based on arbitrary local policies is a very bad thing IMHO. If many operators adopt such practices based on their very own local policies we will end up with a n

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

> that domains using SRH filter it at ingress and egress edges. *it* is a key here. If document says (as I presume Suresh explained) that such ingress filtering will be based on destination address of the packets being the new SRv6 prefix or any other infra address of the AS - all is legal and gr

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

There appear to be two separate issues, only one of which affects this document. The issue that affects this document is that the SRH document explicitly requires that domains using SRH filter it at ingress and egress edges.  That is what is relevant for the document at hand.  And while some f

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

Well, I'd agree it is contrary to several RFCs, but illegal is way too strong of a word and implies somehow that RFCs gained the force of law that I'm not aware they have. Furthermore, declaring the dropping of packets as evil is additional unnecessary hyperbole. Finally, if we are going to go af

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

David, No, that is not what I am saying. I am saying that the concept of limited domains is very loosely defined in rfc8799 and using it as a base to drop packets which contain SRH is not right. For example are my enterprise sites interconnected with SD-WAN a limited domain - surely is for me eve

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

If you are saying the concept of Limited Domains does not apply to SRH since it isn't an IETF consensus document, then I believe that calls the consensus for SRH into serious question. Furthermore, if the SRH consensus is questionable, the idea that operators might filter it shouldn't be surprising

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

Joel, > On 10 Oct 2022, at 15:36, Joel Halpern wrote: > > Eric, you seem to be objecting to something I did not say. I have not asked, > and do not expect, for the document to mandate or even suggest that arbitrary > domains should drop packets with SRH. I will note that given that SRH is >

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

Joel, Am I wrong understanding that definition of "limited domain" was never approved by any formal IETF process ? If so do you really think we should be bounded on something which has been defined outside of IETF ? Cheers, Robert On Mon, Oct 10, 2022 at 4:03 PM Joel Halpern wrote: > SRH was

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

SRH was explicitly defined for use in limited domains.   That is why I think dropping it is acceptable.  Certainly not required, but permitted.  The closest equivalent is NSH, which is also defined for limited domains.  In my personal opinion (not speaking for the SFC working group) I think it

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

> it seems acceptable to block all packets with SRH And such statements you are making are exactly my point. Just curious - Is there any other extension header type subject to being a good enough reason to drop packets at any transit node in IPv6 ? Thx, R. On Mon, Oct 10, 2022 at 3:53 PM Joel

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

ated to Suresh's I-D. Regards -éric *From: *Joel Halpern *Date: *Monday, 10 October 2022 at 15:36 *To: *Eric Vyncke , Robert Raszuk *Cc: *6man , SPRING WG List *Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids Eric, you seem to be objecting to some

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

course, this email and the previous one are written without any hat > and are not related to Suresh's I-D. > > > > Regards > > > > -éric > > > > > > *From: *Joel Halpern > *Date: *Monday, 10 October 2022 at 15:36 > *To: *Eric Vyncke ,

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

h's I-D. Regards -éric *From: *Joel Halpern *Date: *Monday, 10 October 2022 at 15:36 *To: *Eric Vyncke , Robert Raszuk *Cc: *6man , SPRING WG List *Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids Eric, you seem to be objecting to something I did not say.  I have not asked, and d

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

sh's I-D. Regards -éric From: Joel Halpern Date: Monday, 10 October 2022 at 15:36 To: Eric Vyncke , Robert Raszuk Cc: 6man , SPRING WG List Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids Eric, you seem to be objecting to something I did not say. I have not asked, and do n

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

: *ipv6 on behalf of Joel Halpern *Date: *Sunday, 9 October 2022 at 16:38 *To: *Robert Raszuk *Cc: *6man , SPRING WG List *Subject: *Re: [spring] 6MAN WGLC: draft-ietf-6man-sids We require, per the RFC, blocking SRH outside of the limited domain for many reasons. One example is that it turns

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

provider own SID -- both being layer-3 filters BTW). -éric From: ipv6 on behalf of Joel Halpern Date: Sunday, 9 October 2022 at 16:38 To: Robert Raszuk Cc: 6man , SPRING WG List Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids We require, per the RFC, blocking SRH outside of the limited

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

On 10-Oct-22 11:49, Robert Raszuk wrote: Hi Brian, Easily avoided by another layer of encapsulation, surely? Personally I would want to do that, and to use an encrypted encapsulation, to make sure that the SR domain is not penetrated. I am not even sure what you call SR domain ... In the

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

Hi Brian, Easily avoided by another layer of encapsulation, surely? Personally I > would want to do that, and to use an encrypted encapsulation, to make sure > that the SR domain is not penetrated. > I am not even sure what you call SR domain ... In the old days, slides showed the domain as a lit

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

On 10-Oct-22 05:15, Robert Raszuk wrote: Hi Suresh, > One thing that is for certain is that this draft (draft-ietf-6man-sids) does not specify any > restrictions or provide any recommendations on filtering if this allocated prefix is not used OK many thx for this clarification I was not cle

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

Hi Suresh, > One thing that is for certain is that this draft (draft-ietf-6man-sids) does not specify any > restrictions or provide any recommendations on filtering if this allocated prefix is not used OK many thx for this clarification I was not clear on this hence comments made. In general I wo

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

Joel, > You can't tell a packet validly from another piece of your domain from a packet being > sourced by an attacker and spoofing its source address. Please rest assured that it is way easier to filter unplanned actions carried in SRH inserted by an attacker than to protect all end systems from

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

It is accurate that transits that do not use SRH do not need to worry about SRH.  And arguably, even those that do use SRH do not need to worry about SIDs not in their usage ranges.  Getting that right is non-trivial, but... The point in this particular case is that connecting pieces of your

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

Joel, > it turns SRH into a powerful attack vector Really ? How is this possible if IPv6 destination address of the packet does not belong to the block of locally allocated range used as ASN's infra subnet ? I am talking about a pure IPv6 transit case. Isn't this the case that SRH should be exa

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

We require, per the RFC, blocking SRH outside of the limited domain for many reasons. One example is that it turns SRH into a powerful attack vector, given that source address spoofing means there is little way to tell whether an unencapsulated packet actually came from another piece of the sa

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

Hi Brian, Completely agree. One thing is not to guarantee anything in respect to forwarding IPv6 packets with SRH (or any other extension header) and the other thing is to on purpose recommending killing it at interdomain boundary as some sort of evil. Cheers, R. On Sat, Oct 8, 2022 at 9:51 P

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

Robert, If there is any spec which mandates that someone will drop my IPv6 packets only because they contain SRH in the IPv6 header I consider this an evil and unjustified action. The Internet is more or less opaque to most extension headers, especially to recently defined ones, so I don't ho

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

Joel, If anyone would be really serious about keeping SRv6 closed new ethertype should have been allocated to it. But since it reuses IPv6 one filtering packets based on the presence of specific extension headers type is not something we should be endorsing. Just imagine the security aspect when

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

Robert, whether you "buy into limited domain" or not, it is in the RFC and was part of what the IESG considered when they approved it.  As such, unless you believe you can change the community consensus our specifications need to conform to that. Yours, Joel On 10/8/2022 2:52 PM, Robert Rasz

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

Hi Joel, I was hoping this is apparent so let me restate that I do not buy into "limited domain" business for SRv6. I have N sites connected over v6 Internet. I want to send IPv6 packets between my "distributed globally limited domain" without yet one more encap. If there is any spec which manda

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

Robert, I am having trouble understanding your email. 1) A Domain would only filter the allocated SIDs plus what it chooses to use for SRv6. 2) Whatever it a domain filters should be irrelevant to any other domain, since by definition SRv6 is for use only within a limited domain.  So as far

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

: spring [mailto:spring-boun...@ietf.org] On Behalf Of Nick Buraglio Sent: Saturday, October 8, 2022 12:41 AM To: Dale W. Carder Cc: SPRING WG List ; 6man ; Suresh Krishnan Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids On Fri, Oct 7, 2022 at 9:49 AM Dale W. Carder mailto:dwcar...@es.net

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

Hi Suresh, NEW: > In case the deployments do not use this allocated prefix additional care > needs to be exercised at network ingress and egress points so that SRv6 > packets do not leak out of SR domains and they do not accidentally enter SR > unaware domains. > IMO this is too broad. I would sa

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

scribed in Section 5. Is this just for security control at the border of the domain to avoid the leakage of SRv6 information? Best regards Chongfeng xie...@chinatelecom.cn From: Suresh Krishnan Date: 2022-10-03 10:34 To: Joel Halpern CC: Fred Baker; Chongfeng Xie; IPv6 List; spring Sub

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

Thanks Suresh and Joel, the text looks good! Thanks for taking the comment into consideration! Dhruv On Sat, Oct 8, 2022 at 6:46 AM Suresh Krishnan wrote: > 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. >

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

Thanks.  Good enough for me. On 10/7/2022 9:16 PM, Suresh Krishnan wrote: 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, pr

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

Hi Jingrong, Thanks for getting back on my suggestions. Please find responses inline. > On Oct 7, 2022, at 12:04 AM, Xiejingrong (Jingrong) > wrote: > > Hi Suresh, > Sorry for the late reply due to a long holiday. Please see inline below > marked with [XJR]. No worries. Hope you had some

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

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 attacker) entering the SRv6 Domain.) Yours, Joel On 10/7/2022 9:04

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

On Fri, Oct 7, 2022 at 9:49 AM Dale W. Carder wrote: > Thus spake Nick Buraglio (burag...@es.net) on Fri, Oct 07, 2022 at > 06:20:12AM -0500: > > 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 > > > blo

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

Thus spake Nick Buraglio (burag...@es.net) on Fri, Oct 07, 2022 at 06:20:12AM -0500: > 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 blocks for

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

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 blocks for > the SRv6 SIDs then they need to be extra careful about configuring their > edge filters to

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

Hi Suresh, Sorry for the late reply due to a long holiday. Please see inline below marked with [XJR]. 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 ; 6m

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

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 need to be extra careful about configuring their edge filters to prevent leaks inwards or outwards? Yours, Joel On 10/6/

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 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 packet? > > Dhruv: Any thoughts on this? > - This text "This would be useful in iden

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

Does it make sense to develop prefix randomization inside this new SRv6 block? (like for fd/8) Or else it may happen the same as for fc/8 – it is not used because no one organization has been found to accept the registry duties. Ed/ From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Nick Bura

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

nb On Thu, Sep 29, 2022 at 11:16 AM Gyan Mishra wrote: > Brian > > On Thu, Sep 29, 2022 at 5:50 AM Brian Carpenter < > brian.e.carpen...@gmail.com> wrote: > >> No Gyan, fc00::/7 is not available for carving. fc00::/8 is on reserve >> for the dreamt-of centrally registered ULA prefixes, and

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

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. - Do we need to add some text on what happens if the address block assigned by IANA is not used in the received IPv6 packet? - This text "T

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

Hi Suresh, On Mon, 3 Oct 2022 at 13:42, Suresh Krishnan wrote: > > 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 fo

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

<mailto:i...@ietf.org>; spring <mailto:spring@ietf.org> *CC:* 6man Chairs <mailto:6man-cha...@ietf.org>; draft-ietf-6man-sids.authors <mailto:draft-ietf-6man-sids.auth...@ietf.org>; spring-chairs <mailto:spring-cha...@ietf.org> *Subject:* [sprin

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

spring > CC: 6man Chairs; draft-ietf-6man-sids.authors; spring-chairs > Subject: [spring] 6MAN WGLC: draft-ietf-6man-sids > Hello, > > This email starts the 6man Working Group Last Call for the "Segment > Identifiers in SRv6" draft > (https://datatracker.ietf.org/doc

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

C4291].", I‘d like to know where to Signal in the network? Is any new protocol needed to signal? Best regards Chongfeng xie...@chinatelecom.cn From: Jen Linkova Date: 2022-09-17 16:00 To: 6man; spring CC: 6man Chairs; draft-ietf-6man-sids.authors; spring-chairs Subject: [spring] 6MAN WGLC: draft

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

Thanks for Joel's reminder. My comments are below. 1. Document is informational, it may be incorrect. Standard tracks? 2. Avoid reference in Abstract. 3. I-D.filsfilscheng-spring-srv6-srh-compression needs to be updated to I-D.ietf-spring-srv6-srh-compression] 4. Section 3.1. of [RFC8986] desc

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

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 > the dreamt-of centrally registered ULA prefixes, and fd00::/8 is fully > committed. > > If SRV6 is important, it could justify its own prefix. > I think SRv6 must

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

Hi Suresh Responses in-line On Thu, Sep 29, 2022 at 4:12 PM Suresh Krishnan wrote: > 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 c

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 Suresh & authors / all I support publication of the draft as-is. The details I mentioned are covered in other drafts as references so no need to duplicate them in this draft. After reviewing further and feedback from Robert I am on board with /16 block for GUA and no need for ULA. Kind Regar

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

Hi Robert Understood and agreed. I see what you are saying. I was just thinking of ULA with added flexibility in mind. Kind Regards Gyan On Thu, Sep 29, 2022 at 1:01 PM Robert Raszuk wrote: > Gyan, > > SRv6 could use ULA if it would start and stop within "limited domain". > > But concept of S

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

Gyan, SRv6 could use ULA if it would start and stop within "limited domain". But concept of SRv6 is from day one extended to start and end on end systems (user's host, mobile device, sensor etc ...) hence in those deployments is must use GUA. And with that if we are to use GUA in one case we cou

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

Brian On Thu, Sep 29, 2022 at 5:50 AM Brian Carpenter wrote: > No Gyan, fc00::/7 is not available for carving. fc00::/8 is on reserve for > the dreamt-of centrally registered ULA prefixes, and fd00::/8 is fully > committed. > > If SRV6 is important, it could justify its own prefix. > Gyan>

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

Understood. Thanks Gyan On Thu, Sep 29, 2022 at 5:50 AM Brian Carpenter wrote: > No Gyan, fc00::/7 is not available for carving. fc00::/8 is on reserve for > the dreamt-of centrally registered ULA prefixes, and fd00::/8 is fully > committed. > > If SRV6 is important, it could justify its own p

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

Hi working group: I have a few comments/questions on the draft (Marked with ==> in the beginning of a line). Section 1 "SR source nodes initiate packets with a segment identifier in the Destination Address of the IPv6 header". ==>SR source node may be a host originating a packet ... ==>SR sour

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

No Gyan, fc00::/7 is not available for carving. fc00::/8 is on reserve for the dreamt-of centrally registered ULA prefixes, and fd00::/8 is fully committed. If SRV6 is important, it could justify its own prefix. Regards, Brian Carpenter (via tiny screen & keyboard) On Thu, 29 Sep 2022,

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

Gyan Mishra wrote: > Understood. Most operators would like to use ULA for SRV6 > deployments so do we need to carve out block out of ULA space just as > we are doing for GUA to conform with RFC 4291. ULA has is a big enough > block FC00::/7 so we could carve a block out of that.

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

On Wed, Sep 28, 2022 at 11:31 PM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > On 29-Sep-22 16:06, Gyan Mishra wrote: > ... > > > We should qualify the IANA request to make the /16 non internet routable > identical to ULA addressing. > > > > If that is what we desire then why don’t we

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

On 29-Sep-22 16:06, Gyan Mishra wrote: ... We should qualify the IANA request to make the /16 non internet routable identical to ULA addressing. If that is what we desire then why don’t we make it standard BCP to always use ULA for the operators SRV6 domain. I don't believe that a /48 would

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

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 section 4.2 as is not relevant. Section 4 talks about C-SID which is vague as it should be referencing the two different vendor solutions bel

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, Acee. The reason you cite may not be perfect, but your advice is. I shall suppress my urges. 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 new Dest

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

-cha...@ietf.org" Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids Hi Adrian, Thanks for your comments. Greatly appreciate your detailed review. Please find responses inline. On Sep 24, 2022, at 1:13 PM, Adrian Farrel mailto:adr...@olddog.co.uk>> wrote: Hi Jen, all, I've do

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

Thanks for the speedy turn-around, Suresh. Lots of snipping to just a few open points…. 3. "It is also fairly clear" Well, that is illuminating :-) Perhaps you want to make statements about the SID elements and not about the clarity of the referenced documents? Sure :-). Suggest OLD

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

Hi Jen, all, I've done a review of this document as part of working group last call. I found quite a few nits and so on, so I think the document needs some more work before escaping from the working group and being present for publication. Cheers, Adrian == I find it odd that this is an Inf

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] 6MAN WGLC: draft-ietf-6man-sids

Hi Jen, Coauthors, et al, I have read this document and support publication. The document contains useful information and can hopefully be reference to avoid rehashing the relationship between IPv6 Addressing Architecture and SRv6 SIDs. I have two comments. 1. Since this document has an IAN

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

Hi, I think this draft is just about ready. A few comments: shall we specify that it MUST NOT be in the DFZ I think the "DFZ" concept is too vague these days and will distract from the main message. (Also, this is informational, so we can't say MUST NOT.) So it would be good to tighten up the

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

Hello, This email starts the 6man Working Group Last Call for the "Segment Identifiers in SRv6" draft (https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids). The WGLC ends on Tue, Oct 4, 23:59:59 UTC. As the document is closely related to the work in the SPRING WG, we'd like the SPRING WG