Re: [spring] Beyond SRv6.

Zafar Please can you clarify: Is that all forwarding ASICs on all platforms or are there some restrictions? - Stewart On 16/09/2019 16:59, Zafar Ali (zali) wrote: Dear Chairs and the WG, As asked by the chairs ... Cisco ASIC is capable of reading and writing an SRH of up to 9 (nine)

Re: [spring] Beyond SRv6.

: spring on behalf of Rob Shakir Date: Sunday, August 4, 2019 at 5:03 PM To: SPRING WG List Subject: [spring] Beyond SRv6. Hi SPRING WG, Over the last 5+ years, the IETF has developed Source Packet Routing in NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6

Re: [spring] Beyond SRv6.

rek Saad ; Robert Raszuk Subject: Re: [spring] Beyond SRv6. +1 The ability of using a single SRH to convey behaviour information wether they are per-segment or per-path has proven to be very simple and quick to define in various data plane targets. At first analysis, trying to replicat

Re: [spring] Beyond SRv6.

- END.T Ron Juniper Business Use Only From: Bernier, Daniel Sent: Thursday, September 12, 2019 2:26 PM To: Ron Bonica ; Mark Smith Cc: Rob Shakir ; SPRING WG ; 6man <6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn; Tarek Saad Subject: RE: [spring] Beyond SRv6.

Re: [spring] Beyond SRv6.

9 6:32 AM To: Robert Raszuk ; Ron Bonica Cc: xie...@chinatelecom.cn; Rob Shakir ; SPRING WG ; 6man <6...@ietf.org>; Tarek Saad Subject: Re: [spring] Beyond SRv6. Robert, > But what is most important that common hardware reads just entire > header then starts processing. So

Re: [spring] Beyond SRv6.

Hi Tom, Robert, > > Right, but isn't that precisely one of the arguments that 16 byte SIDs are > a problem? For instance, if my parsing buffer is 128 bytes then that allows > an SRH with at most four or maybe five SIDs if I'm not mistaken. It seems > like the smaller SID size of SRV6+, even with

Re: [spring] Beyond SRv6.

On Thu, Sep 12, 2019, 4:15 PM Robert Raszuk wrote: > Hi Brian, > > > To what extent is this behind the present argument? > > If you are calling elephant and ASIC/FPGA - that was not my reasoning at > all. > > Regardless if you are processing packets by a fixed burned ASIC or > programmable NP

Re: [spring] Beyond SRv6.

t;6...@ietf.org>; Rob Shakir ; Tarek Saad Subject: Re: [spring] Beyond SRv6. Robert, > But what is most important that common hardware reads just entire > header then starts processing. So it really makes much more sense to > encode SR SIDs and related functions and their paramet

Re: [spring] Beyond SRv6.

Hi Brian, > To what extent is this behind the present argument? If you are calling elephant and ASIC/FPGA - that was not my reasoning at all. Regardless if you are processing packets by a fixed burned ASIC or programmable NP the packet must be read into DRAM and its header stored in SRAM during

Re: [spring] Beyond SRv6.

t;> SIDs: >> >> >> >>- END.DX2 >>- END.DX2V >>- END.DX2U >>- END.DX2M >>- END.DT4 >>- END.DX4 >>- END.DT6 >>- END.DX6 >>- END.DT46 >>- END.T >> >> >> >> >

Re: [spring] Beyond SRv6.

.@gmail.com>>; Rob Shakir mailto:ro...@google.com>>; SPRING WG mailto:spring@ietf.org>>; 6man <6...@ietf.org<mailto:6...@ietf.org>>; xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; Tarek Saad mailto:tsaad@gmail.com>> Subject: Re: [spring] Beyon

Re: [spring] Beyond SRv6.

tf.org>; 6man <6...@ietf.org>; xie...@chinatelecom.cn; Tarek > Saad > *Subject:* Re: [spring] Beyond SRv6. > > > > Dear Ron, > > > > I was trying to stop responding but its pretty hard when I see such post > like your last one ... > > > > >

Re: [spring] Beyond SRv6.

gt;> Cc: Rob Shakir mailto:ro...@google.com>>; SPRING WG mailto:spring@ietf.org>>; 6man <6...@ietf.org<mailto:6...@ietf.org>>; Robert Raszuk mailto:rob...@raszuk.net>>; xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; Tarek Saad mailto:tsaad...

