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

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 26 Feb 2020 14:01:00 +0000

Hi Mark,

Thank you for your feedback. Please see inline [PC1].

Cheers,
Pablo.

-----Original Message-----
From: Mark Smith <[email-masked]>
Date: Wednesday, 26 February 2020 at 01:31
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Ron Bonica <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Is srv6 PSP a good idea

    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.

[PC1]: Did you just make this up? ;-) RFC8200 does not talk about mutability.
    
    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.
    
[PC1]: I disagree with you. As a matter of fact RFC8200 allows the deletion of an extension header at a node identified in the destination address of the packet (page 8 paragraph 2). 
Please see these emails from other people who state the opposite from you:
https://mailarchive.ietf.org/arch/msg/ipv6/Ypnpw-oneCb7W6s41dVZGMok0Nw/
https://mailarchive.ietf.org/arch/msg/spring/pGS5O53VTDSt2tpc7mm3FVVd0Xk/
https://mailarchive.ietf.org/arch/msg/spring/i0faTfqB-NduzI2VyMyQ6R60dQw/
https://mailarchive.ietf.org/arch/msg/spring/JdpSLS7ax0VUZLG6SINxnOWJzbY/
https://mailarchive.ietf.org/arch/msg/spring/plidxjZFBnd4_mEzGsLC76FZmQ0/
https://mailarchive.ietf.org/arch/msg/spring/67ZG76XRezPXilsP3x339rGpcso/
    
    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.

[PC1]: Did you also just make up this “quality assurance” thing? I have not found a reference to it in RFC4302 or RFC4301. RFC4301 contains a good section 2.1 describing the Design Objectives. It only talks about interoperable cryptographically-based security.     
    
    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.

[PC1]: 
- As described in https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-7.5 , AH is not required to secure the SR Domain. For this reason, the use of AH at the SR source node is out of the scope of this document.
- Regardless of the above, please keep in mind that the PSP flavor is indicated in the control-plane advertisement of the SID (e.g., in ISIS), as part of the behavior identifier. A source node using AH in combination with SRv6 can thus ensure that the SRH will remain in the packet until the final destination by selecting a penultimate SID that does not have the PSP flavor.     

    > 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."

[PC1]: Is this a technical argument?

[PC1]: Operators can freely choose what to do in their network. PSP is optional. They have stated the benefits of PSP, and we know that at least half of the public SRv6 deployments are using it.
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].
And additionally, operators have expressed their value in [4] and [5].
 [1].- https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0
[2].- https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c
[3].- https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0
[4].- https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk
[5].- https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI
    
    How much troubleshooting experience have they had with this?

[PC1] Operators who have deployed stated that this is not operationally complex.

    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.

[PC1] Please take a look at the list of operators that have deployed this in their production network that is so core to their business. You seem to be raising doubts about operational aspects of their network. This doesn’t look like a technical argument. If you are questioning their experience and deployment decision; well, up to you to do it.    
    
    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: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 11:35:51 -0300

