From nobody Mon Mar 8 09:47:16 2021 Return-Path: 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 93E393A135D; Mon, 8 Mar 2021 09:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Dc_-ElZvEbeC; Mon, 8 Mar 2021 09:47:13 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 755EB3A135A; Mon, 8 Mar 2021 09:47:13 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id u5-20020a7bcb050000b029010e9316b9d5so1380551wmj.2; Mon, 08 Mar 2021 09:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RtI3enistM7uhqli0VcnJyALzr/7SL64KbbFjynlY2Q=; b=DdUAXxeQIzEpymz6s0YGOltDmgAXZ1FBpIJd3+Q4Z5OFMt9294K7ICyT2mSLvpI3JW TB1RI/v1/85yIgpMdKyHBv9e/Osur2/zn2GCfPP/grbvCIKq/Op+MjB8kpLOjt07slzz MidkXn5HPjyCtHjPRPlVCPyIriPpOFs+TJXDU9tFA+nCCvqovwZhK1FT7XDU5L774YZ9 EEQNw23H2UUW5bSTpZ45OLXWTi5qxdCt13n22BXbw/wreJ4X0plByaOmU0nb+k6fxu3V O+vRYaDnF2vWkyPxr2mFnSjMTxpzUWxBX6Si/OUOzdcgGxt47FHBpow1RdMww5SIu0cz r4eg== 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=RtI3enistM7uhqli0VcnJyALzr/7SL64KbbFjynlY2Q=; b=D/veTJEf4bj7XSu7Kb51L4tiFV+uOjEQ+CPWsWtXFn0dYGE1bfo0VYKJkt133QpA6E jGxVsb9GX5OTFoGwMcGRX8gW6un0TgBKW8akJh7vjkrRtSRETU7OW9fDtuEYJkEzGT7Q MQLEly0/qBE+un3JL1iMOVi3OTzdkdrdRzqPAQMESoZXqFKUX7R0pTXc7TutGpq92x6O Z2uJYm8NyOYn8u8aiHJ2OaTVK97GfRpjD2zz6FJCE1uGP1a3r492zTRmRUHMXesxG42F ALrGdIPlcQ/C+WCocHCLRwqsN+pzBcUEiSN5O4sWt6y31Fx3MZihBGoImqVeSkJ9Kx79 gbTQ== X-Gm-Message-State: AOAM531owI684wFK2S7cpi8BIsSwi7RpCGs30k3nNmxqpn3unMOlqlT7 vQc7EF94X+ITBurFRj1fnq6PaEm0aYK0kbA3bls0tpd7Xoo= X-Google-Smtp-Source: ABdhPJw3WAvuTBA9D8FAAuYIk3nePrZMiAT91Iu9+gsYsMYKQUXd/G+/byOl79TI60CsGGDOWMYijIlkrUDyP7md7Ag= X-Received: by 2002:a1c:f614:: with SMTP id w20mr3968794wmc.70.1615225628936; Mon, 08 Mar 2021 09:47:08 -0800 (PST) MIME-Version: 1.0 References: <05ce01d70b9a$f1c38230$d54a8690$@com> <0a2901d70f24$c15fcf80$441f6e80$@com> In-Reply-To: From: Rishabh Parekh Date: Mon, 8 Mar 2021 09:46:55 -0800 Message-ID: To: Ron Bonica Cc: Weiqiang Cheng , "srcomp@ietf.org" , SPRING WG List Content-Type: multipart/alternative; boundary="000000000000d8505805bd0a05e5" Archived-At: Subject: Re: [spring] [Srcomp] New drafts from SRCOMP design team X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 17:47:16 -0000 --000000000000d8505805bd0a05e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ron, SRv6 Replication SID does not need to follow IPv6 multicast address format since it is an IPv6 unicast address like any other SRv6 SID. -Rishabh On Tue, Mar 2, 2021 at 9:09 AM Ron Bonica wrote: > Rishabh, > > > > Is Section 2 of the SR replication segment draft compliant with Section > 2.7 of RFC 4291? Could it be brought into compliance by using the high > order 16 bits that RFC 4291 recommends? > > > > > = Ron > > > > > > > > Juniper Business Use Only > > *From:* Srcomp *On Behalf Of *Weiqiang Cheng > *Sent:* Tuesday, March 2, 2021 12:28 AM > *To:* 'Rishabh Parekh' > *Cc:* srcomp@ietf.org; 'SPRING WG List' > *Subject:* Re: [Srcomp] [spring] New drafts from SRCOMP design team > > > > *[External Email. Be cautious of content]* > > > > Hi Rishabh, > > Thanks for your comments. > > It is good point, and DT will consider the it in. > > > > B.R. > > Weiqiang Cheng > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA**:* spring [mailto:spring-bounces@ietf.org <= spring-bounces@ietf.org>] > *=E4=BB=A3=E8=A1=A8 *Rishabh Parekh > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2021=E5=B9=B42=E6=9C=8827=E6=97= =A5 01:50 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Weiqiang Cheng > *=E6=8A=84=E9=80=81:* srcomp@ietf.org; SPRING WG List > *=E4=B8=BB=E9=A2=98:* Re: [spring] New drafts from SRCOMP design team > > > > Weiqiang, > > Text quoted below from the SPRING charter indirectly covers > Point-to-Multipoint requirement which is addressed by SR Replication > Segment draft > https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment= / > > > New types of segments mapping to forwarding behaviour (e.g., local > > ingress replication, local forwarding resources, a pre-existing > > replication structure) if needed for new usages. > > For the Point-to-Multipoint compression requirement, what exactly is > "multicast address" in the Metric? Is this an IPv6 multicast address? If > so, it really does not conform to SRv6 data plane. > > > > I would rather consider the SRv6 Replication SID, described in the latest > version of SR Replication segment draft, to be the Metric for measuring > P2MP requirement. Maybe we should also consider adding it to SRv6 > Functionality Section 4.2.1 of the compression requirements draft. > > > > -Rishabh > > > > > > On Thu, Feb 25, 2021 at 9:25 AM Weiqiang Cheng < > chengweiqiang@chinamobile.com> wrote: > > Hi All, > > Two drafts have been submitted. Please review them and any comments are > welcomed. > > > > Compression requirement draft -04 version provided two more requirements: > > > https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-require= ment-04.txt > > > > > Compression analysis draft -00 provided a skeleton for the analysis of 4 > candidate proposals. > > > https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-analysi= s-00.txt > > > > > B.R. > > Weiqiang > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --000000000000d8505805bd0a05e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ron,
SRv6 Replication SID does not need to = follow IPv6 multicast address format since it is an IPv6 unicast address li= ke any other SRv6 SID.

