Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

From: [email-masked]
Date: Sun, 23 Feb 2020 12:06:05 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the IETF.

        Title           : SRv6 Network Programming
        Authors         : Clarence Filsfils
                          Pablo Camarillo Garvia
                          John Leddy
                          Daniel Voyer
                          Satoru Matsushima
                          Zhenbin Li
	Filename        : draft-ietf-spring-srv6-network-programming-10.txt
	Pages           : 38
	Date            : 2020-02-23

Abstract:
   The SRv6 Network Programming framework enables a network operator or
   an application to specify a packet packet processing program by
   encoding a sequence of instructions in the IPv6 packet header.

   Each instruction is implemented on one or several nodes in the
   network and identified by an SRv6 Segment Identifier in the packet.

   This document defines the SRv6 Network Programming concept and
   specifies the base set of SRv6 behaviors that enables the creation of
   interoperable overlays with underlay optimization (Service Level
   Agreements).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-10
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Sun, 23 Feb 2020 20:10:42 +0000

Hi all,

We have published a new update to draft-ietf-spring-srv6-network-programming. This revision simplifies the counters as per [1], clarifies the upper layer header processing as per [2] and removes the reference to the OAM draft [3].

Thank you for the review and feedback. 

Cheers,
Pablo.

[1].- https://mailarchive.ietf.org/arch/msg/spring/HbDXXETZI1DGZ6J7TbUHQFE1FDU/
[2].- https://mailarchive.ietf.org/arch/msg/spring/4uOBM2lyA_Gg6RCczgZD93lNjZU/
[3].- https://mailarchive.ietf.org/arch/msg/spring/HbDXXETZI1DGZ6J7TbUHQFE1FDU/

-----Original Message-----
From: spring <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Reply to: "[email-masked]" <[email-masked]>
Date: Sunday, 23 February 2020 at 21:06
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

    
    Abstract:

    

    

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

---

From: Sander Steffann <[email-masked]>
Date: Sun, 23 Feb 2020 21:46:51 +0100

Hi,

> We have published a new update to draft-ietf-spring-srv6-network-programming. This revision simplifies the counters as per [1], clarifies the upper layer header processing as per [2] and removes th…

I still oppose the segment popping flavours in section 4.16 without updating RFC8200.

Cheers,
Sander

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Feb 2020 08:49:34 +1100

On Mon, 24 Feb 2020, 07:47 Sander Steffann, <[email-masked]> wrote:

> Hi,
>
> > We have published a new update to
> draft-ietf-spring-srv6-network-programming. This revision simplifies the
> counters as per [1], clarifies the upper layer header processing as per [2]
> and removes the reference to the OAM draft [3].
>

I would expect that defying Internet Standard 86/RFC8200 means this ID
needs to have Experimental rather than Standards Track status.

---

From: Andrew Alston <[email-masked]>
Date: Mon, 24 Feb 2020 10:06:21 +0000

I agree with the sentiments expressed below

Andrew

From: spring <[email-masked]> On Behalf Of Mark Smith
Sent: Monday, 24 February 2020 00:50
To: Sander Steffann <[email-masked]>
Cc: SPRING WG <[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

On Mon, 24 Feb 2020, 07:47 Sander Steffann, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I would expect that defying Internet Standard 86/RFC8200 means this ID needs to have Experimental rather than Standards Track status.

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: Ron Bonica <[email-masked]>
Date: Mon, 24 Feb 2020 15:26:47 +0000

Folks,

We may need to ask the following questions:

  1.  Does PSP violate letter of RFC 8200?
  2.  Does PSP violate the spirit of RFC 8200?
  3.  Is PSP a good idea?

The 6man WG, and not SPRING, should answer the first two questions. So I will avoid them an explore the third.

At first glance, PSP adds no value. Once Segments Left has been decremented to 0, the Routing header becomes a NOOP. So why bother to remove it? I see the following arguments:

  1.  To save bandwidth between the penultimate and ultimate segment endpoints.
  2.  To unburden the ultimate segment endpoint from the task of processing the SRH
  3.  To unburden the ultimate segment endpoint from the task of removing the SRH

The first argument is weak. Routing headers should not be so large that the bandwidth they consume is an issue.

The second argument is also weak. Once the ultimate segment endpoint has examined the Segments Left field, it can ignore the SRH. The ultimate segment endpoint must be SRv6-aware, because it must process the SID in the IPv6 destination address field. Given that the ultimate segment endpoint is SRv6 aware, it should be able to process the SRH on the fast path.

The third argument is even weaker. The ultimate segment endpoint:

  *   Has to remove the IPv6 tunnel header, anyway
  *   Being closer to the edge, may be less heavily loaded than the penultimate segment endpoint.

Can anyone articulate a better justification for PSP? If not, why test the limits of RFC 8200 over it?

                                                                                                           Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Andrew Alston
Sent: Monday, February 24, 2020 5:06 AM
To: Mark Smith <[email-masked]>; Sander Steffann <[email-masked]>
Cc: SPRING WG <[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Mark Smith
Sent: Monday, 24 February 2020 00:50
To: Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:pcamaril=[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Cheers,
Sander

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Tfl9m_at6pZSp38lOtxE5WZLnsW_ojrgXUvQ_Rx-tN4MY7qa-MtwIQWgGCTduGJT$>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 24 Feb 2020 22:38:29 +0000

Ron,

This is the 5th time that we have this discussion in the past five months.

I consider those three questions as closed based on the previous discussion.
https://mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/

Cheers,
Pablo.

From: Ron Bonica <rbonica=[email-masked]>
Date: Monday, 24 February 2020 at 16:27
To: Andrew Alston <[email-masked]>, Mark Smith <[email-masked]>, Sander Steffann <[email-masked]>
Cc: SPRING WG <[email-masked]>, "Pablo Camarillo (pcamaril)" <[email-masked]>
Subject: RE: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Folks,

1)      Does PSP violate letter of RFC 8200?

2)      Does PSP violate the spirit of RFC 8200?

3)      Is PSP a good idea?

1)      To save bandwidth between the penultimate and ultimate segment endpoints.

2)      To unburden the ultimate segment endpoint from the task of processing the SRH

3)      To unburden the ultimate segment endpoint from the task of removing the SRH

-          Has to remove the IPv6 tunnel header, anyway

-          Being closer to the edge, may be less heavily loaded than the penultimate segment endpoint.

                                                                                                           Ron

Andrew

Cheers,
Sander

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 24 Feb 2020 18:35:20 -0500

PSP has historical context from PHP ( Penultimate Hop POP) in the MPLS
world.

20+ years ago when MPLS we originally developed the concept of PHP implicit
null reserved label value 0 was done to offload the burden of the egress PE
FEC destination to pop the entire label stack before forwarding the native
IP packet to the CE.

Hardware these days for the last 15 years or so are so advanced that the
idea that you are saving processing on the egress PE has not existed for a
long time.

Even  back then in both SP and enterprise space there were issues that
arise related to PHB QOS egress queuing,  that occurs on the PHP node that
had the MPLS shim popped, it cannot schedule on the topmost label via exp
provider markings done on the ingress PE upon label imposition.

A workaround to this issue was to set explicit null label value 0 and use
pipe or uniform mode to tunnel the customer payload to the egress PE FEC
destination called UHP ultimate hop node with topmost label intact.

The concept of implicit null PHP concept did not bode well in the MPLS
world so I don’t see why that feature parity would be added to a next gen
protocol that would be the future MPLS replacement.

I agree with taking some of the good features and knobs from MPLS, but why
take the ones like implicit null with is really an archaic feature.

My 2 cents

Gyan

On Mon, Feb 24, 2020 at 5:38 PM Pablo Camarillo (pcamaril) <pcamaril=
[email-masked]> wrote:

