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 <rob...@raszuk.net> 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) < > weibin.w...@nokia-sbell.com> wrote: > >> Inline; >> >> *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Robert Raszuk >> *Sent:* Wednesday, March 4, 2020 9:31 PM >> *To:* Ketan Talaulikar (ketant) <ket...@cisco.com> >> *Cc:* spring@ietf.org; Alexander Vainshtein < >> alexander.vainsht...@ecitele.com> >> *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) < >> ket...@cisco.com> wrote: >> >> 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> wrote: >> >> Hi Sasha, >> >> >> >> Please check inline below. >> >> >> >> *From:* Alexander Vainshtein <alexander.vainsht...@ecitele.com> >> *Sent:* 04 March 2020 15:41 >> *To:* Ketan Talaulikar (ketant) <ket...@cisco.com> >> *Cc:* spr...@ietf...org <spring@ietf.org>; Martin Vigoureux < >> martin.vigour...@nokia.com>; Joel M. Halpern <j...@joelhalpern.com>; >> Andrew G. Malis <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 >> >> >> >> >> >> -----Original Message----- >> From: Ketan Talaulikar (ketant) <ket...@cisco.com> >> Sent: Wednesday, March 4, 2020 11:49 AM >> To: Alexander Vainshtein <alexander.vainsht...@ecitele.com >> <alexander.vainsht...@ecitele...com>>; Joel M. Halpern < >> j...@joelhalpern.com>; Andrew G. Malis <agma...@gmail.com> >> Cc: spring@ietf.org; Martin Vigoureux <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 <spring-boun...@ietf.org>> On >> Behalf Of Alexander Vainshtein >> >> Sent: 04 March 2020 15:09 >> >> To: Joel M. Halpern <j...@joelhalpern.com>; Andrew G. Malis < >> agma...@gmail.com> >> >> Cc: spring@ietf.org; Martin Vigoureux <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 >> >> >> >> -----Original Message----- >> >> From: spring <spring-boun...@ietf..org <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> >> >> Cc: spring@ietf.org; Martin Vigoureux <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 <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 <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 <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%2Fmailman%2Flistinfo%2Fspring >> >> > >> >> >> >> _______________________________________________ >> >> spring mailing list >> >> 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 >> >> >> 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 >> https://www.ietf.org/mailman/listinfo/spring >> >>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
