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

Robert Raszuk <robert@raszuk.net> Wed, 04 March 2020 10:37 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309B73A0BF2 for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 02:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.589
X-Spam-Level:
X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE1RO4dC4QRe for <spring@ietfa.amsl.com>; Wed, 4 Mar 2020 02:37:17 -0800 (PST)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD6D3A0BF6 for <spring@ietf.org>; Wed, 4 Mar 2020 02:37:17 -0800 (PST)
Received: by mail-ot1-x331.google.com with SMTP id v22so1485800otq.11 for <spring@ietf.org>; Wed, 04 Mar 2020 02:37:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P+A1QAOfjwOgCP+30nrbR5UEAON+CPpJylIAXujR3Jk=; b=X59Vb43h6ljPyowO4iqyuIsaxQA9A5lhiaWi3kg5rJhfmhnDRUpgzKAj+JCNboawGi HNngh1Ce7D6mJnbCC2rQPkHWxf2bAvReZMQLMgtgdgIVe/5xlzSNVJ9FiQVQOfVeWmMN MVQ0bOROjHgO0JrsxOEc1DVZCdK2haZAySZK8QpHyDmNpjF9HcAIxymHkkhtspQE8gE2 XfuWegfVOt9j56+ZqrG/dHE8tlrLWvHvysN5Cv01rfQ157doX43RO8FGJCQxT1d2Ndgs kDkzqM/y5XH/drtdmlzj/Y0j11vAKUpPL9ngKvxlRd6uf8xpv62dAONEweld6Dvrg1+s 87Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P+A1QAOfjwOgCP+30nrbR5UEAON+CPpJylIAXujR3Jk=; b=ZzH/IYO+K6gsPq5RhThKDlY4Nb25+UB4LiBENLCZL4Ytg1UVi4fszU1g0l9Oci0bSw nI/cEeUqB20a4NOxtRyVaVoquTSI0zxBJYoRzgGk4BEVfQOsrksmB4KlOGrpNRXUCSoN fj6CJDtGZNZy/4XwDesnK+liQXm+Atba1zGFQa5GGwiDB4ZTYcKHVAIK31UzDBE3S+fH Woiov3QvI2aCiA++S2Q7ZWsPTEVU8Foxy4JSJsZo1pA9IFymY++LyiKGvYyeXKjikh/R bFpbJKQSR+tPHwdv7PpR2thKUP4MZCq2ZTFej4uxr+Y0fEc2A/tE+j389E6+gsaE168g 0fag==
X-Gm-Message-State: ANhLgQ0ChZnFslpKTeOZkRZk4FF0chEhDJ3XB47eVeS5iPgWuyleVY/y oZd+yJA0pRCRQLakDTDAvXYgMKTcrjvfNTcn6e01ww==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vt2Fb10YZ2mwGftIl+gFeNPwxsXCZJ/QObfaY5N?= =?utf-8?q?kcQLzwNOipj0shTDXgJUn8SBI6meIqpBHUzy4pC8m3vNZzA=3D?=
X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr1233798otr.86.1583318236428; Wed, 04 Mar 2020 02:37:16 -0800 (PST)
MIME-Version: 1.0
References: =?utf-8?q?=3C17421=5F1575566127=5F5DE93B2F=5F17421=5F93=5F1=5F53?= =?utf-8?q?C29892C857584299CBF5D05346208A48D1A3DA=40OPEXCAUBM43=2Ecorporate?= =?utf-8?q?=2Eadroot=2Einfra=2Eftgroup=3E?= <3e2da3a5-5d1b-10a0-aeb4-320c57584241@nokia.com> =?utf-8?q?=3C8259d37e-b460-5f76-1ce6-b0d026bccf6b=40gont=2Ecom=2Ear=3E_=3C2?= =?utf-8?q?0143=5F1583250558=5F5E5E7C7E=5F20143=5F390=5F3=5F53C29892C8575842?= =?utf-8?q?99CBF5D05346208A48DD80E6=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Einf?= =?utf-8?q?ra=2Eftgroup=3E?= =?utf-8?q?=3C5d693a5e-baa0-6ffb-4e39-2695795b7413=40joelhalpern=2Ecom=3E_?= =?utf-8?q?=3C7501=5F1583255845=5F5E5E9125=5F7501=5F499=5F1=5F53C29892C85758?= =?utf-8?q?4299CBF5D05346208A48DD84FF=40OPEXCAUBM43=2Ecorporate=2Eadroot=2Ei?= =?utf-8?q?nfra=2Eftgroup=3E?= =?utf-8?q?=3Cfc5bf8d9-073f-2eff-6041-e1610bf6e116=40joelhalpern=2Ecom=3E_?= =?utf-8?q?=3CDM6PR05MB63484795948C4901C9B7A548AEE40=40DM6PR05MB6348=2Enampr?= =?utf-8?q?d05=2Eprod=2Eoutlook=2Ecom=3E?= <CAOj+MMGE+j7_QnFn-8ZQcU3BKLGEPaXj6hfppxG7-7iFkT3R1g@mail.gmail.com> <CAA=duU3fXaQY--XufYo+CuCnJsTd+bXH2uBbjUUHVJg6tLpzng@mail.gmail.com> =?utf-8?q?=3C409678ed-7175-006a-b8b3-f236c1640fa3=40joelhalpern=2Ecom=3E_?= =?utf-8?q?=3CAM0PR0302MB3217A8B8000B8936202DAEC49DE50=40AM0PR0302MB3217=2Ee?= =?utf-8?q?urprd03=2Eprod=2Eoutlook=2Ecom=3E_=3CMW3PR11MB457073BC9EE97A5EDC2?= =?utf-8?q?7A986C1E50=40MW3PR11MB4570=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E_?= =?utf-8?q?=3CAM0PR0302MB321780C8C7A72A6BAD439EB29DE50=40AM0PR0302MB3217=2Ee?= =?utf-8?q?urprd03=2Eprod=2Eoutlook=2Ecom=3E_=3CMW3PR11MB45707E8A763F6F5B60F?= =?utf-8?q?C4AF6C1E50=40MW3PR11MB4570=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3CMW3PR11MB45707E8A763F6F5B60FC4AF6C1E50=40MW3PR11MB?= =?utf-8?q?4570=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 4 Mar 2020 11:37:07 +0100
Message-ID: <CAOj+MMGe0mGywCyULJM-Zk2+GQOy_HyoqGZQF7O1+Y-bjLT8Lg@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>
Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000c83ea05a005016d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/sqh-ukgvvscW-_bDxyWmDhrZ97U>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 10:37:20 -0000

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 ?

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 ?

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 ?

