Dear Tom, > The most obvious difference, besides SID size, is that SRV6 contains > TLVs and SRV6+ doesn't.
I was hoping you know that this is not true at all so I skipped commenting on that aspect. Folks promoting SRv6+ are smart and they know how to sell stuff which looks simple and innocent on the surface like concept of CRH with just fixed label/sid list while hide all complexity under the deep cover and only show little corners of it here and there hoping no one will connect the dots. So what you call "complexity" has been just moved from routing header to destination options header and will be defined in number of different documents piece by piece. Just please take a look at the proposal describing per path service instructions encoding. It does have Type Length and Value so to me looks like TLV structure going into IPv6 header. 4 <https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06#section-4>.. The PPSI Option The PPSI Option contains the following fields: o Option Type: 8-bit selector. PPSI option. Value TBD by IANA. (Suggested value: 144). See Note below. o Opt Data Len - 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 4. o PPSI identifier - (32-bit selector). Identifies a PPSI. REF: https://tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06 That TLV value comes from Destination Options and Hop-by-Hop Options registry which effectively is already full. It is 8 bit register with 3 first bits taken for identification so remaining are 5 bits. Now from that remaining 5 bits (32 values) only 5 values are left for allocation. https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml So they noticed that and just at the last rev of the VPN extenstion renamed what originally was called *VPN Context Information Option* to PPSI as it was very obvious that with 5 remaining values there is no room for new types for other service instructions. Now the plan is to nest under PPSI TLV in a sub-TLV format any potential new service instructions. Now I will leave it as the exercise for the reader to judge which approach is more complex. Is it to put the cards on the table and play open by clearly defining SRv6 SRH with SIDs and functions or to play such poker with IETF WGs ? Thx, R. On Sat, Sep 7, 2019 at 11:19 PM Tom Herbert <t...@herbertland.com> wrote: > Robert, > > You've chosen to selectively comment on only parts of what I wrote, > not the main thesis which is that SRV6 packet format is more complex > than SRV6+. > > The most obvious difference, besides SID size, is that SRV6 contains > TLVs and SRV6+ doesn't. I don't believe that this was ever needed, HBH > and destination already exist in RC8200 and could have been used as > they will be in SRV6+. Similarly, AH could have been used instead of > defining SR specific HMAC. Furthermore, several implementations of > SRV6 are listed in draft-ietf-6man-segment-routing-header-22; all > except one have the words "no TLV processing". The exception is Linux, > which doesn't not implement SR TLVs per the standard and wouldn't > interoperate with an implementation that is conformant (I have looked > at the Linux code and in fact have suggested a fix). So the claim that > SRV6 is mature and deployed is suspect considering there doesn't seem > to be proper support for TLVs which is a major part of the protocol. > > Based on this analysis, I believe my statement that SRV6 format is > more complex than SRV6+ is factual. It's my opinion that SRV6, > particularly because of TLVs, is overly complex. > > Tom > > > On Sat, Sep 7, 2019 at 10:54 AM Robert Raszuk <rob...@raszuk.net> wrote: > > > > > > > It doesn't depend on extension header insertion > > > > Nothing depends on extension header insertion ... SRH insertion is an > optional optimization. > > > > > and there's no need to have multiple routing headers in the same > packet. > > > > Really ? > > > > If I am doing SRv6+ in my network for TE and want to to do TI-LFA how > would I not end up with 3 IPv6 fixed headers and two Dest Option EHs and > two CRH EHs in the packet under protection ? > > > > But this is just tip of the ugliness iceberg ... > > > > All required extensions to protocols developed in to name just a few > already proposed by SRv6+ authors: IDR, LSR, BESS and 6MAN WG to support > the new mapping (which is other then nomenclature close to SR-MPLS mapping) > will require real development resources. > > > > OAM in spite of few claims from Ron that "just works" is not addressed > and does require even more extensions. > > > > Then last I will not be able to use SRv6+ for my deployment needs in the > global IPv6 overlay I am running simply that within my overlay I do not > plan to run any control plane. Underlay basic reachability provided by > third parties is all I need to construct optimal paths. So any protocol > which requires new signalling to distribute mapping is non starter. > > > > At the end we should learn from others ... (hint SDWANs) and avoid > mistakes of the past (hint: LDP). > > > > Many thx, > > R. > > > > > > > > > > > > > > > > > > On Sat, Sep 7, 2019 at 6:41 PM Tom Herbert <t...@herbertland.com> wrote: > >> > >> On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica > >> <rbonica=40juniper....@dmarc.ietf.org> wrote: > >> > > >> > Folks, > >> > > >> > > >> > > >> > We have explored many facets of SRv6 and SRv6, sometime passionately.. > I think that this exploration is a good thing. In the words of Tolkien, > “All who wander are not lost.” > >> > > >> > > >> > > >> > But it may be time to refocus on the following: > >> > > >> > > >> > > >> > For many operators, SRv6 is not deployable unless the problem of > header length is addressed > >> > Many objections the uSID proposal remain unanswered > >> > SRv6+ offers an alternative solution > >> > > >> > > >> > > >> > Given these three facts, I think that it would be a mistake to > discontinue work on SRv6+. > >> > > >> + 1 > >> > >> I'd suggest a fourth fact. The packet format of SRv6+ is much simpler > >> than SRv6 and the protocol works better with existing mechanisms and > >> protocols of IPv6 like Destination and HBH options, as well as AH. It > >> doesn't depend on extension header insertion and there's no need to > >> have multiple routing headers in the same packet. > >> > >> Tom > >> > >> > >> > > >> > > >> > > Ron > >> > > >> > > >> > > >> > > >> > Juniper Business Use Only > >> > > >> > -------------------------------------------------------------------- > >> > IETF IPv6 working group mailing list > >> > i...@ietf.org > >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> > -------------------------------------------------------------------- > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
