I agree to make the SID align on word boundaries but I am thinking the software should have hardware independence if at all possible.
I think 32 bit is a reasonable size. Gyan S. Mishra IT Network Engineering & Technology Consultant Routing & Switching / Service Provider MPLS & IPv6 Expert www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT Mobile – 202-734-1000 Sent from my iPhone > On Apr 14, 2019, at 7:54 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 > > > > 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 > > > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
