Re: [spring] Progressing Standardizing SR over IPv6 compression
Hi Joel and WG, > Should the working group standardize one data plane behavior for > compressing SRv6 information? Yes, we should pick up and standardize a single solution for SRv6 compression. Interoperability is one of important factors for operators. Multi-options may prevent interoperability. Regards, Shunsuke On Thu, Aug 5, 2021 at 3:52 AM Joel M. Halpern wrote: > The SPRING Working Group Chairs thank the design team for their efforts > on the requirements and analysis drafts. The question of how the > working group wants to progress that part of the work will be the topic > for a separate email a bit later. > > Right now, we are hearing the discussion about how many solutions, and > the perspectives being expressed. While the topic was well-raised, the > discussion to date has not been structured in a way that makes clear to > everyone what the purpose is. In particular, the chairs have decided to > re-ask the question. We ask that even those who have responded in the > discussion respond to this thread. Preferably with both what their > opinion is and an explanation of why. > > The question we are asking you to comment on is: > > Should the working group standardize one data plane behavior for > compressing SRv6 information? > > Please speak up. We are looking to collect responses until close of > business PDT on 20-August-2021. > > Thank you, > Joel, Jim, and Bruno > > ___ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Hi WG, I think that this document is good enough as starting point for the WG, and I support the adoption. There are many drafts related to network slice with SR (e.g., SR + Flex-algo, draft-bestbar-spring-scalable-ns, etc.) and I hope it will be clarified which is the best in future work. The following are my comments to the draft. - The example describes three isolated VTNs. I assume (hard) isolation will cause split loss, and oversubscription will be sometimes needed. Hence, it may be better to allow a resource-aware SID to belong to multiple VTNs. - From network slicing (i.e., NaaS model) perspective, I assume visibility will be especially important. As one more important requirement, network operators want to provide only information of the VTN whose customer uses to that customer. For example, if a customer gets VTN information with BGP-LS, some mechanisms to prevent to leak other VTNs information in BGP-LS would be needed. - There is a typo in figure2. The adj-SID of the link from 203 to 204 in green VTN should be 2002. Regards, Shunsuke On Wed, Jan 27, 2021 at 8:47 PM James Guichard < james.n.guich...@futurewei.com> wrote: > Dear WG: > > > > This message starts a 2 week WG adoption call for > https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ > ending February 10th 2021. > > > > After review of the document please indicate support (or not) for WG > adoption to the mailing list and if you are willing to work on the > document, please state this explicitly. This gives the chairs an indication > of the energy level of people in the working group willing to work on this > document. Please also provide comments/reasons for your support (or lack > thereof) as this is a stronger way to indicate your (non) support as this > is not a vote. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > > ___ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Hi WG, I reviewed the draft, and support the adoption. The proposal may be a useful improvement of SR architecture, and it will be valuable to consider it. The follows are my comments: - Regarding scalability, it will depend on how to design configurations, and I think that there is little difference between existing technologies and the proposal. The number of virtual networks which can be built will strongly depend on the spec/ability of the underlay network. For example, the number of available QoS classes is limited by the number of queues which routers have. Or the size of a forwarding table depends on performance of TCAM. I think a critical point on scalability is underlay network spec/ability rather than the nature of techniques/protocols. - Simplifying data plane structure and its management by unifying several forwarding mechanisms to SID may be one of advantages of the proposal. - This extension may be a fundamental improvement, and it may not be necessary to be tied to usage for enhanced VPN solution. Regards, Shunsuke On Wed, Jul 29, 2020 at 12:48 AM Greg Mirsky wrote: > Dear Authors, > thank you for that well-written document. It was a pleasure to read. I > have a number of questions and much appreciate it if you can clarify them > for me: > >- how you envision mapping resources to a topological SID, e.g. >adj-SID? Would it be 1:1, i..e., a new SID for each resource that >characterizes a link in a virtual network? >- how granular association of a resource with a SID could practically >be? For example, BW may be de-composed into, per. RFC 6003, CIR, CBS, EIR, >and EBS. Do you expect a transient SR node to do policing and/or shaping >according to such resource information? >- I agree, that FlexE is one of Layer 2 technologies to provide >predictable, in regard to performance, transport. What benefits of using >resource information you see for FlexE? Would an intermediate node manage >the FlexE calendar? > > Regards, > Greg > > On Wed, Jul 15, 2020 at 4:17 AM James Guichard < > james.n.guich...@futurewei.com> wrote: > >> Dear WG: >> >> >> >> This email begins a 2 week WG adoption call for >> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ >> ending Wednesday 29th July 2020. >> >> >> >> Please speak up if you support or oppose adopting this document into the >> WG. Please also provide comments/reasons for that support (or lack >> thereof). Silence will not be considered consent. >> >> >> >> Thanks! >> >> >> >> Jim, Joel & Bruno >> >> >> >> >> >> >> ___ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > ___ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
