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

[Gyan Mishra <[e-mail]>]

Inline gyan>

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

> Gyan,
>
>
>
> Inline [PC1].
>
>
>
> Thanks,
>
> Pablo.
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Thursday, 27 February 2020 at 08:14
> *To: *"Pablo Camarillo (pcamaril)" <[e-mail]>
> *Cc: *SPRING WG <[e-mail]>
> *Subject: *Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
>
>
> In-line response
>
>
>
>
>
> On Tue, Feb 25, 2020 at 10:16 AM Pablo Camarillo (pcamaril) <
> [e-mail]> wrote:
>
> 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
>
>
>
> (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.
>
>  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,
>
> 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.
>
>  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.
>
>  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
>
  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.

>
>
> 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.
>
>  gyan> ok good
>
> 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.
>
>
  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

> (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??
>
> PC1: See below on email 5.
>
>
>
> (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
>
> 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
>
> (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.
>
> 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
>
>
>
> (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.
>
>  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
>
> The “Transit Node” only supports RFC8200.
>
>  gyan> main crux of the discussion has been that the IPv6 packet is immutable which violates RFC8200 with PSP SRH removal.
>
> (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
>
> [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.
>
> PC1: I’ve already replied above explaining why this understand is
> incorrect.
>
>
>
> 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.
>
> 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].-
> 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
>
> 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.
>
>
>
> [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?
>
> 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??

>
>
> 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:
>
> 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
>
> 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?

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

>
>
> I don't see the point of starting a new thread from zero that discusses
> the same thing.
>
>
>
> Cheers,
>
> Pablo.
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Tuesday, 25 February 2020 at 00:35
> *To: *"Pablo Camarillo (pcamaril)" <[e-mail]>
> *Cc: *Ron Bonica <[e-mail]>, SPRING WG <[e-mail]>
> *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=
> [e-mail]> wrote:
>
> 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=[e-mail]>
> *Date: *Monday, 24 February 2020 at 16:27
> *To: *Andrew Alston <[e-mail]>, Mark Smith <
> [e-mail]>, Sander Steffann <[e-mail]>
> *Cc: *SPRING WG <[e-mail]>, "Pablo Camarillo (pcamaril)" <
> [e-mail]>
> *Subject: *RE: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
> 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 <[e-mail]> *On Behalf Of *Andrew Alston
> *Sent:* Monday, February 24, 2020 5:06 AM
> *To:* Mark Smith <[e-mail]>; Sander Steffann <
> [e-mail]>
> *Cc:* SPRING WG <[e-mail]>; Pablo Camarillo (pcamaril) <pcamaril=
> [e-mail]>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
> I agree with the sentiments expressed below
>
>
>
> Andrew
>
>
>
>
>
> *From:* spring <[e-mail]> *On Behalf Of *Mark Smith
> *Sent:* Monday, 24 February 2020 00:50
> *To:* Sander Steffann <[e-mail]>
> *Cc:* SPRING WG <[e-mail]>; Pablo Camarillo (pcamaril) <
> pcamaril=[e-mail]>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
>
>
> On Mon, 24 Feb 2020, 07:47 Sander Steffann, <[e-mail]> 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 still oppose the segment popping flavours in section 4.16 without
> updating RFC8200.
>
>
>
> 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
> [e-mail]
> 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$>
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
>
>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
>
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]