Re: [spring] Beyond SRv6.

gt;- END.DT46 >- END.T > > > > > > > Ron > > > > > > Juniper Business Use Only > > *From:* Bernier, Daniel > *Sent:* Thursday, September 12, 2019 2:26 PM > *To:* Ron Bonica ; Mark Smith > > *Cc:* Rob Shakir

Re: [spring] Beyond SRv6.

Ron Juniper Business Use Only From: Bernier, Daniel Sent: Thursday, September 12, 2019 2:26 PM To: Ron Bonica ; Mark Smith Cc: Rob Shakir ; SPRING WG ; 6man <6...@ietf.org>; Robert Raszuk ; xie...@chinatelecom.cn; Tarek Saad Subject: RE: [spring] Beyon

Re: [spring] Beyond SRv6.

ct: Re: [spring] Beyond SRv6. It's simple because IPv6 doesn't look past the fixed IPv6 header to perform its forwarding, and matches on the Destination Address to determine if to perform deeper packet host processing. You're building much more complicated forwarding services if you're

Re: [spring] Beyond SRv6.

ing On Behalf Of Bernier, Daniel Sent: Wednesday, September 11, 2019 11:41 PM To: xie...@chinatelecom.cn; List Cc: Rob Shakir ; 6man <6...@ietf.org>; Tarek Saad ; Robert Raszuk Subject: Re: [spring] Beyond SRv6. +1 The ability of using a single SRH to convey behaviour information wether they

Re: [spring] Beyond SRv6.

s > > Jingrong > > > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Bernier, Daniel > Sent: Thursday, September 12, 2019 11:41 AM > To: xie...@chinatelecom.cn; List > Cc: Rob Shakir ; 6man <6...@ietf.org>; Tarek Saad > ; Robert Raszuk > Subject:

Re: [spring] Beyond SRv6.

be given on how to support new > services,for instance, Application-aware network > (APN). Meanwhile, we should consider more on > how to implmement smooth transition and protect the network assetof carriers. > > Best regards > Chongfeng > > > *From:* Dirk Steinberg &g

Re: [spring] Beyond SRv6.

] On Behalf Of Bernier, Daniel Sent: Thursday, September 12, 2019 11:41 AM To: xie...@chinatelecom.cn; List Cc: Rob Shakir ; 6man <6...@ietf.org>; Tarek Saad ; Robert Raszuk Subject: Re: [spring] Beyond SRv6. +1 The ability of using a single SRH to convey behaviour information

Re: [spring] Beyond SRv6.

to:rob...@raszuk.net>; Rob Shakir<mailto:ro...@google.com>; Tarek Saad<mailto:tsaad@gmail.com> Subject: Re: [spring] Beyond SRv6. There seems to be some confusion regarding TI-LFA. A couple of comments: - Remote LFA tunnel is not used with SR, only TI-LFA which only operates o

Re: [spring] Beyond SRv6.

To: Gyan Mishra > CC: SPRING WG List; 6...@ietf.org; Robert Raszuk; Rob Shakir; Tarek Saad > Subject: Re: [spring] Beyond SRv6. > There seems to be some confusion regarding TI-LFA. > A couple of comments: > > - Remote LFA tunnel is not used with SR, only TI-LFA which >

Re: [spring] Beyond SRv6.

assetof carriers. Best regards Chongfeng From: Dirk Steinberg Date: 2019-09-09 21:31 To: Gyan Mishra CC: SPRING WG List; 6...@ietf.org; Robert Raszuk; Rob Shakir; Tarek Saad Subject: Re: [spring] Beyond SRv6. There seems to be some confusion regarding TI-LFA. A couple of comments: - Remote LFA

Re: [spring] Beyond SRv6.

; "Tarek Saad"; Sent: 2019-09-11 (水) 10:31:12 (GMT+09:00) Subject: Re: [spring] Beyond SRv6. Excellent news. I’d capture your case in the SRv6 deployment draft, in case you’d be okay. Cheers, --satoru 2019/09/11 9:55、Hirofumi Ichihara のメール: Hi folks, ​ Let me mention my opinion as

Re: [spring] Beyond SRv6.