> *From: *Ron Bonica <rbonica=[email-masked]>
> *Date: *Monday, 24 February 2020 at 16:27
> *To: *Andrew Alston <[email-masked]>, Mark Smith <
> [email-masked]>, Sander Steffann <[email-masked]>
> *Cc: *SPRING WG <[email-masked]>, "Pablo Camarillo (pcamaril)" <
> [email-masked]>
> *Subject: *RE: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
> Folks,
>
>
>
> At first glance, PSP adds no value. Once Segments Left has been
> decremented to 0, the Routing header becomes a NOOP. So why bother to
> remove it? I see the following arguments:
>
>
>
> The second argument is also weak. Once the ultimate segment endpoint has
> examined the Segments Left field, it can ignore the SRH. The ultimate
> segment endpoint must be SRv6-aware, because it must process the SID in the
> IPv6 destination address field. Given that the ultimate segment endpoint is
> SRv6 aware, it should be able to process the SRH on the fast path.
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Andrew Alston
> *Sent:* Monday, February 24, 2020 5:06 AM
> *To:* Mark Smith <[email-masked]>; Sander Steffann <
> [email-masked]>
> *Cc:* SPRING WG <[email-masked]>; Pablo Camarillo (pcamaril) <pcamaril=
> [email-masked]>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Mark Smith
> *Sent:* Monday, 24 February 2020 00:50
> *To:* Sander Steffann <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>; Pablo Camarillo (pcamaril) <
> pcamaril=[email-masked]>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Tfl9m_at6pZSp38lOtxE5WZLnsW_ojrgXUvQ_Rx-tN4MY7qa-MtwIQWgGCTduGJT$>
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Feb 2020 10:39:23 +1100

> https://mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/

Ron isn't the only arbiter that you and the SPRING WG have to satisfy.

If the discussion has come up 5 times in the past 5 months, yet hasn't
been resolved, then I think it says SPRING aren't trying to act in
good faith to attempt to comply with another IETF working group's
widely deployed, full Internet Standard protocol, one of only 92
Internet Standards since 1969.

I'm reminded of when the ITU did something similar to the IETF. I
think it is now one IETF WG doing a similar thing to another.

RFC5704, "Uncoordinated Protocol Development Considered Harmful"

https://tools.ietf.org/html/rfc5704

s/SDO/IETF WG/gc

"In particular, the
   IAB considers it an essential principle of the protocol development
   process that only one SDO maintains design authority for a given
   protocol, with that SDO having ultimate authority over the allocation
   of protocol parameter code-points and over defining the intended
   semantics, interpretation, and actions associated with those code-
   points."

SPRING are also ignoring its own 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."

PSP is not required, there are existing functional equivalents that
are compatible with existing deployments.

(I have no affiliation with any vendors, I fight for the users.)

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 25 Feb 2020 15:16:40 +0000

Gyan,

As I (and other WG members) have explained in the past, PSP is not trying to provide any feature parity with MPLS.

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].
There is substantial benefit. Four operators have deployed PSP, which proves the benefit.
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

I don't see the point of starting a new thread from zero that discusses the same thing.

Cheers,
Pablo.

From: Gyan Mishra <[email-masked]>
Date: Tuesday, 25 February 2020 at 00:35
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Ron Bonica <[email-masked]>, SPRING WG <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

PSP has historical context from PHP ( Penultimate Hop POP) in the MPLS world.

20+ years ago when MPLS we originally developed the concept of PHP implicit null reserved label value 0 was done to offload the burden of the egress PE FEC destination to pop the entire label stack before forwarding the native IP packet to the CE.

Hardware these days for the last 15 years or so are so advanced that the idea that you are saving processing on the egress PE has not existed for a long time.

Even  back then in both SP and enterprise space there were issues that arise related to PHB QOS egress queuing,  that occurs on the PHP node that had the MPLS shim popped, it cannot schedule on the topmost label via exp provider markings done on the ingress PE upon label imposition.

A workaround to this issue was to set explicit null label value 0 and use pipe or uniform mode to tunnel the customer payload to the egress PE FEC destination called UHP ultimate hop node with topmost label intact.

The concept of implicit null PHP concept did not bode well in the MPLS world so I don’t see why that feature parity would be added to a next gen protocol that would be the future MPLS replacement.

I agree with taking some of the good features and knobs from MPLS, but why take the ones like implicit null with is really an archaic feature.

My 2 cents

Gyan

On Mon, Feb 24, 2020 at 5:38 PM Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:[email-masked]>> wrote:
Ron,

Cheers,
Pablo.

From: Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>
Date: Monday, 24 February 2020 at 16:27
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>, Mark Smith <[email-masked]<mailto:[email-masked]>>, Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>, "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Folks,

3)      Is PSP a good idea?

                                                                                                           Ron

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Andrew Alston
Sent: Monday, February 24, 2020 5:06 AM
To: Mark Smith <[email-masked]<mailto:[email-masked]>>; Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>; Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Andrew

Cheers,
Sander

Email: [email-masked]<mailto:[email-masked]>

---

From: "Voyer, Daniel" <[email-masked]>
Date: Tue, 25 Feb 2020 15:28:00 +0000

Mark, no need to drag this conversation to the other corner either ..

Pablo pasted the email thread, here once again:  https://mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/

If you think it's not closed, then go back to the email trail and keep adding to it. I'm curious to see what you can add ..

dan

On 2020-02-24, 6:39 PM, "spring on behalf of Mark Smith" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    
    s/SDO/IETF WG/gc
    
    "In particular, the

    

    
    _______________________________________________
    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

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 25 Feb 2020 15:23:06 +0000

Mark,

The point that you are making has already been addressed at the mailer (and indeed you have participated in such discussion)
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/

I don't see the point of starting a new thread from zero that discusses exactly the same thing.

Cheers,
Pablo.

-----Original Message-----
From: Mark Smith <[email-masked]>
Date: Tuesday, 25 February 2020 at 00:40
To: "Pablo Camarillo (pcamaril)" <[email-masked]>
Cc: Ron Bonica <[email-masked]>, SPRING WG <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

    On Tue, 25 Feb 2020 at 09:38, Pablo Camarillo (pcamaril)
    <pcamaril=[email-masked]> wrote:
    >
    > Ron,
    >
    >
    >
    > This is the 5th time that we have this discussion in the past five months..
    >
    >
    >

    

    
    s/SDO/IETF WG/gc
    
    "In particular, the

    

    > To: Mark Smith <[email-masked]>; Sander Steffann <sander@steffann..nl>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 27 Feb 2020 02:14:15 -0500

In-line response

On Tue, Feb 25, 2020 at 10:16 AM Pablo Camarillo (pcamaril) <
[email-masked]> wrote:

> [1].-
> https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0
>

(1) reduce the load of final destination. This benefit can be notable
for the following sub reasons.

I know you say you are not trying to create any feature parity with
MPLS however by using PSP is similar to PHP in that you are trying to
offload processing on the end X node in which could be any node in the
path and not just the PHP node.

With SRv6 the loophole created here is that at each hop along the
traffic engineered path, the SID in the SL is popped and copied to the
DA hop by hop - so each hop being a single hop End X SID
instantiation, the PSP function of SRH removal can now occur at any
node along the path and not just the MPLS style one hop prior to
ultimate hop egress PE node.

So PSP is being leveraged to be used at any end X and not just the
final destination.  This makes the situation worse for RFC 8200
violations.

What would be the use case where you would need to pop the SRH early
at an End X node that is not the final destination.  The SL has to be
0 to pop the SRH.  Please correct me then if the PSP function can only
occur at the final destination one hop prior PHP node.

(1.1) final destination tends to have heavy load. It need to handle
all the EHs and do the delivery/demultiplex the packet to the right
overlay service.

Does the egress PE really have a heavy load with modern hardware.

How is the PSP function with modern hardware any more difficult
popping the SRH on the final destination node then with MPLS explicit
null UHP.

Other then the 6in6 topmost SRv6 encapsulation that is popped at the
final destination which is different then MPLS 4 byte shim topmost,
with the bottom stack labels being identical in both scenarios, is
there really extra load on the final destination egress PE that is
being saved??

(1.2) example 1, the final destination may need to handle the DOH after the RH.

DOH would be set in the encapsulated packet in the customer payload
that is tunneled 6in6 over the provider network. Doubtful that DOH
would be set in the SP SRv6 closed domain

(1.3) example 2, the final destination may need to do the assembly of
fragmented packets.

In general almost across the board all providers set their MTU to 9216
jumbo so as to not have outer 6in6 SRv6 header fragmentation issues