Many thx,
R.




On Wed, Mar 4, 2020 at 11:17 AM Ketan Talaulikar (ketant) <ketant=
40cisco.com@dmarc.ietf.org> wrote:

> Hi Sasha,
>
>
>
> Please check inline below.
>
>
>
> *From:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> *Sent:* 04 March 2020 15:41
> *To:* Ketan Talaulikar (ketant) <ketant@cisco.com>
> *Cc:* spring@ietf.org; Martin Vigoureux <martin.vigoureux@nokia.com>om>;
> Joel M. Halpern <jmh@joelhalpern.com>om>; Andrew G. Malis <agmalis@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.Vainshtein@ecitele.com
>
>
>
>
>
> -----Original Message-----
> From: Ketan Talaulikar (ketant) <ketant@cisco.com>
> Sent: Wednesday, March 4, 2020 11:49 AM
> To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>; Joel M.
> Halpern <jmh@joelhalpern.com>om>; Andrew G. Malis <agmalis@gmail.com>
> Cc: spring@ietf.org; Martin Vigoureux <martin.vigoureux@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-bounces@ietf.org> On Behalf Of Alexander Vainshtein
>
> Sent: 04 March 2020 15:09
>
> To: Joel M. Halpern <jmh@joelhalpern.com>om>; Andrew G. Malis <
> agmalis@gmail.com>
>
> Cc: spring@ietf.org; Martin Vigoureux <martin.vigoureux@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 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.Vainshtein@ecitele.com
>
>
>
> -----Original Message-----
>
> From: spring <spring-bounces@ietf.org> On Behalf Of Joel M. Halpern
>
> Sent: Wednesday, March 4, 2020 9:09 AM
>
> To: Andrew G. Malis <agmalis@gmail.com>
>
> Cc: spring@ietf.org; Martin Vigoureux <martin.vigoureux@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 <robert@raszuk.net
>
> > <mailto:robert@raszuk.net <robert@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.net@dmarc.ietf.org
>
> >     <mailto:40juniper.net@dmarc.ietf.org <40juniper.net@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
>