Agree with Jingrong. Suddenly, I am thinking about a question: Does SRv6+ bring new value to the networking beyond SRv6? What's the purpose? To compress the Routing header? Then we have many options to do that. Why a new RH with brand new routing scheme?
Let's do the standard works together once again, another 5 years? No! I think we should solve the problem based on the existing solution, instead of creating a new mechanism. >From the aspect of information theory, what's the new info added by SRv6+? >What is that for? These are the questions should be answered. If we would like to provide an efficient encoding format, that is all right.. Please don't compare the length of RH only, since the length of DOH TLVs should be counted as well. BTW, we already have C-SID, uSID and I believe there may be more options. I don't think moving info from SRv6 SIDs to DOH TLVs is a good choice. Bad Performance of processing TLVs in DOH, and terrible scalability since only 5 reserved types, or the 37 types when the CHG bit is reused. Also, how many bytes can be reduced by CRH. If you compare with C-SID, you will be surprised that C-SID provides a more efficient encoding mechanism for SRv6 than CRH. The first DOH works for the destinations encoded in RH does not mean the info CAN NOT be carried in RH for per-segment processing. How about let's focus on how to reduce the overhead of SRv6, that will be very helpful. Best Regards, Cheng From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Xiejingrong Sent: Sunday, September 08, 2019 8:55 AM To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org>; Robert Raszuk <rob...@raszuk.net>; Tom Herbert <t...@herbertland.com> Cc: spring <spring@ietf.org>; 6man <6...@ietf.org> Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+ the CHG bit is meaningful of hop-by-hop options, but is totally meaningless for Destination options. CHG is meaningful for both. Also I think the use of unique last-5bits of option is just a week recommendation. There is still enough space of 8bit if needed. It's not necessary to change interpretation of CHG. Thanks Jingrong From:Ron Bonica <rbonica=40juniper....@dmarc.ietf.org<mailto:rbonica=40juniper....@dmarc.ietf.org>> To:Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>;Tom Herbert <t...@herbertland.com<mailto:t...@herbertland.com>> Cc:spring <spring@ietf.org<mailto:spring@ietf.org>>;6man <6...@ietf.org<mailto:6...@ietf.org>> Date:2019-09-08 06:32:00 SubjectRE: [spring] Regaining Focus on SRv6 and SRv6+ Robert, You may need to rethink your argument. (That is, except for the part where you said that I was smart!) The SRv6+ PPSI does replaces something int SRv6. But it does not replace the SRH's tags, flags or TLVs. It replaces the low order bits in the last SID.. More specially, it identifies a function to be executed by SR egress node.. It replaces functions like END.DT4, END.DT6, END.DX4, END.DX6, etc.) As Tom says, the CRH is much simpler to parse that the SRH. It contains only five fields, four of which are mandated by RFC 8200. (The other is the SID list.) Unlike TLVs, the PPSI is fixed length (32 bits). It identifies an instruction to be executed on the SR egress node. Carries the same information as an MPLS service label or the low order bits of the final SID in as SRv6 SID list. What you say about the IPv6 Option registry being nearly full may be a bit of an exaggeration. This is because the CHG bit is meaningful of hop-by-hop options, but is totally meaningless for Destination options. So, for destination options, the IPv6 option registry is actually 6 bits wide. Ron From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Sent: Saturday, September 7, 2019 5:54 PM To: Tom Herbert <t...@herbertland.com<mailto:t...@herbertland.com>> Cc: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>; spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org> Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+ 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://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06*section-4__;Iw!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9VJXmGie$>. 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<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-vpn-dest-opt-06__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9dfFF-MI$> 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<https://urldefense.com/v3/__https:/www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9V9FULVl$> 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<mailto: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<mailto: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<mailto:t...@herbertland.com>> wrote: >> >> On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica >> <rbonica=40juniper....@dmarc.ietf.org<mailto: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<mailto:i...@ietf.org> >> > Administrative Requests: >> > https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9RFWajEZ$> >> > -------------------------------------------------------------------- >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org<mailto:spring@ietf.org> >> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!S9X3wTIFHuThdbtX6z4bKoc7xE6NlkGRvw9k43j_eioOgUMzYf2E8HKI9YjolzkW$> Juniper Business Use Only
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
