Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Hi Brian, I agree with your statement re operational practices. Indeed this was mentioned on SPRING in the past, and at that time a couple RFC examples were given RFC6059, RFC7599. I'm sure there are others. Andrew, are you providing any new technical information? Darren On Mar 11, 2020, at 5:3

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Correct Brian, no SLAAC. Darren > On Mar 11, 2020, at 10:34 PM, Brian E Carpenter > wrote: > > On 12-Mar-20 10:44, Fernando Gont wrote: >> On 11/3/20 18:30, Brian E Carpenter wrote: >> [] >>> >>> However, I can't find anything in RFC 4291 that forbids addresses >>> having semantic meaning

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

On 12-Mar-20 10:44, Fernando Gont wrote: > On 11/3/20 18:30, Brian E Carpenter wrote: > [] >> >> However, I can't find anything in RFC 4291 that forbids addresses >> having semantic meanings rather than being pure locators. It goes >> against one of my design prejudices, but I can't find anythi

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Brian, > On Mar 11, 2020, at 2:30 PM, Brian E Carpenter > wrote: > > On 12-Mar-20 09:53, Andrew Alston wrote: >> Hi Spring WG >> >> >> >> On the basis of the below – I must conclude that the issues relating the >> SID/IPv6 semantics have indeed not been dealt with by the spring working >>

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

On 11/3/20 18:30, Brian E Carpenter wrote: [] However, I can't find anything in RFC 4291 that forbids addresses having semantic meanings rather than being pure locators. It goes against one of my design prejudices, but I can't find anything resembling "Encoding semantics in address bits cons

Re: [spring] Dispute process (Was: Resignation request)

On 11 Mar 2020, at 15:57, Nico Williams wrote: >> I would refer you to RFC 7776. I don't think this would be in the >> ombudsteam's purview. (Not trying to get out of work, really!) > > I was suggesting updating that, not acting as though we already have :) Uh...I think we have enough on our plat

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

On 12-Mar-20 09:53, Andrew Alston wrote: > Hi Spring WG > >   > > On the basis of the below – I must conclude that the issues relating the > SID/IPv6 semantics have indeed not been dealt with by the spring working > group in the context of the network programming draft – and I would now like >

Re: [spring] Dispute process (Was: Resignation request)