(1.4) example 3, the final destination may need to do AH/ESP after the
Fragmentation Header.

Just like 1.2 AH/ESP would be part of the customer payload encapsulated

(1.5) example 4, the final destination may need to deliver the packet
to the right overlay service.

In the SP network the packet is still forwarded hop by hop along the
SRH traffic engineered path to the prefix SID fec destination, which
is always the final destination in the SL, when SL is 0 the USP USD
deencapsulation occurs.  So in my mind the overlay service would not
ever be on an end DT transit node P router and would always sit on an
egress PE router.

Am I missing something?

(2) support the incremental deployment when final destination(s) do
not process/recognize SRH. This benefit can be notable for the
following sub reasons.

This is during interim migration, however I believe the best practice
for SRv6 brown field is to have the PEs SRv6 capable and the Ps IPv6
capable for End DT x transit node forwarding only - which P routers
should adhere strictly to RFC 8200 and should never have to perform or
technically even have to perform the PSP function.

In most SP networks the PEs are protocol and feature rich and have the
latest code and hardware where the P routers “BGP free” “pim free”
core - only perform label swapping in MPLS world and SR world only
label stacking.

(2.1) A core router may (fan-out) connected with a big number of
low-end routers that do not support SRH but support
tunnel-end/service-demultiplex function of SRv6.

Please elaborate on this scenario

<https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0>
>
> [2].-
> https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c
>

For example in SRv6-based L3VPN service scenario,  The ingress PE
within SRv6-enabled domain can utilize SR-TE policy to enable TE-path
function when encapsulating and transiting L3VPN traffic, The Ingress
PE push on customer packets with SID list representing SR-TE policy
plus END.DT4 as last SRv6 SID in SRH;  So I think,  each flavor of
PSP/USP/USD can be designed to perform in related SRv6 endpoint.
Imaging the PSP, the penultimate Endpoint can perform PSP, e.g. copy
the last SID (END.DT4) of SRH to destination field of IPv6 header and
POP the SRH, then forwarding it toward egress PE identified by DA.

This comment is what lead me to believe my comment in (1) then the PSP is
being leveraged as a loophole to be able to perform the PSP function at any
node and pop the SRH.

In thinking about this it does not make sense at all.

My thoughts are that the SRv6 source node ingress PE adds the SRH, and the
final destination node egress PE pops the SRH.  I don’t understand why any
P node along the path would ever pop the SRH if you have not made it yet to
the final destination.
Also in the SRv6 programming PSP psuedocode it states the SL=0 has to be
satisfied — so if you are on any P router and not at the final destination
prefix SID FEC,  then you are doing the standard IPv6 data plane forwarding
and end dt x node and copying hop by hop the SID to the DA.  Since the P
routers are doing standard IPv6 forwarding they must comply with RFC8200.

Am I missing something?

> <https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c>
>
> [3].-
> https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0
>

> Removing bytes (aor adding bytes) from arbitrary positions in the middle of a packet is generally any extremely painful operation.  Why would we want a standard that mandated such an operation?  Savings a few bytes on SR hop (sure, several IP router hops) seems a small benefit for such a cost.
>

I agree that not much savings adding the PSP function just to POP the
SRH at an end x node

That sounds weird comment for me. We have deployed that type of
function with no compromise in terms of of both performance and
operation within reasonable and affordable cost.

<https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0>
>
> [4].-
> https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk
>

As of the end of 2019, the SRv6 network consists of:
- 1000 Cisco NCS 5500 routers
- 1800 Iliad's Nodeboxes
- The network services 4.5 million mobile subscribers (as of Q3 2019)
- The network is carrying 300 Gbps of commercial traffic at peak hours
- It is expected to grow to more than 4000 Nodeboxes in 2020.

The following SRv6 features have been deployed:
- A Segment Routing Header based data plane
- End (PSP), End.X (PSP), End.DT4, T.Encaps.Red, T.Insert.Red functions
- BGP VPN SRv6 extensions
- ISIS SRv6 extensions
- SRH-based Topology Independent (TI-LFA) Fast Reroute mechanisms
- Support for ping and traceroute

Is this customer doing PSP in end x meaning any transit P router end dt x
node?

If so in those cases where the SRH is popped on end x node, was their a
service overlay or SFC at the P node which was the reason to pop the SRH
early on a transit P node.

> <https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk>
>
> [5].-
> https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI
>

PSP allows us to bring SRv6 to legacy PE devices that are not capable
of processing the SRH in the dataplane, but are capable of supporting
SRv6 in the control plane.

See this example:
I am streaming traffic from a server to a customer;
The ingress PE (near the server) encapsulates the packet and adds an
SRH with a low-latency list of segments;
The penultimate node in the SRH executes PSP;
The egress PE (near the customer) decapsulates the IPv6 header and
forwards the inner packet to the customer.

We can include SLA unidirectionally from the server to the customer
even though that the egress PE has a legacy ASIC. Legacy equipment are
a reality and are not easy to replace, hence interoperability with
brownfield is key for any innovative approach.

This is during migration however I believe the best practice for SRv6
brown field is to have the PEs SRv6 capable and the Ps IPv6 capable
for End DT x transit node forwarding only - which P routers should
adhere strictly to RFC 8200 and should never have to perform or
technically even have to perform the PSP function.

In most SP networks the PEs are protocol and feature rich and have the
latest code and hardware where the P routers “BGP free” “pim free”
only perform label swapping in MPLS world and SR world only label
stacking.

<https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Tuesday, 25 February 2020 at 00:35
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked]>
> *Cc: *Ron Bonica <[email-masked]>, SPRING WG <[email-masked]>
> *Subject: *Re: [spring] I-D Action:
> 20+ years ago when MPLS we originally developed the concept of PHP
> implicit null reserved label value 0 was done to offload the burden of the
> egress PE FEC destination to pop the entire label stack before forwarding
> the native IP packet to the CE.
>
>
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Ron Bonica <[email-masked]>
Date: Thu, 27 Feb 2020 18:38:06 +0000

Pablo,

The question at hand is whether PSP is so crucial to SRv6 that it is worth stretching the limits of RFC 8200 compliance. The emails that you site below say that it is for the following reasons:

  1.  Because PSP is already deployed
  2.  Because PSP unburdens the ultimate segment router from the task of processing and removing the SRH
  3.  Because PSP enables incremental deployment

The first argument can be dismissed out of hand. Just because something has been deployed doesn't mean that it adds value or even that it causes no harm.

The second argument is dubious. Given that the ultimate segment endpoint has to remove the outer IPv6 header and forward the packet, the additional cost of checking the Segments Left field and removing the SRH is minimal.

The third argument was best articulated Dan Voyer in https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/ and deserves some consideration. In his deployment scenario, the ultimate segment endpoint:

  *   Can process a SID, received as an IPv6 DA, on the fast path
  *   Cannot process an SRH, even if Segments Left equal 0, on the fast path.

In this scenario, PSP keeps packets off of that device's slow path.

While I have sympathy for Dan's dilemma, I wonder whether it is a good idea to stretch the IPv6 standard to accommodate IPv6-challenged devices.

Maybe a compromise is possible? Would it be possible to move discussion of the PSP out of the Network programming draft and into a separate draft that a) describes the use-case in which it is required and b) discourages its use in all other cases.

                                                                                                                         Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Tuesday, February 25, 2020 10:17 AM
To: Gyan Mishra <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Gyan,

Cheers,
Pablo.

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 25 February 2020 at 00:35
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>, SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

The concept of implicit null PHP concept did not bode well in the MPLS world so I don't see why that feature parity would be added to a next gen protocol that would be the future MPLS replacement.

My 2 cents

Gyan

I consider those three questions as closed based on the previous discussion.
https://mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYs9oOW3B$>

Cheers,
Pablo.

Folks,

3)      Is PSP a good idea?

                                                                                                           Ron

Andrew

Cheers,
Sander

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYkKy0jPv$>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Feb 2020 20:11:03 +0100

Ron,

How about we go the other way and really admit that some hardware just can
not PSP at line rate ?

But for that there is very simple solution - you advertise PSP depth of
zero in IGP extensions and you are done.

