Re: [spring] Beyond SRv6.

Completely agree with Ron. SRv6+ is much more simpler , minimum config required and easy to implement.. Regards Parag Juniper Business Use Only From: spring On Behalf Of Ron Bonica Sent: Sunday, September 1, 2019 2:04 AM To: Rob Shakir ; SPRING WG List ; 6...@ietf.org Subject: Re: [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 requirements f

Re: [spring] New Version Notification for draft-bonica-spring-srv6-plus-05.txt

Hi Ron: Thank u for your explanation in detail, I fully agreed on what you said from SID's different perspective. You have offered new idea for Segment. The key reason why I previously raised the different opinion to your Node-local significance of all type of SID is my understanding of segment

Re: [spring] Question about SRv6 Insert function

Cameron, I hear you. SRv6+ will try to limit its ask to the following: * Enough community review to make sure that we aren't doing anything dangerous * Four code points (i.e., two IPv6 Routing types and two IPv6 options) * One registry (i.e., Special purpose SIDs) Beyond that, we w

Re: [spring] Beyond SRv6.

Adding my perspective here. The fact that some proposals come on the table shows that we have something to optimize. So far there has been little feedback on sizes required in real deployments. Personally I have seen request for small (1-2 sids) to other cases which require up to 9-10 sids deep.

[spring] 答复: Beyond SRv6.

Hi Folks, I have explained opinions in the session meeting of IETF104. Here I would like to summarize it agian: 1. Problem Statement There are three three major concerns about SRH: 1) Path MTU: In theory it may be an issue. But as the develoment of the link layer technology, the network admin

Re: [spring] Question about SRv6 Insert function

On Mon, Sep 2, 2019 at 9:07 AM Suresh Krishnan wrote: > 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 he

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

Re: [spring] Beyond SRv6.

Just another note on clashes – any company that deals with constant and frequent merges and acquisitions will know – uniqueness is paramount – unless you want integration headaches that will cause you weeks of sleepness nights. And when you’re doing 3 or 4 M&A’s a year – this is very very very i

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 usua

Re: [spring] Beyond SRv6.

Hi, I agree with Dirk. The SRv6 fulfills our requirements for vast majority of our use-cases. For some use cases requiring MTU efficiency, we have SRv6 uSID segments that are just a different pseudo code and is fully integrated with SRH. I also concur, there is no need for the work group for de

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 headers, and still other information in Destination Options headers. SRv6+

Re: [spring] Beyond SRv6.

Let’s not forget the SRv6 ecosystem includes several open-source implementations • Linux: Kernel and srext module • FD.io: VPP • Apps: Snort, iptables and nftables, tcpdump and Wireshark. Thanks, Darren On Aug 31, 2019, at 12:06 AM, Zafar Ali (zali) mailto:z...@cisco.com>> wrot

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 m

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 > a

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.

The introduction of alternatives was prompted by a number of concerns, not just the encapsulation overhead. Having said that, we as a group have not adopted the uSID approach, and many of us have serious concerns about that. Claiming that uSID is agreed and solves the size problems seems not to