On 26/2/20 11:01, Pablo Camarillo (pcamaril) wrote:
> Cheers, Pablo.
> -----Original Message----- From: Mark Smith
> <[email-masked]> Date: Wednesday, 26 February 2020 at 01:31 
> To: "Pablo Camarillo (pcamaril)" <[email-masked]> Cc: Ron Bonica
> <[email-masked]>, "Joel M. Halpern" <[email-masked]>,
> "[email-masked]" <[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 “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.
> 
> flight between the packet's original source and final destination,
> nor is there anything in RFC 8200 that specifies how to do those 
> [PC1]: I disagree with you. As a matter of fact RFC8200 allows the
> deletion of an extension header at a node identified in the
> destination address of the packet (page 8 paragraph 2). 

Unfortunately, the amount of creativity that has been applied during the 
last few years when it comes how to read RFC2460 and RFC8200 has meant 
that we have had to work harder and harder to clarify the wording in 
RFC2406 and RFC8200 for folks to understand and recognize what has 
always been the specification and intent of IPv6.

I have made yet another attempt to clarify the text here: 
https://www.rfc-editor.org/errata/eid5933

I'd hope that the submitted errata is processed, the existing spec is 
honored and respected, and folks submit a formal specification update if 
they mean to change IPv6 -- as opposed to try to circumvent the spec for 
the n-th try.

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

---

From: Dirk Steinberg <[email-masked]>
Date: Wed, 26 Feb 2020 17:45:17 +0200

Hi Fernando,

I am amazed to read that you believe that you
have the sole power to retroactively re-interpret the
wording of existing RFCs and make changes to said
wording to give documents that have existed for
many years (RFC2460 more than 20 years) a
new meaning.

Interesting.

Where can I obtain such superpowers?

Best,
Dirk

---

From: Dirk Steinberg <[email-masked]>
Date: Wed, 26 Feb 2020 17:57:17 +0200

Hi Fernando,

adding to my own comment and to be more specific:

The existing RFCs are very clear in their wording that
the node identified in the Destination Address field of
the  IPv6 header is free to do whatever it desires with
the packet it just received. After all, the packet was
addressed specifically to that node.

These nodes are called segment endpoint nodes in SRv6.

Only nodes that are *NOT* identified in the DA are
prohibited from making any changes.

This should be very clear, even if you seem to
wish that IPv6 had been defined differently.

Best,
Dirk

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Feb 2020 13:54:44 -0300

> wish that IPv6 had been defined differently.

Are you saying that IPv6 allows for in the network header insertion/removal?

If so, please tell me how AH, Path-MTU Discovery, and ICMPv6 error 
reporting works -- all very basic functions of IPv6.

IPv6 is an end to end protocol. With RH you change the DA on the flight, 
because routing only works based on the DA -- there's no other way to 
specify waypoints.

If you claim otherwise, that can be, at best, a major misunderstanding 
of how IPv6 works.

Thanks,

---

From: Dirk Steinberg <[email-masked]>
Date: Wed, 26 Feb 2020 19:50:47 +0200

> Are you saying that IPv6 allows for in the network header

No, not on a transit node.

Yes, in SRv6 on a segment endpoint node.
And that is not plain IPv6 anymore, that is
the innovation the SRv6 brings along.

> IPv6 is an end to end protocol.

The IPv6 you are referring to (end-to-end user traffic)
must not be confused with what SRv6 is. SRv6 will
always encapsulate said user traffic and NOT modify
it at all -- just like you demand. Therefore on that user
plane all functions that you talk about will continue
to function as before, AH, PMTU, and all.
Managing MTU so as not to blow up within a carrier network
has been done successfully with MPLS for more than 20 years.

SRv6 should be understood for what it is -- a modern successor
to MPLS to be used as both an underlay and service layer,
managed within a well-defined network domain.

SRv6 SRH should never occur directly within the user IPv6
header but only within the header added and owned by the
carrier running SRv6. And within their own header the
network operator, after receiving the packet at the IPv6 DA,
can make changes. It's their own private header, just like
the MPLS label stack in SR-MPLS.

If you want to take a really orthodox and strict viewpoint
maybe you should view the "end-to-end" IPv6 relation
as being segment endpoint to segment endpoint only.
Each new SRv6 segment opens up a new IPv6 end-to-end
relation, whereas the "end-to-end" relation from the SRv6
point of view is at a higher layer.

Then of course you could also adopt a more liberal viewpoint
and just view the entire end-to-end SRv6 path as one
end-to-end IPv6 entity as well without considering the
underlying segment endpoints as IPv6 endpoints.

With RH you change the DA on the flight,

No -- you do not change DA in flight -- only on segment endpoints
which are the DA of the IPv6 packet. When IPv6 was defined
decades ago nobody was thinking about SRv6. That notion was
not present then -- otherwise one might have indeed clarified some
of the points that are debated today. But just because the inventors
of IPv6 did not think to include SRv6 capabilities from the start
this should not be used as an excuse to block innovation.

One could, of course, just say that SRv6 is a completely new animal
to completely avoid the current type of discussion and just redefine
everything from scratch. But why should we do such a thing?
IMHO it is much better to take existing IPv6 and innovate by
extending it -- not changing existing behavior -- in ways that had
never been envisioned by the original authors of IPv6.
That is what SRv6 is doing.

> of how IPv6 works.

SRv6 is not the same as IPv6.

Maybe there is a misunderstanding about SRv6 here.

Cheers
Dirk

Thanks,