Both ISIS and OSPFv3 extensions support this already today.

And as it has been said and illustrated it does not stretch RFC8200 at all.
PSP is performed by node listed in DA of the arriving packet. Such node can
do whatever it want with the outer header of the packet. Some folks try to
punch holes in 8200 to cover their issues - is that in good spirit of IETF
?

Your idea of taking piece of the consistent spec away is very broken as it
now makes other documents inconsistent and blocks hardware where such
function is supported today at line rate.

Let the operator choose if he wants PSP or not and move on ...

Best,
R.

On Thu, Feb 27, 2020 at 7:39 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Pablo,
>
>
>
> The question at hand is whether PSP is so crucial to SRv6 that it is worth
> stretching the limits of RFC 8200 compliance. The emails that you site
> below say that it is for the following reasons:
>
>
>
> The first argument can be dismissed out of hand. Just because something
> has been deployed doesn’t mean that it adds value or even that it causes no
> harm.
>
>
>
> The second argument is dubious. Given that the ultimate segment endpoint
> has to remove the outer IPv6 header and forward the packet, the additional
> cost of checking the Segments Left field and removing the SRH is minimal.
>
>
>
> The third argument was best articulated Dan Voyer in
> https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/
> and deserves some consideration. In his deployment scenario, the ultimate
> segment endpoint:
>
>
>
>    - Can process a SID, received as an IPv6 DA, on the fast path
>    - Cannot process an SRH, even if Segments Left equal 0, on the fast
>    path.
>
>
>
> In this scenario, PSP keeps packets off of that device’s slow path.
>
>
>
> While I have sympathy for Dan’s dilemma, I wonder whether it is a good
> idea to stretch the IPv6 standard to accommodate IPv6-challenged devices.
>
>
>
> Maybe a compromise is possible? Would it be possible to move discussion of
> the PSP out of the Network programming draft and into a separate draft that
> a) describes the use-case in which it is required and b) discourages its
> use in all other cases.
>
>
>
>
>               Ron
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Pablo Camarillo
> (pcamaril)
> *Sent:* Tuesday, February 25, 2020 10:17 AM
> *To:* Gyan Mishra <[email-masked]>
> *Cc:* SPRING WG <[email-masked]>
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/yRkDJlXd71k0VUqagM3D77vYcFI/__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYs9oOW3B$>
>
>
>
> Cheers,
>
> Pablo.
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!TEtwPySm6G-5vGGZ1n_7cdy_CuLlKozmPjpyK5rOohk2yw1JV1unB51aYkKy0jPv$>
>
> --
>
> Gyan  Mishra
>

---

From: Andrew Alston <[email-masked]>
Date: Thu, 27 Feb 2020 20:02:51 +0000

Robert –

Do you know or can you please name any hardware that cannot do line rate PSP?  I could understand not being able to do USP at line rate – which may in certain implementations cause re-circulation (maybe THAT’S the unstated dirty secret that are keeping people pushing this without stating a use case?) – but PSP?

Andrew

From: ipv6 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, 27 February 2020 at 22:11
To: Ron Bonica <rbonica=[email-masked]>
Cc: SPRING WG <[email-masked]>, 6man WG <[email-masked]>, "Pablo Camarillo (pcamaril)" <pcamaril=[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Ron,

How about we go the other way and really admit that some hardware just can not PSP at line rate ?

But for that there is very simple solution - you advertise PSP depth of zero in IGP extensions and you are done.

And as it has been said and illustrated it does not stretch RFC8200 at all. PSP is performed by node listed in DA of the arriving packet. Such node can do whatever it want with the outer header of the packet. Some folks try to punch holes in 8200 to cover their issues - is that in good spirit of IETF ?

Your idea of taking piece of the consistent spec away is very broken as it now makes other documents inconsistent and blocks hardware where such function is supported today at line rate.

Best,
R.

On Thu, Feb 27, 2020 at 7:39 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Pablo,

The first argument can be dismissed out of hand. Just because something has been deployed doesn’t mean that it adds value or even that it causes no harm.

The third argument was best articulated Dan Voyer in https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/<https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/> and deserves some consideration. In his deployment scenario, the ultimate segment endpoint:

While I have sympathy for Dan’s dilemma, I wonder whether it is a good idea to stretch the IPv6 standard to accommodate IPv6-challenged devices.

                                                                                                                         Ron

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Tuesday, February 25, 2020 10:17 AM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Gyan,

[1].- https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0<https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0>
[2].- https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c<https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c>
[3].- https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0<https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0>
[4].- https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk<https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk>
[5].- https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI<https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI>

Cheers,
Pablo.

My 2 cents

Gyan

On Mon, Feb 24, 2020 at 5:38 PM Pablo Camarillo (pcamaril) <pcamaril=[email-masked]<mailto:[email-masked]>> wrote:
Ron,

Cheers,
Pablo.

Folks,

3)      Is PSP a good idea?

                                                                                                           Ron

Andrew

Cheers,
Sander

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 27 Feb 2020 20:38:45 +0000

Gyan,

Inline [PC1].

Thanks,
Pablo.

Date: Thursday, 27 February 2020 at 08:14

In-line response

On Tue, Feb 25, 2020 at 10:16 AM Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

(1) reduce the load of final destination. This benefit can be notable for the following sub reasons.

I know you say you are not trying to create any feature parity with MPLS however by using PSP is similar to PHP in that you are trying to offload processing on the end X node in which could be any node in the path and not just the PHP node.

With SRv6 the loophole created here is that at each hop along the traffic engineered path, the SID in the SL is popped

PC1: This is incorrect. The SID in position SL is never popped. You copy the active segment in to the IPv6 Destination Address field, but you don’t remove it from the SRH. I’m sure that you already know this, but let’s make sure that others do not get confused.

and copied to the DA hop by hop - so each hop being a single hop End X SID instantiation,
PC1: A hop as per RFC8200 happens every time that a router forwards the packet. SRv6 does not change this.
The next segment is copied once that you arrive to the node identified in the IPv6 Destination Address field of the packet.

 the PSP function of SRH removal can now occur at any node along the path and not just the MPLS style one hop prior to ultimate hop egress PE node.
PC1: This is incorrect. The SRH removal operation occurs when you receive a packet with SL=1; and subsequently you copy the last segment into the IPv6 Destination Address field and decrement Segments Left to zero

So PSP is being leveraged to be used at any end X and not just the final destination.
PC1: It is not executed at any router. PSP is only triggered when you are at the node identified in the Destination Address field of the IPv6 header and the received Segments Left value is equal to 1.

This makes the situation worse for RFC 8200 violations.
PC1: This is explicitly allowed in RFC8200. It is not executed at “any router” as you said before.

What would be the use case where you would need to pop the SRH early at an End X node that is not the final destination.  The SL has to be 0 to pop the SRH.  Please correct me then if the PSP function can only occur at the final destination one hop prior PHP node.
PC1: The PSP function can only occur on the segment endpoint node that decrement the Segments Left value from 1 to 0.

(1.1) final destination tends to have heavy load. It need to handle all the EHs and do the delivery/demultiplex the packet to the right overlay service.

How is the PSP function with modern hardware any more difficult popping the SRH on the final destination node then with MPLS explicit null UHP.

Other then the 6in6 topmost SRv6 encapsulation that is popped at the final destination which is different then MPLS 4 byte shim topmost,  with the bottom stack labels being identical in both scenarios, is there really extra load on the final destination egress PE that is being saved??
PC1: See below on email 5.

DOH would be set in the encapsulated packet in the customer payload that is tunneled 6in6 over the provider network. Doubtful that DOH would be set in the SP SRv6 closed domain
PC1: Are you suggesting that we modify the customer packet to insert a DoH on the fly? Im sorry. This is not what we want to do. When we receive a customer packet into the SRv6 closed domain we encapsulate the customer packet and include all the necessary headers. The customer packet integrity is preserved end to end. The customer packet is never modified or processed.

(1.3) example 2, the final destination may need to do the assembly of fragmented packets.

In general almost across the board all providers set their MTU to 9216 jumbo so as to not have outer 6in6 SRv6 header fragmentation issues

(1.4) example 3, the final destination may need to do AH/ESP after the Fragmentation Header.

