From nobody Wed Feb 15 21:30:10 2023 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 84524C169523; Wed, 15 Feb 2023 21:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09DCsw9Oib3H; Wed, 15 Feb 2023 21:30:04 -0800 (PST) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AA2C169522; Wed, 15 Feb 2023 21:30:04 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id a10so1214285edu.9; Wed, 15 Feb 2023 21:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1VQGenKYa5aPj6BHPT3qBhS/ebSFTZTyhySxFcATBtU=; b=KZNaqpzoxWW9YOD454GySJlQcKS33c+ONDFTokpY8hsFFXIQYtLM0xJzy7njfa4IRX VsNMGk5FLYejMv+C2EeUHy0xVs4Fd4/cdTnIDOr1BsSELZS3ZzTZvniH2Vv4MhkCm1dD oly5zzlrX+nXMKyjGwcmr3hVeeTuI4ctc/HQR7aPDisMACvGoVqu0/dcxP1fDyh4quJ+ ijEx4aACdx2kEx4m9aUjsN+er2ea0bLkMNG2ACRaylLmpa+uE20ARllkQUHPWZSHR9rs xuSxKJMChKV3iIJYrvg9hBqMh0iT4PWtFfJfxk1BM1G6we1ACmQOInKfr0wkTqMNJYv9 GOYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1VQGenKYa5aPj6BHPT3qBhS/ebSFTZTyhySxFcATBtU=; b=IpAp0rvM1r4rYLBw3Ya8bY9j00S/tltQvNukgI9ENZX3yZz4K+6ym95c1P1rKj1NKd LTwCanxofdqKAGq8tqr2q3XqJT60gaUlLti7LQxqUw8ed1QC69ubvdPID0H9VcvjJO6R WRHMVskG9UnU389YtIlt2Tzdrr9LTwOhaPM8CySdeqqmhil0D/lA+Kp8pMg/6xMG5pYg F3BITrB4Nc45oWuWr0D1uqq5aWfCGvdxDIYXrzzKY64wU3oJq0HHie2of3jMvpzpzcBP pDyEPhuET+c5HCnr0uqj9ON4sRNDT2GxP3hVXZwvGvHZmkbq7r0KbqFdH+QwNKfbs6Bd TZww== X-Gm-Message-State: AO0yUKVxo/HXdXcvf1gnJGJ0zkpjanDWgQQif4VWrrfFWQRAKZAIUOpP mxNQwxDeo562kAwduAglkJCsL2UmOa2PhDoZ7ik= X-Google-Smtp-Source: AK7set8knKO6I1hZIuCbky12WSF2ulpyZzJVWGvUf2iMvssplk83VhgsNHjNChJdcqsRjpLGP5sN5kS8y6pGsjYNrts= X-Received: by 2002:a50:d657:0:b0:4a8:2436:4ed2 with SMTP id c23-20020a50d657000000b004a824364ed2mr2360412edj.0.1676525402343; Wed, 15 Feb 2023 21:30:02 -0800 (PST) MIME-Version: 1.0 References: <52270_1676021265_63E60E10_52270_250_1_AS2PR02MB88396E9E3C714762089A301BF0DE9@AS2PR02MB8839.eurprd02.prod.outlook.com> In-Reply-To: From: Rishabh Parekh Date: Wed, 15 Feb 2023 21:29:49 -0800 Message-ID: To: James Guichard Cc: "bruno.decraene@orange.com" , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000104d5105f4ca7d3e" Archived-At: Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2023 05:30:08 -0000 --000000000000104d5105f4ca7d3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable James, Replies inline @ [RP] On Wed, Feb 15, 2023 at 6:58 AM James Guichard < james.n.guichard@futurewei.com> wrote: > Hi Rishabh, Authors, & WG: > > > > Having reviewed the latest version of > https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment= / > > I would appreciate some clarification from the authors on the specifics o= f > packet replication and forwarding between the replication point and > downstream nodes. The draft as I read it bases forwarding at a replicatio= n > point on the combination of a replication SID which triggers and selects > the behavior and the replication state held at that node. The replication > state indicates which downstream nodes the packet should be replicated to > and those nodes may or may not be adjacent to the replication node. In th= e > non-adjacent case my understanding is that the replication state may > include an additional segment-list and this seems to be what the text in > section 2.2. is saying by referencing H.Encaps.Red to re-encapsulate the > packet with a new SRH and outer IPv6 header. If this is correct could it = be > made more explicit; at a minimum I would expect to see a reference to RFC > 8986 section 5.2. > [RP] Your understanding is correct. We can add a reference to RFC 8986 Section 5.2 as you suggest, but you say "... could it be made more explicit ..". Do you mean the current text is not clear about this? > > > In addition to this I would like to clarify the case where > re-encapsulation is not needed i.e. when an explicit path to a downstream > node is not necessary and best path forwarding suffices. The text says th= at > in this case the outer IPv6 header is re-used and the downstream > replication SID is written into the IPv6 header destination address. This > address is most likely NOT contained within the SRH which is a detachment > from the normal SRv6 forwarding case and I would like to hear the authors > and WGs opinions on this. > [RP] Yes, an encapsulation is not needed when a Downstream node is adjacent or best path forwarding to a non-adjacent node is sufficient. The downstream node's Replication SID (from Replication State) is written in outer IPv6 DA and packet is forwarded based on the locator of the downstream node. Our (i.e. authors) opinion is that is permissible within the SRv6 architecture by new End.Replication behavior (associated with incoming local Replication SID) defined in the draft. Furthermore, there is already precedence in SRv6 architecture to process an incoming packet based on local state and forward the modified packet. RFC 8986 defines End.B6.Encaps and End.B6.Encaps.Red (and End.BM) functions that rely on local SR policy state to modify an incoming packet. Thanks, -Rishabh --000000000000104d5105f4ca7d3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
James,
Replies inline @ [R= P]

