Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

[Robert Raszuk <[e-mail]>]

> When a vendor is pushing me to implement a technology

Last time I checked SRv6 is not enabled by default by any code base. What
type of "vendor push" are you referring to ? Maybe you can share which
vendor is pushing you with such strong push that you can not resist ?

Thx,
R.


On Wed, Mar 4, 2020 at 10:58 PM Andrew Alston <
[e-mail]> wrote:

> I have to second the below from an operator perspective.
>
>
>
> When a vendor is pushing me to implement a technology – yet not disclosing
> that implementing it could result in serious network degradation dependent
> on the boxes I have in the network and their positioning – that exposes me
> as an operator to a position of either roll back – or forced upgrades and
> potentially significant cost.
>
>
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
> *From: *spring <[e-mail]> on behalf of "Joel M. Halpern" <
> [e-mail]>
> *Date: *Thursday, 5 March 2020 at 00:25
> *To: *"Darren Dukes (ddukes)" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>rg>, Martin Vigoureux <
> [e-mail]>
> *Subject: *Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
> Darren, could you please comment on the behavioral / deployment
> implications I believe I identified in my recent email about the use
> case? It does seem to me that something needs to be said about the
> implications of the use case. Yes, we do sometimes make allowances in
> protocol design for deficient but complaint implementations. But we do
> not pretend that there are not issues when doing so. And we try to
> identify the needs clearly.
>
> Yours,
> Joel
>
> On 3/4/2020 4:21 PM, Darren Dukes (ddukes) wrote:
> > Hi Ron
> >
> > I don’t think you are really asking equipment vendors to provide that
> > information on this list.  That will not happen.
> >
> > I’ll simply repeat what has been stated by others on this list.
> > Products with limited ability to receive and process a packet containing
> > a RH when SL==0 exist.
> > PSP provides a means of allowing those products to be used as a PE.
> >
> > Thanks
> >   Darren
> >
> >> On Mar 4, 2020, at 3:01 PM, Ron Bonica
> >> <rbonica=[e-mail]
> >> <mailto:rbonica=[e-mail]>> wrote:
> >>
> >> Andy,
> >> AFAIKS, the only use case PSP is to accommodate SRv6 egress nodes that:
> >>
> >> * Can process an SRv6  SID that appears in the IPv6 Destination Address
> >> * Can process the SRH with Segments Left equal to 0
> >> * But cannot process the SRH with Segments Left equal to 0 at high speed
> >>
> >> I am not aware that any such device exists. Does anybody know of one?
> >>                                                    Ron
> >> *From:*Andrew G. Malis <[e-mail] <mailto:[e-mail]>>
> >> *Sent:*Tuesday, March 3, 2020 6:28 PM
> >> *To:*Robert Raszuk <[e-mail] <mailto:[e-mail]>>
> >> *Cc:*Ron Bonica <[e-mail]
> >> <mailto:[e-mail]>>;[e-mail]
> >> <mailto:[e-mail]>;[e-mail]
> >> <mailto:[e-mail]>; Joel M. Halpern <[e-mail]
> >> <mailto:[e-mail]>>; Martin Vigoureux
> >> <[e-mail] <mailto:[e-mail]>>
> >> *Subject:*Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
> >> MPLS PHP was invented to solve a particular issue with some forwarding
> >> engines at the time - they couldn't do a final pop followed by an IP
> >> lookup and forward operation in a single forwarding cycle (it would
> >> impact forwarding speed by 50% best case). 20 years later, is this
> >> still an issue at the hardware/firmware level? If so, affected
> >> implementers should speak up, otherwise there's really no need for PSP.
> >> Cheers,
> >> Andy (who was there at the time)
> >> On Tue, Mar 3, 2020 at 3:11 PM Robert Raszuk <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >> Hi Ron,
> >> >   MPLS PHP is a clear case of de-encapsulation.
> >> Purely looking at technical aspect that is not true at all.
> >> MPLS PHP does not remove label stack. MPLS PHP is just used to pop
> >> last label. After MPLS PHP packets continue with remaining label
> >> stack to the egress LSR (example L3VPN PE).
> >> >  I don't think that you can compare MPLS PHP with SRv6 PSP
> >> But I agree with that. Both operations have very little in common
> >> from packet's standpoint or forwarding apect. Well maybe except
> >> "penultimate" word :)
> >> Kind regards,
> >> R.
> >> On Tue, Mar 3, 2020 at 8:30 PM Ron Bonica
> >> <rbonica=[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >> Folks,
> >>
> >> I don't think that you can compare MPLS PHP with SRv6 PSP.
> >> MPLS PHP is a clear case of de-encapsulation. We do that all
> >> the time. In SRv6 PSP, we are removing something from the
> >> middle of a packet. That is quite a different story.
> >>
> >>
> >>
> >>           Ron
> >>
> >> _______________________________________________
> >> spring mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/spring
> >> <
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QEhtnK3a_SkTtK5jFwY7ANmF22RCkp657bAyNJfcGg1xaI_ewfHQHKp7NIgQ3SpI$
> >
> >> Juniper Business Use Only
> >>
> >> _______________________________________________
> >> spring mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/spring
> >
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>