Just like 1.2 AH/ESP would be part of the customer payload encapsulated
PC1: Again, same as before. The customer packet integrity is always preserved. The SP processing happens only on the SP imposed IP header. If the SP wishes to use AH/ESP, then the AH/ESP header would be added to the outer IPv6 header.

(1.5) example 4, the final destination may need to deliver the packet to the right overlay service.

In the SP network the packet is still forwarded hop by hop along the SRH traffic engineered path to the prefix SID fec destination, which is always the final destination in the SL, when SL is 0 the USP USD deencapsulation occurs.  So in my mind the overlay service would not ever be on an end DT transit node P router and would always sit on an egress PE router.

Am I missing something?
PC1: End.DT SIDs are typically instantiated in the PE routers.

(2) support the incremental deployment when final destination(s) do not process/recognize SRH. This benefit can be notable for the following sub reasons.

This is during interim migration, however I believe the best practice for SRv6 brown field is to have the PEs SRv6 capable and the Ps IPv6 capable for End DT x transit node forwarding only - which P routers should adhere strictly to RFC 8200 and should never have to perform or technically even have to perform the PSP function.

In most SP networks the PEs are protocol and feature rich and have the latest code and hardware where the P routers “BGP free” “pim free” core - only perform label swapping in MPLS world and SR world only label stacking.
PC1: The point exactly raised by operators is to have legacy hardware PEs. This is exactly the opposite of what you are saying.
Legacy PE is SRv6 capable both from software and hardware perspective, but the ASIC has limited SRH processing capabilities.

PC1: By the way, all the nodes in the SRv6 domain MUST be RFC8200 compliant. Please read the SRH draft particularly section 3 for the definition of each type of node, together with section 4.1-4.3 for the processing at each node.
The “Source SR Node” and “SR Segment Endpoint Node” must support RFC8200 AND also draft-ietf-6man-segment-routing-header and draft-ietf-spring-srv6-network-programming
The “Transit Node” only supports RFC8200.

(2.1) A core router may (fan-out) connected with a big number of low-end routers that do not support SRH but support tunnel-end/service-demultiplex function of SRv6.

For example in SRv6-based L3VPN service scenario,  The ingress PE within SRv6-enabled domain can utilize SR-TE policy to enable TE-path function when encapsulating and transiting L3VPN traffic, The Ingress PE push on customer packets with SID list representing SR-TE policy plus END.DT4 as last SRv6 SID in SRH;  So I think,  each flavor of PSP/USP/USD can be designed to perform in related SRv6 endpoint. Imaging the PSP, the penultimate Endpoint can perform PSP, e.g. copy the last SID (END.DT4) of SRH to destination field of IPv6 header and POP the SRH, then forwarding it toward egress PE identified by DA.
This comment is what lead me to believe my comment in (1) then the PSP is being leveraged as a loophole to be able to perform the PSP function at any node and pop the SRH.
PC1: I’ve already replied above explaining why this understand is incorrect.

My thoughts are that the SRv6 source node ingress PE adds the SRH, and the final destination node egress PE pops the SRH.  I don’t understand why any P node along the path would ever pop the SRH if you have not made it yet to the final destination.
Also in the SRv6 programming PSP psuedocode it states the SL=0 has to be satisfied — so if you are on any P router and not at the final destination prefix SID FEC,  then you are doing the standard IPv6 data plane forwarding and end dt x node and copying hop by hop the SID to the DA.  Since the P routers are doing standard IPv6 forwarding they must comply with RFC8200.
PC1: I don’t follow your point here. Both P and PEs have to comply with RFC8200. The PEs as well as the P nodes where you want to have SRv6 processing need to support in addition the SRv6 drafts.

Am I missing something?

I agree that not much savings adding the PSP function just to POP the SRH at an end x node
PC1: There’s nothing arbitrary in the bytes we remove and there is no cost in such operation.

That sounds weird comment for me. We have deployed that type of function with no compromise in terms of of both performance and operation within reasonable and affordable cost.

- 1800 Iliad's Nodeboxes

- ISIS SRv6 extensions

- Support for ping and traceroute
Is this customer doing PSP in end x meaning any transit P router end dt x node?
PC1: The PSP function is an optional flavor of the End, End.X or End.T behaviors. PSP does not apply to the End.DT or End.DX behavior.

If so in those cases where the SRH is popped on end x node, was their a service overlay or SFC at the P node which was the reason to pop the SRH early on a transit P node.
[5].- https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI

PSP allows us to bring SRv6 to legacy PE devices that are not capable of processing the SRH in the dataplane, but are capable of supporting SRv6 in the control plane.

See this example:

The ingress PE (near the server) encapsulates the packet and adds an SRH with a low-latency list of segments;

The egress PE (near the customer) decapsulates the IPv6 header and forwards the inner packet to the customer.

We can include SLA unidirectionally from the server to the customer even though that the egress PE has a legacy ASIC. Legacy equipment are a reality and are not easy to replace, hence interoperability with brownfield is key for any innovative approach.

This is during migration however I believe the best practice for SRv6 brown field is to have the PEs SRv6 capable and the Ps IPv6 capable for End DT x transit node forwarding only
PC1: Again, you are modifying the customer use-case. I don’t see why you say that this is limited to migration time only. It is not. It is a brownfield deployment.
The PEs will be SRv6 capable; but you cannot assume that the customer will be upgrading all of their hardware. So, the PE can process the SRv6 control plane and dataplane but has limited SRH processing capabilities.

 - which P routers should adhere strictly to RFC 8200 and should never have to perform or technically even have to perform the PSP function.
PC1: In any SRv6 deployment both the SR routers (those who support the SRH/NET-PGM); as well as the NON-SR routers both have to be compliant with RFC8200.

In most SP networks the PEs are protocol and feature rich and have the latest code and hardware where the P routers “BGP free” “pim free” only perform label swapping in MPLS world and SR world only label stacking.

PC1: In most SP the number of PE devices is by far larger than the number of P devices. Are you suggesting that they should replace all of their access just because you disagree with their PSP use-case?

Cheers,
Pablo.

My 2 cents

Gyan

Cheers,
Pablo.

Folks,

3)      Is PSP a good idea?

                                                                                                           Ron

Andrew

Cheers,
Sander

---

From: John Scudder <[email-masked]>
Date: Thu, 27 Feb 2020 21:10:56 +0000

I have an additional observation, or question, about Dan’s scenario. Almost all communication is bidirectional. Presumably this means a router that’s the tail end of an SRv6 path in one direction is the head end in the other. Doesn’t a head end need to add an SRH? If I’ve gotten that right, then we can extend Ron’s list with one more item. That is, apparently the ultimate segment endpoint:

• Can process a SID, received as an IPv6 DA, on the fast path
• Cannot process an SRH on receipt, even if Segments Left equal 0, on the fast path.
• Can add an SRH on transmission, on the fast path

Even though strictly speaking the second and third bullet points aren’t mutually exclusive, it’s a little difficult to imagine a real router that would have both these properties simultaneously. Perhaps I’m not being creative enough in imagining deployment scenarios? Since this scenario is claimed as an important reason this problematic feature is needed, it would be great if someone who understands it would elucidate, thanks.

One further point, Ron says “I wonder whether it is a good idea to stretch the IPv6 standard to accommodate IPv6-challenged devices.” I also wonder this, especially because these devices will have a relatively limited lifetime in the network.[*] I don’t find the cost/benefit attractive of making a permanent detrimental change to the IPv6 architecture to accommodate a temporary deployment issue.

Regards,

—John

[*] Yes, I know “limited lifetime” can mean a surprising number of years, but in any event not as long as the expected lifetime as IPv6 itself. Furthermore, old devices tend to change roles so I think “limited lifetime” *in this role* isn’t too much of a stretch.

On Feb 27, 2020, at 1:38 PM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Pablo,

The third argument was best articulated Dan Voyer in https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_QTmM755Q$> and deserves some consideration. In his deployment scenario, the ultimate segment endpoint:

                                                                                                                         Ron

Gyan,