On Wed, Mar 11, 2020 at 01:26:35PM -0500, Pete Resnick wrote: > On 10 Mar 2020, at 18:34, Nico Williams wrote: > > (A cynic might wonder if that choice was not purposeful, precisely to > > allow the original work to continue unimpeded [perhaps] on the ISE track > > with an appeal mooted. I do not

[spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Hi Spring WG On the basis of the below – I must conclude that the issues relating the SID/IPv6 semantics have indeed not been dealt with by the spring working group in the context of the network programming draft – and I would now like to raise those issues in the context of that draft – and th

Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

> On Mar 11, 2020, at 2:44 PM, Pablo Camarillo (pcamaril) > wrote: > > Hi Chris, > > Indeed, an IPv6 packet with no SRH (and FIB entry is local End SID) is one > way to get to the Upper Layer Header processing defined in 4.1.1. > Another way is to have a FIB entry bound to an End.DT* or End.

Re: [spring] Status of draft-ietf-spring-srv6-network-programming?

On 11/3/20 15:32, Joel M. Halpern wrote: Bruno, I can not speak for anyone else.  But I have made clear to the authors (on list) and the AD (off list) that the current revision of the document does not provide what I consider adequate explanation of the consequence of the PSP issues. If progr

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

On 12-Mar-20 05:06, Alexander Vainshtein wrote: > Darren, > > Lots of thanks for the clarification. > >   > > However, I have several issues with your response: > > 1.   The SRH draft is a 6MAN document. I am not sure if the provision for > new documents defining new SID types and their ha

Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Hi Chris, Indeed, an IPv6 packet with no SRH (and FIB entry is local End SID) is one way to get to the Upper Layer Header processing defined in 4.1.1. Another way is to have a FIB entry bound to an End.DT* or End.DX* behavior. In these cases the ULH processing occurs if the SRH has SL=0 or there

Re: [spring] Status of draft-ietf-spring-srv6-network-programming?

On 11/3/20 15:12, bruno.decra...@orange.com wrote: [] The call for comments is closed and I believe people had ample time to review the document and make comments. Shouldn't the datatracker state be updated? Till then, authors have been working on addressing the received comments, and

Re: [spring] Status of draft-ietf-spring-srv6-network-programming?

Bruno, I can not speak for anyone else. But I have made clear to the authors (on list) and the AD (off list) that the current revision of the document does not provide what I consider adequate explanation of the consequence of the PSP issues. If progress is such an important concern, then put

Re: [spring] Dispute process (Was: Resignation request)

On 10 Mar 2020, at 18:34, Nico Williams wrote: On Tue, Mar 10, 2020 at 03:07:53PM -0400, Paul Wouters wrote: On Mar 10, 2020, at 14:45, Nico Williams wrote: What I've encountered is that at the limit you have to appeal or give up, and how well things go before you get to that stage depends on

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

Andrew, > I just went and checked the spring WG site on trac.ietf.org. I found it > rather curious that there is not a *single* ticket on that site – nor is > there any closures listed on that site, despite all the work that has gone in. Some WGs use the ticket tracking system [1] , some don’

Re: [spring] Dispute process (Was: Resignation request)

On 10 Mar 2020, at 17:44, Andrew Alston wrote: Firstly - let me say this - there are several outstanding, unaddressed issues in this draft - and the moment that this formally goes into last call (which it still hasn't left despite the emails from Martin) that appeal will be coming - that is gu

Re: [spring] Status of draft-ietf-spring-srv6-network-programming?

Fernando, > From: Fernando Gont [mailto:ferna...@gont.com.ar] > Sent: Wednesday, March 11, 2020 5:06 AM > > Folks, > > Ping? > > > On 6/3/20 06:25, Fernando Gont wrote: > > Marting & Bruno, > > > > May I ask what's the status of this I-D? - > > > > On one hand, both of you declared consens

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Darren, Lots of thanks for the clarification. However, I have several issues with your response: 1. The SRH draft is a 6MAN document. I am not sure if the provision for new documents defining new SID types and their handling means that such definitions can be done in the documents handled

Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

> On Mar 11, 2020, at 8:16 AM, Pablo Camarillo (pcamaril) > wrote: > > Hi Chris, > > The processing defined in draft-ietf-spring-srv6-network-programming is > aligned with the SRH. > Particularly see > https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.3 > >>

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Sasha, I think this question got lost in the other emails around this time. Thanks for asking though and, let me clarify. The SRH doc was built with section 4.3.1 stating: "Future documents may define addi

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

Andrew, The threads you initiated describing technical questions on the mailing list have been replied by the authors. You still have not initiated any discussion or clarify your concerns on the topic of “IP Space Burn” on the mailing list. At this point I don’t see any technical discussion poi

Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Pablo, Christian and all, I respectfully disagree with the statement " The processing defined in draft-ietf-spring-srv6-network-programming is aligned with the SRH". Specifically, from my POV the SRH draft does not define

Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Hi Chris, The processing defined in draft-ietf-spring-srv6-network-programming is aligned with the SRH. Particularly see https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.3 > Is 4.1.1 covering (and only covering) the case where my FIB lookup yields a > local End

Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

> On Mar 11, 2020, at 5:59 AM, Pablo Camarillo (pcamaril) > wrote: > > Hi Chris, > > They are the same thing. Ok, so how do I get on 2 different processing paths for the same thing entry as Section 4.1 cannot lead to processing of an upper-layer header as far as I can tell, yet section 4.

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

First I fail to see in the recording where such promise happened. I asked you for the precise timing but you did not send it. It seems to me that you are putting words in someone else’s mouth, because the presenter asked you politely to send your comment to the mailer and you didn’t. Then you ar

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

Andrew, Inline with PC3. Regards, Pablo. From: Andrew Alston Date: Wednesday, 11 March 2020 at 08:48 To: "Pablo Camarillo (pcamaril)" Cc: 6man WG , "spring@ietf.org" Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming Pablo PC2: The comment started because in the draft w

Re: [spring] Question on draft-ietf-spring-srv6-network-programming-12

Hi Chris, They are the same thing. Section 3: ... Its processing is defined in [I-D.ietf-6man-segment-routing-header] section 4.3 and reproduced here as a reminder. Without constraining the details of an implementation, the SR segment endpoint node creates Forwarding Inform

Re: [spring] FW: New Version Notification fordraft-dong-spring-sr-for-enhanced-vpn-07.txt

Hi Ran, Thanks for your feedback. Please see my replies inline with [Jie]: From: chen@zte.com.cn [mailto:chen@zte.com.cn] Sent: Wednesday, March 11, 2020 12:08 PM To: Dongjie (Jimmy) Cc: spring@ietf.org; spring-cha...@ietf.org; t...@ietf.org Subject: Re:[spring] FW: New Version Notificat

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

Pablo PC2: The comment started because in the draft we had an example that was assigning A:1::/32 as loopback interface for a router. This is wrong (prefix length, documentation prefix,). This was fixed in revision 2 of the WG draft, published in September 19th 2019. The closure of this comment