Subject: Re: [spring] Is srv6 PSP a good idea

From: Mark Smith <[email-masked]>
Date: Wed, 26 Feb 2020 11:30:39 +1100

Hi Pablo,

On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)
<[email-masked]> wrote:
>
>  Hi Ron,
>
> I guess we are making some progress here but going in some circles. So far we have moved from “this violates RFC8200” to “there are no use-cases or benefits” to “this is complex for an ASIC” to “what is the benefit again” and now back to “this is complex for an ASIC”.
>

As far as I know, the next header field in both the IPv6 fixed header
and in extension headers is immutable while the packet is travelling
within the network, as is the payload length field in the IPv6 base
fixed header.

Nothing in RFC 8200 modifies those fields while the packet is in
flight between the packet's original source and final destination, nor
is there anything in RFC 8200 that specifies how to do those
modifications and any other discussion about the consequences and
considerations when doing so.

The IPsec AH header is providing integrity checking over fields in the
IPv6 packet that shouldn't be being modified while the packet is
within the network. What is and isn't protected by AH can be seen to
be a specification of what processing on a packet can and cannot occur
while it is in flight across the network towards its final
destination.

Therefore, AH is really a quality assurance mechanism for the network
packet processing that RFC 8200 specifies. The processing of the
packet by the network with or without the use of AH should be the
same. AH should really only be necessary if there is a belief that the
network is likely not to be processing packets in accordance to RFC
8200, either accidentally or intentionally.

Per RFC4302 (IPsec AH),  the following section explicitly states which
fields in the IPv6 header are immutable and are to be protected by AH:

3.3.3.1.2.  ICV Computation for IPv6

3.3.3.1.2.1.  Base Header Fields

   The IPv6 base header fields are classified as follows:

Immutable
           Version
           Payload Length
           Next Header
           Source Address
           Destination Address (without Routing Extension Header)

   Mutable but predictable
           Destination Address (with Routing Extension Header)

   Mutable (zeroed prior to ICV calculation)
           DSCP (6 bits, see RFC2474 [NBBB98])
           ECN (2 bits, see RFC3168 [RFB01])
           Flow Label (*)
           Hop Limit

        (*) The flow label described in AHv1 was mutable, and in
            RFC 2460 [DH98] was potentially mutable.  To retain
            compatibility with existing AH implementations, the
            flow label is not included in the ICV in AHv2.

> As for how easy or not something is, the PSP behavior has been implemented and deployed (running code). The use-cases have been described and positively reinforced by operators. I don't think there is any further explanation to provide.
>

"Just because you can do something, doesn't mean you should."

How much troubleshooting experience have they had with this?

