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

[Robert Raszuk <[e-mail]>]

sorry s/ odd SID - PHP, even SID no PHP/ odd SID - PSP, even SID no PSP/



On Wed, Mar 4, 2020 at 3:00 PM Robert Raszuk <[e-mail]> wrote:

> Dear WWB,
>
> I think we are talking about the same thing ... behaviour to do or not to
> do PSP is embedded into SID. So to have two options you have to have two
> SIDs today advertised by IGP.
>
> I am just gently suggesting that to support both you could have
> algorithmic option (odd SID - PHP, even SID no PHP) and need to only signal
> one - keeping the other one reserved per node but not signalled).
>
> Thx,
> R.
>
> On Wed, Mar 4, 2020 at 2:56 PM Wang, Weibin (NSB - CN/Shanghai) <
> [e-mail]> wrote:
>
>> Inline;
>>
>> *From:* spring <[e-mail]> *On Behalf Of *Robert Raszuk
>> *Sent:* Wednesday, March 4, 2020 9:31 PM
>> *To:* Ketan Talaulikar (ketant) <[e-mail]>
>> *Cc:* [e-mail]; Alexander Vainshtein <
>> [e-mail]>
>> *Subject:* Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>>
>>
>>
>> Hi Ketan,
>>
>>
>>
>> So essentially you are confirming that subject to topology in worst case
>> I need to double the flooding amount of SIDs in my network to support both
>> PSP and non PSP operation. I think if we would consider PSP as optional or
>> on-demand behaviour we could architect it without the need for double
>> flooding node's SIDs just to indicate in one PSP=0 and in the other one PSP
>> !=0 (which by itself is still subject to given IGP and SR code even
>> allowing you to do that).
>>
>>
>>
>> Hi Robert:
>>
>> In my understanding, one behavior id (16bits) is only correspond to one
>> SID, and the 0 is reserved as defined in SRv6 NPG draft, PSP is flavor and
>> is never used alone.
>>
>>
>>
>> Thx;
>>
>> WWB;
>>
>>
>>
>> Thx,
>> R.
>>
>>
>>
>> On Wed, Mar 4, 2020 at 12:01 PM Ketan Talaulikar (ketant) <
>> [e-mail]> wrote:
>>
>> Hi Robert,
>>
>>
>>
>> Please check inline below.
>>
>>
>>
>> *From:* Robert Raszuk <[e-mail]>
>> *Sent:* 04 March 2020 16:07
>> *To:* Ketan Talaulikar (ketant) <[e-mail]>
>> *Cc:* Alexander Vainshtein <[e-mail]>;
>> [e-mail]
>> *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=
>> [e-mail]> wrote:
>>
>> Hi Sasha,
>>
>>
>>
>> Please check inline below.
>>
>>
>>
>> *From:* Alexander Vainshtein <[e-mail]>
>> *Sent:* 04 March 2020 15:41
>> *To:* Ketan Talaulikar (ketant) <[e-mail]>
>> *Cc:* spring@ietf...org <[e-mail]>; Martin Vigoureux <
>> [e-mail]>; Joel M. Halpern <[e-mail]>;
>> Andrew G. Malis <[e-mail]>
>> *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: [phone]
>>
>> Cell:      [phone]
>>
>> Email:   [e-mail]
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Ketan Talaulikar (ketant) <[e-mail]>
>> Sent: Wednesday, March 4, 2020 11:49 AM
>> To: Alexander Vainshtein <[e-mail]
>> <Alexander.Vainshtein@ecitele...com>>; Joel M. Halpern <
>> [e-mail]>; Andrew G. Malis <[e-mail]>
>> Cc: [e-mail]; Martin Vigoureux <[e-mail]>
>> 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-bounces@ietf..org <[e-mail]>> On
>> Behalf Of Alexander Vainshtein
>>
>> Sent: 04 March 2020 15:09
>>
>> To: Joel M. Halpern <[e-mail]>; Andrew G. Malis <
>> [e-mail]>
>>
>> Cc: [e-mail]; Martin Vigoureux <[e-mail]>
>>
>> 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: [phone]
>>
>> Cell:      [phone]
>>
>> Email:   [e-mail]
>>
>>
>>
>> -----Original Message-----
>>
>> From: spring <spring-bounces@ietf..org <[e-mail]>> On
>> Behalf Of Joel M. Halpern
>>
>> Sent: Wednesday, March 4, 2020 9:09 AM
>>
>> To: Andrew G. Malis <[e-mail]>
>>
>> Cc: [e-mail]; Martin Vigoureux <[e-mail]>
>>
>> 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 <[e-mail]
>>
>> > <mailto:[e-mail] <[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] <[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] <[e-mail]>>
>>
>> >
>>
>> > https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%2
>> <https://clicktime.symantec.com/3HYxrbBRUMaCG5VTr1FEMZ96H2?u=https%3A%252>
>>
>> > F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>>
>> >
>>
>>
>>
>> _______________________________________________
>>
>> spring mailing list
>>
>> [e-mail]
>>
>>
>> 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
>>
>> [e-mail]
>>
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>>