Hi Suresh, On Mon, 3 Oct 2022 at 13:42, Suresh Krishnan <suresh.krish...@gmail.com> wrote: > > Hi Mark, > Thanks for your comments. Please find responses inline. > > On Sep 29, 2022, at 8:58 PM, Mark Smith <markzzzsm...@gmail.com> wrote: > > > > On Thu, 29 Sept 2022 at 19:51, Brian Carpenter <brian.e.carpen...@gmail.com> > wrote: >> >> No Gyan, fc00::/7 is not available for carving. fc00::/8 is on reserve for >> the dreamt-of centrally registered ULA prefixes, and fd00::/8 is fully >> committed. >> >> If SRV6 is important, it could justify its own prefix. > > > I think SRv6 must have its own prefix. > > SIDS that are copied into IPv6 addresses in RFC 8986 have a different format, > field names, field semantics and forwarding methods verses previous IPv6 > addressing and forwarding in RFC4291, RFC4193 etc. > > I think the only way to be able to create a new IPv6 address format that has > new and different attributes is to have a new well known prefix for it. > Multicast (FF00::/8), ULA (FC00::/8), Link-Locals (FE80::/10) and > Discard-Only (100::/64) are all examples. > > > Yes. I fully agree with you on all the above points. > > > I'd also suggest a centralised registry for these SRv6 prefixes, or at least > a pseudo random embedded id similar to ULAs, to avoid SRv6 prefix collisions > if SR domains/networks merge. NAT/NPT on SRv6, including on SIDs/IPv6 > addresses in the SRH itself, is not pleasant to think about, nor is > renumbering a well established SID address space/SR domain. > > > I am personally not in favor of a centralized registry or randomized bits > after to provide probabilistic uniqueness (as I do not think these are > expected to be globally routable).
So I'm not suggesting they're to be globally routable. My suggestion is for them to be globally unique, via a central registry or random id, to avoid renumbering if SRv6 networks merge or the temptation to use NAT/NPT to avoid renumbering one of the SRv6 networks when they're merged. There's really two types of address or identifier uniqueness - required uniqueness and operationally convenient uniqueness. These SRv6 addresses aren't required to be globally unique, as they're not intended to be used across the whole of the Internet. However, similar to ULAs, which also aren't routable across the Internet, it would be operationally convenient for them to be globally unique (via central registry or local network random ID) to make merging networks simple. As another example, Ethernet MAC addresses weren't required to be globally unique, as they only need to be unique within the link the NIC is attached to to be able to send frames to other nodes on the link. However, when DEC/Intel/Xerox made them globally unique, allowing them to be burnt in at the factory, we could then conveniently plug NICs into links without having to worry about setting addresses. Very operationally convenient. Regards, Mark. > That said, with my editor hat on, I hope that other WG participants will > chime in and the chairs can determine whether this is the path to go when we > document the operational guidelines for this prefix. > > Regards > Suresh > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
