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=
40cisco.com@dmarc.ietf.org> 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=40juniper.net@dmarc.ietf.org>
> *Date: *Monday, 24 February 2020 at 16:27
> *To: *Andrew Alston <Andrew.Alston@liquidtelecom.com>, Mark Smith <
> markzzzsmith@gmail.com>, Sander Steffann <sander@steffann.nl>
> *Cc: *SPRING WG <spring@ietf.org>, "Pablo Camarillo (pcamaril)" <
> pcamaril@cisco.com>
> *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 <spring-bounces@ietf.org> *On Behalf Of *Andrew Alston
> *Sent:* Monday, February 24, 2020 5:06 AM
> *To:* Mark Smith <markzzzsmith@gmail.com>; Sander Steffann <
> sander@steffann.nl>
> *Cc:* SPRING WG <spring@ietf.org>; Pablo Camarillo (pcamaril) <pcamaril=
> 40cisco.com@dmarc.ietf.org>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
> I agree with the sentiments expressed below
>
>
>
> Andrew
>
>
>
>
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Mark Smith
> *Sent:* Monday, 24 February 2020 00:50
> *To:* Sander Steffann <sander@steffann.nl>
> *Cc:* SPRING WG <spring@ietf.org>; Pablo Camarillo (pcamaril) <
> pcamaril=40cisco.com@dmarc.ietf.org>
> *Subject:* Re: [spring] I-D Action:
> draft-ietf-spring-srv6-network-programming-10.txt
>
>
>
>
>
> On Mon, 24 Feb 2020, 07:47 Sander Steffann, <sander@steffann.nl> 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
> spring@ietf.org
> 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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com