On Fri, Apr 19, 2019, 5:54 PM Greg Mirsky <[email protected]> wrote:
> Hi Tom, > in draft-mirsky-6man-unified-id-sr > <https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-02> we've > proposed the use of 20 and 32 bits-long SIDs in SR EH. Two bits-long field > also defined in the Flags to identify the length of SID element in the SR > EH: > 0b00 - 128-bits SID; > 0b01 - 20-bits SID; > 0b10 - 32-bits SID > 0b11 - reserved for future use. > Hi Greg, 20 bit fields in a list seems a little odd; how is this packed in a packet? It's more typical to have byte alignment at least and if the fields hold numerical values they would usually be bytes, words, double words, etc. with natural alignment maintained. In a two bit representation of length, I think best possibilities are 16, 32, 64, and 128 bits. Tom > Much appreciate your comments on that draft, suggestions. > > Regards, > Greg > > > On Fri, Apr 12, 2019 at 3:09 PM 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 >> > > > -------------------------------------------------------------------- >> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