[1].- https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_QAAm0nSw$>
[2].- https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_R7CfuQuA$>
[3].- https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_RGqFWLfw$>
[4].- https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_RhwnT1cw$>
[5].- https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_Se7ocRiA$>

Cheers,
Pablo.

My 2 cents

Gyan

Cheers,
Pablo.

Folks,

3)      Is PSP a good idea?

                                                                                                           Ron

Andrew

Cheers,
Sander

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_SwXxoPGw$

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 28 Feb 2020 05:05:28 +0000

Hi John,

Please check inline below.

From: spring <[email-masked]> On Behalf Of John Scudder
Sent: 28 February 2020 02:41
To: SPRING WG <[email-masked]>; 6man WG <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

I have an additional observation, or question, about Dan’s scenario. Almost all communication is bidirectional.
[KT] Sure and perhaps you can actually look at Dan’s scenario at https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/ … and (while I don’t claim this to be Dan’s application) then consider it’s about delivering content to a user/customer from a DC.

Presumably this means a router that’s the tail end of an SRv6 path in one direction is the head end in the other. Doesn’t a head end need to add an SRH?
[KT] No. Since content delivery (say OTT video) is heavy in one direction and that is where we can agree that an operator would wish to do TE. The other way is not required. You see that this is work to address real-life scenarios and practical deployments – that is what is driving the implementation and deployment efforts. It is not about a “religious” thing – it’s fact based and real.

If I’ve gotten that right, then we can extend Ron’s list with one more item. That is, apparently the ultimate segment endpoint:
[KT] I hope you see what you perhaps missed 😊 … rest of your (and Ron and other’s similar) points below are now moot.

I hope I’ve been able to make you see the benefits of just one of the use-cases … assuming that you are not wearing the glasses of “PSP violates/stretches RFC8200” 😉

Thanks,
Ketan

Regards,

—John

Pablo,

The third argument was best articulated Dan Voyer in https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_QTmM755Q$> and deserves some consideration. In his deployment scenario, the ultimate segment endpoint:

                                                                                                                         Ron

Gyan,

[1].- https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_QAAm0nSw$>
[2].- https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_R7CfuQuA$>
[3].- https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_RGqFWLfw$>
[4].- https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_RhwnT1cw$>
[5].- https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_Se7ocRiA$>

Cheers,
Pablo.

My 2 cents

Gyan

Cheers,
Pablo.

Folks,

3)      Is PSP a good idea?

                                                                                                           Ron

Andrew

Cheers,
Sander

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_SwXxoPGw$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QXdFeGu9dyfhNfAlfTPmnuE7WHzQpDyOF8Q4c6MmoszqzKkWGYSCS_SwXxoPGw$>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 28 Feb 2020 00:49:52 -0500

Inline gyan>

On Thu, Feb 27, 2020 at 4:00 PM Pablo Camarillo (pcamaril) <
[email-masked]> wrote:

> *Date: *Thursday, 27 February 2020 at 08:14
> *Cc: *SPRING WG <[email-masked]>
> PC1: This is incorrect. The SID in position SL is never popped. You copy
> the active segment in to the IPv6 Destination Address field, but you don’t
> remove it from the SRH. I’m sure that you already know this, but let’s make
> sure that others do not get confused.
>
>  gyan> Understood by pop I meant copy or process the active SID to DA
>
>
and copied to the DA hop by hop - so each hop being a single hop End X
SID instantiation,
> The next segment is copied once that you arrive to the node identified in
> the IPv6 Destination Address field of the packet.
>
>  gyan> The point I was trying to make is that  SRv6 use the IPv6 data plane differently then vanilla IPv6 in that the  .    destination copies from SRH to DA is a hop by hop traffic steered source routed path then natively routed.
>
> PC1: This is incorrect. The SRH removal operation occurs when you receive
> a packet with SL=1; and subsequently you copy the last segment into the
> IPv6 Destination Address field and decrement Segments Left to zero
>
  gyan> Good.  That’s what I thought but wanted to make sure usage of PSP
is only when packet with  SL=1
   Is received.  In some of the responses in this some of the threads it
sounded like PSP was being used for other cases other then when SL=1 is
received.  So in an SRv6 domain similar to MPLS domain the PHP node one hop
before the egress PE is the same as in SRv6 domain when SL=1 is the egress
P node before the last hop in the SRv6 domain being the egress PE UHP node
or USP node in an SRv6 domain.

> PC1: It is not executed at any router. PSP is only triggered when you are
> at the node identified in the Destination Address field of the IPv6 header
> and the received Segments Left value is equal to 1.
>
>  gyan> ok good
>
  gyan>ok good

> PC1: The PSP function can only occur on the segment endpoint node that
> decrement the Segments Left value from 1 to 0
>
   gyan> ok good

> PC1: Are you suggesting that we modify the customer packet to insert a DoH
> on the fly? Im sorry. This is not what we want to do. When we receive a
> customer packet into the SRv6 closed domain we encapsulate the customer
> packet and include all the necessary headers. The customer packet integrity
> is preserved end to end. The customer packet is never modified or processed.
>
>  gyan> I am saying that since the DOH is in the customer payload encapsulated packet this would not be a reason for offloading DOH processing using PSP
>
> PC1: Again, same as before. The customer packet integrity is always
> preserved. The SP processing happens only on the SP imposed IP header. If
> the SP wishes to use AH/ESP, then the AH/ESP header would be added to the
> outer IPv6 header.
>
> gyan> since the AH/ESP header would be in the customer payload encapsulated and not SP header then also just as with doh would not be a use case reason for PSP
>
>
>
> PC1: The point exactly raised by operators is to have legacy hardware PEs.
> This is exactly the opposite of what you are saying.
>
> Legacy PE is SRv6 capable both from software and hardware perspective, but
> the ASIC has limited SRH processing capabilities.
>
>  Is the ASIC hardware processing limitations due to MSD SID depth?
>
> PC1: By the way, all the nodes in the SRv6 domain MUST be RFC8200
> compliant. Please read the SRH draft particularly section 3 for the
> definition of each type of node, together with section 4.1-4.3 for the
> processing at each node.
>
> The “Source SR Node” and “SR Segment Endpoint Node” must support RFC8200
> AND also draft-ietf-6man-segment-routing-header and
> draft-ietf-spring-srv6-network-programming
>
>  gyan> main crux of the discussion has been that the IPv6 packet is immutable which violates RFC8200 with PSP SRH removal.
>
> PC1: I don’t follow your point here. Both P and PEs have to comply with
> RFC8200. The PEs as well as the P nodes where you want to have SRv6
> processing need to support in addition the SRv6 drafts.
>
>
>
> Am I missing something?
>
> [3].-
> PC1: The PSP function is an optional flavor of the
> End, End.X or End.T behaviors. PSP does not apply to
> the End.DT or End.DX behavior.
>

   gyan> This is what I was thinking but was not sure on the use case  of
PSP optional flavor.  End.X and End.T L3 xconnect or V6 table lookup is
what I was talking about in the 1st few questions.  So the End.X and End.T
is really any P node along the path to the final destination. So you are
saying that you can now do the PSP option flavor to any P node along the
path??

> PC1: Again, you are modifying the customer use-case. I don’t see why you
> say that this is limited to migration time only. It is not. It is a
> brownfield deployment.
>
> The PEs will be SRv6 capable; but you cannot assume that the customer will
> be upgrading all of their hardware. So, the PE can process the SRv6 control
> plane and dataplane but has limited SRH processing capabilities.
>
    gyan> so you are saying due to SRH processing limitations on legacy
hardware that we would in brown field and not migration but semi permanent
long term use the PSP function on the P - and upgrade the egress P hardware
to support SRH processing - to avoid having to upgrade a fan out of PE
endpoints.  Makes sense.

May I ask which vendor and legacy platform has this SRH processing
limitation?

> PC1: In any SRv6 deployment both the SR routers (those who support the
> SRH/NET-PGM); as well as the NON-SR routers both have to be compliant with
> RFC8200.
>
>
>
    gyan> I get it now.  Out of all the reasons for PSP I can see this one
as a valid reason to be able to avoid upgrading of many PE endpoints to
support SRH processing.

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 11:55:08 +0100

Hi John,