On Wed, Feb 15, 2023 at 6:58 AM James Guichard <james.n.guichard@futurewei.com>= ; wrote:

Hi Rishabh, Authors, & WG:

=C2=A0

Having reviewed the latest version of https://datatracker.ietf.org/doc/draft-= ietf-spring-sr-replication-segment/ I would appreciate some clar= ification from the authors on the specifics of packet replication and forwa= rding between the replication point and downstream nodes. The draft as I read it bases forwarding at a replication= point on the combination of a replication SID which triggers and selects t= he behavior and the replication state held at that node.=C2=A0The replicati= on state indicates which downstream nodes the packet should be replicated to and those nodes may or may not be adjac= ent to the replication node. In the non-adjacent case my understanding is t= hat the replication state may include an additional segment-list and this s= eems to be what the text in section 2.2. is saying by referencing H.Encaps.Red to re-encapsulate the packet wi= th a new SRH and outer IPv6 header. If this is correct could it be made mor= e explicit; at a minimum I would expect to see a reference to RFC 8986 sect= ion 5.2.


[RP] Your understand= ing is correct. We can add a reference to RFC 8986 Section 5.2 as you sugge= st, but you say "... could it be made more explicit ..". Do you mean the current text is n= ot clear about this?
=

=C2=A0

In addition to this I would like to clarify the case= where re-encapsulation is not needed i.e. when an explicit path to a downs= tream node is not necessary and best path forwarding suffices. The text say= s that in this case the outer IPv6 header is re-used and the downstream replication SID is written into the I= Pv6 header destination address. This address is most likely NOT contained w= ithin the SRH which is a detachment from the normal SRv6 forwarding case an= d I would like to hear the authors and WGs opinions on this.


[RP] Yes, an encapsulation is not needed when a Downstream node is ad= jacent or best path forwarding to a non-adjacent node is sufficient. The do= wnstream node's Replication SID (from Replication State) is written in = outer IPv6 DA and packet is forwarded based on the locator of the downstrea= m node. Our (i.e. authors) opinion is that is permissible within the SRv6 a= rchitecture by new End.Replication behavior (associated with incoming local= Replication SID) defined in the draft. Furthermore, there is already prece= dence in SRv6 architecture to process an incoming packet based on local sta= te and forward the modified packet. RFC 8986 defines End.B6.Encaps and End.= B6.Encaps.Red (and End.BM) functions that rely on local SR policy state to = modify an incoming packet.

Thanks,
-Rish= abh

--000000000000104d5105f4ca7d3e--