Hi Joel, Thanks for bringing up this important point for discussion. In my view there are two aspects into how we evaluate this choice:
* If the information element is not generically applicable to all IPv6 nodes it should ideally not go into a destination option. The IPv6 option space is pretty small and should be used for things that are widely useful to IPv6 nodes. Things that are relevant mainly to SRv6 nodes are best handled using SRH TLVs * I think it is important to avoid duplication of the same information elements using IPv6 destination options and SRH TLVs. This leads to a whole bunch of issues including conflicts, implementation complexity and interop issues (and other potential issues detailed in section 2.3. of RFC5505) So in summary, I fully agree with your assessment of the second obvious choice (“allow any extension that can be carried in a DOH to also be carried in an SRH TLV”) and I don’t think it should be done. Regarding the first obvious choice(“not to allow any extension in the SRH that can be properly handled by a DoH”), I think I feel exactly the opposite should be true. Destination Options need to show wide applicability to IPv6 nodes and not just incidental independence from the contents of SRH. Regards Suresh > On Feb 22, 2023, at 9:36 AM, Joel Halpern <j...@joelhalpern.com> wrote: > > The SPRING WG Chairs have noticed several recent discussions which wound > around to the question of whether specific information belongs in a > Destination Option Header (DOH) before the SHR, or belongs in an SRH TLV. > Clearly there are some pieces of information that are closely tied to the > SRH, such as SRH Authentication information, that belong in the SRH TLV. The > question is discussed here is about information that while tied to the SRH > hops is not tied to the SRH contents. > > There seem to be two obvious answers, but we'd like to hear the WG opinion, > in particular to propose alternatives. > > One obvious alternative would seem to be simply not to allow any extension in > the SRH that can be properly handled by a DoH, and does not depend upon > information in the SRH other than potentially the current DA, which is in the > IPv6 Destination Address field. This provides a clear decision process for > the working group, but some folks have argued it is limiting or inefficient. > > The next obvious choice would seem to be to allow any extension that can be > carried in a DOH to also be carried in an SRH TLV. This seems to lead to a > large number of SRH TLV definitions, complicating implementations and adding > limited value. It should also be noted for this evaluation that RFC 8754 > section 4.3.1.1 and section 4.3.1.1.1 make it clear that processing TLVs at > an SRv6 Hop is optional and subject to local configuration. > > > Does the working group have any suggestions or opinions? > > Thank you, > > Joel, Jim, and Bruno > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