> I have an additional observation, or question, about Dan’s scenario.
Almost all communication is bidirectional.
> Presumably this means a router that’s the tail end of an SRv6 path in one
direction is the head end in the other.

While your observation is correct that most TCP connections are bidir SR in
a lot of cases can operate only in one direction. Needless to say it can
also be used with UDP streaming.

To extend Ketan's OTT video example let me observe that in a lot of
transactions queries from clients are tiny and do not TE capabilities while
responses are huge and bursty and may indeed benefit from special handling.

Sure if you think of applications like VPNs than you are right ..
regardless of the size of the packets proper tagging must occur in either
direction - but this is just one use of SRv6 perhaps not even the major
one.

- - -

Now as one friend just asked me offline - putting all IPv6 dogmas aside -
what is the technical issue with removing previously applied extension
header from the packet within a given operator's network ? What breaks when
you do that ?

Thx,
R.

On Thu, Feb 27, 2020 at 10:11 PM John Scudder <jgs=
[email-masked]> wrote:

> I have an additional observation, or question, about Dan’s scenario.
> Almost all communication is bidirectional. Presumably this means a router
> that’s the tail end of an SRv6 path in one direction is the head end in the
> other. Doesn’t a head end need to add an SRH? If I’ve gotten that right,
> then we can extend Ron’s list with one more item. That is, apparently the
> ultimate segment endpoint:
>
> Even though strictly speaking the second and third bullet points aren’t
> mutually exclusive, it’s a little difficult to imagine a real router that
> would have both these properties simultaneously. Perhaps I’m not being
> creative enough in imagining deployment scenarios? Since this scenario is
> claimed as an important reason this problematic feature is needed, it would
> be great if someone who understands it would elucidate, thanks.
>
> One further point, Ron says “I wonder whether it is a good idea to stretch
> the IPv6 standard to accommodate IPv6-challenged devices.” I also wonder
> this, especially because these devices will have a relatively limited
> lifetime in the network.[*] I don’t find the cost/benefit attractive of
> making a permanent detrimental change to the IPv6 architecture to
> accommodate a temporary deployment issue.
>
> Regards,
>
> —John
>
>

---

From: John Scudder <[email-masked]>
Date: Fri, 28 Feb 2020 14:49:39 +0000

Hi Ketan,

Apropos content delivery, fair enough, thanks. (And yes, I did actually look at Dan’s scenario, why would you imply I hadn’t?)

Does this moot the point about the inutility of routers that are only able to serve as an SR tail end but not head end? I’m willing to stipulate that it does. Does it moot the final question about whether the end justifies the means? No. That’s a judgement call, of course, but what we do in this organization is largely about judgement calls so it’s a fit topic for conversation. (You also claim that you’ve mooted Ron’s points, I don’t see that but you can address Ron directly if you want to make that case.)

Regarding “wearing the glasses”, I didn’t come to the conversation with too many preconceived notions, but after reading through a few hundred messages, and the draft, I find myself increasingly convinced that PSP does indeed violate/stretch RFC8200. The people arguing for this point have strong textual and historical support, and have in large part made their points respectfully and with careful presentation of evidence. Those arguing against it rely on either spec-lawyering of a single paragraph, or ad hominem. To repeat a point others have made, the fact that this is so doesn’t mean PSP can’t be done. It does mean that if you want to do it right, you have to update RFC 8200, at least by adding “Updates: RFC 8200” to the header of the NP document.

Regards,

—John

On Feb 28, 2020, at 12:05 AM, Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>> wrote:

Hi John,

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of John Scudder
Sent: 28 February 2020 02:41
To: SPRING WG <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

I have an additional observation, or question, about Dan’s scenario. Almost all communication is bidirectional.
[KT] Sure and perhaps you can actually look at Dan’s scenario athttps://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/<https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI/__;!!NEt6yMaO-gk!UlMSW38-9w_MpvI7uETSG5Ta9wDVUs5lRCzB3QKgV_sqbw5D8Onj51fmg1Hurg$> … and (while I don’t claim this to be Dan’s application) then consider it’s about delivering content to a user/customer from a DC.

Thanks,
Ketan

Regards,

—John

Pablo,

                                                                                                                         Ron

Gyan,

Cheers,
Pablo.

My 2 cents

Gyan

Cheers,
Pablo.

Folks,

3)      Is PSP a good idea?

                                                                                                           Ron

Andrew

Cheers,
Sander

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Feb 2020 11:03:26 -0500

While it is true that some traffic only needs steering in one direction, 
I have real trouble figuring out how an operator would dare deploy an SR 
edge device that could not steer incoming traffic.  Either they do not 
need SR, or they can expect that some traffic will need it in both 
directions.  So I am left supporting John's contention that there seems 
to be a gap in how one would used the hypothesized device that needs 
another device performing PSP.

also, and edge device that requires PSP would place constraints on the 
SRv6 traffic paths that could be used be used to it.  One would have to 
ensure that all SRv6 traffic ending there had a penultimate explicit hop 
to a device that could perform PSP.  Yes, this can be done.  It does 
seem to complicate life.  Thus, yet another way that PSP adds complications.

Yours,
Joel

