If it helps in clarifying updating the definitions may be in order. Anyway it seems more logical that an (IP) interface is defined by its address than the other way around. But I do not know the original intention of the text.
I'm not sure I understand your point regarding many functions on many nodes. Isn't that the case only in combination with the SRv6 functions that are applied the 128-bit entity? And even then it only points to one function on one node at a time? cheers, Eduard On Thu, Oct 7, 2021 at 9:35 PM Ron Bonica <rbon...@juniper.net> wrote: > > > Inline [RB] > > > > Ron > > > > > > Juniper Business Use Only > > *From:* Eduard Metz <etm...@gmail.com> > *Sent:* Thursday, October 7, 2021 5:03 AM > *To:* Ron Bonica <rbon...@juniper.net> > *Cc:* 6...@ietf.org; SPRING WG <spring@ietf.org> > *Subject:* Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 > > > > *[External Email. Be cautious of content]* > > > > > > Can the SID be viewed as the address of the "interface" to, in this case, > the function that resides in a node? From a routing / forwarding point of > view the group of functions is more similar to a network (represented by a > prefix, rather than a single address), but still. > > > > [RB] In RFC 8986, a classic SRv6 SID represents a **single** function > that resides on a **single** node. If you like, you can even say that > represents a **single** interface to a **single** function that resides > on a **single** node. > > > > By contrast, a Compressed SID Container (i.e., the 128-bit entity that is > copied into the IPv6 Destination Address field) represents an entire SR > Path. Specifically, it represents **many** functions that reside on * > *many** nodes > > > > > > For my understanding, apart from that the (definition of) SID may not be > aligned with the literal text in below RFCs, what is the real problem? Are > there any protocols that specifically rely on this definition of an IPv6 > address? > > > > [RB] We don’t know if there are any protocols that rely on this definition > of the IPv6 address. And if we don’t update RFC 4291 before violating it, > we don’t know if anybody might write such an application in the future. > > > > > Ron > > > > > > cheers, > > Eduard > > > > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