-Rishabh
On Tue, M= ar 2, 2021 at 9:09 AM Ron Bonica <rbonica@juniper.net> wrote:

Rishabh,

=C2=A0

Is Section 2 of the SR replication segment draft comp= liant with Section 2.7 of RFC 4291? Could it be brought into compliance by = using the high order 16 bits that RFC 4291 recommends?=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0Ron

=C2=A0

=C2=A0

=C2=A0

Juniper Business Use Only<= u>

From: Srcomp <srcomp-bounces@ietf.org> On Behalf Of Weiqiang Cheng
Sent: Tuesday, March 2, 2021 12:28 AM
To: 'Rishabh Parekh' <rishabhp@gmail.com>
Cc: srcomp@ietf= .org; 'SPRING WG List' <spring@ietf.org>
Subject: Re: [Srcomp] [spring] New drafts from SRCOMP design team=

=C2=A0

[External Email. Be cautious of co= ntent]

=C2=A0

Hi Rishabh,

Thanks for your comments.

It is good point, and DT will = consider the it in.

=C2=A0

B.R.

Weiqiang Cheng

=C2=A0

=E5= =8F=91=E4=BB=B6=E4=BA=BA: spring [mailto:spring-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Rishabh Parekh
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 20= 21=E5=B9=B42=E6=9C=8827=E6=97=A5 01:50
=E6=94=B6=E4=BB=B6=E4=BA=BA: Weiqiang Ch= eng
=E6=8A=84=E9=80=81: srcomp@ietf.org; SPRING WG List
=E4=B8=BB=E9=A2=98: Re: [spring] New dra= fts from SRCOMP design team

=C2=A0

Weiqiang,

Text quoted below from the SPRING charter indi= rectly covers Point-to-Multipoint requirement which is addressed by SR Repl= ication Segment draft https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/<= /a>

New types of segments mapping to forwarding behaviour (e.g., loc=
al
ingress replication, local forwarding resources, a pre-existing<=
u>
replication structure) if needed for new usages.

For the Point-to-Multipoint compression requir= ement, what exactly is "multicast address" in the Metric? Is this= an IPv6 multicast address? If so, it really does not conform to SRv6 data = plane.

=C2=A0

I would rather consider the SRv6 Replication S= ID, described in the latest version of SR Replication segment draft, to be = the Metric for measuring P2MP requirement. Maybe we should also consider ad= ding it to SRv6 Functionality Section 4.2.1 of the compression requirements dra= ft.

=C2=A0

-Rishabh

=C2=A0=

=C2=A0

Hi All,

Two drafts have been submitted.=C2=A0 Please r= eview them and any comments are welcomed.

=C2=A0

Compression requirement draft -04 version prov= ided two more requirements:

https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-r= equirement-04.txt

=C2=A0

Compression analysis draft -00 provided a skel= eton for the analysis of 4 candidate proposals.

https://www.ietf.org/archive/id/draft-srcompdt-spr= ing-compression-analysis-00.txt

=C2=A0

B.R.

Weiqiang

______________________________________________= _
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spr= ing

--000000000000d8505805bd0a05e5--