On 2/28/2020 5:55 AM, Robert Raszuk wrote:
>  > Presumably this means a router that’s the tail end of an SRv6 path in 
> one direction is the head end in the other.
> 
> While your observation is correct that most TCP connections are bidir SR 
> in a lot of cases can operate only in one direction. Needless to say it 
> can also be used with UDP streaming.
> 
> transactions queries from clients are tiny and do not TE 
> capabilities while responses are huge and bursty and may indeed benefit 
> from special handling.
> 
> regardless of the size of the packets proper tagging must occur in 
> either direction - but this is just one use of SRv6 perhaps not even the 
> major one.
> 
> - - -
> 
> Now as one friend just asked me offline - putting all IPv6 dogmas aside 
> - what is the technical issue with removing previously applied extension 
> header from the packet within a given operator's network ? What breaks 
> when you do that ?
> 
> Thx,
> R.
> 
> 
> On Thu, Feb 27, 2020 at 10:11 PM John Scudder 
> <jgs=[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     I have an additional observation, or question, about Dan’s
>     scenario.. Almost all communication is bidirectional. Presumably
>     this means a router that’s the tail end of an SRv6 path in one
>     direction is the head end in the other. Doesn’t a head end need to
>     add an SRH? If I’ve gotten that right, then we can extend Ron’s list
>     with one more item. That is, apparently the ultimate segment endpoint:
> 
>     Even though strictly speaking the second and third bullet points
>     aren’t mutually exclusive, it’s a little difficult to imagine a real
>     router that would have both these properties simultaneously. Perhaps
>     I’m not being creative enough in imagining deployment scenarios?
>     Since this scenario is claimed as an important reason this
>     problematic feature is needed, it would be great if someone who
>     understands it would elucidate, thanks.
> 
>     One further point, Ron says “I wonder whether it is a good idea to
>     stretch the IPv6 standard to accommodate IPv6-challenged devices.” I
>     also wonder this, especially because these devices will have a
>     relatively limited lifetime in the network.[*] I don’t find the
>     cost/benefit attractive of making a permanent detrimental change to
>     the IPv6 architecture to accommodate a temporary deployment issue.
> 
>     Regards,
> 
>     —John
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 17:12:35 +0100

Joel,

Let me observe that as it has been said already such end device may support
SR but SRH above say N SIDs is handled only in slow path.

In the same time let me observe that while slow path may be just fine for a
lot of time such device also is to receive 5 well engineered high
bandwidth streams. So only for those 5 streams it is required to do PSP.

IMO this is good enough reason to support it.

Thx,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 28 Feb 2020 08:22:25 -0800

Hi Robert,
you've asked about a possible operational drawback of PSP. I think that for
OAM PSP has decremental effect on the usefulness of performance
measurements as there's no obvious information to identify the path a
packet traversed.

Regards,
Greg

On Fri, Feb 28, 2020 at 2:55 AM Robert Raszuk <[email-masked]> wrote:

> in a lot of cases can operate only in one direction. Needless to say it can
>> I have an additional observation, or question, about Dan’s scenario..
>> stretch the IPv6 standard to accommodate IPv6-challenged devices.” I also
>> wonder this, especially because these devices will have a relatively
>> limited lifetime in the network.[*] I don’t find the cost/benefit
>> attractive of making a permanent detrimental change to the IPv6
>> architecture to accommodate a temporary deployment issue.
>>
>> Regards,
>>
>> —John
>>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 17:37:01 +0100

Greg,

I agree. Moreover I would suggest to add such text that PSP endpoint
behaviours should or must not be set for any OEM packets. Would that help ?

Thx,
R.

On Fri, Feb 28, 2020 at 5:22 PM Greg Mirsky <[email-masked]> wrote:

> Hi Robert,
> you've asked about a possible operational drawback of PSP. I think that
> for OAM PSP has decremental effect on the usefulness of performance

---

From: Ron Bonica <[email-masked]>
Date: Fri, 28 Feb 2020 16:37:32 +0000

Beyond that, SRv6 nodes examine the O-flag, even when Segments Left is equal to 0. So, when the SRH is removed, O-flag functionality isn't available at the ultimate segment endpoint.

                                                          Ron

From: spring <[email-masked]> On Behalf Of Greg Mirsky
Sent: Friday, February 28, 2020 11:22 AM
To: Robert Raszuk <[email-masked]>
Cc: John Scudder <jgs=[email-masked]>; SPRING WG <[email-masked]>; 6man WG <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Hi Robert,
you've asked about a possible operational drawback of PSP. I think that for OAM PSP has decremental effect on the usefulness of performance measurements as there's no obvious information to identify the path a packet traversed.

Regards,
Greg

On Fri, Feb 28, 2020 at 2:55 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi John,

> I have an additional observation, or question, about Dan's scenario. Almost all communication is bidirectional.
> Presumably this means a router that's the tail end of an SRv6 path in one direction is the head end in the other.

While your observation is correct that most TCP connections are bidir SR in a lot of cases can operate only in one direction. Needless to say it can also be used with UDP streaming.

To extend Ketan's OTT video example let me observe that in a lot of transactions queries from clients are tiny and do not TE capabilities while responses are huge and bursty and may indeed benefit from special handling.

Sure if you think of applications like VPNs than you are right ... regardless of the size of the packets proper tagging must occur in either direction - but this is just one use of SRv6 perhaps not even the major one.

- - -

Now as one friend just asked me offline - putting all IPv6 dogmas aside - what is the technical issue with removing previously applied extension header from the packet within a given operator's network ? What breaks when you do that ?

Thx,
R.

On Thu, Feb 27, 2020 at 10:11 PM John Scudder <jgs=[email-masked]<mailto:[email-masked]>> wrote:
I have an additional observation, or question, about Dan's scenario... Almost all communication is bidirectional. Presumably this means a router that's the tail end of an SRv6 path in one direction is the head end in the other. Doesn't a head end need to add an SRH? If I've gotten that right, then we can extend Ron's list with one more item. That is, apparently the ultimate segment endpoint:

* Can process a SID, received as an IPv6 DA, on the fast path
* Cannot process an SRH on receipt, even if Segments Left equal 0, on the fast path.
* Can add an SRH on transmission, on the fast path

Even though strictly speaking the second and third bullet points aren't mutually exclusive, it's a little difficult to imagine a real router that would have both these properties simultaneously. Perhaps I'm not being creative enough in imagining deployment scenarios? Since this scenario is claimed as an important reason this problematic feature is needed, it would be great if someone who understands it would elucidate, thanks.

One further point, Ron says "I wonder whether it is a good idea to stretch the IPv6 standard to accommodate IPv6-challenged devices." I also wonder this, especially because these devices will have a relatively limited lifetime in the network.[*] I don't find the cost/benefit attractive of making a permanent detrimental change to the IPv6 architecture to accommodate a temporary deployment issue.

Regards,

-John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WHQ0NUhAjwHVsM4IaKk9Y18cX6e8a4CIRz74xNQrYqdWDNahVJLVKyhuirvllWKo$>
--------------------------------------------------------------------

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 28 Feb 2020 08:44:34 -0800

Hi Robert,
thank you for you consideration. Pablo and I had discussed references to
OAM in the SRv6 network programming draft. Pablo and authors kindly agreed
to remove all references to OAM and draft-ietf-6man-spring-srv6-oam. As we
are discussing the network programming
draft, draft-ietf-6man-spring-srv6-oam is in WGLC at 6man. My intention was
to work with the authors of SRv6 OAM draft on documenting its relationship
with PSP. Would that make sense?

Regards,
Greg

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Feb 2020 17:45:56 +0100

Even better !

Thank you,
R.

On Fri, Feb 28, 2020 at 5:44 PM Greg Mirsky <[email-masked]> wrote:

>>>> While your observation is correct that most TCP connections are bidir
>>>> SR in a lot of cases can operate only in one direction. Needless to say it
>>>>> aren’t mutually exclusive, it’s a little difficult to imagine a real router
>>>>> that would have both these properties simultaneously. Perhaps I’m not being

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 28 Feb 2020 08:47:17 -0800

Hi Ron,
absolutely agree. And that is, in my opinion, question the authors of
draft-ietf-6man-spring-srv6-oam must clarify in the document. AFAIK, Zafar
and authors are working on the update to address WGLC comments. I'm looking
forward to discuss the changes.

Regards,
Greg

On Fri, Feb 28, 2020 at 8:37 AM Ron Bonica <[email-masked]> wrote:

>
>
> Beyond that, SRv6 nodes examine the O-flag, even when Segments Left is
> equal to 0. So, when the SRH is removed, O-flag functionality isn’t
> available at the ultimate segment endpoint.
>
>
>
>                                                           Ron
>
>
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *Greg Mirsky
> *Sent:* Friday, February 28, 2020 11:22 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* John Scudder <jgs=[email-masked]>; SPRING WG <
> [email-masked]>; 6man WG <[email-masked]>
> Sure if you think of applications like VPNs than you are right ...
> I have an additional observation, or question, about Dan’s scenario...
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WHQ0NUhAjwHVsM4IaKk9Y18cX6e8a4CIRz74xNQrYqdWDNahVJLVKyhuirvllWKo$>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 28 Feb 2020 18:05:55 +0000

Hi Greg,

Please see [ZA] in-line.

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Friday, February 28, 2020 at 11:45 AM
To: Robert Raszuk <[email-masked]>
Cc: John Scudder <jgs=[email-masked]>, SPRING WG <[email-masked]>, 6man WG <[email-masked]>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Hi Robert,
thank you for you consideration. Pablo and I had discussed references to OAM in the SRv6 network programming draft. Pablo and authors kindly agreed to remove all references to OAM and draft-ietf-6man-spring-srv6-oam. As we are discussing the network programming draft, draft-ietf-6man-spring-srv6-oam is in WGLC at 6man. My intention was to work with the authors of SRv6 OAM draft on documenting its relationship with PSP. Would that make sense?

[ZA] Agreed!

Regards,
Greg

On Fri, Feb 28, 2020 at 8:37 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

I agree. Moreover I would suggest to add such text that PSP endpoint behaviours should or must not be set for any OEM packets. Would that help ?

Thx,
R.

On Fri, Feb 28, 2020 at 5:22 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,
you've asked about a possible operational drawback of PSP. I think that for OAM PSP has decremental effect on the usefulness of performance measurements as there's no obvious information to identify the path a packet traversed.

Regards,
Greg

> Presumably this means a router that’s the tail end of an SRv6 path in one direction is the head end in the other.

Sure if you think of applications like VPNs than you are right .. regardless of the size of the packets proper tagging must occur in either direction - but this is just one use of SRv6 perhaps not even the major one.

- - -

Thx,
R.

On Thu, Feb 27, 2020 at 10:11 PM John Scudder <jgs=[email-masked]<mailto:[email-masked]>> wrote:
I have an additional observation, or question, about Dan’s scenario... Almost all communication is bidirectional. Presumably this means a router that’s the tail end of an SRv6 path in one direction is the head end in the other. Doesn’t a head end need to add an SRH? If I’ve gotten that right, then we can extend Ron’s list with one more item. That is, apparently the ultimate segment endpoint:

Regards,

—John