On 18-Oct-21 14:30, Darren Dukes (ddukes) wrote: > Hi Brian, > >> Would it change your examples if you used 2001:db8:a:1100::1 instead? > > No it would not change the examples, any other assignment for loopback > interfaces works the same.
OK, that's helpful. >> Still, using IID == 0 seems to be asking for trouble, since it's a reserved value and is definitely special-cased in some code. Unless, that is, you want exactly the properties described in RFC4291 section 2.6.1 (thanks, Mark Smith). > > As Michael described, this assignment to loopback interfaces works fine. The > addresses are assigned as /128’s, not prefixes, the router subnet anycast concern is not applicable. I'm not sure about that. Is there a risk that ICMP replies sent to such an address might get lost? Standard host stacks identify any such address as a router when they save it in the neighbor cache. My home router declines to answer ICMP pings sent to such an address. (Try pinging fe80::) However, that is not our problem here. On the other hand, it seems that as the compressed SIDs are shifted out one at a time, we will end up with an effective zero IID at the final recipient. So the DA would then be a subnet router anycast address, according to RFC4291. That seems a bit strange and might have unexpected consequences, such as more than one box handling the packet and decapsulating it. Brian > > > > Thanks, > > Darren > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > *From:* Brian E Carpenter <brian.e.carpen...@gmail.com> > *Sent:* Sunday, October 17, 2021 6:15 PM > *To:* Darren Dukes (ddukes); Mark Smith > *Cc:* SPRING WG List; 6man WG; Francois Clad (fclad) > *Subject:* Re: [spring] Question from SPRING regarding > draft-filsfilscheng-spring-srv6-srh-compression > > > > On 18-Oct-21 09:28, Darren Dukes (ddukes) wrote: >> Hi Brian, the draft says: >> >> Loopback interface addresses are allocated from the prefix >> 2001:db8:a::/48. >> >> In the examples 2001:db8:a:1100:: is the IPv6 address assigned to the >> loopback interface of node 11. > > > Still, using IID == 0 seems to be asking for trouble, since it's a reserved > value and is definitely special-cased in some code. Unless, that is, you want exactly the properties described in RFC4291 section 2.6.1 (thanks, Mark Smith). > > Would it change your examples if you used 2001:db8:a:1100::1 instead? > > Brian > >> >> >> >> Darren >> >> >> >> >> >> >> >> On 2021-10-17, 2:06 AM, "ipv6" <ipv6-boun...@ietf.org> wrote: >> >> >> >> Ah, thanks, that's the sort of thing you can only know by knowing it :-). >> Ok, so my question about the examples supplied stands. Using this as a > source address has interesting implications. >> >> Regards, >> Brian Carpenter >> (via tiny screen & keyboard) >> >> >> >> On Sun, 17 Oct 2021, 18:58 Mark Smith, <markzzzsm...@gmail.com >> <mailto:markzzzsm...@gmail.com <mailto:markzzzsm...@gmail.com>>> wrote: >> >> On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter >> <brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com >><mailto:brian.e.carpen...@gmail.com>>> wrote: >> > >> > Thanks for this draft. >> > >> > Question: where you show "Source address 2001:db8:a:1100::" is that >>intended to be the complete address, because it looks like a prefix? I > can't find anywhere that an interface identifier of zero is forbidden, but > it's unusual, and can only exist once in a given subnet. >> > >> >> The IID value of all zeros is the subnet-router anycast address within >> a subnet, and is required. See 2.6.1 of RFC4291. >> >> For example, Linux automatically configures the subnet-router anycast >> address for all prefixes on an interface if the interface is a >> forwarding interface. >> >> [mark@opy ~]$ ip -6 route show table local | grep anycast >> anycast 2403:5803:XXXX:: dev wlp3s0 proto kernel metric 0 pref medium >> anycast fe80:: dev wlp3s0 proto kernel metric 0 pref medium >> [mark@opy ~]$ >> >> (The "local" route table is where the interface address and multicast >> route route table entries are kept in Linux. They don't all show up >> via the normal 'ip addr show' or 'ifconfig' commands). >> >> Regards, >> Mark. >> >> >> > Regards >> > Brian Carpenter >> > >> > On 16-Oct-21 10:55, Francois Clad (fclad) wrote: >> > > Hello Erik, >> > > >> > > >> > > >> > > You may find some examples here: >>https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ >> >><https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/> >> >><https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ >> >><https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/>> >> >><https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ >> >><https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ >> >><https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/>>> >> > > >> > > >> > > >> > > Hope this helps. >> > > >> > > >> > > >> > > Thanks, >> > > >> > > Francois >> > > >> > > >> > > >> > > *From: *spring <spring-boun...@ietf.org >><mailto:spring-boun...@ietf.org <mailto:spring-boun...@ietf.org>>> on behalf >>of Erik Kline <ek.i...@gmail.com <mailto:ek.i...@gmail.com >><mailto:ek.i...@gmail.com>>> >> > > *Date: *Thursday, 14 October 2021 at 19:06 >> > > *To: *Joel M. Halpern <j...@joelhalpern.com <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>> >> > > *Cc: *spring@ietf.org <mailto:spring@ietf.org >><mailto:spring@ietf.org>> <spring@ietf.org > <mailto:spring@ietf.org <mailto:spring@ietf.org>>>, i...@ietf.org > <mailto:i...@ietf.org <mailto:i...@ietf.org>> <i...@ietf.org > <mailto:i...@ietf.org <mailto:i...@ietf.org>>> >> > > *Subject: *Re: [spring] Question from SPRING regarding >>draft-filsfilscheng-spring-srv6-srh-compression >> > > >> > > Joel, >> > > >> > > >> > > >> > > Thank you for your email. The ADs and chairs have been discussing. >> > > >> > > >> > > >> > > One thing that would be very helpful to our discussions would be >>some worked examples of the various C-SID behaviors, showing some SRv6 >>datagrams and what happens to their contents as they move across some suitable example SR domain. >> > > >> > > >> > > >> > > (It would also be helpful if they showed what happens to something >>like >> > an ICMPv6 Echo Request to a representative Destination Address in > these cases when, say, an SRH is not present, i.e. to see when typical > unicast semantics are preserved or when something more like anycast or > multicast behavior is to be expected.) >> > > >> > > >> > > >> > > Assuming some forthcoming helpful examples, we have a goal to get a >>more complete answer back to you by the latter half of next week. >> > > >> > > >> > > >> > > Thanks, >> > > >> > > -Erik >> > > >> > > >> > > >> > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern >><j...@joelhalpern.com <mailto:j...@joelhalpern.com >><mailto:j...@joelhalpern.com>> <mailto:j...@joelhalpern.com >><mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>>> wrote: >> > > >> > > The SPRING working group is in the midst of an adoption call on >> > > >>https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ >> >><https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/> >> >><https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ >> >><https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/>> >> >><https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ >> >><https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ >> >><https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/>>>. >> > > >> > > The SPRING charter has text that is explicit > that modifications to data >> > > planes and architectures standardized by other working groups >>may not be >> > > modified in SPRING unless the chairs and ADs > responsible for that data >> > > plane and / or architecture agree. >> > > >> > > To complete the context, as my SPRING co-chairs are co-authors >>on the >> > > document in question, they have recused themselves from >>decisional >> > > activities regarding the document. Therefore, this message is >> > coming >> > > just from my as the responsible SPRING co-chair managing this >>adoption call. >> > > >> > > As you have seen, multiple questions have been raised about the >> > > relationship of the document to the IPv6 defined data plane and >> > > architecture (particularly RFC 4291 and 8200). In particular the >> > > questions seem to revolve around what the document describes as >>the >> > > NEXT-C-SID flavor of compressed SID, and its > relationship to the IPv6 >> > > standards. (For those seeking more context without reading the >>full >> > > document, a paraphrase and simplification of > the NEXT-C_SID flavor is >> > > provided as a postscript.) >> > > >> > > I raised the question of concurrence as required by the SPRING >>charter >> > > with the Internet ADs and SPRING chairs. > They quite reasonably asked me >> > > to write a note to 6man explaining the concerns as clearly as a can, so >> > > that they can then determine how to proceed. >> > > >> > > The questions that prompted my inquiry are: >> > > >> > > 1) Does the placement of a list of sids in the IPv6 DA field >>change >> > the >> > > IPv6 architectural description of that field. >> > > 2) Does the operation of shifting information around in the IPv6 >> > > destination address field represent a modification or extension >>of the >> > > IPv6 data plane. >> > > >> > > On a related note, the document in question also defines two >>other >> > > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The >> > > NEXT-and-REPLACE-C_SID flavor is defined to include the >>NEXT-C_SID >> > > flavor operation, so seems to be affected by > the same question. >> > > >> > > From my own reading, it appears that the REPLACE-C-SID flavor >> > does not >> > > raise issues requiring 6man leadership concurrence. >> > > >> > > Yours, >> > > Joel M. Halpern for the SPRING working group >> > > >> > > >> > > PS: >> > > Clearly, understanding the question requires > some understanding of what >> > > the NEXT-C_SID flavor does. This > explanation is a simplification for >> > > length and context. Really, the best place to understand it is the >> > > draft. However, to give you enough information to let you decide >> > > whether you care, I will try to provide a fair summary. My >>apologies in >> > > advance to the authors for necessary liberties for length. Also, >> > > discussion of the draft contents (as distinct from the interaction with >> > > the IPv6 data plane and architecture) belongs on the SPRING list, and >> > > should not clutter up 6man. >> > > >> > > SIDs are the identifiers used in segment routing. >> > > In SRv6, as document in the current RFCs, these are 128 bits. >> > As >> > > defined in the relevant RFCs, SIDs which identify endpoints to which >> > > packets are directed are identified by endpoint SIDs. These can >>have >> > > behaviors (decapsulate and forward is one example). They can >>have >> > > flavors such as where the SRH is removed. >> > > >> > > The topic under discussion is means to compress these SIDs in the >> > > packets on the wire. The document under discussion provides >>three >> > > flavors of compression. >> > > >> > > The fundamental mechanism of the draft is to > use a single SRH entry >> > as a >> > > container for multiple SIDs. In the NEXT-C_SID mechanism, when >>it is >> > > first encountered the entire container is copied into the >>desination >> > > address of the IPv6 packet. The container has a common routing >>prefix >> > > used for all the NEXT-C-SID SIDs. It is followed by a sequence >>of >> > > compressed SIDs of a configured length. > One could configure 16, 24, or >> > > 32 bits. Or whatever length. The > routing advertisements >> > are arranged >> > > so that the IPv6 packet is directed to the node represented by the first >> > > compressed SID on the basis of longest prefix match matching the >> > > combination of the common routing prefix and > that compressed SID. >> > > >> > > When the packet arrives at that node, it looks up the configured >> > > portion, the compressed SID, and determines the behavior and flavor. In >> > > the case of the NEXT-C-SID flavor, the resulting operation is to >>shift >> > > the entire remaining contents of the IPv6 address (the bits past >>the >> > > first compressed sid) so as to over-write the first compressed >>SID. 0 >> > > bits are shifted into the low order positions. If the result is >>a >> > > non-zero new first compressed SID, then the packets is forwarded >>and the >> > > process repeats. When all that is left > are 0s, if there is an >> > SRH, it >> > > is consulted to find the next SRH entry, which is, per normal >>SRv6 >> > > processing, put into the IPv6 DA. >> > > Note that in the common case where the SIDS needed all fit in to a >> > > single container, the analysis also assumes the use of the >>reduced >> > > encapsulation options which omits the SRH that is not needed as >>it would >> > > have no entries. This the packet contains a normal IPv6 header, >>with a >> > > sequence of compressed SIDs (what one might or might not call a >>source >> > > route) in the IPv6 destination address field. >> > > >> > > PPS: If the authors of the NEXT-C-SID flavor > feel I have mis-represented >> > > the work, please, send clarifications or corrections. Again, >>the best >> > > source of information is the draft itself. I was asked to >>provide extra >> > > context in this email. >> > > >> > > _______________________________________________ >> > > spring mailing list >> > > spring@ietf.org <mailto:spring@ietf.org >><mailto:spring@ietf.org>> <mailto:spring@ietf.org <mailto:spring@ietf.org >><mailto:spring@ietf.org>>> >> > > https://www.ietf.org/mailman/listinfo/spring >><https://www.ietf.org/mailman/listinfo/spring> > <https://www.ietf.org/mailman/listinfo/spring > <https://www.ietf.org/mailman/listinfo/spring>> > <https://www.ietf.org/mailman/listinfo/spring > <https://www.ietf.org/mailman/listinfo/spring > <https://www.ietf.org/mailman/listinfo/spring>>> >> > > >> > > >> > > -------------------------------------------------------------------- >> > > IETF IPv6 working group mailing list >> > > i...@ietf.org <mailto:i...@ietf.org <mailto:i...@ietf.org>> >> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >><https://www.ietf.org/mailman/listinfo/ipv6> >><https://www.ietf.org/mailman/listinfo/ipv6 >><https://www.ietf.org/mailman/listinfo/ipv6>> >> > > -------------------------------------------------------------------- >> > > >> > >> > _______________________________________________ >> > spring mailing list >> > spring@ietf.org <mailto:spring@ietf.org <mailto:spring@ietf.org>> >> > https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring> <https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>> >> > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
