Greg, I would much prefer that one of the SRv6 experts answers that question.
Regards Brian On 21-Oct-21 09:13, Greg Mirsky wrote: > Hi Brian, > I've got some questions about what you've said: > > For that reason, the fact that the bottom 64 bits in the > > "address" look funny or change is simply irrelevant. They are > invisible to routing (which is done based on the prefix) > and invisible to neighbor discovery (because it never happens). > > As I understand it, what you describe is the case of a strict explicit path > defined using one of the C-SID compression methods. But I am not sure that > your conclusion also always applies when it is a loose explicit path > specified in the compressed Segment List. As all C-SIDs share the same prefix, how routing can be done based only on that prefix and not using a part of that "funny" bottom 64 bits? And if any part of the bottom 64 bits must be used, how one can guarantee that CIDR still works in that domain? > > Regards, > Greg > > On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter > <brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>> wrote: > > Hi, > > After reading a lot of messages, I'm going to offer my considered > opinion as a direct response to Joel's OP. > > Firstly, I don't believe that in the end this draft raises any > concerns that are *significantly* different than those raised > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 > of RFC 8754 explains that SIDs of any shape or size are only > meaningful within an SR domain. That applies to srh-compression > too. > > Secondly, I was concerned about how these strange looking > "addresses" would potentially interfere with normal IPv6 > addresses and their handling by normal IPv6 nodes. Well, I > now believe that they won't. The reason is that in the SR model > these "addresses" are *never used for final delivery of IPv6 > packets to a host.* All SRv6 participants are routers. The > last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: > is *not* the last hop on a LAN, mediated by neighbor discovery > for 2001:db8:a:1900::. It's just a hop from one router to another, > using the entry for 2001:db8:a:1900::/64 in the FIB of the last > router that actually forwards the packet. 2001:db8:a:1900:: is > not assigned to a physical interface so RFC 4861 is never invoked. > > Another way to say it is RFC 7608 is the relevant architectural > standard. CIDR rules, even within an SR domain. > > For that reason, the fact that the bottom 64 bits in the > "address" look funny or change is simply irrelevant. They are > invisible to routing (which is done based on the prefix) > and invisible to neighbor discovery (because it never happens). > > I apologise if this is all obvious to everybody, but I needed > to spell it out for my own understanding. > > Now back to Joel's questions: > > > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > There is a typo in the below which if not understood as a typo would be > > > quite confusing. I wrote that I raised the issue with > > "with the Internet ADs and SPRING chairs". > > That should have read "with the Internet ADs and 6man chairs". > > The SPRING co-chairs are recused, and the charter requirement leads to > > the 6man chairs. Which is who I talked to. > > > > Also, I am sending a courtesy copy to the routing ADs, which I should > > have done originally. > > > > Thank you and enjoy. > > Yours, > > Joel > > > > On 10/12/2021 11:52 PM, Joel M. Halpern 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/>. > >> > >> > >> 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. > > I think it should be noted explicitly somewhere that since the contents > of the DA field are *never* used for last-hop neighbor discovery, > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 > are irrelevant. Another citation is RFC 7608: for routing, all that > counts is the prefix, and it can be anything up to 128. > > Perhaps this should have been in section 5 of RFC 8754, but I leave > that to the wordsmiths. > > >> 2) Does the operation of shifting information around in the IPv6 > >> destination address field represent a modification or extension of the > > >> IPv6 data plane. > > No. As my text above indicates, the SRv6 DA field is only ever used > by routing, where RFC 7608 rules. And of course it vanishes as soon > as the packet is decapsulated. > > Regards > Brian > > >> > >> 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. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > i...@ietf.org <mailto:i...@ietf.org> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > <https://www.ietf.org/mailman/listinfo/ipv6> > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org <mailto:i...@ietf.org> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6> > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
