Hi Robert,
Please check inline below.
From: Robert Raszuk <rob...@raszuk.net>
Sent: 04 March 2020 16:07
To: Ketan Talaulikar (ketant) <ket...@cisco.com>
Cc: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Hi Ketan,
Let's assume following scenario:
----- T1
|
A ---- Z ---- P ---- T2
|
----- T3
A - is ingress
P - is potential PSP performer
Ts - are egress (from SR pov)
Q1:
Assume T1 and T3 signal capability to handle SRH depth = 4 and T2 = 2
Assume P signals PSP = 5 for SID P
SRH depth required is 3
How does A can build SRH for all three SR paths to do PSP only to node T2 ?
sub-Q1: Is it legal today to signal by P two SIDs one with PSP depth supported
= N and the other with depth = 0 ?
[KT] The MSD support is advertised at node level. The node P can advertise say
two End SID – one with PSP and another without it. The SR Source Node picks up
which of the two End SIDs to pick based on the capabilities of the egress
nodes. Ultimately, the SR Source Node A decides and instructs P what it needs
to do for each of the 3 paths.
Q2:
Assume T1, T2 and T3 signal capability to handle SRH depth = 4
Assume P signals PSP = 5 for SID P
SRH depth required is 3
How can A build SRH such that PSP will happen only for very fat flows ?
[KT] As in the previous example, A can make a choice on a per flow basis by
picking up the PSP or non-PSP flavor of P’s SIDs.
Q3:
Assume T1, T2 and T3 signal capability to handle SRH depth = 2
Assume P signals PSP = 0
SRH depth required is 3
Would A not be able to insert SRH and do any SR in this case ?
[KT] Yes, A cannot generate a packet with SRH with 3 segments destined to the T
nodes in such a case.
Thanks,
Ketan
Many thx,
R.
On Wed, Mar 4, 2020 at 11:17 AM Ketan Talaulikar (ketant)
<ketant=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote:
Hi Sasha,
Please check inline below.
From: Alexander Vainshtein
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
Sent: 04 March 2020 15:41
To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>
Cc: spr...@ietf..org<mailto:spring@ietf.org>; Martin Vigoureux
<martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>>; Joel M.
Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; Andrew G. Malis
<agma...@gmail.com<mailto:agma...@gmail.com>>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Ketan,
Lots of thanks for the pointer.
Here is the text I have found at this reference:
4.4<https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#section-4.4>.
Maximum End D MSD Type
The Maximum End D MSD Type specifies the maximum number of SIDs in an
SRH when performing decapsulation associated with "End.Dx" behaviors
(e.g., "End.DX6" and "End.DT6") as defined in
[I-D.ietf-spring-srv6-network-programming<https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#ref-I-D..ietf-spring-srv6-network-programming>].
SRH Max End D Type: 45 (Suggested value - to be assigned by IANA)
If the advertised value is zero or no value is advertised
then it is assumed that the router cannot apply
"End.DX6" or "End.DT6" behaviors if the outer IPv6 header contains an SRH.
I assume that you have actually referred to the highlighted text in this
section – is this correct?
If this is correct then, to the best of my understanding:
1. The request for PSP (expressed as inability to process the SRH and to
perform certain lookup by the originator of an SID) is global and not local
between the originator and the penultimate node
[KT] This is correct.
1. It is not clear what the penultimate router that has received such a
request but cannot implement it is supposed to do.
[KT] This is not a request to the penultimate SR Endpoint Node. The source SR
Node explicitly instructs the penultimate SR Endpoint Node when it wants it do
PSP operation. A router which does not support PSP operation (i.e. does not
advertise SIDs with those flavors), then the source SR Node will not be able to
instruct it to do PSP. Ultimately the SR Source Node decides.
Thanks,
Ketan
My 2c,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email:
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>
-----Original Message-----
From: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>
Sent: Wednesday, March 4, 2020 11:49 AM
To: Alexander Vainshtein
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele..com>>;
Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; Andrew G.
Malis <agma...@gmail.com<mailto:agma...@gmail.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; Martin Vigoureux
<martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Hi Sasha,
There is the signalling from the "tail-end node" in SRv6 as well. Perhaps you
missed
https://clicktime.symantec.com/3Fjd1GocprnmRnQ68mT2Nv46H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-isis-srv6-extensions-06%23section-4.4
?
Thanks,
Ketan
-----Original Message-----
From: spring <spring-boun...@ietf..org<mailto:spring-boun...@ietf.org>> On
Behalf Of Alexander Vainshtein
Sent: 04 March 2020 15:09
To: Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; Andrew
G. Malis <agma...@gmail.com<mailto:agma...@gmail.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; Martin Vigoureux
<martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Joel, Andy and all,
FWIW I concur with your positions regarding comparison between PHP in MPLS and
PSP in SRv6.
I would also like to stress that, to the best of my understanding, in MPLS PHP
is a local behavior between the penultimate and ultimate nodes with the
ultimate node explicitly requesting it and the penultimate one giving the
option to agree (i.e.to<http://i.e.to> pop the top label when forwarding the
packet) or disagree (and to swap the top label to Explicit NULL). The head-end
node (and the rest of the nodes on the path) remain completely ignorant of this
behavior. I.e., PHP has been introduced - and remains - truly optional.
I have not seen any specifications that would allow the tail-end node of an
SRv6 path that wants to benefit from PSP to explicitly request this behavior
from the penultimate one, nor do I see would the penultimate node that cannot
support PSP do if requested to perform it. The suggestions I have seen that it
would be up to the head-end node (that inserts the SRH) to indicate that PSP is
requested - on behalf of the tail-end node? - look problematic to me as well.
My 2c,
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email:
alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>
-----Original Message-----
From: spring <spring-boun...@ietf..org<mailto:spring-boun...@ietf.org>> On
Behalf Of Joel M. Halpern
Sent: Wednesday, March 4, 2020 9:09 AM
To: Andrew G. Malis <agma...@gmail.com<mailto:agma...@gmail.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; Martin Vigoureux
<martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
In this case, it is even less relevant. The PSP for SRv6 does not remove the
double-processing. It merely removes the need to ignore the SRH at the
ultimate node.
Yours,
Joel
On 3/3/2020 6:27 PM, Andrew G. Malis wrote:
> 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
> <rob...@raszuk.net<mailto:rob...@raszuk.net>
> <mailto:rob...@raszuk.net>> 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=40juniper....@dmarc.ietf.org<mailto:40juniper....@dmarc.ietf.org>
> <mailto:40juniper....@dmarc.ietf.org>> 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
> spring@ietf.org<mailto:spring@ietf.org> <mailto:spring@ietf.org>
>
> https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%2<https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%252>
> F%2Fwww.ietf.org<http://2Fwww.ietf.org>%2Fmailman%2Flistinfo%2Fspring
>
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this transmission in error, please inform us by e-mail, phone or fax,
and then delete the original and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://clicktime.symantec.com/3GkRJLpXrP2pY9W9t8khQDB6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains information
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
this
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
