On Sun, Apr 14, 2019 at 4:55 PM Ron Bonica <[email protected]> wrote: > > Hi Robert, > > > > In order to make the CRH ASIC-friendly, we have the following constraints: > > > > Support only a small handful of SID lengths > If at all possible, make them align on word boundaries > > > > Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should > support a length greater than 32? Is there some length less than 32 that > would be beneficial? > Ron,
I think the term "Compressed Routing Header" is a bit of a misnomer. It's really a "Mapped Routing Header" where the SIDs are presumably smaller that the addresses that they map to. But, mapping requires configuration and state in the network in order for it to work. For instance, if I just want to send a packet to a list of nodes by IPv6 address, it seems like I'd need to use something else besides CRH (or set up a possibly complex control plane that might be overkill for this scenario). We can do that in segment routing since it carries 128 bit addresses, but then that creates giant headers which is what we're trying to avoid in the first place. A compressed format would remove redundant information that can be reconstructed at the hops without additional state beyond what is in the packet. For instance, compressing a list of IPv6 addresses is possible if they all share a common prefix that can be compressed-- which is probably very likely in the closed domains that it seems like source routing is targeted to. Tom > > > Ron > > > > > > > > Juniper Internal > > From: spring <[email protected]> On Behalf Of Robert Raszuk > Sent: Friday, April 12, 2019 6:13 PM > To: Tom Herbert <[email protected]> > Cc: SPRING WG <[email protected]>; [email protected]; Mark Smith > <[email protected]>; Dino Farinacci <[email protected]>; [email protected] > list <[email protected]> > Subject: Re: [spring] IPv6-compressed-routing-header-crh > > > > Hi Tom, > > > > I already suggested this on March 30th ... > > > > "PS. But if you choose to go ahead with CRH I would highly advise to make > your CRH SID a variable length. " > > > > No feedback/response was received from authors. > > > > Thx, > R. > > > > On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <[email protected]> wrote: > > On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <[email protected]> wrote: > > > > Hi Tom, > > > > On Sat, 13 Apr 2019 at 00:26, Tom Herbert <[email protected]> wrote: > > > > > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <[email protected]> wrote: > > > > > > > > Hi Mark, > > > > > > > > > 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. > > > > > > > > > > > > Thank you for describing your understanding of fundamentals of SR. > > > > > > > > I think SR while indeed started with the story of "less control plane > > > > is good for you" now clearly has evolved into not only reduction of > > > > control plane but what can be even more important to some users ability > > > > to request specific behavior via programmed functions of network > > > > elements on a per flow basis without actually per flow or per path > > > > signalling or state. > > > > > > > > Yes for some it may be very useful feature and I am sure some will call > > > > it overload of data plane or . There is no one size fits all. > > > > > > > > With that let's observe that till today SR did not require any new > > > > mapping plane to be distributed in control plane and to be inserted > > > > into data plane. This is clearly a precedent. > > > > > > > > Furthermore as we see in companion documents all additional network > > > > functionality is being taken away from SRH and is being shifted to > > > > Destination Options . > > > > > > > > As far as mapping plane I already pointed out in my Vector Routing > > > > proposal that we have one already it is called BGP. One needs to also > > > > observe that we as industry worked number of years of protocol suite > > > > called LISP allowing not only very good mapping plane, but also data > > > > plane integration. CC-ing lisp authors for their comments. Note also > > > > work for integrating SRv6 with LISP which is already is published. > > > > > > > > Since you correctly observed that now SID can be 32 bit and that is > > > > similar to the size of IPv4 my fundamental question is why not use > > > > something which already exists instead of defining some sort of new > > > > from scratch ? > > > > > > > Robert, > > > > > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you > > > please provide a reference? > > > > > > > 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. 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. > > 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
