Hi Daren, thank you for responding to my question. Is 64-bits routable prefix in the DA an implicit prerequisite of the C-SID solution?
As to my question about what Brian referred to as a "funny" part. In Section 6 we read: The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. and then: The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are 16, 32 or 48 bits. Now, it seems to me that there are many possibilities of getting the "funny" part of C-SID into a routable space of the DA. For example, an operator, following the recommendation of the C-SID specification, uses 16-bit NEXT-C-SID in combination with, for example, 32 bits block size. As a result, 16 bits of "funny" part, i.e., another NEXT-C-SID, are in the routable space. Am I missing something? Thank you for your consideration. Regards, Greg On Thu, Oct 21, 2021 at 10:06 PM Darren Dukes (ddukes) <ddu...@cisco.com> wrote: > Hi Gyan and Greg. > > Gyan I’m sorry but i don’t see a question in your email. I’ll go back to > Greg. > > While I’m not exactly sure what is being asked, I will say that Brian is > correct for every Srv6 SID behavior (not just csid flavors) when he says > the following about their arguments (lowest 64 bits in the ipv6 Dest addr. > > “They are invisible to routing (which is done based on the prefix) and > invisible to neighbor discovery (because it never happens).” > > I hope this helps. > > Darren > > ------------------------------ > *From:* Gyan Mishra <hayabusa...@gmail.com> > *Sent:* Thursday, October 21, 2021 7:03 PM > *To:* Darren Dukes (ddukes) > *Cc:* Brian E Carpenter; Greg Mirsky; i...@ietf.org; spring@ietf.org > *Subject:* Re: Typo correction Re: Question from SPRING regarding > draft-filsfilscheng-spring-srv6-srh-compression > > > > Hi Darren > > What Greg is asking is if the SID is a prefix SID End and not adjacency > SID End.x, so now the common prefix is needed to ECMP steer the flow to > the prefix SID which uses the common prefix, which may in this case be > mutated due to shifting of SIDs in GSID container. > > > Kind Regards > > Gyan > On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) <ddukes= > 40cisco....@dmarc.ietf.org> wrote: > >> Hi Greg, >> >> >> >> Your question is not clear to me. >> >> Can you try to restate it with the flavors and behaviors from the draft >> in question? >> >> >> >> Darren >> >> >> >> On 2021-10-20, 4:15 PM, "ipv6" <ipv6-boun...@ietf.org> 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> 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/. >> >> >> >> >> >> >> 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 >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> > >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> i...@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> i...@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347 * > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
