Re: [spring] Chair Review of draft-ietf-spring-srv6-srh-compression-11

Hey Tony,

Perfect point ... so look at section 3 of IETF STD:
https://datatracker.ietf.org/doc/html/rfc8754

With that please kindly indicate in what respect the subject draft does not
comply ?

Observe that RFC8754 was approved and published after RFC8200

Any more discussions on IETF STD violation ?

Cheers,
Robert

On Tue, Mar 26, 2024 at 6:33 PM Tony Przygienda <tonysietf@gmail.com> wrote:

> Robert, please do read the according draft with the explanation of this
> being completely optional and freely mixable with "SRv6 is IPv6 kind of"
> mode  ...
>
> And let's stick to basic technical sanity and IETF STD documents being
> standards that cannot be violated by following documents lest they be not
> standards at all rather than calling the usual deities of exigency to
> justify any transgression committed or prepared to be committed. There is
> no statute of limitations on STD documents or security/operational impact.
> Rather, debt incurred in technology tends to accumulate over years
> mercilessly.
>
> --- tony
>
> On Tue, Mar 26, 2024 at 6:24 PM Robert Raszuk <robert@raszuk.net> wrote:
>
>> Ron,
>>
>> While I did suggest the use of new Ethertype for SRv6 in the very early
>> days the killer and valid argument against it was ease of deployment. An
>> equally valid argument was built in the extensibility of IPv6 protocol.
>>
>> So we see the latter is an interesting one, but let's zoom on the former.
>>
>> In a 1000 node network, if I want to enable SRv6 only on subset of nodes
>> (which in many cases is sufficient for a lot of TE purposes)  I need to
>> upgrade only those affected nodes leaving all other nodes just doing basic
>> vanilla IPv6.
>>
>> If for SRv6 encapsulation new Ethertype is used all 1000 nodes need to be
>> upgraded. It will be worse then transition to IPv6 as you will then say -
>> Oh Mr. Customer ... do you really need to upgrade your entire network and
>> spend millions doing it - just stick to SR-MPLS :) And I know you would
>> love to do that.
>>
>> So I think like others say .. The ship has hit the waters. You have a
>> choice to jump on it or stay on the shore.
>>
>> Cheers,
>> Robert
>>
>>
>> On Tue, Mar 26, 2024 at 6:14 PM Ron Bonica <rbonica@juniper.net> wrote:
>>
>>> Working Group,
>>>
>>> Might  SRv6 progress much more quickly if we did the following:
>>>
>>>
>>>    - Divorce SRv6 from IPv6
>>>    - Give SRv6 its own ethertype
>>>    - Let SRv6 progress along its own evolutionary trajectory,
>>>    unencumbered by IPv6 restrictions
>>>
>>>
>>> At very least, this divorce would end the long and painful debates
>>> regarding IPv6 compliance. And would it give SRv6 more degrees of freedom
>>> as it evolves,
>>>
>>> As far as I can see, the only benefit of binding SRv6 to IPv6 is in the
>>> expectation that IPv6-enabled hardware won't have to change too much to
>>> support SRv6. This benefit might still be realized if SRv6 doesn't deviate
>>> too much from IPv6.
>>>
>>> My question is not rhetorical. Maybe I am missing something, but is
>>> there any real benefit in continuing to bind SRRv6 to IPv6?
>>>
>>>                                                            Ron
>>>
>>> Juniper Business Use Only
>>> ------------------------------
>>> *From:* Tom Herbert <tom@herbertland.com>
>>> *Sent:* Monday, March 25, 2024 3:40 PM
>>> *To:* Alvaro Retana <aretana.ietf@gmail.com>
>>> *Cc:* Robert Raszuk <robert@raszuk.net>; Andrew Alston - IETF
>>> <andrew-ietf@liquid.tech>; Ron Bonica <rbonica@juniper.net>;
>>> spring@ietf.org <spring@ietf.org>; Joel Halpern <jmh@joelhalpern.com>
>>> *Subject:* Re: [spring] Chair Review of
>>> draft-ietf-spring-srv6-srh-compression-11
>>>
>>> [External Email. Be cautious of content]
>>>
>>>
>>> On Mon, Mar 25, 2024 at 12:31 PM Alvaro Retana <aretana.ietf@gmail.com>
>>> wrote:
>>> >
>>> > Tom:
>>> >
>>> > Hi!
>>> >
>>> > I understand your point.
>>> >
>>> > I put the option out there because it came up at last week’s spring
>>> meeting and it should be discussed.
>>>
>>> Alvaro,
>>>
>>> This seems to come back to the fundamental question: is SRv6 still
>>> IPv6 or is it a new protocol. If it's IPv6 then it should adhere to
>>> all the requirements and expectations of IPv6, if it's a new protocol
>>> that is going to diverge from the standard IPv6 then maybe it needs
>>> its own EtherType and standards development path.
>>>
>>> Tom
>>>
>>>
>>> >
>>> > Thanks!
>>> >
>>> > Alvaro.
>>> >
>>> >
>>> > On March 25, 2024 at 2:58:48 PM, Tom Herbert (tom@herbertland.com)
>>> wrote:
>>> >
>>> > On Mon, Mar 25, 2024 at 11:17 AM Alvaro Retana <aretana.ietf@gmail.com>
>>> wrote:
>>> > >
>>> > > FWIW, I agree with most of what Joel wrote. ;-)
>>> > >
>>> > > I see another path forward: Given that the issue is constrained to
>>> an SR domain, the draft could also point out the issues as
>>> operational/deployment considerations. Operators can then make an informed
>>> decision on whether they want to/can use C-SIDs without an SRH in their
>>> network. This path forward (or leaving it out of scope, as Joel suggests
>>> below) is something the spring WG can reach consensus on by itself (i.e.,
>>> without needing to consult or agree with other WGs).
>>> >
>>> > Alvaro,.
>>> >
>>> > This wouldn't be robust and would seem to violate the "be conservative
>>> > in what you send clause". Punting this to the operators doesn't seem
>>> > practical either, in an even moderately large network they wouldn't be
>>> > able to know all the potential problems they might hit in devices.
>>> > They're about one misconfiguration away from having to debug a rather
>>> > unpleasant problem. For instance, if operator gets a packet trace from
>>> > a router they would see a whole bunch of packets with bad checksums,
>>> > but they would have no way of knowing if these were cases of segment
>>> > routing or actually corrupted packets.
>>> >
>>> > Tom
>>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>