I think a very important factor is how easy something is to
troubleshoot - how obvious is the mechanism works; is the mechanism
consistent with existing behaviours i.e. the principle of least
surprise (removing EHs at an intermediary hop certainly isn't in IPv6,
even if the intermediary hop as the packet's current DA); when it
inevitably fails, how obvious is it where the fault is likely to be;
and how quickly can a typical fault be rectified.

Regards,
Mark.

> Happy Holidays,
> Pablo.
>
>
> -----Original Message-----
> From: Ron Bonica <[email-masked]>
> Date: Tuesday, 17 December 2019 at 16:06
> To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: RE: [spring] Is srv6 PSP a good idea
>
>     Pablo,
>
>     In your message below, are you arguing that it is easier for the penultimate node to remove the SRH than it is for the ultimate node to ignore it? I think that would be a stretch.
>
>                                                                                   Ron
>
>
>
>     Juniper Business Use Only
>
>     -----Original Message-----
>     From: Pablo Camarillo (pcamaril) <[email-masked]>
>     Sent: Saturday, December 14, 2019 4:50 AM
>     To: Ron Bonica <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
>     Subject: Re: [spring] Is srv6 PSP a good idea
>
>     Ron,
>
>     What is the "price paid by the penultimate segment"? All the current implementations do this at linerate with no performance degradation as I have explained in my email before.
>
>     There is substantial benefit. Four operators have deployed PSP, which proves the benefit.
>     It enables new use-cases that have been provided by other members in the list. [1], [2] and [5].
>     From operational perspective it is not complex as explained in [3].
>     Operators have expressed their value in [4] and [5].
>
>     [1].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcdXeBzk_$
>     [2].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcU9bihBc$
>     [3].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4Icc_wo902$
>     [4].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcRXo_q-1$
>     [5].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IceGPpSab$
>
>     Cheers,
>     Pablo.
>
>     -----Original Message-----
>     From: Ron Bonica <[email-masked]>
>     Date: Thursday, 12 December 2019 at 21:50
>     To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
>     Subject: RE: [spring] Is srv6 PSP a good idea
>
>         Pablo,
>
>         I am not convinced the benefit derived by the ultimate segment justifies the price paid by the penultimate segment. Specifically,
>
>         - the ultimate segment benefits because it doesn't have to skip over the SRH with SL == 0
>         - in order for the ultimate segment to derive this benefit, the penultimate segment needs to remove bytes from the middle of the packet and update two fields in the IPv6 header
>
>         As Joel said, we typically don't add options (i.e., complexity) to a specification unless there is substantial benefit.
>
>                                                             Ron
>
>
>
>
>         Juniper Business Use Only
>
>         -----Original Message-----
>         From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
>         Sent: Wednesday, December 11, 2019 3:12 PM
>         To: Joel M. Halpern <[email-masked]>; [email-masked]
>         Subject: Re: [spring] Is srv6 PSP a good idea
>
>         Joel,
>
>         1.- The use-case for PSP has already been provided at the mailer. There are scenarios where it provides benefits to operators.
>
>         2.- The PSP behavior is optional. It is up to the operator in his deployment to decide whether to enable it or not at one particular router.
>         Similarly, a vendor may decide not to implement it. The PSP behavior has been implemented by several vendors and deployed (see the srv6 deployment draft).
>
>         3.- A network may have PSP enabled at some nodes and not at others.  Everything is still interoperable and works fine.
>
>         4.- PSP is not a complex operation in hardware (doable at linerate on existing merchant silicon).
>         Example: It has been implemented and deployed on Broadcom J/J+. If I recall correctly Broadcom Jericho+ started shipping in March 2016! PSP is supported on this platform at linerate with no performance degradation (neither PPPS nor BW).
>         Given that this is doable in a platform from more than 3 years ago, I fail to see how you need "very special provision" to do this.
>
>         Is it really something that horrible to provide freedom of choice to the operators deploying?
>
>         In summary, it can be implemented without any burden in hardware and deployment experience prove this is beneficial to operators.
>
>         Thanks,
>         Pablo.
>
>         -----Original Message-----
>         From: spring <[email-masked]> on behalf of "Joel M. Halpern" <[email-masked]>
>         Date: Wednesday, 11 December 2019 at 03:55
>         To: "[email-masked]" <[email-masked]>
>         Subject: [spring] Is srv6 PSP a good idea
>
>             For purposes of this thread, even if you think PSP violates RFC 8200,
>             let us assume that it is legal.
>
>             As I understand it, the PSP situation is:
>             o the packet arrives at the place (let's not argue about whether SIDs
>             are locators) identified by the SID in the destination address field
>             o that SID is the next to last SID in the SID list
>             o that sid is marked as / known to be PSP
>             o at the intended place in the processing pseudocode, the last (first)
>             entry in the SRH is copied into the destination IPv6 address field of
>             the packet
>             -> The SRH being used is then removed from the packet.
>
>             In order to evaluate whether this is a good idea, we have to have some
>             idea of the benefit.  It may be that I am missing some of the benefit,
>             and I would appreciate clarification.
>             As far as I can tell, the benefit of this removal is that in exchange
>             for this node doing the work of removing the SRH, the final node in the
>             SRH does not have to process the SRH at all, as it has been removed.
>
>             I have trouble seeing how that work tradeoff can be beneficial.
>             Removing bytes from the middle of a packet is a complex operation.
>             Doing so in Silicon (we expect this to be done in the fast path of
>             significant forwarders as I understand it) requires very special
>             provision.  Even in software, removing bytes from the middle of a packet
>             requires somewhere between some and a lot of extra work.  It is
>             distinctly NOT free.
>
>             In contrast, we have assumed that the work of processing SRH itself is
>             tractable, since otherwise all of SRv6 would be problematic.  So why is
>             this necessary.
>
>             Yours,
>             Joel
>
>             PS: Note that both the MPLS case and the encapsulation case are very
>             different in that the material being removed is at the front of the IP
>             packet.  Pop or prepend are MUCH easier than middle-removal (or
>             middle-insertion).
>
>             _______________________________________________
>             spring mailing list
>             [email-masked]
>             https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
>
>
>         _______________________________________________
>         spring mailing list
>         [email-masked]
>         https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 26 Feb 2020 09:50:44 +0000

Hi Mark,
I think both AH and PSP are optional.
If AH is desired to deploy, then the operator can choose not to use PSP.
If AH is not deployed, and the operator has its requirements of incremental-deployment, then the operator can choose to use PSP.
If the already deployed PSP is removed from the draft, then I think it's backward for interoperation.

RFC4301:
3.2.  How IPsec Works

   IPsec uses two protocols to provide traffic security services --
   Authentication Header (AH) and Encapsulating Security Payload (ESP).
   Both protocols are described in detail in their respective RFCs
   [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY
   support AH. (Support for AH has been downgraded to MAY because
   experience has shown that there are very few contexts in which ESP
   cannot provide the requisite security services.  Note that ESP can be
   used to provide only integrity, without confidentiality, making it
   comparable to AH in most contexts.)

Thanks,
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Wednesday, February 26, 2020 8:31 AM
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

Hi Pablo,

> I guess we are making some progress here but going in some circles. So far we have moved from “this violates RFC8200” to “there are no use-cases or benefits” to “this is complex for an ASIC” to “wh…

As far as I know, the next header field in both the IPv6 fixed header and in extension headers is immutable while the packet is travelling within the network, as is the payload length field in the IPv6 base fixed header.

Nothing in RFC 8200 modifies those fields while the packet is in flight between the packet's original source and final destination, nor is there anything in RFC 8200 that specifies how to do those modifications and any other discussion about the consequences and considerations when doing so.

The IPsec AH header is providing integrity checking over fields in the
IPv6 packet that shouldn't be being modified while the packet is within the network. What is and isn't protected by AH can be seen to be a specification of what processing on a packet can and cannot occur while it is in flight across the network towards its final destination.

Therefore, AH is really a quality assurance mechanism for the network packet processing that RFC 8200 specifies. The processing of the packet by the network with or without the use of AH should be the same. AH should really only be necessary if there is a belief that the network is likely not to be processing packets in accordance to RFC 8200, either accidentally or intentionally.

Per RFC4302 (IPsec AH),  the following section explicitly states which fields in the IPv6 header are immutable and are to be protected by AH:

Immutable
           Version
           Payload Length
           Next Header
           Source Address

   Mutable but predictable

I think a very important factor is how easy something is to troubleshoot - how obvious is the mechanism works; is the mechanism consistent with existing behaviours i.e. the principle of least surprise (removing EHs at an intermediary hop certainly isn't in IPv6, even if the intermediary hop as the packet's current DA); when it inevitably fails, how obvious is it where the fault is likely to be; and how quickly can a typical fault be rectified.

Regards,
Mark.

> To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Joel M. 
> Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
>     [5].- 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
> ng/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiB
> zoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IceGPpSab$
>
>     Cheers,
>     Pablo.
>
>         I am not convinced the benefit derived by the ultimate segment 
> justifies the price paid by the penultimate segment. Specifically,
>
>         - in order for the ultimate segment to derive this benefit, 
> the penultimate segment needs to remove bytes from the middle of the 
> packet and update two fields in the IPv6 header
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r7
> 8vsFpWAHa8hW2$
>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r7
> 8vsFpWAHa8hW2$
>
>
>

---

From: Huzhibo <[email-masked]>
Date: Wed, 26 Feb 2020 10:00:39 +0000

+1 support Jingrong's point.

Thanks
Zhibo 

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Xiejingrong (Jingrong)
Sent: Wednesday, February 26, 2020 5:51 PM
To: Mark Smith <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

Hi Mark,

RFC4301:
3.2.  How IPsec Works

Thanks,
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Wednesday, February 26, 2020 8:31 AM
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

Hi Pablo,

Immutable
           Version
           Payload Length
           Next Header
           Source Address

   Mutable but predictable

Regards,
Mark.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Feb 2020 11:00:43 +0100

On Wed, Feb 26, 2020 at 1:31 AM Mark Smith <[email-masked]> wrote:

> > I guess we are making some progress here but going in some circles. So
> far we have moved from “this violates RFC8200” to “there are no use-cases
> or benefits” to “this is complex for an ASIC” to “what is the benefit
> again” and now back to “this is complex for an ASIC”.
> >
>
> > As for how easy or not something is, the PSP behavior has been
> implemented and deployed (running code). The use-cases have been described
> and positively reinforced by operators. I don't think there is any further
> explanation to provide.
> >
>
> >     In your message below, are you arguing that it is easier for the
> penultimate node to remove the SRH than it is for the ultimate node to
> ignore it? I think that would be a stretch.
> >
> >
>          Ron
> >
> >
> >
> >     What is the "price paid by the penultimate segment"? All the current
> implementations do this at linerate with no performance degradation as I
> have explained in my email before.
> >
> >     [1].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcdXeBzk_$
> >     [2].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcU9bihBc$
> >     [3].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4Icc_wo902$
> >     [4].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcRXo_q-1$
> >     [5].-
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IceGPpSab$
> >
> >     Cheers,
> >     Pablo.
> >
> >         - in order for the ultimate segment to derive this benefit, the
> penultimate segment needs to remove bytes from the middle of the packet and
> update two fields in the IPv6 header
> >
> >         As Joel said, we typically don't add options (i.e., complexity)
> to a specification unless there is substantial benefit.
> >
> >                                                             Ron
> >
> >
> >
> >
> >         1.- The use-case for PSP has already been provided at the
> mailer. There are scenarios where it provides benefits to operators.
> >
> >         2.- The PSP behavior is optional. It is up to the operator in
> his deployment to decide whether to enable it or not at one particular
> router.
> >         Similarly, a vendor may decide not to implement it. The PSP
> behavior has been implemented by several vendors and deployed (see the srv6
> deployment draft).
> >
> >         3.- A network may have PSP enabled at some nodes and not at
> others.  Everything is still interoperable and works fine.
> >
> >         Example: It has been implemented and deployed on Broadcom J/J+.
> If I recall correctly Broadcom Jericho+ started shipping in March 2016! PSP
> is supported on this platform at linerate with no performance degradation
> (neither PPPS nor BW).
> >         Given that this is doable in a platform from more than 3 years
> ago, I fail to see how you need "very special provision" to do this.
> >
> >         In summary, it can be implemented without any burden in hardware
> and deployment experience prove this is beneficial to operators.
> >
> >         Thanks,
> >         Pablo.
> >

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Feb 2020 11:06:49 +0100

So now we have one more to Pablo's list: "Let's not use it as it is hard to
troubleshoot" ...

Clearly each new tool has a learning curve and no doubt not everyone will
know how to use it. But does this mean we should stop inventing new things
? IMO for someone who is starting to use SRv6 PHP is the least complex
operational behaviour.

Thx,
R.

On Wed, Feb 26, 2020 at 1:31 AM Mark Smith <[email-masked]> wrote:
>> >     What is the "price paid by the penultimate segment"? All the
>> current implementations do this at linerate with no performance degradation
>> as I have explained in my email before.
>> >
>> >         In summary, it can be implemented without any burden in
>> hardware and deployment experience prove this is beneficial to operators.
>> >
>> >         Thanks,
>> >         Pablo.
>> >

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 26 Feb 2020 11:32:11 +0000

Agree! I thought these problems have already been closed for a while since we have a lot of discussion for a while.

After two months not paying attention to the mailing list, the discussion is still there?

Clearly, we had a  lot of discussion already, please refs to the links in the below emails. From tech aspect, agree with Jingrong’s POV. Copied below.

Best Regards,
Cheng

Hi Mark,

RFC4301:

3.2.  How IPsec Works

Thanks,

Jingrong

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, February 26, 2020 6:07 PM
To: Mark Smith <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

So now we have one more to Pablo's list: "Let's not use it as it is hard to troubleshoot" ...

Clearly each new tool has a learning curve and no doubt not everyone will know how to use it. But does this mean we should stop inventing new things ? IMO for someone who is starting to use SRv6 PHP is the least complex operational behaviour.

Thx,
R.

On Wed, Feb 26, 2020 at 1:31 AM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pablo,

Immutable
           Version
           Payload Length
           Next Header
           Source Address

   Mutable but predictable

Regards,
Mark.

> From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
> To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>     From: Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>
>     To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>     Operators have expressed their value in [4] and [5]..
>
>     [1].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcdXeBzk_$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcdXeBzk_$>
>     [2].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcU9bihBc$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcU9bihBc$>
>     [3].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4Icc_wo902$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4Icc_wo902$>
>     [4].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcRXo_q-1$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcRXo_q-1$>
>     [5].- https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IceGPpSab$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IceGPpSab$>
>
>     Cheers,
>     Pablo.
>
>     From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
>     To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>         From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Pablo Camarillo (pcamaril)
>         To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>         From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>
>         To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>             [email-masked]<mailto:[email-masked]>
>             https://urldefense.com/v3/__https://www.ietf..org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$>
>
>
>         [email-masked]<mailto:[email-masked]>
>         https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r78vsFpWAHa8hW2$>
>
>
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Mark Smith <[email-masked]>
Date: Wed, 26 Feb 2020 22:44:35 +1100

> So now we have one more to Pablo's list: "Let's not use it as it is hard

Listing objections doesn't mean they've been addressed.

> Clearly each new tool has a learning curve
>

IPv6 is not a new tool.

It is 21 years since I started learning and using it. In that time, no
changes have been made to it that are as radical as removing EHs while
packets are in flight would be.

Radical changes have to have exceptional justification when something is so
old, widely understood, widely documented in books and training materials,
many people have been trained on and is now quite rapidly becoming widely
deployed.

and no doubt not everyone will know how to use it. But does this mean we
> should stop inventing new things ? IMO for someone who is starting to use
> SRv6 PHP is the least complex operational behaviour.
>

Structurally modifying packets in flight is a far more complex operation
than simply forwarding them.

The ideal is to minimise and ideally avoid packet modifications in flight,
so what what arrives at the final destination is as close as possible to
what as sent by the original source. This forces simplicity in the network
and makes troubleshooting simpler because the number of changes and devices
that can make changes is reduced.

I think the original designers of IP had a goal of "read only" forwarding.
Early versions of IP (e.g. RFC675, "IPv1", 1974) didn't have a TTL field,
and I think they only added it because they eventually realised after 4
years that they weren't going to come up with a routing protocol that
didn't have transient loops.

Mark.

>>> the penultimate segment needs to remove bytes from the middle of the packet
>>> and update two fields in the IPv6 header
>>> >
>>> >         As Joel said, we typically don't add options (i.e.,
>>> complexity) to a specification unless there is substantial benefit.
>>> >
>>> >                                                             Ron
>>> >
>>> >
>>> >
>>> >
>>> >         Example: It has been implemented and deployed on Broadcom
>>> J/J+. If I recall correctly Broadcom Jericho+ started shipping in March
>>> 2016! PSP is supported on this platform at linerate with no performance
>>> degradation (neither PPPS nor BW).

---

From: Mark Smith <[email-masked]>
Date: Wed, 26 Feb 2020 22:57:17 +1100

On Wed, 26 Feb 2020, 20:50 Xiejingrong (Jingrong), <[email-masked]>
wrote:

> If AH is not deployed, and the operator has its requirements of
> incremental-deployment, then the operator can choose to use PSP.

You've missed the point. AH is an assurance mechanism for something that
should *already* be happening - processing packets in accordance with RFC
8200.

Somebody choosing not to use AH doesn't mean SPRING can ignore the IPv6
specifications.

If the already deployed PSP is removed from the draft, then I think it's
> backward for interoperation.
>
> RFC4301:
> 3.2.  How IPsec Works
>

> As far as I know, the next header field in both the IPv6 fixed header and
> in extension headers is immutable while the packet is travelling within the
> network, as is the payload length field in the IPv6 base fixed header.
>
> Nothing in RFC 8200 modifies those fields while the packet is in flight
> between the packet's original source and final destination, nor is there
> anything in RFC 8200 that specifies how to do those modifications and any
> other discussion about the consequences and considerations when doing so.
>
>
> IPv6 packet that shouldn't be being modified while the packet is within
> the network. What is and isn't protected by AH can be seen to be a
> specification of what processing on a packet can and cannot occur while it
> is in flight across the network towards its final destination.
>
> packet processing that RFC 8200 specifies. The processing of the packet by
> the network with or without the use of AH should be the same. AH should
> really only be necessary if there is a belief that the network is likely
> not to be processing packets in accordance to RFC 8200, either accidentally
> or intentionally.
>
>
> I think a very important factor is how easy something is to troubleshoot -
> how obvious is the mechanism works; is the mechanism consistent with
> existing behaviours i.e. the principle of least surprise (removing EHs at
> an intermediary hop certainly isn't in IPv6, even if the intermediary hop
> as the packet's current DA); when it inevitably fails, how obvious is it
> where the fault is likely to be; and how quickly can a typical fault be
> rectified.
>
>
>
> Regards,
> Mark.
>
>
>
>
> > Happy Holidays,
> > Pablo.
> >
> >

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Feb 2020 14:05:31 +0100

specifications.

I think it sure can and in fact it should.

See there is perhaps key misunderstanding here.

Regardless if folks agree or not with that SRv6 is a new data plane. SRv6
!= IPv6 that's obvious.

It also does not attempt to *extend* IPv6. It reuses some IPv6 elements and
makes sure non SRv6 nodes can treat the packets as vanilla IPv6, but that's
it. With that in mind all of this going back and forth between SPRING and
6MAN to me is triggered by wrong positioning of SRv6 as a new transport.

Sure if SRv6 would be extending IPv6 then updates to RFC8200 would be
needed - but here RFC8200 should at best be informative reference. I am not
even sure why SRH needs to be 6MAN RFC. IETF is designed to build and
improve prior art not be locked by it.

Cheers,
R.

---

From: James Guichard <[email-masked]>
Date: Wed, 26 Feb 2020 13:44:30 +0000

+1 and well said!

From: spring <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, February 26, 2020 8:06 AM
To: Mark Smith <[email-masked]>
Cc: Xiejingrong (Jingrong) <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

> Somebody choosing not to use AH doesn't mean SPRING can ignore the IPv6 specifications.

Regardless if folks agree or not with that SRv6 is a new data plane. SRv6 != IPv6 that's obvious.

It also does not attempt to *extend* IPv6. It reuses some IPv6 elements and makes sure non SRv6 nodes can treat the packets as vanilla IPv6, but that's it. With that in mind all of this going back and forth between SPRING and 6MAN to me is triggered by wrong positioning of SRv6 as a new transport.

Sure if SRv6 would be extending IPv6 then updates to RFC8200 would be needed - but here RFC8200 should at best be informative reference. I am not even sure why SRH needs to be 6MAN RFC. IETF is designed to build and improve prior art not be locked by it.

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Feb 2020 14:47:45 +0100

Thx Jim !

Apologies - I spotted one typo in my mail:    s/ as a new transport./ It is
a new transport./

On Wed, Feb 26, 2020 at 2:44 PM James Guichard <
[email-masked]> wrote:

> +1 and well said!
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, February 26, 2020 8:06 AM
> *To:* Mark Smith <[email-masked]>
> *Cc:* Xiejingrong (Jingrong) <[email-masked]>; Ron Bonica <
> [email-masked]>; [email-masked]; Joel M. Halpern <
> [email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
> *Subject:* Re: [spring] Is srv6 PSP a good idea
>
>
>
>
>
> It also does not attempt to *extend* IPv6. It reuses some IPv6 elements
> and makes sure non SRv6 nodes can treat the packets as vanilla IPv6, but
> that's it. With that in mind all of this going back and forth
> between SPRING and 6MAN to me is triggered by wrong positioning of SRv6 as
> a new transport.
>
>
>

---

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 14:48:50 +0100

Hi Robert,

> It also does not attempt to *extend* IPv6. It reuses some IPv6 elements and makes sure non SRv6 nodes can treat the packets as vanilla IPv6, but that's it. With that in mind all of this going back…

This is completely bogus. SRv6 is not a new L3 protocol that just happens to be compatible with IPv6. That is insane BS.

> Sure if SRv6 would be extending IPv6 then updates to RFC8200 would be needed - but here RFC8200 should at best be informative reference. I am not even sure why SRH needs to be 6MAN RFC. IETF is des…

Because you are building SRv6 on IPv6, plain and simple.

Cheers,
Sander

---

From: Andrew Alston <[email-masked]>
Date: Wed, 26 Feb 2020 14:15:22 +0000

+1 Sander.

Furthermore - if indeed that is the contention - then - I suggest you move the whole thing out of SPRING - I quote from the SPRING charter:

The Source Packet Routing in NetworkinG (SPRING) Working Group is the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6).

Relevant portion in bold.

You can claim that SRv6 is a new routing header - you cannot claim that it is not part of IPv6 - the IPv6 base header is maintained - you are adding a routing header - done/done - no point even entertaining this line of thought any further

Andrew

From: spring <[email-masked]> On Behalf Of Sander Steffann
Sent: Wednesday, 26 February 2020 16:49
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; 6man WG <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

Hi Robert,

Cheers,
Sander

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: Andrew Alston <[email-masked]>
Date: Wed, 26 Feb 2020 14:24:48 +0000

Figured I'd add to this - as I continued to read the charter

SPRING WG should avoid modification to existing data planes that would
make them incompatible with existing deployments. Where possible,
existing control and management plane protocols must be used within
existing architectures to implement the SPRING function. Any
modification of -or extension to- existing architectures, data planes,
or control or management plane protocols should be carried out in the
WGs responsible for the architecture, data plane, or control or
management plane protocol being modified and in coordination with the
SPRING WG, but may be done in SPRING WG after agreement with all the
relevant WG chairs and responsible Area Directors.

If SRv6 is not IPv6 - as is the contention - (which in my view is an absolutely false contention designed to step around a specification because it simply doesn't suite what you want) - well - then what exactly are we doing here - because by that claim - we are inventing a new control plane, a new data plane, and well, it's a new protocol - so - do we have the agreement of the relevant WG chairs, Area Directors etc - to invent an entirely new everything.

Didn't think so....

Andrew

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 11:24:25 -0300

On 26/2/20 11:15, Andrew Alston wrote:
> +1 Sander.
> 
> Furthermore – if indeed that is the contention – then – I suggest you 
> move the whole thing out of SPRING – I quote from the SPRING charter:
> 
> /The Source Packet Routing in NetworkinG (SPRING) Working Group is 
> the////home of Segment Routing (SR) using MPLS (SR-MPLS) *_and IPv6 
> (SRv6)._*/*/__/*
> 
> You can claim that SRv6 is a new routing header – you cannot claim that 
> it is not part of IPv6 – the IPv6 base header is maintained – you are 
> adding a routing header – done/done – no point even entertaining this 
> line of thought any further

The fact that this is still going on is at least alarming.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Wed, 26 Feb 2020 14:53:31 +0000

Hi Mark
I have comment below;

Cheers!

Wang Weibin

From: spring <[email-masked]> On Behalf Of Mark Smith
Sent: Wednesday, February 26, 2020 7:45 PM
To: Robert Raszuk <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

and no doubt not everyone will know how to use it. But does this mean we should stop inventing new things ? IMO for someone who is starting to use SRv6 PHP is the least complex operational behaviour.

Structurally modifying packets in flight is a far more complex operation than simply forwarding them.

The ideal is to minimise and ideally avoid packet modifications in flight, so what what arrives at the final destination is as close as possible to what as sent by the original source. This forces simplicity in the network and makes troubleshooting simpler because the number of changes and devices that can make changes is reduced.

WWB：in many SRv6 deployment case at present, the original packet from outside of SRv6 domain will always be encapsulated by outer IPv6 header and SRH header in ingress router of SRv6 domain, and the original packet leave the SRv6 domain at egress router without any change. During the forwarding procedure within SRv6 domain, only the outer header and its SRH might be changed endpoint by endpoint. The all nodes within SRv6 domain managed by single operator have a consensus rule about how to deal with SRv6 packet. So I don’t think the SRv6 carrier tool violate the spirit you mentioned above. I think we had better slightly distinguish the function of roles between outer IPv6 header (and its EHs) and internal IPv6 header (and its EHs).

I think the original designers of IP had a goal of "read only" forwarding. Early versions of IP (e.g. RFC675, "IPv1", 1974) didn't have a TTL field, and I think they only added it because they eventually realised after 4 years that they weren't going to come up with a routing protocol that didn't have transient loops.

Mark.

Thx,
R.

Immutable
           Version
           Payload Length
           Next Header
           Source Address

   Mutable but predictable

Regards,
Mark.

> To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <jmh@joelhalpern..com<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Feb 2020 11:23:08 -0500

Robert, given that PSP either pushes the envelop of what is permitted by 
RFC 8200 or outright violates it (which applies seems to depend upon the 
reader) it would seem that there ought to be a good reason for including 
PSP, rather than claiming that objectors need to motivate removing it.

I have seen only minimal descriptions of value for PSP.
We know that adding optional behaviors is undesirable in the abstract.
Adding optional behaviors that push or violate the standards seems 
significantly worse.

Yours,
Joel

On 2/26/2020 5:06 AM, Robert Raszuk wrote:
> Clearly each new tool has a learning curve and no doubt not everyone 
> will know how to use it. But does this mean we should stop inventing new 
> things ? IMO for someone who is starting to use SRv6 PHP is the least 
> complex operational behaviour.
> 
> Thx,
> R.
> 
> 
>         <[email-masked] <mailto:[email-masked]>> wrote:
>          >
>          >  Hi Ron,
>          >
>          > I guess we are making some progress here but going in some
>         circles. So far we have moved from “this violates RFC8200” to
>         “there are no use-cases or benefits” to “this is complex for an
>         ASIC” to “what is the benefit again” and now back to “this is
>         complex for an ASIC”.
>          >
> 
>          > As for how easy or not something is, the PSP behavior has
>         been implemented and deployed (running code). The use-cases have
>         been described and positively reinforced by operators. I don't
>         think there is any further explanation to provide.
>          >
> 
>          > To: "Pablo Camarillo (pcamaril)" <[email-masked]
>         <mailto:[email-masked]>>, "Joel M. Halpern"
>         <[email-masked] <mailto:[email-masked]>>,
>         "[email-masked] <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>          >     In your message below, are you arguing that it is easier
>         for the penultimate node to remove the SRH than it is for the
>         ultimate node to ignore it? I think that would be a stretch.
>          >
>          >                                                             
>                               Ron
>          >
>          >
>          >
>          >     To: Ron Bonica <[email-masked]
>         <mailto:[email-masked]>>; Joel M. Halpern
>         <[email-masked] <mailto:[email-masked]>>;
>         [email-masked] <mailto:[email-masked]>
>          >     What is the "price paid by the penultimate segment"? All
>         the current implementations do this at linerate with no
>         performance degradation as I have explained in my email before.
>          >
>          >     To: "Pablo Camarillo (pcamaril)" <[email-masked]
>         <mailto:[email-masked]>>, "Joel M. Halpern"
>         <[email-masked] <mailto:[email-masked]>>,
>         "[email-masked] <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>          >         I am not convinced the benefit derived by the
>         ultimate segment justifies the price paid by the penultimate
>         segment. Specifically,
>          >
>          >         - in order for the ultimate segment to derive this
>         benefit, the penultimate segment needs to remove bytes from the
>         middle of the packet and update two fields in the IPv6 header
>          >
>          >         From: spring <[email-masked]
>         <mailto:[email-masked]>> On Behalf Of Pablo Camarillo
>         (pcamaril)
>          >         To: Joel M. Halpern <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>
>          >         1.- The use-case for PSP has already been provided at
>         the mailer. There are scenarios where it provides benefits to
>         operators.
>          >
>          >         2.- The PSP behavior is optional. It is up to the
>         operator in his deployment to decide whether to enable it or not
>         at one particular router.
>          >         Similarly, a vendor may decide not to implement it.
>         The PSP behavior has been implemented by several vendors and
>         deployed (see the srv6 deployment draft).
>          >
>          >         3.- A network may have PSP enabled at some nodes and
>         not at others.  Everything is still interoperable and works fine.
>          >
>          >         4.- PSP is not a complex operation in hardware
>         (doable at linerate on existing merchant silicon).
>          >         Example: It has been implemented and deployed on
>         Broadcom J/J+. If I recall correctly Broadcom Jericho+ started
>         shipping in March 2016! PSP is supported on this platform at
>         linerate with no performance degradation (neither PPPS nor BW).
>          >         Given that this is doable in a platform from more
>         than 3 years ago, I fail to see how you need "very special
>         provision" to do this.
>          >
>          >         Is it really something that horrible to provide
>         freedom of choice to the operators deploying?
>          >
>          >         In summary, it can be implemented without any burden
>         in hardware and deployment experience prove this is beneficial
>         to operators.
>          >
>          >         Thanks,
>          >         Pablo.
>          >
>          >         From: spring <[email-masked]
>         <mailto:[email-masked]>> on behalf of "Joel M. Halpern"
>         <[email-masked] <mailto:[email-masked]>>
>          >         To: "[email-masked] <mailto:[email-masked]>"
>         <[email-masked] <mailto:[email-masked]>>
>          > [email-masked] <mailto:[email-masked]>
>          >
>          > [email-masked] <mailto:[email-masked]>
>          >
>          > [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 26 Feb 2020 08:37:58 -0800

On Wed, Feb 26, 2020, 6:26 AM Andrew Alston <[email-masked]>
wrote:

> Figured I’d add to this – as I continued to read the charter
>
>
>
> *SPRING WG should avoid modification to existing data planes that would*
>
>
>
>
>
>
>
>
> * make them incompatible with existing deployments. Where possible,
> existing architectures to implement the SPRING function. Any modification
> of -or extension to- existing architectures, data planes, or control or
> management plane protocols should be carried out in the WGs responsible for
> the architecture, data plane, or control or management plane protocol being
> modified and in coordination with the SPRING WG, but may be done in SPRING
> WG after agreement with all the relevant WG chairs and responsible Area
> Directors.*
>
>
>
> If SRv6 is not IPv6 – as is the contention – (which in my view is an
> absolutely false contention
>

+1

> designed to step around a specification because it simply doesn’t suite
> what you want) - well – then what exactly are we doing here – because by
> that claim – we are inventing a new control plane, a new data plane, and
> well, it’s a new protocol – so – do we have the agreement of the relevant
> WG chairs, Area Directors etc – to invent an entirely new everything.
>

That's already happened. SRH has reinvented both protocol options, TLVs, in
the network layer, as well as header authentication.

Tom

>
>
> Didn’t think so….
>
>
>
> Andrew
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Feb 2020 20:44:52 +0100

Hey Sander,

No worries ... three IPv6 musketeers have already presented themselves well
to this discussion. This was just one more demo of it. No need to apologize
- at least me :)

And while you can call someone's opinion the way you like - the fact that
SRv6 builds on top of IPv6 does not make it automatically IPv6 extension.

My perhaps subtle point was that while politically it has been sold like
minor IPv6 extension from technical point it does not need to be
positioned like one. The sole fact that it reuses the same ethertype does
not make it an extension.

Now as I have already been through my round of circular explanations in the
previous months - now I just sit and watch how it goes round and round
again.

Best,
R.,

On Wed, Feb 26, 2020 at 8:22 PM Sander Steffann <[email-masked]> wrote:

> Hi,
> that's it. With that in mind all of this going back and forth between
> SPRING and 6MAN to me is triggered by wrong positioning of SRv6 as a new
> transport.
> >
> > This is completely bogus. SRv6 is not a new L3 protocol that just
> happens to be compatible with IPv6. That is insane BS.
>
> I have been told by good friends that my language was inappropriate. It
> probably is, but I'm not going to apologize for it. I and others have tried
> the polite way unsuccessfully and are still ignored by the authors. This
> has been going on for far too long, and if it's necessary that someone
> stops being polite and call it out then I'll be the one to do it.
>
> Cheers,
> Sander
>
>
>

---

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 21:07:44 +0100

Hi Robert,

> No worries ... three IPv6 musketeers have already presented themselves well to this discussion. This was just one more demo of it. No need to apologize - at least me :)
> 
> And while you can call someone's opinion the way you like - the fact that SRv6 builds on top of IPv6 does not make it automatically IPv6 extension.

Yes it does. It uses the IPv6 header with IPv6 extension headers with IPv6 addresses. SRv6 packets are IPv6 packets, and therefore have to follow IPv6 semantics. If you want to create an exception to that, then RFC8200 is the place to be.

> My perhaps subtle point was that while politically it has been sold like minor IPv6 extension from technical point it does not need to be positioned like one. The sole fact that it reuses the same ethertype does not make it an extension.

Oh yes, it also uses the IPv6 ethertype. I almost forgot that one. SRv6 is still based on an IPv6 *Extension* Header.

> Now as I have already been through my round of circular explanations in the previous months - now I just sit and watch how it goes round and round again.

Happy to hear you're giving up on pushing a draft that violates RFC8200 by claiming that SRv6 doesn't have to follow the RFC that it is based on because SRv6/NP is special, SRv6/NP is not really IPv6, IPv6 addresses as used by SRv6/NP aren't really IPv6 addresses etc.

Instead of trying to squeeze your way through with all these excuses, why not simply acknowledge the comments that PSP violates RFC8200, and either work on updating RFC8200 or removing PSP (whose benefits have been questioned on their own)? Work with this community and the operators to gain actual consensus, not some parody of consensus by trying to bend the rules when you don't like them.

You could easily get my consent by removing PSP from the draft. It violates RFC8200 and for what? What makes PSP so important that the draft would be unworkable without it? Why do you rather play these games than adjust the draft based on honest feedback? What hidden agendas are there? Because based on everything I have seen PSP is a minor feature that is implemented in a very controversial way. Why is it worth all this nonsense? (and I mean nonsense in the literal way: it really doesn't make sense to me)

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 17:09:47 -0300

On 26/2/20 16:44, Robert Raszuk wrote:
> Hey Sander,
> 
> No worries ... three IPv6 musketeers have already presented themselves 
> well to this discussion. This was just one more demo of it. No need to 
> apologize - at least me :)
> 
> And while you can call someone's opinion the way you like - the fact 
> that SRv6 builds on top of IPv6 does not make it automatically IPv6 
> extension.
> 
> positioned like one. The sole fact that it reuses the same ethertype 
> does not make it an extension.

Yeah, it's not an extension: it's a major surgery to IPv6, and a major 
change to the IPv6 architecture (nobody would even call it "IPv6 
maintenance").

A number of us wonder how many milliseconds it would have taken for this 
proposal to be shot down if it wasn't being pushed by a big vendor.

Thanks,

---

From: "john leddy.net" <[email-masked]>
Date: Wed, 26 Feb 2020 15:22:02 -0500 (EST)

I would suggest that people read RFC 7282 - "On Consensus and Humming in the IETF"...

My question is: How do you reach Consensus when the complaint is about how many milliseconds it takes to shoot down a proposal?

Is this about the proposal or the vendor involved?

---

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 21:24:31 +0100

Hi John,

> Is this about the proposal or the vendor involved?

Definitely the proposal. That a vendor seems to have an inappropriate amount of influence on the IETF process is just an additional concern.

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 21:27:52 +0100

> Definitely the proposal. That a vendor seems to have an inappropriate amount of influence on the IETF process is just an additional concern.

PS: that the vendor is Cisco in this instance is not relevant. Any vendor doing this would be equally bad. Any major vendor has played inappropriate games using the IETF. This is just what is currently on the table.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 17:40:27 -0300

> My question is: How do you reach Consensus when the complaint is about how many milliseconds it takes to shoot down a proposal?

This document proposes a *major* change to IPv6. This group has been way 
overly conservative even for very minor modifications to the IPv6 specs, 
well within 6man charter.

Given that, I would have expected that a long time ago, a long queue of 
folks (including the relevant AD) had made it crystal clear that this is 
an update to RFC8200, and given the depth of the change, outside of the 
charter of 6man.

It is in a way unbelievable the amount of energy we spend on polishing 
maintenance updates to IPv6, but then fail to even recognize that what's 
being proposes by this document is a major update to IPv6, out of the 
scope of 6man (which stands for "IPv6 maintenance", and not for "IPv6 
major surgery").

The amount of nonsense we have had to deal with, including this proposal 
not violating RFC8200, this proposal being something else other than 
IPv6, etc., has also been pointed out by others.

> Is this about the proposal or the vendor involved?

It is about the proposal, indeed. I have sent dozens of emails 
expressing technical concerns for this proposal. And the only reference 
to "vendors" has been about the conjecture regarding why it has been 
acceptable for us being fooled around.

Full disclosure: You didn't ask, but I don't mind being very open about 
it: I don't work for any router vendor, or OS vendor, nor do I have any 
kind of ongoing, past, or future contract with any of them, or any other 
party involved in a competing technology.

I have technical concerns about the proposal (expressed ad nauseam), and 
also concerns about how this process has been going on.

Thanks,

---

From: "john leddy.net" <[email-masked]>
Date: Wed, 26 Feb 2020 16:02:44 -0500 (EST)

So you are saying that other than the PSP issue, you support moving the document forward?

> On February 26, 2020 at 3:40 PM Fernando Gont <[email-masked]> wrote:
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 18:18:45 -0300

> So you are saying that other than the PSP issue, you support moving the document forward?

A number of us had repeatedly expressed their concerns with the 
document. Please check the mailing-list archives.

I haven't argued in favor or against the document. I simply asked the 
existing specifications be complied with.

It's a waste of time to be rehashing the same discussions all the time.

Thanks,

---

From: Sander Steffann <[email-masked]>
Date: Wed, 26 Feb 2020 22:20:41 +0100

Hi John,

> So you are saying that other than the PSP issue, you support moving the document forward?

Yes. As long as it doesn't violate existing RFCs and with that potentially causes trouble for implementations that expect those RFCs to be followed I'm fine with it. It's not something I would deploy, but I'm not going to stand in the way of those who want it if it's not going to hurt others.

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 18:26:02 -0300

> Yes. As long as it doesn't violate existing RFCs and with that potentially causes trouble for implementations that expect those RFCs to be followed I'm fine with it. It's not something I would depl…

Indeed, that's the underlying principle: don't violate existing specs, 
and if you mean to, propose a formal update of RFC8200.

(I don't remember of the top of my head if PSP was the only part of the 
document violating RFC8200, hence my general comment).

---

From: Mark Smith <[email-masked]>
Date: Thu, 27 Feb 2020 08:30:43 +1100

> No worries ... three IPv6 musketeers have already presented themselves well to this discussion. This was just one more demo of it. No need to apologize - at least me :)

You realise that the 3 musketeers were heroes in that story?

> And while you can call someone's opinion the way you like - the fact that SRv6 builds on top of IPv6 does not make it automatically IPv6 extension.

SRv6 is not building on top of IPv6 when it is proposing fundamental
changes to the way IPv6 packets are processed.

SPRING WG charter:

"SPRING WG should avoid modification to existing data planes that would
make them incompatible with existing deployments. Where possible,
existing control and management plane protocols must be used within
existing architectures to implement the SPRING function."

Regards,
Mark "Athos" Smith.

>> I have been told by good friends that my language was inappropriate. It probably is, but I'm not going to apologize for it. I and others have tried the polite way unsuccessfully and are still ignored by the authors. This has been going on for far too long, and if it's necessary that someone stops being polite and call it out then I'll be the one to do it.
>>
>> Cheers,
>> Sander
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Feb 2020 01:29:23 +0100

> You realise that the 3 musketeers were heroes in that story?

Oh I do.

And I want to sincerely congratulate three of you to be very effective to
discourage touching IPv6, its dogmas and principles. If this is good for
the industry, time will tell.

To me I got even more assurance now that IPv6 with its 40 octet fixed
header is a broken concept and deserves to be obsolete very soon -
especially for intra-domain use cases.

Btw new data plane much more efficient can be easily made compatible with
all existing and deployed v6 capable data plane hardware. If I would work
for a vendor perhaps I would have some cycles to propose it, but otherwise
it is just impossible to get sufficient support and get through with new
technology.

Kind regards,
RR.

PS. @Fernando ... you keep forgetting in your post and your errata about
RFC2473. I recommend you take a new read of it including section 3.1 and
match it against your IPv6 end to end principle. It is roto operational
principle behind SRv6.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 27 Feb 2020 21:11:00 +0000

Mark AH is not defined for SRH.  There is no specification to ignore.

Recall RFC8200 says nothing about mutability, it only describes things that are
modified in flight and how/why.

RFC4301 builds on RFC8200 to define mutability for use in AH ICV computation
without having to modify RFC8200.  “Mutability" is not defined for IPv6 headers
for any other reason.

draft-ietf-6man-semgnet-routing-header builds on RFC8200 to define a new RH
type without modifying RFC8200.

draft-ietf-spring-srv6-network-programming builds on RFC8200 and
draft-ietf-6man-segment-routing-header to define useful SIDs, their behaviors
and signaling within an SR domain without modifying any of the base specifications.

Of course RFC8200 has text covering the validity of extension header insertion,
deletion and processing at node(s) identified in the IPv6 destination address (Section 4).
As we all know, routing headers can’t work if a segment endpoint can’t
process extension headers.  Using this fact, PSP builds on RFC8200 to
offer new functionality within an SR Domain.

Of course RFC4301 says AH processing for new extension headers are outside its
scope, one can define AH processing for SRH with knowledge of, and building on,
all the above. Or they can just use ESP.

There is no ignoring here.
There is conscious and careful building on existing standards as they are written.

Darren

On Feb 26, 2020, at 6:57 AM, Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, 26 Feb 2020, 20:50 Xiejingrong (Jingrong), <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mark,
I think both AH and PSP are optional.
If AH is desired to deploy, then the operator can choose not to use PSP.
If AH is not deployed, and the operator has its requirements of incremental-deployment, then the operator can choose to use PSP.

You've missed the point. AH is an assurance mechanism for something that should *already* be happening - processing packets in accordance with RFC 8200.

RFC4301:
3.2.  How IPsec Works

Thanks,
Jingrong

-----Original Message-----
From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mark Smith
Sent: Wednesday, February 26, 2020 8:31 AM
To: Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Is srv6 PSP a good idea

Hi Pablo,

Immutable
           Version
           Payload Length
           Next Header
           Source Address

   Mutable but predictable

Regards,
Mark.

> To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "Joel M.
> Halpern" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Feb 2020 19:11:01 -0300

> Mark AH is not defined for SRH.  There is no specification to ignore.

Do you realize that you are using IPv6, and that AH is specified for IPv6?

Is the AD watching? -- Seriously, this is going through a very curious 
and dangerous path.

For the interested reader, a longer explanation of the issue:
https://mailarchive.ietf.org/arch/msg/ietf/sbb95BqdPifuRb_NPc3aeiqBbfM/

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 28 Feb 2020 02:04:10 +0000

Ridiculous ..  any NOS coder, coding IPv6, would have awareness of 2460, why would you even go there .. seriously ?

The highlight was for: https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#page-4 - you should probl read it all.

I think we've reach the limit of what the "IETF email" can offer for such debate. We should probably have a call or meet at 107.

While reading the "longer explanation", don't forget to lookup the reply here:
https://mailarchive.ietf.org/arch/msg/ietf/rtMom05r7_pLq1zN2lf16_B58mE/

dan

On 2020-02-27, 5:11 PM, "spring on behalf of Fernando Gont" <[email-masked] on behalf of [email-masked]> wrote:

    

    Thanks,

    _______________________________________________
    spring mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/spring
    ------------------------------------------------------------------------------
    External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints