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

[Joel Halpern <[e-mail]>]

The WG LC has not been closed because it is clear that the discussion of 
issues is ongoing.  Declaring a conclusion seems to this chair to be 
inappropriate.   The rules are very clear that the time limit when we 
start a call is a guideline.  Chairs are not free to cut off unresolved 
discussions.

Yours,

Joel

On 3/27/2024 6:13 AM, Robert Raszuk wrote:
> Andrew,
>
> It is so cool IETF is about rough consensus ...
>
> Dear SPRING chairs,
>
> WGLC on this doc started Jan 22nd - Today we have March 27th - was the
> result of the working group's last call announced and I missed it ? Looking
> at the list it seems this draft got pretty overwhelming support already.
> Why are we not progressing ? What is holding us ?
>
> Many thx,
> Robert
>
>
>
>
>
> On Wed, Mar 27, 2024 at 10:36 AM Andrew Alston - IETF
> <[e-mail]> wrote:
>
>> No Robert,
>>
>>
>>
>> There are operators that have legitimate security concerns and concerts
>> about layer violations – and those operators are entirely in their rights
>> to have such concerns and act on them accordingly.  What this means is that
>> unless those concerns are addressed (with a fail closed
>> solution/ethertype/whatever) those operators will err on the side of
>> security and choose to forgo srv6 entirely no matter what it offers.
>>
>>
>>
>> This may well not be the case if SRv6 did diverge from Ipv6 and take
>> appropriate measures to become a fail closed system, giving the operator
>> the ability to run srv6 as they see fit, in either fail-closed mode (with
>> its own ethertype) or in open mode (without its own ethertype) – or in a
>> hybrid mode (though when we wrote the raviolli draft we chose not to
>> discuss the semantics of hybrid operation because of complexity and because
>> it probably would be a bad idea – but it CAN be done)
>>
>>
>>
>> Thanks
>>
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>>
>> Internal All Employees
>> From: Robert Raszuk <[e-mail]>
>> *Date: *Wednesday, 27 March 2024 at 12:28
>> *To: *Andrew Alston - IETF <[e-mail]>
>> *Cc: *Tom Herbert <[e-mail]>, Ron Bonica <[e-mail]>,
>> Alexander Vainshtein <[e-mail]>, [e-mail] <
>> [e-mail]>, Alvaro Retana <[e-mail]>
>> *Subject: *Re: [spring] Chair Review of
>> draft-ietf-spring-srv6-srh-compression-11
>>
>> Andrew,
>>
>>
>>
>>> because there are operators out there that will never run srv6
>>
>>
>> So for the operator who will never run SRv6 what exactly is the problem ?
>> How is he going to be affected by any SRv6 extensions ?
>>
>>
>>
>> Isn't such an operator acting like coast guard of selected IPv6 extensions
>> defending its day one "purity" even if people living further on the land
>> find it useful ? Or is there some cherry picking going on at the "Gates to
>> IPv6 Land" ? You can enter pls come in but you Sr. ohhh sorry No - pls go
>> away ?
>>
>>
>>
>> As mentioned I did observe those operators fighting when 6man allowed SRv6
>> to be IPv6 and they lost the battle badly including fired appeals.
>>
>>
>>
>> RFC8754 is a clear example of this. It is IETF STD track RFC and published
>> by 6man WG. So at this point any discussion on new ethertype for IPv6
>> should first start an effort to first obsolete all RFCs already approved in
>> this space.
>>
>>
>>
>> Best,
>> R.
>>
>>
>>
>> On Wed, Mar 27, 2024 at 7:24 AM Andrew Alston - IETF
>> <[e-mail]> wrote:
>>
>> Tom,
>>
>>
>>
>> I believe a number of the differences are highlighted in
>> draft-ietf-6man-sids.
>>
>>
>>
>> Though that does not go as far as to say they ipv6 and srv6 are not the
>> same thing – it does highlight that there are key deviations between srv6
>> and rfc4291 for example.
>>
>>
>>
>> (I hit discuss on this when I was still an AD as seen here
>> https://datatracker.ietf.org/doc/draft-ietf-6man-sids/ballot/#draft-ietf-6man-sids_andrew-alston  because
>> as I said in the discuss I believe that the sids document was attempting to
>> have it both ways – and I don’t believe you can do that)
>>
>>
>>
>> I also point out that if we do agree to diverge between srv6 and ipv6 –
>> this can be done without creating further complexity – and by allowing for
>> an **optional** ethertype as per
>> https://datatracker.ietf.org/doc/draft-raviolli-intarea-trusted-domain-srv6/
>> this also would allow operators the choice to run srv6 in a way that makes
>> them comfortable or not – without complexity and actually **enhance** the
>> deployment of srv6 – because there are operators out there that will never
>> run srv6 while we continue to insist its ipv6 but violate the ipv6
>> standards – at the expense of security and other aspects.
>>
>>
>>
>> I have never understood the vendor resistence to giving operators this
>> choice though – especially when it would actually help get their stuff
>> deployed in more networks potentially.
>>
>>
>>
>> Andrew
>>
>>
>>
>>
>>
>> Internal All Employees
>>
>> From: Tom Herbert <[e-mail]>
>> *Date: *Wednesday, 27 March 2024 at 02:52
>> *To: *Ron Bonica <[e-mail]>
>> *Cc: *Alexander Vainshtein <[e-mail]>,
>> [e-mail] <[e-mail]>, Andrew Alston - IETF
>> <[e-mail]>, Robert Raszuk <[e-mail]>, Alvaro
>> Retana <[e-mail]>
>> *Subject: *Re: [spring] Chair Review of
>> draft-ietf-spring-srv6-srh-compression-11
>>
>> On Tue, Mar 26, 2024 at 4:03 PM Ron Bonica <[e-mail]> wrote:
>>> Sasha,
>>>
>>> At the moment when SRv6 diverges from  IPv6, the two evolutionary
>> branches are identical. If SRv6 needs link locals, it can use them.
>>> However, SRv6 now has the freedom to evolve in ways that IPv6 cannot.
>> Hi Ron,
>>
>> That assumes that SRv6 is forked from IPv6? It might be nice for
>> someone to write up an I-D to really clarify the relationship between
>> SRv6 and IPv6.
>>
>> Tom
>>
>>>                                                                    Ron
>>>
>>> Juniper Business Use Only
>>>
>>> ________________________________
>>> From: Alexander Vainshtein <[e-mail]>
>>> Sent: Tuesday, March 26, 2024 4:24 PM
>>> To: Ron Bonica <[e-mail]>
>>> Cc: [e-mail] <[e-mail]>; Andrew Alston - IETF
>> <[e-mail]>; Robert Raszuk <[e-mail]>; Tom Herbert
>> <[e-mail]>; Alvaro Retana <[e-mail]>
>>> Subject: Re: [spring] Chair Review of
>> draft-ietf-spring-srv6-srh-compression-11
>>>
>>> [External Email. Be cautious of content]
>>>
>>> Ron,
>>> I am not sure you can separate just the forwarding plane of SRv6 and
>> IPv6.
>>> E.g., what would happen to all the IPv6 mechanisms that use link-local
>> IPv6 addresses?
>>> Replicating these mechanisms does not make much sense to me.
>>>
>>> My 2c,
>>> Sasha
>>>
>>>
>>> Get Outlook for Android
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> ________________________________
>>> From: Ron Bonica <[e-mail]>
>>> Sent: Tuesday, March 26, 2024 8:36:49 PM
>>> To: Alexander Vainshtein <[e-mail]>
>>> Cc: [e-mail] <[e-mail]>; Andrew Alston - IETF
>> <[e-mail]>; Robert Raszuk <[e-mail]>; Tom Herbert
>> <[e-mail]>; Alvaro Retana <[e-mail]>
>>> Subject: [EXTERNAL] Re: [spring] Chair Review of
>> draft-ietf-spring-srv6-srh-compression-11
>>> Sasha,
>>>
>>> Good point. In my previous email, I didn't mean suggest that we should
>> divorce SRv6 from the entire suite of Internet protocols. I only meant that
>> we should divorce the SRv6 forwarding plane from the IPv6 forwarding plane.
>> BGP could continue to distribute SIDS exactly as is distributes MPLS
>> service labels today.
>>> You bring up another good point about the parallel evolution of SRv6 and
>> IPv6. Yes, this is an engineering trade off. If you divorce SRv6 from IPv6,
>> and IPv6 develops a useful new feature, SRv6 might need to develop that
>> feature, too. However, if you bind SRv6 to IPv6, SRv6 must strictly adhere
>> to IPv6 standards, both now and in the future.
>>> Which is more painful?
>>>
>>>
>> Ron
>>> Juniper Business Use Only
>>>
>>> ________________________________
>>> From: Alexander Vainshtein <[e-mail]>
>>> Sent: Tuesday, March 26, 2024 1:56 PM
>>> To: Ron Bonica <[e-mail]>
>>> Cc: [e-mail] <[e-mail]>; Andrew Alston - IETF
>> <[e-mail]>; Robert Raszuk <[e-mail]>; Tom Herbert
>> <[e-mail]>; Alvaro Retana <[e-mail]>
>>> Subject: RE: [spring] Chair Review of
>> draft-ietf-spring-srv6-srh-compression-11
>>>
>>> [External Email. Be cautious of content]
>>>
>>> Ron and all,
>>>
>>> I respectfully disagree with the proposal of separation of SRv6 from the
>> existing IPv6.
>>>
>>>
>>> IMHO and FWIW the most important added value of SRv6 is its ability to
>> provide BGP-based overlay services without any changes in the P routers as
>> described in Introduction of RFC 9252:
>>>
>>>
>>> To provide SRv6 service with best-effort connectivity, the egress PE
>> signals an SRv6 Service SID with the BGP overlay service route. The ingress
>> PE encapsulates the payload in an outer IPv6 header where the destination
>> address is the SRv6 Service SID provided by the egress PE. The underlay
>> between the PEs only needs to support plain IPv6 forwarding [RFC8200].
>>>
>>>
>>> To me this means that SRv6 services can benefit from incremental
>> deployment when new forwarding capabilities (implementation of SRv6
>> Endpoint Behaviors) would be initially available just in the relevant PEs