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

[Tom Herbert <[e-mail]>]

On Fri, Apr 19, 2019, 5:54 PM Greg Mirsky <[e-mail]> 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 <[e-mail]> wrote:
>
>> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <[e-mail]>
>> wrote:
>> >
>> > Hi Tom,
>> >
>> > On Sat, 13 Apr 2019 at 00:26, Tom Herbert <[e-mail]> wrote:
>> > >
>> > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <[e-mail]>
>> 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
>> > > > [e-mail]
>> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > > > --------------------------------------------------------------------
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>