Hi Tom, It is not related to CSID. Because it is not important how IP address is prepared, it should be IP address at the time of writing to DA field. And it is.
You are asking more general question: what was the legal reason to treat IPv6 address as LOC:FUNCT:ARG? Sorry, but it is a little bit late – RFC 8986 is already published. Eduard From: Tom Herbert [mailto:t...@herbertland.com] Sent: Friday, October 8, 2021 5:47 PM To: Vasilenko Eduard <vasilenko.edu...@huawei.com> Cc: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>; Eduard Metz <etm...@gmail.com>; SPRING WG <spring@ietf.org>; 6MAN <6...@ietf.org> Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 On Fri, Oct 8, 2021 at 1:38 AM Vasilenko Eduard <vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com>> wrote: > > Ø 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 > > > > But CSID is not an IP address, right? Why IP address rules should be > applicable to CSID? > Eduard, If the protocol is copying the CSI into the IPv6 Destination address the CSI MUST be an IP address because the Destination Address field in an IPv6 packet *contains* an IPv6 address. Overloading fields in the IPv6 header with other data would be non-conformant with the IPv6 standard (not just addresses, see the several attempts to structure flow label for instance). Frankly, this is one thing that I have found troubling with SrRv6. Sometimes it is portrayed as an alternative, shadow protocol to IPv6 that just happens to use the IPv6 protocol format for convenience instead of creating a new L3 protocol for its purposes. The rationalization for this seems to be that SRv6 is confined to limited domains, and within a limited domain we can safely redefine standard protocols in arbitrary ways-- note, there is no consensus that that philosophy is acceptable. Tom > > > From: ipv6 [mailto:ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>] On > Behalf Of Ron Bonica > Sent: Thursday, October 7, 2021 10:36 PM > To: Eduard Metz <etm...@gmail.com<mailto:etm...@gmail.com>> > Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; > 6...@ietf.org<mailto:6...@ietf.org> > Subject: RE: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 > > > > > > Inline [RB] > > > > Ron > > > > > > Juniper Business Use Only > > From: Eduard Metz <etm...@gmail.com<mailto:etm...@gmail.com>> > Sent: Thursday, October 7, 2021 5:03 AM > To: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>> > Cc: 6...@ietf.org<mailto:6...@ietf.org>; SPRING WG > <spring@ietf.org<mailto: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 > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org<mailto:i...@ietf.org> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
