Re: [lisp] [spring] IPv6-compressed-routing-header-crh

[Mark Smith <[e-mail]>]

Hi Tom,

On Sat, 13 Apr 2019 at 08:09, Tom Herbert <[e-mail]> 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
> > > > [e-mail]
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------