Hi Tom, On Sat, 13 Apr 2019 at 08:09, Tom Herbert <[email protected]> wrote: >
<snip> > > To clarify, I've been thinking about the idea of a smaller SID size > > for IPv6 for a while now (since inserting EHs came up), and thought > > about what would be a generic single size that might suit SR that > > wasn't the same size as an IPv6 address. 32 bits seemed suitable to > > me, although if people wanted bigger, I'd be suggesting 64 bits (not > > entirely coincidentally the common IID size.) > > > > Ron and others have written this draft, which supports SIDS of various > > sizes - 8, 16 or 32 bits - that triggered this discussion. > > > Mark, > > Why not just put a SID length field in the header (like RFC6554 but > more generic). That would allow lengths of 1-16 bytes. More generally, I think it is better to have a single size field that is a "one-size-fits-all" for all foreseeable use cases, and some reasonable overhead to try to cater for future unforeseeable use cases. It is simpler in design, implementation and operation. A major operational issue is created if you happen to underestimate the size you need, and have to go through your network increasing it. For a production network, that sort of project is a bit like what replacing an air plane engine would be like while the plane is flying. The simplest and safest way to avoid a future size upgrade is to pick a single size that far exceeds all likely use cases. Apparently that was the practice with CLNS variable length addresses, where people commonly picked 20 octet addresses regardless, with that practice used to then decide against variable length IPv6 addresses. So people preferred and tended to "one-size-fits-all" addressing anyway when they had a variable length addressing choice. It has been common in RFC1918 addressed networks to universally or near universally use /24s for the same reasons. I think RFC6554's complexity is justified because the links it is operating over are very bandwidth and MTU constrained. More general scenarios don't have those sorts of constraints, and constant technology evolution is also constantly reducing or eliminating them. >Additional > flags could be used to indicate the semantics of the entries. For > instance, they might be actual addresses (128 bits for IPv6, 32 bits > for IPv4), parts of addresses (prefixes of suffixes like in RFC6554) > where the rest of the address can be inferred, indices into a table, > labels, etc. While not addressing the parts of addresses case, the other choice is to encode semantics in the addresses indicating what they're representing and how they should be processed. We already do that in many cases - unicast address scopes and types (Link-Local scope vs global ULA/GUA), and functions such as 6to4 or discard (i.e. 100::/64), and multicast address scopes and multicast forwarding via replication at network junctions itself. Regards, Mark. > > Tom > > > "The IPv6 Compressed Routing Header (CRH)" > > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03 > > > > Regards, > > Mark. > > > > > > > As for trying to use something that already exists, why does SR used a > > > fixed size format for SIDs instead of a variable length format like > > > that described in RFC6554? Similarly, why does SR define it's own TLV > > > format instead of using Hop-by-Hop and Destination Options defined in > > > RFC8200? > > > > > > Tom > > > > > > > It will be perfectly fine to have full proper SRv6 with SRH and LISP or > > > > Vector Routing as an alternative options. I really do not see a room or > > > > need for yet one more mapping plane. What problem does it solve which > > > > would not be already solved elsewhere ? > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > >>> 2) Is there an agreement that solutions which require additional per > > > >>> SR path state in both control plane and now in data plane are really > > > >>> something we should be endorsing here ? > > > >> > > > >> > > > >> I think so. > > > >> > > > >> My understanding of what SR is fundamentally about is to reduce > > > >> control plane state and processing. The trade-off for reduced control > > > >> plane state and processing is to instead carry and encode most or all > > > >> of that information or its semantics as per-packet overhead. > > > >> > > > >> If the per-packet overhead becomes too large and expensive, then > > > >> pushing some of that information and processing back into the control > > > >> plane should be ok, as long as there is still a beneficial overall > > > >> reduction in control plane state and processing. > > > >> > > > >> As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and > > > >> a 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform > > > >> SR in an IPv6 network. > > > >> > > > >> As 32 bit SIDs are also the same size as IPv4 addresses, that may also > > > >> create some opportunities to leverage IPv4 support in existing > > > >> protocols to suite carrying and processing 32 bit SIDs with some, > > > >> possibly slight, modification. For example, perhaps IPv4 Address > > > >> Family support in OSPFv3 (RFC 5838) could be somehow leveraged to suit > > > >> SR. > > > >> > > > >> Regards, > > > >> Mark. > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > [email protected] > > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
