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? 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
