Looks excellent to me. Thanks Alvaro!! // Zahed
On Wed, 27 Nov 2024 at 17:06, Alvaro Retana <aretana.i...@gmail.com> wrote: > On November 27, 2024 at 3:54:14 AM, Zaheduzzaman Sarker wrote: > > > Zahed: > > Hi! > > ... > > I think the following would be helpful to understand the intention > better . > > it's a suggestion only and should depict what I am after, free to > > amend/reject. > > > > -- The SPRING WG is responsible for protocol-independent general > architecture > > or framework work. The protocol specific modification of, or extension > to the > > existing architecture, data planes, or control or management plane > protocols > > should be carried out in the WGs responsible for the same. Those work > would > > be benefited by coordinating with the spring working group, if necessary, > > those work can be carried out in the SPRING WG after agreement with all > the > > relevant WGs chairs and responsible ADs. -- > > The paragraph with the long sentence talks about avoiding > modifications, while the next paragraph is about scoping. Suggestion: > > OLD> > > The work in the SPRING WG should avoid modification to existing data > planes that would make them incompatible with existing deployments. > Where possible, existing control and management plane protocols must > be used within existing architectures to implement the SPRING > function. Any modification of -or extension to- existing > architectures, data planes, or control or management plane protocols > should be carried out in the WGs responsible for the architecture, > data plane, or control or management plane protocol being modified > and in coordination with the SPRING WG, but may be done in SPRING WG > after agreement with all the relevant WG chairs and responsible Area > Directors. > > The SPRING WG defines procedures that allow an SR node to steer a packet > through an SR Policy instantiated as an ordered list of instructions > called segments without needing per-path state information at transit > nodes. A network comprising only SR nodes can achieve full path > control (through loose or strict path specification). However, SR > nodes must interoperate through loose routing in existing networks. > > > NEW> > > The work in the SPRING WG should avoid modification to existing data > planes that would make them incompatible with existing deployments. > Existing protocols must be used within existing architectures to > implement the SPRING function where possible. Any modification or > extension of existing architectures, data planes, or protocols should > be carried out in the WGs responsible for them and in coordination > with the SPRING WG. Alternatively, after agreement among the relevant > WG chairs and Area Directors, such work may be done in the SPRING WG. > > The SPRING WG defines protocol-independent procedures that allow an SR > node to steer a packet... > > > I simplified the initial paragraph following your suggestions and > added the protocol-independent part to the second one. > > Thoughts? > > > Thanks! > > Alvaro. >
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
