On 20-Oct-21 05:02, Tom Herbert wrote: > > > On Tue, Oct 19, 2021, 12:10 AM Mark Smith <markzzzsm...@gmail.com > <mailto:markzzzsm...@gmail.com>> wrote: > > Hi Brian, > > On Tue, 19 Oct 2021 at 15:51, 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. > > > > So I'm guessing you're probably thinking of a router as a physical > device (as most of us will by default), rather than as routing as a > function. > > RFC8200 definitions: > > "router a node that forwards IPv6 packets not explicitly > addressed to itself. (See Note below.) > > host any node that is not a router. (See Note below.)" > (the note is about hosts having multiple interfaces) > > (A node doesn't have to be a device, and a device doesn't have to be > physical, so the above are really function descriptions.) > > If a router as a physical device has IPv6 addresses that are sent to > the device itself, then the router as a physical device is also > performing host functions. For packets with those "router addresses", > the router as a physical device is not "forward[ing] IPv6 packets not > explicitly addressed to itself. " > > In a router as a physical device, the forwarding plane is performing > the router function above. In a router as a physical device, the > "control plane" (really just a fancy name for a host) is performing > host functions on packets that are directly to and from it (BGP, OSPF, > SSH, SNMP etc. packets). > > The consequence is that all IPv6 addresses are host addresses, and all > processing of packets at the device that holds a packet's DA is host > processing of the packet. > > It is the same in IPv4 - from RFC791, "The internet protocol provides > for transmitting blocks of data called datagrams from sources to > destinations, where sources and destinations are hosts identified by > fixed length addresses." > > So these packets with CSID rotating IPv6 DAs are being host processed > by the router (as a device), after the forwarding plane in the router > (as a device) has forwarded the packet to the colocated host function. > > (A more practical example to support the above observation. If a > router as a device is bought from a router vendor, and then is run as > a BGP route reflector, meaning it is never in a packet forwarding > path, and therefore never "forwards IPv6 packets not explicitly > addressed to itself" is the router device still a router? Functionally > no, it is a host, even though it looks like a router (as a device).) > > > Mark, > > On the other hand, when a node is processing a routing it header it does > forward packets addressed to it self (but not being the final destination). > Processing a router header is intuitively router functionality and not host > functionality. The RFC8200 definition of host and router don't seem to > consider routing headers, perhaps this should be amended to say that a host > is the final destination of the packet.
That is the case even if the host is also a router and if it recognises the DA of a packet delivered to it in its role as a router as a DA that it handles in its role as a host. (In Linux jargon, that means "if the DA is assigned to its loopback interface", but that is an implementation detail.) The point here is that the *previous* router doesn't know that the DA is assigned that way; it just forwards the packet to whoever announced the longest-matching prefix. It *does not* send the packet to DA. Brian > > Tom > > > Regards, > Mark. > > > 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> > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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
