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>
To:Robert Raszuk <rob...@raszuk.net>;Tom Herbert <t...@herbertland.com>
Cc:spring <spring@ietf.org>;6man <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>
Sent: Saturday, September 7, 2019 5:54 PM
To: Tom Herbert <t...@herbertland.com>
Cc: Ron Bonica <rbon...@juniper.net>; spring@ietf.org; 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
