From: spring <[email protected]> On Behalf Of Stefano Salsano Sent: Friday, 20 November 2020 08:09 To: 程伟强 <[email protected]>; spring <[email protected]> Cc: srcomp <[email protected]>; [email protected] <[email protected]> Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt
Il 2020-11-15 16:27, 程伟强 ha scritto: > Hi Group, > > SR compression design team have submitted a new version of compression > requirement draft. > > Main changes as follows: > > - added 3 items about scalibility with agreement within the design team > > - added an appendix including 3 items without without unanimous > consensus within the design team Hi all, the the appendix A of latest draft version includes three items that should be taken into consideration, in particular: Requirement A.2.1. SRv6 Based Requirement A.2.2. SRv6 Functionality "A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 architecture, control plane and data plane" and "A solution to compress an SRv6 SID list MUST support the functionality of SRv6" I've been working in the last 4 years on the open source ecosystem supporting SRv6, including the support of SRv6 in the Linux kernel (see https://netgroup.github.io/rose/<https://netgroup.github.io/rose>) a lot of effort has been spent in this ecosystem that now offers a feature set comparable to vendors' implementation of SRv6 it is very important for the research community to have such ecosystem and it will be painful to rebuild the support for a new solution outside of the current SRv6 architecture... one of the problem of the MPLS architecture (from the research comunity point of wiew) was that the support in Linux has never been comparable to vendors's solution (e.g. for the control plane), for this reason the research work diverged a lot from production solutions, I really would like to avoid such gap again My issue with this is that there are operators – who have requirements today – that encompass a solution that has already shipped – requirements that are built on something entirely outside of the SRH – and I fail to see why such a solution should not be catered for – or alternatively – should not be considered entirely outside of the scope of spring (which would be just fine by me) so that the work can proceed within the context of the IETF – rather than forcing it outside of the IETF because of stalling and this view that some how there can only be one solution to every problem. By the time we get anything done here, we will be 10 months into this – and I point out that in the meeting I stated 6 months and it was disputed. The design team was first muted in May – it took 2 months to get going – but this has actually been 6 months, and now we are looking at another 4 months before we meet again. This is on top of the stalling that has taken place since IETF 106 on moving forward on anything that the srv6 pundits seem to view as some kinda competition to them. This is having very real world consequences for certain operators – and I can also state flatly, this is beginning to impact on my decisions as regards to vendor purchasing – and that is also the message I will be taking to the operators I work with – that there are competing solutions to certain very specific problems – one of those solutions is shipping in code today – it was developed outside of IETF adoption because there was no alternative to that – we hope one day to get the IETF to be willing to work on this to refine it and take it forward – but until then – if you want it – this is what you are going to have to buy. Andrew
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