uot;; > Cc: "SPRING WG List"; "6...@ietf.org"<6...@ietf.org>; "Gyan > Mishra"; "Robert Raszuk"; "Rob > Shakir"; "Tarek Saad"; > Sent: 2019-09-10 (火) 02:51:48 (GMT+09:00) > Subject: Re: [spring] Beyond SRv6. > >

Re: [spring] Beyond SRv6.

;; "Ron Bonica"; Cc: "SPRING WG List"; "6...@ietf.org"<6...@ietf.org>; "Gyan Mishra"; "Robert Raszuk"; "Rob Shakir"; "Tarek Saad"; Sent: 2019-09-10 (火) 02:51:48 (GMT+09:00) Subject: Re: [spring] Beyond SRv6. Andy, R

Re: [spring] Beyond SRv6.

; Tarek Saad Subject: Re: [spring] Beyond SRv6. Ron, Doesn't ISIS require a quad octet / 32 bit / IPv4 address for it's router ID? So you can't really build an ipv4 'free' network. Not 100% anyway. Andy On Sep 9, 2019, at 12:21 PM, Ron Bonica mailto:rbonica=40juniper@dmarc.ietf.org

Re: [spring] Beyond SRv6.

ing@ietf.org>>; 6...@ietf.org > <mailto:6...@ietf.org>; Zafar Ali (zali) <mailto:z...@cisco.com>>; Rob Shakir <mailto:ro...@google.com>>; Ron Bonica <mailto:rbon...@juniper.net>>; Tarek Saad <mailto:tsaad@gmail.com>> > Subject: Re: [s

Re: [spring] Beyond SRv6.

. Ron Juniper Business Use Only From: Gyan Mishra Sent: Sunday, September 8, 2019 3:20 AM To: Robert Raszuk Cc: Srihari Sangli ; SPRING WG List ; 6...@ietf.org; Zafar Ali (zali) ; Rob Shakir ; Ron Bonica ; Tarek Saad Subject: Re: [spring] Beyond SRv6. As an operator of a Tier 1 provider

Re: [spring] Beyond SRv6.

There seems to be some confusion regarding TI-LFA. A couple of comments: - Remote LFA tunnel is not used with SR, only TI-LFA which only operates on the node that is the PLR (point of local repair). - Any encapsulation on the ingress PE with or without EH has nothing to do with TI-LFA

Re: [spring] Beyond SRv6.

As an operator of a Tier 1 provider with massive mpls networks I think our traditional bread and butter “mpls” will be around for a very very long time as is IPv4 if not longer. Most all service provider cores run greater then or equal to MTU 9000 mpls cores to account for mpls overhead shims

Re: [spring] Beyond SRv6.

I don't think so. In OAM packets are on purpose made huge - even up to MTU to make sure real customer packets can go through or to detect and diagnose MTU issues. So adding SRH to it is nothing one can call inefficient. Wrong tree :) Cheers, R. On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli

Re: [spring] Beyond SRv6.

om.com> > *Cc:* Ron Bonica ; Srihari Sangli < > ssan...@juniper.net>; Tarek Saad ; Rob Shakir < > ro...@google.com>; SPRING WG List ; 6...@ietf.org; Zafar > Ali (zali) > *Subject:* Re: [spring] Beyond SRv6. > > > > Hi Andrew, > > > > I agree w

Re: [spring] Beyond SRv6.

On 06/09/19, 4:32 PM Robert Raszuk from rob...@raszuk.net said > Not really. Only SR OAM packets may need it. Is that a real problem ? Thanks for clarification. Like Ron pointed out before, its inefficient encoding. srihari…

Re: [spring] Beyond SRv6.

k , Andrew Alston Cc: Ron Bonica , Srihari Sangli , Tarek Saad , Rob Shakir , SPRING WG List , "6...@ietf.org" <6...@ietf.org>, "Zafar Ali (zali)" Subject: Re: [spring] Beyond SRv6. Hi Andrew, I agree with Robert. CRH is nothing else than IPv6 over SR-MPLS. In the vast ma

Re: [spring] Beyond SRv6.

> > Vanilla TRACEROUTE reveals all of the mapping information. RFC 5837 offers > some nice extras, but isn't strictly required. > Really ? If your traffic policy steers some TCP traffic for ports 4000-5000 to take segment A-B-C-D and for ports 6000-7000 to take segment A-E-F-G-D how your vanilla

Re: [spring] Beyond SRv6.

Sent: Friday, September 6, 2019 2:42 AM To: Ron Bonica Cc: spring@ietf.org; 6...@ietf.org Subject: Re: [spring] Beyond SRv6. > Nothing so complicated is required. At most, PING and TRACEROUTE with RFC > 5837 extensions. Are there any vendors actually implementing RFC 5837? Ivan Pep

Re: [spring] Beyond SRv6.

Not really. Only SR OAM packets may need it. Is that a real problem ? Best R On Fri, Sep 6, 2019, 11:41 Srihari Sangli wrote: > Zafar, > > > > · The original segment list is maintained by using the > non-Reduced flavor (in which case the SID list is fully preserved in the > SRH). > > >

Re: [spring] Beyond SRv6.

Zafar, · The original segment list is maintained by using the non-Reduced flavor (in which case the SID list is fully preserved in the SRH). [RB] At the cost of encoding efficiency. 50% decrease !! If I understand it right, the IPv6 packet carrying uSIDs will also have full set

Re: [spring] Beyond SRv6.

t; > > > *From:* Zafar Ali (zali) > *Sent:* Friday, 6 September 2019 11:28 > *To:* Robert Raszuk ; Andrew Alston < > andrew.als...@liquidtelecom.com> > *Cc:* Ron Bonica ; Srihari Sangli < > ssan...@juniper.net>; Tarek Saad ; Rob Shakir < > ro...@google.com>; SPRING

Re: [spring] Beyond SRv6.

; Tarek Saad ; Rob Shakir ; SPRING WG List ; 6...@ietf.org; Zafar Ali (zali) Subject: Re: [spring] Beyond SRv6. Hi Andrew, I agree with Robert. CRH is nothing else than IPv6 over SR-MPLS. In the vast majority of the deployments (single SP domain), one can deploy MPLS. In a minority of cases

Re: [spring] Beyond SRv6.

: Robert Raszuk Date: Friday, September 6, 2019 at 4:01 AM To: Andrew Alston Cc: "Zafar Ali (zali)" , Ron Bonica , Srihari Sangli , Tarek Saad , Rob Shakir , SPRING WG List , "6...@ietf.org" <6...@ietf.org> Subject: Re: [spring] Beyond SRv6. Hi Andrew, I can

Re: [spring] Beyond SRv6.

Hi Andrew, I can say that I may even agree with some of your points. But one question I asked which no one responded still stands ... SRv6+ is almost identical to SR-MPLS with IP transport between segment nodes. Both require mapping, both require changes to OAM, both require IGP extensions, both

Re: [spring] Beyond SRv6.

lp.no" Date: Friday, September 6, 2019 at 2:42 AM To: "rbonica=40juniper@dmarc.ietf.org" Cc: "spring@ietf.org" , "6...@ietf.org" <6...@ietf.org> Subject: Re: [spring] Beyond SRv6. Nothing so complicated is required. At most, PING and TRACEROUTE wit

Re: [spring] Beyond SRv6.

> Nothing so complicated is required. At most, PING and TRACEROUTE with RFC > 5837 extensions. Are there any vendors actually implementing RFC 5837? Ivan Pepelnjak commented "However, it looks like nobody implemented it in almost five years since it was published." at

Re: [spring] Beyond SRv6.

Bonica Date: Friday, September 6, 2019 at 2:23 AM To: "Zafar Ali (zali)" , Srihari Sangli , Tarek Saad , Rob Shakir , SPRING WG List , "6...@ietf.org" <6...@ietf.org> Subject: RE: [spring] Beyond SRv6. Ali, Nothing so complicated is required. At most, PING an

Re: [spring] Beyond SRv6.

> This is absolutely false!   > Have you forgotten the very strong arguments against it at the Spring session > in Montreal and the various emails on the list that echoed them  > Not to mention comments from Robert R >

Re: [spring] Beyond SRv6.

; Tarek Saad ; Rob Shakir ; SPRING WG List ; 6...@ietf.org Cc: Zafar Ali (zali) Subject: Re: [spring] Beyond SRv6. Hi Ron, Please see in-line. Thanks Regards ... Zafar From: Ron Bonica mailto:rbon...@juniper.net>> Date: Friday, September 6, 2019 at 1:57 AM To: "Zafar Ali (zali

Re: [spring] Beyond SRv6.

Hi Ron, Please see in-line. Thanks Regards … Zafar From: Ron Bonica Date: Friday, September 6, 2019 at 1:57 AM To: "Zafar Ali (zali)" , Srihari Sangli , Tarek Saad , Rob Shakir , SPRING WG List , "6...@ietf.org" <6...@ietf.org> Subject: RE: [spring] Beyond S

Re: [spring] Beyond SRv6.

>SRv6+ is definitely a better proposal in terms > 1.Adherence to IPv6 Architecture > 2.Efficient encoding > 3.Operational simplicity > > There hasn't been a single mail denying the above advantages of SRv6+ This is absolutely false! Have you forgotten the very strong arguments against it

Re: [spring] Beyond SRv6.

Hi Reji, > SRv6+ confirms to the V6 architecture, explains the rationale behind the > design and is non ambiguous to start with. Till now there has not been any > valid shortcomings brought forth with the Srv6+ design. I saw a mention that > SRv6+ needs to distribute the SID to address

Re: [spring] Beyond SRv6.

Bonica > > > Date: Monday, September 2, 2019 at 9:23 AM > To: Rob Shakir , SPRING WG List < > spring@ietf.org>, "6...@ietf.org" <6...@ietf.org> > Subject: Re: [spring] Beyond SRv6. > > Rob, > > There may be an elephant in the room that needs address

Re: [spring] Beyond SRv6.

   Thanks,  Ron *From:* spring *On Behalf Of *Rob Shakir *Sent:* Sunday, August 4, 2019 5:04 PM *To:* SPRING WG List *Subject:* [spring] Beyond SRv6. Hi SPRING WG, Over the last 5+ years, the IETF has developed Source Packet Routing in NetworkinG (SPRING) aka

Re: [spring] Beyond SRv6.

To: Rob Shakir , SPRING WG List , "6...@ietf.org" <6...@ietf.org> Subject: Re: [spring] Beyond SRv6. Rob, There may be an elephant in the room that needs addressing…. Over the years, the IPv6 community has specified a very tight architecture that encodes some information in IP

Re: [spring] Beyond SRv6.

uot;6...@ietf.org" <6...@ietf.org> Subject: Re: [spring] Beyond SRv6. Rob, There may be an elephant in the room that needs addressing…. Over the years, the IPv6 community has specified a very tight architecture that encodes some information in IPv6 addresses, other information in Routing he

Re: [spring] Beyond SRv6.

on that. Ron From: Robert Raszuk Sent: Tuesday, September 3, 2019 11:00 AM To: Ron Bonica Cc: Shraddha Hegde ; Rob Shakir ; SPRING WG List ; 6...@ietf.org Subject: Re: [spring] Beyond SRv6. Hi Ron, You are spot on that SRv6+ conceptually and operationally is very similar to SR

Re: [spring] Beyond SRv6.

Ron > > > > > > > > > > *From:* Robert Raszuk > *Sent:* Tuesday, September 3, 2019 8:13 AM > *To:* Shraddha Hegde > *Cc:* Ron Bonica ; Rob Shakir ; > SPRING WG List ; 6...@ietf.org > *Subject:* Re: [spring] Beyond SRv6. > >

Re: [spring] Beyond SRv6.

inserted. Ron Juniper Business Use Only -Original Message- From: Fernando Gont Sent: Tuesday, September 3, 2019 7:26 AM To: Ron Bonica ; Rob Shakir ; SPRING WG List ; 6...@ietf.org Subject: Re: [spring] Beyond SRv6. On 2/9/19 00:10, Ron Bonica wrote: > Hi Fernan

Re: [spring] Beyond SRv6.

some text. Ron From: Robert Raszuk Sent: Tuesday, September 3, 2019 8:13 AM To: Shraddha Hegde Cc: Ron Bonica ; Rob Shakir ; SPRING WG List ; 6...@ietf.org Subject: Re: [spring] Beyond SRv6. Hi Shraddha, The proposed architecture in CRH based drafts is a significant departure fro

Re: [spring] Beyond SRv6.

tter > solution and > >I support SPRING WG to continue work on SRv6+. > > > > > > Rgds > > Shraddha > > > > *From:* spring *On Behalf Of *Ron Bonica > *Sent:* Monday, September 2, 2019 6:53 PM > *To:* Rob Shakir ; SPRING WG List < > sprin

Re: [spring] Beyond SRv6.

On 2/9/19 00:10, Ron Bonica wrote: > Hi Fernando, > > 6man participants should look at the following: > > - https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01 > (In particular, Sections 4 and 5) > - >

Re: [spring] Beyond SRv6.

and I support SPRING WG to continue work on SRv6+. Rgds Shraddha From: spring On Behalf Of Ron Bonica Sent: Monday, September 2, 2019 6:53 PM To: Rob Shakir ; SPRING WG List ; 6...@ietf.org Subject: Re: [spring] Beyond SRv6. Rob, There may be an elephant in the room that needs addressing

Re: [spring] Beyond SRv6.

: spring mailto:spring-boun...@ietf.org>> On Behalf Of Rob Shakir Sent: Sunday, August 4, 2019 5:04 PM To: SPRING WG List mailto:spring@ietf.org>> Subject: [spring] Beyond SRv6. Hi SPRING WG, Over the last 5+ years, the IETF has developed Source Packet Routing in NetworkinG (SPRING)

Re: [spring] Beyond SRv6.

I agree; there is no need for a new encapsulation. -- Kamran From: spring on behalf of "Voyer, Daniel" Date: Monday, September 2, 2019 at 10:25 AM To: Dirk Steinberg , SPRING WG List , Rob Shakir Subject: Re: [spring] Beyond SRv6. Hi, I agree with Dirk. The SRv6 fulfills our re

Re: [spring] Beyond SRv6.

it would be bad if we change direction all of a sudden. So I propose to flush out what we have and where the limits are and figure out a way forward based on this. My 2 cents. From: spring on behalf of Rob Shakir Date: Sunday, 4 August 2019 at 22:04 To: SPRING WG List Subject: [spring] Beyond

Re: [spring] Beyond SRv6.

important Andrew From: spring on behalf of Nick Hilliard Date: Monday, 2 September 2019 at 16:28 To: Robert Raszuk Cc: Ron Bonica , SPRING WG List , "6...@ietf.org" <6...@ietf.org>, Mark Smith , Rob Shakir , Fernando Gont Subject: Re: [spring] Beyond SRv6. Robert Raszuk wro

Re: [spring] Beyond SRv6.

Robert Raszuk wrote on 02/09/2019 12:49: Yes you are 100% correct. The decision to inject any prefix into someone's IGP (or BGP) is a local operator's decision. It is, and most operators take pains to avoid injecting shared addressing resources into their routing domains. These days it

Re: [spring] Beyond SRv6.

for define a new extension header. Thanks, dan From: spring on behalf of Dirk Steinberg Date: Sunday, September 1, 2019 at 10:20 AM To: SPRING WG List , Rob Shakir Subject: [EXT]Re: [spring] Beyond SRv6. Hi, the introduction of SRv6 as alternate data plane in addition to MPLS has been

Re: [spring] Beyond SRv6.

List Subject: [spring] Beyond SRv6. Hi SPRING WG, Over the last 5+ years, the IETF has developed Source Packet Routing in NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE

Re: [spring] Beyond SRv6.

t mailto:spring@ietf.org>> Subject: [spring] Beyond SRv6. Hi SPRING WG, Over the last 5+ years, the IETF has developed Source Packet Routing in NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP in UDP

Re: [spring] Beyond SRv6.

Hey Mark, I think the only place you can put uSIDs is in the IID field, and I went > to the effort of providing RFC references. > I only tend to follow the rules which make sense or which violation even if they do not make sense goes against best practices, common rules or could endanger anyone

Re: [spring] Beyond SRv6.

Robert Raszuk wrote on 02/09/2019 12:09: If that is the only concern I think we are done then. The only issue is that if you happen to have hierarchical IGP you will not be able to summarize them - but I don't think that this would be a showstopper to any deployment. Robert, please correct

Re: [spring] Beyond SRv6.

Hi Nick, Yes you are 100% correct. The decision to inject any prefix into someone's IGP (or BGP) is a local operator's decision. Btw let me also self correct last note - It is actually pretty trivial to pseudo-random generate ULAs such that blocks of it can actually be aggregatable across areas

Re: [spring] Beyond SRv6.

On Mon., 2 Sep. 2019, 21:09 Robert Raszuk, wrote: > > > Are uSID values going to be entirely pseudo-random? > > I see no reason why not ... > > Networks are managed by some form of NMS. NMS can generate such values and > abstract it with a "node_name_usid" string for any additional processing >

Re: [spring] Beyond SRv6.

> Are uSID values going to be entirely pseudo-random? I see no reason why not ... Networks are managed by some form of NMS. NMS can generate such values and abstract it with a "node_name_usid" string for any additional processing and human abstraction. If that is the only concern I think we are

Re: [spring] Beyond SRv6.

On Mon., 2 Sep. 2019, 17:58 Robert Raszuk, wrote: > Hi Mark, > > >> The uSID proposal is taking the position that all the bits after the high >> order prefix are available for any purpose. This is not correct, and would >> violate a number of standards track RFCs, including the IPv6 Addressing

Re: [spring] Beyond SRv6.

Hi Mark, > The uSID proposal is taking the position that all the bits after the high > order prefix are available for any purpose. This is not correct, and would > violate a number of standards track RFCs, including the IPv6 Addressing > Architecture RFC (RFC 4291) and the ULA RFC (RFC 4193). >

Re: [spring] Beyond SRv6.

far *From:*spring <mailto:spring-boun...@ietf.org>> on behalf of Rob Shakir <mailto:robjs=40google@dmarc.ietf.org>> *Date:*Sunday, August 4, 2019 at 5:04 PM *To:*SPRING WG List mailto:spring@ietf.org>> *Subject:*[spring] Beyond SRv6. Hi SPRING WG, Over the last 5+ yea

Re: [spring] Beyond SRv6.

On Mon., 2 Sep. 2019, 07:56 Robert Raszuk, wrote: > > Yes Ron I saw this message from Bob and as you see from the mailer I > responded with clarification on why this is not 2^112. > > While I do not understand why ULAs blocks must be globally unique (to me > this is analogy of RFC1918 :) > RFC

Re: [spring] Beyond SRv6.

l still get around to doing this – time has just been a little > hectic of late. > > > > Andrew > > *From: *Robert Raszuk > *Date: *Sunday, 1 September 2019 at 22:28 > *To: *Andrew Alston > *Cc: *Ron Bonica , Rob Shakir < > ro...@google.com>, SPRING WG List , "6

Re: [spring] Beyond SRv6.

On Mon., 2 Sep. 2019, 07:39 Robert Raszuk, wrote: > Nick, > > How about using ULAs as defined in RFC4193 ? > I've analysed uSID in the context of all current IPv6 unicast address formats in this email. https://mailarchive.ietf.org/arch/msg/spring/Gsr-nJqzhyYIrj8mG6p3KZ_HZ5E Short answer is

Re: [spring] Beyond SRv6.

not suffice. Jim From: spring On Behalf Of Andrew Alston Sent: Sunday, September 01, 2019 5:30 PM To: Robert Raszuk Cc: Ron Bonica ; Rob Shakir ; SPRING WG List ; 6...@ietf.org Subject: Re: [spring] Beyond SRv6. Robert, CRH works just fine with the deep label depth in our testing of it. As I stated

Re: [spring] Beyond SRv6.

Yes Ron I saw this message from Bob and as you see from the mailer I responded with clarification on why this is not 2^112. While I do not understand why ULAs blocks must be globally unique (to me this is analogy of RFC1918 :) there are few more options on the table on what blocks to use for

Re: [spring] Beyond SRv6.

tus-01 section > 2.3. > > Best regards, > Sébastien > > - Mail original - >> De: "Satoru Matsushima" >> À: "SPRING WG List" >> Cc: "Zafar Ali, zali" , "Rob Shakir" >> >> Envoyé: Samedi 31 Août 2019 1

Re: [spring] Beyond SRv6.

Subject: Re: [spring] Beyond SRv6. Nick, How about using ULAs as defined in RFC4193 ? After all isn't local IPv6 FC00::/7 address block defined precisely for such private use cases like the one which uSID requires? Clearly RIRs will not allocate /22 blocks left and right and that v6 prefix would

Re: [spring] Beyond SRv6.

Nick, How about using ULAs as defined in RFC4193 ? After all isn't local IPv6 FC00::/7 address block defined precisely for such private use cases like the one which uSID requires? Clearly RIRs will not allocate /22 blocks left and right and that v6 prefix would be required if I have 1000 node

Re: [spring] Beyond SRv6.

Ron Bonica wrote on 01/09/2019 22:10: -https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02 Ron, if this draft proposes using up to /32 per router in a SRv6 domain, or even /40 to /48, it may be appropriate to solicit input from RIR address policy groups about

Re: [spring] Beyond SRv6.

still get around to doing this – time has just been a little hectic of late. Andrew From: Robert Raszuk Date: Sunday, 1 September 2019 at 22:28 To: Andrew Alston Cc: Ron Bonica , Rob Shakir , SPRING WG List , "6...@ietf.org" <6...@ietf.org> Subject: Re: [spring] Beyond

Re: [spring] Beyond SRv6.

Ron Juniper Business Use Only -Original Message- From: Fernando Gont Sent: Saturday, August 31, 2019 4:53 PM To: Ron Bonica ; Rob Shakir ; SPRING WG List ; 6...@ietf.org Subject: Re: [spring] Beyond SRv6. Hi, Ron, For those 6man

Re: [spring] Beyond SRv6.

eed. > > > > Andrew > > > > > > *From: *spring on behalf of Ron Bonica 40juniper@dmarc.ietf.org> > *Date: *Sunday, 1 September 2019 at 21:00 > *To: *Robert Raszuk > *Cc: *Rob Shakir , SPRING WG List , " > 6...@ietf.org" <6...@ietf.or

Re: [spring] Beyond SRv6.

6...@ietf.org> Subject: Re: [spring] Beyond SRv6. Robert, I can only repeat what my customers’ requirements. They have asked for 8-12 SIDs in SR-MPLS and SRv6 and SRv6+. We didn’t question that requirement for SR-MPLS. Why should things be any different

Re: [spring] Beyond SRv6.

> > > > > > > > > *From:* Robert Raszuk > *Sent:* Sunday, September 1, 2019 11:03 AM > *To:* Ron Bonica > *Cc:* Rob Shakir ; SPRING WG List ; > 6...@ietf.org > *Subject:* Re: [spring] Beyond SRv6. > > > > Dear Ron, > > > > > SR c

Re: [spring] Beyond SRv6.

+? Ron From: Robert Raszuk Sent: Sunday, September 1, 2019 11:03 AM To: Ron Bonica Cc: Rob Shakir ; SPRING WG List ; 6...@ietf.org Subject: Re: [spring] Beyond SRv6. Dear Ron, > SR customers have stated a firm requirement to support SR paths that contain > 8 to 12 segments. Let m

Re: [spring] Beyond SRv6.

ons that are inevitably encountered when > stretching the interpretation of a specification that is so fundamental as > RFC 8200. > > > > > > Thanks, > > >

Re: [spring] Beyond SRv6.

, as they progress through the working group, they won’t > need to overcome the objections that are inevitably encountered when > stretching the interpretation of a specification that is so fundamental as > RFC 8200. > > > > > >

Re: [spring] Beyond SRv6.

not see the need for any new encapsulation work. > > Thanks > > Regards … Zafar > > From: spring mailto:spring-boun...@ietf.org>> on > behalf of Rob Shakir <mailto:robjs=40google@dmarc.ietf.org>> > Date: Sunday, August 4, 2019 at 5:04 PM > T

Re: [spring] Beyond SRv6.

NG WG List" > Cc: "Zafar Ali, zali" , "Rob Shakir" > > Envoyé: Samedi 31 Août 2019 15:41:43 > Objet: Re: [spring] Beyond SRv6. > Hi, > > As part of the 5G rollout, Softbank have deployed a nationwide SRv6 network > carrying commercial

Re: [spring] Beyond SRv6.

On Sun., 1 Sep. 2019, 10:53 Fernando Gont, wrote: > On 1/9/19 03:32, Mark Smith wrote: > > +1 > > > > The value in using a commodity protocol like RFC 8200 compliant IPv6 > > for something like SR is that you're gaining from IPv6 being well > > understood, widely implemented, widely deployed,

Re: [spring] Beyond SRv6.

On 1/9/19 03:32, Mark Smith wrote: > +1 > > The value in using a commodity protocol like RFC 8200 compliant IPv6 > for something like SR is that you're gaining from IPv6 being well > understood, widely implemented, widely deployed, widely interoperable, > widely tested, and the major bugs have

Re: [spring] Beyond SRv6.

> Thanks, > > > Ron > > > > > > > > > > > > >

  1   2   >